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

GCP

Google Professional Cloud Developer

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

시험 도메인

Designing Highly Scalable, Available, and Reliable Cloud-Native Applications출제율 36%
Building and Testing Applications출제율 22%
Deploying Applications출제율 22%
Integrating Google Cloud Services출제율 20%

실전 문제

1
문제 1

Company overview: SkyLend is a peer‑to‑peer micro‑lending platform expanding from one country to global regions (us-central1, europe-west1, asia-southeast1) and targeting a 10x increase in concurrent users (from 5,000 to 50,000) while reducing operational overhead; technical requirement: the public /loan and /payment APIs must meet 99.9% monthly availability and 95th percentile latency under 250 ms per region, teams must define SLIs and SLOs, track error budgets, visualize SLO health, and receive burn‑rate alerts (2x over 1 hour and 5x over 5 minutes) without building custom tooling; compliance and exec reporting require auditable SLO dashboards across services and regions. Question: Which Google Cloud product best meets SkyLend’s need to define, monitor, and alert on service level indicators and objectives (including error budgets and burn‑rate alerts) across regions?

Cloud Profiler는 실행 중인 애플리케이션에서 CPU hot spot, memory allocation issue, expensive function 식별과 같은 지속적인 code-level performance analysis를 위해 설계되었습니다. 따라서 latency 또는 cost 문제가 감지된 이후 최적화 작업에는 유용하지만, first-class SLO object 또는 service-level compliance tracking을 제공하지는 않습니다. rolling period 동안 서비스가 99.9% availability target을 충족하는지 여부를 나타내거나 error budget을 계산할 수 없습니다. 또한 리전 전반에서 표준화된 SLO burn-rate alert 또는 executive SLO dashboard를 생성하는 데 사용되는 도구도 아닙니다.

Cloud Monitoring이 정답인 이유는 서비스 정의, SLI 연결, 그리고 rolling compliance period 전반에 걸친 SLO 관리를 위한 Google Cloud의 네이티브 제품이기 때문입니다. 내장 또는 custom metrics에서 파생된 request-based 또는 windows-based SLI를 사용하여 availability 및 latency 중심 목표를 평가할 수 있으므로, 여러 리전의 user-facing API를 모니터링해야 하는 요구 사항에 적합합니다. 또한 Cloud Monitoring은 error budget consumption을 자동으로 계산하고 시각화하므로, 팀은 reliability target 내에서 운영되고 있는지 추적할 수 있습니다. 추가로, 서로 다른 time window에 대한 burn-rate alert와 같은 SLO 기반 alerting pattern을 지원하며, dashboard는 engineering, compliance, executive stakeholder를 위한 중앙 집중식이고 감사 가능한 가시성을 제공합니다.

Cloud Trace는 분산 request trace를 수집하고 분석하여 개발자가 서비스와 dependency 전반에서 latency가 어디서 발생하는지 이해할 수 있도록 하는 데 사용됩니다. 느린 /loan 또는 /payment request를 troubleshooting하는 데는 유용하지만, service-level objective를 정의하거나 SLO target 대비 compliance를 계산하지는 않습니다. Trace data는 SLO가 왜 충족되지 않는지 설명하는 데 도움이 될 수 있지만, SLO 자체와 해당 error budget은 다른 곳에서 관리됩니다. 또한 서비스와 리전 전반에서 burn-rate alerting 및 감사 가능한 SLO reporting을 위한 기본 제품 역할도 하지 않습니다.

Cloud Logging은 애플리케이션과 인프라에서 생성된 log를 수집, 저장, 쿼리, 라우팅하는 데 중점을 둡니다. log는 Monitoring에 입력되는 log-based metric을 생성하는 데 사용될 수 있지만, Logging 자체는 네이티브 SLO entity, error budget calculation, 또는 SLO health dashboard를 제공하지 않습니다. 팀은 log를 입력 신호로 사용할 수는 있지만, 여전히 SLO를 정의하고 평가하기 위해 Cloud Monitoring에 의존해야 합니다. 따라서 Logging만으로는 custom tooling 없이 내장된 SLI/SLO 관리와 burn-rate alerting 요구 사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 커스텀 툴링 없이 SLI/SLO를 정의하고 운영하며, error budget을 추적하고, burn-rate alert를 생성하기 위한 Google Cloud의 내장 Site Reliability Engineering (SRE) 기능을 테스트합니다. Google Cloud에서는 이러한 기능이 Cloud Monitoring의 SLO Monitoring (Google Cloud Observability의 일부)을 통해 제공됩니다. 정답이 맞는 이유: Cloud Monitoring은 팀이 서비스(멀티 리전 서비스 포함)에 대한 service level objectives를 정의하고, rolling window에서 SLI 준수 여부를 자동으로 계산하며, error budget 소비를 추적하고, burn-rate alerting policy(예: “1시간 동안 2x”, “5분 동안 5x”)를 생성할 수 있게 해주는 제품입니다. 또한 Monitoring dashboards를 통한 감사 가능한 대시보드와 리포팅, 그리고 Cloud Logging/Trace metrics와의 통합을 지원하여, 서비스와 리전 전반에 걸친 임원/컴플라이언스 가시성 요구사항을 충족합니다. 주요 기능 / 요구사항 충족 방식: 1) SLOs 및 SLIs: 요청 기반 metric(예: load balancers, Cloud Run, GKE, 또는 custom metrics에서)으로 availability 및 latency SLO를 정의합니다. Latency SLO는 distribution metrics와 threshold(예: 95th percentile < 250 ms)를 기반으로 할 수 있습니다. 2) Error budgets: SLO target(예: 99.9%)에서 자동으로 계산되며, 남은 budget과 burn으로 표시됩니다. 3) Burn-rate alerts: SLO burn rate에 대한 네이티브 alerting을 multi-window, multi-burn policy로 제공(“fast burn” 및 “slow burn” 패턴을 정확히 매칭). Alert는 notification channels를 통해 email, PagerDuty, Slack 등으로 라우팅할 수 있습니다. 4) Dashboards 및 감사 가능성: 서비스/리전별 중앙 대시보드, 일관된 정의, exec 리포팅에 적합한 히스토리 뷰를 제공합니다. 흔한 오해: Observability 안에 모두 포함되어 있어 Monitoring을 Logging/Trace/Profiler와 혼동하는 경우가 많습니다. Logging은 로그를 저장하고, Trace는 latency trace를 보여주며, Profiler는 CPU/memory hotspot을 보여줍니다. 이들만으로는 first-class SLO object, error budget, burn-rate alerting을 제공하지 않습니다. 시험 팁: Google Cloud에서 SLOs/error budgets/burn-rate alerting을 떠올릴 때는 “Cloud Monitoring SLO Monitoring”을 생각하세요. 트러블슈팅을 위해 Cloud Logging/Trace와 개념적으로 페어링할 수는 있지만, SRE 목표와 alerting의 control plane은 Monitoring입니다. 또한 요구사항을 Google Cloud Architecture Framework의 Reliability pillar에 매핑하세요: SLO를 정의하고, 사용자 관점의 SLI를 모니터링하며, 원시 리소스 metric이 아니라 error budget burn에 대해 alerting합니다.

2
문제 2

Your IoT analytics company runs a multi-tenant data pipeline on a Google Kubernetes Engine (GKE) Autopilot cluster in us-central1 for 120 production customers, and you promote releases with Cloud Deploy; during a 2-week refactor of a telemetry aggregator service (container image <250 MB), developers will edit code every 5–10 minutes on laptops with 8 GB RAM and limited CPU and must validate changes locally before pushing to the remote repository. Requirements: • Automatically rebuild and redeploy on local code changes (hot-reload loop ≤ 10 seconds). • Local Kubernetes deployment should closely emulate the production GKE manifests and deployment flow. • Use minimal local resources and avoid requiring a remote container registry for inner-loop builds. Which tools should you choose to build and run the container locally on a developer laptop while meeting these constraints?

Docker Compose와 dockerd는 빠른 로컬 rebuild/restart 루프를 제공할 수 있지만, GKE 및 Cloud Deploy에서 사용하는 Kubernetes manifest나 Kubernetes 배포 플로우를 가깝게 에뮬레이션하지 못합니다. Compose는 다른 구성 모델(docker-compose.yml)을 사용하며 Deployments, Services, ConfigMaps, RBAC 같은 네이티브 개념이 없습니다. 이는 프로덕션 Kubernetes manifest와 배포 동작을 가깝게 에뮬레이션해야 한다는 요구사항을 충족하지 못합니다.

Terraform과 kubeadm은 인프라 프로비저닝과 Kubernetes 클러스터 부트스트래핑에 초점이 맞춰져 있으며, 빠른 inner-loop 개발을 위한 것이 아닙니다. kubeadm은 노트북 워크플로에 비해 무겁고 운영 복잡도가 높으며, Terraform은 hot-reload를 가능하게 하기보다 인프라 관리 오버헤드를 추가합니다. 어느 쪽도 Skaffold에 필적하는 자동 파일 감시 rebuild/redeploy 루프를 제공하지 않으므로, 10초 이하 반복 요구사항을 충족하지 못합니다.

Minikube는 노트북에 적합한 경량 로컬 Kubernetes 클러스터를 제공하며, 로컬 image store를 사용할 수 있어 개발자가 원격 registry에 push할 필요가 없습니다. Skaffold는 코드 변경을 감시하고 프로덕션과 동일한 manifest(또는 Kustomize/Helm)를 사용해 Kubernetes로 rebuild/redeploy함으로써 inner loop를 자동화합니다. 둘을 함께 사용하면 빠른 hot-reload, Kubernetes 충실도, 그리고 최소한의 로컬/원격 의존성을 가장 잘 충족합니다.

kaniko와 Tekton은 주로 Kubernetes에서 이미지를 build하고 파이프라인을 실행하도록 설계된 것(CI/CD)이며, 리소스가 제한된 노트북에서 빠른 로컬 개발자 inner loop를 위한 것이 아닙니다. kaniko는 일반적으로 registry로 push하며, Tekton은 Kubernetes 클러스터와 파이프라인 설정 오버헤드가 필요합니다. 이 조합은 registry 없이 로컬 hot-reload 개발보다는 원격 build 시스템(예: in-cluster CI)에 더 적합합니다.

문제 분석

핵심 개념: 이 문제는 Kubernetes 앱을 위한 개발자 inner-loop 워크플로를 테스트합니다: 파일 변경 시 빠른 로컬 build+deploy, Kubernetes manifest 충실도, 그리고 원격 의존성 회피. Google Cloud에 정렬된 워크플로에서 Skaffold는 Kubernetes로 연속적인 로컬 개발을 위한 대표적인 도구이며, 경량 로컬 클러스터(Minikube)는 GKE manifest를 가깝게 근사합니다. 정답이 맞는 이유: Minikube는 비교적 낮은 오버헤드로 로컬에서 단일 노드 Kubernetes 클러스터를 실행하며, 로컬 Docker daemon(또는 containerd)을 사용하도록 지원하므로 이미지를 원격 registry에 push하지 않고도 build해서 사용할 수 있습니다. Skaffold는 자동화된 “edit-build-deploy” 루프를 제공합니다: 소스 파일을 감시하고, 컨테이너를 rebuild한 뒤, 로컬 클러스터에 redeploy합니다. file sync(수동 sync 규칙) 및/또는 빠른 incremental build를 통해 Skaffold는 많은 코드 변경에서 10초 미만의 반복을 달성할 수 있어 hot-reload/inner-loop 요구사항을 충족합니다. 또한 Skaffold는 프로덕션에서 사용하는 것과 동일한 Kubernetes manifest(또는 Kustomize/Helm)를 사용해 배포하므로, GKE 배포 형태를 매우 유사하게 에뮬레이션합니다. 주요 기능 / 모범 사례: - Skaffold “dev” 모드: 파일 감시 + 연속 build + deploy. - registry 없이 로컬 build: Minikube의 Docker 환경(예: 클러스터의 daemon에 직접 build) 사용 또는 Skaffold local builder에서 “push: false”로 구성. - manifest 충실도: 프로덕션 YAML/Kustomize overlay 재사용; 환경별 차이는 별도 툴링이 아니라 overlay에 유지. - 리소스 제약: Minikube는 (CPU/memory 제한) 튜닝 가능하며, 일반적으로 완전한 멀티 노드 로컬 클러스터를 실행하는 것보다 가볍습니다. 흔한 오해: - Docker Compose는 빠르지만, Kubernetes 오브젝트(Deployments, Services, ConfigMaps, RBAC)나 동일한 배포 플로우를 에뮬레이션하지 못합니다. - kaniko와 Tekton은 주로 CI/CD build 프리미티브이며, 노트북 inner-loop hot reload에 최적화되어 있지 않고 보통 registry 및 클러스터 기반 실행을 전제로 합니다. - Terraform/kubeadm은 클러스터/인프라 프로비저닝을 위한 것이지, 빠른 로컬 반복을 위한 것이 아닙니다. 시험 팁: Professional Cloud Developer에서는 요구사항을 개발자 라이프사이클에 매핑하세요: inner loop(Skaffold, Minikube/kind 같은 로컬 K8s) vs outer loop(Cloud Build/Cloud Deploy). “hot reload”, “watch files”, “Kubernetes manifests”, “no remote registry”가 보이면, Skaffold + 로컬 Kubernetes 클러스터가 표준 정답입니다. 또한 Autopilot은 프로덕션용이며, 로컬 에뮬레이션은 Autopilot 특화 스케줄링 동작이 아니라 Kubernetes API 호환성에 초점을 둡니다.

3
문제 3

Your IoT solution in Google Cloud collects data from thousands of sensor devices. Each device must publish messages to its own Pub/Sub topic, and consume messages from its own subscription. You need to ensure that each device can only publish and subscribe to its own Pub/Sub resources, while preventing access to others. What should you do?

정답입니다. 각 디바이스의 topic에는 pubsub.publisher를, 각 디바이스의 subscription에는 pubsub.subscriber를 할당하고, 특정 디바이스 identity를 resource level에서 binding합니다. 이는 최소 권한과 강력한 격리를 강제합니다. IAM evaluation은 다른 어떤 topic/subscription에 대한 접근도 거부합니다. 또한 감사 가능성을 개선하고 단일 디바이스가 침해되었을 때 표적 revoke를 지원합니다.

오답입니다. project-level pubsub.publisher 및 pubsub.subscriber는 디바이스 identity가 프로젝트 내 어떤 topic에도 publish하고 어떤 subscription에도 subscribe할 수 있게 합니다(role permissions 범위 내에서). 이는 각 디바이스를 자신의 resources로만 제한해야 한다는 요구사항을 위반합니다. 이는 multi-tenant 또는 디바이스별 격리 시나리오에서 흔한 anti-pattern입니다.

