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

Practice Test #1

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

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

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

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

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

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

문제 분석

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

2
문제 2

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

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

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

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

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

문제 분석

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

3
문제 3

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

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

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

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

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

문제 분석

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

4
문제 4

Your media analytics team runs a custom regression test harness that executes Linux-native binaries and shell scripts to validate a new codec pipeline; the full suite currently takes about 6 hours on 4 on-premises servers (24 vCPUs total) and must be reduced to under 45 minutes by parallelizing runs without rewriting the tests, with each test job needing a standard Linux VM, a custom startup script, and access to a 50-GB artifact set in Cloud Storage, and the lab triggers 10–20 full runs per workday with peak concurrency of up to 800 short-lived workers during business hours while preferring pay-as-you-go and minimal operational overhead. Which Google Cloud infrastructure should you recommend?

Network Load Balancer와 함께 사용하는 unmanaged instance groups는 주로 VM으로 들어오는 인바운드 네트워크 트래픽을 분산하기 위한 것입니다. built-in autoscaling, autohealing, 또는 선언적 instance templates를 제공하지 않으므로 최대 800개의 워커를 생성/종료하는 운영 오버헤드가 증가합니다. 또한 load balancer는 배치 스케줄링 문제를 해결하지 못합니다. 이 워크로드는 request-driven이 아니라 job-driven입니다. 결국 자체적으로 플릿 관리를 스크립팅해야 하며, 이는 “운영 오버헤드 최소화”와 충돌합니다.

Managed instance groups가 가장 적합합니다. instance template(Linux VM + startup script + IAM)을 정의하고 수요에 맞춰 그룹을 autoscale합니다. autoscaling은 CPU로도 구동할 수 있지만, 테스트 harness 워커의 경우 queue depth(Pub/Sub/Cloud Tasks/custom metric)가 보통 올바른 신호입니다. MIGs는 autohealing과 rolling updates도 제공하여 운영 부담을 줄입니다. 이는 수백 개의 수명이 짧은 워커로의 빠른 scale-out과 pay-as-you-go 비용 제어를 지원합니다.

Dataproc은 관리형 Hadoop/Spark 클러스터와 데이터 처리 프레임워크를 위해 설계되었습니다. 문제에서 harness는 Linux 네이티브 바이너리와 shell scripts를 실행하며 테스트 재작성 없이 병렬화해야 한다고 명시합니다. Dataproc으로 옮기려면 테스트를 Spark/Hadoop jobs로 패키징하거나 클러스터 노드에서 어색하게 실행해야 하며, 이는 복잡성과 비용(클러스터 라이프사이클, YARN/Spark 오버헤드)을 추가할 뿐, 단순한 VM 기반 워커에 대한 명확한 이점이 없습니다.

App Engine은 특정 runtime과 request-driven 실행을 갖는 웹 애플리케이션용 PaaS입니다. 임의의 Linux 바이너리와 긴 시간 실행되는 shell scripts를 대용량 로컬 아티팩트와 함께 실행하도록 의도된 서비스가 아닙니다. Cloud Logging이 관측 가능성을 돕기는 하지만, 핵심 요구사항(배치 작업을 실행하기 위한 ephemeral Linux VMs 플릿을 빠르게 확장)을 해결하지 못합니다. App Engine의 scaling semantics와 sandbox 제약은 이 워크로드에 적합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 버스티하고 수명이 짧은, Linux VM 기반 배치 워크로드를 위해 적절한 컴퓨팅 오케스트레이션을 선택하는지를 평가합니다. 이 워크로드는 운영 부담을 최소화하면서 수백 개의 워커로 확장되어야 합니다. 핵심 서비스는 Compute Engine Managed Instance Groups (MIGs), autoscaling, 그리고 Cloud Storage에 있는 아티팩트를 활용한 자동 인스턴스 초기화(startup scripts)입니다. 정답이 맞는 이유: autoscaling이 설정된 regional MIG는 “테스트 재작성 없음,” “표준 Linux VM,” “custom startup script,” “Cloud Storage의 50-GB 아티팩트 세트,” “최대 800개의 수명이 짧은 워커 동시 실행” 요구사항에 가장 잘 부합합니다. MIGs는 VM 템플릿(machine type, boot disk image, service account/IAM, metadata startup script)을 제공하며, 수요에 맞춰 자동으로 scale out/in 할 수 있습니다. 이를 통해 많은 테스트를 동시에 실행하여 전체 소요 시간을 6시간에서 45분 미만으로 줄일 수 있습니다. 또한 pay-as-you-go 모델과도 일치합니다. 인스턴스는 필요할 때만 존재하고, autoscaling이 유휴 비용을 줄여줍니다. 핵심 기능 / 구성 / 모범 사례: instance template에 startup script를 포함해 Cloud Storage에서 50-GB 아티팩트를 가져오고(가능하면 MIG와 가까운 regional bucket 사용), 단일 테스트 작업을 실행한 뒤 종료하도록 구성합니다. autoscaling은 CPU만으로 구동하기보다 큐 깊이 메트릭(예: Pub/Sub subscription backlog, Cloud Tasks queue size, 또는 custom Cloud Monitoring metric)을 기반으로 구동하는 것이 좋습니다. 테스트 러너는 I/O-bound일 수 있어 CPU가 “남은 작업량”의 신뢰할 만한 지표가 아닐 수 있기 때문입니다. 테스트가 재시도를 허용한다면 비용 절감을 위해 preemptible/Spot VMs를 사용합니다. 더 높은 가용성과 zone 간 더 빠른 용량 확보를 위해 regional MIGs를 고려합니다. 800개의 동시 VM을 지원할 수 있도록 quota(vCPU, instances, API rate limits)를 증설해야 합니다. 흔한 오해: unmanaged instance groups와 load balancer는 배치 워커 플릿이 아니라 트래픽 서빙을 위한 것이며, autoscaling과 self-healing이 없습니다. Dataproc은 Spark/Hadoop 작업에 최적화되어 있어 harness를 수정해야 합니다. App Engine은 HTTP 기반 애플리케이션 코드용이며, 임의의 Linux 바이너리를 실행하기 위한 것이 아닙니다. 시험 팁: “동일한 수명이 짧은 워커가 많이 필요,” “startup scripts,” “수백 개로 burst,” “운영 최소화”가 보이면 MIG + autoscaling + queue-driven scaling을 떠올리세요. load balancers는 요청 분산용이고, 배치 병렬성은 보통 큐와 autoscaled worker pool을 사용합니다.

