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

Practice Test #2

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

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) 구현을 기대합니다.

2
문제 2

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 처리 패턴에 달려 있다는 점을 기억하세요.

3
문제 3

You operate a telemetry collection microservice on Cloud Run that accepts HTTP POST requests with JSON metrics, averaging 50,000 requests per minute. For compliance reasons, the ingestion endpoint must be hosted on a different domain than the user-facing app. The Cloud Run service is exposed at https://ingest.acme-data.io, while the single-page web app and an embedded mobile WebView both originate from https://dashboard.acme.io. You need to add a header to the service's HTTP response so that only pages and WebViews served from https://dashboard.acme.io can submit metrics via cross-origin requests. Which response header should you add?

Access-Control-Allow-Origin: * 는 모든 website origin이 cross-origin 요청을 보내고 응답을 읽을 수 있도록 허용합니다(다른 CORS 규칙의 적용을 받음). 이는 제출을 오직 https://dashboard.acme.io 로만 제한해야 한다는 요구 사항을 직접적으로 위반합니다. 단순성을 위해 매력적으로 보일 수 있고 CORS 문제 해결을 줄일 수는 있지만, 명시된 제한 사항을 준수하지 않으며 일반적으로 민감한 ingestion endpoint에는 권장되지 않습니다.

Access-Control-Allow-Origin 은 https://*.acme.io 와 같은 wildcard pattern을 지원하지 않습니다. CORS spec은 단일 명시적 origin, 리터럴 wildcard * 또는 allowlist에 포함된 경우 요청의 Origin을 동적으로 그대로 반환하는 방식만 허용합니다. 따라서 이 header 값은 browser에서 의도한 대로 동작하지 않으며 CORS 실패를 일으킬 가능성이 높아, 규정 준수 측면에서도 부적절하고 신뢰할 수 없습니다.

Access-Control-Allow-Origin: https://ingest.acme-data.io 는 origin이 ingestion domain 자체인 페이지에 대해서만 cross-origin 요청을 허용합니다. 하지만 호출하는 origin은 https://dashboard.acme.io 이므로 browser는 여전히 요청을 차단합니다. 이 선택지는 resource의 host(API가 실행되는 위치)와 요청을 보내는 origin(JavaScript/WebView 콘텐츠가 제공되는 위치)을 혼동하고 있습니다.

Access-Control-Allow-Origin: https://dashboard.acme.io 가 올바른 header인 이유는 CORS 결정이 API 자체의 hostname이 아니라 요청을 보내는 origin을 기준으로 이루어지기 때문입니다. 페이지가 해당 사이트에서 로드되어 Cloud Run endpoint로 JSON을 POST하려고 하면 browser 또는 WebView는 Origin header로 https://dashboard.acme.io 를 전송합니다. Access-Control-Allow-Origin 에 정확히 그 origin을 반환하면 browser에 이 특정 cross-origin 요청이 허용된다는 것을 알립니다. 이는 최소 권한 구성이며, https://dashboard.acme.io 에서 제공되는 페이지와 WebViews만 metrics를 제출할 수 있어야 한다는 요구 사항과 일치합니다.

문제 분석

핵심 개념: 이 문제는 Cloud Run HTTP 서비스에 대한 Cross-Origin Resource Sharing (CORS)를 테스트합니다. 브라우저는 Same-Origin Policy를 강제하므로, https://dashboard.acme.io 에 있는 웹 앱은 수집 서비스가 적절한 CORS 응답 헤더를 반환하지 않는 한 https://ingest.acme-data.io 로 POST할 수 없습니다. 핵심 헤더는 Access-Control-Allow-Origin이며, 이는 어떤 origin이 응답을 읽을 수 있는지(따라서 cross-origin 요청을 완료할 수 있는지)를 브라우저에 알려줍니다. 정답이 맞는 이유: 대시보드 웹 앱(그리고 동일한 origin을 사용하는 내장 WebView)만 cross-origin 요청을 통해 메트릭을 제출하도록 허용하려면, 서비스는 해당 단일 origin을 명시적으로 허용해야 합니다. 다음과 같이 설정하면: Access-Control-Allow-Origin: https://dashboard.acme.io cross-origin 접근을 정확히 그 origin으로만 제한합니다. 이는 “https://dashboard.acme.io 에서 제공되는 페이지만과 WebViews만”이라는 요구사항과 일치합니다. 실제로는 서비스가 preflight OPTIONS 요청(JSON POST에서 흔함)도 올바르게 처리하고 필요에 따라 Access-Control-Allow-Methods 및 Access-Control-Allow-Headers를 반환해야 하지만, 이 문제는 구체적으로 어떤 응답 헤더를 추가해야 하는지를 묻고 있습니다. 주요 특징 / 모범 사례: CORS는 Cloud Run 자체가 아니라 브라우저가 강제합니다. 애플리케이션(또는 proxy/API gateway)을 통해 구현합니다. 대용량 수집(50,000 rpm)의 경우 OPTIONS preflight 처리가 효율적이어야 하며 Access-Control-Max-Age로 preflight 응답 캐싱을 고려하세요. 또한 credentials가 관련된 경우 Access-Control-Allow-Origin에서 광범위한 wildcard를 안전하게 사용할 수 없고, 요청하는 Origin과 정확히 일치해야 합니다. 흔한 오해: 많은 사람들이 wildcard 서브도메인 패턴(예: https://*.acme.io)을 Access-Control-Allow-Origin에서 유효하다고 생각하지만, 그렇지 않습니다. 또 다른 오해는 허용 origin을 서비스 자체 도메인(ingest.acme-data.io)으로 설정하는 것인데, 이는 dashboard.acme.io가 호출하도록 허용하지 않습니다. 시험 팁: “브라우저에서 오직 이 사이트만 내 API를 호출할 수 있게”라면 Access-Control-Allow-Origin에 단일 명시적 origin을 선택하세요. 기억할 점: CORS는 브라우저 기반 cross-origin 요청에 관한 것이며, 서버-투-서버 호출은 CORS에 의해 차단되지 않습니다. 또한 유효하지 않은 wildcard 패턴과 “Origin”(scheme+host+port)과 URL path의 차이를 주의하세요.