오답입니다. pubsub.topics.create 및 pubsub.subscriptions.create를 부여하는 것은 기존 resources에 대한 publish/subscribe 제한이 아니라 provisioning에 초점을 둡니다. 또한 디바이스가 임의의 topics/subscriptions를 생성할 수 있게 하여 위험을 증가시킵니다(잠재적인 quota 고갈 및 비용 증가). custom role을 사용하더라도 격리를 위해서는 여전히 resource-level publish/subscribe permissions가 필요합니다.

오답입니다. service account를 공유하면 모든 디바이스가 사실상 동일한 permissions를 갖게 되므로, 어떤 디바이스든 해당 service account가 접근 가능한 어떤 resource에도 publish/subscribe할 수 있습니다. 이는 격리를 깨고 특정 디바이스에 대한 행위 attribution을 어렵게 만듭니다. 또한 credential rotation/revocation이 모든 디바이스에 영향을 주기 때문에 incident response도 복잡해집니다.

문제 분석

핵심 개념: 이 문제는 최소 권한 원칙을 사용하여 Pub/Sub에 대한 Google Cloud IAM 권한 부여를 테스트합니다. Pub/Sub 권한은 IAM roles를 통해 부여되며, bindings는 서로 다른 resource level(프로젝트, topic, subscription)에서 적용될 수 있습니다. 디바이스별 격리를 위해서는 각 디바이스가 소유한 특정 topic/subscription으로 권한 범위를 제한해야 합니다. 정답이 맞는 이유: 각 디바이스 identity(일반적으로 디바이스당 고유한 service account 또는 고유한 workload identity)를 자신의 topic에는 pubsub.publisher로, 자신의 subscription에는 pubsub.subscriber로 resource level에서 binding하면 엄격한 resource-level access control이 적용됩니다. 각 디바이스는 자신의 topic에만 publish할 수 있고 자신의 subscription에서만 pull/ack할 수 있으며, IAM은 다른 디바이스의 Pub/Sub resources와 상호작용하는 것을 차단합니다. 이는 Google Cloud Architecture Framework의 security pillar인 최소 권한, 강력한 identity, 그리고 compartmentalization에 부합합니다. 주요 기능 / 모범 사례: - 광범위한 project-level grant 대신 Pub/Sub topics 및 subscriptions에 resource-level IAM을 사용합니다. - 폐기/교체 및 감사 가능성을 위해 디바이스당(또는 디바이스 클래스당) 하나의 identity를 선호합니다. - 과도하게 넓은 roles 대신 predefined roles(pubsub.publisher, pubsub.subscriber)를 사용합니다. 이는 필요한 작업(publish vs pull/ack)에 깔끔하게 매핑됩니다. - 운영 측면에서는 수천 대의 디바이스를 처리하기 위해 automation(Terraform/Deployment Manager/CI)으로 bindings를 관리합니다. 흔한 오해: - project level에서 roles를 부여하면 더 단순해 보이지만, identity가 프로젝트의 모든 topics/subscriptions에 접근할 수 있어 격리가 깨집니다. - create permissions가 포함된 custom roles를 만드는 것은 provisioning과 runtime access를 혼동한 것입니다. 일반적으로 디바이스는 Pub/Sub resources를 생성하면 안 됩니다. - 하나의 service account를 여러 디바이스가 공유하면 IAM 오버헤드는 줄지만 디바이스별 격리가 사라지고, incident response(특정 디바이스만 revoke)도 어려워집니다. 시험 팁: “자신의 resource에만 접근”이라는 문구가 보이면 가장 좁은 IAM scope(resource-level)와 작업에 맞는 가장 작은 predefined roles를 선택하세요. Pub/Sub에서는 publisher는 topics용, subscriber는 subscriptions용임을 기억하세요. 요구사항이 명시적으로 광범위한 접근을 허용하지 않는 한 project-level bindings는 피하세요.

4
문제 4

You are designing a tablet app for municipal tree inspectors that must store hierarchical observations (city -> district -> park -> tree -> inspection) with up to 5 nested levels and support offline work for up to 72 hours; upon reconnect, the app must automatically sync local changes and handle conflicts gracefully. A backend on Cloud Run will use a dedicated service account to enrich the same records (e.g., geocoding, policy tags) directly in the database, performing up to 5,000 writes per minute at peak. The solution must scale securely to 250,000 monthly active users in the first quarter and provide client SDKs with built-in offline caching and synchronization. Which database and IAM role should you assign to the backend service account?

Cloud SQL은 계층 구조에 대한 relational modeling을 지원하지만, 모바일/tablet apps를 위한 내장 offline persistence 및 automatic sync를 제공하는 Google client SDKs가 없습니다. local storage, change tracking, conflict resolution, sync logic을 직접 구현해야 합니다. 또한 roles/cloudsql.editor는 database-level DML permissions를 직접 부여하는 것이 아니라 instance를 관리하는 권한이며, app-level writes에 필요한 것보다 더 광범위합니다.

Bigtable은 높은 write throughput과 대규모 scale을 처리할 수 있지만, 계층형 document 탐색과 offline-first 모바일 sync보다는 time-series/analytics 스타일 access pattern에 최적화된 wide-column store입니다. offline caching/synchronization을 위한 Firestore 같은 client SDKs가 없습니다. 또한 roles/bigtable.viewer는 read-only이므로 backend가 records를 write로 enrichment해야 하는 요구사항을 충족할 수 없습니다.

Firestore in Native mode는 Firebase/Firestore client SDKs(offline persistence, local cache, reconnect 시 automatic sync)를 통해 계층형 관측 데이터와 offline-first 운영 요구사항을 충족합니다. hot spots를 피하도록 설계하면 대규모 user base로 확장 가능하며 높은 write rate도 지원합니다. roles/datastore.user는 backend service account에 Firestore에 대한 필요한 read/write access를 제공하여 enrichment updates를 안전하게 수행할 수 있게 합니다.

Firestore in Datastore mode는 주로 Datastore API compatibility를 위한 것이며, client apps에 대한 Firebase 스타일 offline synchronization 기대치와 직접적으로 잘 맞지 않습니다. 설령 database 선택이 수용 가능하더라도 roles/datastore.viewer는 read-only이므로 Cloud Run backend가 records를 enrichment하기 위해 분당 최대 5,000 writes를 수행해야 하는 요구사항을 충족할 수 없습니다.

문제 분석

핵심 개념: 이 문제는 계층형 데이터 모델링을 지원하면서 Google 제공 client SDK를 통해 모바일/오프라인-퍼스트 동기화를 지원하는 database를 선택하고, 해당 database에 write해야 하는 Cloud Run service account에 대해 최소 권한 IAM role을 고르는지를 평가합니다. 정답이 맞는 이유: Firestore in Native mode가 가장 적합합니다. Firebase/Firestore client SDK의 기반이 되는 database로서, 내장 offline persistence, local caching, 그리고 연결이 복구되면 자동 synchronization을 제공하므로 72시간 오프라인 요구사항과 “sync + conflict handling” 요구사항에 정확히 부합합니다. Firestore의 document/collection 모델은 subcollections를 사용하거나 reference/ID를 저장하는 방식으로 계층형 entity(도시/구/공원/나무/점검)를 자연스럽게 표현할 수 있으며, subcollections는 최대 100 레벨까지 지원하므로 5단계 중첩은 제한 내에 충분히 들어옵니다. Cloud Run에서 backend enrichment를 수행하려면 service account에 Firestore에 대한 read/write access가 필요하며, roles/datastore.user는 entity/document를 read 및 write할 수 있는 권한을 부여합니다(서버 사이드 access의 일반적인 최소 권한 기준). 이를 통해 backend가 분당 최대 5,000 writes를 수행할 수 있습니다. 주요 기능 및 best practices: - Offline-first: Firestore SDKs(Android/iOS/Web)는 offline persistence와 automatic sync를 지원합니다. conflict는 보통 “last write wins” semantics로 처리되며, transactions, server timestamps, custom merge logic로 개선할 수 있습니다. - Scale: Firestore는 serverless이며 높은 concurrency와 대규모 user base를 위해 설계되었습니다. Google Cloud Architecture Framework의 scalability 및 operational excellence 원칙과도 부합합니다. - Security: end-user auth에는 Firebase Authentication/Identity Platform을 사용하고, client access에는 Firestore Security Rules를 사용합니다. Cloud Run에는 IAM 기반 access를 가진 전용 service account를 사용합니다. - Throughput: 분당 5,000 writes(초당 약 83 writes)는 일반적으로 가능하며, hot-spot 회피(문서 key 전반에 write 분산, 단일 문서 contention 회피) 관점에서 설계해야 합니다. 흔한 오해: - Cloud SQL은 계층형 데이터를 저장할 수 있지만 offline sync SDK를 제공하지 않습니다. custom sync/conflict resolution을 직접 구축해야 합니다. - Bigtable은 매우 scalable하지만 모바일 offline sync SDK가 없고 계층형 document access pattern에 이상적이지 않습니다. - Firestore in Datastore mode는 Datastore APIs에 더 초점이 맞춰져 있어 Firebase offline sync 기대치와 직접적으로 잘 맞지 않습니다. Exam tips: “offline caching과 automatic synchronization이 있는 client SDKs”를 보면 Firestore (Native mode) / Firebase를 떠올리세요. 그다음 backend service account에 필요한 작업(read/write)을 가능하게 하는 IAM role을 선택합니다. viewer role은 write에 사용할 수 없고, 과도하게 광범위한 role은 피해야 합니다.

5
문제 5

Your mobile health platform currently stores per-user workout telemetry and personalized settings in a single PostgreSQL instance; records vary widely by user and evolve frequently as new device firmware adds fields (e.g., heart-rate variability, sleep stages), resulting in weekly schema migrations, downtime risks, and high operational overhead; you expect up to 8 million users, peak 45,000 writes/second concentrated by userId, simple key-based reads per user, and only per-user transactional consistency is required, not multi-user joins or complex cross-entity transactions. To simplify development and scaling while accommodating highly user-specific, evolving state without rigid schemas, which Google Cloud storage option should you choose?

Cloud SQL (PostgreSQL)은 managed relational database이지만 여전히 스키마 관리와 신중한 용량 계획이 필요합니다. 매주 스키마 마이그레이션과 다운타임 위험은 시나리오에서 언급된 정확한 고통 지점입니다. 45,000 writes/second에서는 단일 인스턴스로는 충분하지 않으며, 확장은 일반적으로 read replica(쓰기용이 아님) 또는 애플리케이션 수준 sharding이 필요해 운영 오버헤드가 증가합니다. 또한 잦은 마이그레이션 없이 사용자별로 매우 가변적인 레코드를 자연스럽게 지원하지 못합니다.

Cloud Storage는 blob(파일)을 위한 object store로 매우 높은 내구성과 처리량을 제공하지만, 사용자별 트랜잭션 일관성을 갖춘 저지연 키 기반 읽기/쓰기에 최적화된 데이터베이스는 아닙니다. 사용자별 JSON object를 저장할 수는 있지만, 효율적인 querying, 여러 관련 항목에 대한 atomic update, 데이터베이스 수준의 concurrency control을 잃게 됩니다. 원시 telemetry 아카이브, export, 또는 batch analytics 입력에 더 적합합니다.

Cloud Spanner는 수평 확장 가능한 relational SQL과 강한 일관성, 높은 가용성을 제공하며 매우 높은 write throughput도 처리할 수 있습니다. 그러나 schema 기반이며, 대규모에서 relational modeling, SQL join, row/table 간 transaction이 필요할 때 가장 적합합니다. 이 시나리오는 rigid schema와 잦은 마이그레이션을 피하고자 하며, 사용자별 트랜잭션 일관성과 단순 키 기반 읽기만 필요하므로 Spanner는 불필요하게 복잡하고 비용이 큽니다.

Cloud Datastore/Firestore는 확장 가능하고 운영 부담이 낮은 NoSQL document storage를 위해 목적에 맞게 설계되었으며 유연한 스키마를 제공합니다. 사용자별 파티셔닝(userId를 document key로 사용)에 적합하고, 자동 확장으로 높은 write rate를 지원하며, 문서가 필드 단위로 진화할 수 있어 매주 스키마 마이그레이션을 피할 수 있습니다. 또한 multi-entity relational join 없이도 사용자별 일관성을 위한 transaction/batched write를 지원합니다. 이는 확장성, 민첩성, 운영 오버헤드 우려를 직접적으로 해결합니다.

문제 분석

핵심 개념: 이 문제는 대규모 확장, 높은 쓰기 처리량, 그리고 잦은 스키마 마이그레이션 없이 엔터티별 데이터가 빠르게 변화하는 상황에 적합한 스토리지 시스템을 선택하는지를 평가합니다. Google Cloud에서는 자동 확장과 엔터티별 트랜잭션 의미론을 제공하는 스키마리스(또는 스키마 유연) 문서/NoSQL 데이터베이스가 가장 적합합니다. 정답이 맞는 이유: Cloud Datastore/Firestore (Firestore in Native mode)는 키 기반 액세스 패턴과 시간이 지나며 진화할 수 있는 문서 스타일 데이터(마이그레이션 없이 새 필드 추가 가능)를 위해 설계되었습니다. 이 워크로드는 userId 기준으로 강하게 파티셔닝할 수 있고, 사용자별 단순 읽기/쓰기가 필요하며, 사용자 데이터 범위 내에서만 트랜잭션 일관성이 요구됩니다. Firestore는 문서 집합 내에서 atomic operation과 transaction을 지원하고, “사용자별” 문서/서브컬렉션을 자연스럽게 모델링합니다. 또한 인스턴스 관리 없이 매우 높은 요청률까지 수평 확장되므로 운영 오버헤드와 다운타임 위험을 줄일 수 있습니다. 핵심 기능 / 모범 사례: - 유연한 스키마: 문서는 사용자마다 서로 다른 필드를 가질 수 있으며, firmware가 telemetry 속성을 추가함에 따라 진화할 수 있습니다. - 높은 확장성: 자동 sharding/partitioning과 managed operation이 800만 사용자 및 bursty write에 부합합니다. - 데이터 모델링: userId로 키잉된 최상위 users collection을 사용하고, settings는 user document에 저장하며 telemetry는 subcollection에 저장합니다(예: users/{userId}/telemetry/{eventId}). - 일관성/트랜잭션: 사용자별 불변 조건에는 transaction/batched write를 사용하고, 사용자 간 cross-user transactional requirement는 피합니다. - Architecture Framework 정렬: operational excellence(managed service), reliability(multi-zone replication), performance efficiency(low-latency key lookup). 흔한 오해: Spanner는 “규모” 때문에 자주 선택되지만 relational이며 schema 기반입니다. 잦은 스키마 변경과 문서형 가변성은 마찰을 증가시킵니다. Cloud SQL은 익숙하지만 45k writes/sec에서 상당한 sharding과 운영 복잡성 없이 확장/운영 목표를 달성하기 어렵습니다. Cloud Storage는 내구성이 높고 저렴하지만, 트랜잭션 의미론을 갖춘 키 기반 저지연 읽기/쓰기를 위한 데이터베이스는 아닙니다. 시험 팁: (1) 빠르게 변하는 필드, (2) 키 기반 엔터티별 접근, (3) 최소 운영으로 대규모 확장, (4) 엔터티 수준 트랜잭션만 필요—이 조합이 보이면 Firestore/Datastore를 떠올리세요. 전 세계 규모에서 row/table 간 강한 일관성과 relational modeling, SQL이 필요하면 Spanner를 선택하고, 중간 규모의 전통적 relational 워크로드에는 Cloud SQL을, blob/object에는 Cloud Storage를 선택하되 운영 DB 접근 패턴으로는 보지 마세요.

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

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