5
문제 5

Your media company is building a new production environment on Google Cloud in a single VPC named media-prod with a subnet in us-central1 and will connect it to your data center using HA Cloud VPN with Cloud Router (dynamic routing); your on-premises RFC1918 address space is 10.20.0.0/16 and 172.18.0.0/16, and during a 6-month coexistence period every on-prem host must be reachable from Google Cloud and every Google Cloud workload must be reachable from on-prem without using NAT; you will also deploy a GKE cluster using alias IPs that requires two secondary ranges for Pods and Services; how should you plan the Google Cloud IP ranges to avoid reachability problems over the VPN during the migration?

오답입니다. Google Cloud subnet에 10.20.0.0/16을 할당하면 on-premises range와 overlap됩니다. HA VPN + Cloud Router(BGP)에서는 양쪽 모두 10.20.0.0/16에 대한 route를 갖게 되어 라우팅이 모호해지고, blackholing 또는 비대칭 경로가 발생할 가능성이 큽니다. on-prem addressing을 미러링하는 방식은 동시에 연결되지 않거나 NAT를 사용할 때만 동작하는데, 여기서는 NAT가 명시적으로 금지되어 있습니다.

오답입니다. GKE에 비중복 secondary range를 추가하더라도, Google Cloud의 primary subnet range로 10.20.0.0/16을 사용하므로 on-prem과 overlap됩니다. route가 동적으로 교환되는 공존 기간에는 이 overlap이 연결성을 깨뜨립니다. 요구사항은 NAT 없이 end-to-end 연결성이므로, 하이브리드 경계 전반에서 모든 라우팅 prefix가 고유해야 합니다.

정답입니다. VPC primary subnet과 GKE secondary range(Pods 및 Services) 모두에 비중복 range만 사용합니다. 이는 BGP advertisement가 on-prem RFC1918 range(10.20.0.0/16 및 172.18.0.0/16)와 충돌하지 않으므로 Cloud Router가 있는 HA VPN에서 결정적 라우팅을 보장합니다. 공존 요구사항을 충족하며, 하이브리드 네트워크와 GKE VPC-native 클러스터를 위한 모범 사례 IP 계획과 일치합니다.

오답입니다. GKE secondary range로 10.20.0.0/16을 재사용하는 것 역시 on-prem과 overlap을 만듭니다. GKE Pod/Service CIDR은 VPC의 IP space 일부이며 VPN을 통해 advertise/learn될 수 있어 route 충돌을 유발합니다. “policy routing”은 BGP domain 간 private range overlap에 대한 견고하거나 표준적인 해결책이 아니며, 마이그레이션 중 HA와 운영 단순성을 저해합니다.

문제 분석

