CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
  1. Cloud Pass
  2. GCP
  3. Google Professional Cloud Architect
Google Professional Cloud Architect

GCP

Google Professional Cloud Architect

199+ 기출 문제 (AI 검증 답안 포함)

Free questions & answers실제 시험 기출 문제
AI-powered explanations상세 해설
Real exam-style questions실제 시험과 가장 유사
199+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 Google Professional Cloud Architect 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

시험 도메인

Designing and Planning a Cloud Solution Architecture출제율 25%
Managing and Provisioning a Cloud Solution Infrastructure출제율 17%
Designing for Security and Compliance출제율 17%
Analyzing and Optimizing Technical and Business Processes출제율 15%
Managing Implementation출제율 12%
Ensuring Solution and Operations Excellence출제율 12%

실전 문제

1
문제 1

A global logistics firm operates 650 smart loading bays across 8 distribution centers on 3 continents, and each bay has a beam-break sensor that reports its state once per second; each event contains only a sensor ID and several discrete status flags, and analysts must correlate this data with driver account records, scheduled dock assignments, and warehouse location metadata to run join-heavy queries and produce operational reports; which database type should you use?

flat files(예: filesystem 또는 object storage의 CSV/JSON)은 원시 저장과 단순 배치 처리에는 저렴하지만, 빈번하고 join-heavy한 분석 쿼리에 최적화된 데이터베이스 유형은 아닙니다. join 성능을 확보하려면 외부 쿼리 엔진과 신중한 데이터 모델링이 필요합니다. 또한 스키마 진화, indexing, 동시 분석가 접근을 관리하는 것도 관계형/SQL 시스템에 비해 어렵습니다.

NoSQL 데이터베이스(document, key-value, wide-column)는 고속 센서 이벤트를 ingest하고 수평 확장이 가능하지만, 일반적으로 복잡한 관계형 join을 효율적으로 지원하지 않습니다. 이벤트를 운전자, 배정, 위치 메타데이터와 연관시키려면 보통 데이터를 denormalize하거나 애플리케이션 코드 또는 파이프라인에서 join을 수행해야 하며, 이는 복잡도를 높이고 불일치 위험을 키웁니다. NoSQL은 단순한 액세스 패턴에는 적합하지만 분석가 주도의 join-heavy 리포팅에는 적합하지 않습니다.

관계형 데이터베이스는 관계가 있는 구조화된 데이터를 위해 설계되었고 SQL을 사용한 효율적인 join을 지원합니다. 이는 센서 이벤트를 운전자 계정, 도크 스케줄, 창고 메타데이터와 연관시켜야 한다는 요구사항과 일치합니다. Google Cloud에서는 BigQuery가 대규모 운영 리포팅과 join-heavy 분석을 위한 일반적인 선택입니다(partitioning, clustering, distributed joins). 워크로드가 주로 트랜잭션이라면 Cloud Spanner/Cloud SQL을 고려하겠지만, 문제는 분석을 강조합니다.

blobstore(Cloud Storage 같은 object storage)는 원시 이벤트 로그, 백업, data lake 파일을 내구성 있게 저비용으로 저장하는 데 이상적이지만, 인터랙티브한 join-heavy 쿼리를 위한 데이터베이스는 아닙니다. join과 리포팅을 수행하려면 여전히 SQL 엔진(예: BigQuery external tables)으로 데이터를 load/query해야 합니다. blob storage 자체에는 indexing, query planning, 관계형 기능이 없습니다.

문제 분석

핵심 개념: 이 문제는 쿼리 패턴에 따라 올바른 데이터베이스 모델을 선택하는지를 평가합니다. 핵심 요구사항은 “join-heavy queries”로, 고빈도 센서 이벤트를 여러 참조 데이터셋(운전자 계정, 도크 배정, 창고/위치 메타데이터)과 연관시키는 것입니다. 이는 정규화된 dimension을 fact/event 테이블과 join하는 관계형/SQL 분석 패턴을 가리킵니다. 정답이 맞는 이유: 관계형 데이터베이스 유형은 join, referential integrity, 그리고 여러 엔터티에 걸친 표현력 있는 SQL을 강하게 지원해야 할 때 가장 적합합니다. 여기서는 분석가들이 운영 보고서를 만들기 위해 센서 이벤트를 여러 구조화된 테이블과 일상적으로 join해야 합니다. SQL 엔진과 관계형 스키마(fact + dimensions)는 이를 위해 설계되었습니다. Google Cloud에서는 일반적으로 대규모 분석 join(컬럼형 스토리지, 분산 실행)을 위해 BigQuery에 매핑되며, 워크로드가 주로 트랜잭션이라면 Cloud Spanner/Cloud SQL이 해당됩니다. 650개 센서가 초당 1회 보고(~650 events/sec, ~56M/day)하는 상황에서, join이 많은 분석/리포팅은 BigQuery의 강점과 강하게 부합합니다. 핵심 기능 / 모범 사례: star schema를 사용하세요: 이벤트를 위한 큰 append-only fact 테이블(ingestion/event time 기준 partitioning, sensor_id 또는 distribution_center 기준 clustering)과 운전자, 배정, 위치를 위한 dimension 테이블로 구성합니다. BigQuery는 standard SQL joins, 비용/성능을 위한 partitioning/clustering을 지원하며 Pub/Sub + Dataflow로 ingest할 수 있습니다. 배정/계정에 대해 전 세계적으로 일관된 OLTP 업데이트가 필요하다면, 이를 트랜잭션 스토어(예: Spanner/Cloud SQL)에 유지하고 리포팅을 위해 BigQuery로 replicate/export하세요. 흔한 오해: NoSQL은 “IoT/time-series”에 자주 선택되지만, 많은 NoSQL 시스템은 복잡한 join을 포기하는 대신 denormalize하거나 애플리케이션 측 join을 수행해야 하며, 이는 분석가 주도의 ad hoc 리포팅에는 비효율적입니다. flat files 또는 blob storage는 데이터를 저렴하게 저장할 수 있지만 쿼리 최적화, indexing, join 실행을 제공하지 않습니다. 시험 팁: 쿼리 패턴이 선택을 좌우하게 하세요: “join-heavy”, “analysts”, “reports”는 관계형/SQL 분석을 강하게 시사합니다. GCP에서는 대규모 분석 join이면 BigQuery를 떠올리세요. 운영 앱을 위해 저지연 트랜잭션 업데이트와 강한 일관성이 추가로 필요할 때만 별도의 OLTP 데이터베이스를 고려하세요.

2
문제 2

A ticketing company needs to expose a public HTTPS webhook API written in Go 1.20 that is idle most of the day but can surge from ~0 to 10,000 requests per minute within 90 seconds when major sales go live; the service must maintain at least 99.95% availability during spikes, support request timeouts up to 60 seconds, auto-scale without pre-provisioning capacity, and minimize operational overhead by avoiding server, cluster, or OS management—what deployment approach should you recommend?

Google Kubernetes Engine는 Go 1.20 container를 실행하고 horizontal scaling을 수행할 수는 있지만, cluster management를 피해야 한다는 요구 사항을 충족하지 못합니다. 매우 managed된 GKE 모드에서도 cluster configuration, deployment strategy, scaling behavior, 그리고 security 및 upgrade lifecycle의 일부는 여전히 사용자가 책임져야 합니다. 또한 pre-provisioned capacity 없이 near-zero 상태에서 rapid scale을 수행하는 것은 더 어렵습니다. sudden spikes 동안 node provisioning과 pod startup이 지연을 유발할 수 있기 때문입니다. 따라서 GKE는 단순한 public webhook API에 비해 필요 이상으로 operationally heavy합니다.

App Engine standard는 low-ops autoscaling web services에 매력적이지만, 애플리케이션이 Go 1.20을 명시적으로 요구하고 선택지에 compatible runtime generation 또는 custom runtime 지원이 언급되지 않은 경우에는 최선의 답이 아닙니다. standard environment는 flexible보다 더 opinionated하고 제약이 많아서, 정확한 language versions와 dependencies에 대한 compatibility issues를 만들 수 있습니다. autoscale은 잘할 수 있지만, 여기서는 runtime requirement가 결정적인 요소입니다. 따라서 custom runtime을 사용하는 App Engine flexible보다 덜 적합합니다.

Compute Engine의 Managed Instance Group은 VM images, OS patching, instance templates, 그리고 scaling behavior를 관리해야 하므로 operational requirements와 가장 맞지 않습니다. highly available하고 autoscaled되도록 구성할 수는 있지만, idle 상태에서 매우 높은 traffic으로 90초 이내에 갑자기 급증하는 상황을 처리하려면 종종 warm capacity나 세심한 tuning이 필요합니다. 이는 operational overhead를 최소화하고 server management를 피하려는 목표와 직접적으로 충돌합니다. MIG는 VM-level control이 필요할 때 더 적합하며, 이 시나리오에서는 그런 요구가 없습니다.

App Engine flexible environment는 custom runtimes를 지원하므로, 정확한 runtime version이 중요한 Go 1.20 애플리케이션에 여기서는 가장 강력한 선택지입니다. HTTP services를 배포하기 위한 managed platform을 제공하며, built-in HTTPS 지원과 autoscaling을 갖추고 있고, servers, operating systems, 또는 Kubernetes clusters를 직접 관리할 필요가 없습니다. VM-backed이기는 하지만, GKE나 Managed Instance Groups와 비교하면 operational overhead를 여전히 크게 줄여 줍니다. 또한 60초를 훨씬 초과하는 request duration도 지원하므로, webhook 스타일 API의 timeout requirement를 충분히 충족합니다.

문제 분석

핵심 개념: 급격한 autoscaling, managed operations, runtime flexibility, 그리고 HTTP request handling 제약 조건 사이에서 가장 적절한 균형을 제공하는 Google Cloud compute platform을 선택하는 것입니다. 이 workload는 Go 1.20으로 작성된 public HTTPS webhook API이며, 대부분의 시간에는 idle 상태이지만 빠르게 급증할 수 있고, 최대 60초의 request duration이 필요하며, server, cluster, 또는 OS 관리를 피해야 합니다. 정답인 이유: custom runtime을 사용하는 App Engine flexible environment는 containerized deployment model에서 Go 1.20을 지원하면서도 대부분의 infrastructure operations를 추상화하며, HTTPS를 통해 노출되는 web services에 대해 automatic scaling을 지원합니다. 핵심 기능: custom runtime 지원, managed HTTPS ingress, autoscaling, 그리고 Kubernetes clusters나 Compute Engine instances를 직접 관리할 필요가 없다는 점입니다. 흔한 오해: App Engine standard는 low-ops web apps에 자주 선택되지만, 특정 최신 language runtime과 custom environment가 필요한 경우 runtime 제약과 platform 제한 때문에 적합성이 떨어집니다. 시험 팁: 문제가 standard runtimes에서 기본적으로 보장되지 않는 특정 runtime version, minimal ops, 그리고 autoscaling을 강조한다면, Cloud Run이 선택지에 없을 경우 GKE나 Compute Engine보다 managed custom-runtime platform을 우선 고려하세요.

3
문제 3

Your media analytics firm stores 150 TB of sensitive video feature vectors on regional SSD persistent disks attached to a Dataproc cluster in us-central1. For regulatory reasons, you must be able to rotate the encryption key protecting the data at rest on these disks at least every 90 days without manually re-encrypting data or changing Spark jobs. Pipelines must continue to run with minimal operational overhead and no plaintext copies written to intermediate storage. You want to follow Google-recommended practices for security. What should you do?

ingestion jobs에서 Cloud KMS를 사용한 암호화(application-level encryption)는 기밀성 목표를 충족할 수 있지만, Spark jobs/processing logic을 변경하지 말아야 한다는 요구사항을 위반하고 운영 오버헤드를 증가시킵니다. 또한 Spark에서 복호화가 필요하므로 처리 중 plaintext 노출 위험이 있으며, 신중하게 설계하지 않으면 plaintext intermediates(shuffle/spill/temp files)를 만들 수 있습니다. 이는 disk-at-rest key rotation에 대해 Google이 권장하는 가장 단순한 접근이 아닙니다.

persistent disks에 대한 CMEK가 올바른 접근입니다: Dataproc에 연결된 regional SSD persistent disks가 Cloud KMS key를 사용하도록 구성합니다. 새로운 key versions를 추가하고 새로운 primary version을 설정하여 rotation을 수행하면, 150 TB를 수동으로 재암호화하거나 Spark jobs를 수정하지 않고도 정기적인 rotation이 가능합니다. 암호화는 HDFS/Spark에 투명하게 적용되며, 운영 오버헤드를 최소화하고, intermediate storage로의 plaintext copies를 피하며, centralized auditing과 access control을 제공합니다.

GPG 기반 암호화는 커스텀 방식으로 운영 부담이 크고, Google Cloud의 managed encryption controls와 통합되어 있지 않습니다. Spark jobs 내부에서 key distribution, rotation, decryption을 관리해야 하므로 잡 변경을 피하고 오버헤드를 최소화해야 한다는 요구사항과 충돌합니다. 또한 처리 중 memory, temp files, spill locations에 plaintext 데이터가 나타날 위험을 증가시키며, 권장되는 managed-cloud 관행이 아닙니다.

CSEK(customer-supplied encryption keys)는 각 disk operation마다 raw AES-256 key material을 Google에 제공해야 하며, secure storage, rotation, access를 직접 관리해야 합니다. 이는 상당한 운영 오버헤드와 더 높은 위험(key handling, distribution, potential loss)을 초래합니다. 또한 key versions를 통해 제어, auditing, rotation을 중앙화하는 CMEK with Cloud KMS에 비해 Google 권장 관행과의 정렬이 떨어집니다.

문제 분석

