CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Professional Cloud Developer
Google Professional Cloud Developer

Practice Test #3

50개 문제와 120분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

50문제120분700/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

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 호환성에 초점을 둡니다.

2
문제 2

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 접근 패턴으로는 보지 마세요.

3
문제 3
(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 애플리케이션.

4
문제 4

You are building a Rust-based microservice for a logistics analytics platform on Google Cloud that must be packaged as a container image; the service links against two in-house native .so libraries and requires OpenSSL 1.1 during build, exposes HTTP on port 8080, must autoscale from 0 instances to handle bursts up to 400 requests per second, and needs cold starts under 2 seconds; your team does not want to provision, patch, or manage any servers or clusters. How should you deploy the microservice?

Cloud Functions는 서버리스이며 오토스케일링이 가능하지만, 주로 이벤트/함수 중심이고 역사적으로 런타임과 패키징에 제약이 있었습니다. 최신 컨테이너 지원이 있더라도, 문제는 네이티브 .so 라이브러리와 OpenSSL 1.1 빌드 요구사항을 가진 컨테이너화된 마이크로서비스를 명시하고 있으며, 이는 Cloud Run의 “run any container” 모델과 HTTP 서비스 시맨틱(8080 포트, 요청 라우팅, concurrency 제어)에 더 자연스럽게 부합합니다.

Cloud Build는 빌드 중 OpenSSL 1.1을 설치하고 사내 .so 라이브러리를 링크/복사하는 Dockerfile을 사용해 커스텀 컨테이너 이미지를 빌드할 수 있습니다. 해당 이미지를 Cloud Run에 배포하면 요구사항을 충족합니다: 완전 관리형(서버/클러스터 없음), 8080 포트의 HTTP, 0에서 오토스케일링, 버스트를 처리하기 위한 빠른 수평 확장(concurrency와 max instances 구성). 콜드 스타트는 이미지 크기와 런타임 튜닝으로 최적화할 수 있습니다.

Compute Engine에서 Container-Optimized OS VM은 컨테이너를 실행할 수 있지만, 여전히 VM 프로비저닝 및 관리(패치 전략, 인스턴스 그룹, 오토스케일링 구성, OS 라이프사이클, 모니터링, 용량 계획)가 필요합니다. 또한 추가 오케스트레이션 없이는 자연스럽게 0까지 스케일되지 않으며, 일반적으로 Cloud Run보다 운영 반복 속도가 느립니다. 이는 “서버를 관리하고 싶지 않다” 요구사항을 위반합니다.

GKE는 강력한 컨테이너 오케스트레이션을 제공하지만, (Autopilot 모드에서도) 클러스터 관리 오버헤드(노드 풀, 업그레이드, 패치, 스케일링, 네트워킹 정책)를 도입합니다. GKE도 오토스케일링이 가능하지만, HTTP 서비스에 대해 0까지 스케일하고 일관되게 낮은 콜드 스타트를 달성하는 것은 더 복잡하며 보통 Knative/KEDA 패턴이 필요합니다. 문제는 클러스터 관리를 피하라고 명시하므로 Cloud Run이 더 적합합니다.

문제 분석

핵심 개념: 이 문제는 HTTP 마이크로서비스를 지원하고, 0까지 스케일하며, 서버/클러스터 관리를 피할 수 있는 완전 관리형 컨테이너 기반 컴퓨팅 플랫폼을 선택하는지를 평가합니다. 핵심 서비스는 Cloud Build( OpenSSL 1.1 및 네이티브 .so 라이브러리 같은 커스텀 빌드 의존성이 포함된 컨테이너 이미지를 빌드)와 Cloud Run(서버리스로 컨테이너를 실행하며 오토스케일링 지원)입니다. 정답이 맞는 이유: Cloud Run은 상태 비저장(stateless) HTTP 컨테이너를 위해 설계되었고, 단일 HTTP 포트(기본 8080)를 노출하며, 들어오는 요청에 따라 0 인스턴스에서 다수 인스턴스로 오토스케일링할 수 있습니다. Google이 기반 인프라를 관리하므로 “프로비저닝/패치/관리할 서버나 클러스터가 없음” 요구사항을 충족합니다. Cloud Build를 사용하면 빌드 단계에서 OpenSSL 1.1을 설치하고 사내 .so 라이브러리를 복사/링크하는 Dockerfile을 정의하여 배포 가능한 컨테이너 이미지를 만들 수 있습니다. 최대 약 400 RPS 수준의 버스트에 대해 Cloud Run은 수평 확장이 가능하며, 처리량과 지연 시간 목표를 맞추기 위해 concurrency와 max instances를 튜닝합니다. 주요 기능 / 구성: - Cloud Run: scale-to-zero, 요청 기반 오토스케일링, 구성 가능한 concurrency(인스턴스당 요청 수), min instances(scale-to-zero를 위해 0으로 설정), max instances, CPU/메모리 사이징. - 콜드 스타트: 적절한 CPU/메모리를 선택하고(멀티 스테이지 빌드로) 컨테이너를 가볍게 유지하며 Rust 시작 시간을 최적화합니다. 모든 조건에서 엄격한 2초 미만을 달성하기 어렵다면 Cloud Run “startup CPU boost” 및/또는 작은 min instances 값을 고려할 수 있습니다(다만 이는 “0에서 시작”과 충돌). - Cloud Build: 재현 가능한 빌드, 프라이빗 의존성, Artifact Registry 통합, CI 트리거. - Architecture Framework 정렬: 운영 우수성(관리형 플랫폼), 신뢰성(오토스케일링), 성능(적정 사이징, concurrency), 보안(Artifact Registry, IAM). 흔한 오해: Cloud Functions는 서버리스이지만 네이티브 공유 라이브러리와 특정 빌드 타임 의존성을 포함한 커스텀 컨테이너를 패키징해 실행해야 하는 경우에는 이상적이지 않습니다. 최신 세대에서 컨테이너를 지원하더라도, 문제에서 강조하는 컨테이너화된 마이크로서비스와 네이티브 링크 요구사항은 Cloud Run에 더 직접적으로 부합합니다. GKE/Compute Engine은 컨테이너를 실행할 수 있지만 클러스터/VM 관리, 패치, 용량 계획이 필요하며 이는 명시적으로 허용되지 않습니다. 시험 팁: “container image”, “HTTP on 8080”, “scale to zero”, “no server/cluster management”를 보면 기본 선택은 Cloud Run입니다. 커스텀 빌드 단계나 네이티브 의존성이 필요하면 Cloud Build(및 Artifact Registry)와 함께 묶어 설명하세요. RPS 스케일링을 위해 concurrency/max instances를 항상 언급하고, scale-to-zero와 콜드 스타트 간 트레이드오프도 함께 언급하세요.

5
문제 5

You inherit a public-facing marketing microsite hosted on a managed instance group of 3 Compute Engine VMs behind an external HTTPS load balancer (https://promo.example.com), and before a campaign launch you must automatically crawl up to 500 pages to verify whether any bundled client-side libraries have known vulnerabilities and whether the site is susceptible to reflected or stored XSS; which Google Cloud service should you use to run this security scan and generate a findings report?

Google Cloud Armor는 Cloud Load Balancing 뒤의 애플리케이션을 위한 보안 enforcement 서비스(WAF 및 DDoS 보호)입니다. preconfigured WAF rules(예: OWASP CRS), custom rules, rate limiting을 사용해 위협을 완화하는 데 도움이 됩니다. 그러나 사이트를 크롤링하거나 active scanning으로부터 취약점 findings report를 생성하지는 않습니다. 이는 발견/평가가 아니라 예방 및 완화를 위한 서비스입니다.

Cloud Debugger(Cloud Operations의 일부)는 앱을 중단하지 않고 snapshots를 캡처하고 logpoints를 추가하여 프로덕션에서 애플리케이션 상태를 검사하는 데 도움을 줍니다. 이는 코드 이슈를 트러블슈팅하고 디버깅하는 데 사용되며, 보안 스캐닝을 위한 것이 아닙니다. 웹 페이지를 크롤링하지도, XSS를 테스트하지도, 취약한 client-side libraries를 보고하지도 않습니다.

Web Security Scanner는 웹 애플리케이션을 크롤링하고 reflected 및 stored XSS를 포함한 일반적인 취약점을 스캔하는 Google Cloud의 DAST 솔루션입니다. HTTPS load balancer URL과 같은 public endpoint를 대상으로 실행하도록 설계되어 있으며, 구조화된 findings report를 생성합니다. 이는 출시 전에 수백 페이지까지 자동으로 크롤링하고 보안 findings report를 생성해야 한다는 요구사항과 직접적으로 일치합니다.

Error Reporting은 애플리케이션 오류/예외를 집계하고 그룹화하며, 개발자가 수정 우선순위를 정할 수 있도록 알림과 대시보드를 제공합니다. 이는 신뢰성과 프로덕션 이슈 디버깅에 유용하지만, 웹 취약점 스캐닝을 수행하지 않고, 페이지를 크롤링하지 않으며, XSS 노출이나 취약한 client-side libraries를 평가하지도 않습니다.

문제 분석

핵심 개념: 이 문제는 웹 앱을 위한 Google Cloud의 애플리케이션 보안 테스트 도구, 특히 사이트를 크롤링하고 XSS와 같은 일반적인 웹 취약점을 점검하는 dynamic application security testing (DAST)에 대한 지식을 평가합니다. 정답이 맞는 이유: Web Security Scanner는 공개 웹 애플리케이션(외부 HTTPS Load Balancer 뒤에 있는 애플리케이션 포함)을 자동으로 크롤링하고 취약점을 스캔하도록 설계된 Google Cloud 서비스입니다. 구성된 한도까지 크롤링할 수 있으며(문제에서는 최대 500페이지 언급), reflected 및 stored cross-site scripting (XSS)와 (스캐너의 점검으로 탐지 가능한 경우) 취약한 client-side libraries 사용과 같은 이슈를 식별하는 findings report를 생성합니다. 이는 캠페인 출시 전에 페이지를 “자동으로 크롤링”하고 “findings report를 생성”해야 한다는 요구사항과 일치합니다. 주요 기능 / 사용 방법: scan target(예: https://promo.example.com)을 구성하고, 필요 시 authentication을 설정하며(여기서는 public-facing이므로 필요 없음), 최대 crawl depth/limits를 정의한 뒤, 스캔을 예약하거나 필요 시 실행합니다. Findings는 Web Security Scanner UI에 보고되며, Security Command Center 통합 또는 API를 통해 내보내거나 활용하여 추적 및 remediation 워크플로에 사용할 수 있습니다. Architecture Framework 관점에서 이는 트래픽 급증 전에 악용 가능한 이슈를 선제적으로 식별함으로써 Security, Reliability, Operational Excellence pillar를 지원합니다. 자주 하는 오해: Cloud Armor는 종종 “scanner”로 혼동되지만, 취약점 발견 도구가 아니라 보호/제어 플레인(WAF, DDoS 방어)입니다. Debugger와 Error Reporting은 observability 도구로, 코드 동작과 크래시를 진단하는 데 도움을 주지만 보안 상태를 평가하는 도구는 아닙니다. “crawl pages”와 “scan for XSS”라는 핵심 문구는 Web Security Scanner를 직접적으로 가리킵니다. 시험 팁: Professional Cloud Developer 시험에서는 요구사항을 서비스 목적에 매핑하세요: OWASP 스타일의 웹 취약점에 대한 scanning/crawling → Web Security Scanner (DAST). 엣지에서 공격을 차단/완화 → Cloud Armor. 재배포 없이 코드 수준 트러블슈팅 → Debugger. 예외 및 stack traces 집계 → Error Reporting. 또한 Web Security Scanner는 외부에서 접근 가능한 앱을 대상으로 하며, 내부 전용 앱은 일반적으로 다른 접근(예: private scanning 구성 또는 third-party tools)이 필요하다는 점도 유의하세요.

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

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

6
문제 6

You operate a Python microservice on Cloud Run in us-central1 that writes time-series telemetry to Firestore (Native mode) and must sustain 8,000 document writes per minute with p95 write latency under 40 ms while using Application Default Credentials, retries with backoff, deadlines, and connection pooling per Google best practices. To optimize performance and minimize boilerplate, how should the service write to Firestore?

Cloud Client Libraries는 Python에서 Firestore에 대한 권장 접근 방식입니다. Cloud Run에서 ADC와 매끄럽게 통합되고, 최적화된 전송(일반적으로 gRPC)을 사용하며, Google 모범 사례와 일치하는 내장 재시도 및 타임아웃 제어를 제공합니다. 또한 보일러플레이트를 줄이면서 성능 튜닝(클라이언트 재사용, 배칭, 동시성)을 가능하게 합니다. 이는 낮은 p95 지연 시간과 지속적인 write 처리량 요구사항에 가장 잘 부합합니다.

Google API Client Libraries는 더 범용적이며 종종 discovery 기반 API를 사용하는 REST/HTTP 중심입니다. ADC로 인증할 수는 있지만, Firestore 전용 Cloud Client Libraries와 동일한 재시도, 데드라인, 커넥션 재사용 동작을 달성하려면 보통 더 많은 수동 구성이 필요합니다. Firestore 성능에 민감한 워크로드에서는 불필요한 보일러플레이트를 추가하며 최적의 지연 시간 특성을 제공하지 못할 수 있습니다.

커스텀 gRPC 클라이언트는 이론적으로 높은 성능을 낼 수 있지만, 구현 복잡성과 위험을 크게 증가시킵니다. 인증(ADC 토큰 처리), 올바른 멱등성 시맨틱을 갖춘 재시도, 데드라인, 채널 풀링, 에러 처리를 정확히 구현해야 합니다. 이는 보일러플레이트를 최소화해야 한다는 요구사항에 반하며, 시험 시나리오에서는 공식 라이브러리에 없는 기능이 필요한 경우가 아니라면 권장 접근이 아닙니다.

서드파티 HTTP 클라이언트 라이브러리는 Firestore API 호출, 인증, 재시도/백오프, 데드라인, 커넥션 풀링을 수동으로 구현해야 합니다. 재시도 동작을 잘못 구현하기 쉽고(예: 멱등하지 않은 write를 재시도), Google이 권장하는 클라이언트 구성을 놓치기 쉽습니다. 이 선택지는 보일러플레이트와 운영 리스크를 증가시키며, 일관된 저지연 write를 위한 최선의 경로가 될 가능성이 낮습니다.

문제 분석

핵심 개념: 이 문제는 Google이 권장하는 클라이언트 패턴인 Application Default Credentials (ADC), 효율적인 전송(gRPC), 지수 백오프를 사용하는 재시도, 데드라인/타임아웃, 그리고 처리량 및 지연 시간 SLO를 충족하기 위한 커넥션 풀링/채널 재사용을 활용하여 Cloud Run Python 서비스를 Firestore (Native mode)와 통합하는 방법을 평가합니다. 정답이 맞는 이유: Cloud Client Libraries (google-cloud-firestore)는 Firestore를 위한 의도된 고수준 SDK입니다. Cloud Run에서 ADC를 기본적으로 지원하고, Firestore에 최적화된 하위 전송( gRPC )을 사용하며, Google API 모범 사례에 맞춘 내장 재시도 및 타임아웃 구성을 제공합니다. 또한 하위 gRPC 스택을 통해 채널 풀링/재사용을 관리하는데, 이는 지속적인 write 부하에서 p95 지연 시간을 낮게 유지하는 데 중요합니다. Cloud Client Libraries를 사용하면 보일러플레이트를 최소화하면서도 성능 튜닝(배칭, async/동시성, 호출별 데드라인)을 할 수 있습니다. 주요 기능 / 모범 사례: - ADC: Cloud Run에서는 수동 키 처리 없이 라이브러리가 자동으로 service account identity를 사용합니다. - 재시도와 데드라인: 클라이언트 라이브러리는 메서드별 재시도/타임아웃 설정을 노출합니다. 합리적인 데드라인(예: SLO에 따라 수십~수백 ms)을 설정하고, 멱등성을 인지하는 재시도에 의존할 수 있습니다. - 커넥션 관리: gRPC 채널은 재사용됩니다. 요청마다 새 클라이언트를 만들지 마세요. Firestore client는 컨테이너 인스턴스당 한 번만 생성하세요. - 처리량: 8,000 writes/min(~133 writes/sec)은 Firestore 제한과 document hot-spotting 고려사항을 준수하면서 동시 요청 및/또는 배치 write(WriteBatch/BatchWrite)로 달성 가능합니다. 흔한 오해: Google API Client Libraries(일반적인 discovery 기반 REST 클라이언트)는 “공식”처럼 보일 수 있지만, 더 로우레벨이고 종종 REST 지향적이며, gRPC 성능 특성을 맞추고 재시도/타임아웃/채널 재사용을 올바르게 구현하려면 보통 더 많은 수작업이 필요합니다. 커스텀 gRPC 또는 서드파티 HTTP 클라이언트는 튜닝할 수는 있지만, 위험과 보일러플레이트가 증가하고 모범 사례를 위반하기 쉽습니다(잘못된 재시도 시맨틱, 부실한 풀링, 인증 플로우 누락). 시험 팁: Google 관리형 서비스(Firestore, Pub/Sub, Storage)에서는 특정 미지원 기능이 필요한 경우가 아니라면 Cloud Client Libraries를 우선 선택하세요. Cloud Run에서는 커넥션을 재사용하기 위해 클라이언트를 전역(요청 핸들러 밖)에서 생성하세요. 지연 시간 SLO를 충족하는 것은 순수 서비스 용량만큼이나 전송/채널 재사용과 올바른 타임아웃 설정에 좌우된다는 점을 알아두세요. 또한 고 write 워크로드를 위한 Firestore 모범 사례도 기억하세요: hot document/collection을 피하고, 적절한 경우 배칭을 고려하세요.

7
문제 7

Your microservices application named fintrack-ui runs on three GKE clusters—fintrack-ui-dev, fintrack-ui-uat, and fintrack-ui-prod—in us-central1, and your security team requires that only container images signed by a designated release attestor (using a Cloud KMS key in projects/123456/locations/us/keyRings/prod/cryptoKeys/release) are allowed to be deployed to the fintrack-ui-prod cluster while dev and uat remain permissive; following Google-recommended practices, how should you implement this so that enforcement applies only to the production cluster?

정확합니다. Binary Authorization는 이미지 attestation을 강제하기 위한 GKE의 네이티브 admission control입니다. clusterAdmissionRules를 사용하면 fintrack-ui-prod에만 엄격한 REQUIRE_ATTESTATION(지정된 Cloud KMS 키로 백업되는 release attestor 포함)을 적용하고, dev/uat는 ALWAYS_ALLOW 또는 dryrun으로 설정할 수 있습니다. 이는 production-only 제어를 위한 권장되는 정책 기반, 클러스터 범위(enforcement) 모델입니다.

부정확합니다. Binary Authorization 정책은 클러스터의 admission controller에 의해 배포 시점에 평가됩니다. 동일한 이미지가 어떤 클러스터에도 배포될 수 있으므로, 현실적으로 “prod에 배포되지 않는 이미지를 exempt”하는 방식은 적절하지 않습니다. 요구사항은 이미지별 exemption이 아니라 클러스터별 enforcement입니다. 올바른 접근은 clusterAdmissionRules를 통해 prod 클러스터로 규칙 범위를 제한하는 것입니다.

부정확합니다. vulnerability scanning을 수행하고 이미지를 untrusted로 태깅하는 것은 cryptographic signing/attestation 강제와 동일하지 않습니다. scanning은 리스크 판단에 정보를 제공할 수 있지만, 그 자체만으로는 GKE 배포를 차단하지 못합니다. “release attestor로 서명된 것만”을 강제하려면 Artifact Registry scanning metadata만이 아니라, attestor와 admission policy를 갖춘 Binary Authorization가 필요합니다.

부정확합니다. build pipeline에서 Cloud Functions 기반 게이트를 두는 것은 클러스터 admission에 대한 권장 제어가 아니며, 누군가 다른 pipeline이나 registry path에서 이미지를 배포하면 enforcement를 보장하지 못합니다. 요구사항은 prod 클러스터에서의 배포 시점 강제입니다. Binary Authorization는 이미지가 어떻게 빌드되거나 저장되었는지와 무관하게 중앙집중적이고 감사 가능하며 클러스터에서 강제되는 정책을 제공합니다.

문제 분석

핵심 개념: 이 문제는 GKE용 Binary Authorization(BinAuthZ)을 테스트합니다. 이는 배포 시점(deploy-time)에 정책을 강제하는 제어로, 지정된 attestation 요구사항을 충족하는 이미지에 대해서만 클러스터에 admission(승인)되도록 허용합니다. Cloud KMS로 백업되는 attestor와 통합되며, “prod에서는 서명된 이미지만 실행”을 강제하기 위한 Google 권장 접근 방식입니다. 정답이 맞는 이유: dev/uat는 허용적으로 유지하면서 fintrack-ui-prod에만 signature/attestation을 강제해야 합니다. Binary Authorization는 clusterAdmissionRules를 통해 클러스터별 정책을 지원하므로, 클러스터(클러스터 location/name으로 식별)마다 서로 다른 enforcement mode와 attestation 요구사항을 적용할 수 있습니다. 지정된 Cloud KMS 키(projects/123456/locations/us/keyRings/prod/cryptoKeys/release)를 서명 키로 사용하는 attestor를 생성한 다음, prod 클러스터는 해당 attestation을 요구하도록 정책을 구성하고 dev/uat는 always-allow(또는 dryrun) 규칙을 사용합니다. 주요 기능 / 구성: - Attestor: 서명/검증을 위해 Cloud KMS key version(s)를 사용하도록 구성. - Policy: admissionWhitelistPatterns(선택) 및 defaultAdmissionRule + clusterAdmissionRules. - fintrack-ui-prod: enforcement를 REQUIRE_ATTESTATION(또는 동등한 설정)으로 설정하고 release attestor를 요구. - dev/uat: enforcement를 ALWAYS_ALLOW로 설정(또는 점진적 롤아웃을 위해 dryrun 사용). 이는 배포 시점에 정책 기반의 자동화된 제어를 적용하여 인적 오류를 줄인다는 Google Cloud Architecture Framework 보안 원칙과 일치합니다. 흔한 오해: 많은 사람들이 vulnerability scanning(Artifact Analysis/Container Scanning)과 admission control을 혼동합니다. scanning은 이슈를 식별하지만, Binary Authorization 같은 admission controller와 결합되지 않으면 배포를 막지 못합니다. 또 다른 오해는 “prod에 배포되지 않는 이미지를 exempt”하려는 것입니다. 정책은 배포 목적지를 예측하는 방식이 아니라, 클러스터별로 admission 시점에 평가됩니다. 시험 팁: “서명/attested된 이미지만 GKE에 배포 가능”을 보면 Binary Authorization를 떠올리세요. 요구사항이 “prod에서만”이라면 전역 default가 아니라 clusterAdmissionRules(클러스터별 override)를 특히 확인하세요. 또한 KMS 키 location이 클러스터 region과 일치할 필요는 없지만, 키와 attestor에 대한 IAM이 서명/검증 워크플로를 허용해야 합니다. 롤아웃 패턴도 고려하세요: non-prod에서는 dryrun으로 시작한 뒤, prod에서 enforce합니다.

8
문제 8

You are monitoring a media transcoding microservice written in Node.js that runs on Cloud Run (fully managed). Each revision is configured with 2 vCPUs and 1.5 GiB memory, and Cloud Monitoring shows sustained spikes of ~90% CPU and ~1.3 GiB memory for 15-minute intervals during peak traffic (~800 RPS). You must identify which function is consuming the most CPU cycles and heap memory with minimal overhead (<1% CPU) and without adding significant latency in production. What should you do?

오답입니다. 모든 함수 호출 전/후에 console.log를 추가하는 것은 매우 침습적입니다. 동기/비동기 오버헤드를 추가하고 CPU 사용량을 증가시키며, 800 RPS에서 latency와 로그 볼륨/비용을 크게 증가시킬 수 있습니다. 또한 데이터가 지나치게 노이즈가 많아지고 프로덕션 운영 리스크가 커집니다. 이는 최소 오버헤드(<1% CPU) 및 “유의미한 latency 추가 없이”라는 요구사항을 위반합니다.

오답입니다. 요청 로그를 집계하고 handler duration을 계산하면 느린 요청을 식별할 수는 있지만, CPU cycles 또는 heap 사용량을 특정 함수에 신뢰성 있게 귀속시키지는 못합니다. latency는 I/O 대기, 네트워크 호출, 또는 downstream 의존성에 의해 지배될 수 있습니다. 또한 요청 로그는 일반적으로 함수 수준의 세분성을 제공하지 않으며, 타임스탬프로 CPU hotspot을 추론하는 것은 부정확하고 오해를 유발할 수 있습니다.

오답입니다. OpenTelemetry + Cloud Trace는 분산 tracing에 매우 유용하며 서비스 전반에서 고지연 span을 식별하는 데 탁월하지만, CPU/heap profiler는 아닙니다. Tracing은 CPU cycles를 소비하는 함수나 heap을 할당하는 함수를 보여주는 것이 아니라(대기 시간 포함) 시간이 어디에 쓰였는지를 보여줍니다. 또한 800 RPS에서 high-cardinality tracing은 신중하게 샘플링하지 않으면 오버헤드를 추가할 수 있으며, 그럼에도 CPU/heap에 대한 flame graphs를 생성하지는 못합니다.

정답입니다. Cloud Profiler(@google-cloud/profiler를 통해)는 프로덕션에 적합한 샘플링 기반 CPU 및 heap 프로파일링을 낮은 오버헤드로 제공합니다. Cloud console에서 CPU 및 heap flame graphs를 생성하여 가장 뜨거운 함수와 메모리 할당/유지 패턴을 직접 보여줍니다. 이는 최소 오버헤드와 최소 추가 latency로 CPU 및 heap 집약적인 함수를 식별해야 한다는 요구사항을 충족합니다.

문제 분석

핵심 개념: 이 문제는 매우 낮은 오버헤드로 운영 중인 Node.js 서비스에서 function 수준의 CPU hotspot과 heap memory 사용량을 식별하기 위한 올바른 observability 도구를 선택하는 것에 관한 것입니다. 요구 사항은 단순히 느린 request를 찾는 것이 아니라, 어떤 function이 가장 많은 CPU cycle과 heap memory를 소비하는지 판단하는 것입니다. 정답인 이유: sampling profiler는 이 작업에 적합한 도구입니다. 모든 function call을 instrumenting하는 대신 stack trace와 memory usage를 주기적으로 sample하기 때문입니다. Google Cloud에서 Node.js용 Profiler agent는 시간 경과에 따라 어떤 function이 가장 뜨거운지 보여주는 CPU 및 heap flame graph를 제공하도록 설계되었습니다. 이는 운영 환경에서 사용할 수 있을 만큼 runtime 오버헤드를 낮게 유지하면서 문제의 두 가지 요구를 모두 직접적으로 해결합니다. 주요 기능: Cloud Profiler는 CPU 및 heap profiling을 제공하고, 결과를 flame graph로 시각화하며, 일회성 debugging이 아니라 continuous profiling을 목적으로 합니다. sampling 기반 profiling은 광범위한 logging이나 custom timing instrumentation보다 훨씬 가볍습니다. request log만으로는 보이지 않는 code 수준의 hotspot을 찾는 데 특히 적합합니다. 흔한 오해: Tracing과 logging은 latency를 설명하는 데 도움이 될 수 있지만, function별 CPU consumption이나 heap allocation을 직접 측정하지는 않습니다. 느린 span은 CPU를 많이 사용하는 것이 아니라 I/O를 기다리고 있을 수 있으며, request log는 무거운 custom instrumentation을 추가하지 않는 한 handler 수준의 timing만 보여줍니다. 모든 function call 주변에 manual logging을 추가하는 방식은 특히 high-throughput 운영 서비스에 적합하지 않습니다. 시험 팁: 문제에서 가장 뜨거운 function, CPU cycle, heap memory, flame graph, 또는 낮은 오버헤드의 운영 진단을 묻는다면 Profiler를 떠올리세요. 여러 서비스에 걸친 request path latency를 묻는다면 Trace를 떠올리세요. event나 debugging output을 묻는다면 Logging을 떠올리세요.

9
문제 9

You are rolling out a reporting microservice on a Compute Engine VM (10.10.2.4) in the analytics-vpc (CIDR 10.10.0.0/16, region us-central1) that must connect to a Cloud SQL for PostgreSQL instance via the Cloud SQL Auth Proxy. The Cloud SQL instance resides in a separate db-vpc (CIDR 10.20.0.0/16) and has both public and private IPs; its private address is 10.20.3.5. For compliance, all database traffic must use the private IP. In testing, connections to the instance’s public IP succeed, but connections to 10.20.3.5 time out even though firewall rules in both VPCs allow TCP:5432 from their respective CIDR ranges and the proxy is started with --private-ip. How should you fix this issue?

Cloud SQL Auth Proxy를 background service로 실행하면 신뢰성과 startup 동작은 개선될 수 있지만, network reachability는 바뀌지 않습니다. 10.20.3.5로의 time out은 proxy 프로세스 관리 방식이 아니라 analytics-vpc와 db-vpc 사이의 L3 routing 부재로 인해 발생합니다. daemon으로 실행하더라도 peering/VPN/Interconnect 없이 다른 VPC의 private IP에 도달할 수는 없습니다.

시나리오에서 proxy가 이미 --private-ip로 시작되었다고 명시되어 있습니다. 이 flag는 proxy가 public address 대신 인스턴스의 private address로 연결하도록 지시할 뿐입니다. VPC들 간 connectivity를 생성하지는 않습니다. client VM이 10.20.0.0/16으로 routing할 수 없다면 --private-ip를 사용하면 관찰된 것처럼 time out만 발생합니다.

VM이 Cloud SQL 인스턴스의 private IP(10.20.3.5)로 트래픽을 routing할 수 있도록 analytics-vpc(10.10.0.0/16)와 db-vpc(10.20.0.0/16) 사이에 VPC Network Peering이 필요합니다. firewall rules만으로는 도달 가능성이 제공되지 않으며, peering이 필요한 routes와 private connectivity를 제공합니다. 이는 public endpoint를 사용하는 대신 database 트래픽을 private IP에 유지해야 한다는 compliance 요구사항과도 일치합니다.

Cloud SQL Client IAM role은 Auth Proxy가 credentials를 획득하고 Cloud SQL에 연결하는 데 필요하지만, 증거상 public IP 연결이 이미 성공하므로 IAM은 대체로 올바른 것으로 보입니다. IAM permissions는 private IP로의 VPC routing에 영향을 주지 않습니다. peering(또는 VPN/Interconnect) 없이 VM은 여전히 10.20.3.5에 도달할 수 없으므로 role을 부여해도 time out은 해결되지 않습니다.

문제 분석

핵심 개념: 이 문제는 네트워크 간 Cloud SQL private IP 연결성을 테스트합니다. private IP가 있는 Cloud SQL 인스턴스는 해당 인스턴스의 private services access (PSA) 범위가 할당된 VPC network에 대해 private connectivity가 있는 네트워크에서만 도달 가능합니다. Cloud SQL Auth Proxy는 관련 없는 VPC들 사이로 private IP 트래픽을 “터널링”하지 않으며, 단지 연결할 인스턴스 주소(public vs private)를 선택할 뿐입니다. 정답이 맞는 이유: public IP로의 연결이 성공하는 이유는 public IP 액세스가 Google의 public endpoint를 사용하며 analytics-vpc와 db-vpc 사이에 L3 routing이 필요하지 않기 때문입니다. 10.20.3.5로의 연결이 time out 되는 이유는 VM(10.10.2.4)이 10.20.0.0/16 네트워크로 가는 route가 없기 때문입니다. TCP:5432를 허용하는 firewall rules가 있고 proxy를 --private-ip로 시작했더라도, VPC들 간 network connectivity가 없으면 패킷이 private IP에 도달할 수 없습니다. analytics-vpc와 db-vpc 사이에 VPC Network Peering을 구성하면 10.10.0.0/16과 10.20.0.0/16 사이에 private RFC1918 routing이 설정되어, proxy(또는 direct clients)가 10.20.3.5에 도달할 수 있습니다. 주요 기능 / Best Practices: - Cloud SQL private IP는 client VPC에서 인스턴스의 VPC로의 private network connectivity(routing)가 필요합니다. - VPC Network Peering은 transitive routing 없이 low-latency의 private connectivity를 제공하며, CIDR ranges는 겹치면 안 됩니다. - Firewall rules는 필요하지만 충분하지 않습니다. routes도 필요합니다. peering은 routes를 자동으로 생성합니다. - Cloud SQL 인스턴스가 해당 VPC에서 private IP로 구성되어 있는지 확인하세요(private IP가 있으므로 PSA는 이미 존재합니다). 흔한 오해: 많은 사람들이 Auth Proxy의 --private-ip가 네트워크 토폴로지와 무관하게 “private connectivity를 강제”한다고 가정합니다. 실제로는 private address를 선택할 뿐이며, 누락된 routes를 극복할 수 없습니다. 마찬가지로 두 VPC에서 firewall를 열어도 peering/VPN/Interconnect 경로가 없으면 도움이 되지 않습니다. Exam Tips: 서로 다른 VPC들 사이에서 “private IP가 time out”을 보면, 먼저 routing(peering/VPN/Interconnect)을 생각하고 그다음 firewall, 그다음 IAM/proxy flags를 확인하세요. public IP가 동작한다는 것은 IAM과 proxy 기본 설정은 괜찮다는 강력한 단서이며, 빠진 요소는 private network connectivity입니다. 또한 peering은 non-transitive라는 점을 기억하세요. 더 많은 네트워크가 관련되면 추가 peering이 필요하거나 Cloud VPN/Interconnect와 Cloud Router를 사용한 hub-and-spoke가 필요할 수 있습니다.

10
문제 10

Your company runs a fleet-telemetry API on Cloud Run in the us-central1 region under the production project fleet-prod. For every release candidate, you must spin up an ephemeral QA environment that is fully isolated from production (separate Google Cloud project for networking/IAM/billing), is created and torn down automatically by your CI pipeline on each pull request, mirrors production settings (region: us-central1, CPU: 1, min instances: 0), and completes provisioning in under 10 minutes without sending any traffic to production. You want the approach that provides full automation with the least ongoing effort while enabling automated end-to-end tests. What should you do?

정답. Cloud Build에서 Terraform을 사용하면 새 project를 생성하고 us-central1에 CPU=1 및 min-instances=0으로 동일한 Cloud Run 서비스를 배포한 뒤, 테스트 후 삭제할 수 있습니다. 이는 엄격한 격리(IAM/네트워킹/빌링)를 충족하며, QA 서비스가 다른 project의 자체 URL을 가지므로 프로덕션 트래픽을 완전히 회피합니다. IaC는 명령형 스크립트 대비 drift와 지속적인 유지보수를 줄입니다.

오답. 기존 프로덕션 project에서 새 revision을 배포하고 traffic splitting을 사용하는 것은 완전한 격리를 제공하지 않습니다. IAM, 네트워킹, quota, 그리고 잠재적으로 데이터 접근이 프로덕션과 공유되며, 잘못된 설정으로 트래픽이 프로덕션으로 전송될 수 있습니다. 테스트 트래픽을 새 revision으로 라우팅하더라도 프로덕션 의존성과 상호작용할 위험이 있고 “별도 project” 요구사항을 위반합니다.

부분적으로 가능하지만 최선은 아님. gcloud 명령으로 project를 생성하고 Cloud Run을 배포할 수는 있지만, 이는 명령형 자동화로서 Terraform보다 유지보수가 어렵고 재사용성이 낮으며 구성 drift에 더 취약한 경향이 있습니다. 요구사항이 진화(IAM binding, API enablement, org policy, 네트워킹)할수록 스크립트는 취약해집니다. 문제는 최소한의 지속적 노력을 요구하므로 Terraform 기반 IaC가 더 적합합니다.

오답. 옵션 B와 마찬가지로 모든 것을 프로덕션 project에 유지하고 traffic splitting에 의존합니다. 별도 project라는 명시적 요구사항을 충족하지 못하며, 실수로 프로덕션에 영향을 줄 위험을 증가시킵니다. 또한 공유 라우팅/구성 실수 또는 공유 backend로 인해 프로덕션 시스템에 영향을 줄 수 있으므로 “프로덕션으로 어떤 트래픽도 보내지 않기”를 보장하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Infrastructure as Code (IaC)와 Cloud Run 배포 패턴을 사용하여 CI/CD를 위한 자동화된 환경 프로비저닝을 테스트합니다. 핵심 요구사항은 완전한 격리(IAM/네트워킹/빌링을 위한 별도 project), PR마다 빠른 임시 생성/해제, 프로덕션 Cloud Run 설정 미러링, 그리고 어떤 트래픽도 프로덕션에 도달하지 않도록 보장하는 것입니다. 정답이 맞는 이유: 옵션 A는 Cloud Build로 Terraform을 실행하여 (1) 완전히 새로운 Google Cloud project를 생성하고 (2) 해당 project에 Cloud Run 서비스를 배포한 다음, end-to-end 테스트를 실행하고 모든 것을 삭제합니다. 이는 project 경계가 IAM 정책, VPC/네트워킹, quota, billing을 격리하므로 “프로덕션으로부터 완전 격리”를 직접 충족합니다. Terraform은 반복 가능하고 선언적인 프로비저닝을 제공하여 자동화 및 장기 유지보수가 쉽고, 명령형 스크립팅보다 지속적인 노력을 최소화합니다. 적절한 module 설계를 통해 project와 소수의 리소스(API enablement, service account, Cloud Run service)를 프로비저닝하는 것은 10분 목표 내에 맞출 수 있습니다. 핵심 기능 / 모범 사례: Terraform은 Google Cloud project 생성, API enablement, IAM binding, Cloud Run 리소스를 지원하므로 단일 pipeline에서 환경을 일관되게 생성하고 해제할 수 있습니다. region (us-central1), CPU (1), min instances (0)를 파라미터화하여 프로덕션을 미러링할 수 있습니다. 별도 project 사용은 Google Cloud Architecture Framework의 보안 및 거버넌스 원칙(강한 격리, least privilege, 명확한 리소스 경계)과 일치합니다. PR별 Cloud Build trigger는 완전 자동화를 제공합니다. 흔한 오해: 트래픽 분할(options B/D)은 “빠른 QA”에 매력적으로 보일 수 있지만, 완전 격리 요구사항을 위반하고 실수로 프로덕션과 상호작용할 위험이 있습니다(공유 IAM, 공유 네트워킹, 공유 quota, 잠재적 데이터 접근). 명령형 gcloud 스크립팅(option C)은 가능할 수 있지만, 특히 환경이 진화함에 따라 IaC에 비해 장기 유지보수 부담과 drift 위험이 커지는 경향이 있습니다. 시험 팁: “완전 격리(fully isolated)”와 “별도 project(separate project)”가 보이면, project 내 revision/traffic splitting보다 환경별 project + IaC(Terraform)를 우선 선택하세요. 또한 “최소한의 지속적 노력(least ongoing effort)”은 보통 커스텀 명령 스크립트보다 선언적 IaC를 의미합니다. 마지막으로, 별도 project의 별도 endpoint에 배포하고 해당 endpoint에 대해서만 테스트를 실행하여 프로덕션 트래픽을 확실히 차단하는 접근인지 확인하세요.

합격 후기(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 #4

50 문제·120분·합격 700/1000
← 모든 Google Professional Cloud Developer 문제 보기

지금 학습 시작하기

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