핵심 개념: 이 문제는 HA Cloud VPN + Cloud Router(동적 라우팅/BGP)와 GKE VPC-native(alias IP) 클러스터를 사용하는 하이브리드 네트워킹 IP 계획을 테스트합니다. 핵심 개념은 동적 라우팅과 no-NAT 요구사항이 있을 때, 모호한 라우팅과 연결성 장애를 피하기 위해 양쪽에서 라우팅되는 모든 prefix가 고유(비중복)해야 한다는 점입니다. 정답이 맞는 이유: 6개월 공존 기간 동안 모든 on-prem 호스트는 Google Cloud에서 도달 가능해야 하고, 모든 Google Cloud 워크로드는 on-prem에서 “NAT 없이” 도달 가능해야 합니다. HA VPN + Cloud Router에서는 BGP를 통해 route가 교환됩니다. Google Cloud subnet primary range 또는 GKE secondary range가 on-prem RFC1918 range(10.20.0.0/16 또는 172.18.0.0/16)와 겹치면, 양쪽에 동일한 destination space에 대한 경쟁 route가 생깁니다. 이는 비대칭 라우팅, blackholing, 또는 VPN을 통과하지 않고 트래픽이 로컬에 머무는 문제를 유발합니다. 따라서 Google Cloud에서 VPC subnet과 GKE secondary range(Pods 및 Services) 모두에 대해 완전히 비중복 CIDR block을 할당해야 합니다. 옵션 C가 정확히 이를 수행합니다. 주요 기능 / 모범 사례: - Cloud Router는 VPC subnet primary range와(구성/필요 시) 관련 secondary range를 advertise하며, on-prem router는 이를 BGP로 학습합니다. overlap은 결정적 라우팅을 깨뜨립니다. - GKE VPC-native는 Pod IP용과 Service ClusterIP용 두 개의 secondary range가 필요합니다. 이는 네트워크에서 사용되는 실제 IP이며, on-prem에서 접근해야 한다면 하이브리드 링크를 통해 라우팅 가능해야 합니다. - Google Cloud Architecture Framework(Network 및 Security pillar): IP addressing을 초기에 계획하고, overlap을 피하며, 명확한 routing domain을 위해 설계합니다. - 실무 계획: 성장과 추가 클러스터/subnet을 수용할 수 있도록 충분히 큰 비중복 block(종종 별도의 /16 또는 더 큰 aggregate)을 예약합니다. 흔한 오해: A와 B는 on-prem range를 재사용하면 “cutover를 단순화”할 수 있어 매력적으로 보이지만, 이는 NAT를 사용하거나 환경이 동시에 연결되지 않을 때만 가능합니다. 여기서는 공존 + no NAT이므로 overlap은 허용되지 않습니다. D는 “policy routing”으로 해결할 수 있다고 가정하지만, 실제로 BGP domain 간 RFC1918 overlap은 취약하며 HA VPN/Cloud Router route exchange에 대한 지원되는 모범 사례가 아닙니다. 시험 팁: (1) 하이브리드 연결, (2) 동적 라우팅/BGP, (3) 명시적인 “no NAT”를 보면, GKE secondary range를 포함해 “모든 곳에서 비중복 CIDR”을 즉시 선택하세요. 또한 GKE alias IP는 라우팅에 참여하는 VPC secondary range를 소비하므로, 다른 subnet range와 동일하게 계획해야 함을 기억하세요.

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

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

6
문제 6

Refer to the dark-mode network diagram shown below: your company has three separate VPCs in Google Cloud, each containing one Compute Engine instance. Subnets do not overlap and must remain isolated. Instance #1 is a special case and must communicate directly with Instance #2 and Instance #3 using internal IP addresses. What should you do?

Cloud Router는 VPC를 자동으로 도달 가능하게 만들지 않습니다. 이는 Cloud VPN 또는 Cloud Interconnect(BGP) 위에서 라우트를 동적으로 교환하기 위한 컨트롤 플레인 구성요소입니다. 기본 연결 메커니즘(VPN/Interconnect/peering) 없이 subnet #2/#3의 라우트를 subnet #1로 광고해도 데이터 플레인 연결은 생성되지 않습니다. 또한 VPN/Interconnect가 있더라도 이는 네트워크 레벨 연결이므로, 요청된 “오직 Instance #1만” 범위의 접근이 아닙니다.

정답입니다. multi-NIC Compute Engine 인스턴스는 여러 VPC 네트워크에 연결될 수 있어 Instance #1이 VPC #1, VPC #2, VPC #3에 동시에 내부 IP를 갖게 됩니다. 이를 통해 Instance #1에서 Instance #2와 Instance #3로 내부 IP 기반의 직접 통신이 가능해지며, VPC들은 서로 격리된 상태를 유지합니다(VPC-to-VPC 라우팅 없음). 이후 VPC #2와 VPC #3에서 firewall rules를 조정하여 Instance #1의 내부 IP들로부터의 트래픽을 허용합니다.

두 개의 Cloud VPN 터널은 VPC #1-to-#2 및 VPC #1-to-#3 네트워크 연결을 설정합니다. 이는 서브넷/VPC가 격리된 상태를 유지해야 한다는 요구사항을 위반합니다. VPN 라우팅은 일반적으로 VPC #1의 허용된 리소스가 VPC #2/#3에 도달할 수 있게 만들기 때문입니다(라우트와 firewall에 따름). 또한 운영 복잡성(HA VPN, Cloud Router/BGP, 모니터링)과 반복 비용을 추가하며, 단일 인스턴스 요구사항에는 불필요합니다.

VPC Network Peering은 네트워크-대-네트워크 연결 기능입니다. VPC #1을 VPC #2와 peering하고 VPC #1을 VPC #3와 peering하면, VPC #1의 리소스(Instance #1만이 아니라)가 내부 IP를 사용해 VPC #2 및 VPC #3의 리소스에 도달할 수 있게 됩니다(firewall에 따름). 이는 “격리된 상태를 유지” 제약을 깨고 영향 범위를 확대합니다. Peering은 단일 VM 예외가 아니라 VPC 간 광범위한 프라이빗 연결이 필요할 때 적합합니다.

문제 분석