4
문제 4

You are deploying a GKE Deployment for a background worker that pulls jobs from a Cloud Pub/Sub subscription. You must include a health check that verifies the container can reach the Pub/Sub endpoint every 10 seconds, with a 2-second timeout, and mark it unhealthy after 3 consecutive failures; if the worker becomes unhealthy due to lost connectivity, the container must execute /app/shutdown.sh (which can take up to 15 seconds) to gracefully drain and checkpoint work before termination. How should you configure the Deployment?

오답입니다. Kubernetes Job은 유한한 run-to-completion 작업을 위한 것이지, 장시간 실행되는 Deployment의 지속적인 health monitoring과 lifecycle 관리를 위한 것이 아닙니다. 별도의 Job은 kubelet 관점에서 특정 Pod/컨테이너를 unhealthy로 직접 표시할 수 없고, probe failure 시 graceful termination을 신뢰성 있게 조율하기도 어렵습니다. 이 접근은 복잡성만 늘리고, 문제에서 요구하는 probe 의미론(period/timeout/failureThreshold)을 충족하지 못합니다.

정답입니다. livenessProbe는 10초마다 2초 timeout으로 Pub/Sub reachability를 확인하고 3회 연속 실패 후 실패하도록(periodSeconds=10, timeoutSeconds=2, failureThreshold=3) 구성할 수 있습니다. liveness가 실패하면 kubelet이 컨테이너를 재시작합니다. preStop lifecycle hook은 termination 전에 /app/shutdown.sh를 실행하며, terminationGracePeriodSeconds >= 15초로 설정하면 drain/checkpoint 작업을 위해 스크립트가 완료될 수 있습니다.

오답입니다. postStart는 health check 메커니즘이 아니며 주기적 체크, timeout, failure threshold를 제공하지 않습니다. 컨테이너 시작 시 한 번만 실행됩니다. 또한 Kubernetes는 preStop을 “컨테이너가 failing일 때만” 조건부로 실행할 수 없고, preStop은 컨테이너가 종료될 때마다(restart, rollout, node drain) 실행됩니다. 이 선택지는 10초 단위의 지속적인 health verification 요구사항을 충족하지 못합니다.

오답입니다. initContainer는 main container가 시작되기 전에만 Pub/Sub connectivity를 검증할 수 있으며, 런타임 동안 10초마다 지속적으로 connectivity를 검증할 수는 없습니다. preStop이 /app/shutdown.sh를 두기에 적절한 위치인 것은 맞지만, 이 옵션의 health-check 메커니즘은 지속적인 probe 요구사항(periodSeconds/timeoutSeconds/failureThreshold)을 만족하지 못하고, 실행 중간에 발생하는 connectivity loss를 감지하지 못합니다.

문제 분석

핵심 개념: 이 문제는 GKE에서 Kubernetes의 health checking과 graceful termination 동작을 테스트합니다: liveness probe를 사용해 멈추거나(broken/stuck) 비정상인 컨테이너를 감지하고, lifecycle hook(preStop)과 terminationGracePeriodSeconds를 함께 사용해 깔끔한 종료를 허용하는 것입니다. 정답이 맞는 이유: 10초마다 2초 timeout으로 활성 health check를 수행하고, 3회 연속 실패 후 컨테이너를 unhealthy로 표시해야 합니다. 이는 livenessProbe의 periodSeconds: 10, timeoutSeconds: 2, failureThreshold: 3에 정확히 매핑됩니다. liveness probe가 반복적으로 실패하면 kubelet은 컨테이너를 unhealthy로 간주하고 재시작합니다. 컨테이너가 종료되기 전에 Kubernetes는 preStop lifecycle hook을 실행하는데, 바로 여기에 작업을 drain하고 상태를 checkpoint하기 위한 /app/shutdown.sh를 배치합니다. 스크립트가 최대 15초 걸릴 수 있으므로 terminationGracePeriodSeconds는 최소 15로 설정해야 하며(일반적으로 SIGTERM 처리와 hook 오버헤드를 고려해 조금 더 크게 설정), 그래야 정상 종료가 가능합니다. 주요 기능 / 구성: - livenessProbe: exec/httpGet/tcpSocket로 Pub/Sub endpoint reachability를 검증; periodSeconds=10, timeoutSeconds=2, failureThreshold=3으로 튜닝. - lifecycle.preStop: 종료 시( liveness 실패로 인한 restart 및 rolling update 포함) /app/shutdown.sh 실행. - terminationGracePeriodSeconds: preStop hook과 app shutdown이 완료되기 전에 Pod가 SIGKILL되지 않도록 보장. - (Best practice) readinessProbe를 사용해 “처리 가능(can process)”과 “트래픽을 받아야 함(should receive traffic)”을 분리하는 것을 고려할 수 있지만, 요구사항은 명시적으로 “unhealthy로 표시”이므로 liveness에 부합합니다. 흔한 오해: 많은 사람들이 initContainers 또는 postStart hook을 지속적인 health check와 혼동합니다. initContainers는 시작 시 한 번만 실행되며 지속적인 connectivity를 강제할 수 없습니다. postStart는 health check가 아니며, 그 실패는 문제에서 요구하는 주기적/threshold 기반 의미론을 제공하지 않습니다. 또한 Kubernetes에는 “실패할 때만 preStop 실행” 같은 내장 조건부 기능이 없고, preStop은 종료 이유와 무관하게 termination 시 항상 실행됩니다. 시험 팁: 재시작/eviction 시 graceful drain이 필요한 GKE workload에서는 liveness/readiness probe를 preStop 및 충분한 terminationGracePeriodSeconds와 결합하세요. probe 타이밍 파라미터를 기억하세요: periodSeconds는 빈도, timeoutSeconds는 시도당 timeout, failureThreshold는 조치 전 연속 실패 횟수입니다. 이는 Pub/Sub 또는 기타 외부 dependency를 소비하는 background worker에서 흔한 패턴입니다.