6
문제 6

During a disaster recovery drill, your workload fails over to a standby Google Cloud project in europe-west1. Within 20 seconds, a newly created and previously idle Cloud Storage bucket begins handling approximately 2100 object write requests per second and 7800 object read requests per second. As the surge continues, services calling the Cloud Storage JSON API start receiving intermittent HTTP 429 and occasional 5xx errors. You need to reduce failed responses while preserving as much throughput as possible. What should you do?

여러 bucket에 업로드를 분산하는 것은 일부 시스템에서 per-bucket hot-spotting 제약이 있을 때 도움이 될 수 있지만, Cloud Storage는 일반적으로 bucket당 매우 높은 request rate를 지원합니다. 이 시나리오는 새로 생성된 유휴 bucket과 갑작스러운 단계적 증가를 강조하므로, ramp/throttling 동작과 retry storm을 시사합니다. Sharding은 운영 복잡도(이름 지정, lifecycle, IAM, analytics)를 추가할 뿐, 스파이크로 유발된 429/5xx를 직접 해결하지 못합니다.

JSON API와 XML API는 동일한 Cloud Storage 서비스에 대한 서로 다른 인터페이스입니다. API를 전환해도 backend throttling 동작, quota, 또는 429/5xx를 올바르게 처리해야 하는 필요성이 의미 있게 바뀌지 않습니다. 여전히 적절한 retry 및 backoff 로직이 필요합니다. 이 선택지는 흔한 함정입니다: 프로토콜 변경은 갑작스러운 부하로 인한 rate limiting이나 일시적 오류를 거의 해결하지 못합니다.

HTTP 오류를 최종 사용자에게 그대로 전달하는 것은 실패 응답을 줄이는 데 아무런 도움이 되지 않습니다. 단지 내부 throttling과 일시적 실패를 고객에게 노출하여 체감 다운타임을 증가시킵니다. 모범 사례는 429/5xx를 제어된 재시도, backoff, 그리고 필요 시 circuit-breaking으로 처리하는 것입니다. DR/failover에서는 원시 오류 전달이 아니라 우아한 복구와 안정적인 처리량이 목표입니다.

점진적 ramp-up을 포함한 클라이언트 측 rate limiting은 429 throttling과 간헐적 5xx를 유발하는 갑작스러운 트래픽 스파이크를 완화합니다. 재시도에 exponential backoff + jitter를 결합하면 retry storm을 방지하고, Cloud Storage가 오류를 줄이면서 높은 지속 처리량을 제공할 수 있게 합니다. 이는 부하 상황에서 Google APIs에 권장되는 reliability 패턴입니다: concurrency를 제어하고, failover 이후 점진적으로 ramp하며, 일시적 실패를 안전하게 재시도합니다.

문제 분석

핵심 개념: 이 문제는 갑작스러운 트래픽 스파이크 동안 Cloud Storage의 request-rate 동작과, 높은 처리량을 유지하면서 throttling(HTTP 429) 및 일시적인 backend 오류(5xx)를 처리하도록 클라이언트/서비스를 설계하는 방법을 평가합니다. 또한 “cold” 리소스가 갑자기 hot해지는 재해 복구 failover 패턴도 다룹니다. 정답이 맞는 이유: 새로 생성되어 이전에 유휴 상태였던 bucket은 높은 QPS로 빠르게 상승(ramp)할 수 있습니다. 많은 클라이언트가 동시에 요청을 발행하기 시작하면, Cloud Storage는 per-project/per-bucket/per-client 또는 내부 fairness 제한으로 인해 429(Too Many Requests)를 반환할 수 있고, 과부하 또는 일시적 조건에서 간헐적으로 5xx가 발생할 수 있습니다. 처리량을 유지하면서 실패 응답을 줄이는 가장 효과적인 방법은 스파이크를 완화(smooth)하는 것입니다. 즉, 클라이언트 측 rate limiting을 점진적 ramp-up과 함께 구현하고(그리고 재시도에는 exponential backoff + jitter를 결합) 적용합니다. 이는 429/5xx 처리에 대한 Google의 가이드(서비스를 계속 두드리기보다 back off 후 retry)와 일치합니다. 제어된 ramp는 즉시 계단형(step-function)으로 증가시키는 것보다 오류가 적은 상태로 안정적인 높은 처리량에 도달합니다. 주요 기능 / 모범 사례: 클라이언트별 token-bucket/leaky-bucket rate limiting을 사용하고, 수십 초에 걸쳐 허용 QPS를 점진적으로 증가시키세요. 재시도는 jitter를 포함한 exponential backoff를 사용하고, 존재할 경우 Retry-After를 준수하며, retry storm을 방지하기 위해 최대 재시도 동시성(concurrency)을 제한하세요. 적용 가능한 경우 request batching을 고려하고, 쓰기 작업은 안전하게 재시도할 수 있도록 idempotency를 보장하세요(예: ifGenerationMatch 같은 precondition). 이 접근은 Google Cloud Architecture Framework의 reliability 원칙(우아한 성능 저하와 failover 중 제어된 복구 설계)을 따릅니다. 흔한 오해: 처리량을 늘리기 위해 여러 bucket으로 “shard”하는 것(A)이 유혹적일 수 있지만, Cloud Storage는 bucket당 높은 request rate를 처리하도록 설계되어 있습니다. 여기서 문제는 근본적으로 bucket sharding이 필요한 것이 아니라, 갑작스러운 ramp와 클라이언트 동작입니다. API를 바꾸는 것(B)은 기본 quota/limit을 바꾸지 않습니다. 오류를 최종 사용자에게 전달하는 것(C)은 실패를 줄이지 못하고 사용자 경험만 악화시킵니다. 시험 팁: 갑작스러운 급증 중 간헐적인 429와 가끔의 5xx가 보이면, throttling + 일시적 과부하를 떠올리세요. 시험은 API를 바꾸거나, 문제가 지속적인 per-bucket limit임을 명시하지 않는 한 bucket sharding 같은 아키텍처 복잡도를 추가하기보다, exponential backoff with jitter와 smooth ramp-up(rate limiting) 구현을 기대합니다.

7
문제 7

You are deploying a Python microservice to a Linux-based GKE Autopilot cluster in us-central1 that must connect to a Cloud SQL for PostgreSQL instance (instance connection name: myproj:us-central1:orders-db) via a Cloud SQL Auth Proxy sidecar, and you have already created a dedicated service account (my-app-sa) and want to follow Google-recommended practices and the principle of least privilege; what should you do next?

cloudsql.instances.connect만 포함하는 custom role은 더 제한적으로 보일 수 있지만, 문제가 Google 권장 사례를 묻는 경우에는 최선의 답이 아닙니다. 표준 Cloud SQL Auth Proxy 연결의 경우, Google은 일반적으로 custom role보다 predefined roles/cloudsql.client role을 기대합니다. 또한 custom role은 운영 오버헤드를 추가하고, 나중에 workload에 추가 관련 권한이 필요해질 경우 오류가 발생하기 쉽습니다. 자격증 시험에서는 문제에서 custom role을 만들라고 명시적으로 요구하지 않는 한, predefined 최소 권한 role이 일반적으로 선호됩니다.

roles/cloudsql.client는 Cloud SQL Auth Proxy를 통해 Cloud SQL에 연결해야 하는 workload를 위한 표준 predefined IAM role입니다. 인스턴스에 대한 관리 기능을 부여하지 않으면서 연결 전용 액세스를 제공하는 Google 권장 최소 권한 선택입니다. --unix-socket 옵션은 Pod 내부에서 Proxy를 로컬로 노출하는 유효한 방법이지만, 이 선택지가 정답인 본질적인 이유는 Unix socket이 필수이기 때문이 아니라 IAM role 할당 때문입니다. Autopilot 환경에서는 일반적으로 이 role을 Workload Identity와 함께 사용하여 sidecar가 장기 key 없이 안전하게 인증할 수 있도록 합니다.

roles/cloudsql.editor는 Cloud SQL 리소스에 단순히 연결하는 것이 아니라 이를 수정할 수 있게 하므로 권한이 지나치게 많습니다. Auth Proxy를 사용하는 Python microservice는 database session을 설정하기 위해 인스턴스 관리 권한이 필요하지 않습니다. editor 액세스를 부여하면 최소 권한 원칙을 위반하고 workload가 손상될 경우 보안 위험이 증가합니다. 시험 시나리오에서는 요구 사항이 애플리케이션 연결뿐일 때 관리 role은 오답입니다.

roles/cloudsql.viewer는 Cloud SQL 리소스에 대한 읽기 전용 가시성은 제공하지만 Cloud SQL Auth Proxy를 통한 연결 권한은 부여하지 않습니다. Proxy에는 연결 관련 권한이 필요하며, viewer에는 이러한 권한이 포함되어 있지 않습니다. 그 결과 workload는 metadata를 확인할 수는 있지만 애플리케이션에 필요한 인증된 Proxy 연결을 설정할 수는 없습니다. viewer는 Cloud SQL과 관련 있어 보이지만 실제로 액세스를 활성화하지 않기 때문에 흔한 오답 유도 선택지입니다.

문제 분석

핵심 개념: 이 문제는 Google 권장 사항과 최소 권한 원칙을 따르면서 GKE workload가 Cloud SQL Auth Proxy를 통해 Cloud SQL for PostgreSQL에 연결할 수 있도록 하는 올바른 IAM role에 관한 것입니다. Proxy를 통한 애플리케이션 연결의 경우, Google의 표준 predefined role은 workload가 사용하는 service account에 부여하는 roles/cloudsql.client입니다. GKE Autopilot에서는 일반적으로 Workload Identity와 함께 사용하여 Pod가 key를 저장하지 않고도 Google service account를 impersonate할 수 있게 합니다. 정답인 이유: 옵션 B가 정답인 이유는 roles/cloudsql.client가 Auth Proxy를 통해 Cloud SQL에 연결하기 위한 권장 최소 권한 predefined role이기 때문입니다. Proxy는 로컬 TCP port 또는 Unix domain socket을 노출할 수 있으며, --unix-socket 사용은 유효하고 Kubernetes에서 일반적으로 사용되지만, 답의 핵심은 roles/cloudsql.client를 부여하는 것입니다. 이는 표준 연결 패턴에 대해 범위를 좁힌 custom role을 만드는 것보다 Google 가이드에 더 잘 부합합니다. 주요 특징: - workload가 사용하는 Google service account에 roles/cloudsql.client를 부여합니다. - GKE Autopilot에서는 Workload Identity를 사용하여 Kubernetes service account를 my-app-sa에 바인딩합니다. - Cloud SQL Auth Proxy를 애플리케이션과 동일한 Pod 내의 sidecar로 실행합니다. - Proxy는 localhost TCP 또는 Unix socket에서 수신할 수 있으며, 둘 다 지원됩니다. 흔한 오해: - roles/cloudsql.viewer는 metadata를 보는 것만 가능하고 연결은 허용하지 않으므로 충분하지 않습니다. - roles/cloudsql.editor는 database 연결만 필요한 앱에는 권한이 지나치게 많습니다. - cloudsql.instances.connect만 포함한 custom role이 더 제한적으로 들릴 수 있지만, Google 권장 사례를 묻는 시험 문제에서는 일반적으로 표준 predefined roles/cloudsql.client role을 기대합니다. 시험 팁: Google Cloud 시험에서 Cloud SQL Auth Proxy 액세스에 대해 최소 권한과 권장 사례를 함께 묻는다면, 문제에서 custom role 설계를 명시적으로 요구하지 않는 한 roles/cloudsql.client를 우선 선택하세요. 또한 GKE Autopilot에서는 service account key 대신 Workload Identity가 선호되는 인증 메커니즘이라는 점도 기억하세요.

8
문제 8

GlobeGigs, a global freelance marketplace, runs a MySQL primary in us-central1 with read replicas in europe-west1 and asia-southeast1 and routes reads to the nearest replica; users in Singapore and Frankfurt still see p99 write latencies over 800 ms because writes go to the primary, and the team targets sub-200 ms p95 for both reads and writes with minimal operational overhead and without introducing eventual consistency for critical transactions. What should they do to further reduce latency for all database interactions with the least amount of effort?

Bigtable은 대규모 처리량과 낮은 지연 시간의 key/value 액세스 패턴에 최적화된 wide-column NoSQL 데이터베이스입니다. 이는 관계형 MySQL 대체재가 아니며, SQL join이나 “중요한 트랜잭션”에 기대되는 동일한 트랜잭션 의미론을 제공하지 않습니다. 가용성을 위해 복제할 수는 있지만, 전 세계적으로 일관된 관계형 쓰기에 가장 적합한 선택은 아닙니다. 마이그레이션에는 상당한 애플리케이션 재설계가 필요하며, 다중 행 관계형 트랜잭션에 대한 강한 일관성 기대치를 충족하지 못할 수 있습니다.

Cloud Spanner는 리전 전반에 걸쳐 낮은 지연 시간의 읽기와 쓰기를 제공하도록 구축된, 전 세계 분산형의 강한 일관성을 갖는 관계형 데이터베이스입니다. 사용자와 가까운 읽기-쓰기 복제본(예: Europe 및 Asia)을 갖는 multi-region Spanner 인스턴스를 사용하면, 트랜잭션에 대한 external consistency를 유지하면서 쓰기를 로컬에서 처리할 수 있습니다. 또한 완전 관리형(sharding, replication, failover)으로 “최소 운영 오버헤드” 요구사항을 충족하며, 단일 primary MySQL에 내재된 cross-region 쓰기 지연을 직접 해결합니다.