핵심 개념: 이 문제는 VPC 격리와 분리된 VPC 네트워크 간에 사용할 수 있는 연결 패턴인 VPC Network Peering, Cloud VPN/Interconnect, 다중 NIC Compute Engine 인스턴스를 테스트합니다. 핵심 요구사항이 특이합니다. Instance #1만 내부 IP를 사용해 다른 두 개의 격리된 VPC에 있는 인스턴스에 직접 도달해야 하며, 동시에 VPC/서브넷은 서로 간에 격리된 상태를 유지해야 합니다. 정답이 맞는 이유: Instance #1에 추가 NIC를 붙이는 것(VPC #2/subnet #2에 NIC 1개, VPC #3/subnet #3에 NIC 1개)이 VPC 간 네트워크-대-네트워크 연결을 만들지 않으면서 Instance #1이 각 VPC에 네이티브하게(내부 IP로) 존재하도록 하는 유일한 옵션입니다. 여러 NIC를 사용하면 Instance #1은 dual-/tri-homed 호스트가 됩니다. 즉, 목적지 VPC에 속한 인터페이스로 트래픽을 내보내 Instance #2와 Instance #3에 그들의 내부 IP로 도달할 수 있습니다. 이는 VPC #2와 VPC #3가 서로 연결되지 않고(VPC #1도 네트워크 계층에서 그들과 연결되지 않음) 단일 VM만 여러 네트워크에 참여하기 때문에 격리 요구사항을 보존합니다. 주요 기능 / 구성: - Compute Engine은 VM에서 여러 네트워크 인터페이스(NIC)를 지원합니다(머신 타입 제한 적용). - 각 NIC는 정확히 하나의 VPC 네트워크와 하나의 서브넷에 연결되며, 해당 서브넷에서 내부 IP를 할당받습니다. - VPC #2와 VPC #3에서 VPC firewall rules를 업데이트하여 Instance #1의 내부 IP들로부터의 ingress를 허용해야 합니다(리턴 경로에 따라 VPC #1에서도 선택적으로 필요할 수 있음). - OS 라우팅/소스 기반 라우팅이 올바른지 확인합니다(게스트 OS가 각 목적지로의 트래픽을 올바른 NIC를 통해 보내야 함). 라우터/NVA를 의도적으로 구축하는 경우가 아니라면 IP forwarding 활성화는 피하세요. 흔한 오해: - Peering(옵션 D)은 단순해 보이지만 VPC-to-VPC 연결을 생성하므로 “격리된 상태를 유지” 요구사항을 위반하며, 요구사항보다 더 광범위한 도달성을 허용하게 됩니다. - Cloud VPN(옵션 C)도 마찬가지로 네트워크를 연결하며(그리고 비용/운영 오버헤드를 추가) 단일 VM으로만 연결을 제한하지 못합니다. - Cloud Router(옵션 A)는 VPN/Interconnect를 위한 동적 라우트 교환(BGP)에 사용되며, 그 자체만으로 격리된 VPC를 연결하지는 않습니다. 시험 팁: “오직 한 VM만 접근 필요” + “네트워크는 격리 유지”를 보면 peering/VPN이 아니라 “multi-NIC VM”을 떠올리세요. Peering/VPN은 네트워크 레벨 구성요소로, 일반적으로 단일 인스턴스를 넘어 도달성을 확장하며 격리 요구사항에 비추어 신중한 정당화가 필요합니다.

7
문제 7

You are deploying a Cloud Run microservice that persists customer profiles in Cloud Datastore; at startup, the service must preload 50 top-level Profile entities whose numeric IDs are provided by a configuration file, and all entities are root entities with no ancestors; you want to minimize Cloud Datastore operational overhead (number of RPCs and index usage) and reduce retrieval latency; what should you do?

정답입니다. 알려진 50개 숫자 ID에 대해 Key를 구성하고 단일 배치 조회(Lookup/getAll)를 실행하면 RPC 수와 지연 시간을 최소화할 수 있습니다. 키 기반 조회는 쿼리 실행과 인덱스 스캔을 우회하여 Datastore 운영 오버헤드를 줄입니다. 이는 엔티티 식별자를 이미 알고 있고 빠르고 예측 가능한 읽기(예: Cloud Run에서 시작 시 프리로딩)가 필요할 때 권장되는 패턴입니다.

오답입니다. 개별 get 작업은 50개의 독립적인 RPC(또는 최소한 필요 이상으로 많은 RPC)를 수행하므로 콜드 스타트 시간과 테일 지연 시간을 증가시키고 Datastore API 할당량/오버헤드를 더 많이 소비합니다. 각 get은 여전히 키 조회이므로(인덱스를 피함) 인덱스는 사용하지 않지만, 문제는 RPC와 조회 지연 시간을 최소화하라고 명시하며, 배치 조회가 이를 더 잘 충족합니다.

오답입니다. ID로 필터링하는 쿼리를 만드는 것은 최적의 Datastore 패턴이 아닙니다. 쿼리는 인덱스와 쿼리 실행에 의존하므로 직접 키 조회에 비해 오버헤드가 추가됩니다. Datastore는 SQL처럼 임의의 키 집합에 대해 단순하고 효율적인 “ID IN (…)”에 해당하는 쿼리를 지원하지 않습니다. 설령 에뮬레이션하더라도 인덱스 사용과 지연 시간이 증가합니다.

오답입니다. 엔티티당 쿼리 1개는 최악의 조합입니다. RPC 수(50개 쿼리)를 늘리고 각 엔티티에 대해 인덱스 기반 쿼리 실행을 강제합니다. 이는 운영 오버헤드와 지연 시간을 최대화하여 RPC와 인덱스 사용을 최소화하라는 요구사항과 정면으로 충돌합니다. ID를 알고 있다면 쿼리는 불필요하며, 대신 키 조회를 사용해야 합니다.

문제 분석