5
문제 5

Your mobile gaming platform’s matchmaking service (running on Cloud Run behind an external HTTP(S) Load Balancer) has been instrumented with OpenTelemetry and uses a 10% sampling rate; you need to validate end-to-end latency in Cloud Trace for a single test curl request from your laptop without changing the global sampler. How can you guarantee that this specific request is traced regardless of the default sampling decision?

기다리는 것은 확률에 의존할 뿐 확실성이 없습니다. 10% sampling rate에서는 단일 요청이 tracing되지 않을 확률이 90%이며, 시간 경과는 특정 1회성 curl에 대해 이를 바꾸지 못합니다. 이는 특정 요청 하나에 대해 tracing을 보장해야 한다는 요구사항을 충족하지 못하며, 비결정론적이므로 검증을 위한 운영 관행으로도 좋지 않습니다.

요청을 반복 전송하면 최소 한 요청이 sample될 가능성은 높아지지만, 관심 있는 특정 테스트 요청이 캡처된다는 것을 여전히 보장할 수는 없습니다. 또한 불필요한 트래픽을 추가하고, metric을 왜곡할 수 있으며, 추가 비용이 발생할 수 있습니다. 결정론과 최소 영향을 강조하는 시험 시나리오에서는 brute-force retry가 올바른 접근이 아닙니다.

Cloud Trace API는 span을 작성하거나 trace에 annotation을 추가할 수 있지만, unsampled 요청을 end-to-end로 사후에 강제로 캡처하게 만들지는 못합니다. Sampling 결정은 일반적으로 instrumentation/SDK에서 trace 생성 시점에 이루어집니다. Custom attribute는 기존 span을 풍부하게 할 뿐, sampler를 override하거나 원래 drop되었을 요청이 tracing되도록 보장하지 않습니다.

유효한 trace ID, span ID, 그리고 o=1이 포함된 X-Cloud-Trace-Context를 추가하는 것은 해당 개별 요청에 대한 명시적인 sampling 결정을 전달하는 유일한 선택지입니다. Google Cloud tracing 시나리오에서 이 header는 Google 전용 trace propagation 형식이며, sampled bit는 해당 요청이 traced되어야 함을 알리기 위한 용도입니다. 따라서 전역 sampler를 변경하거나 우연에 의존하는 대신 하나의 요청을 직접 대상으로 하기 때문에 시험 정답으로 올바릅니다. 실제로 정확한 동작은 Cloud Run 서비스와 해당 OpenTelemetry propagator가 들어오는 header를 따르는지에 따라 달라지지만, 제시된 선택지 중에서는 분명히 가장 적절하고 기대되는 해결책입니다.

문제 분석

핵심 개념: 이 문제는 external HTTP(S) Load Balancer 뒤에 있는 Cloud Run 서비스에 대해 요청별 trace sampling 제어를 다룹니다. 애플리케이션의 전역 sampling rate를 변경하지 않고 특정 요청 하나를 검사해야 할 때, 올바른 접근 방식은 해당 요청이 sampled로 명시되도록 trace context를 전송하여 tracing stack이 그 결정을 따르도록 하는 것입니다. Google Cloud 환경에서는 X-Cloud-Trace-Context가 Google 전용 propagation header이며, sampled 플래그는 o=1로 표현됩니다. 정답인 이유: 옵션 D가 최선의 정답인 이유는 확률이나 사후 처리에 의존하지 않고 trace context에 명시적인 요청별 sampling 결정을 전달하려는 유일한 선택지이기 때문입니다. 서비스와 tracing 구성이 들어오는 trace context를 따르는 경우, 유효한 trace ID/span ID와 o=1을 설정하면 해당 요청은 sampled로 처리되며, 이는 단일 요청 경로를 검증하기 위한 표준적인 targeted-debugging 기법입니다. 주요 특징: - X-Cloud-Trace-Context에는 trace ID, span ID, 그리고 trace options 필드가 포함됩니다. - o=1 플래그는 해당 요청이 sampled되어야 함을 나타냅니다. - 이 접근 방식은 일회성 검증을 위해 설계되었으며 전역 sampling rate를 높이거나 불필요한 트래픽을 생성하는 일을 피합니다. - 확률적 재시도보다 더 바람직한 이유는 요청 metadata에서 의도를 직접 표현하기 때문입니다. 흔한 오해: 흔한 실수 중 하나는 반복 요청을 하거나 더 오래 기다리면 특정 요청이 캡처된다는 보장이 있다고 가정하는 것이지만, 그렇지 않습니다. 또 다른 오해는 Trace API가 이미 unsampled된 요청을 Cloud Trace에 강제로 나타나게 할 수 있다고 생각하는 것이지만, sampling 결정은 일반적으로 instrumentation이 trace를 생성할 때 내려집니다. 또한 일부 OpenTelemetry 설정은 주로 W3C traceparent/tracestate를 사용하므로, X-Cloud-Trace-Context를 따를지는 구성된 propagator와 환경에 따라 달라집니다. 시험 팁: 문제에서 'single request', 'do not change the global sampler', 그리고 tracing을 'guarantee' 또는 'force'하라고 하면, sampled 플래그가 포함된 trace context를 주입하는 선택지를 찾으세요. Google Cloud 시험에서는 해당 header가 선택지로 제공될 때 X-Cloud-Trace-Context와 o=1이 기대되는 패턴이며, 실제 환경에서의 동작은 tracing library 구성에 따라 달라질 수 있습니다.

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

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