핵심 개념: 이 문제는 Cloud KMS customer-managed encryption keys (CMEK)를 사용하여 Google Cloud persistent disks의 at rest 암호화를 구현하는 방법과, 데이터를 재암호화하거나 애플리케이션을 변경하지 않고 키 rotation이 어떻게 동작하는지를 평가합니다. 또한 Dataproc이 Compute Engine persistent disks를 사용하는 방식과 Google 권장 보안 모범 사례도 함께 다룹니다. 정답이 맞는 이유: Dataproc cluster의 persistent disks에 Cloud KMS의 CMEK를 사용하면, Google-managed disk encryption이 여러분의 KMS key로 wrapping되는 형태로 동작합니다. 키 rotation은 Cloud KMS에서 새로운 key version을 생성하고 이를 primary로 설정하는 방식으로 수행됩니다. 이후 새로운 write는 새 version을 사용하며, Google이 data encryption keys의 cryptographic wrapping/rewrapping을 처리하므로 150 TB를 수동으로 재암호화할 필요가 없고, Spark jobs를 변경할 필요도 없으며, plaintext intermediate copies도 생성하지 않습니다. 암호화/복호화는 VM 및 HDFS layer에 투명하게 적용되므로, 최소한의 운영 오버헤드로 pipeline을 계속 실행할 수 있습니다. 주요 기능 / 구성: - regional 제약을 충족하고 운영 이슈를 줄이기 위해, disks와 동일한 location/region(us-central1)에 Cloud KMS key ring과 key를 생성합니다. - Dataproc/Compute Engine persistent disks를 생성할 때 CMEK를 사용하도록 구성합니다(그리고 IAM: Compute Engine/Dataproc service accounts에 roles/cloudkms.cryptoKeyEncrypterDecrypter가 있는지 확인). - 새로운 key versions를 추가하고 새로운 primary version을 승격하여 rotation을 수행하며, Cloud KMS policies와 Cloud Audit Logs를 통해 rotation을 감사(audit)하고 강제(enforce)합니다. - Google Cloud Architecture Framework의 보안 원칙(centralized key management, least privilege, auditability, automation)과 정렬됩니다. 흔한 오해: 많은 사람들이 키를 rotation하려면 애플리케이션(Spark/HDFS)에서 데이터를 암호화해야 한다고 생각합니다. 하지만 이는 복잡성을 증가시키고 plaintext spill 위험을 키우며 코드/잡 변경을 요구합니다. 또 다른 오해는 CMEK와 CSEK를 혼동하는 것입니다. CSEK는 요청마다 raw keys를 제공하고 관리해야 하므로 운영 부담과 위험이 증가합니다. 시험 팁: “데이터를 재암호화하지 않고 키를 rotation” 및 “앱 변경 없음” 요구사항이 있으면, storage layer(Persistent Disk, Cloud Storage, BigQuery 등)에 통합된 CMEK with Cloud KMS를 우선 선택하세요. CSEK는 작업별로 key material을 Google에 제공해야 한다는 요구가 명시적으로 있을 때만 선택합니다. 또한 location 제약을 주의하세요: KMS key location은 리소스의 location/region과 일치해야 합니다.

4
문제 4

Cinemetrix, a media analytics firm, enabled Google Workspace (domain: cinemetrix.com) last week and created a Google Cloud Organization; they currently have 85 projects across 6 folders. The security office now mandates that, effective immediately, no principals from outside cinemetrix.com may be granted any IAM role on any project, folder, or resource within the Organization. The control must be enforced centrally at the Organization level, automatically apply to newly created projects, work without custom scripts or periodic jobs, take effect within 30 minutes, and must not break existing or future service-account-based workloads. What should you do?

정답입니다. constraints/iam.allowedPolicyMemberDomains는 허용된 identity domain/customer를 기준으로 IAM policies에 어떤 principals가 포함될 수 있는지 제한하도록 특별히 설계된 Organization Policy constraint입니다. 이를 Organization 루트에 적용하면 중앙 집중식 거버넌스와 모든 folders 및 projects로의 상속이 제공되므로, 기존 resources와 새로 생성되는 projects가 자동으로 모두 적용 대상이 됩니다. 이는 preventive control이므로 허용되지 않은 외부 principals를 추가하려는 시도는 나중에 정리되는 것이 아니라 policy 업데이트 시점에 거부됩니다. 또한 custom scripts나 주기적 jobs를 피해야 한다는 요구 사항에도 부합하며, 이러한 유형의 guardrail에 대한 표준 Google Cloud 메커니즘입니다.

오답입니다. service account 생성을 방지하는 것은 관리자가 외부 users, groups 또는 domains에 IAM roles를 부여하는 것을 막지 못하며, 이것이 바로 문제의 실제 요구 사항입니다. 이는 완전히 다른 문제를 다루는 것이며, authentication 및 authorization을 위해 service accounts에 의존하는 많은 workloads와 Google Cloud services를 방해할 가능성이 큽니다. 문제에서는 기존 또는 향후의 service-account-based workloads를 중단시키면 안 된다고 명시하고 있으므로, 이 선택지는 그 요구 사항과 충돌합니다. 또한 IAM members에 대한 요청된 domain 기반 제한도 제공하지 못합니다.

오답입니다. Cloud Scheduler와 Cloud Function 솔루션은 custom scripted remediation process이며, 문제에서 이를 명시적으로 배제하고 있습니다. 또한 이는 preventive가 아니라 reactive 방식이므로, 외부 principal이 access를 부여받은 뒤 다음 예약 실행 시점까지 그 access를 유지할 수 있어 compliance 및 security 공백이 발생합니다. 60분마다 실행되므로 30분 이내에 적용되어야 한다는 요구 사항도 충족하지 못합니다. 운영 측면에서도 복잡성이 증가하고, policies를 검사하고 수정하기 위해 광범위한 IAM permissions가 필요하며, 기본 제공되는 Organization Policy control보다 신뢰성이 떨어집니다.

오답입니다. VM에서 cron job을 실행하여 IAM policies를 스캔하고 수정하는 것은 또 다른 custom periodic remediation 접근 방식이므로, scripts와 scheduled jobs를 피해야 한다는 요구 사항을 위반합니다. option C와 마찬가지로 preventive 방식이 아니며, 그 결과 승인되지 않은 외부 principals가 access를 유지할 수 있는 시간적 공백이 생깁니다. 또한 특히 VM 또는 technical user가 Organization-level Owner privileges를 가지고 있다면 불필요한 운영 부담과 security risk를 초래합니다. 이는 문제에서 시사하는 managed, inherited, policy-based control과는 정반대입니다.

문제 분석

핵심 개념: 이 문제는 IAM을 위한 Organization Policy Service를 사용한 중앙집중식 예방 거버넌스를 테스트하며, 특히 전체 Google Cloud Organization 전반에서 IAM 정책에 추가될 수 있는 주체(principal)를 제한하는 내용입니다. 이는 Google Cloud Architecture Framework의 Security, Privacy, and Compliance pillar와 정렬됩니다: policy-as-code 가드레일을 중앙에서, 일관되게, 자동으로 강제합니다. 정답이 맞는 이유: 요구사항은 Organization 어디에서든(프로젝트, 폴더, 리소스) cinemetrix.com 외부의 principal이 IAM role을 부여받지 못하도록 하고, 새 프로젝트에도 자동 상속되며, 스크립트/잡 없이, 거의 실시간(약 30분 이내)으로 강제하는 것입니다. Organization policy constraint인 constraints/iam.allowedPolicyMemberDomains는 정확히 이를 위해 설계되었습니다: IAM policy member를 고객이 관리하는 identity domain allowlist로 제한합니다. Organization root에 설정하면(명시적으로 override하지 않는 한) 모든 폴더/프로젝트에 상속되며(override를 막도록 강제할 수도 있음), 예방적 통제를 제공합니다: 허용되지 않은 principal을 추가하려는 시도는 거부됩니다. 주요 기능 / 구성 참고사항: - Organization 노드에서 정책을 설정하여 cinemetrix.com Cloud Identity/Google Workspace domain만 허용합니다. - service account가 깨지지 않도록 주의: 워크로드는 흔히 Google-managed service account identity(예: *.gserviceaccount.com)를 사용합니다. 이 constraint는 필요한 service account domain을 허용할 수 있어, 기존/향후 service-account 기반 워크로드가 계속 동작하도록 합니다. - 상속을 통해 새로 생성되는 프로젝트도 추가 자동화 없이 자동으로 준수합니다. - Organization Policy 변경은 일반적으로 빠르게 전파되며(문제의 30분 요구사항은 기대되는 전파 동작과 일치), 요구사항을 충족합니다. 흔한 오해: 많은 응시자는 “예방”이 아니라 “스캔 및 수정”(스케줄된 스크립트)으로 바로 넘어갑니다. 수정(remediation) 잡(Cloud Scheduler/cron)은 즉시성이 없고, 짧게 부여된 권한을 놓칠 수 있으며, 운영 리스크를 추가하고, no-scripts 요구사항을 위반합니다. 또 다른 오해는 service account 생성을 차단하는 것인데, 이는 외부 사용자가 role을 부여받는 것을 막지 못하고 워크로드를 깨뜨립니다. 시험 팁: - 중앙집중식, 자동, 예방적 통제를 위해 Organization Policy constraint를 우선 고려하세요. - 예방 가드레일(Org Policy)과 탐지/수정 통제(Asset Inventory + Functions, cron jobs)를 구분하세요. - IAM member를 제한할 때는 service account 및 Google-managed identity를 항상 고려하여 플랫폼 서비스와 CI/CD pipeline을 방해하지 않도록 하세요. - “새 프로젝트에 자동 적용” 및 “주기적 잡 없음”이 요구되면, Organization root의 Organization Policy가 강한 시그널입니다.

5
문제 5

Your retail analytics team needs to run 40 legacy Hadoop MapReduce jobs on Google Cloud for weekly batch processing without changing any job code or deployment scripts; they want to minimize both compute cost and infrastructure management effort; each batch runs 3–6 hours and the pipelines can tolerate up to 20% worker loss without failing. What should you do?

standard workers를 사용하는 Dataproc은 Dataproc이 managed Hadoop 서비스이므로 “code/script 변경 없음”과 “관리 최소화” 요구사항은 충족합니다. 그러나 “compute 비용 최소화” 요구사항을 가장 잘 충족하지는 못합니다. 주 1회 3–6시간 배치의 경우, 워크로드가 worker 손실을 허용하고 더 저렴한 preemptible capacity를 활용할 수 있는데도 모든 worker에 대해 full on-demand 가격을 지불하는 것은 일반적으로 불필요합니다.

preemptible workers를 사용하는 Dataproc은 모든 제약 조건에 가장 부합합니다: managed Hadoop(최소 ops), 기존 MapReduce job과의 호환성(code 변경 없음), 그리고 더 낮은 compute 비용. 파이프라인이 최대 20% worker 손실을 허용할 수 있으므로 preemption은 수용 가능하며, YARN이 task를 재스케줄링할 수 있고 클러스터를 적절히 사이징하면 job은 완료될 수 있습니다. 안정성을 위해 master는 standard instances로 유지합니다.

standard instances를 사용하는 Compute Engine의 self-managed Hadoop 클러스터는 인프라 관리 노력을 증가시킵니다: Hadoop 설치/구성, 업그레이드/패치 관리, 모니터링 처리, 클러스터 신뢰성 유지가 필요합니다. legacy job을 code 변경 없이 실행할 수는 있지만, “인프라 관리 노력 최소화” 요구사항을 충족하지 못하며, 주기적 배치 워크로드에서는 Dataproc보다 운영 측면에서 더 비싼 경우가 많습니다.

preemptible instances에서 self-managed Hadoop을 운영하면 compute 비용은 줄일 수 있지만, 운영 복잡성과 리스크가 크게 증가합니다. preemption 처리, 노드 교체, 클러스터 상태를 다루기 위한 자동화를 구축해야 하고, 여전히 Hadoop lifecycle을 직접 관리해야 합니다. 이는 인프라 관리 노력을 최소화하라는 요구사항과 충돌합니다. Dataproc은 managed control plane과 더 단순한 통합을 제공하면서도 preemptible workers를 사용할 수 있게 해줍니다.

문제 분석

핵심 개념: 이 문제는 배치 MapReduce 워크로드에 대해 적절한 managed Hadoop 서비스와 VM 구매 모델을 선택하는지를 평가합니다. 핵심 서비스는 Cloud Dataproc(managed Hadoop/Spark)과 Compute Engine(self-managed Hadoop)입니다. 핵심 가격/가용성 개념은 preemptible VMs(최신 용어로 Spot VMs)로, 비용이 크게 저렴하지만 종료될 수 있습니다. 정답이 맞는 이유: 팀은 “어떤 job code나 deployment scripts도 변경하지 않고” 40개의 legacy Hadoop MapReduce job을 실행해야 하며, 인프라 관리 작업을 최소화하길 원합니다. Cloud Dataproc은 managed Hadoop 환경(HDFS/YARN/MapReduce)을 제공하고 Cloud Storage와 통합되므로, 최소한의 변경으로 기존 Hadoop job을 실행하도록 설계되어 있습니다. compute 비용을 최소화하려면 preemptible worker instances를 사용합니다. 워크로드는 주 1회, 3–6시간이며 worker 손실을 최대 20%까지 허용할 수 있으므로, 가끔 VM이 종료되더라도 클러스터에 충분한 용량이 있고 YARN이 task를 재스케줄링할 수 있다면 preemptible workers와 잘 맞습니다. 핵심 기능 / Best Practices: - Dataproc은 ops 노력을 줄입니다: 자동화된 클러스터 프로비저닝, 구성, 모니터링 통합, 간편한 job 제출. - 비용 절감을 위해 preemptible workers를 사용(종종 60–80% 더 저렴)하되, 안정성을 위해 master(그리고 선택적으로 일부 core workers)는 standard instances로 유지합니다. - 장애 허용을 고려해 설계: Cloud Storage에 적절한 replication/inputs를 보장하고, worker를 최대 20% 잃어도 SLA를 충족하도록 클러스터를 사이징합니다. - ephemeral clusters(배치마다 생성, 종료 후 삭제)를 사용해 유휴 시 비용을 지불하지 않도록 합니다. 이는 추가 비용 절감이 되며 주간 처리 패턴과도 부합합니다. 흔한 오해: - “standard workers가 더 안전하다”(Option A)지만, 비용이 핵심 요구사항이며 워크로드가 worker 손실을 명시적으로 허용합니다. - “Compute Engine에서 수동 Hadoop이 더 많은 제어를 준다”(Options C/D)지만, 인프라 관리 노력을 최소화해야 한다는 요구사항을 위반하고 운영 부담(패치, configuration drift, 모니터링, 스케일링)을 증가시킵니다. Exam Tips: “legacy Hadoop/MapReduce를 최소 변경으로”를 보면 기본적으로 Dataproc을 선택하세요. “batch, fault-tolerant, cost-sensitive”를 보면 preemptible/Spot workers를 고려하세요. 또한 아키텍처 원칙을 기억하세요: 운영 오버헤드를 줄이기 위해 managed services를 선호합니다(Google Cloud Architecture Framework: operational excellence 및 cost optimization).

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

6
문제 6