핵심 개념: 이 문제는 키를 이미 알고 있을 때 Cloud Datastore(Datastore mode의 Firestore)에서 알려진 엔티티 집합을 가장 효율적으로 가져오는 방법을 평가합니다. Datastore에서 키 기반 조회는 오버헤드가 가장 낮은 읽기 경로입니다. 쿼리 플래닝을 피하고, 인덱스 스캔을 피하며, 단일 Lookup RPC로 실행할 수 있습니다. 정답이 맞는 이유: 서비스에 최상위(루트) Profile 엔티티의 50개 숫자 ID가 들어 있는 구성 파일이 있으므로, 전체 키(kind + numeric ID, 그리고 해당되는 경우 project/namespace)를 결정적으로 구성할 수 있습니다. Datastore는 하나의 요청에서 여러 키를 받는 배치 조회(Lookup API / client library getAll)를 제공합니다. 이는 RPC 수를 50개의 개별 읽기에서 (일반적으로) 1개의 RPC로 줄여 운영 오버헤드를 최소화하고, 엔티티별 왕복을 피하며 백엔드가 엔티티를 효율적으로 가져오도록 하여 지연 시간을 줄입니다. 엔티티가 조상(ancestor)이 없는 루트 엔티티이므로, ancestor query나 트랜잭션 의미론이 필요하지 않습니다. 주요 기능 / 모범 사례: 키 기반 조회는 인덱스가 필요 없고 쿼리 인덱스 리소스를 소비하지 않습니다. (단순한 것이라도) 쿼리는 인덱스에 의존하며 추가 오버헤드와 지연 시간을 유발할 수 있습니다. 배치 조회는 시작 시 워밍업과 캐시 프리로딩을 위한 표준 성능 패턴입니다. Cloud Run에서는 콜드 스타트 성능과 다운스트림 부하 제어를 위해 시작 시 네트워크 호출을 줄이는 것이 중요합니다. 또한 단일 Lookup 요청을 사용하면 할당량 효율(더 적은 API 호출)이 좋아지고 재시도 동작도 단순해집니다. 흔한 오해: 쿼리로 “ID로 필터링”하고 싶을 수 있지만, Datastore 쿼리는 관계형의 IN 절처럼 엔티티 키를 동일한 방식으로 효율적으로 필터링할 수 없고, 쿼리는 본질적으로 인덱스를 사용하며 직접 키 get보다 더 큰 오버헤드로 결과를 반환할 수 있습니다. 또 다른 오해는 50번의 get이 “충분히 작다”는 것이지만, 문제는 RPC와 지연 시간을 최소화하는 것을 명시적으로 우선시합니다. 시험 팁: 정확한 엔티티 키를 알고 있다면 Lookup/get by key를 선호하고(그리고 배치로 묶으세요). 속성, 정렬, 범위로 검색해야 할 때는 쿼리를 사용합니다. 기억하세요: 쿼리는 인덱스 사용을 의미하지만, 키 조회는 그렇지 않습니다. Cloud Run 및 기타 서버리스 런타임에서는 초기화 중 네트워크 왕복을 최소화하는 것이 흔한 아키텍처/프레임워크 성능 최적화입니다.

8
문제 8

You operate a latency-sensitive order-matching microservice on Google Kubernetes Engine in us-central1 with a Deployment named matcher-deploy (4 replicas with readinessProbes) exposed internally via a ClusterIP Service named matcher-svc behind an Internal HTTP(S) Load Balancer; you must roll out a new container image gcr.io/acme/matcher:v2 with minimal disruption (no more than 1 pod unavailable at any time) and without recreating the Service or changing the node pool; what should you do?

kubectl set image는 Deployment의 Pod template을 업데이트하고 통제된 rolling update를 트리거합니다. readinessProbes가 있으면 새 Pods는 Ready가 될 때까지 트래픽을 받지 않으며, Service/ILB는 변경되지 않습니다. “unavailable이 1개를 넘지 않음”을 보장하려면 Deployment strategy가 RollingUpdate에서 maxUnavailable=1(그리고 필요 시 maxSurge=1)을 사용하도록 하세요. 이는 GKE에서 새 container image를 롤아웃하는 표준적이고 중단이 가장 적은 방식입니다.

node pool의 managed instance group을 업데이트하는 것은 인프라 롤아웃(노드/OS/Kubernetes 버전)이지 애플리케이션 롤아웃이 아닙니다. matcher-deploy가 사용하는 container image를 직접 변경하지도 않습니다. 또한 노드 업그레이드 중에는 신중한 drain 및 budget 설정이 없으면 여러 Pods가 동시에 evict될 수 있어 중단 위험이 커집니다. 요구사항에서 node pool을 변경하지 말라고 명시했습니다.

Deployment를 삭제하고 재생성하면 불필요한 중단이 발생합니다. 기존 Pods가 모두 종료되고 새 Pods가 처음부터 생성되므로 “어떤 시점에도 1개 이상의 pod가 unavailable이면 안 된다” 제약을 위반할 수 있습니다. Service가 유지되더라도, 시작 시간과 readiness에 따라 ready endpoints가 감소하거나 0이 되는 구간이 생길 수 있습니다. 모범 사례는 삭제가 아니라 Deployment를 업데이트/apply하는 것입니다.

