연습 문제

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

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

문제 분석

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

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

문제 분석

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

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?

문제 분석

핵심 개념: 이 문제는 버스티하고 수명이 짧은, 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

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?

문제 분석

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

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?

문제 분석

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

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?

문제 분석

핵심 개념: 이 문제는 키를 이미 알고 있을 때 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

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?

문제 분석

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

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?

문제 분석

핵심 개념: 이 문제는 매우 높은 처리량의 글로벌 이벤트에 대해 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

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?

문제 분석

핵심 개념: 이 문제는 전 세계에 분산된 콘텐츠를 위한 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”을 언급하는 선택지는 위험 신호입니다.

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(10)

지금 학습 시작하기