Firestore in Datastore mode는 관리형 NoSQL document 데이터베이스입니다. multi-region 구성으로 배포할 수 있고 많은 작업에서 강한 일관성을 제공하지만, 관계형 데이터베이스가 아니며 SQL 쿼리, join, 복잡한 관계형 스키마 전반의 전형적인 MySQL 트랜잭션 패턴이 없습니다. 마켓플레이스의 중요한 트랜잭션 워크로드를 MySQL에서 Datastore mode로 옮기려면 보통 데이터 모델과 쿼리를 대폭 재설계해야 하며, “중요한 트랜잭션”이 암시하는 관계형/트랜잭션 요구사항을 충족하지 못할 수 있습니다.

서비스를 GKE로 옮기고 load balancer를 추가하면 애플리케이션 확장성과 가용성은 개선되지만, 근본 문제는 해결하지 못합니다. 쓰기 지연 시간은 us-central1의 단일 MySQL primary까지의 cross-region round-trip time에 의해 지배됩니다. compute를 아무리 완벽하게 확장해도 데이터베이스 commit에 필요한 대륙 간 지연이라는 물리적 한계를 줄일 수 없습니다. 병목은 데이터베이스 아키텍처(단일 writer primary)이므로, 해법은 데이터 계층에서 글로벌 쓰기 지역성과 일관성을 해결해야 합니다.

문제 분석

핵심 개념: 이 문제는 대륙 간에 걸쳐 낮은 지연 시간의 읽기와 쓰기를 제공하면서, 중요한 트랜잭션에 대해 강한 일관성을 유지하고 운영 오버헤드를 최소화할 수 있는 전 세계 분산 데이터베이스를 선택하는지를 평가합니다. 정답이 맞는 이유: Cloud Spanner는 전 세계적으로 강한 일관성이 필요한 관계형 워크로드를 위해 설계되었습니다. Spanner에서는 여러 리전에 복제본(읽기-쓰기 복제본 포함)을 배치할 수 있으며, 클라이언트가 가장 가까운 읽기-쓰기 복제본에 쓰기를 수행할 수 있어 MySQL primary/replica에서 보이는 단일 primary로 인한 대양 횡단 쓰기 페널티를 피할 수 있습니다. Spanner는 트랜잭션에 대해 external consistency(TrueTime 기반의 강한 일관성)를 제공하므로, 중요한 작업에서 eventual consistency를 받아들일 필요가 없습니다. 이는 eventual consistency를 도입하지 않으면서 전 세계적으로 읽기와 쓰기 모두 p95 200ms 미만이라는 요구사항을 직접 충족합니다. 주요 기능 / 모범 사례: - 여러 리전에 읽기-쓰기 복제본을 두는 multi-region 인스턴스 구성을 통해, 지역성(locality)으로 쓰기 지연 시간을 줄입니다. - MySQL과 유사한 관계형 모델링을 지원하는 강한 일관성의 SQL 트랜잭션, secondary index(단, 스키마/SQL dialect는 다름). - Managed service: 자동 샤딩, 복제, failover, 고가용성을 제공하여 self-managed 또는 복잡한 복제 토폴로지 대비 운영 오버헤드를 줄입니다. - 클라이언트 측 모범 사례: 연결을 리전 단위로 유지하고, Spanner client library를 사용하며, hot-spotting을 피하도록 스키마를 설계합니다(예: 단조 증가 키를 피함). 흔한 오해: - “Read replica가 글로벌 지연 시간을 해결한다”: 읽기에는 도움이 되지만, 쓰기는 여전히 primary까지의 RTT 비용을 지불합니다. - “어떤 NoSQL 글로벌 DB든 더 빠르다”: 많은 NoSQL 옵션은 강한 일관성 또는 관계형 트랜잭션을 희생하므로, 중요한 트랜잭션 요구사항을 위반합니다. - “Compute 확장(GKE/LB)으로 DB 지연 시간이 해결된다”: 애플리케이션 확장은 cross-region 데이터베이스 쓰기 RTT를 제거하지 못합니다. 시험 팁: 글로벌 사용자 + 낮은 지연 시간의 읽기와 쓰기 + 강한 일관성/트랜잭션 + 최소 운영 부담을 보면, 정석적인 선택은 Cloud Spanner입니다. Bigtable은 wide-column 기반의 고처리량 분석/서빙 패턴용이며(관계형 트랜잭션용 아님), Firestore/Datastore는 multi-region이 가능하지만 document/NoSQL이라 대규모에서 엄격한 관계형/트랜잭션 요구사항을 충족하지 못할 수 있습니다. 항상 요구사항을 CAP/일관성 요구와 managed 글로벌 복제 기능에 매핑하세요.

9
문제 9

Your company operates a ride-hailing dispatch platform that maintains a persistent cache of all edge worker VMs used for geo-routing; only instances that are in the RUNNING state and have the label fleet=edge-worker should be eligible for job assignment (exclude STOPPED, SUSPENDED, or DELETED instances). The dispatcher reads this cache every 10 seconds and must reflect lifecycle changes (start/stop/suspend/preempt/delete) within 5 seconds across a fleet of 500+ instances to avoid misrouting. You need to design how the application keeps this available-VM cache from becoming noncurrent while minimizing operational overhead. What should you do?

Cloud Storage log sink는 아카이빙 및 배치 스타일 처리에 맞게 설계되었습니다. object finalization으로 트리거하더라도 로그는 가변적인 batching/flush 간격으로 파일로 기록되므로, 종단 간 지연이 5초 이내로 신뢰성 있게 보장되지 않습니다. 또한 운영 오버헤드(bucket 관리, object lifecycle, 파일 파싱)를 추가하며, 거의 실시간 캐시 무효화에 권장되는 패턴이 아닙니다.

Cloud Asset Inventory real-time feed는 자산 인벤토리/메타데이터 변경(create/delete, IAM/policy, 일부 구성 변경)을 추적하는 데 가장 적합합니다. RUNNING/STOPPED/SUSPENDED 같은 빠른 인스턴스 전원 상태 전환이나 preemption 신호에는 적합성이 떨어지며, 디스패치 정확성에 필요한 일관된 sub-5-second 라이프사이클 충실도를 제공하지 못할 수 있습니다.

Cloud Logging의 Pub/Sub log sink는 감사 로그 항목을 거의 실시간으로 스트리밍합니다. Compute Engine 라이프사이클 관련 Admin Activity 및 System Event 로그를 필터링하면 사용자 주도 작업과 preemption 같은 시스템 주도 이벤트를 모두 포착할 수 있습니다. 이후 Eventarc가 재시도와 낮은 운영 오버헤드로 이러한 메시지를 서비스에 전달할 수 있어, 500+ 인스턴스 전반에서 수 초 내 캐시 업데이트가 가능합니다.

BigQuery log sink는 저지연 이벤트 처리보다 분석에 최적화되어 있습니다. 1분마다 query하는 것만으로도 5초 최신성 요구사항을 이미 위반하며, 잦은 query는 비용과 복잡성을 증가시킵니다. 이는 pull 기반 polling 설계로, 특히 라이프사이클 변경(preemption, autoscaling, rolling update) burst 동안 캐시가 오래되거나 잘못 라우팅될 위험이 있습니다.

문제 분석

핵심 개념: 이 문제는 거의 실시간에 가까운 인프라 상태 변경에 대한 이벤트 기반 통합을 테스트합니다. 핵심 서비스는 Cloud Logging(감사 로그), Pub/Sub로의 log sink, 그리고 애플리케이션으로의 신뢰할 수 있는 전달을 위한 Eventarc입니다. 목표는 적격 Compute Engine 인스턴스(RUNNING + label fleet=edge-worker)의 매우 최신 캐시를 <5초 전파와 최소 운영으로 유지하는 것입니다. 정답이 맞는 이유: 옵션 C는 Compute Engine 인스턴스 라이프사이클 변경(start/stop/suspend/delete/preempt/terminate)을 위해 Cloud Logging 감사 로그(Admin Activity + System Event)를 사용하고, 조직 수준 log sink를 통해 일치하는 항목을 Pub/Sub로 내보냅니다. Pub/Sub는 저지연 fan-out과 버퍼링을 제공하며, Eventarc는 해당 Pub/Sub 메시지를 캐시를 즉시 업데이트하는 서비스(Cloud Run/GKE/Cloud Functions)로 라우팅할 수 있습니다. 이 아키텍처는 push 기반이며, 500+ 인스턴스로 확장 가능하고, polling보다 5초 최신성 요구사항을 훨씬 더 잘 충족합니다. 주요 기능 / 구성 참고 사항: - 여러 프로젝트/플릿을 커버하고 운영 오버헤드를 줄이기 위해 org-level sink를 사용합니다. - 관련 Compute Engine audit log method와 resource.type="gce_instance"를 필터링하고, 가능한 경우 label 제약도 포함합니다(대개 label은 consumer에서 Compute API를 호출해 현재 상태/label을 확인하는 방식으로 강제하는 것이 가장 좋습니다). - Admin Activity(사용자/API 시작)와 System Event(시스템 생성, 예: preemption)를 모두 포함하여 라이프사이클 전환을 누락하지 않도록 합니다. - Eventarc + Pub/Sub는 재시도, dead-lettering 패턴, 디커플링을 제공하며, Pub/Sub retention은 burst를 흡수하는 데 도움이 됩니다. 흔한 오해: - Asset Inventory feed는 자산 메타데이터 변경에 관한 것이며, 필요한 즉시성으로 모든 런타임 상태 전환(RUNNING/STOPPED/SUSPENDED)을 포착하지 못할 수 있습니다. - Cloud Storage 또는 BigQuery sink는 추가 지연 및/또는 polling을 유발하여 5초 요구사항을 위반합니다. 시험 팁: 인프라 변경에 대해 sub-minute(초 단위) 반응이 필요할 때는 push 기반 이벤트 처리를 선호하세요: Cloud Logging -> Pub/Sub sink -> Eventarc/consumer. 지연 요구사항이 느슨할 때만 polling(BigQuery query, 주기적 list 호출)을 사용하세요. 또한 preemption은 일반적으로 시스템 생성 로그/이벤트로 노출되므로 System Event 커버리지를 포함해야 합니다.

10
문제 10

You are designing a real-time processing pipeline for a city's bike-sharing program: each bike sends a GPS/status event to a Pub/Sub topic at an average rate of 5,000 messages per minute with spikes up to 50,000; each message must be processed within 300 ms to update a live availability dashboard, the processing component must have no dependency on any other system or managed infrastructure (no VMs or clusters), and you must incur costs only when new messages arrive; how should you configure the architecture?

Compute Engine은 VM 인스턴스를 프로비저닝하고 관리(패치, scaling groups, health checks)해야 합니다. Pub/Sub push가 메시지를 효율적으로 전달하더라도, 트래픽을 수신하려면 VM이 계속 실행 중이어야 하므로 유휴 상태에서도 비용을 지불하게 되어 “새 메시지가 도착할 때만 비용 발생”을 위반합니다. 또한 VM 또는 클러스터 같은 관리형 인프라에 대한 의존성이 없어야 한다는 요구사항과도 충돌합니다.

Cloud Functions는 pull subscription을 생성하고 Pub/Sub를 polling하면 안 됩니다. polling은 불필요한 지연과 비용을 추가하는데, 함수가 지속적으로 실행되거나 스케줄에 의해 호출되어야 하므로 이벤트 기반 모델이 깨집니다. 또한 스파이크 동안 확장을 복잡하게 만들고, polling interval과 subscription 관리 오버헤드 때문에 300 ms 처리 목표를 놓칠 수 있습니다.

GKE는 명시적으로 관리형 클러스터(노드, autoscaling, upgrades)이므로 “VM 또는 클러스터 없음” 제약을 위반합니다. pull subscription과 worker pod로 높은 처리량을 다룰 수는 있지만, 복잡한 scale-to-zero 패턴(일반적으로 GKE에서는 전형적이지 않음)을 구현하지 않는 한 메시지가 없을 때도 클러스터 리소스 비용을 지불합니다. 운영 오버헤드도 서버리스 옵션보다 훨씬 큽니다.

Pub/Sub trigger가 있는 Cloud Functions는 Pub/Sub 메시지 처리를 위한 정석적인 서버리스 패턴입니다. 메시지 볼륨에 따라 자동으로 확장되고, bursty workload를 지원하며, invocation/compute time 기준으로 과금되어 메시지 도착 시에만 비용이 발생하는 요구사항과 정렬됩니다. VM/클러스터 관리를 피할 수 있고, 함수 로직을 가볍고 idempotent하게 유지하면 준실시간 대시보드 업데이트에 적합한 낮은 지연의 이벤트 전달을 제공합니다.

문제 분석

핵심 개념: 이 문제는 Pub/Sub와 Cloud Functions를 사용하여 Google Cloud에서 이벤트 기반, 서버리스 스트림 처리를 평가하며, 자동 확장, 낮은 운영 오버헤드, 사용량 기반 과금을 강조합니다. 또한 Pub/Sub의 push/pull 전달 모델의 차이와 관리형 컴퓨팅 인프라(VM/클러스터)를 피해야 하는 시점을 간접적으로 테스트합니다. 정답이 맞는 이유: Pub/Sub trigger가 있는 Cloud Functions는 Pub/Sub 메시지가 도착하는 즉시 처리하도록 목적에 맞게 설계되어 있습니다. VM/클러스터 관리에 대한 의존성이 없고, 메시지 볼륨(스파이크 포함)에 따라 자동으로 확장되며, 주로 invocation과 compute time에 대해 과금되어 “새 메시지가 도착할 때만 비용이 발생” 요구사항과 일치합니다. 적절한 함수 설계(빠른 startup, 최소한의 외부 호출)를 하면, 가벼운 변환과 대시보드 업데이트에 대해 300 ms 처리 목표를 달성하는 것이 가능합니다. 주요 기능 / 구성 모범 사례: - Pub/Sub-triggered function(2nd gen Cloud Functions는 Cloud Run 인프라에서 실행)을 사용하여 이벤트 전달로 메시지를 수신합니다. - Pub/Sub는 at-least-once delivery를 제공하므로 idempotent 처리를 보장해야 합니다. event ID 또는 timestamp를 사용해 중복을 처리합니다. - 스파이크를 처리하기 위해 concurrency와 instance limits(2nd gen)를 튜닝하고, 지연 시간을 줄이기 위해 처리 CPU/memory를 적절히 사이징합니다. - 복원력을 위해 subscription에 dead-letter topics와 retry 설정을 사용합니다. - 의존성을 최소화하고 긴 네트워크 호출을 피합니다. 대시보드 datastore를 업데이트한다면 낮은 지연의 managed service(예: Firestore/MemoryStore)를 사용하되, compute 구성요소 자체는 서버리스로 유지합니다. 흔한 오해: - “VM으로 push subscription”(옵션 A)은 단순해 보이지만, 관리형 인프라가 없어야 한다는 요구사항을 위반하고 유휴 상태에서도 비용이 발생합니다. - “pull subscriptions로 polling”(옵션 B/C)은 서버리스 trigger에서 흔한 안티패턴입니다. 지연 시간을 늘리고 compute를 낭비하며 확장을 복잡하게 만듭니다. 시험 팁: 요구사항에 (1) 서버/클러스터 없음, (2) 이벤트 발생 시에만 과금, (3) Pub/Sub로부터의 준실시간 처리 가 포함되면, 기본 선택은 Pub/Sub trigger가 있는 Cloud Functions(또는 Cloud Run)입니다. 항상 켜져 있는 worker나 polling이 필요한 설계는 피하세요. 또한 Pub/Sub는 at-least-once이므로 retry와 중복을 고려해 설계해야 합니다.

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

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