Services는 container images를 참조하지 않습니다. Services는 labels로 Pods를 선택하고 안정적인 네트워킹(ClusterIP)과 로드 밸런싱을 제공합니다. Service를 삭제하고 재생성하면(명시적으로 보존하지 않는 한) ClusterIP가 바뀔 수 있고, Internal HTTP(S) Load Balancer/NEG 연결이 깨져 불필요한 다운타임을 유발할 수 있습니다. 애플리케이션 버전 관리는 Service가 아니라 Deployment/Pod template에 속합니다.

문제 분석

핵심 개념: 이 문제는 GKE에서 Kubernetes 워크로드 롤아웃 메커니즘—특히 Deployments가 안정적인 Service 및 Internal HTTP(S) Load Balancer 뒤에서 가용성을 유지하면서 rolling update를 수행하는 방식—을 테스트합니다. 또한 readinessProbes, maxUnavailable/maxSurge, 그리고 Pods/Deployments와 Services 간 관심사 분리를 암묵적으로 테스트합니다. 정답이 맞는 이유: Deployment에서 kubectl set image를 사용하면 Pod template(spec.image)이 업데이트되고 Deployment가 관리하는 rolling update가 트리거됩니다. replicas가 4개이고 readinessProbes가 설정되어 있으면, Kubernetes는 v2 이미지로 새 Pods를 생성하고 Ready 상태가 된 이후에만 트래픽을 전달합니다. Service(matcher-svc)는 변경되지 않으므로, 해당 virtual IP와 Internal HTTP(S) Load Balancer backend는 안정적으로 유지되어 Service를 재생성하지 말라는 요구사항을 충족합니다. “어떤 시점에도 1개 이상의 pod가 unavailable이면 안 된다”를 보장하려면 Deployment strategy를 RollingUpdate로 두고 maxUnavailable=1(그리고 필요 시 maxSurge=1)을 사용(또는 설정)합니다. 이는 Google Cloud Architecture Framework의 reliability 원칙(사용자 영향 최소화와 통제된 변경)과도 일치합니다. 주요 기능 / 모범 사례: - Deployment rolling updates: 선언적 desired state; Kubernetes가 교체를 오케스트레이션. - readinessProbes: Ready가 될 때까지 Pods로 라우팅하지 않도록 하며, 지연 시간에 민감한 서비스에 중요. - RollingUpdate 파라미터: maxUnavailable은 가용성을 강제; maxSurge는 일시적 추가 용량을 제어(클러스터 용량/쿼터 고려). - Service 안정성: ClusterIP Service가 Pods를 추상화; 설정에 따라 load balancer가 Service/NEGs를 대상으로 하므로 이를 건드리지 않음. 흔한 오해: - node pools/MIGs 업데이트(옵션 B)는 애플리케이션 이미지가 아니라 인프라를 변경하는 것이며, 더 느리고 중단 위험이 큼. - Deployments/Services 삭제 후 재생성(옵션 C/D)은 불필요한 다운타임, IP/endpoint 변경을 유발하고 “최소 중단” 요구사항을 위반. 시험 팁: GKE에서 애플리케이션 롤아웃은 Deployment 레벨(이미지/태그 업데이트, manifests apply)에서 수행합니다. readiness/liveness probes와 RollingUpdate 설정을 함께 사용해 SLO를 충족하세요. 일반적인 릴리스에서 Services를 삭제/재생성하는 것은 피하세요. Services는 안정적인 네트워킹 프리미티브입니다. 또한 용량도 기억하세요: maxSurge는 여유 리소스를 필요로 할 수 있으므로 클러스터 한도에 맞는 값을 선택해야 합니다.

9
문제 9

You are designing an ingestion layer for a cross-continent payment event stream that feeds a reconciliation microservice requiring strict per-merchant FIFO ordering and exactly-once delivery; traffic arrives from 7 regions, spikes to 80,000 events per second, and must be processed end-to-end within 1.5 seconds while using only managed GCP services and avoiding custom brokers. Which products should you deploy to ensure guaranteed-once FIFO delivery and meet the scalability and latency requirements?

Cloud Pub/Sub는 훌륭한 관리형 ingestion 서비스이며 낮은 지연으로 매우 높은 처리량까지 확장할 수 있습니다. 그러나 전달 모델은 at-least-once이고, Pub/Sub만으로는 애플리케이션까지의 end-to-end exactly-once delivery를 제공하지 않습니다. ordering keys로 ordering을 개선할 수는 있지만, 엄격한 merchant별 FIFO와 exactly-once 처리는 일반적으로 sequencing을 강제하고 deduplicate하는 처리 계층이 필요합니다.

Cloud Pub/Sub에서 Cloud Dataflow로 이어지는 구성은 가장 강력한 선택지입니다. Pub/Sub는 글로벌 분산 환경의 bursty ingestion을 처리하고, Dataflow는 keyed ordering과 deduplication logic에 필요한 stream-processing 계층을 추가하기 때문입니다. Dataflow에서는 merchant ID로 record를 keying하여 key별 순서 보장 처리를 유지하고, state 또는 sequence validation을 사용해 retry와 out-of-order arrival를 관리할 수 있습니다. 또한 Dataflow는 수평 확장이 가능하고 낮은 지연 시간의 streaming workload를 위해 설계되었으므로 초당 80,000 events에 적합합니다. 다만 exact-once라는 표현은 pipeline 내부 또는 지원되는 sink에서의 exactly-once processing semantics로 이해해야 하며, 외부 microservice endpoint에 대한 무조건적인 보장을 의미하지는 않습니다.