6
문제 6

Your analytics team needs to run a 30-minute spike test reaching up to 8,000 requests per second against a new HTTPS API running on GKE Autopilot in us-central1 using JMeter. You must generate load from a consistent, in-region source, capture request and latency logs for rapid analysis, and publish a dashboard within 1 hour after the test. Following Google-recommended practices, which setup should you use to orchestrate the test and analysis?

로컬에서 JMeter를 실행하면 집/사무실 네트워크와 인터넷 경로가 변동성을 유발하고 8,000 RPS를 안정적으로 유지하지 못할 수 있으므로, 일관된 리전 내 소스 요구사항을 위반합니다. 로그를 BigQuery로 내보내는 것은 신속한 분석에 좋지만, Looker(enterprise)는 이미 프로비저닝되어 있지 않다면 1시간 내 달성하기 어려울 수 있습니다. 가장 큰 문제는 리전 외의 일관되지 않은 부하 생성입니다.

us-central1의 Compute Engine은 리전 내 부하 생성기로 좋은 선택입니다. 하지만 Cloud Storage로 로그를 sink하는 것은 신속한 분석에 적합하지 않습니다. 로그가 파일 형태로 저장되며, 지연 시간 퍼센타일 계산과 인터랙티브 차트 구축을 효율적으로 하려면 보통 추가 ETL(예: BigQuery로 로드)이 필요하기 때문입니다. Looker Studio는 대시보드에 빠르지만, Storage sink가 분석 워크플로를 느리게 만듭니다.

이 옵션에는 두 가지 단점이 있습니다. 첫째, Cloud Storage로 로그를 내보내는 것은 빠른 쿼리보다는 보존/아카이빙에 더 적합하여 1시간 내 신속한 분석을 어렵게 만듭니다. 둘째, Looker(enterprise)는 보통 Looker Studio보다 설정이 더 무겁기 때문에, 이미 배포되어 연결되어 있지 않다면 대시보드 게시가 지연될 수 있습니다. 리전 내 JMeter VM은 맞지만, 분석 스택이 적절하지 않습니다.

us-central1의 Compute Engine은 GKE Autopilot API에 가까운 일관되고 제어 가능한 부하 소스를 제공하여 재현성을 높이고 네트워크 노이즈를 줄입니다. Cloud Logging sink to BigQuery는 대규모 요청/지연 시간 로그에 대해 즉시 SQL 분석을 가능하게 하며, 오류율과 지연 시간 퍼센타일을 빠르게 계산하는 데 이상적입니다. Looker Studio는 BigQuery에 직접 연결되며 1시간 내 공유 가능한 대시보드를 게시하는 가장 빠른 방법입니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서의 실무적 부하 테스트와 신속한 관측 가능성(Observability)을 평가합니다. 즉, 리전 내 트래픽 생성(인터넷 변동성 회피), 빠른 쿼리를 위한 Cloud Logging 데이터 내보내기, 그리고 Google 권장 저마찰(low-friction) 도구로 대시보드를 신속히 구축하는 능력입니다. 정답이 맞는 이유: us-central1의 GKE Autopilot에서 동작하는 HTTPS API에 대해 30분 동안 최대 8,000 RPS까지 스파이크를 주려면, 일관된 리전 내 부하 생성기가 필요합니다. us-central1의 Compute Engine VM에서 JMeter를 실행하면 대상과 가까운 안정적이고 제어 가능한 소스를 제공하여, 로컬 머신 대비 지연 시간 노이즈와 egress 예측 불가능성을 최소화합니다. 또한 “신속한 분석을 위한 요청 및 지연 시간 로그 캡처” 요구에는 BigQuery로 로그를 내보내는 것이 최적입니다. BigQuery는 즉시 SQL 기반 탐색, 집계(p50/p95/p99), 그리고 대규모 필드 조인을 가능하게 합니다. 마지막으로 “1시간 내 대시보드 게시”는 BigQuery에 직접 연결해 거의 실시간 차트를 만들 수 있고 설정이 빠른 Looker Studio(무료)와 가장 잘 부합합니다. 주요 기능 / 모범 사례: - us-central1의 Compute Engine VM: 일관된 네트워크 경로, 예측 가능한 처리량, 8,000 RPS를 위한 CPU/네트워크 사이징 가능(필요 시 수평 확장도 가능). - Cloud Logging sink to BigQuery: 구조화된 로그 분석, 빠른 애드혹 쿼리, BI 도구와의 쉬운 통합. - Looker Studio + BigQuery: Looker(enterprise) 인프라를 프로비저닝하지 않고도 공유 가능한 대시보드로 가는 가장 빠른 경로. 이는 운영 우수성과 관측 가능성에 관한 Google Cloud Architecture Framework 원칙(텔레메트리 중앙화, 쿼리 가능하게 만들기, 신속한 피드백 제공)을 따릅니다. 흔한 오해: Cloud Storage sink는 아카이빙 및 배치 처리에는 좋지만, 파일을 파싱하고 분석 엔진에 로드해야 하므로 “신속한 분석”에는 속도가 떨어집니다. Looker(enterprise)는 강력하지만, 이미 배포 및 구성되어 있지 않다면 보통 1시간 내에 세팅하기 가장 빠른 선택지는 아닙니다. 시험 팁: 로그/지연 시간의 “신속한 분석”이 보이면 BigQuery sink를 떠올리세요. “대시보드를 빠르게 게시”가 보이면 Looker Studio를 떠올리세요. 부하 생성은 로컬 머신을 피하고, 변동성을 줄이고 재현성 요구를 충족하기 위해 리전 내 컴퓨팅(대개 Compute Engine)을 사용하세요.