A regional logistics company on Google Cloud needs to process live telemetry from delivery vans (8,000–12,000 events/second with sub-5-second aggregation windows) while also running hourly batch reconciliations of daily manifests; they have no existing analytics codebase and want a fully managed service that supports both batch and streaming with minimal operations overhead. Which technology should they use?

Google Cloud Dataproc은 managed Hadoop/Spark clusters를 제공하며 batch ETL과 기존 Spark streaming jobs에 강점이 있습니다. 하지만 여전히 cluster management(node sizing, upgrades, autoscaling policies)가 필요하고 가장 낮은 ops 선택지는 아닙니다. 기존 analytics codebase가 없는 상황에서 Spark 도입과 클러스터 운영은 Dataflow의 serverless 모델로 streaming windowed aggregations와 batch reconciliations를 모두 처리하는 것보다 부담이 큽니다.

Google Cloud Dataflow가 최적의 선택입니다: Apache Beam을 위한 완전 관리형, serverless 서비스로 하나의 programming model로 streaming과 batch를 모두 지원합니다. event-time windowing, triggers, late data를 네이티브로 처리하므로 초당 8k–12k events에서 sub-5-second aggregations에 이상적입니다. Autoscaling과 managed execution으로 운영 오버헤드를 최소화하며, Pub/Sub, BigQuery, Bigtable, Cloud Storage와 깔끔하게 통합됩니다.

GKE와 Cloud Bigtable을 사용해 custom streaming pipeline(예: Pub/Sub를 consume하고 Bigtable에 쓰는 microservices)을 구축할 수 있습니다. Bigtable은 high-throughput, low-latency key-value access에 뛰어나지만 stream processing engine은 아닙니다. 이 옵션은 운영 복잡도(cluster management, scaling, deployments, observability)를 높이고 windowed aggregation logic을 직접 구현해야 하므로 “fully managed/minimal ops” 요구사항과 충돌합니다.

Compute Engine과 BigQuery 조합은 VM에서 custom processing을 실행하고 결과를 BigQuery에 로드하는 것을 의미합니다. BigQuery는 managed analytics warehouse이며 streaming inserts를 지원하지만, sub-5-second windowed aggregations를 위한 streaming processing engine을 대체하지는 못합니다. Compute Engine을 사용하면 운영 오버헤드(VM management, scaling, fault tolerance)가 크게 증가하며, batch와 streaming pipelines를 통합하는 접근으로는 Dataflow 대비 권장되지 않습니다.

문제 분석

핵심 개념: 이 문제는 운영 오버헤드를 최소화하면서 스트리밍(저지연, 연속)과 배치(예약/주기) 파이프라인을 모두 지원하는 완전 관리형 데이터 처리 서비스를 선택하는지를 평가합니다. Google Cloud에서 정석적인 선택은 Dataflow(Apache Beam managed service)입니다. 정답이 맞는 이유: 회사는 초당 8,000–12,000 events를 ingest하고 5초 미만의 aggregation을 계산해야 합니다. Dataflow는 이를 정확히 위해 설계되었습니다: windowing(tumbling/sliding/session windows), triggers, watermarks를 통해 out-of-order telemetry를 처리하면서 high-throughput streaming을 제공합니다. 또한 동일한 서비스가 동일한 Beam programming model로 hourly batch reconciliation을 실행할 수 있는데, 이는 기존 analytics codebase가 없고 별도 시스템을 유지하기보다 통합된 접근을 원한다는 점에서 중요합니다. 주요 기능 / Best Practices: Dataflow는 serverless이며 autoscaling을 제공해 ops 오버헤드를 줄입니다(클러스터 sizing, patching, capacity planning 불필요). 스트리밍의 경우 Pub/Sub를 ingestion layer로 사용하고, 적절한 triggers(early/on-time/late) 및 allowed lateness와 함께 fixed windows(예: 5 seconds)를 구현합니다. Dataflow Streaming Engine은 stateful/windowed pipelines에서 성능을 개선하고 worker 리소스 사용량을 줄일 수 있습니다. 배치 reconciliation의 경우 Cloud Scheduler/Workflows로 Dataflow batch jobs를 스케줄링하거나 필요 시 Composer로 orchestration할 수 있습니다. 출력은 보통 analytics를 위해 BigQuery, low-latency lookups를 위해 Bigtable, archival을 위해 Cloud Storage로 저장됩니다. 흔한 오해: Dataproc은 “managed”이지만 여전히 운영자가 클러스터를 운영해야 합니다(lifecycle, sizing, upgrades) 그리고 이미 Spark/Hadoop jobs가 있을 때 더 적합합니다. GKE + Bigtable은 streaming architecture를 처리할 수 있지만 운영 부담이 증가하고 custom stream processors를 구축/운영해야 합니다. Compute Engine + BigQuery는 streaming processing service가 아니며, VM에서 custom code를 호스팅하게 되어 ops가 크게 늘어납니다. Exam Tips: “streaming + batch”, “windowing”, “sub-second to seconds latency”, “fully managed/minimal ops”를 보면 Dataflow를 떠올리세요. Dataproc은 lift-and-shift Spark/Hadoop용, GKE는 custom platforms용, Compute Engine은 가장 low-level이며 managed analytics pipelines의 정답으로는 드뭅니다. Google Cloud Architecture Framework 원칙과 정렬하세요: operational excellence(serverless), performance efficiency(autoscaling), reliability(managed service).

7
문제 7

A regional film studio needs to move a one-time 12-TB set of 4K render files from its on-premises NAS into a Google Cloud Storage bucket for archival. The studio has a reliable 1 Gbps internet connection to Google Cloud and a 48-hour maintenance window. They want to minimize total transfer time and cost while following Google-recommended practices. What should they do?

Dataflow는 분산 데이터 처리(ETL/ELT) 및 스트리밍/배치 변환을 위해 설계되었으며, NAS에서의 단순한 대량 파일 마이그레이션에는 적합하지 않습니다. 파일을 읽어 Cloud Storage에 쓰는 파이프라인을 구축하면, 직접 업로드 대비 전송 속도를 개선하지 못하면서도 엔지니어링 노력, 운영 오버헤드, Dataflow 작업 비용이 추가됩니다. 또한 일회성 아카이브 복사에 불필요하게 더 많은 장애 지점을 도입합니다.

Transfer Appliance는 네트워크 전송이 너무 느리거나 신뢰할 수 없거나 허용된 시간 창을 초과할 때(또는 매우 큰 데이터셋을 이동할 때) 가장 적합합니다. 여기서는 1 Gbps에서 48시간 내 12 TB가 온라인으로 달성 가능하므로, appliance를 사용하면 주문, 배송, 적재, 발송, Google ingestion 단계로 인해 종단 간 시간이 오히려 늘어날 가능성이 크고, appliance/배송 비용도 추가됩니다.

상용 파트너 ETL 솔루션은 일회성 파일 업로드에는 불필요하며 일반적으로 비용과 복잡도를 증가시킵니다. ETL 도구는 변환, 메타데이터 보강, 이기종 시스템 간 오케스트레이션, 또는 지속적인 파이프라인이 필요할 때 가치가 있습니다. 렌더 파일을 아카이빙 목적으로 Cloud Storage에 단순 복사하는 경우에는, 네이티브 Google 도구가 비용 효율이 더 높고 관리해야 할 구성 요소도 더 적습니다.

gcloud storage cp를 사용하는 것은 대역폭과 시간이 허용될 때 일회성 업로드에 가장 단순하고 최저비용인 접근입니다. 이는 resumable uploads를 지원하며, 병렬성을 활용해 1 Gbps 연결을 더 잘 활용할 수 있습니다. 이는 Google 권장 운영 관행과도 일치합니다: 커스텀 코드를 최소화하고, 지원되는 툴링을 사용하며, 비용을 통제하면서 유지보수 시간 창 내에 전송을 완료합니다.

문제 분석

핵심 개념: 이 문제는 데이터셋 크기, 사용 가능한 대역폭, 시간 창, 비용을 기준으로 Cloud Storage로의 올바른 데이터 수집(ingestion) 방법을 선택하는지를 평가합니다. 일회성 온라인 전송의 경우, Google 권장 방식은 적용 가능하면 Storage Transfer Service (STS)를 사용하거나, 직접 업로드를 위해 병렬화된 CLI 도구(gcloud storage)를 사용하는 것입니다. 네트워크 전송이 너무 느리거나 비현실적일 때는 Transfer Appliance가 권장됩니다. 정답이 맞는 이유: 신뢰할 수 있는 1 Gbps 링크에서 48시간 내 12 TB 전송은 온라인으로 충분히 가능합니다. 1 Gbps에서의 이론적 처리량은 약 125 MB/s입니다. 48시간 동안의 최대 전송량은 약 21.6 TB(125 MB/s * 172,800 s)이므로, 프로토콜 오버헤드, TLS, 완벽하지 않은 사용률을 감안하더라도 12 TB는 시간 창 내에서 여유 있게 가능합니다. NAS에서 Cloud Storage 버킷으로의 일회성 전송에서는 gcloud storage cp(현대 gcloud storage의 기본 동작으로 병렬 composite uploads가 활성화되어 있고 적절한 병렬성을 설정하는 것이 이상적)를 사용하는 것이 가장 저비용이며, 가장 단순하고, 시작이 가장 빠른 접근입니다. 주요 기능 / 모범 사례: 성능과 단순성을 위해 최신 “gcloud storage” 명령(레거시 gsutil이 아님)을 사용하세요. NAS에 대한 로컬/네트워크 접근이 빠른 머신에서 실행하고, checksum/TLS를 위한 충분한 CPU를 확보하며, 1 Gbps 링크를 포화시키기 위해 병렬성(여러 프로세스/스레드)을 사용하세요. 중단에 대비해 resumable uploads(지원됨)를 고려하세요. checksums로 검증하고, 아카이빙 비용 최적화를 위해 업로드 후 적절한 storage class(예: Archive)와 lifecycle policies 설정을 고려하세요. 흔한 오해: Transfer Appliance는 “빠르다”는 인상을 주지만, 배송 시간, 일정 조율, appliance 비용이 추가되며—네트워크가 SLA를 충족할 수 있다면 불필요합니다. Dataflow/ETL 도구는 변환 파이프라인을 위한 것이지 대량 파일 복사를 위한 것이 아니며, 비용/복잡도를 증가시킵니다. 시험 팁: 항상 대역폭-시간 계산을 하세요. 온라인 전송이 시간 창에 들어오면, 단순한 네이티브 도구(gcloud storage/STS)를 우선하세요. 데이터가 매우 크거나(대개 수십~수백 TB+) 네트워크/시간 제약으로 온라인 전송이 비현실적일 때 Transfer Appliance를 선택하세요. 선택을 Architecture Framework에 매핑하세요: 일회성 마이그레이션에서는 구성 요소를 최소화하여 비용과 운영 우수성(operational excellence)을 최적화합니다.

8
문제 8

Your fintech company runs a payment authorization microservice as a Kubernetes Deployment with 12 replicas in a regional GKE Autopilot cluster in us-central1. During rolling updates (maxUnavailable=0, maxSurge=2), production-only configuration mistakes have intermittently caused 5xx errors at ~1,500 RPS because new Pods begin receiving traffic before the bad settings cause runtime failures. You need a platform-level preventive control so that only healthy Pods receive traffic during the rollout and faulty versions do not trigger outages. What should you do?

정답입니다. Readiness probes는 Pod가 Service의 endpoints에 추가되어 트래픽을 받을 수 있는지를 결정하는 Kubernetes 고유 메커니즘입니다. rolling update 동안 이는 새로 생성된 Pod가 완전히 초기화되고 health validation을 통과할 때까지 요청을 처리하지 못하도록 방지합니다. 이 시나리오에서 readiness probe는 Pod가 사용 가능하다고 간주되기 전에 production 전용 configuration 오류를 감지할 수 있으므로, 결함이 있는 버전으로 인한 5xx 오류를 방지합니다. Liveness probes도 self-healing에 유용할 수 있지만, 여기서 핵심적인 예방 제어는 readiness입니다.

오답입니다. Managed instance group (MIG) health check는 load balancer 뒤의 Compute Engine VM 기반 워크로드에 적용되며, GKE Autopilot cluster의 Kubernetes Pod에는 적용되지 않습니다. GKE에서 Pod health와 트래픽 대상 여부는 Kubernetes readiness/liveness probe와 (선택적으로) load balancer 통합으로 제어되며, MIG health check로 제어되지 않습니다.

오답입니다. 가용성을 확인하는 scheduled task는 사후 대응(reacive) 성격의 외부 메커니즘이며 보통 간격이 큽니다. Rolling update 중 새 Pod가 online 되는 순간에 트래픽을 신뢰성 있게 게이트할 수 없고, Kubernetes endpoint readiness와 통합되어 비정상 Pod를 자동으로 제외하는 기능도 없습니다.

오답입니다. Cloud Monitoring의 uptime alert는 장애를 감지하고 증상이 나타난 뒤 운영자에게 알립니다. 새로 시작된 Pod로 트래픽이 도달하는 것을 막지 못하며, Kubernetes readiness나 rollout 동작에도 영향을 주지 않습니다. Alert는 운영에 중요하지만, 예방적 rollout 제어는 아닙니다.

문제 분석

핵심 개념: 이 문제는 GKE Autopilot에서 Kubernetes rollout 안전성과 Deployment 업데이트 중 정상적인 Pod만 트래픽을 받도록 보장하는 방법을 테스트합니다. 핵심 메커니즘은 readiness probe이며, 이는 Pod가 Service endpoints에 추가되는지 여부와 따라서 요청을 받을 수 있는지를 제어합니다. 정답인 이유: maxUnavailable=0 및 maxSurge=2를 사용하면 Kubernetes는 기존 Pod를 제거하기 전에 새 Pod를 생성합니다. 새 Pod가 너무 일찍 Ready로 표시되면 즉시 production 트래픽을 받아 오류를 일으킬 수 있습니다. 적절하게 설계된 readiness probe는 애플리케이션이 완전히 초기화되었고 요청을 안전하게 처리할 수 있는지 확인하며, 여기에는 configuration 및 dependency 가용성 검증도 포함됩니다. readiness probe가 성공할 때까지 Pod는 Service load balancing에서 제외되므로 rollout 중 결함이 있는 버전이 트래픽을 받는 것을 방지합니다. 주요 기능: - Readiness probe: Pod가 Service를 통해 트래픽을 받아야 하는지 결정합니다. - startupProbe: startup이 느릴 때 유용하며, readiness/liveness checks가 너무 일찍 실패하지 않도록 합니다. - Liveness probe: container가 실행 중일 때 멈추거나 죽은 경우 재시작하는 데 도움이 되지만, 기본적인 트래픽 제어 메커니즘은 아닙니다. - 의미 있는 health endpoint는 단순히 process가 시작되었는지만이 아니라 실제로 요청 처리 준비가 되었는지를 검증해야 합니다. 일반적인 오해: External monitoring, scheduled checks, alerts는 사후 대응 제어입니다. 이들은 영향이 시작된 후 장애를 감지할 수는 있지만, rollout 중 잘못된 Pod로 트래픽이 전달되는 것을 막기 위해 Kubernetes endpoint readiness와 통합되지는 않습니다. 또한 MIG health checks도 GKE에서 Pod readiness를 제어하는 데 사용되는 메커니즘이 아닙니다. 시험 팁: GKE 또는 Kubernetes 문제에서 정상적인 Pod만 트래픽을 받도록 보장하는 방법을 묻는다면, 가장 좋은 답은 readiness probes입니다. 시나리오에 rollout 안전성, endpoint membership, 또는 잘못된 버전이 요청을 처리하지 못하게 하는 내용이 언급되면 먼저 readiness를 떠올리세요. liveness는 재시작 동작을 위한 것이지, 트래픽 제어를 위한 것이 아닙니다.