Cloud Logging은 대량의 결제 이벤트를 위한 event-stream ingestion 및 processing 플랫폼이 아닙니다. 이는 로그 수집, 보관, 분석에 최적화되어 있으며, 80,000 events/sec에서 엄격한 FIFO ordering, exactly-once delivery, 또는 sub-second stream processing을 제공하도록 설계되지 않았습니다. Logging을 중간 계층으로 사용하면 필요한 전달 및 ordering 보장을 제공하지 못한 채 지연, 비용, 복잡성만 증가합니다.

Cloud SQL은 관계형 데이터베이스이지, 고처리량 streaming ingestion 계층이 아닙니다. 80,000 events/sec를 Cloud SQL에 직접 쓰면 connection, write throughput, scaling 한계에 부딪힐 가능성이 크고, downstream microservice에 대해 merchant별 FIFO processing 시맨틱을 본질적으로 제공하지도 않습니다. 또한 목적에 맞게 설계된 streaming pipeline에 비해 지연 증가와 운영 제약 위험이 있습니다.

문제 분석

핵심 개념: 이 문제는 매우 높은 처리량의 글로벌 이벤트에 대해 merchant별 순서 보장 처리와 실질적인 exactly-once processing semantics가 필요한 경우, 완전관리형 GCP ingestion 및 stream-processing 설계를 선택하는 내용입니다. 보기 중 가장 적합한 것은 내구성이 있고 지연 시간이 낮은 글로벌 ingestion을 위한 Cloud Pub/Sub와 merchant를 key로 사용하는 확장 가능한 stream processing을 위한 Cloud Dataflow의 조합입니다. 정답인 이유: Pub/Sub는 여러 리전의 트래픽을 매우 큰 규모로 낮은 운영 오버헤드로 수용할 수 있고, Dataflow는 stream을 병렬로 처리하면서 per-key state를 유지할 수 있습니다. merchant ID를 key로 사용하면 pipeline이 merchant별 순서 보장 처리를 유지하고, 결과를 전달하기 전에 deduplication 또는 sequence 검사를 수행할 수 있습니다. 나열된 보기 중 관리형 서비스만으로 처리량 및 지연 시간 목표를 현실적으로 충족할 수 있는 것은 이것뿐입니다. 다만 외부 microservice에 대한 진정한 end-to-end exactly-once는 여전히 downstream sink 또는 consumer가 idempotent하거나 transaction-aware한지에 달려 있습니다. 주요 기능: - Cloud Pub/Sub는 높은 처리량과 낮은 지연 시간을 갖춘 글로벌 분산형 관리형 event ingestion을 제공합니다. - Cloud Dataflow는 per-key state, timer, checkpointing, autoscaling, ordered processing pattern을 갖춘 streaming pipeline을 지원합니다. - Pub/Sub ordering key는 특정 merchant key에 대한 publish 순서를 유지하는 데 도움이 되며, Dataflow는 merchant별 sequencing logic을 강제하고 retry를 deduplicate할 수 있습니다. - Dataflow는 대규모 streaming workload를 위해 설계되었으며, 적절히 튜닝하면 낮은 지연 시간 목표를 충족할 수 있습니다. 흔한 오해: 흔한 실수는 Pub/Sub만으로 exactly-once delivery와 보편적인 FIFO semantics를 보장한다고 가정하는 것입니다. 실제로 Pub/Sub는 본질적으로 내구성 있는 messaging과 at-least-once delivery를 중심으로 설계되었고, ordering은 ordering key 내에서만 제공됩니다. 또 다른 오해는 Dataflow가 어떤 downstream microservice에 대해서도 자동으로 end-to-end exactly-once delivery를 보장한다는 것입니다. exactly-once는 pipeline 내부와 지원되는 sink에서 가장 강력하며, 외부 side effect는 여전히 idempotency 또는 transactional design이 필요합니다. 시험 팁: PCA 시험에서 global ingestion과 매우 높은 처리량이 보이면 Pub/Sub를 떠올리세요. 여기에 per-key ordering, stateful stream logic, deduplication, low-latency processing이 함께 보이면 Dataflow를 추가하세요. 'guaranteed-once delivery' 같은 표현은 주의해서 보세요. 많은 아키텍처에서 관리형 서비스는 pipeline 내에서 exactly-once processing semantics를 제공할 수 있지만, end-to-end 보장은 destination의 동작에 달려 있습니다.

10
문제 10

A nonprofit Earth-observation collective distributes high-resolution satellite imagery bundles for public download (each file 500 MB–3 GB, ~9 TB total), and their audience spans more than 45 countries across 6 continents; they need to minimize download latency for all users and adhere to Google-recommended practices while keeping operations simple. How should they store the files?

정답입니다. Multi-Regional Cloud Storage bucket은 넓은 지리적 범위의 사용자가 접근하는 콘텐츠를 위해 설계되었으며, geo-redundant storage를 제공하고 일반적으로 단일 regional bucket보다 평균 읽기 지연 시간이 더 좋습니다. 또한 운영을 단순하게 유지합니다: bucket 1개, namespace 1개, IAM/policies 1세트, 그리고 글로벌 배포를 위해 관리해야 할 커스텀 replication 또는 synchronization이 없습니다.