7
문제 7

You containerized a Node.js API and deployed it to Cloud Run (2 vCPU, 1 GiB RAM, max concurrency 80, min instances 0); locally the /orders endpoint averages 120 ms per request under a load test of 200 RPS, but in production Cloud Monitoring shows p95 latency at 1.6 s with CPU at ~30% and memory at ~45%, and you want to pinpoint which parts of the code are causing the delay in production with minimal overhead and without adding custom timing code. What should you do?

Support ticket은 코드 수준 latency 분석을 위한 올바른 첫 단계가 아닙니다. 증상(p95 latency는 높지만 CPU/memory는 낮음)은 플랫폼 장애라기보다 애플리케이션 동작 또는 dependency latency를 시사합니다. 시험에서는 보통 support로 escalation하기 전에 내장 관측 가능성 도구(Profiler/Trace/Monitoring)를 사용해 근거를 수집하기를 기대합니다.

Cloud Debugger snapshot은 앱을 중단하지 않고 특정 코드 위치에서 변수와 stack trace를 캡처할 수 있어 로직 버그 진단에 유용합니다. 하지만 요청 전반에 걸친 집계된 성능 데이터를 제공하거나, 여러 요청에서 대부분의 wall time이 어디에 쓰이는지 식별하지는 못합니다. latency hotspot을 찾거나 어떤 함수가 p95 latency를 지배하는지 정량화하는 데 최적의 도구가 아닙니다.

Cloud Profiler가 최선의 선택인 이유는 프로덕션에서 매우 낮은 오버헤드로 어떤 함수와 호출 경로가 CPU time을 소비하는지, 그리고 특히 여기서 중요한 wall time을 소비하는지를 식별하기 때문입니다. custom timing code를 추가할 필요가 없고, CPU가 포화되지 않은 상황에서도(예: I/O waits, blocking calls, contention) 높은 latency를 설명하는 데 도움이 됩니다. 이는 프로덕션에서 지연을 유발하는 코드 영역을 pinpoint하라는 요구사항과 직접적으로 일치합니다.

광범위한 타이밍 log 추가는 수동 계측(manual instrumentation)의 한 형태이며 custom timing code를 피하라는 요구사항에 위배됩니다. 또한 오버헤드(요청당 추가 작업)를 유발하고, log volume과 비용을 증가시키며, latency 측정을 왜곡할 수 있습니다. hotspot을 드러낼 수는 있지만, Cloud Profiler에 비해 최소 오버헤드의 모범 사례 접근법은 아닙니다.

문제 분석

핵심 개념: 이 문제는 관리형 관측 가능성 도구를 사용하여 Cloud Run에서 프로덕션 성능을 진단하는 능력을 평가하며, 특히 Cloud Profiler(Google Cloud Observability의 일부)를 다룹니다. 목표는 코드에 계측을 추가하지 않고 최소한의 오버헤드로 코드 수준의 지연 기여 요인(CPU time 및 wall time)을 찾는 것입니다. 정답이 맞는 이유: Cloud Profiler는 프로덕션에서 실행 중인 애플리케이션을 지속적으로 샘플링하고, 리소스 사용량과 지연을 특정 함수 및 호출 경로에 귀속하도록 설계되었습니다. 이 시나리오에서는 p95 latency가 높음(1.6 s)에도 CPU(~30%)와 memory(~45%)가 포화 상태가 아니므로, 병목은 I/O 대기(database/network), lock contention, 동기식 blocking, 또는 Cloud Run의 런타임 조건(cold starts, 다른 network path, upstream dependencies)에서 드러나는 비효율적인 코드 경로일 수 있습니다. Profiler의 wall-time profile은 CPU가 최대치가 아니더라도 시간이 어디에 소비되는지 정확히 짚어내며, 광범위한 logging에 비해 매우 낮은 오버헤드로 이를 수행합니다. 주요 기능 / 모범 사례: Cloud Profiler는 Node.js를 지원하며 CPU 및 wall-time profile을 수집하도록 활성화할 수 있습니다. Cloud Monitoring/Trace context와 통합되어 hot function, 느린 call stack, 버전 간 regression을 식별하는 데 도움이 됩니다. 이는 Google Cloud Architecture Framework의 Operational Excellence 원칙과도 잘 부합합니다: 관리형 관측 가능성을 사용하고, 프로덕션에서 측정하며, 진단의 성능 영향을 최소화합니다. Cloud Run에서는 일반적으로 container에 Profiler agent를 활성화하고 service name/version을 구성하여 revision 간 profile을 비교할 수 있게 합니다. 흔한 오해: Cloud Debugger(snapshot)는 종종 profiling과 혼동됩니다. Debugger는 특정 시점의 상태와 변수를 검사하기 위한 것이지, 지연 hotspot을 체계적으로 찾기 위한 도구가 아닙니다. 타이밍 log를 추가하는 방식은 가능할 수 있지만, “최소 오버헤드” 및 “custom timing code를 추가하지 않음” 요구사항을 위반하며 latency와 비용을 증가시킬 수 있습니다. 시험 팁: “프로덕션에서 어떤 코드 부분이 지연을 유발하는지 pinpoint”해야 하고 “최소 오버헤드”, “custom timing 없음”이 조건이면 Cloud Profiler를 떠올리세요. Debugger는 상태 검사, Trace는 서비스 간 request-level latency 분해, Logging은 이벤트 기록에 사용하며, high-cardinality/high-volume 타이밍 계측에는 적합하지 않습니다.