9
문제 9

You are deploying a telemetry ingestion service in Google Cloud that must privately exchange data with a vendor-managed control system hosted in a third-party colocation facility outside Google Cloud. The average sustained traffic is 300 kbps, with occasional bursts up to 1 Mbps. The business requires 99.99% connectivity availability and emphasizes cost optimization. You need to design private connectivity between the Google Cloud VPC and the external site to meet these requirements. What should you provision?

이것이 최선의 정답인 이유는 HA Cloud VPN이 고가용성을 위해 설계된 Google Cloud VPN 서비스이며, 저대역폭 private connectivity에 대해 비용 최적화된 선택이기 때문입니다. 이는 두 개의 인터페이스를 가진 regional HA gateway를 사용하고 redundant tunnels를 지원하며, Google Cloud 측에서 99.99% 가용성 목표를 충족하기 위한 표준 패턴입니다. 다른 옵션과 비교하면, 올바른 product family를 선택하면서도 옵션 C의 불필요한 추가 gateway와 peer device를 피할 수 있습니다. 자격증 시험에서는 HA Cloud VPN을 사용할 수 있고 트래픽 양이 매우 적다면, 일반적으로 더 복잡하거나 legacy 대안보다 이것이 의도된 정답입니다.

Classic Cloud VPN은 legacy 서비스이며, 요구 사항에서 99.99% connectivity availability를 명시적으로 요구하는 경우 권장되는 설계가 아닙니다. 두 개의 tunnel을 구성하더라도, Classic VPN은 더 높은 가용성 설계 패턴과 관련된 HA gateway 아키텍처를 제공하지 않습니다. 따라서 엄격한 uptime 요구 사항에서는 HA Cloud VPN보다 적합성이 떨어집니다. 그러므로 이 문제의 가용성과 best practice 측면을 모두 충족하지 못합니다.

이 옵션은 필요한 것보다 더 많은 redundancy를 제공하며, 수백 kbps에서 1 Mbps 정도만 필요한 워크로드에 대해 비용 최적화되어 있지 않습니다. Google Cloud에 두 개의 HA Cloud VPN gateway를 배포하고 추가로 두 개의 온프레미스 VPN gateway를 배포하면, 요구 사항이 시사하는 수준을 크게 넘는 복잡성과 비용이 발생합니다. 높은 복원력을 제공할 수는 있지만, 문제는 명시적으로 비용 최적화를 강조하므로 과도하게 구축된 설계는 최선의 정답이 아닙니다. 시험 관점에서 이것은 기술적으로는 강하지만 가장 적절한 솔루션은 아닌 distractor입니다.

단일 Classic Cloud VPN tunnel은 의미 있는 redundancy가 없으며 99.99% 가용성 요구 사항을 충족할 수 없습니다. tunnel, device 또는 path 중 어느 하나라도 장애가 발생하면 해당 단일 경로에서 수동 또는 자동 복구가 일어날 때까지 connectivity가 중단됩니다. 또한 HA Cloud VPN이 아니라 legacy VPN product를 사용합니다. 이는 reliability와 아키텍처 best practice 측면 모두에서 분명히 가장 부적절한 옵션입니다.

문제 분석

핵심 개념: 이 문제는 99.99% 가용성 목표를 충족하면서도 가장 비용 효율적인 private hybrid connectivity 옵션을 선택하는 것에 관한 것입니다. 300 kbps 지속 트래픽과 1 Mbps 버스트처럼 처리량이 매우 낮은 경우, Cloud VPN이 Interconnect보다 훨씬 경제적이며, 높은 가용성이 필요한 경우 HA Cloud VPN이 Google에서 권장하는 옵션입니다. 정답은 HA Cloud VPN 기반 설계입니다. 이는 비용을 의식하면서도 99.99% 가용성 요구 사항에 부합하는 유일한 옵션이기 때문입니다. 흔한 오해는 99.99%를 달성하려면 Google Cloud에 여러 개의 HA Cloud VPN gateway를 배포해야 한다는 것이지만, 이는 불필요한 비용과 복잡성을 추가합니다. 핵심은 Classic VPN이 아니라 HA Cloud VPN을 사용하는 것입니다. 시험 팁: 대역폭 요구가 낮고 가용성 요구가 높다면 Interconnect나 Classic VPN보다 HA Cloud VPN을 우선하고, 명시된 요구 사항을 넘는 과도한 설계를 피하세요.

10
문제 10

A retail analytics team runs a Google Kubernetes Engine (GKE) worker that pulls events from a Pub/Sub pull subscription (orders-events) and writes batch outputs to Cloud Storage; the app was deployed as a single pod and Pub/Sub monitoring shows a backlog of about 12,000 undelivered messages with the 90th percentile wait time at 8 minutes, while each pod processes roughly 6 messages per second when disk throughput is near 80 MB/s, indicating the workload is I/O-intensive; you must scale the processing so the backlog stays under 500 messages and per-message latency remains under 60 seconds without changing the application code; what should you do?

CPU 기반 HPA는 구성하기 쉽지만, I/O 집약적인 Pub/Sub consumer에는 잘못된 제어 신호입니다. disk throughput이 제한 요인이므로 메시지가 쌓이는 동안에도 CPU는 50% 이하로 유지될 수 있어 scale-out이 일어나지 않고 백로그/지연 목표를 위반할 수 있습니다. 또한 이 옵션은 scaling을 SLO(백로그 < 500, 지연 < 60s)와 직접적으로 연결하지 못합니다.

이는 subscription/push_request_latencies를 기준으로 scaling하라고 제안하지만, 워크로드는 pull subscription을 사용합니다. push request latency metrics는 Pub/Sub가 HTTPS endpoint로 push delivery할 때 적용되며, GKE에서 실행되는 pull 기반 consumer에는 해당되지 않습니다. 설령 지연 metric을 사용할 수 있더라도, pull consumer에서는 일반적으로 백로그 depth가 더 안정적이고 실행 가능한 scaling 신호입니다.

cluster autoscaling을 활성화하면 GKE가 pod를 스케줄링할 리소스가 부족해 pod가 pending일 때만 node를 추가/제거할 수 있습니다. 이는 consumer pod의 replica 수를 결정하지 않으므로 Pub/Sub 백로그를 자체적으로 줄이지 못합니다. 워크로드 수요에 따라 pod replica를 늘리려면 여전히 HPA(또는 다른 controller)가 필요합니다.

subscription/num_undelivered_messages를 기준으로 deployment를 scaling하면 백로그를 직접적으로 겨냥하게 되며, 이는 핵심 증상이자 SLO 제약입니다. 백로그가 증가하면 HPA가 replica를 늘려 총 소비 처리량을 높이고, 백로그가 줄어들면 scale down합니다. 이 접근은 애플리케이션 변경 없이 동작하며, CPU가 병목이 아닌 pull 기반 Pub/Sub consumer에 적합합니다.

문제 분석

핵심 개념: 이 문제는 Pub/Sub에서 소비하는 GKE 워크로드에 대한 이벤트 기반 autoscaling과, 애플리케이션 코드를 변경할 수 없을 때 올바른 scaling 신호를 선택하는지를 테스트합니다. 또한 SLO(백로그 < 500, 지연 < 60s)에 맞춰 scaling을 정렬하고, Cloud Monitoring metrics를 사용해 custom/external metrics를 통해 Kubernetes Horizontal Pod Autoscaler (HPA)를 구동하는 내용도 다룹니다. 정답이 맞는 이유: 백로그와 지연을 낮게 유지하려면 CPU가 아니라 수요(대기 중인 메시지 수)를 기준으로 scale해야 합니다. 이 워크로드는 명시적으로 I/O 집약적이며(disk throughput이 80 MB/s 근처), 따라서 CPU utilization은 처리량의 좋은 대리 지표가 아닙니다. Pub/Sub는 subscription/num_undelivered_messages를 제공하는데, 이는 백로그 압력을 직접적으로 나타냅니다. HPA가 이 metric을 기준으로 deployment를 scale하도록 구성하면 백로그가 증가할 때 pod 수를 늘리고, 백로그가 소진되면 줄여서 코드 변경 없이 요구사항을 충족할 수 있습니다. 핵심 기능 / Best Practices: - Cloud Monitoring(Pub/Sub subscription metrics)에서 가져온 external/custom metrics로 HPA를 사용합니다. 실무에서는 HPA가 Cloud Monitoring metrics를 읽을 수 있도록 metrics adapter(예: Google Cloud Managed Service for Prometheus + adapter, 또는 external metrics adapter)로 구현하는 경우가 일반적입니다. - 처리량과 지연 SLO에서 도출한 pod(또는 replica)당 목표 백로그를 선택합니다. 예시 논리: 각 pod가 ~6 msg/s라면, 최악의 대기 시간을 <60s로 유지하기 위해 백로그가 빠르게 소진되도록 충분한 replica가 필요합니다(예: total processing rate >= incoming rate이고 backlog/total_rate <= 60s). 백로그 기반 scaling은 가장 직접적인 제어 루프입니다. - 이는 Google Cloud Architecture Framework(Operational Excellence 및 Performance Optimization)와도 정렬됩니다: 올바른 신호를 측정하고, scaling을 자동화하며, elasticity를 고려해 설계합니다. 흔한 오해: - CPU 기반 autoscaling(옵션 A)은 기본값이고 설정이 쉬워서 유혹적이지만, CPU는 낮게 유지되는 동안 백로그가 증가할 수 있는 I/O-bound consumer에서는 실패합니다. - 지연 metric(옵션 B)은 여기서 오해를 부를 수 있습니다. 해당 옵션은 push_request_latencies를 언급하는데, 이는 push subscription용이며 이 워크로드는 pull subscription을 사용합니다. - Cluster autoscaling(옵션 C)은 pod autoscaling과 다릅니다. 이는 pod가 리소스 부족으로 pending일 때만 node를 추가/제거합니다. 시험 팁: 시스템이 큐/스트림(Pub/Sub, Kafka)에서 소비하고 코드 변경 없이 백로그/지연을 제어해야 한다면, queue depth(num_undelivered_messages) 또는 파생된 “work items per replica” metric으로 autoscaling하는 것을 우선 고려하세요. CPU는 CPU가 병목일 때만 사용합니다. 또한 metric의 적용 범위(push vs pull)를 확인하고, HPA(pods)와 Cluster Autoscaler(nodes)를 구분하세요.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

11
문제 11

Your media streaming company wants to maintain a near–real-time warm standby of its on-premises billing MariaDB cluster in Google Cloud for disaster recovery. The dataset is approximately 4 TB, and change data capture can burst to 800 Mbps during nightly reconciliations (hundreds of GB per hour). The replication engine requires endpoints to communicate over RFC1918 private IP space and must not traverse NAT or public addresses; you also need predictable, low-latency connectivity. Which networking approach should you use?

Dedicated Interconnect는 private하고 non-internet 연결에서 예측 가능한 지연 시간과 높은 처리량이 필요한 경우 가장 적합합니다. NAT 없이 RFC1918 addressing을 지원하고, Cloud Router (BGP)와 함께 VLAN attachments를 사용하며, HA를 위해 중복 구성할 수 있습니다. 이는 복제 엔진의 엄격한 private endpoint 요구 사항과 대규모 초기 sync 및 야간 CDC burst를 위한 대역폭 요구 사항에 부합합니다.

Cloud VPN은 온프레미스 네트워크를 Google Cloud에 안전하게 연결하면서 워크로드 간 private IP 통신을 유지할 수 있지만, tunnel 자체는 public internet을 통과합니다. 즉, Interconnect보다 지연 시간과 jitter의 예측 가능성이 떨어지며, 이는 명시적으로 예측 가능한 low-latency 연결을 요구하는 복제 워크로드에 문제가 됩니다. 일부 경우에는 VPN 처리량이 충분할 수 있지만, 결정론적인 성능이 중요한 지속적인 대용량 복제와 큰 burst window에는 최적의 선택이 아닙니다. 따라서 Dedicated Interconnect만큼 네트워킹 요구 사항을 잘 충족하지 못합니다.

NAT 및 TLS translation gateway는 복제 endpoints가 NAT 또는 public addresses를 통과해서는 안 된다는 명시된 요구 사항과 호환되지 않습니다. 암호화와 translation이 기술적으로 가능하더라도, 이 설계는 복제 엔진이 명시적으로 금지하는 방식으로 addressing 동작을 변경하게 됩니다. 또한 대규모 복제 burst에 대해 불필요한 복잡성, 운영 오버헤드, 잠재적인 bottleneck을 초래합니다. 문제는 private하고 예측 가능한 하이브리드 네트워킹 접근 방식을 요구하므로, 이 선택지는 명백히 부적절합니다.

Compute Engine 인스턴스에서 self-managed VPN server를 운영하는 것은 이러한 유형의 하이브리드 복제 워크로드에 권장되는 엔터프라이즈 연결 패턴이 아닙니다. patching, scaling, failover, monitoring에 대한 운영 부담을 추가하며, 여전히 일반적으로 dedicated private connectivity가 아니라 internet 기반 VPN 동작에 의존합니다. 즉, Dedicated Interconnect와 같은 수준의 예측 가능성, 복원력, 관리형 네트워킹 특성을 제공하지 못합니다. 엄격한 private-path 요구 사항이 있는 대규모 warm standby replication 설계에서는 이 선택지가 관리형 Interconnect 솔루션보다 열등합니다.