11
문제 11

Your team uses Cloud Build to run CI for a Go microservice stored in a private GitHub repository mirrored to Cloud Source Repositories; one of the build steps requires a specific static analysis tool (version 3.7.2) that is not present in the default Cloud Build environment, the tool is ~120 MB and must be available within 5 seconds at step start to keep total build time under a 10-minute SLA, outbound internet access during builds is restricted, and you need reproducible results across ~50 builds per day—what should you do?

빌드 중 바이너리를 다운로드하는 방식은 취약하며 제시된 제약을 대체로 충족하지 못합니다. 아웃바운드 인터넷 접근이 제한되어 다운로드가 완전히 차단될 수 있습니다. 허용되더라도 네트워크 변동성과 업스트림 가용성 문제로 5초 시작 요구사항을 쉽게 초과하고 10분 SLA를 위협할 수 있습니다. 또한 체크섬을 고정하고 미러를 처리하지 않으면 재현성이 떨어지며, 이는 복잡성과 리스크를 추가합니다.

커스텀 Cloud Build builder 이미지가 가장 적합합니다. 정확한 도구 버전(3.7.2)을 컨테이너 이미지에 패키징하여 단계가 시작되는 즉시 사용할 수 있게 합니다. 이는 아웃바운드 인터넷 접근을 피하고, 성능을 개선하며(런타임 다운로드 없음), 이미지 태그 또는 더 나은 방식으로 이미지 digest를 고정하여 재현 가능한 결과를 보장합니다. 이미지를 Artifact Registry에 저장하면 통제되고 감사 가능한 CI 의존성을 지원합니다.

120 MB 바이너리를 소스 리포지토리에 커밋하면 인터넷 없이도 빌드가 가능해질 수 있지만, CI/CD 관점에서 좋지 않은 관행입니다. 리포지토리를 비대하게 만들고, 클론 및 미러링을 느리게 하며, 코드 리뷰를 복잡하게 하고, 공급망 거버넌스 문제(바이너리 출처, 스캐닝, 라이선스)를 만들 수 있습니다. 또한 도구 배포를 소스 변경에 결합시키며, 여러 서비스나 파이프라인이 동일 도구를 필요로 할 때 오류가 발생하기 쉽습니다.

기능 요청을 제출하는 것은 즉각적인 요구사항을 해결하지 못하며 SLA를 충족하기 위한 신뢰할 수 있는 전략이 아닙니다. 기본 Cloud Build 환경은 Google의 일정에 따라 변경되며, 특수한 도구나 특정 버전을 포함하지 않을 수 있습니다. 추가되더라도 재현성을 위해 버전 고정이 필요합니다. 시험에서는 명확한 제약이 있을 때 “플랫폼이 추가해주길 기다린다”는 거의 정답이 아닙니다.

문제 분석

핵심 개념: 이 문제는 Cloud Build 실행 환경과 빌드 단계에 대해 결정적(deterministic)이고 빠르며 오프라인인 의존성을 제공하는 방법을 테스트합니다. Cloud Build에서는 각 단계가 컨테이너 이미지에서 실행됩니다. 필요한 도구가 기본 builders에 없다면, 빌드 시점에 가져오거나(custom download) 커스텀 builder 이미지에 패키징할 수 있습니다. 정답이 맞는 이유: 정적 분석 도구(v3.7.2)가 이미 포함된 커스텀 Cloud Build builder 이미지는 단계가 시작되자마자 도구를 즉시 사용할 수 있게 해주어(5초 요구사항 충족) 외부 인터넷 아웃바운드 접근을 피할 수 있습니다(제한됨). 또한 도구 버전이 이미지에 고정(pinned)되므로 하루 약 50회 빌드 전반에서 재현성을 보장합니다. 이는 CI 모범 사례(불변(immutable)이고 버전 관리되는 빌드 환경으로 변동성과 외부 의존성을 줄임)와 일치합니다. 주요 기능 / 구성 / 모범 사례: - 커스텀 builder 이미지(예: 최소 Linux 이미지 또는 공식 Go builder 기반)를 만들고 120 MB 바이너리를 이미지 레이어에 포함(bake)합니다. - 이미지를 Artifact Registry(또는 Container Registry)에 저장하고 cloudbuild.yaml 단계에서 이미지 이름으로 참조합니다. - 최대 재현성을 위해 불변 digest(예: image@sha256:...)로 고정(pin)합니다. - 더 엄격한 네트워크 egress 제어가 필요하면 Cloud Build private pools를 사용합니다. 다만 egress가 제한되더라도, 사전 패키징된 이미지는 런타임 다운로드를 피할 수 있습니다. - 이 접근은 Google Cloud Architecture Framework 원칙을 지원합니다: 신뢰성(일관된 빌드), 운영 우수성(반복 가능한 파이프라인), 성능 효율성(빠른 단계 시작). 흔한 오해: 빌드 중 다운로드(옵션 A)는 단순해 보이지만, 제한된 아웃바운드 인터넷 요구사항을 위반하고 지연/가용성 리스크를 유발하여 10분 SLA를 깨뜨릴 수 있습니다. 바이너리를 커밋(옵션 C)하는 방식은 재현 가능해 보일 수 있지만, 리포지토리를 비대하게 만들고 리뷰를 복잡하게 하며, 일반적으로 공급망(supply-chain) 및 유지보수 관점에서 안티 패턴입니다. 기본 지원 요청(옵션 D)은 시험 시나리오에서 실행 가능한 해결책이 아니며 즉각적인 SLA 요구를 충족하지 못합니다. 시험 팁: Cloud Build 문제에서 “도구가 없음”, “인터넷 없음”, “빠른 시작”, “재현 가능한 빌드”가 나오면 기대되는 패턴은 다음입니다: 커스텀 builder 이미지를 만들고, Artifact Registry에 저장한 뒤, 빌드 단계에서(종종 digest로 고정하여) 참조합니다. 런타임 다운로드나 대용량 바이너리를 소스 컨트롤에 커밋하는 것보다 불변이고 버전 관리되는 아티팩트를 선호하세요.

12
문제 12

Your fintech company runs payment microservices on GKE in project retail-prod-001 and must satisfy PCI DSS 10.3; compliance mandates mirroring a duplicate of all application logs matching resource.type="k8s_container" AND labels.app="payments" AND severity>=ERROR from retail-prod-001 to a separate project audit-logs-123 that is restricted to the audit team, without altering existing retention or disrupting current log flows, and without building custom batch jobs; delivery must be near real time (<60 seconds) and the audit project must control retention at 365 days. What should you do?

정답입니다. cross-project Log Router sink는 매칭되는 로그를 near real time으로 audit-logs-123의 user-defined log bucket으로 export합니다. 이는 기존 retention을 변경하거나 retail-prod-001의 현재 log flow를 방해하지 않으면서 로그를 복제합니다. audit project는 자신의 bucket에 365일 retention을 설정할 수 있으며, sink의 writer identity에 logs.bucketWriter를 부여하면 안전한 least-privilege 전달이 가능합니다.

오답입니다. scheduled Function은 custom batch/ETL 접근 방식으로, custom batch jobs를 피하라는 요구사항을 위반하며 <60초 near-real-time SLA를 충족하지 못할 가능성이 큽니다(매일 스케줄은 명시적으로 너무 느립니다). 또한 운영 리스크(retries, duplicates, pagination, quota limits)와 비용을 추가합니다. 추가로, _Required에서 읽는 것은 application container log에 대한 올바른 소스가 아닙니다.

오답입니다. 로그를 redirect하기 위해 “_Default bucket의 routing rules를 수정”하지 않습니다. 라우팅은 Log Router sink로 수행되며, redirect는 기존 log flow를 변경하게 되어 금지되어 있습니다. 요구사항은 현재 동작을 그대로 유지하면서 로그를 mirror/duplicate하는 것입니다. 또한 system bucket(_Default/_Required)에는 제약이 있으므로, baseline ingestion 패턴을 변경하기보다 추가 sink를 만드는 것이 best practice입니다.

오답입니다. Admin Activity 및 System Event 로그는 audit log이지, GKE container의 application log가 아닙니다. 요구사항은 resource.type="k8s_container"에 labels.app="payments" 및 severity>=ERROR인 로그로 명확히 지정되어 있으며, 이는 application log입니다. _Required audit log category만 복사하면 PCI DSS 10.3의 application error logging 요구를 충족하지 못하고, 지정된 filter criteria도 놓치게 됩니다.

문제 분석

핵심 개념: 이 문제는 Cloud Logging 아키텍처를 테스트합니다: Log Router sink, log bucket으로의 cross-project log routing, 그리고 retention 제어입니다. 또한 감사 가능성과 직무 분리(separation of duties)에 대한 PCI DSS 10.3 기대사항을 다루며, 이는 Google Cloud Architecture Framework의 security pillar(centralized logging, controlled access, immutable/retained audit evidence)에 매핑됩니다. 정답이 맞는 이유: 기존 log flow를 방해하지 않으면서 retail-prod-001의 일부 로그를 near real time으로 별도의 접근 제한된 audit project에 미러링하려면, 소스 project에 inclusion filter가 있는 Log Router sink를 만들고 audit-logs-123의 destination log bucket으로 라우팅합니다. 이렇게 하면 duplicate stream이 생성됩니다: 로그는 소스 project의 bucket에 기존과 동일하게 계속 저장되고, 매칭되는 엔트리는 수 초 내(일반적으로 60초 훨씬 이내)에 audit project로 export됩니다. 이후 audit project는 user-defined bucket에 대해 자체 retention(365일)을 설정할 수 있어, 감사 팀이 retention을 제어해야 한다는 요구사항을 충족합니다. 주요 기능 / 구성: - audit-logs-123에 user-defined log bucket을 생성하고 retention을 365일로 설정합니다. - retail-prod-001에서 다음과 같은 inclusion filter를 가진 sink를 생성합니다: resource.type="k8s_container" AND labels.app="payments" AND severity>=ERROR - destination을 audit project의 log bucket으로 선택합니다. - sink의 writer identity에 destination bucket에서 필요한 최소 IAM role(logs.bucketWriter)을 부여합니다. 이는 least privilege와 separation of duties를 보장합니다. 흔한 오해: 많은 사람들이 로그를 “이동”해야 하거나 default bucket을 변경해야 한다고 생각합니다. Cloud Logging에서는 일반적으로 sink를 통해 export/copy하며, system bucket을 수정하거나 기존 ingestion을 방해하지 않습니다. 또 다른 사람들은 custom ETL(Functions/Scheduler)을 선택하지만, 이는 “custom batch jobs 금지” 및 near-real-time 제약을 위반하고 운영적으로 취약합니다. 시험 팁: - retention 제어가 필요한 cross-project log duplication이라면: Log Router sink -> destination log bucket을 떠올리세요. - _Required는 특별한(플랫폼 필수) 로그이며, application log가 일반적으로 위치하는 곳이 아닙니다. application log는 보통 라우팅하지 않으면 _Default에 있습니다. - retention은 destination project의 log bucket 수준에서 제어되며, exporting은 source retention을 변경하지 않습니다. - IAM 단계를 항상 포함하세요: sink writer identity에 destination bucket 권한을 부여합니다.

13
문제 13

Your retail analytics team has an IoT gateway that uploads a 5 MB CSV summary every 10 minutes to a Cloud Storage bucket gs://retail-iot-summaries-prod. Upon each successful upload, you must notify a downstream pipeline via the Pub/Sub topic projects/acme/topics/iot-summaries so a Dataflow job can start. You want a solution that requires the least development and operational effort, introduces no additional compute to manage, and can be set up within 1 hour; what should you do?

정답입니다. Cloud Storage는 object finalize(OBJECT_FINALIZE) 알림을 Pub/Sub topic으로 직접 publish하도록 구성할 수 있습니다. 이는 코드가 필요 없고 관리할 compute도 없는 네이티브 통합으로, 최소 운영 노력과 빠른 설정 요구사항에 부합합니다. IAM에서 Cloud Storage service account가 topic에 publish할 수 있도록 허용하고, 다운스트림 consumer는 at-least-once delivery semantics를 고려해 설계하세요.

오답입니다. App Engine은 업로드를 수신한 뒤 Pub/Sub로 publish하는 애플리케이션 endpoint를 구축하고 배포해야 합니다. 이는 개발 시간, 운영 고려사항(버전, 스케일링 동작, 모니터링)을 추가하고, 수집 경로도 변경합니다(Cloud Storage에 직접 업로드하는 대신 앱으로 업로드). 최소 개발 및 추가 compute 관리 없음이라는 요구사항을 위반합니다.

이 문제의 제약 조건에서는 오답입니다. Cloud Storage finalize 이벤트로 트리거되는 Cloud Function이 Pub/Sub로 publish할 수는 있지만, 여전히 코드 작성/배포/운영이 필요합니다(런타임 구성, 재시도, 로깅/알림, function에 대한 IAM). Cloud Storage가 Pub/Sub로 직접 publish할 수 있으므로, 단순 알림에는 function이 불필요한 추가 구성 요소입니다.

