실전 문제

문제 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?

문제 분석

핵심 개념: 이 문제는 쿼리 패턴에 따라 올바른 데이터베이스 모델을 선택하는지를 평가합니다. 핵심 요구사항은 “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

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?

문제 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?

문제 분석

핵심 개념: 이 문제는 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

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?

문제 분석

핵심 개념: 이 문제는 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

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?

문제 분석

핵심 개념: 이 문제는 배치 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

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에서 정석적인 선택은 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

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?

문제 분석

핵심 개념: 이 문제는 데이터셋 크기, 사용 가능한 대역폭, 시간 창, 비용을 기준으로 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

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?

문제 분석

핵심 개념: 이 문제는 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

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?

문제 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?

문제 분석

핵심 개념: 이 문제는 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)를 구분하세요.

문제 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?

문제 분석

핵심 개념: 이 문제는 엄격한 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

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?

문제 분석

핵심 개념: 이 문제는 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

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?

문제 분석

핵심 개념: 이 문제는 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

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?

문제 분석

핵심 개념: 이 문제는 외부 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

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?

문제 분석

핵심 개념: 이 문제는 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 원칙과도 일치합니다.

문제 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(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

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?

문제 분석

핵심 개념: 이 문제는 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

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?

문제 분석

핵심 개념: 이 문제는 대역폭이 제한되고 일정이 고정된 상황에서 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

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?

문제 분석

핵심 개념: 이 문제는 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

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?

문제 분석

핵심 개념: 이 문제는 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를 쓰는 것은 피하세요.