문제 분석

핵심 개념: 이 문제는 엄격한 private-IP (RFC1918) 요구 사항, 높은 지속 처리량, 예측 가능한 낮은 지연 시간을 갖는 재해 복구 복제를 위한 하이브리드 연결 설계를 테스트합니다. 핵심 서비스는 Dedicated Interconnect vs Cloud VPN이며, “private, no NAT/public”과 성능 요구 사항이 왜 Interconnect를 가리키는지 이해하는 것입니다. 정답인 이유: Google Cloud Dedicated Interconnect는 VLAN attachments (Cloud Interconnect)를 통해 온프레미스 네트워크와 Google Cloud VPC 사이에 private하고 SLA가 보장되는 Layer 2 연결을 제공합니다. 트래픽은 종단 간 private RFC1918 addressing을 유지하며 public internet을 통과하지 않습니다. 이는 복제 엔진의 제약 조건(no NAT, no public endpoints)을 충족하고, 최대 약 800 Mbps의 burst와 대규모 데이터 이동(초기 4 TB sync 및 야간 CDC spike)에 적합한 예측 가능한 지연 시간과 높은 처리량을 제공합니다. 또한 인터넷 변동성을 줄이고 결정론적인 네트워크 동작을 가능하게 함으로써 DR을 위한 Google Cloud Architecture Framework의 reliability 및 performance 원칙에도 부합합니다. 주요 기능 / 구성 / 모범 사례: - 고가용성을 위해 별도의 edge availability domains/metros에 중복 연결(최소 두 개의 10/100 G 링크)을 갖춘 Dedicated Interconnect를 사용합니다. - 동적 route 교환을 위해 Cloud Router (BGP)에 VLAN attachments를 생성하고, 온프레미스 RFC1918 prefixes와 VPC subnets를 advertise합니다. - reconciliation burst를 위한 충분한 capacity headroom을 확보하고, 여러 VLAN attachments 및 온프레미스의 QoS/traffic engineering을 고려합니다. - warm standby의 경우 GCP 측 regional 설계(예: MySQL-compatible engines용 Cloud SQL 또는 GCE의 self-managed MariaDB)와 함께 사용하고, peak throughput에서 replication lag를 검증합니다. 흔한 오해: Cloud VPN은 private IP를 사용할 수 있지만 public internet을 통해 동작하므로 jitter/variable latency의 영향을 받습니다. 또한 여러 tunnel을 사용하는 HA VPN을 사용하더라도 높은 지속 처리량을 처리하는 데 어려움이 있을 수 있으며, 동일한 수준의 예측 가능성은 제공하지 못합니다. NAT/TLS translation은 “must not traverse NAT/public addresses” 요구 사항을 위반합니다. GCE에서 DIY VPN server를 운영하는 방식은 운영 리스크를 추가하며 권장되는 엔터프라이즈 패턴이 아닙니다. 시험 팁: “predictable low latency,” “high throughput,” “private RFC1918 end-to-end,” 그리고 엔터프라이즈 DR replication이 보이면 기본적으로 Interconnect (Dedicated 또는 Partner)를 떠올리세요. 비용이 가장 중요하고 성능/지연 시간 변동성을 허용할 수 있을 때 VPN을 선택하세요. 요구 사항이 명시적으로 금지하는 경우 NAT/public endpoints를 도입하는 모든 선택지는 제거하세요.

12
문제 12

An aerospace research division must move 12 Windows Server 2022 Datacenter VMs from a classified on-premises lab to Google Cloud within 30 days while reusing existing Microsoft Windows Server licenses covered by active Software Assurance; no Google-provided Windows licensing fees are permitted. Workloads must run in the europe-west4 region with host-level isolation under your control, and each migrated VM must boot from its original OS disk to preserve in-guest agents and local policies. You need a repeatable approach for the first validation VM that keeps licensing compliant and maintains the existing OS state. What should you do?

이 옵션은 raw image를 Google Cloud로 이동하여 원래 운영 체제를 보존해야 한다는 요구 사항을 부분적으로 충족합니다. 그러나 VM을 sole-tenant infrastructure에서 실행한다고 명시하지 않으므로, 고객 제어 하의 host 수준 격리라는 명시적 요구 사항을 충족하지 못합니다. 또한 이 문제에서 Google 제공 Windows license fee가 없는 시나리오에 필요한 dedicated-host 측면도 빠져 있습니다. 추가로, 단순히 disk를 import한다고 말하는 것은 Compute Engine boot 호환성을 위해 image를 준비하는 지원되는 Windows image import workflow를 사용하는 것보다 덜 정확합니다.

이 옵션이 잘못된 이유는 원래 on-premises OS disk를 보존하는 대신 public Windows image에서 새 VM을 생성하기 때문입니다. Compute Engine의 public Windows image는 Google 제공 Windows licensing을 사용하므로, Google 제공 Windows licensing fee가 발생해서는 안 된다는 요구 사항을 직접적으로 위반합니다. 또한 standard Compute Engine instance는 기본적으로 sole-tenant가 아니므로 host 수준 격리 요구 사항도 충족하지 못합니다. 가장 중요한 점은 fresh image에서 배포하면 원래 VM의 기존 in-guest agent, 로컬 정책, 시스템 상태를 보존할 수 없다는 것입니다.

이 옵션은 원래 VM image를 import하지만, 그 후 이를 data disk로만 사용하므로 마이그레이션된 VM이 원래 OS disk에서 부팅해야 한다는 요구 사항을 충족하지 못합니다. instance가 public Windows image에서 생성되기 때문에 여전히 Google 제공 Windows licensing을 사용하게 되며, 따라서 licensing 제약을 위반합니다. 또한 sole-tenant 배치를 명시하지 않으므로 host 수준 격리 요구 사항도 놓치고 있습니다. imported disk를 보조 스토리지로 연결하면 파일은 보존될 수 있지만, 검증에 필요한 원래 실행 중인 운영 체제 환경은 보존하지 못합니다.

이 옵션은 문제의 모든 요구 사항을 충족하는 유일한 선택지입니다. image import 단계는 기존 Windows Server 2022 시스템을 원래 OS 상태를 유지하면서 Google Cloud에서 부팅할 수 있는 형태로 Compute Engine으로 가져옵니다. 여기에는 설치된 agent, 로컬 보안 정책, 머신별 구성도 포함됩니다. VM을 europe-west4에서 sole-tenant instance로 생성하면 고객이 제어하는 전용 host 배치가 제공되며, 이는 host 수준 격리 요구 사항을 직접적으로 충족합니다. 또한 Google에서 제공하는 Windows public image에 의존하지 않으므로, 문제에서 명시적으로 금지한 Google 제공 Windows licensing fee를 피할 수 있습니다. 마지막으로 imported disk를 boot disk로 사용하면 마이그레이션된 VM이 새로 설치된 운영 체제가 아니라 원래 시스템 볼륨에서 시작되도록 보장합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 Windows 라이선스 이동성(BYOL), 원래 OS 디스크 상태를 보존하면서 VM을 마이그레이션하는 요구사항, 그리고 격리 요구사항을 평가합니다. Google Cloud에서는 Software Assurance가 포함된 기존 Windows Server 라이선스를 Bring Your Own License (BYOL)로 재사용하는 것이 Sole-tenant nodes(및 일부 전용 제공 방식)에서만 지원되며, 표준 공유 테넌시 Compute Engine VM에서는 지원되지 않습니다. 정답인 이유: 해당 부서는 (1) Google에서 제공하는 Windows 라이선싱 비용이 없어야 하고, (2) 고객이 제어하는 호스트 수준 격리가 필요하며, (3) europe-west4에 배치되어야 하고, (4) 각 VM이 원래 OS 디스크로 부팅하여 게스트 내 에이전트와 로컬 정책을 보존해야 합니다. 옵션 D는 네 가지를 모두 충족합니다. 지원되는 import 도구(gcloud compute images import에서 올바른 Windows OS 플래그 사용)를 통해 온프레미스 OS 디스크를 Compute Engine image로 가져온 다음, Sole-tenant instance를 생성하고 가져온 디스크를 부팅 디스크로 명시적으로 사용합니다. Sole-tenant nodes는 전용 물리 호스트를 제공하며, 이것이 Google Cloud에서 Windows BYOL을 규정 준수 방식으로 사용하기 위한 핵심 전제조건입니다. 주요 기능 / 구성: - Sole-tenant nodes: 전용 호스트 하드웨어, node affinity, 배치 제어를 제공하며, 규정 준수/격리 요구사항에 부합하고 Windows BYOL을 가능하게 합니다. - Image import 도구: gcloud compute images import(VM import 기반)는 포맷 변환과 Windows 전용 준비/드라이버 주입을 수행하여 가져온 디스크가 Compute Engine에서 안정적으로 부팅되도록 합니다. - 가져온 디스크로 부팅: 공개 image로 재설치하는 것이 아니므로 OS 상태, 설치된 에이전트, 로컬 정책을 보존합니다. - 리전 요구사항: europe-west4에서 node와 VM을 생성합니다. 흔한 오해: 많은 사람이 단순히 디스크를 import하는 것(옵션 A)만으로 충분하다고 생각하지만, Sole-tenant가 없으면 Windows BYOL이 허용되지 않으며 표준 인스턴스에서는 Google Windows 라이선싱 비용이 발생합니다. 옵션 B와 C는 익숙한 공개 image를 사용하므로 매력적으로 보일 수 있지만, 본질적으로 Google 제공 Windows 라이선싱을 사용하게 되며 원래 OS 디스크를 부팅 디스크로 보존하지도 못합니다. 시험 팁: “기존 Windows 라이선스 재사용” + “Google Windows 비용 없음”을 보면 Compute Engine에서는 즉시 “Sole-tenant nodes”를 떠올리세요. “원래 OS 디스크로 부팅해야 함”을 보면 VM import/image import 워크플로를 우선 고려하고, 그 다음 가져온 디스크를 부팅 디스크로 사용하여 VM을 생성하세요(데이터 디스크로 붙이는 것이 아님). 또한 리전 제약과 격리 관련 표현을 확인하세요. 이는 종종 Google Cloud Architecture Framework(보안/컴플라이언스 pillar)에 따른 전용 호스트 및 컴플라이언스 제어를 시사합니다.

13
문제 13

Your media-streaming company deploys a Node.js service to Google Kubernetes Engine (GKE) across dev, staging, and prod using Cloud Build and Artifact Registry. Compliance requires that every production deployment can be traced to the exact Git commit that produced the running container, and that this linkage is auditable via registry and CI/CD records for at least 180 days; what should you do?

date/time으로 commit을 태깅하는 것은 수동이며 추적성을 위한 강력하고 고유한 식별자가 아닙니다. 동일한 시간 구간에 여러 commit이 발생할 수 있고, 태그는 이동되거나 삭제될 수 있으며, Artifact Registry의 실행 중인 컨테이너 이미지가 정확히 어떤 commit인지와 직접적으로 연결되지 않습니다. 또한 CI/CD 시스템 기록을 활용하지 못해 감사가 더 어렵고 신뢰성이 떨어집니다.

commit message에 배포 티켓을 포함하는 것은 프로세스 추적에는 도움이 될 수 있지만, 프로덕션 컨테이너와 정확한 소스 상태 사이의 결정적 연결은 아닙니다. commit message는 불변 컴플라이언스 증거로 강제되지 않으며, Artifact Registry 이미지 메타데이터나 Cloud Build build provenance와 자동으로 연결되지도 않습니다. 이는 보조 메타데이터일 뿐, 1차 추적 메커니즘이 아닙니다.

컨테이너 이미지를 정확한 Git commit SHA로 태깅하면 소스에서 아티팩트로의 직접적이고 고유한 매핑이 제공됩니다. Cloud Build는 commit SHA 태그를 자동으로 적용할 수 있고, Artifact Registry는 태그-대-digest 연관관계를 저장하며, GKE는 불변성을 위해 해당 특정 태그(또는 digest)를 배포할 수 있습니다. log retention/export 및 artifact retention policies와 결합하면 180일 이상에 대한 감사 가능한 체인이 만들어집니다.

latest를 사용하는 것은 프로덕션 컴플라이언스에서 전형적인 anti-pattern입니다. mutable이기 때문입니다: 동일한 태그가 시간에 따라 서로 다른 image digest를 가리킬 수 있습니다. 개발자가 commit을 latest로 태깅하더라도 registry 태그는 덮어쓸 수 있어 감사 추적이 깨지고, 특정 시점에 실행 중인 컨테이너를 어떤 commit이 생성했는지 증명할 수 없게 됩니다. 이는 추적성과 감사 요구사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud의 컨테이너 기반 CI/CD 파이프라인에서 소프트웨어 공급망 추적 가능성(traceability)과 감사 가능성(auditability)을 테스트합니다. 핵심 서비스는 Cloud Build(빌드 provenance 및 로그), Artifact Registry(불변 이미지 참조 및 메타데이터), GKE(특정 image digest/tag 배포)입니다. 이는 보안 및 컴플라이언스 요구사항, 즉 프로덕션에서 정확히 어떤 코드가 실행 중인지 증명하고 정해진 기간 동안 증거를 보관할 수 있어야 한다는 요구와 직접적으로 연결됩니다. 정답이 맞는 이유: 각 빌드된 이미지를 정확한 Git commit SHA로 태깅하면 소스와 런타임 아티팩트 사이에 결정적(deterministic)이고 감사 가능한 링크가 생성됩니다. Cloud Build는 빌드 시점에 commit SHA(예: $COMMIT_SHA)를 이미지 태그에 주입할 수 있고, Artifact Registry는 해당 태그가 어떤 image digest에 연결되는지와 함께 저장합니다. 프로덕션이 그 불변 태그(또는 더 강하게는 image digest)를 배포하면, 감사자는 다음을 추적할 수 있습니다: (1) Kubernetes Deployment manifest가 해당 태그를 참조함, (2) Artifact Registry가 그 태그가 가리키는 digest와 push된 시점을 보여줌, (3) Cloud Build history/logs가 해당 commit에서 트리거된 빌드와 registry로의 push를 보여줌. 이후 180일 동안 이 기록을 보관하는 것은 log retention 및 artifact retention policies의 문제입니다. 핵심 기능 / Best Practices: Cloud Build substitutions($COMMIT_SHA)를 사용해 이미지에 태그(예: app:$COMMIT_SHA)를 붙이고 Artifact Registry로 push합니다. 프로덕션에는 불변 참조를 선호하세요: commit-SHA 태그는 관례상 사실상 불변이며, 최대한 엄격하게 하려면 digest(image@sha256:...)로 배포합니다. 180일 감사 요구사항을 충족하도록 Cloud Logging retention을 구성(또는 로그를 BigQuery/Cloud Storage로 export)합니다. Artifact Registry cleanup/retention policies를 구성해 필요한 기간 동안 이미지와 메타데이터가 계속 사용 가능하도록 보장합니다. 흔한 오해: 팀들은 종종 latest 같은 mutable 태그나 사람이 입력한 메타데이터(티켓, 타임스탬프)에 의존합니다. 이런 방식은 실행 중인 컨테이너에서 소스 commit으로의 암호학적 또는 결정적 매핑을 보장하지 못하고, 덮어쓰기나 위조가 쉬워 컴플라이언스 증거를 약화시킵니다. Exam Tips: 컴플라이언스 추적성 문제에서는 불변 식별자(commit SHA, image digest)와 시스템 기록(CI logs + registry metadata)을 찾으세요. latest 또는 수동 개발자 프로세스가 포함된 답은 피하세요. 또한 retention도 고려해야 합니다. 로그와 아티팩트는 retention 설정 또는 export를 통해 충분히 오래 보관되어야 합니다.