오답입니다. Cloud Storage bucket은 zonal 리소스가 아니므로 “zone당 bucket 1개”는 유효하거나 권장되는 설계 패턴이 아닙니다. 이를 “region당 1개”로 해석하더라도, 단일 regional location은 해당 region에서 먼 사용자에게 지연 시간을 증가시키며, Google 권장 사례를 따르면서 글로벌 사용자에 대한 지연 시간을 최소화하라는 요구사항을 충족하지 못합니다.

오답입니다. 이 선택지는 두 가지 측면에서 문제가 있습니다. Cloud Storage에 적용되지 않는 zonal bucket 개념에 의존하고, 동시에 상당한 운영 복잡성(여러 bucket, 릴리스 조율, IAM/policies 중복, 콘텐츠 불일치 가능성)을 추가합니다. multi-region 분산이 지연 시간을 줄일 수는 있지만, 단순성을 위한 Google 권장 사례는 많은 regional bucket이 아니라 multi-regional storage(그리고 선택적으로 CDN)를 사용하는 것입니다.

오답입니다. 여러 multi-regional bucket(US/EU/ASIA 같은 multi-region당 1개)을 생성하면 운영 오버헤드가 증가하고 게시 및 접근 관리가 복잡해집니다. 또한 데이터셋을 분절시키고 사용자가 “올바른” bucket을 선택해야 하게 만들 수 있습니다. 단순성과 광범위한 글로벌 접근이 목표라면, 선택지 중에서는 단일 multi-regional bucket이 가장 적합합니다.

문제 분석

핵심 개념: 이 문제는 전 세계에 분산된 콘텐츠를 위한 Cloud Storage 위치 전략을 테스트합니다. 즉, 사용자 다운로드 지연 시간을 최적화하면서 운영을 단순하게 유지하기 위해 regional vs multi-regional bucket 중 무엇을 선택할지 묻습니다. 또한 성능 최적화, 안정성, 운영 우수성과 관련된 Google Cloud Architecture Framework 원칙과도 암묵적으로 정렬됩니다. 정답이 맞는 이유: Multi-Regional Cloud Storage bucket은 넓은 지리적 범위에 분산된 사용자에게 낮은 지연 시간과 높은 가용성으로 콘텐츠를 제공하도록 설계되었습니다. 6개 대륙의 45개+ 국가에 걸친 사용자층이 있는 경우, 데이터를 단일 region에 두면 해당 region에서 먼 사용자에게 지속적으로 더 높은 지연 시간이 발생합니다. multi-regional bucket은 광범위한 지리(예: US, EU, ASIA) 내 여러 region에 걸쳐 데이터를 중복 저장하여, 팀이 여러 bucket이나 replication 워크플로를 관리할 필요 없이 읽기 성능과 복원력을 개선합니다. 이는 운영을 단순하게 유지하면서 “모든 사용자”에 대해 가능한 한 다운로드 지연 시간을 최소화하라는 요구사항과 일치합니다. 주요 기능 / Best Practices: multi-regional bucket은 geo-redundancy와 강력한 durability를 제공하며, region별 bucket과 replication을 관리하는 것에 비해 운영 오버헤드를 줄입니다. 공개 다운로드의 경우 Cloud Storage는 Cloud CDN(일반적으로 external HTTP(S) load balancer를 통해)과도 잘 통합되어 지연 시간을 추가로 줄이고 origin 읽기 부하를 오프로딩할 수 있습니다. 다만 이 문제는 특히 storage 배치에 초점을 두고 있으며, 단순성이 중요할 때 널리 분산된 접근 패턴에 대해 Google이 권장하는 기본값은 multi-regional입니다. 흔한 오해: 흔한 함정은 “더 많은 장소에 더 많은 bucket”이 항상 더 나은 지연 시간을 의미한다고 생각하는 것입니다. 실제로는 여러 bucket이 복잡성을 유발합니다: 객체 동기화, 릴리스 일관성, access control 중복, 운영 리스크 등이 있습니다. 또 다른 오해는 “zone당 bucket 1개”인데, Cloud Storage bucket은 zonal 리소스가 아니라 regional, dual-region, 또는 multi-regional입니다. 시험 팁: “글로벌 사용자 + 공개 다운로드 + 단순하게 유지”를 보면 기본적으로 Multi-Regional Cloud Storage(또는 선택지에 따라 Dual-Region/Multi-Region)를 떠올리세요. 반대로 데이터 레지던시, 엄격한 regional 컴플라이언스, 또는 쓰기 로컬리티가 강조된다면 Regional(또는 Dual-Region) + CDN/replication이 더 적합할 수 있습니다. 또한 Cloud Storage는 zonal이 아니므로 “zone별 bucket”을 언급하는 선택지는 위험 신호입니다.

합격 후기(10)

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

학습 기간: 1 month

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

김
김**Nov 19, 2025

학습 기간: 1 month

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

박
박**Nov 17, 2025

학습 기간: 1 month

앱 너무 좋네요

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

학습 기간: 2 weeks

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

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

학습 기간: 1 month

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

← 모든 Google Professional Cloud Architect 문제 보기

지금 학습 시작하기

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

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

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

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

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

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

앱 받기

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