오답입니다. GKE에서 서비스를 실행하면 운영 오버헤드가 가장 큽니다: cluster 프로비저닝, node 관리(Autopilot이어도 추가 설정은 필요), 배포, 스케일링, 보안 패치, 모니터링이 필요합니다. 또한 업로드 흐름을 서비스로 보내도록 변경해야 합니다. 이는 “1시간 이내” 및 “추가 compute 관리 없음” 요구사항과 거리가 멉니다.

문제 분석

핵심 개념: 이 문제는 운영 오버헤드를 최소화하면서 Cloud Storage와 Pub/Sub 간의 이벤트 기반 통합을 테스트합니다. 핵심 기능은 Cloud Storage 이벤트 알림(object finalize)으로, 중간에 어떤 컴퓨팅도 실행하지 않고도 Pub/Sub topic으로 직접 publish할 수 있어, Dataflow 같은 다운스트림 시스템이 새 object에 반응할 수 있습니다. 정답이 맞는 이유: bucket이 OBJECT_FINALIZE 알림을 Pub/Sub로 보내도록 구성하는 것이 개발과 운영 측면에서 가장 부담이 적은 접근입니다. 코드가 필요 없고, 배포할 런타임도 없으며, 컴퓨팅의 스케일링/패치/모니터링도 필요 없습니다. 빠르게(대개 몇 분 내) 구성할 수 있고, finalize 이벤트는 bucket에서 object가 성공적으로 생성/덮어쓰기될 때 발생하므로 “각 업로드가 성공할 때마다”라는 요구사항을 충족합니다. 주요 기능 / 구성 / 모범 사례: - gs://retail-iot-summaries-prod에 대해 OBJECT_FINALIZE용 Cloud Storage Pub/Sub notifications를 사용합니다. - Pub/Sub topic이 올바른 project(projects/acme/topics/iot-summaries)에 존재하는지 확인하고, Cloud Storage service account에 해당 topic에 publish할 권한(pubsub.publisher)을 부여합니다. - 다운스트림에서 필터링/중복 처리를 고려합니다: storage notifications는 at-least-once delivery이므로 Dataflow 트리거 로직은 idempotent해야 합니다(예: object name + generation으로 dedupe). - 알림에 object metadata(bucket, objectId, generation)를 포함해 Dataflow가 정확한 파일을 찾을 수 있게 합니다. 흔한 오해: Cloud Functions(option C)도 serverless이지만, 코드 작성, 배포, function runtime에 대한 IAM, 재시도, 그리고 cold-start/관측성 오버헤드가 추가됩니다. App Engine과 GKE는 운영 부담이 더 크며, Cloud Storage가 이미 Pub/Sub 이벤트를 직접 emit할 수 있으므로 불필요합니다. 시험 팁: 요구사항이 “최소 개발,” “추가 compute 없음,” “빠른 설정”을 강조할 때는 glue code를 작성하기보다 managed integration(네이티브 이벤트 알림)을 우선 선택하세요. Cloud Storage → Pub/Sub notifications는 대표적인 통합 패턴이며, publish 전에 변환/검증/라우팅/보강이 필요한 경우에만 Cloud Functions를 사용하세요.

14
문제 14

You are building a real-time leaderboard microservice for a gaming platform and plan to run it on Cloud Run in us-central1. Your source code is stored in a Cloud Source Repository named game-leaderboard, and new releases must deploy automatically whenever changes are pushed to the release/v2 branch. You have already created a cloudbuild.yaml that builds and pushes gcr.io/PROJECT_ID/leaderboard:$SHORT_SHA and then runs: gcloud run deploy leaderboard-api --image gcr.io/PROJECT_ID/leaderboard:$SHORT_SHA --region us-central1 --platform managed --allow-unauthenticated. You want the most efficient approach to ensure each commit to release/v2 triggers a deployment with no manual commands. What should you do next?

Pub/Sub는 CSR-to-Cloud Build 자동화에 가장 효율적이거나 표준적인 접근이 아닙니다. Pub/Sub로 event-driven pipeline을 구성할 수는 있지만, CSR은 push event에 대해 Cloud Build triggers와의 first-class integration을 이미 제공합니다. Pub/Sub를 추가하면 추가적인 가치 없이 복잡성(topic, permissions, message format, trigger wiring)만 증가합니다. 이는 단순한 “push-to-deploy” workflow에는 불필요합니다.

의도된 해법입니다: Cloud Source Repository에 연결된 Cloud Build trigger를 생성하고 release/v2 branch로의 push 시 실행되도록 구성합니다. Trigger는 기존 cloudbuild.yaml을 실행하여 image를 빌드 및 push한 뒤 Cloud Run에 배포합니다. 이는 최소한의 구성요소로 진정한 CI/CD를 제공하며, 강력한 auditability와 branch 기반 release 제어를 제공합니다.

일반적인 webhook trigger도 동작할 수는 있지만, CSR이 이미 Google-native source로서 Cloud Build trigger를 직접 지원하므로 여기서는 가장 효율적이지 않습니다. Webhooks는 보통 외부 Git provider 또는 Cloud Build로 POST할 수 있는 custom system에서 사용됩니다. Webhook을 사용하면 네이티브 CSR trigger에 비해 운영 오버헤드(URL/secret 관리 및 delivery 보장)가 추가됩니다.

Cloud Scheduler로 24시간마다 gcloud builds submit을 실행하는 방식은 polling 기반이며, release/v2에 대한 각 commit이 배포를 트리거해야 한다는 요구사항을 충족하지 못합니다. 또한 불필요한 latency를 유발하고, 실행 사이에 여러 commit이 발생하면 stale code를 배포할 수 있습니다. 이는 event-driven trigger보다 신뢰성이 낮고 CI/CD best practices에도 덜 부합합니다.

문제 분석

핵심 개념: 이 문제는 Cloud Source Repositories (CSR)와 통합된 Cloud Build triggers를 사용하여 소스 변경 시 자동으로 빌드 및 Cloud Run 배포를 수행하는 Google Cloud의 continuous delivery를 테스트합니다. 정답이 맞는 이유: Cloud Build trigger는 CSR repository에 직접 연결할 수 있으며, 특정 branch (release/v2)로의 push 시 실행되도록 구성할 수 있습니다. Trigger가 실행되면 기존 cloudbuild.yaml을 실행하는데, 이 파일은 이미 container image를 빌드하고 Container Registry (gcr.io)에 push한 다음 gcloud run deploy를 사용해 Cloud Run에 배포하도록 되어 있습니다. 이는 가장 효율적이고 네이티브한 접근 방식입니다: 추가적인 glue service가 필요 없고, polling도 없으며, 수동 명령도 필요 없습니다. 주요 기능 / 구성 / Best Practices: - Cloud Build “Repository event” triggers는 branch filtering (예: ^release/v2$)을 지원하므로 의도한 release만 배포됩니다. - Trigger는 service account로 실행되므로 roles/run.admin 및 roles/iam.serviceAccountUser(Cloud Run 배포용)와 image push 권한(예: roles/storage.admin 또는 적절한 Artifact Registry/Container Registry 권한)이 있는지 확인하세요. - least privilege와 auditability(Architecture Framework: security 및 operations excellence)를 위해 전용 Cloud Build service account와 Cloud Audit Logs를 사용하세요. - 최신 best practices 및 regional repositories를 위해 Container Registry (gcr.io)에서 Artifact Registry로의 migration을 고려할 수 있지만, 이 문제를 푸는 데 필수는 아닙니다. 흔한 오해: Build를 “notify”하기 위해 Pub/Sub 또는 webhooks가 필요하다고 생각할 수 있지만, CSR은 이미 Cloud Build triggers와 통합되어 있습니다. Pub/Sub는 custom eventing pipeline이나 소스 시스템이 Google Cloud 외부에 있을 때 더 흔합니다. Webhooks는 repo가 Google Cloud 밖에 있거나 네이티브 통합을 사용할 수 없을 때 유용합니다. Exam Tips: “특정 branch에 push할 때마다 배포”가 보이고 repo가 CSR(또는 GitHub)에 있다면, 기본 정답은 거의 항상 branch filter가 있는 Cloud Build trigger입니다. 문제가 cross-system integration 또는 custom event routing을 명시적으로 요구하지 않는 한 polling(Cloud Scheduler)이나 불필요한 구성요소(Pub/Sub)를 추가하는 해법은 피하세요.

15
문제 15
(2개 선택)

You are rolling out an internal reporting service on a fleet of e2-standard-4 Compute Engine VMs in us-central1-a using Terraform; one VM restored from a snapshot has been stuck in 'Starting' for 12 minutes and the serial console shows repeated boot attempts—what two investigations should you prioritize to resolve the launch failure? (Choose two.)

정답입니다. serial console 출력과 함께 반복적인 부팅 시도는 OS 레벨의 부팅 실패를 강하게 시사합니다. snapshot에서 복원한 후 흔한 원인은 filesystem 불일치/손상(특히 소스 VM이 실행 중일 때 snapshot을 찍은 경우)입니다. boot disk를 rescue VM에 연결해 로그를 확인하고 fsck를 실행하는 것은 표준적이며 신호가 강한 조사 방법이고, Compute Engine 트러블슈팅 모범 사례와도 일치합니다.

오답입니다. VM이 “Starting”에 멈춰 반복적으로 재부팅된다면, OS는 sshd가 실행되고 로그인을 수락하는 안정적인 multi-user 상태에 도달하지 못했을 가능성이 큽니다. Linux username을 바꾸는 것은 bootloader/kernel/filesystem 실패를 해결하지 못합니다. SSH 트러블슈팅은 인스턴스가 RUNNING이고 serial console이 OS가 성공적으로 부팅되었음을 보여줄 때 적절합니다.

오답입니다. VPC firewall rule과 route는 인스턴스의 네트워크 연결성에 영향을 주지만, 게스트 OS의 부팅을 막지는 않습니다. VM은 네트워크 액세스가 전혀 없어도 완전히 부팅될 수 있습니다. 설명된 증상(serial console에 반복적인 부팅 시도가 보이고 인스턴스가 Starting에 머묾)은 routing 또는 firewall 구성보다는 디스크/OS 부팅 문제를 가리킵니다.

정답입니다. boot disk가 완전히 가득 차면 필수적인 부팅 시점 쓰기(로그, temp 파일, systemd 상태, cloud-init, package script)가 불가능해져 서비스가 실패하고 재부팅/부팅 루프를 유발할 수 있습니다. 10-GB boot disk는 비교적 작아 로그나 애플리케이션 산출물이 snapshot에 포함되면 용량이 찰 가능성이 커집니다. rescue attach로 disk usage를 확인하는 것은 우선순위가 높은 조사입니다.

오답입니다. 네트워크 트래픽 drop(firewall/policy)은 SSH 불가 또는 애플리케이션 접근 불가를 설명할 수 있지만, serial console에 표시되는 반복적인 부팅 시도나 VM이 “Starting”에 멈춘 상태를 설명하지는 못합니다. 네트워크 policy는 OS가 부팅되고 NIC가 구성된 이후에 동작하며, 일반적으로 kernel/init 실패나 재부팅 루프를 유발하지 않습니다.

문제 분석

핵심 개념: 이 시나리오는 Compute Engine VM 부팅 트러블슈팅, 특히 snapshot에서 복원한 후 발생하는 실패를 테스트합니다. 인스턴스가 “Starting”에 멈춰 있고 serial console에 반복적인 부팅 시도가 보인다면, 문제는 거의 항상 네트워킹이 아니라 게스트 OS 부팅 경로(디스크, filesystem, bootloader, init) 내부에 있습니다. serial console은 OS가 SSH나 에이전트가 시작되는 상태에 도달하지 못하더라도 동작하므로, 가장 중요한 신호입니다. 정답이 맞는 이유: A (root filesystem 손상)는 snapshot 복원 후 최우선으로 조사해야 하는 항목입니다. 소스 VM이 정상적으로 종료되지 않았거나 pending write가 남아 있는 상태에서 snapshot을 찍으면, 복원된 snapshot이 일관되지 않은 filesystem을 포함할 수 있습니다. 손상은 kernel panic, initramfs 진입, 또는 systemd 실패 및 루프 재부팅을 유발할 수 있으며, 이는 “반복적인 부팅 시도”와 일치합니다. 표준적인 조치는 boot disk를 분리/연결하여 정상적인 rescue VM에 붙인 뒤 로그를 확인하고 filesystem repair (fsck)를 실행하거나 백업에서 복구하는 것입니다. D (boot disk 용량 부족) 또한 부팅 루프의 가능성이 높은 원인입니다. root partition이 100% 가득 차면, 중요한 부팅 시점 쓰기(journald, systemd unit, package trigger, cloud-init, log rotation)가 실패하여 서비스 실패 및 watchdog/재부팅 동작으로 이어질 수 있습니다. 10-GB boot disk는 특히 내부 reporting 서비스가 로그나 cache를 쓸 수 있으므로 이 위험을 키웁니다. 주요 기능 / 모범 사례: serial console 출력과 “get-serial-port-output”을 사용해 실패 단계가 어디인지 정확히 파악합니다. rescue 워크플로우를 사용하세요: VM을 중지하고, boot disk를 분리한 다음, 다른 VM에 연결하고, 먼저 read-only로 mount하여 여유 공간을 확인하고, fsck를 실행하며, /var/log 및 journal 파일을 검토합니다. 더 큰 boot disk 또는 별도의 data disk를 선호하고, snapshotting 전에 clean shutdown을 보장하며, filesystem 유형과 journaling을 고려합니다. 흔한 오해: 네트워킹/firewall 문제(C/E)는 SSH 및 애플리케이션 트래픽을 막을 수는 있지만 VM 부팅 자체를 막지는 않습니다. 부팅 루프와 함께 플랫폼 “Starting” 상태가 지속되는 현상은 dropped packet으로 설명되지 않습니다. 다른 SSH user를 시도하는 것(B)은 OS가 sshd startup에 도달하지 못한다면 무관합니다. 시험 팁: “Starting에 멈춤” + serial console 부팅 루프를 보면, 디스크/OS 무결성 점검(filesystem 손상, 디스크 full, 잘못된 fstab/UUID, bootloader)을 우선순위로 두세요. 네트워크 점검은 2순위이며, 주로 VM이 RUNNING인데 접근 불가할 때 적용됩니다. 증상을 계층에 매핑하세요: 플랫폼/부팅 vs 연결성 vs 애플리케이션.

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

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

16
문제 16

Your startup has a containerized Node.js 20 API for shipping rate calculations that must be accessible only to customers located within the European Union; traffic averages about 3,500 requests per minute from 09:00–21:00 CET and drops to near zero overnight; you are migrating this workload to Google Cloud and need uncaught exceptions and stack traces to appear in Error Reporting after the move; you want the lowest operational effort and to avoid paying for idle compute when there is no traffic. What should you do?