14
문제 14

You operate a healthcare data processing environment on Google Cloud. All Compute Engine VMs run in VPC 'med-analytics-vpc' on subnet 'proc-subnet' (10.24.0.0/20), and an organization policy prohibits any VM from having an external (public) IP. A firewall rule denies ingress tcp:22 from 0.0.0.0/0, and there is no Cloud VPN or Cloud Interconnect to your office network (198.51.100.0/24). You must initiate an SSH session to a specific VM named 'etl-node-03' in us-central1-a for an urgent diagnosis, without assigning any public IPs or opening new inbound internet access. What should you do?

Cloud NAT는 외부 IP가 없는 인스턴스가 인터넷에 도달할 수 있도록 아웃바운드(egress) NAT를 제공합니다. SSH할 수 있는 인바운드 엔드포인트를 만들지 않으며, VM에 도달하기 위해 “Cloud NAT IP로 SSH”할 수도 없습니다. NAT는 reverse proxy나 port forwarder가 아닙니다. 이 옵션은 아웃바운드 연결성과 인바운드 관리 액세스를 혼동한 것입니다.

external TCP Proxy Load Balancer는 퍼블릭 IP를 노출하고 포트 22에서 인바운드 연결을 수락하여, 사실상 새로운 인바운드 인터넷 액세스를 생성합니다. 또한 불필요한 복잡성을 추가하며 SSH에 권장되는 패턴이 아닙니다. 게다가 새로운 인바운드 액세스를 열지 말라는 요구사항과 충돌하고 최소 권한 보안 상태를 약화시킵니다.

IAP TCP forwarding은 외부 IP가 없고 VPN 연결도 없는 VM에 SSH/RDP로 접속해야 하는 정확히 이 시나리오를 위해 설계되었습니다. IAM으로 인증한 다음 gcloud를 사용해 IAP를 통해 터널링합니다. 유일한 네트워크 변경은 35.235.240.0/20에서 VM(태그/서비스 계정 경유)으로 tcp:22를 허용하는 타깃형 방화벽 규칙입니다. 이는 VM의 프라이빗 상태를 유지하고 감사 가능성을 제공합니다.

외부 IP가 있는 bastion host는 새로운 퍼블릭 인그레스 경로를 도입하므로, 새로운 인바운드 인터넷 액세스를 열지 말라는 요구사항을 위반합니다. 또한 조직 정책이 어떤 VM에도 외부 IP를 금지한다면 차단될 수 있습니다. 허용되더라도 bastion은 IAP의 관리형, ID 중심 접근 방식에 비해 운영 오버헤드(패치, 하드닝, 키 관리)를 증가시킵니다.

문제 분석

핵심 개념: 이 문제는 외부 IP가 없고 인바운드 인터넷 노출이 없는 프라이빗 Compute Engine VM에 대한 안전한 관리 액세스를 테스트합니다. 핵심 서비스는 Identity-Aware Proxy (IAP) TCP forwarding (IAP tunneling)으로, Google의 엣지를 통해 VM 포트(예: SSH/22)에 대해 인증되고 권한이 부여된 액세스를 제공하며, 최소 권한 및 zero-trust 원칙에 부합합니다. 정답이 맞는 이유: 조직 정책이 외부 IP를 차단하고 사무실 네트워크에서 VPN/Interconnect가 없으므로 직접 SSH할 수 없습니다. 또한 새로운 인바운드 인터넷 액세스를 열면 안 됩니다. IAP TCP forwarding은 관리자가 gcloud에서 --tunnel-through-iap를 사용해 SSH 세션을 시작할 수 있게 하여 이를 해결합니다. VM은 퍼블릭 IP 없이 유지되며, 연결은 Google 인프라에서 VPC를 통해 VM으로 아웃바운드로 설정됩니다. 필요한 방화벽 변경은 IAP TCP forwarding IP 대역(35.235.240.0/20)에서 대상 VM으로의 tcp:22 인그레스만 허용하는 것입니다(일반적으로 네트워크 태그 또는 서비스 계정 타깃팅을 통해). 액세스는 IAM(IAP-secured Tunnel User)으로 제어되며 감사가 가능합니다. 주요 기능 / 구성: - 프로젝트에 대해 IAP를 활성화(그리고 VM이 필요한 Google APIs에 연결할 수 있도록 보장: 일반적으로 서브넷의 Private Google Access 또는 적절한 egress). - 운영자에게 roles/iap.tunnelResourceAccessor (IAP-secured Tunnel User) 부여. - 좁은 범위의 방화벽 규칙 추가: 35.235.240.0/20에서 VM(태그 지정) 또는 해당 서비스 계정으로 tcp:22 허용. - 사용: gcloud compute ssh etl-node-03 --zone us-central1-a --tunnel-through-iap. 이 접근 방식은 Google Cloud Architecture Framework 보안 가이드에 부합합니다: 노출 최소화, 중앙화된 ID 사용, 감사 가능성 유지. 흔한 오해: - Cloud NAT(옵션 A)는 아웃바운드 인터넷 egress 전용이며, 인바운드 SSH 연결을 수락하지 않습니다. - Load balancer(옵션 B) 및 외부 IP가 있는 bastion host(옵션 D)는 새로운 퍼블릭 진입점을 도입하여, 인바운드 인터넷 액세스를 열지 말라는 요구사항을 위반하고 조직 정책 의도와도 충돌합니다. 시험 팁: “no external IPs”, “no VPN”, “need SSH”를 보면 기본적인 모범 사례 정답은 IAP TCP forwarding입니다. 필요한 방화벽 소스 대역(35.235.240.0/20)과 IAM 역할 요구사항을 기억하세요. 또한 인바운드 액세스 방식(IAP)과 아웃바운드 egress 도구(Cloud NAT)를 구분하세요.

15
문제 15

Your online gaming operations team enabled a trace export from all match servers to push every gameplay event to Google Cloud Storage for later analysis; each event payload is between 50 KB and 15 MB, and traffic can spike to 3,000 events per second during peak tournaments. You need to minimize data loss while sustaining high write throughput; which process should you implement?

매시간 새 bucket을 만드는 것은 운영 부담이 크고 주요 확장 문제를 해결하지 못합니다. serverName-Timestamp 네이밍 패턴은 여전히 hot prefix를 만들 수 있습니다(여러 server가 유사한 구조의 이름을, 종종 시간 순으로, 기록). 이는 쓰기 처리량을 낮출 수 있습니다. metadata를 포함하고 오브젝트별로 compression을 하는 것은 괜찮지만, bucket rotation은 권장되는 성능 전략이 아니며 bucket 관리 오버헤드와 quota 고려사항에 걸릴 수 있습니다.

10,000 events를 하나의 archive로 batching하면 요청 수는 줄지만 blast radius가 커집니다. 업로드가 실패하면 큰 배치를 잃게 되어 “데이터 손실 최소화”와 충돌합니다. 또한 분석을 위한 가용성을 지연시키고 부분 재시도를 복잡하게 만듭니다. 일 단위 bucket rotation은 불필요하며 복잡성만 추가합니다. 이 접근은 오프라인 bulk transfer에는 유용할 수 있지만, 스파이크가 있는 near-real-time ingest 신뢰성에는 이상적이지 않습니다.

serverName-EventSequence는 특히 server별로 순차적 네이밍 패턴을 만들어 쓰기가 hot-spotting될 수 있으며, 스파이크 동안 처리량을 제한합니다. 별도의 metadata 업데이트 호출은 API 작업 수를 2배로 늘리고 2단계 동작을 유발합니다. 업데이트가 실패하면 metadata 없이 오브젝트만 존재할 수 있어 불일치와 운영 부담이 증가합니다. 이 선택지는 높은 QPS에서 실패 지점을 최소화하는 것과 정반대입니다.

Randomized(또는 hashed) prefix는 높은 동시성 하에서 부하를 분산하고 높은 쓰기 처리량을 유지하기 위한 Cloud Storage의 핵심 모범 사례입니다. GCS는 확장되므로 일반적으로 단일 bucket에 모두 유지하는 것으로 충분하며, bucket sprawl을 피할 수 있습니다. metadata를 파일 본문에 포함하면 추가 업데이트 호출을 피할 수 있어 실패 표면적을 줄이고, 스파이크 동안 데이터 손실을 최소화하는 데 도움이 됩니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud Storage (GCS)의 고처리량 ingest 패턴과 오브젝트 네이밍이 쓰기 확장성에 어떤 영향을 미치는지 평가합니다. 또한 다단계 쓰기/업데이트를 피하고 내구적이며 원자적인 오브젝트 업로드를 사용하여 데이터 손실을 최소화하는 점도 다룹니다. 정답이 맞는 이유: 피크 시 3,000 events/sec에 오브젝트 크기가 최대 15 MB이면 매우 높은 요청률입니다. GCS에서 오브젝트 생성은 강한 일관성과 내구성을 제공하지만, 순차적 또는 시간 기반 오브젝트 이름 prefix(예: serverName-Timestamp 또는 serverName-Sequence)로 인해 발생하는 hot-spotting을 피해야 합니다. Hot prefix는 트래픽을 내부 파티션의 일부에 집중시켜 달성 가능한 처리량을 낮출 수 있습니다. 선택지 D는 randomized prefix 패턴을 명시적으로 사용하며, 이는 GCS의 내부 인덱싱/파티셔닝 전반에 부하를 분산하고 높은 write QPS를 유지하기 위한 잘 알려진 모범 사례입니다. 핵심 기능 / 모범 사례: 1) Randomized 오브젝트 이름 prefix: 짧은 random string(또는 hashed prefix)을 이름 앞에 붙여 쓰기를 분산합니다. 2) 단일 bucket이면 충분: 일반적으로 성능을 위해 bucket sharding이 필요하지 않습니다. GCS는 수평 확장합니다. 많은 bucket을 만들면 운영 오버헤드가 증가하고 project/bucket quota에 걸릴 수 있습니다. 3) metadata를 오브젝트 본문에 포함: 오브젝트당 두 번째 API 호출을 피할 수 있습니다(실패 표면적이 커지고 요청량이 2배가 되는 것을 방지). 나중에 검색 가능한 metadata가 필요하면 downstream 처리 중에 추출할 수 있습니다. 4) 오브젝트 단위 compression: 스토리지와 네트워크를 줄이는 데 합리적이지만, match server에서 과도한 CPU latency를 추가하지 않는지 확인해야 합니다. 흔한 오해: A와 B는 주기적으로 새 bucket을 만들어 “확장”하려 하지만, 이는 보통 불필요하며 핵심 병목(오브젝트 이름의 hot prefix)을 해결하지 못한 채 관리 복잡성만 증가시킬 수 있습니다. C는 EventSequence 네이밍을 사용해 매력적으로 보이지만, 그것이 바로 처리량을 제한할 수 있는 순차적 prefix 패턴입니다. 또한 별도의 metadata 업데이트 호출을 추가하여 부분 실패 가능성을 높입니다. 시험 팁: “Cloud Storage에 대한 높은 쓰기 처리량”을 보면 즉시 오브젝트 네이밍을 평가하세요. randomized 또는 hashed prefix를 선호하고 timestamp/sequence prefix는 피하십시오. 또한 데이터 손실과 운영 리스크를 최소화하기 위해 다단계 워크플로보다 단일 단계 업로드를 선호하며, 이는 신뢰성과 운영 우수성을 위한 Google Cloud Architecture Framework 원칙과도 일치합니다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

16
문제 16

A telehealth company runs a consultation-booking application on Google Kubernetes Engine (Autopilot) across two prod clusters in us-central1 and europe-west1, with managed Anthos Service Mesh and Config Sync enabled; over the last 15 minutes (10:00–10:15 UTC), the 95th percentile latency for the /book endpoint increased from 200 ms to 1.3 s while error rate stayed below 0.2% and pod CPU usage remained under 40%; you need to pinpoint which microservice-to-microservice call is introducing the delay without redeploying any workloads. What should you do?

정답입니다. Anthos Service Mesh는 서비스 간 L7 telemetry(P95 latency, request volume, error rates)와 문제 있는 edge를 강조해주는 service graph를 제공합니다. 이는 “어떤 microservice-to-microservice 호출이 지연을 유발하는가”에 직접 답하며, 워크로드를 재배포하지 않고도 즉시 사용할 수 있습니다. 이는 service-mesh-enabled 마이크로서비스 환경에서 latency regression을 격리하는 표준 운영 접근 방식입니다.

오답입니다. Config Sync의 ClusterSelector와 워크로드 필터링은 무엇이 어디에 배포되어 있는지 이해하는 데는 도움이 되지만, 런타임 request-path latency attribution을 제공하지 않습니다. manifest를 검사하면 resource requests/limits나 구성 차이를 볼 수는 있으나, 특정 15분 구간 동안 어떤 inter-service 호출이 느려졌는지는 식별할 수 없습니다. 이는 configuration management이지, 성능 observability가 아닙니다.

오답입니다. NamespaceSelector와 booking namespace의 워크로드 구성을 검토하는 것 역시 정적 구성 점검입니다. /book endpoint의 P95 latency 증가를 유발하는 downstream service hop이 무엇인지 보여주지 못합니다. 문제는 지연을 만드는 microservice-to-microservice 호출을 pinpoint하라고 요구하며, 이를 위해서는 GitOps 구성 뷰가 아니라 런타임 telemetry(service mesh metrics/traces)가 필요합니다.