8
문제 8

Your data engineering team maintains batch analytics jobs packaged as containers and stored in an Artifact Registry repository named analytics-jobs in europe-west1. Images can be pushed from multiple paths: a standard CI sequence, ad hoc docker push from engineers' laptops during on-call hotfixes, and occasional emergency retags. You are responsible for configuring CI/CD automation in Cloud Build. Every time any new image or tag is pushed to Artifact Registry, a separate Cloud Build pipeline must start within 1 minute to run a vulnerability scan and write results to a BigQuery dataset. You want to meet this requirement with the least engineering effort and without missing manual pushes. What should you do?

이것이 가장 직접적인 managed 설계입니다. Artifact Registry는 image push와 tag change에 대한 event를 Pub/Sub에 publish할 수 있고, Cloud Build는 해당 message가 도착할 때 vulnerability scanning pipeline을 시작하도록 Pub/Sub trigger를 사용할 수 있습니다. 즉, trigger가 특정 workflow 하나가 아니라 registry event에 연결되므로 standard CI, laptop에서 engineer가 push하는 경우, emergency retag를 포함한 모든 push 경로가 포괄됩니다. 또한 custom code나 polling logic를 유지할 필요가 없으므로 최소한의 운영 노력으로 1분 이내 요구 사항도 충족합니다.

이 접근 방식은 하나의 producer 경로, 즉 standard CI pipeline만 계측합니다. 문제에서는 image가 engineer의 laptop에서 수동으로 push되거나 emergency retag를 통해서도 push될 수 있다고 명시하고 있으므로, 이러한 event는 custom Pub/Sub message를 발생시키지 않으며 누락됩니다. 요구 사항은 모든 새로운 image 또는 tag push마다 trigger되는 것이므로, 이 설계는 불완전합니다. 또한 repository를 system of record로 사용하는 대신 하나의 CI 구현과 scanning workflow를 결합하게 됩니다.

기술적으로는 동작하겠지만, engineering effort가 가장 적은 방법은 아닙니다. Cloud Function을 도입하면 Cloud Build가 이미 Pub/Sub에서 직접 trigger될 수 있음에도 불구하고 배포, 보안 설정, 모니터링, 유지 관리해야 할 추가 구성 요소가 생깁니다. 시험 문제에서는 native integration이 존재할 때 serverless bridge를 추가하는 것은 일반적으로 불필요한 복잡성으로 간주됩니다. 따라서 이 선택지는 Artifact Registry에서 Pub/Sub를 거쳐 Cloud Build trigger로 직접 연결하는 경로보다 덜 최적입니다.

5분 polling interval은 별도의 Cloud Build pipeline이 push 후 1분 이내에 시작되어야 한다는 요구 사항을 명백히 위반합니다. 또한 polling은 이전에 확인한 tag 또는 digest를 추적하고, deduplication을 처리하며, race condition을 피하기 위한 추가 logic를 필요로 합니다. 이는 event-driven notification과 비교해 engineering effort와 운영 복잡성을 증가시킵니다. Artifact Registry가 이미 event publication을 지원하므로, 여기서 polling은 잘못된 패턴입니다.

문제 분석

핵심 개념: event-driven integration을 사용하여 모든 Artifact Registry image push 또는 tag update가 event를 발생시키고, 그 event가 즉시 별도의 Cloud Build pipeline을 시작하도록 합니다. 정답인 이유: Artifact Registry는 repository event를 Pub/Sub에 publish할 수 있고, Cloud Build는 Pub/Sub trigger를 지원하므로 image push에서 build 실행까지 직접적인 managed 경로를 제공합니다. 주요 특징: 이 방식은 CI, 수동 docker push, retag를 포함한 모든 push source를 포착합니다. 또한 거의 실시간으로 동작하며 일반적으로 1분 요구 사항을 충분히 충족합니다. 그리고 custom glue code를 피할 수 있습니다. 흔한 오해: CI만 수정하는 방식은 manual push를 포괄하지 못하며, Cloud Build가 이미 Pub/Sub를 subscribe할 수 있으므로 Cloud Functions를 추가하는 것은 불필요합니다. 시험 팁: 요구 사항이 모든 producer, 낮은 지연 시간, 최소한의 engineering effort를 강조할 때는 custom bridging이나 polling보다 native event source와 native trigger를 우선 선택하세요.

9
문제 9
(2개 선택)

Your media analytics company is breaking a legacy ad-serving platform into roughly 40 independently deployable microservices running on Google Kubernetes Engine (GKE) and Cloud Run; three consumer teams (Java, Go, and Python) will integrate with these services, weekly releases must not break existing clients, backward compatibility must be maintained for at least 12 months, average per‑service load is 600 RPS with p95 latency SLO of 200 ms and bursts up to 2,500 RPS during major events, and you need to choose which design aspects to implement to meet these requirements while enabling composability and team autonomy; which two should you prioritize? (Choose two.)

단일 언어로 표준화하면 인지 부하를 줄일 수 있지만, 3개의 consumer 팀(Java, Go, Python)이 통합할 것이라는 요구사항과 충돌합니다. 단일 언어 강제는 자율성을 낮추며 마이크로서비스 생태계에서 현실적으로 어려운 경우가 많습니다. 또한 구현 언어와 무관하게 깨지는 API 변경은 발생할 수 있으므로 backward compatibility를 보장하지도 않습니다. 시험에서는 조직적 강제보다 언어 중립적인 interface contract를 더 선호하는 경향이 있습니다.