Cloud Run은 container를 위한 serverless 서비스로 자동으로 확장되며 scale to zero가 가능해 야간에 트래픽이 줄어들 때 비용을 최소화합니다. europe-west1에 배포하면 EU regionality를 지원하고, Cloud Run은 기본적으로 stdout/stderr를 Cloud Logging으로 내보냅니다. stderr에 기록된(또는 ERROR severity로 로깅된) 미처리 Node.js 예외와 stack trace는 추가 구성 없이도 Error Reporting에서 최소한의 설정으로 수집됩니다.

Cloud Storage는 Error Reporting의 주요 통합 경로가 아닙니다. 로그를 bucket으로 스트리밍하면 운영 복잡도(로그 라우팅, lifecycle, parsing)가 증가하며 Error Reporting 이벤트를 자동으로 생성하지도 않습니다. 예외를 노출하려면 여전히 Cloud Logging 기반의 error 엔트리 또는 추가 처리가 필요합니다. Cloud Run은 compute 선택으로는 여전히 적절하지만, 로깅 접근 방식이 Error Reporting 모범 사례와 맞지 않습니다.

GKE Autopilot은 cluster 관리를 줄여주지만 여전히 Kubernetes 운영(deployment, service, policy)이 필요하고 보통 기본 비용이 발생합니다. 또한 HTTP API에 대해 전체 플랫폼을 자연스럽게 0으로 scale to zero하지는 않습니다. container의 stderr 로그가 Cloud Logging과 Error Reporting으로 전달될 수는 있지만, Cloud Run에 비해 “최소 운영 노력” 및 “유휴 compute 비용 회피” 요구사항을 위반합니다.

가장 운영 노력이 큰 옵션입니다: Kubernetes 리소스를 관리해야 하고, Cloud Storage로의 비표준 로깅 파이프라인까지 추가합니다. Error Reporting은 raw bucket 로그가 아니라 Cloud Logging(또는 지원되는 error event format)의 오류를 기대합니다. Autopilot cluster 오버헤드 비용과 상시 구성요소 비용을 지불하게 될 가능성이 높아, 일중 변동 트래픽과 비용 목표에 부합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 (1) EU 내에서만 접근/데이터 레지던시 요구사항을 강제하고, (2) 수요에 따라 확장되며 유휴 비용을 피하기 위해 scale to zero가 가능하고, (3) Cloud Logging 및 Error Reporting과 통합되어 미처리 예외/stack trace가 최소한의 운영 노력으로 캡처되는 serverless container 플랫폼을 선택하는지를 평가합니다. 정답이 맞는 이유: Cloud Run은 트래픽 변동이 매우 큰(업무 시간에는 분당 3,500 req, 야간에는 거의 0) containerized Node.js API에 가장 적합합니다. Cloud Run은 들어오는 요청에 따라 자동으로 scale out하며, 유휴 시에는 인스턴스를 0으로 scale to zero할 수 있어 유휴 compute 비용을 지불하지 않고 운영을 최소화해야 한다는 요구사항에 부합합니다. europe-west1 같은 EU region에 배포하면 EU data residency를 지원하며, 서비스를 regional로 유지하고 추가 접근 제어(예: IAM, load balancer 정책)를 활성화함으로써 cluster를 관리하지 않고도 “EU 내 고객만 접근 가능” 요구사항을 충족하는 데 도움이 됩니다. 주요 기능 / 구성: - Error Reporting 통합: Cloud Run은 stdout/stderr를 자동으로 Cloud Logging으로 내보냅니다. 미처리 예외와 stack trace를 stderr에 기록(또는 severity=ERROR인 structured logging 사용)하면 Error Reporting이 이를 그룹화하여 표시할 수 있습니다. - Scale-to-zero 및 요청 단위 과금: Cloud Run은 주로 요청 처리 중의 CPU/memory(및 설정된 minimum instances가 있다면 그에 대한 비용)에 대해 과금합니다. min instances를 0으로 두면 야간 비용을 피할 수 있습니다. - EU-only 접근: europe-west1에 배포하고 ingress(내부 및 Cloud Load Balancing)를 제한하며 identity 기반 접근(IAM)을 적용하고, 필요 시 edge에서 geo 기반 접근 제어(일반적으로 Cloud Armor geo 정책이 적용된 external HTTPS load balancer 사용)를 추가합니다. 핵심은 Cloud Run이 가장 낮은 운영 부담을 제공한다는 점입니다. 흔한 오해: 자주 빠지는 함정은 Error Reporting을 위해 로그를 Cloud Storage에 저장해야 한다고 가정하는 것입니다. Error Reporting은 bucket의 raw log 파일이 아니라 Cloud Logging 엔트리(및 지원되는 error event)에 의해 동작합니다. 또 다른 오해는 GKE Autopilot이 “완전 관리형이므로 Cloud Run과 운영 부담이 동일하다”는 생각입니다. Autopilot은 node 관리를 줄여주지만, 여전히 Kubernetes object, upgrade/rollout, 기본 cluster 비용을 관리해야 하며, 항상 켜져 있는 API에 대해 자연스럽게 scale to zero가 되지 않습니다. 시험 팁: “containerized web API”, “spiky/diurnal traffic”, “lowest operational effort”, “avoid paying for idle”를 보면 Kubernetes primitive에 대한 강한 요구사항이 없는 한 기본 선택은 Cloud Run입니다. Error Reporting은 다음을 기억하세요: 오류를 stderr(또는 ERROR severity의 structured log)로 기록하면 Cloud Logging이 자동으로 Error Reporting에 전달합니다.

17
문제 17

Your manufacturing analytics batch runs every 10 minutes from a containerized job on GKE that invokes the bq CLI in batch mode to execute a SQL file against the BigQuery dataset iot_agg in project alpha-logs, piping the CLI output to a downstream formatter process; the workload uses the node-attached service account gke-batch@factory-ops.iam.gserviceaccount.com, and the bq CLI intermittently fails with a permission error indicating the job cannot be created when the query runs. You need to resolve the permission issue without changing the query logic or the piping behavior of the CLI output. What should you do?

정답입니다. bq를 통해 실행되는 BigQuery 쿼리는 job 생성 권한(bigquery.jobs.create)이 필요하며, 이는 프로젝트 수준의 BigQuery Job User로 부여됩니다. 또한 쿼리는 테이블/뷰에 대한 읽기 접근이 필요하며, 이는 BigQuery Data Viewer로 제공됩니다. 프로젝트 alpha-logs에서 두 역할을 모두 부여하면, 제시된 “job을 생성할 수 없음” 오류를 해결하고 데이터셋을 읽을 수 있도록 보장하며, 쿼리 로직이나 출력 파이핑을 변경할 필요가 없습니다.

오답입니다. 데이터셋에 대한 Data Editor와 Data Viewer는 데이터셋 객체에 대한 접근(읽기/쓰기)을 제어하지만 BigQuery job을 생성할 권한은 부여하지 않습니다. bq CLI는 여전히 쿼리 job을 제출해야 하며, 프로젝트에 roles/bigquery.jobUser(또는 동등한 역할)가 없으면 service account는 bigquery.jobs.create 권한 오류로 계속 실패할 수 있습니다.

오답입니다. 뷰를 생성해도 job 생성이 없어지지 않습니다. SELECT * FROM view를 실행하는 것 역시 BigQuery 쿼리 job으로 실행되며 bigquery.jobs.create가 여전히 필요합니다. 또한 운영 모델을 변경(관리형 객체 및 배포 라이프사이클 도입)하며, 뷰를 생성/관리하기 위한 추가 권한이 필요할 수 있는데, 이는 근본 원인을 해결하지 못합니다.

오답입니다. 데이터를 임시 데이터셋으로 복사하는 것은 비용, 복잡성, 운영 리스크(데이터 신선도, 중복, quota)를 증가시키는 아키텍처적 우회책입니다. 또한 job 생성 권한을 본질적으로 해결하지 못합니다. 임시 데이터셋에 대한 쿼리도 job이 실행되는 프로젝트에서 bigquery.jobs.create가 필요하므로, 동일한 권한 오류가 지속될 수 있습니다.

문제 분석

핵심 개념: 이 문제는 BigQuery IAM 권한을 (1) 데이터 읽기(데이터셋/테이블 접근)와 (2) 쿼리 job 생성/실행(프로젝트 수준 job 생성)으로 분리해서 이해하는지를 테스트합니다. bq CLI는 출력이 stdout으로 스트리밍되어 다른 프로세스로 파이프되더라도, 쿼리에 대해 항상 BigQuery job을 제출합니다. 정답이 맞는 이유: 오류는 job을 생성할 수 없음을 나타냅니다. BigQuery에서 쿼리 job을 생성하는 권한은 bigquery.jobs.create로 제어되며, 일반적으로 job이 생성/과금되는 프로젝트 수준에서 roles/bigquery.jobUser (BigQuery Job User)를 통해 부여됩니다. 별도로, 쿼리는 참조하는 테이블/뷰에 대한 읽기 권한이 필요하며, 이는 보통 데이터셋에 roles/bigquery.dataViewer로 부여합니다. 프로젝트 alpha-logs에서 BigQuery Job User와 BigQuery Data Viewer를 모두 부여하면 GKE 노드에 연결된 service account가 (a) 쿼리 job을 생성하고 (b) iot_agg 데이터셋 객체를 읽을 수 있어, 쿼리 로직이나 CLI 파이핑 동작을 변경하지 않고도 문제를 해결합니다. 주요 기능 / 모범 사례: - BigQuery job 생성은 프로젝트 범위입니다. 데이터셋 역할만으로는 job 제출 권한이 부여되지 않습니다. - 최소 권한: 많은 설계에서 프로젝트에는 Job User를, 데이터셋에는 Data Viewer를 부여합니다. 하지만 제시된 선택지 중 job 생성과 데이터 접근을 모두 확실히 해결하는 것은 프로젝트 수준의 Job User + Data Viewer입니다. - GKE에서는 workload identity/credential 경로가 일관적인지 확인하세요. 간헐적인 권한 오류는 일부 pod/node가 서로 다른 identity를 사용할 때 자주 나타납니다. 다만, 제시된 오류는 구체적으로 job 생성 권한에 관한 것입니다. - Google Cloud Architecture Framework 보안 원칙과 정렬됩니다: 런타임 identity에 필요한 권한만 부여하고, IAM을 우회하기 위해 데이터 흐름을 재설계하는 것을 피합니다. 흔한 오해: - 데이터셋 수준 권한만 있으면 쿼리를 실행할 수 있다고 가정하는 것. 그렇지 않습니다. job 생성 권한도 필요합니다. - 뷰나 다른 데이터셋을 사용해 “job을 피하려고” 시도하는 것. 쿼리는 여전히 job으로 실행되며, 뷰도 bigquery.jobs.create 필요성을 제거하지 못합니다. 시험 팁: “Access Denied: User does not have bigquery.jobs.create permission” 같은 BigQuery 오류를 보면, 과금/job 프로젝트에 BigQuery Job User를 추가해야 한다고 생각하세요. 테이블/데이터셋에 대한 “Access Denied”를 보면, 데이터셋에 Data Viewer(읽기) 또는 Data Editor(쓰기)를 떠올리세요. job 권한(프로젝트)과 데이터 권한(데이터셋)을 구분하세요.

18
문제 18

You are building an external review portal for a film festival that stores high‑bitrate video dailies in Cloud Storage, and you must let reviewers—some of whom do not have Google accounts—securely access only their assigned files with the ability to read, upload replacements, or delete them for a strict 24-hour window; how should you provide access to the objects?

정답입니다. V4 signed URL을 사용하면 검토자가 Google account로 인증할 필요 없이 애플리케이션이 특정 Cloud Storage object에 대한 임시 액세스를 부여할 수 있습니다. 이는 외부 사용자에 대한 요구 사항과 일치하며, 할당된 파일에 대해서만 URL을 생성함으로써 최소 권한 액세스를 지원합니다. 24시간 만료도 지원되므로, 이 시나리오에서 안전하고 시간 제한이 있는 object 액세스를 위한 가장 적합한 방법은 signed URL입니다.

오답입니다. Service Account Token Creator를 부여하면 impersonation이 가능해지며, 이는 외부 사용자에게는 강력하고 위험합니다. 권한 구성에 따라 검토자가 credential을 획득하고 할당된 객체를 넘어서는 액세스를 할 수 있는 경로를 사실상 제공할 수 있습니다. 또한 검토자가 Google IAM 기반 flow와 identity를 사용할 수 있다는 전제를 깔고 있어 “일부는 Google account가 없다”는 조건과 충돌하며, 최소 권한에도 부합하지 않습니다.

오답입니다. 외부 검토자에게 service account key를 배포하는 것은 중대한 보안 anti-pattern입니다. 키는 복사, 재사용, 유출(exfiltration)될 수 있습니다. 또한 service account key는 암시된 것처럼 “24시간 후 만료”를 기본적으로 지원하지 않으며, 키를 수동으로 rotation/delete해야 합니다. 이 접근은 광범위한 액세스를 부여하고 credential management 모범 사례를 위반합니다.

오답입니다. IAM role(만료되는 IAM Conditions가 있더라도)은 principal identity에 대한 binding이 필요합니다. Google account가 없는 검토자에게는 bucket에 Storage Object User를 직접 부여할 수 없습니다. 또한 bucket 수준 role 할당은 복잡한 conditional logic을 결합하지 않는 한 객체별 액세스보다 범위가 넓습니다. signed URLs가 객체 수준의 시간 제한 외부 액세스에 더 단순하고 정밀합니다.

문제 분석