오답입니다. ASM은 이미 활성화되어 managed 상태이며, 문제에서 워크로드를 재배포하지 말라고 명시했으므로 Anthos Service Mesh 재설치는 불필요합니다. 재설치는 리스크, 잠재적 다운타임, configuration drift를 유발합니다. 또한 latency metrics는 일반적으로 ASM/Cloud Monitoring을 통해 이미 사용 가능하므로, 올바른 조치는 기존 dashboards를 사용해 high-latency edge를 식별하는 것입니다.

문제 분석

핵심 개념: 이 문제는 Anthos Service Mesh(managed Istio)를 사용하는 GKE의 마이크로서비스 아키텍처에서 관측 가능성(observability)과 트러블슈팅을 평가합니다. 특히 워크로드를 재배포하지 않고 서비스 메시 텔레메트리(골든 시그널: latency, traffic, errors, saturation)를 사용해 end-to-end latency 증가를 유발하는 service-to-service hop이 무엇인지 분리해내는 데 초점을 둡니다. 정답이 맞는 이유: Anthos Service Mesh가 이미 활성화되어 managed 상태이므로, 각 pod의 Envoy sidecar(또는 이에 상응하는 managed data plane)가 서비스 간 요청에 대한 L7 metrics를 내보냅니다. /book P95 latency가 200 ms에서 1.3 s로 급증했지만 error rate는 낮고 CPU도 40% 미만이라면, 원인은 compute saturation이 아니라 downstream dependency(예: database call, external API, 또는 특정 internal service)의 지연일 가능성이 큽니다. 문제의 hop을 가장 빠르게 특정하는 방법은 Anthos Service Mesh의 service graph/traffic dashboards를 사용해 edge-level telemetry를 드릴다운하고, 10:00–10:15 UTC 동안 어떤 microservice-to-microservice 호출에서 P95 latency가 상승했는지 확인하는 것입니다. 주요 기능 / 모범 사례: Anthos Service Mesh는 서비스별 및 edge별로 service graph, request volume, error rate, latency metrics를 제공하여 마이크로서비스 전반에서 “blame assignment”가 가능하게 합니다. 이는 Google Cloud Architecture Framework의 “Operational Excellence” 원칙(중앙화된 텔레메트리를 통해 instrument, observe, troubleshoot)을 따르며, 워크로드를 재배포하거나 변경하는 대신 관측 데이터를 활용합니다. 또한 프로덕션에서 위험한 변경을 피하고 기존 managed control plane 기능을 활용합니다. 흔한 오해: Config Sync/Anthos Config Management는 desired-state configuration(GitOps) 및 policy enforcement를 위한 것이지, 런타임 성능 진단을 위한 것이 아닙니다. manifest를 검토해도 최근 15분 동안 어떤 call path가 느렸는지는 알 수 없습니다. Anthos Service Mesh를 재설치하는 것은 불필요하며 제약 조건(재배포 금지)을 위반하고 운영 리스크를 증가시킵니다. 시험 팁: 느린 microservice-to-microservice 호출을 식별하라는 질문이 나오면 “service mesh telemetry/service graph”(또는 언급되어 있다면 distributed tracing)를 떠올리세요. 제약 조건에 “no redeploy”가 포함되면, 구성 변경보다 기존 observability 도구(ASM dashboards, Cloud Monitoring)를 우선하세요. 또한 시그널 패턴도 확인하세요: 높은 latency + 낮은 errors + 낮은 CPU는 종종 downstream dependency latency, network 문제, 또는 앱의 CPU-bound 작업 외부에서의 contention을 의미합니다.

17
문제 17

Your company runs a city-event ticketing API on Compute Engine behind a global HTTP(S) Load Balancer, with containerized NGINX (web) and Node.js (app) tiers each deployed as autoscaled managed instance groups across two zones (europe-west3-a and europe-west3-b), while the database runs on Cloud SQL for MySQL with HA but a fixed machine type (no autoscaling); under a limited beta of 500 authenticated testers the system meets a 99.99% availability SLA at a peak of 120 requests/second, but next month the API will be opened to the public (including unauthenticated requests) with an expected 10x increase to 1,200 requests/second and existing autoscaling policies target 60% CPU on the MIGs; you must design a resiliency testing strategy to validate that the system will maintain the SLA under the additional load without harming real users; what should you do?

정답. 기록된 beta 트래픽을 replay하면 현실적인 endpoint mix, authentication patterns, payload sizes가 보존되어 capacity 결과의 의미가 커집니다. 1,200 RPS로 스케일링하면 설정된 60% CPU target에서의 autoscaling 동작을 검증할 수 있습니다. 전체 zonal outage(drain LB + instances terminate)를 시뮬레이션하면 two-zone MIG 설계의 주요 failure domain을 테스트하고, test environment에서 실행할 경우 실제 사용자에게 영향을 주지 않으면서 남은 zone과 Cloud SQL HA가 SLA를 유지할 수 있음을 확인할 수 있습니다.

최선이 아님. synthetic random requests는 실제 production 동작(hot endpoints, cache hit ratios, DB query patterns)을 반영하지 못하는 경우가 많아 capacity를 과소/과대 추정할 수 있습니다. instances를 무작위로 terminate하는 것은 유용한 chaos engineering이지만, 여기서 가장 중요한 시나리오인 한 zone의 완전 손실과 그로 인한 capacity/latency 영향을 명시적으로 검증하지는 못합니다. 또한 실제 트래픽과 동일한 방식으로 Cloud SQL에 부하를 주지 못할 수도 있습니다.

오답. 실제 사용자에게 피해를 줄 위험이 있어 요구사항을 직접 위반합니다. canary release는 배포 리스크를 완화하는 기법이지, 알려진 10x 트래픽 증가에 대한 1차 resiliency testing 전략이 아닙니다. 실제 사용자 canary 중에 추가로 chaos(리소스 terminate)를 동시에 수행하면 blast radius가 더 커지고, 문제 원인이 부하인지 주입된 장애인지 구분하기 어려워져 SLA가 중요한 공개 런칭에서 바람직하지 않은 운영 방식입니다.

오답. 이는 overprovisioning을 통한 capacity planning이지 resiliency testing이 아닙니다. CPU를 80%까지 올린 뒤 추정 부하의 200%를 미리 프로비저닝하는 것은 장애(zonal outage) 상황에서의 동작을 검증하지 못하고, Cloud SQL(고정 크기, autoscaling 없음)이 10x 트래픽을 처리할 수 있는지도 확인하지 못합니다. 또한 다른 saturation 지점(connections, IOPS, memory, LB/backend limits)을 무시하며, SLA를 입증하지 못한 채 불필요하게 비용이 커질 수 있습니다.

문제 분석

핵심 개념: 이 문제는 global HTTP(S) Load Balancer 뒤에 있는 multi-tier, zonally distributed Compute Engine 아키텍처(autoscaled managed instance groups(MIGs) 및 autoscale되지 않는 stateful backend(Cloud SQL for MySQL HA))에 대해 resiliency와 load testing을 평가합니다. 이는 Google Cloud Architecture Framework의 “Reliability” 및 “Operational Excellence” pillar에 부합합니다. 즉, 실제 사용자에게 영향을 주지 않으면서 예상 부하 및 장애 상황에서의 동작을 검증하는 것입니다. 정답이 맞는 이유: 옵션 A가 최선의 전략인 이유는 대표성 있는 트래픽(기록된 beta 트래픽)을 사용해 예상되는 10x RPS로 스케일링하고, 여기에 통제된 현실적 장애 모드(전체 zone 손실)를 결합하기 때문입니다. 이는 (1) 60% CPU 기준의 autoscaling policy가 1,200 RPS에서 충분히 빠르게 반응하는지, (2) global load balancer와 MIGs가 한 zone이 불가용일 때도 서비스를 유지할 수 있는지, (3) 시스템의 실제 병목(대개 Cloud SQL)이 scale-out 및 zonal failover 동안에도 용량 한도 내에 머무는지를 직접 검증합니다. 또한, 이는 전용 test environment(또는 shadow testing)에서 실행할 수 있어 실제 사용자에게 피해를 주지 않습니다. 주요 기능 / 모범 사례: - 무작위 synthetic 트래픽이 아니라 실제 요청 믹스(endpoints, auth patterns, cacheability, payload sizes)를 기반으로 한 traffic replay를 사용합니다. - zonal resilience를 검증합니다: 한 zone의 backends를 drain/disable하고 instances를 terminate하여 실제 outage를 시뮬레이션하며, 남은 zone에서 health checks, connection draining, capacity를 확인합니다. - end-to-end SLO를 관측합니다: latency, error rate, saturation(CPU, memory, connection pools) 및 Cloud SQL metrics(CPU, IOPS, connections, replication/failover behavior). Cloud SQL HA는 failover를 제공하지만 horizontal scaling은 제공하지 않으므로, 10x 부하를 처리할 수 있는지 확인해야 합니다. - 테스트를 안전하게 수행합니다: 별도 project/VPC로 격리하거나 mirrored environment를 사용하고, quotas(MIG size, load balancer limits, Cloud SQL connections)가 충분한지 확인합니다. 흔한 오해: instance 수준의 chaos testing(B)은 유용할 수 있지만, 가장 중요한 failure domain(zone 손실)을 검증하지 못할 수 있고 무작위 트래픽은 중요한 hot paths를 놓칠 수 있습니다. 실제 사용자에게 canary를 적용(C)하는 것은 실제 사용자에게 피해를 주지 말라는 요구사항을 위반합니다. overprovisioning(D)은 resiliency test가 아니며 failover 동작과 database 제약을 무시합니다. 시험 팁: (1) production-like 트래픽을 사용하고, (2) 현실적인 failure domain(zone/region)을 테스트하며, (3) autoscaling과 stateful dependency를 검증하고, (4) 격리된 환경 또는 통제된 shadow test에서 실행해 사용자를 보호하는 전략을 우선하세요. 99.99% 목표의 경우 평균 CPU만 보지 말고 zonal failure와 capacity headroom을 명시적으로 테스트하세요.

18
문제 18

A genomics research institute needs to import 82 TB of raw sequencing data from its on-premises NAS into Google Cloud within 30 days. Their internet link averages 500 Mbps during off-peak hours and must remain available for other workloads. They will store the data in Cloud Storage and want to follow Google-recommended, secure, and predictable migration practices. What should they do?

정답입니다. Transfer Appliance는 WAN 대역폭이 제한된 상황에서 대규모, 기한이 있는 전송에 대해 Google이 권장하는 솔루션입니다. 데이터를 로컬로 복사한 뒤 어플라이언스를 배송하고, 지원되는 Transfer Appliance rehydration 프로세스를 사용해 복호화하여 대상 Cloud Storage bucket에 기록합니다. 이를 통해 완료 시점을 예측 가능하게 하고, 온프레미스 인터넷 링크를 다른 워크로드에 계속 사용할 수 있게 하며, 안전한 처리 및 암호화 모범 사례를 따릅니다.

오답입니다. Cloud Dataprep은 데이터 준비/ETL 도구(정제, 프로파일링, 변환)이며 Transfer Appliance 페이로드를 복호화하거나 Cloud Storage로 인제스트하는 지원 메커니즘이 아닙니다. Transfer Appliance에는 안전한 복호화 및 업로드를 위한 특정 rehydration 워크플로/도구가 있습니다. 여기서 Dataprep을 사용하는 것은 범주 오류이며 Google 권장 마이그레이션 모범 사례와도 맞지 않습니다.

오답입니다. resumable 및 병렬 업로드를 사용하는 gsutil은 WAN 기반 전송에 적합하지만, 제약 조건 때문에 예측이 어렵습니다. 링크는 오프피크에만 평균 500 Mbps이며 다른 워크로드를 위해 계속 사용 가능해야 합니다. 실제 처리량은 이론치보다 훨씬 낮을 가능성이 크고, 경합/재시도로 30일 마감이 위태로워질 수 있습니다. 또한 오프라인 어플라이언스 대비 운영 복잡성과 리스크가 증가합니다.

오답입니다. 대용량 전송에서는 streaming uploads가 resumable uploads보다 일반적으로 복원력이 낮습니다. 중단이 발생하면 재시작이 필요해 실패 위험이 커질 수 있습니다. 제한되고 공유되는 대역폭과 큰 데이터셋에서는 streaming이 가장 예측 불가능한 선택지입니다. 설령 동작하더라도 WAN 용량을 계속 소모하여 다른 워크로드에 영향을 줄 수 있고, 안전하고 예측 가능한 마이그레이션 관행 요구사항과도 충돌합니다.

문제 분석

핵심 개념: 이 문제는 대역폭이 제한되고 일정이 고정된 상황에서 Cloud Storage로 데이터를 마이그레이션하는 올바른 접근 방식을 선택하는지를 평가합니다. 핵심 서비스는 Transfer Appliance(오프라인 대용량 전송)와 Cloud Storage 인제스천 모범 사례입니다. 정답이 맞는 이유: 500 Mbps 링크로 82 TB를 30일 내에 전송하는 것은 위험하며, 특히 해당 링크가 다른 워크로드를 위해 계속 사용 가능해야 하기 때문입니다. 500 Mbps를 24/7로 완전히 전용한다고 해도 이론상 30일 동안 약 162 TB 전송이 가능합니다(500/8=62.5 MB/s; 하루 약 5.4 TB). 하지만 실제로는 프로토콜 오버헤드, 경합, 재시도, 제한된 오프피크 시간대 등으로 처리량이 크게 감소하여 일정 예측이 어렵습니다. WAN 용량이 제한된 대규모, 기한이 있는 마이그레이션에 대해 Google이 권장하는 방식은 Transfer Appliance입니다. 데이터를 로컬에서 어플라이언스에 복사한 뒤 Google로 배송하고, Google이 대상 Cloud Storage bucket으로 업로드합니다. Transfer Appliance Rehydrator는 Google Cloud에서 데이터를 복호화/rehydrate하여 Cloud Storage에 기록하는 지원되는 메커니즘으로, 안전한 custody 체인과 예측 가능한 완료를 제공합니다. 핵심 기능 / 모범 사례: - 예측 가능성: 배송 방식은 WAN 변동성을 회피하고 비즈니스 핵심 대역폭을 보호합니다. - 보안: Transfer Appliance는 암호화를 사용하며, 키는 고객이 관리하고 rehydration은 Google이 통제하는 시설/워크플로에서 수행됩니다. - 운영 적합성: NAS/파일 기반 소스와 Cloud Storage로의 대량 object 인제스천에 맞게 설계되었습니다. - Architecture Framework 정렬: 신뢰성(30일 목표 달성), 보안(암호화된 운송 및 통제된 처리), 비용 최적화(장기간 WAN 포화 및 운영상 소방 대응 회피). 흔한 오해: - “gsutil 병렬 업로드면 충분하다”: 병렬성은 도움이 되지만 제한된 가용 대역폭과 오프피크 전용 제약을 극복할 수는 없습니다. 또한 운영 리스크(스로틀링, 재시도, 공유 링크에서의 noisy-neighbor 영향)를 증가시킵니다. - “어떤 도구든 복호화할 수 있다”: 복호화/rehydration은 Dataprep 사용 사례가 아닙니다. Dataprep은 데이터 정제/ETL용이며 Transfer Appliance 인제스천을 위한 것이 아닙니다. 시험 팁: 수십 TB 규모, 엄격한 마감, 제한/공유 인터넷이 보이면 오프라인 전송(Transfer Appliance)을 기본으로 고려하세요. Cloud Storage로의 공식 rehydration 워크플로를 언급하는 선택지를 고르세요. 대역폭이 충분하고 예측 가능하거나 증분/지속 동기화가 필요할 때는 WAN 도구(Storage Transfer Service, gsutil)를 사용합니다.