명확한 API contract(OpenAPI/proto)는 composability와 팀 자율성의 기반입니다. 이는 contract-first 개발, 다중 언어를 위한 code generation, 일관된 error handling, 그리고 릴리스 전에 breaking change를 탐지하기 위한 CI에서의 자동 validation을 가능하게 합니다. 이는 기존 client를 깨뜨리지 않으면서 주간 릴리스를 직접적으로 지원하며, 다중 팀 마이크로서비스 환경에서 가장 중요한 integration 설계 요소입니다.

Asynchronous, event-driven 통신은 decoupling을 개선하고 burst를 흡수할 수 있지만, 모든 상호작용을 async로 요구하는 것은 적절하지 않습니다. 많은 use case는 synchronous request/response가 필요합니다(예: 200 ms p95 SLO가 있는 ad serving 경로). Event-driven 설계는 ordering, duplication, schema-evolution 문제도 도입하며, event에 대해서도 여전히 명시적 contract와 versioning이 필요합니다. 이는 도구이지, 보편적 요구사항이 아닙니다.

항상 peak(2,500 RPS)에 맞춰 replica를 사전 프로비저닝하는 것은 비효율적이고 비용이 많이 들며, backward compatibility 문제를 해결하지도 않습니다. Cloud Run에서는 일반적으로 autoscaling과 concurrency에 의존하고, GKE에서는 burst를 처리하기 위해 HPA/VPA와 cluster autoscaler를 사용합니다. 고정된 peak capacity를 유지하면 스파이크 시 latency에는 도움이 될 수 있지만, 12개월 compatibility를 위한 interface stability와 versioning에 비해 우선순위가 아닙니다.

Versioning 전략은 backward-incompatible 변경을 지원하면서 최소 12개월 동안 기존 client를 유지하기 위해 필수입니다. 일반적인 패턴으로는 /v1 및 /v2 endpoint, header 기반 version, 또는 protobuf package/service versioning이 있습니다. Versioning은 구/신 인터페이스의 병렬 운영, 통제된 deprecation, 예측 가능한 client migration 타임라인을 가능하게 하며—독립적 배포와 빈번한 릴리스에 핵심입니다.

문제 분석

핵심 개념: 이 문제는 마이크로서비스를 위한 API 설계를 평가합니다. 즉, contract-first 인터페이스와 명시적 versioning을 통해 독립적 배포, 다중 언어 consumer, 그리고 장기간의 backward compatibility를 가능하게 하는 것입니다. 이는 Google Cloud Architecture Framework의 Reliability(깨지는 변경 방지), Operational Excellence(명확한 소유권 경계), Performance/Scalability(클라이언트를 불안정하게 만들지 않으면서 효율적으로 진화할 수 있는 인터페이스) 원칙과 일치합니다. 정답이 맞는 이유: 약 40개의 독립 배포 가능한 서비스와 3개의 consumer 팀(Java/Go/Python)이 있는 상황에서, 주간 릴리스의 가장 큰 리스크는 client integration을 깨뜨리는 것입니다. 가장 효과가 큰 두 가지 설계 요소는 (B) 명확하고 강제 가능한 API contract와 (E) versioning 전략입니다. contract(OpenAPI 기반 REST 또는 gRPC용 protobuf)는 request/response 형태, error model, semantics를 정의하여 팀들이 독립적으로 개발하고 자동화된 compatibility check로 변경을 검증할 수 있게 합니다. versioning은 backward-incompatible 변경을 위한 통제된 경로를 제공하면서 최소 12개월 동안 이전 버전을 유지하여, 제시된 요구사항을 충족합니다. 주요 기능 / Best Practices: - Contract-first 개발: OpenAPI/Proto schema를 게시하고, Java/Go/Python용 client SDK를 생성하며, 배포 전에 CI check(예: OpenAPI/proto의 breaking-change detection)를 사용합니다. - Backward compatibility: additive 변경(새 optional field 추가)을 선호하며, field rename/remove는 피합니다. - Versioning 패턴: URI versioning(예: /v1, /v2), header 기반 versioning, 또는 protobuf package/service versioning; 12개월 deprecation window 동안 v1과 v2를 동시에 운영합니다. - GKE/Cloud Run에서는 progressive delivery(canary/blue-green)와 SLO monitoring을 함께 적용할 수 있지만, 이 문항에서는 interface stability가 그보다 우선입니다. 흔한 오해: 팀들은 종종 단일 언어 강제(A)나 모든 것을 event-driven async로 의무화(C)하여 compatibility를 “해결”하려고 합니다. 이는 일부 맥락에서는 도움이 될 수 있지만, 이질적인 consumer 전반에서 깨지지 않는 주간 릴리스를 직접적으로 보장하지는 않습니다. 마찬가지로 peak capacity를 사전 프로비저닝(D)하는 것은 burst 성능에는 도움이 되지만 interface evolution에는 도움이 되지 않으며, 일반적으로 autoscaling과 right-sizing이 더 적절합니다. 시험 팁: 요구사항이 독립적 배포, 여러 consumer 언어, 그리고 긴 backward-compatibility 기간을 강조한다면, API contract + versioning을 우선시하세요. GCP 마이크로서비스(GKE/Cloud Run)에서는 scalability 전술(autoscaling, concurrency, HPA)이 중요하지만, 이는 엄격한 interface governance 및 deprecation/version policy를 대체하지 못합니다.

10
문제 10

You must stress-test a GraphQL mutation webhook hosted on Cloud Functions (2nd gen) behind HTTPS. The endpoint accepts HTTP POST requests with a 1 KB JSON payload and must sustain burst traffic of 5,000 requests per second for 3 minutes. Your load tests must meet the following requirements: • Load is initiated from multiple parallel threads per generator. • Client traffic to the endpoint originates from multiple source IP addresses. • Load can be scaled up by adding additional test instances as needed. • Test runs are repeatable and provide latency/throughput metrics. You want to follow Google-recommended best practices. How should you configure the load testing?