핵심 개념: 이 문제는 Google identity가 없을 수 있는 외부 사용자에게 Cloud Storage object에 대한 안전한 시간 제한 액세스를 제공하는 방법을 테스트합니다. 핵심 개념은 Cloud Storage signed URL을 사용하여 최종 사용자에게 직접 IAM permission을 부여하지 않고도 특정 object에 대한 임시 액세스를 위임하는 것입니다. 정답인 이유: 일부 검토자는 Google account가 없으므로 IAM role binding은 적절한 방법이 아닙니다. Signed URL을 사용하면 애플리케이션이 제한된 시간 동안 개별 object에 대한 액세스를 부여할 수 있으며, 이는 각 검토자가 24시간 동안 자신에게 할당된 파일에만 액세스하도록 제한해야 한다는 요구 사항과 일치합니다. 이것은 Cloud Storage object에 대한 임시 외부 액세스를 위한 표준 Google Cloud 패턴입니다. 주요 기능 / 모범 사례: - Google authentication을 요구하지 않고 임시 object 액세스를 제공하기 위해 24시간 만료의 V4 signed URL을 사용합니다. - Object별로 URL을 생성하여 각 검토자가 자신에게 할당된 파일에만 액세스할 수 있도록 합니다. - Object retrieval 및 upload에 signed URL을 사용하고, service account key나 광범위한 IAM permission을 배포하는 것은 피합니다. - 장기 key를 export하는 대신 관리형 service account credential을 사용한 애플리케이션 제어 signing을 선호합니다. 일반적인 오해: 흔한 함정은 IAM Conditions가 모든 임시 액세스 문제를 해결한다고 가정하는 것입니다. 하지만 여전히 유효한 principal identity가 필요합니다. 또 다른 오해는 service account credential을 공유하는 것이 외부 액세스를 위한 허용 가능한 지름길이라는 생각인데, 실제로는 중대한 보안 위험입니다. 또한 요구 사항이 object별 위임일 때는 bucket 수준 IAM이 보통 너무 광범위합니다. 시험 팁: 문제에서 Google account가 없는 외부 사용자와 Cloud Storage에 대한 임시 액세스가 언급되면, signed URL이 보통 가장 좋은 정답입니다. 최소 권한, object 수준 범위, 단기 액세스에 집중하세요. Credential 배포나 외부 당사자에게 광범위한 IAM role을 할당해야 하는 선택지는 제거하세요.

19
문제 19

Your startup manages 3,000 smart vending machines that publish 4 KB JSON telemetry to a Pub/Sub topic at an average rate of 600 messages per second (peaks up to 1,200). You must parse each message and persist it for analytics with end-to-end latency under 45 seconds, and each message must be processed exactly once to avoid double-counting transactions. You want the cheapest and simplest fully managed approach with minimal operations overhead and cannot maintain clusters or build custom deduplication workflows. What should you do?

반복 Dataproc job은 배치 지향이며, 매우 엄격한 <45초 end-to-end 지연 시간 SLA를 충족하려면 극도로 자주 실행해야 하는데 이는 비용과 복잡도를 증가시킵니다. Dataproc는(일시적이라 하더라도) 클러스터 관리가 수반되어 “클러스터를 유지할 수 없다”는 조건과 충돌합니다. 또한 Pub/Sub에서 배치로 pull하는 방식은 offset 관리와 exactly-once 보장을 추가 상태 처리 없이 달성하기 어렵게 만들 수 있습니다.

Dataflow streaming은 완전 관리형이며 autoscaling을 지원하고, 낮은 지연 시간으로 Pub/Sub 수집을 처리하도록 설계되었습니다. Apache Beam의 PubsubIO가 깔끔하게 통합되며, Dataflow는 checkpointing을 통한 fault tolerance를 제공하므로 파이프라인 내에서 메시지가 중복 집계되지 않습니다. Cloud Storage로의 windowed writes는 운영 오버헤드를 낮게 유지하면서 효율적인 downstream 분석 워크플로를 지원하고 45초 지연 시간 요구사항을 충족합니다.

Pub/Sub 트리거 Cloud Functions는 at-least-once delivery를 제공하므로 retry, timeout, transient error 동안 중복이 발생할 수 있습니다. 따라서 Functions에서 BigQuery로 직접 쓰면 idempotency 또는 deduplication을 구현하지 않는 한 중복 집계가 발생할 수 있습니다. 이 선택지는 daily dedup query에 명시적으로 의존하는데, 이는 “exactly once” 요구사항을 위반하며 분석의 <45초 end-to-end 정확성 요구사항도 충족하지 못합니다.

이 설계는 불필요한 복잡성과 운영 오버헤드를 추가합니다. Bigtable에 기록한 뒤 두 번째 스트리밍 파이프라인을 실행해 중복을 제거하는 것은 문제에서 금지한 커스텀 deduplication 워크플로에 해당합니다. 또한 비용(Bigtable 인스턴스 + 두 개의 파이프라인)을 증가시키고 더 많은 장애 지점과 지연 시간을 유발합니다. Dataflow는 이러한 2단계 접근 없이 exactly-once 처리를 수행할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 낮은 지연 시간 SLA와 exactly-once 처리 시맨틱을 만족하는 완전 관리형 스트리밍 수집 및 처리 아키텍처를 선택하는지를 평가합니다. 핵심 서비스는 수집을 위한 Pub/Sub와 관리형 스트림 처리를 위한 Dataflow (Apache Beam), 그리고 분석용 sink입니다. 정답이 맞는 이유: Pub/Sub에서 읽고 윈도우 기반 출력을 Cloud Storage에 쓰는 Dataflow 스트리밍 파이프라인은 선택지 중 <45초 end-to-end 지연 시간 요구사항을 충족하면서 파이프라인 내 exactly-once 처리 보장을 제공할 수 있는 가장 단순한 완전 관리형 옵션입니다. Dataflow는 checkpointing, autoscaling, fault-tolerant 처리를 제공합니다. 소스로 Pub/Sub를 사용할 때 Dataflow는 각 메시지가 파이프라인에서 한 번만 처리되도록 보장할 수 있으며(커스텀 dedup 워크플로 불필요), downstream 분석을 위해 Cloud Storage에 결정적인(deterministic) 윈도우 파일을 생성할 수 있습니다(예: BigQuery로 배치 로드 또는 Dataproc Serverless/BigQuery external tables를 통한 처리). 핵심 기능 / 구성 / 모범 사례: - Pub/Sub 소스를 사용하는 Dataflow streaming을 사용하고 효율성을 위해 streaming engine을 활성화합니다. - event-time 처리를 fixed windows(예: 1-minute)와 함께 사용하고, 디바이스 clock skew에 맞는 allowed lateness를 설정합니다. - Cloud Storage에는 windowed writes(예: file-per-window + sharding)로 기록하여 파일 크기를 적절히 유지하고 small-file 문제를 방지합니다. - 피크 트래픽 기준 sizing: 1,200 msg/s * 4 KB ≈ 4.8 MB/s로 Pub/Sub 및 Dataflow 처리량 범위 내이며, Dataflow autoscaling이 burst를 처리합니다. - Exactly-once: Dataflow의 checkpointing과 replay 처리로 파이프라인 내 중복 처리를 방지합니다. sink가 idempotency를 지원하지 않는 한 non-idempotent side effects는 피합니다. 흔한 오해: - “Cloud Functions가 더 단순하다”: 운영 측면에서는 단순하지만, Pub/Sub 트리거 함수는 exactly-once를 보장하지 않습니다(at-least-once delivery). 따라서 deduplicate가 필요하며, 이는 문제에서 금지합니다. - “Dataproc job이 더 저렴하다”: 반복 배치 job은 지연 시간을 증가시키고 클러스터 운영(또는 최소한 job orchestration)이 필요하며, 45초 스트리밍 SLA를 자연스럽게 만족하지 못합니다. - “Bigtable을 쓰고 나중에 dedupe한다”: 추가 파이프라인과 커스텀 dedup 로직을 도입하게 되어, 최소 운영 및 커스텀 dedup 워크플로 금지 요구사항을 위반합니다. 시험 팁: - Pub/Sub 스트리밍에서 낮은 지연 시간과 최소 운영이 요구되면 기본 선택은 Dataflow입니다. - 요구사항에 “exactly once”가 있고 커스텀 dedup를 금지하면, sink가 본질적으로 idempotent이고 설계에서 unique keys를 명시적으로 사용하는 경우가 아니라면 Cloud Functions/Cloud Run consumer는 피합니다. - 요구사항을 Google Cloud Architecture Framework에 매핑하세요: operational excellence(관리형 서비스), reliability(checkpointing/retries), performance(autoscaling), cost(always-on 클러스터 회피).

20
문제 20

Your CI pipeline runs 200 unit tests per commit for a fleet-management analytics service that consumes messages from a Cloud Pub/Sub topic named 'telemetry' using ordering keys set to vehicle_id; for each test you need to publish a sequence of 50 messages for a single vehicle_id and assert that your subscriber processes them strictly in order within the key, while keeping the tests reliable, fast, and at zero additional GCP cost; what should you do?

커스텀 mocking framework는 Pub/Sub semantics(ordering keys, redelivery, ack deadlines, flow control, concurrency effects)를 정확히 재현하기가 매우 어렵기 때문에 위험합니다. 이런 mocks는 실제 동작과 달라져 테스트는 통과하지만 프로덕션에서는 실패하는 상황을 만들 수 있습니다. 또한 유지보수 부담을 늘리며, 공식 emulator가 존재하는 managed services 테스트 모범 사례에도 부합하지 않습니다.

테스터별로 전용 topic과 subscription을 만들면 간섭을 줄일 수는 있지만, 운영 오버헤드(리소스 생성/정리, IAM, quotas)를 추가하고 실제 서비스 의존성 때문에 여전히 flaky할 수 있습니다. 또한 Pub/Sub 사용량(publish/deliver operations, storage)은 과금 대상이므로 “추가 GCP 비용 0” 요구사항을 위반하며, 많은 CI 실행으로 확장하면 비용이 커질 수 있습니다.

Subscription filters는 tester_id로 메시지를 격리할 수 있지만, 비용이나 외부 의존성을 제거하지는 못합니다. 여전히 publishing과 delivery attempts에 비용을 지불해야 하며, filters는 복잡성(모든 메시지에 올바른 attributes 보장, filter expressions 관리)을 추가합니다. 또한 filters는 shared infrastructure, 병렬 테스트 경쟁, CI에서의 일시적인 Pub/Sub 서비스 동작으로 인한 flakiness를 완전히 방지하지 못합니다.

로컬 Cloud Pub/Sub emulator는 GCP 과금 없이 개발 및 테스트를 수행하도록 설계되었습니다. 네트워크 및 managed-service 변동성을 제거하여 CI에서 신뢰성과 속도를 높이는 격리된 환경을 제공합니다. “신뢰성, 속도, 추가 GCP 비용 0” 요구사항에 가장 잘 부합하면서도 실제 client libraries와 subscriber의 ordering-key 로직을 그대로 검증할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 message ordering keys에 의존하는 Pub/Sub consumer에 대해 신뢰할 수 있고, 빠르며, 비용이 들지 않는 자동화 테스트를 구축하는 방법을 평가합니다. Pub/Sub ordering 보장은 미묘합니다(정렬은 ordering key별로 적용되며, topic에서 message ordering이 활성화되어야 하고, 서비스에 의해 강제됨). 따라서 테스트는 flaky한 네트워크/서비스 의존성을 도입하지 않으면서 동작을 검증해야 합니다. 정답이 맞는 이유: 로컬 Cloud Pub/Sub emulator를 대상으로 unit tests를 실행하면 GCP 과금 없이 지연이 최소인, 결정적이고 격리된 환경을 제공합니다. shared-project 간섭(다른 CI job이 동일한 topic에 publish) 을 피하고, 일시적인 서비스 throttling, IAM 전파 지연, 리전 네트워크 변동성과 같은 외부 요인을 제거하여 CI 테스트가 flaky해지는 것을 방지합니다. 커밋당 200개의 테스트를 실행하는 CI pipeline에서 emulator는 실행을 빠르고 반복 가능하게 유지하면서도 publisher/subscriber 통합 로직과 ordering-key 처리까지 실제로 검증할 수 있습니다. 주요 기능 / 모범 사례: - Pub/Sub emulator는 로컬(또는 CI container)에서 실행되며 Pub/Sub 사용 비용이 발생하지 않습니다. - hermetic tests를 가능하게 합니다: 각 테스트는 자체 topic/subscription 이름을 만들고, 단일 vehicle_id ordering key에 대해 50개의 메시지를 publish한 뒤 subscriber가 이를 순서대로 처리하는지 assert할 수 있습니다. - Google Cloud Architecture Framework 원칙과 부합합니다: reliability(반복 가능한 테스트), operational excellence(자동화된 CI), cost optimization(추가 비용 0). - 실무적 접근: 테스트 실행마다 고유한 리소스 이름을 사용해 cross-test contamination을 방지하고, key 내 ordering을 검증하기 위해 acknowledgments와 subscriber concurrency를 제어합니다. 흔한 오해: 실제 Pub/Sub에서 별도의 topics/subscriptions 또는 filters로 트래픽을 격리하고 싶을 수 있지만, 이는 여전히 비용이 들고 리소스 관리 오버헤드를 추가하며 병렬 CI에서는 flaky할 수 있습니다. 또 다른 함정은 커스텀 mocks를 만드는 것입니다. 이는 Pub/Sub의 실제 semantics(redelivery, ack deadlines, flow control, ordering behavior)를 거의 정확히 맞추지 못해 잘못된 확신을 낳기 쉽습니다. 시험 팁: 문제가 Pub/Sub 테스트에 대해 “신뢰성, 속도, 추가 GCP 비용 0”을 강조하면 emulator가 정석적인 선택입니다. CI의 unit/integration tests에는 emulator를 우선하고, 실제 Pub/Sub는 더 적은 수의 end-to-end 테스트에만 사용하세요. 또한 ordering은 ordering key 내에서만 보장되며 올바른 client configuration과 subscriber 처리 패턴에 달려 있다는 점을 기억하세요.

합격 후기(6)

V
V***********Nov 24, 2025

학습 기간: 2 months

The scenarios in this app were extremely useful. The explanations made even the tricky deployment questions easy to understand. Definitely worth using.

B
B************Nov 21, 2025

학습 기간: 2 months

The questions weren’t just easy recalls — they taught me how to approach real developer scenarios. I passed this week thanks to these practice sets.

철
철**Nov 17, 2025

학습 기간: 1 month

1개월 구독하니 빠르게 풀어야 한다는 강박이 생기면서 더 열심히 공부하게 됐던거 같아요. 다행히 문제들이 비슷해서 쉽게 풀 수 있었네요

이
이**Nov 15, 2025

학습 기간: 1 month

이 앱의 문제들과 실제 시험 문제들이 많이 비슷해서 쉽게 풀었어요! 첫 시험만에 합격하니 좋네요 굿굿

R
R***********Nov 6, 2025

학습 기간: 1 month

I prepared for three weeks using Cloud Pass and the improvement was huge. The difficulty level was close to the real Cloud Developer exam, and the explanations helped me fill in my knowledge gaps quickly.

모의고사

Practice Test #1

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

Practice Test #2

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

Practice Test #3

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

Practice Test #4

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 Architect

Google Professional Cloud Architect

Professional

Google Professional Cloud Database Engineer

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Google Professional Data Engineer

Professional

Google Professional Machine Learning Engineer

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

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

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.