19
문제 19

All Compute Engine instances in your project must be able to connect only to an internal code repository at 10.30.40.50 over TCP ports 22 and 443; any other outbound traffic from these instances must be blocked. You will enforce this using VPC firewall rules. How should you configure the firewall rules?

정답입니다. allow rule은 priority 100(먼저 평가됨)으로 TCP 22/443을 10.30.40.50으로 허용합니다. deny-all rule은 priority 1000(이후 평가됨)으로 다른 모든 destination(0.0.0.0/0)을 차단합니다. 이는 VPC firewall 처리 방식(첫 매칭 우선, 숫자가 낮은 priority가 우선)을 따릅니다. 이를 통해 최소 권한 outbound access를 강제합니다.

오답입니다. priority 100의 deny-all rule이 priority 1000의 allow rule보다 먼저 평가됩니다. deny rule은 모든 destination(0.0.0.0/0)과 매칭되므로 10.30.40.50으로 가는 트래픽도 함께 deny되고, 평가가 중단됩니다. 이후 allow rule은 적용되지 않아 outbound access가 전혀 되지 않습니다.

오답입니다. implied deny egress rule이 존재한다고 가정합니다. Google Cloud VPC에서 implied egress rule은 deny가 아니라 0.0.0.0/0에 대한 allow입니다. 10.30.40.50에 대한 allow rule만 추가하면, 다른 모든 egress 트래픽은 implied egress allow rule에 의해 여전히 허용되어 다른 모든 outbound traffic을 차단해야 한다는 요구사항을 위반합니다.

C와 같은 이유로 오답입니다: implied deny egress rule에 의존하지만, implied egress는 allow-all입니다. allow rule priority가 100이더라도, 명시적인 deny-all egress rule이 없으면 기본 implied egress allow 때문에 인스턴스는 다른 어떤 destination으로도 트래픽을 보낼 수 있습니다. 여기서 priority 숫자는 누락된 명시적 deny를 해결해주지 못합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 VPC firewall egress 제어를 테스트합니다: rule 평가 순서(priority), allow vs deny 동작, 그리고 implied rule의 존재 여부입니다. 또한 Google Cloud Architecture Framework(Design for Security)의 최소 권한(least privilege) 보안 원칙도 다룹니다. 정답이 맞는 이유: 인스턴스가 TCP 22 및 443으로 10.30.40.50에만 접근하고 그 외에는 아무 곳에도 나가지 못하게 하려면 (1) 필요한 destination/port를 명시적으로 allow 하고 (2) 다른 모든 egress를 명시적으로 deny 해야 합니다. VPC firewall rule에서는 숫자가 더 낮은 priority가 먼저 평가됩니다. 패킷이 어떤 rule과 매칭되면 해당 action(allow/deny)이 적용되고 평가가 중단됩니다. 따라서 destination 10.30.40.50에 대해 TCP:22,443을 허용하는 더 높은 우선순위의 allow rule(priority 100)을 만들고, 그 다음 destination 0.0.0.0/0에 대한 더 낮은 우선순위의 deny-all rule(priority 1000)을 만듭니다. 이렇게 하면 예외 트래픽은 허용하면서 나머지는 모두 차단됩니다. 주요 기능 / 구성: - EGRESS 방향 rule을 사용합니다. - 광범위한 target( target tag 없음)으로 “all instances”에 적용하거나, 의도치 않은 workload에 영향을 주지 않도록 best practice로 전용 service account 또는 network tag를 사용합니다. - Allow rule: destination 10.30.40.50/32, protocol tcp, ports 22 및 443. - Deny rule: destination 0.0.0.0/0, 모든 protocol(또는 필요에 따라 최소한 tcp/udp/icmp), action deny. - implied rule이 존재하지만, 의도와 맞지 않을 수 있으므로(특히 implied egress는 allow) 이를 신뢰하는 것은 위험하다는 점을 기억합니다. 흔한 오해: 많은 사람이 implied “deny egress” rule이 있다고 가정합니다. Google Cloud VPC에서 implied egress rule은 allow(0.0.0.0/0)입니다. 따라서 “implied deny egress에 의존”하는 선택지는 틀립니다. 또 다른 흔한 실수는 priority를 반대로 두는 것입니다. deny를 allow보다 더 높은 우선순위로 두면 의도한 트래픽까지 차단됩니다. 시험 팁: - 암기: 숫자가 낮을수록 = priority가 높음. - implied rule: ingress deny-all; egress allow-all. - “X만 허용하고 나머지는 전부 차단”하려면 거의 항상 두 개의 명시적 egress rule이 필요합니다: 더 높은 우선순위의 allow 예외 rule과 더 낮은 우선순위의 deny-all. - 운영 안전성을 고려: service account/tag로 rule 범위를 제한하고, 향후 rule 충돌을 방지하기 위해 priority를 문서화합니다.

20
문제 20

You are leading the migration of a digital media platform to Google Cloud, and a major pain point is the on-premises scale-out NAS that requires frequent and costly upgrades to handle diverse workloads identified as follows: 18 TB of audit video fragments that must be retained for 7 years for compliance; 600 GB of VM images and golden templates used for occasional rebuilds; 700 GB of photo preview thumbnails served to end users; and 250 GB of user playlist/cart session state that must persist so users can resume activity even after being offline for up to 5 days. Which of the following best reflects your recommendations for a cost-effective storage allocation?

Local SSD는 ephemeral이며 VM stop/terminate 이벤트, 호스트 유지보수, 또는 인스턴스 재생성 시 데이터가 손실됩니다. 이는 사용자 세션 상태가 최대 5일 동안 유지되어야 한다는 요구사항을 직접 위반합니다. 감사 아카이브, 썸네일, VM images/templates에 대한 Cloud Storage 권고는 방향성(object storage + lifecycle) 측면에서 맞지만, 세션 상태 선택 때문에 이 옵션은 신뢰성과 내구성 측면에서 오답입니다.

이는 흔한 확장형 패턴과 일치합니다. Memorystore for Memcached는 활성 세션에 대해 low-latency 접근을 제공하고, Firestore (Datastore mode)는 내구성 있는 persistence를 제공하여 사용자가 며칠 동안 오프라인이었다가도 재개할 수 있게 합니다. Firestore는 수평 확장이 가능하며 TTL policies로 약 5일 후 세션 엔터티를 만료(expire)시킬 수 있습니다. lifecycle/retention policies가 있는 Cloud Storage는 7년 감사 아카이브와 가끔 사용하는 VM templates에 비용 효율적이며, 썸네일에도 잘 맞습니다(종종 Cloud CDN과 함께 사용).

Cloud SQL은 세션 상태를 영속화할 수 있지만, 일반적으로 탄력성이 떨어지고 connection limits 및 수직 확장 특성 때문에(풀링/샤딩을 신중히 설계하지 않으면) 고처리량 세션 워크로드에서 병목이 될 수 있습니다. 또한 VM boot/data volumes를 위해 local SSD–backed 인스턴스를 이것저것 사용하는 것은 golden images/templates에 대해 비용 효율적이지도 운영적으로도 바람직하지 않습니다. 그런 것들은 특정 인스턴스에 묶기보다 images/snapshots 또는 Cloud Storage에 저장해야 합니다.

Persistent Disk SSD는 내구성이 있지만, 이를 세션 상태의 backing store로 사용하는 것은 anti-pattern입니다. 상태를 VM 인스턴스에 결합(couple)시켜 스케일링을 복잡하게 만들고, 5일 오프라인 윈도우에 필요한 native TTL/expiration semantics가 없습니다. 또한 managed database에 비해 운영 오버헤드가 증가합니다. 옵션 C와 마찬가지로 VM boot/data volumes를 위해 local SSD–backed 인스턴스를 사용하는 것은 golden templates에 적절한 접근이 아니며, 대신 images/snapshots 또는 Cloud Storage를 사용해야 합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 스토리지 티어링과 상태 관리에 대한 이해를 평가합니다. 대용량의 내구성 있는 객체(아카이브, 이미지, 썸네일)에는 Cloud Storage lifecycle 정책을 사용하고, 캐시 손실 및 사용자 오프라인 기간에도 유지되어야 하는 세션/상태에는 database-backed 패턴을 사용하는 것이 핵심입니다. 정답이 맞는 이유: 감사(audit) 비디오 조각(18 TB, 7년 보관)은 전형적인 object storage + lifecycle/retention 사용 사례입니다. Cloud Storage는 retention policies(WORM 스타일 거버넌스)와 lifecycle rules를 지원하여 장기 보관 시 Nearline/Coldline/Archive 같은 더 차가운 클래스(colder classes)로 전환해 비용을 최소화할 수 있습니다. VM images/templates(600 GB)도 가끔 접근하는 워크로드이므로 Cloud Storage(또는 Google-managed storage에 저장되는 Compute Engine Images)에 적합하며, colder classes로 비용을 줄일 수 있습니다. 사진 썸네일(700 GB)은 최종 사용자에게 자주 제공되므로 Cloud Storage Standard에 두고 앞단에 Cloud CDN을 붙이면 성능과 비용 효율이 좋습니다. 사용자 playlist/cart 세션 상태(250 GB)는 사용자가 오프라인이어도 최대 5일 동안 유지되어야 하므로 “cache-only” 요구사항이 아닙니다. 일반적인 패턴은 저지연 읽기/쓰기를 위한 Memorystore (Memcached)와 내구성 있는 backing store를 함께 사용하는 것입니다. Firestore (Datastore mode)는 관리형, 고가용성, 수평 확장 가능한 영속 저장소를 제공하며 TTL policies로 약 5일 후 세션 엔터티를 만료(expire)시킬 수 있어 운영 오버헤드와 확장 한계를 줄입니다. 주요 기능 / 모범 사례: - Cloud Storage: lifecycle rules + storage classes; 컴플라이언스를 위한 retention policies; 선택적으로 Object Versioning; 접근에 대한 Cloud Audit Logs. - 썸네일: Cloud Storage + Cloud CDN; 필요 시 signed URLs 고려. - 세션 상태: 속도를 위한 Memorystore for Memcached; 내구성, 자동 확장, TTL 기반 정리를 위한 Firestore (Datastore mode). - Architecture Framework 정렬: 비용 최적화(tiering), 신뢰성(durable backing store), 운영 우수성(managed services). 흔한 오해: Local SSD는 빠르지만 ephemeral이며, 인스턴스가 재시작/종료되면 “최대 5일 유지” 요구사항을 충족하지 못합니다. Persistent Disk SSD는 내구성이 있지만 세션 상태를 VM 디스크에 묶는 것은 확장 가능한 웹 상태 관리 관점에서 anti-pattern입니다. 관리 복잡도가 증가하고 자연스러운 TTL/만료 모델도 제공하지 않습니다. Cloud SQL도 세션을 저장할 수는 있지만, relational scaling/connection 관리 제약이 있고 고처리량 key-value 접근에는 비용이 더 들거나 탄력성이 떨어질 수 있습니다. 시험 팁: 각 데이터셋을 access pattern + durability + retention에 매핑하세요. 장기 컴플라이언스 아카이브는 Cloud Storage + retention/lifecycle를 떠올리세요. 자주 제공되는 정적 콘텐츠는 Cloud Storage Standard + CDN을 떠올리세요. 캐시 손실에도 살아남아야 하는 session/state는 항상 캐시 뒤에 내구성 있는 managed database(Firestore/Spanner/Cloud SQL)를 선택하고, persistence 요구사항에 Local SSD를 쓰는 것은 피하세요.

합격 후기(10)

E
E**********Nov 21, 2025

학습 기간: 1 month

Many of the scenario patterns I saw on Cloud Pass showed up in the actual PCA exam. The explanations were detailed, which helped strengthen my weak areas. I’ll definitely use this app again for other GCP exams.

김
김**Nov 19, 2025

학습 기간: 1 month

실제 시험 문제하고 유사했던게 15개 이상 나온거 같아요! 굿굿

박
박**Nov 17, 2025

학습 기간: 1 month

앱 너무 좋네요

D
D***********Nov 15, 2025

학습 기간: 2 weeks

These questions forced me to deeply understand GCP networking, IAM, storage trade-offs, and high-availability design. After a month of consistent practice, I finally passed my PCA exam. Amazing app!

M
M*********Nov 8, 2025

학습 기간: 1 month

I passed on the first try. The practice questions were tough but very close to the real exam. The explanations helped me understand why each answer was correct. Highly recommended.

모의고사

Practice Test #1

50 문제·120분·합격 700/1000

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Google Associate Cloud Engineer

Associate

Google Professional Cloud Network Engineer

Google Professional Cloud Network Engineer

Professional

Google Associate Data Practitioner

Google Associate Data Practitioner

Associate

Google Cloud Digital Leader

Google Cloud Digital Leader

Foundational

Google Professional Cloud Security Engineer

Google Professional Cloud Security Engineer

Professional

Google Professional Cloud Database Engineer

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Google Professional Cloud Developer

Professional

Google Professional Machine Learning Engineer

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

Cloud Pass를 다운로드하여 모든 Google Professional Cloud Architect 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

이동 중에도 모든 문제를 풀고 싶으신가요?

앱 받기

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.