Managed instance group(MIG)는 autoscaling과 일관된 VM template을 제공하지만, cURL + shell loop는 반복 가능하고 메트릭이 풍부한 테스트를 위한 모범 사례 접근이 아닙니다. 제어된 ramp-up, 병렬 사용자 동작, 집계된 latency percentile을 포함해 5,000 RPS를 조정하는 것은 어렵습니다. 또한 egress IP 할당을 명시적으로 설계하지 않으면 소스 IP 다양성도 보장되지 않습니다. 단순히 VM을 확장하는 것만으로는 통제된 방식으로 여러 client IP를 보장하지 못합니다.

Unmanaged instance group은 핵심 운영 모범 사례(autoscaling 없음, self-healing 없음, rolling update 없음)를 제거하여 반복 가능한 테스트 실행을 더 어렵게 만듭니다. 옵션 A와 마찬가지로 cURL loop는 내장 조정, 현실적인 사용자 모델링, latency 및 throughput 메트릭의 견고한 리포팅/집계가 부족합니다. 또한 운영 부담과 생성기 구성 불일치 위험을 증가시켜, 반복 가능한 테스트 및 Google 권장 모범 사례 요구사항과 충돌합니다.

GKE는 분산 부하 테스트에 적합합니다: controller와 다수의 worker Pod를 실행하고, replica와 node를 확장하여 5,000 RPS에 도달하며, 도구의 메트릭을 사용해 latency/throughput 리포팅을 수행할 수 있습니다. 각 생성기당 여러 병렬 스레드는 Locust/JMeter worker가 지원합니다. 여러 소스 IP는 worker를 여러 노드에 분산하고 Cloud NAT를 여러 external IP로 구성하여 달성할 수 있습니다. 컨테이너화와 manifest를 통해 실행을 반복 가능하고 확장 가능하게 만들 수 있습니다.

Cloud Shell은 대화형 관리 목적이며 resource/session 제약이 있어, 몇 분 동안 지속되는 5,000 RPS 버스트에 적합하지 않습니다. 여러 container를 “순차적으로” 시작하는 것은 신뢰할 수 있는 확장 전략이 아니며, Cloud Shell은 반복성, 동시성 제어, 안정적인 소스 IP 다양성에 대한 강한 보장을 제공하지 않습니다. 또한 성능 테스트에 대해 Google 권장 모범 사례에서 기대하는 운영 제어 및 관측성 통합도 부족합니다.

문제 분석

핵심 개념: 이 문제는 분산 부하 테스트 프레임워크를 사용하여 Google Cloud에서 확장 가능하고, 반복 가능하며, 메트릭 기반의 부하 테스트를 실행하는 방법을 평가합니다. 병렬성, 여러 소스 IP, 수평 확장성을 통해 높은 RPS를 생성하는 모범 사례를 강조합니다. 정답이 맞는 이유: GKE (Google Kubernetes Engine)에서 Locust 또는 Apache JMeter 같은 분산 프레임워크를 실행하는 것이 모든 제약 조건을 만족하면서 3분 동안 5,000 requests/second 버스트를 달성하는 가장 적절한 방법입니다. controller/leader가 테스트 플랜을 조정하고 결과를 집계하며, worker Pod가 병렬 스레드/프로세스로 부하를 생성합니다. worker replica 수 및/또는 node pool 크기를 늘려 부하를 확장할 수 있습니다. 트래픽이 여러 노드(그리고 잠재적으로 여러 NAT egress IP)에서 발생하므로, “여러 소스 IP 주소” 요구사항을 통제 가능하고 반복 가능한 방식으로 충족할 수 있습니다. 주요 기능 / 구성(모범 사례): - 부하 생성기 전용 node pool을 가진 GKE cluster(프라이빗도 가능)를 사용하고, node pool과 worker replica를 확장하여 목표 RPS에 도달합니다. - egress가 Cloud NAT를 사용하도록 보장합니다. 여러 소스 IP를 보장하려면 여러 external NAT IP address를 할당하고 Cloud NAT가 이를 사용하도록 구성합니다(또는 필요 시 여러 node pool/region을 사용). - 프레임워크의 내장 메트릭(latency percentile, throughput, error rate)을 사용하고 Cloud Monitoring/Cloud Logging으로 export하여 반복 가능한 리포팅을 수행합니다. - 반복성과 버전 관리된 테스트 플랜을 위해 container image와 선언적 manifest(Deployment/Job)를 사용합니다. 흔한 오해: VM에서 단순 cURL loop(A/B)를 사용하는 것은 간단해 보이지만, 견고한 조정, 반복성, 풍부한 메트릭이 부족하고, 대규모에서 병렬 사용자 동작을 안정적으로 생성하고 제어하기 어렵습니다. Cloud Shell(D)은 지속적인 고처리량 분산 테스트를 위해 설계되지 않았고 session limit 및 resource quota의 제약을 받습니다. 시험 팁: GCP에서 대규모 부하 테스트를 할 때는 수평 확장, 중앙 집중 제어, 메트릭을 제공하므로 GKE에서 컨테이너화된 분산 부하 도구(또는 사용 가능할 때 managed load testing service)를 선호합니다. 또한 “여러 소스 IP”는 일반적으로 단일 노드에서 스레드나 Pod를 늘리는 것만으로는 부족하며, 여러 egress IP(예: 여러 address를 사용하는 Cloud NAT)가 필요하다는 점을 기억하세요.

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

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