CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Professional Cloud DevOps Engineer
Google Professional Cloud DevOps Engineer

Practice Test #1

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

Your company runs a payments API behind an NGINX Ingress Controller on a GKE Standard cluster with three n2-standard-4 nodes; the Ops Agent DaemonSet is deployed on all nodes and forwards access logs to Cloud Logging. In the past hour you observed suspicious traffic from the IP address 198.51.100.77, and you need to visualize the per-minute count of requests from this IP in Cloud Monitoring without changing application code or deploying additional collectors. What should you do to achieve this with minimal operational overhead?

정답입니다. 이는 기존 로그 ingest(Ops Agent -> Cloud Logging)를 활용하고, managed logs-based counter metric으로 매칭되는 log entry를 Monitoring time series로 변환합니다. client IP(198.51.100.77)로 filtering하면 60-second alignment로 차트화했을 때 분당 요청 수가 산출됩니다. 애플리케이션 변경 없음, 추가 collector 없음이라는 제약을 만족하며, 운영 오버헤드가 최소입니다.

오답입니다. 로그를 스크레이프하고 custom metrics를 push하는 CronJob은 운영 부담(스케줄링, 권한, 재시도, 스케일링, 파싱 정확성)을 추가하며, 부하나 log rotation 상황에서 취약합니다. 또한 logs-based metrics가 이미 제공하는 기능을 중복합니다. 동작할 수는 있지만 “최소 운영 오버헤드” 요구사항을 위반하며, 권장되는 managed 접근이 아닙니다.

오답입니다. payments API를 수정해 IP별 counter를 export하려면 애플리케이션 코드 변경, 재배포, 그리고 metric cardinality 관리가 필요합니다(per-IP metrics는 cardinality와 비용이 폭증할 수 있음). 문제에서 애플리케이션 코드 변경을 명시적으로 금지합니다. OpenTelemetry를 쓰더라도, 필요한 신호가 이미 ingress access logs에 존재하므로 불필요하게 무겁습니다.

오답입니다. Ops Agent metrics receiver는 시스템 및 지원되는 애플리케이션 metrics(CPU, memory, disk, 일부 service metrics)를 수집하지만, access logs로부터 client IP별 요청 수를 추론하지는 않습니다. IP별 요청 데이터는 보통 HTTP access logs 또는 특화된 L7 telemetry에서만 얻을 수 있습니다. node/application metrics에 의존하면 특정 IP에 대한 분당 카운트를 만들 수 없습니다.

문제 분석

핵심 개념: 이 문제는 GKE에서의 Google Cloud observability 패턴을 테스트합니다: 기존 로그 스트림(Ops Agent를 통해 이미 Cloud Logging에 들어와 있는 NGINX Ingress access logs)을 애플리케이션 코드 변경이나 collector 추가 없이, logs-based metrics를 사용해 Cloud Monitoring의 time-series 데이터로 변환하는 방법입니다. 정답이 맞는 이유: 이미 ingress access logs가 Cloud Logging에 중앙화되어 있습니다. “특정 client IP에서 분당 요청 수”를 시각화하는 가장 낮은 오버헤드 방식은 client IP가 198.51.100.77인 log entry를 매칭하는 logs-based counter metric을 만드는 것입니다. Cloud Logging이 매칭되는 entry를 카운트하고 해당 metric을 Cloud Monitoring으로 내보내며, Cloud Monitoring에서 1-minute alignment/aggregation으로 차트화할 수 있습니다. 이 접근은 managed, scalable하며 클러스터에 새로운 runtime component가 필요하지 않습니다. 주요 기능 / 구성: - Ops Agent logging receiver: NGINX Ingress access log file/stream이 ingest되고 있는지 확인합니다(설정에 따라 file receiver 또는 fluent-bit pipeline인 경우가 많음). 로그가 이미 Cloud Logging에 존재한다면 추가 agent 변경이 필요 없을 수 있습니다. - Logs-based metrics (counter): client IP를 담고 있는 log payload field에 대한 filter를 정의합니다(NGINX의 경우 structured logs에서는 보통 remote_addr / client_ip이거나, text에서 파싱됨). 매칭되는 각 entry를 카운트하도록 counter metric을 사용합니다. - Cloud Monitoring charting: logs-based metric에 대한 chart를 만들고 alignment period를 60s로 설정해 분당 카운트를 얻습니다. 필요하면 ingress, namespace, status code별로 pivot할 수 있도록 grouping labels를 추가합니다. - Architecture Framework alignment: Observability pillar에 부합합니다—중앙화된 logging/metrics와 managed services를 사용하고, 운영 부담을 최소화하며, 빠른 조사(investigation)를 가능하게 합니다. 흔한 오해: - “custom metric pipeline이 필요하다”: 많은 사람들이 로그를 스크레이프해서 custom metrics를 push해야 한다고 생각합니다. 하지만 logs-based metrics는 logs에서 metrics로의 managed 변환을 이미 제공합니다. - “node/application metrics를 사용한다”: 표준 metrics receiver는 client IP별 요청 수를 만들지 못합니다. 그 데이터는 일반적인 system metrics가 아니라 access logs에 있습니다. 시험 팁: 로그에서 파생된 metrics(카운트, rate, error pattern)가 필요하고 코드 변경이나 collector 추가가 금지되어 있다면, Cloud Logging + logs-based metrics + Cloud Monitoring dashboards/alerts를 떠올리세요. 또한 counter vs distribution metrics를 적절히 선택하고, 분당 시각화를 위해 1-minute alignment를 사용한다는 점을 기억하세요.

2
문제 2

You are the on-call SRE for a live trivia streaming platform running on Google Kubernetes Engine (GKE) behind a global external HTTP(S) Load Balancer with geo-based routing; each of 4 regions (us-central1, europe-west1, asia-southeast1, southamerica-east1) contains 3 regional GKE clusters serving traffic via NEG backends, and at 18:05 UTC you receive a page that asia-southeast1 users have had 100% connection failures (HTTP 502) for the past 7 minutes while other regions are healthy and asia-southeast1 normally serves 25% of global requests and the availability SLO is 99.95% monthly with a rapid burn alert firing; you want to resolve the incident following SRE best practices. What should you do first?

정답입니다. 사용자 영향과 error-budget burn을 줄이기 위한 가장 빠르고 안전한 완화 조치입니다. asia-southeast1을 serving path에서 제거(백엔드 비활성화/드레이닝 또는 weight 조정)하여 트래픽이 정상 region으로 가도록 합니다. 이는 global external HTTP(S) Load Balancer의 multi-region 설계를 활용하며 되돌릴 수 있습니다. 서비스가 안정화된 후 asia-southeast1의 root cause를 조사할 수 있습니다.

CPU/memory 확인은 해당 region이 과부하인지 진단하는 데 도움이 될 수 있지만, 현재 502를 보는 사용자에 대한 가용성을 즉시 복구하지는 못합니다. 또한 region 전반에서 100% 502는 단순 리소스 포화보다는 더 광범위한 장애(health check, networking, ingress/proxy, endpoint readiness)를 시사하는 경우가 많습니다. SRE 대응에서는 심층 메트릭 분석보다 완화가 먼저입니다.

대규모 node pool 추가는 느리고 잠재적으로 비용이 큰 변경이며, 진행 중인 outage에서 1차 대응 조치가 아닙니다. 이는 capacity가 root cause라는 가정을 전제로 하지만, 증상(해당 region 전반의 HTTP 502)과는 부합하지 않습니다. scaling은 misconfiguration, network failure, load balancer/NEG health 문제를 해결하지 못할 수 있습니다. 먼저 traffic shift를 선호하고, 그 다음 표적화된 remediation을 수행하세요.

로그는 root cause 분석(예: ingress/controller 오류, upstream reset, TLS 이슈)에 유용하지만, regional outage가 전체 실패와 빠른 SLO burn을 유발하는 상황에서 첫 단계는 아닙니다. SRE 모범 사례는 먼저 사용자 영향을 완화(traffic reroute)한 뒤, logs/metrics/traces로 진단하고 영구적인 수정 사항을 구현하는 것입니다.

문제 분석

핵심 개념: 이 문제는 SRE 원칙에 따른 incident response를 평가합니다. 사용자 영향 감소를 우선하고, error budget을 보호하며, 안전하고 되돌릴 수 있는 완화 조치로 서비스를 빠르게 복구하는 것이 핵심입니다. 또한 geo-based routing과 NEG 백엔드를 사용하는 global external HTTP(S) Load Balancing을 다루며, 전체 서비스를 다운시키지 않고 단일 region을 격리할 수 있음을 포함합니다. 정답이 맞는 이유: asia-southeast1에서 7분 동안 100% connection failure(HTTP 502)가 발생했고 99.95% 월간 SLO에 대한 rapid burn alert가 발생한 상황에서는, 첫 번째 조치는 즉시 고객 영향을 완화하는 것입니다. asia-southeast1 백엔드를 비활성화/드레이닝(또는 해당 region이 0% 트래픽을 받도록 traffic steering 조정)하는 것은 빠르고 위험이 낮은 완화 조치로, 영향을 받는 사용자를 가장 가까운 정상 region으로 보내 가용성을 복구합니다. 이는 SRE 모범 사례(먼저 출혈을 멈추고, 그 다음 root cause를 조사)와 일치합니다. 또한 계속 error budget을 소모하지 않도록 하면서 트러블슈팅 시간을 확보해 줍니다. 주요 기능 / 모범 사례: Global external HTTP(S) Load Balancer는 health check와 traffic steering을 통해 multi-region 백엔드를 지원합니다. 특정 region이 502를 반환하면, serving에서 제거(또는 failover/weight 설정)하여 즉시 오류를 줄일 수 있습니다. GKE에서 NEG를 사용하면 backend health는 endpoint readiness와 health check에 좌우되며, regional 이슈(control plane, networking, misconfig, certificate, Envoy/Ingress 등)로 광범위한 502가 발생할 수 있습니다. SRE playbook은 일반적으로 심층 디버깅 전에 완화 단계(traffic shift, rollback, feature flag off)로 시작합니다. 흔한 오해: 로그/메트릭(B/D)부터 시작하고 싶을 수 있는데, 이는 root cause를 찾는 데는 도움이 되지만 사용자에게 보이는 오류를 즉시 줄이지는 못합니다. 또 다른 함정은 capacity(C)가 문제라고 가정하는 것입니다. 502는 단순 CPU/memory 압박보다는 backend unavailability, misrouting, proxy/upstream failure를 의미하는 경우가 많고, scaling은 느릴 수 있으며 근본 결함을 해결하지 못할 수 있습니다. 시험 팁: “rapid burn”, “100% failures”, “other regions healthy”를 보면, 상세 트러블슈팅 전에 서비스를 복구하는 가장 빠르고 되돌릴 수 있는 완화 조치(traffic shift/문제 region 비활성화)를 선택하세요. 조치를 SRE 우선순위(영향 완화, 안정화, 그 다음 진단 및 재발 방지)에 매핑하세요. 또한 global load balancer는 regional isolation과 failover를 위해 설계되었으므로 incident 동안 그 기능을 활용해야 합니다.

3
문제 3

Your video analytics platform is deploying a frame-processing microservice on both GKE Autopilot in us-central1 (200 pods across 5 namespaces) and 30 on-premises Linux servers in a private data center; you must collect detailed, function-level performance data (CPU and heap profiles) with under 5% overhead, keep profiles for 30 days, and visualize everything centrally in a single Google Cloud project without building or operating your own metrics pipeline—what should you do?

Cloud Profiler는 함수 수준 attribution을 제공하는 지속적, 낮은 오버헤드의 CPU 및 heap 프로파일링을 위한 Google Cloud 관리형 서비스입니다. GKE Autopilot 워크로드와 on-prem Linux 서비스 모두에 Profiler agent를 설치하면 프로파일을 단일 Cloud project로 업로드하여 중앙 시각화 및 분석을 할 수 있습니다. 이는 5% 미만 오버헤드 목표를 충족하고 커스텀 metrics pipeline을 구축/운영하는 것을 피하게 해주며, 주로 agent 통합과 IAM/network 접근만 관리하면 됩니다.

Cloud Debugger는 지속적 CPU/heap 프로파일링이 아니라 애플리케이션 상태(snapshot) 검사와 재배포 없이 logpoint를 추가하는 용도입니다. 타이밍 데이터가 포함된 debug log를 내보내면 로깅 볼륨과 오버헤드가 증가하고, 통계적으로 의미 있는 함수 수준 CPU/heap attribution이 부족하며, 성능 분석을 위한 준(準) 커스텀 파이프라인이 됩니다. 또한 Cloud Profiler에 필적하는 시간 경과에 따른 집계 프로파일링 뷰를 자연스럽게 제공하지 않습니다.

/metrics endpoint를 노출하고 timing library를 사용하는 것은 관리형 프로파일링이라기보다 커스텀 메트릭 수집에 가깝습니다. Cloud Monitoring uptime check는 가용성/endpoint 확인을 위한 것이며, 여러 pod/namespace 및 on-prem server 전반에서 Prometheus 스타일 메트릭을 대규모로 스크레이프하도록 의도된 것이 아닙니다. Managed Service for Prometheus를 사용하더라도 CPU/heap 프로파일의 함수 수준 attribution이 아니라 메트릭을 수집하는 것이며, 더 많은 instrumentation 및 ingestion 구성요소를 운영하게 됩니다.

서드파티 APM agent는 프로파일링을 제공할 수 있지만, 자체 metrics pipeline을 구축/운영하지 않으려는 요구사항을 위반하고 운영 복잡성(agent 관리, 라이선스, 데이터 export, 저장, 시각화)을 추가합니다. 나중에 분석하기 위해 bucket/database로 export하는 것은 Google Cloud에서의 관리형 통합 프로파일링 경험이 아니며 비용과 유지보수를 증가시킵니다. 시험에서는 요구사항이 일치할 때 퍼스트파티 관리형 observability 서비스를 우선 선택하세요.

문제 분석

핵심 개념: 이 문제는 하이브리드 환경 전반에서 코드 수준 성능 프로파일링을 위한 Google Cloud의 관리형 observability 도구를 평가합니다. 핵심 서비스는 Cloud Profiler로, 실행 중인 애플리케이션에서 낮은 오버헤드로 통계적 CPU 및 heap 프로파일을 지속적으로 수집하고 이를 Google Cloud project에 중앙 저장/시각화합니다. 정답이 맞는 이유: 함수 수준 성능 데이터(CPU 및 heap 프로파일), 5% 미만 오버헤드, 30일 보관, 그리고 커스텀 파이프라인을 운영하지 않고 Google Cloud에서 단일 중앙 뷰가 필요합니다. Cloud Profiler는 이를 위해 설계되었습니다. 애플리케이션에 Profiler agent를 통합(또는 지원 언어 agent 사용)하면 프로파일이 project의 Cloud Profiler로 업로드됩니다. GKE(Autopilot 포함)에서 실행되는 워크로드와 on-prem Linux server에서 실행되는 워크로드 모두에서 동작하며, on-prem은 Google Cloud APIs에 인증(일반적으로 service account credentials 또는 workload identity federation)할 수 있고 Profiler endpoint에 도달할 수 있으면 됩니다. 이는 “파이프라인을 구축/운영하지 않음” 요구사항을 직접 충족합니다. 주요 기능 / 구성 / 모범 사례: - 낮은 오버헤드의 지속적 프로파일링: sampling 기반 프로파일링은 일반적으로 오버헤드를 5%보다 훨씬 낮게 유지하도록 설계되었습니다. - 프로파일 유형: CPU 및 heap(그리고 언어/runtime에 따라 기타 유형)은 함수 수준의 attribution을 제공합니다. - 중앙 시각화: 프로파일은 하나의 project 내 Cloud Profiler UI에서 집계 및 탐색되며, Google Cloud Architecture Framework의 Operational Excellence 및 Reliability pillar(측정, 관찰, 개선)와 정렬됩니다. - 보관: Cloud Profiler는 시간 경과에 따른 분석을 위해 프로파일을 보관(일반적으로 30일 운영 윈도우에 맞춤)하여 회귀(regression) 탐지를 가능하게 합니다. - 하이브리드 지원: on-prem 서비스는 service account credentials 또는 federation을 사용해 프로파일을 업로드할 수 있습니다. egress 및 IAM 권한(예: roles/cloudprofiler.agent)을 보장하세요. 흔한 오해: 팀은 종종 프로파일링을 로깅(Cloud Logging) 또는 디버깅(Cloud Debugger)과 혼동합니다. 로그와 debugger snapshot은 증상을 보여줄 수는 있지만, 시간에 걸친 통계적으로 유효한 낮은 오버헤드의 함수 수준 CPU/heap attribution을 제공하지는 못합니다. 마찬가지로 “/metrics endpoint”와 uptime check는 가용성과 기본 메트릭을 위한 것이지, 심층 코드 프로파일링을 위한 것이 아닙니다. 시험 팁: “함수 수준 CPU/heap 프로파일”, “낮은 오버헤드”, “파이프라인을 만들지 않고 관리형/중앙화”가 보이면 Cloud Profiler를 떠올리세요. 요청 수준 지연 시간과 분산 호출 그래프는 Cloud Trace, 로그는 Cloud Logging, 메트릭은 Cloud Monitoring을 생각하면 됩니다. 또한 하이브리드 identity/authentication과 IAM role을 올바른 구현 세부사항의 일부로 고려하세요.

4
문제 4

You work for a fintech company headquartered in Frankfurt where an Organization Policy enforces constraints/gcp.resourceLocations to allow only europe-west3 and europe-west1 for all resources. When you tried to create a secret in Secret Manager using automatic replication, you received the error: "Constraint constraints/gcp.resourceLocations violated for [orgpolicy:projects/1234567890] attempting to create a secret in [global]". You must resolve the error while remaining compliant and ensure the secret’s data resides only in the allowed EU regions. What should you do?

오답입니다. Organization Policy를 제거하면 즉각적인 오류는 해결되지만 컴플라이언스 및 거버넌스 요구사항을 깨뜨립니다. 규제 대상 핀테크 환경에서는 위치 제약이 보통 데이터 레지던시와 리스크 관리를 위해 의무화됩니다. 문제는 컴플라이언스를 유지하고 secret 데이터를 허용된 EU 리전에만 두어야 한다고 명시하므로, guardrail을 약화하거나 제거하는 것은 제시된 제약과 모범 사례를 위반합니다.

오답입니다. Automatic replication으로 secret을 생성하는 것이 바로 위반을 유발한 원인입니다. Automatic replication은 Google이 복제본 저장 위치를 제어하므로 global 위치로 취급되며, europe-west1과 europe-west3 외의 리전을 포함할 수 있습니다. constraints/gcp.resourceLocations 하에서는 global 리소스 또는 배치가 비결정적인 리소스가 생성에 실패하는 경우가 흔합니다.

정답입니다. User-managed replication을 사용하면 허용된 리전(europe-west3 및/또는 europe-west1)을 명시적으로 선택할 수 있어, secret 데이터가 해당 위치에만 상주하도록 보장하고 constraints/gcp.resourceLocations를 충족합니다. 이 접근은 컴플라이언스를 유지하고 감사 가능성을 지원하며, 정책을 변경하기보다 조직 정책에 맞게 리소스 구성을 조정한다는 거버넌스 모범 사례와도 일치합니다.

오답입니다. 허용 목록에 global을 추가하면 automatic replication은 허용되겠지만, secret material이 europe-west1과 europe-west3에만 유지된다는 보장은 더 이상 할 수 없습니다. “Global”은 의도한 리전 범위를 넘어 확장될 수 있는 Google-managed 배치를 의미하므로, 엄격한 데이터 레지던시 요구사항을 약화시킵니다. 이 옵션은 또한 컴플라이언스 요구사항에 반하여 조직의 거버넌스 통제를 약화시킵니다.

문제 분석

핵심 개념: 이 문제는 Organization Policy Service 제약조건(constraints/gcp.resourceLocations)과 이것이 Secret Manager 복제와 어떻게 상호작용하는지를 테스트합니다. Secret Manager secret은 조직에서 허용한 리소스 위치를 준수하는 위치에서만 생성되어야 합니다. “Automatic replication”은 Google이 멀티 리전 배치를 관리하며, 명시적으로 허용된 집합 밖의 위치를 포함할 수 있으므로 “global”로 취급됩니다. 정답이 맞는 이유: constraints/gcp.resourceLocations가 europe-west3와 europe-west1만 허용하는 상황에서 automatic replication으로 secret을 생성하면 secret의 복제 위치가 [global]이므로 정책을 위반합니다. 정책을 준수하고 허용된 EU 리전 내에서만 데이터 레지던시를 보장하려면 user-managed replication을 사용하고 europe-west3 및/또는 europe-west1을 명시적으로 선택하여 secret을 생성해야 합니다. 이렇게 하면 secret의 복제 정책이 결정적(deterministic)이고 감사 가능(auditable)해져, 정책과 핀테크 규제 기대사항을 모두 충족합니다. 주요 기능 / 모범 사례: - Secret Manager는 두 가지 복제 모드를 지원합니다: automatic(Google-managed, “global”)과 user-managed(customer-specified regions). - Organization Policy constraints/gcp.resourceLocations는 지원되는 리소스를 생성할 수 있는 위치와 데이터가 상주할 수 있는 위치를 제한합니다. - 규제 대상 워크로드에서는 데이터 레지던시, 컴플라이언스 증빙, 예측 가능한 failover 특성을 위해 user-managed replication이 모범 사례입니다. - Google Cloud Architecture Framework의 거버넌스 및 컴플라이언스 원칙과 정렬됩니다: 중앙에서 guardrail을 강제하고, 통제를 약화시키기보다 워크로드를 정책에 맞게 설계합니다. 흔한 오해: Automatic replication은 “가용성이 더 높고” “EU 안에 있을 것”처럼 들릴 수 있지만, 허용된 리전 내에만 머문다는 보장이 없고 global로 표현되어 정책 위반을 유발합니다. 또 다른 오해는 org policy를 완화(제거하거나 global을 추가)하여 오류를 “해결”하는 것인데, 이는 거버넌스를 약화시키고 규제 요구사항을 위반할 가능성이 큽니다. 시험 팁: constraints/gcp.resourceLocations와 [global]을 언급하는 오류를 보면, 위치 제한과 충돌하는 “automatic/multi-region/global resource”를 떠올리세요. 컴플라이언스에 맞는 패턴은 허용 목록과 일치하는 regional 또는 user-managed 배치를 선택하는 것입니다. secret과 key의 경우, 규제 산업(금융/헬스케어)에서 리전을 명시적으로 선택하는 것이 흔한 시험 주제입니다.

5
문제 5

During a controlled traffic-shift rollout, your ride-hailing platform running across three GKE regions suffered a 2 hours 45 minutes outage that impacted 100% of rider and driver requests; after approximately 3 hours of incident response, service is fully restored with SLIs back to baseline, and you have 30 minutes to deliver an incident summary to executives, customer support leads, and key city partners following SRE-recommended practices. What should you do first?

개별 통화를 잡는 것은 너무 느리고, 이해관계자 그룹(임원진, support, city partners)이 여러 개이며 30분밖에 없을 때 확장성이 없습니다. 또한 메시지 불일치와 핵심 사실 누락 위험을 높입니다. SRE 실무는 모두가 참조할 수 있는 단일한 written source of truth(sitrep/ISD)를 선호하며, 특정 대상에게 필요할 때만 후속 미팅을 진행합니다.

full postmortem은 신중한 데이터 수집, 타임라인 검증, 기여 요인 분석, action items가 필요하며, 대규모 outage 직후 30분 안에 신뢰성 있게 완료할 수 없습니다. SRE 가이드는 먼저 안정화하고 현재 상태를 커뮤니케이션한 뒤, 적절한 일정으로 blameless postmortem을 작성하라고 합니다. 불완전하거나 서두른 postmortem을 보내면 혼란을 만들고 신뢰를 떨어뜨릴 수 있습니다.

현재 ISD/situation report를 배포하는 것이 올바른 첫 단계인 이유는 영향, 타임라인, mitigations, 현재 상태(복구 완료, SLIs baseline)라는 빠르고 사실 기반이며 일관된 요약을 제공하기 때문입니다. 이를 통해 customer support 및 partner 팀이 정렬된 메시지로 즉시 대응할 수 있습니다. 이는 SRE 인시던트 관리 best practices(빈번하고 표준화된 업데이트, 더 깊은 RCA 작업 이전의 canonical document)와 일치합니다.

on-call engineer의 개인 사과 이메일은 SRE가 권장하는 첫 조치가 아닙니다. 이는 성급할 수 있고(사실이 아직 변동 중일 수 있음), blame을 암시할 수 있으며, 이해관계자가 커뮤니케이션을 조율하는 데 필요한 운영 상세를 제공하지 못합니다. 사과 및 customer-facing statements는 ISD의 검증된 정보를 사용해 확립된 comms 프로세스를 통해 조율되어야 합니다.

문제 분석

핵심 개념: 이 문제는 SRE 인시던트 커뮤니케이션 실무를 평가합니다. 즉, 서비스 복구 후 이해관계자에게 신속히 알리는 방법으로, 더 심층적인 postmortem 이전에 표준화된 산출물(incident state document/situation report)을 사용하는 것입니다. 이는 빠르고 사실 기반의 상태 커뮤니케이션을 이후의 root-cause analysis 및 corrective actions와 분리하라는 SRE 가이드와 일치합니다. 정답이 맞는 이유: 임원진, customer support, 외부 파트너에게 30분 내로 인시던트 요약을 전달해야 합니다. 가장 빠르고 신뢰할 수 있는 첫 조치는 핵심 사항을 이미 담고 있는 현재 Incident State Document (ISD)/situation report를 배포하는 것입니다: 고객 영향(100% outage), 지속 시간(2h45m), 복구된 내용(SLIs가 baseline으로 복귀), 그리고 상위 수준의 타임라인. 이는 메시지의 일관성을 보장하고, 소문/모순을 줄이며, downstream 팀(support, partner managers)이 즉시 커뮤니케이션할 수 있게 합니다. SRE 실무는 인시던트 중/후에 시의적절하고 정확하며 널리 공유되는 업데이트를 강조하며, ISD는 단일한 canonical source of truth입니다. 핵심 특징 / Best Practices: 효과적인 ISD에는 다음이 포함됩니다: 영향 요약(누가/무엇이/어디서), 시작/종료 시간, 현재 상태, 적용된 mitigations, 알려진 잔여 리스크, 그리고 다음 단계(예: postmortem ETA). 비엔지니어를 위해 plain language로 작성하고, dashboards 및 incident tickets 링크를 포함해야 합니다. 이는 blameless culture와 operational excellence를 지원하며(Google Cloud Architecture Framework: Operational Excellence 및 Reliability pillars), 전체 RCA를 기다리지 않고도 이해관계자가 행동할 수 있게 합니다. 흔한 오해: 바로 full postmortem을 시작(B)하거나 high-touch calls(A)를 하는 것이 유혹적일 수 있지만, 이는 더 느리고 일관되지 않은 내러티브를 만들 위험이 있습니다. 사과 이메일(D)은 첫 단계가 아닙니다. 사실이 검증되기 전에 성급할 수 있고, 확인 전 과실을 인정하는 것으로 비칠 수 있으며, 실행 가능한 운영 컨텍스트를 제공하지 못합니다. Exam Tips: DevOps/SRE 시험 시나리오에서 시간이 촉박하고 이해관계자가 많다면, 먼저 표준화되고 반복 가능한 커뮤니케이션 산출물(ISD/sitrep)을 우선하세요. postmortem은 데이터 수집과 안정화 이후에 진행됩니다. “30 minutes,” “executives/support/partners,” “SRE-recommended practices” 같은 키워드를 보면 “share the current status report”를 “write the full report”나 “schedule meetings”보다 우선으로 선택해야 합니다.

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

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

6
문제 6

Your team operates a multi-tenant fraud-scoring API written in Node.js and deployed on Cloud Run (fully managed) with concurrency set to 50 and minimum instances set to 2. During load tests (~200 errors per minute), you must customize the error data sent to Cloud Error Reporting to include tenant_id and op_id, set a custom service/version for grouping, and use a custom fingerprint while ensuring no PII is logged. What should you do?

오답입니다. 애플리케이션을 Compute Engine으로 옮기는 것은 불필요합니다. Cloud Run은 이미 Cloud Logging을 지원하고 있으며 Error Reporting을 포함한 Google Cloud API를 직접 호출할 수 있기 때문입니다. 이 문제의 핵심은 오류가 보고되는 방식을 사용자 지정하는 것이지, VM 수준의 제어나 다른 runtime environment가 필요한 것이 아닙니다. Compute Engine을 도입하면 문제에서 요구하는 고유한 기능을 제공하지 않으면서 instance 관리, patching, scaling configuration 같은 운영 부담만 추가됩니다. 시험에서는 기존 관리형 서비스가 이미 필요한 기능 세트를 지원하는 경우 플랫폼 마이그레이션은 보통 오답입니다.

오답입니다. Google Kubernetes Engine 역시 이 시나리오에서는 불필요한 플랫폼 변경입니다. 애플리케이션은 Cloud Run에 그대로 두고도 Error Reporting 및 Cloud Logging과 계속 통합할 수 있기 때문입니다. 요구 사항은 sidecar, daemonset, 또는 사용자 지정 node-level agent 같은 orchestration 기능을 얻는 것이 아니라, error-reporting 데이터를 보강하고 제어하는 것입니다. GKE로 마이그레이션하면 service/version attribution이나 구조화된 error logging에 필요하지 않음에도 복잡성과 운영 오버헤드가 증가합니다. 모범 사례는 필요한 observability API를 기존에 이미 지원하는 경우 관리형 serverless 플랫폼을 유지하는 것입니다.

오답입니다. 서비스를 Cloud Run에 유지하는 방향은 맞지만, 이 옵션은 Node.js Error Reporting client library 설치만 언급하고 있어 너무 제한적입니다. 문제는 구체적으로 사용자 지정된 error data 처리와 명시적인 service/version 제어를 요구하며, 보기 중 가장 완전하게 지원되는 메커니즘은 Error Reporting API를 구조화된 Cloud Logging과 함께 사용하는 것입니다. client library는 exception 캡처에 도움이 될 수 있지만, 이 옵션은 시나리오에 필요한 전체 사용자 지정 및 logging 설계를 명확하게 다루지 않습니다. 따라서 Cloud Run 자체는 여전히 올바른 플랫폼이지만 C는 최선의 답이 아닙니다.

정답입니다. Cloud Run은 배포 플랫폼을 변경하지 않고도 애플리케이션 오류를 Google Cloud Error Reporting으로 전송하는 것을 완전히 지원하며, Error Reporting API를 호출하거나 올바른 형식의 error log를 Cloud Logging으로 출력하는 방식으로 이를 수행할 수 있습니다. 이 접근 방식은 serviceContext.service와 serviceContext.version에 대한 명시적인 제어를 제공하며, 이는 Error Reporting에서 논리적 서비스와 배포된 버전을 식별하는 표준 방식입니다. 또한 상관관계 분석과 문제 해결을 위해 관련 log entry에 tenant_id와 op_id를 구조화된 비-PII metadata로 포함할 수 있습니다. 이는 Cloud Run의 관리형 운영 모델을 유지하면서 사용자 지정 요구 사항을 충족하는 가장 직접적인 옵션입니다.

문제 분석

핵심 개념: 이 문제는 Cloud Error Reporting 커스터마이징과 Cloud Logging 및/또는 Error Reporting API를 사용하여 serverless 런타임(Cloud Run)에서 오류가 수집/그룹화되는 방식을 테스트합니다. 또한 멀티 테넌트 관측성 설계(tenant/op 상관관계 추가)와 프라이버시 제어(PII 회피)도 다룹니다. 정답인 이유: Cloud Run에서는 처리되지 않은 예외와 올바른 형식의 error log가 자동으로 Error Reporting에 표시될 수 있지만, 기본 캡처/그룹화는 제한적입니다. 요구사항은 명시적으로 (1) 커스텀 필드(tenant_id, op_id) 추가, (2) 그룹화를 위한 커스텀 service/version 설정, (3) 커스텀 fingerprint 사용을 요청합니다. 가장 직접적이고 완전히 제어 가능한 방법은 Error Reporting API를 호출하여 커스텀 context(service/version)와 커스텀 fingerprint를 포함한 ReportedErrorEvent를 작성하고, 동시에 Error Reporting용으로 포맷된 Cloud Logging 엔트리를 내보내는 것입니다. 이 접근은 컴퓨팅 플랫폼을 변경하지 않고도 결정론적 그룹화와 메타데이터를 제공합니다. 주요 기능 / 모범 사례: - ReportedErrorEvent와 함께 Error Reporting API (projects.events.report) 사용. - 배포 간 그룹화를 제어하기 위해 serviceContext.service 및 serviceContext.version 채우기. - tenant/op 또는 오류 시그니처별로 그룹화하기 위해 커스텀 fingerprint 사용(주의: 지나치게 세분화된 fingerprint는 cardinality 폭증을 유발할 수 있음). - tenant_id/op_id를 비-PII labels/metadata로 포함하고, payload는 스크럽 처리(요청 본문, 이메일, 토큰 없음). 애플리케이션 레이어에서 allowlist 및 redaction 구현. - Cloud Logging에는 structured logging을 선호; Cloud Run은 stdout/stderr를 자동 전송. 로그가 Error Reporting format을 충족하여 인식되도록 보장. 흔한 오해: 많은 사람이 Node.js Error Reporting client library 설치만으로 충분하다고 가정합니다. 라이브러리는 예외를 캡처할 수 있지만, API가 제공하는 방식처럼 커스텀 fingerprinting과 정밀한 service/version 그룹화를 본질적으로 해결하지는 못하며, GKE/Compute Engine으로 이동할 필요도 없습니다. 또 다른 함정은 더 풍부한 error reporting을 위해 플랫폼 변경(GKE/VMs)이 필요하다고 생각하는 것인데, Cloud Run은 동일한 API를 지원합니다. 시험 팁: “custom fingerprint”와 “custom service/version” 같은 요구사항이 보이면 agent/client library만이 아니라 “Error Reporting API / ReportedErrorEvent”를 떠올리세요. 또한 멀티 테넌트 시스템에서는 PII 제약과 cardinality 리스크를 주의해야 합니다. tenant 식별자는 labels/metadata로 추가하되 메시지나 stack trace에 민감 데이터를 포함하지 말고, 대규모에서도 실행 가능하도록 그룹화를 설계하세요.

7
문제 7

Your production machine learning inference services run on a 30-node GKE cluster in asia-northeast1 while your Jenkins build agents run in europe-west1, and each rollout requires all nodes to pull a 1.5-GB image within a 10-minute deployment window; to maximize pull bandwidth and use a scalable registry, where should you push the images?

gcr.io는 “global”이 아니라 US 멀티 리전에 이미지를 저장합니다. asia-northeast1의 GKE 클러스터에 대해서는 일반적으로 Asia 위치 대비 더 높은 지연과 잠재적인 대륙 간 egress를 유발합니다. GCR 자체는 확장 가능하지만, 거리 때문에 유효 총 pull 처리량이 감소하여 30개 노드가 1.5-GB 이미지를 pull해야 하는 엄격한 10분 롤아웃 시간 창을 맞추기 더 어려워질 수 있습니다.

eu.gcr.io는 이미지를 EU 멀티 리전에 저장합니다. 이는 europe-west1의 Jenkins 빌드 에이전트가 push하기에는 맞지만, 지배적인 요구사항은 asia-northeast1의 프로덕션 GKE 노드가 빠르게 pull하는 것입니다. Europe에서 Asia로 pull하면 지연과 cross-region 트래픽이 추가되어, 노드 동시 pull 동안 병목이 될 수 있고 배포 시간 창을 놓칠 위험이 커집니다.

asia.gcr.io는 이미지를 Asia 멀티 리전에 저장하며, 이는 asia-northeast1의 GKE 클러스터에 가장 가까운 GCR 위치입니다. 이는 네트워크 거리를 최소화하고 지연 및 잠재적인 대륙 간 egress를 줄이며, 30개 노드가 10분 내에 1.5-GB 이미지를 동시에 pull할 가능성을 높입니다. 또한 완전 관리형의 확장 가능한 레지스트리라는 이점도 유지합니다.

asia-northeast1의 Compute Engine VM에 private registry를 두면 지리적으로는 가깝지만, 30개의 대용량 동시 pull에 대해 본질적으로 확장성이 보장되지 않으며 상당한 운영 오버헤드(패치, 스케일링, HA, 백업, TLS, auth)를 유발합니다. 단일 장애 지점이 될 수 있고, GCR의 신뢰성과 처리량에 맞추려면 load balancing 및 다중 VM 아키텍처가 필요할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 GKE 롤아웃에서 컨테이너 이미지 배포 성능과 Google Container Registry (GCR) hostname이 멀티 리전 스토리지 위치에 어떻게 매핑되는지를 테스트합니다. 본질적으로는 짧은 배포 시간 창에서 지연/egress 병목을 최소화하고 동시 pull의 총 처리량을 최대화하는 것에 관한 문제입니다. 정답이 맞는 이유: GKE 클러스터는 asia-northeast1에 있으며 10분 내에 30개 노드가 큰(1.5-GB) 이미지를 pull해야 합니다. pull 대역폭을 최대화하는 최선의 방법은 레지스트리 스토리지를 소비자(GKE 노드)와 가장 가까운 곳에 두는 것입니다. asia.gcr.io hostname을 사용하면 이미지는 GCR의 Asia 멀티 리전에 저장되며, 이는 EU 또는 US 멀티 리전보다 asia-northeast1에 지리적으로/네트워크 토폴로지상 더 가깝습니다. 그 결과 대륙 간 지연을 줄이고 불필요한 대륙 간 egress를 피하여 유효 처리량과 롤아웃 신뢰성을 개선합니다. 주요 기능 / 모범 사례: GCR은 Google 인프라를 기반으로 하는 확장 가능한 관리형 레지스트리를 제공하므로, 서버를 직접 관리하지 않고도 높은 동시성 pull을 지원합니다. hostname이 멀티 리전을 결정합니다: gcr.io (US), eu.gcr.io (EU), asia.gcr.io (Asia). 대규모 롤아웃에서는 노드 이미지 캐싱, Deployments에서 maxUnavailable 제어, 그리고 (현대 아키텍처에서는) Artifact Registry의 리전별 repository 및 pull-through/cache 패턴도 고려하세요. Google Cloud Architecture Framework 관점에서 이는 네트워크 의존성과 변동성을 줄여 Performance Optimization과 Reliability에 부합합니다. 흔한 오해: 많은 사람들이 gcr.io가 “global”이라서 최선이라고 가정하지만, 그렇지 않습니다—US 멀티 리전에 매핑됩니다. 또 다른 사람들은 빌드가 europe-west1에서 실행된다는 이유로 eu.gcr.io를 선택하지만, 30개의 프로덕션 노드가 빠르게 다운로드해야 하는 상황에서는 빌드 push 위치보다 pull 위치가 더 중요합니다. 리전 내 private registry는 빠를 것처럼 들리지만, 본질적으로 확장성이 보장되지 않으며 운영 및 가용성 리스크가 됩니다. 시험 팁: GKE의 이미지 pull 속도에 대해 묻는다면, 레지스트리의 클러스터 근접성과 관리형 확장성을 우선하세요. GCR hostname은 멀티 리전에 대응하므로, CI 시스템이 아니라 런타임 환경에 가장 가까운 것을 선택해야 합니다. 또한 Artifact Registry가 선택지로 있는 문제도 주의하세요. 예측 가능한 성능과 비용을 위해 클러스터 근처의 리전 repository를 선호합니다.

8
문제 8

Your organization lets product squads self-manage Google Cloud projects, including project-level IAM; the network platform team operates a Shared VPC host project named net-host-prod that connects 18 service projects across 3 folders, and a lien has already been placed on the host project to prevent accidental deletion; you must implement a control so that only principals who hold the resourcemanager.projects.updateLiens permission at the organization level can remove the lien and delete the host project; what should you do?

Terraform pull request로 IAM 변경을 관리하는 것은 강력한 운영 관행(감사 가능, 리뷰 가능, 반복 가능)이지만, 강제(enforcement) 메커니즘은 아닙니다. 충분한 권한이 있는 사용자는 Console, gcloud, 또는 API를 사용해 여전히 lien을 제거하거나 IAM을 직접 변경할 수 있습니다. 이 문제는 org-authorized principal만 lien을 제거할 수 있도록 보장하는 기술적 통제를 요구하며, Terraform 워크플로만으로는 이를 보장할 수 없습니다.

VPC Service Controls는 지원되는 Google API에 대해 데이터 유출 위험을 줄이기 위한 service perimeter를 생성합니다. 이는 lien 제거 또는 project 삭제에 대한 거버넌스 제어를 제공하지 않으며, container.googleapis.com에 대해 이를 활성화하는 것은 resourcemanager lien과 무관합니다. 이 선택지는 보안 경계 통제와 리소스 거버넌스 통제를 혼동한 것으로, 누가 lien을 제거할 수 있는지 제한해야 한다는 요구사항을 충족하지 못합니다.

host project에 직접 바인딩된 identity에서 resourcemanager.projects.updateLiens를 제거하는 것은 불충분하고 취약합니다. 권한은 folder 또는 organization level의 상속된 IAM binding을 통해 부여될 수 있으며, project-level admin은 자신의 역할에 따라 여전히 IAM을 조정할 수 있습니다. 요구사항은 org-level authority에 연결된 중앙집중적이고 강제 가능한 제한을 요구하며, 이는 Organization Policy로 달성하는 것이 더 적합합니다.

organization root에서 compute.restrictXpnProjectLienRemoval을 강제하는 것이 올바른 예방적 가드레일입니다. 이는 project-level IAM 자체 관리 여부와 무관하게 Shared VPC host project lien(XPN lien)의 제거를 중앙에서 제한합니다. org root에 적용하면 host project로 상속되며, 적절히 승인된 principal(필요한 org-level permission 보유자)만 lien을 제거하고 삭제를 진행할 수 있도록 보장합니다.

문제 분석

핵심 개념: 이 문제는 Organization Policy Service와 IAM을 사용하여 Shared VPC host project에 대한 Google Cloud 리소스 거버넌스를 테스트합니다. 특히 Shared VPC host project lien(삭제를 차단하는 보호 메커니즘)의 제거 권한을 누가 가질 수 있는지 제어하고, 중앙에서 승인된 principal(조직 수준 권한 보유자)만 해당 작업을 수행할 수 있도록 보장하는 데 초점을 둡니다. 정답이 맞는 이유: 올바른 제어는 organization root에서 organization policy constraint compute.restrictXpnProjectLienRemoval을 강제(enforce)하는 것입니다. 이 constraint는 Shared VPC(XPN) host project lien의 제거를 제한하도록 설계되었습니다. org root에서 이를 강제하면, 각 제품 스쿼드가 project-level IAM을 어떻게 관리하든 관계없이 전체 리소스 계층(org/folders/projects)에 일관되고 중앙에서 관리되는 가드레일을 적용할 수 있습니다. 이는 “조직 수준 권한( org-level permission )을 가진 principal만 lien을 제거하고 host project를 삭제할 수 있어야 한다”는 요구사항과 일치합니다. Org Policy는 project admin이 우회할 수 없는 예방적(preventive) 제어를 제공합니다. 주요 기능 / 모범 사례: - Organization Policy Service는 중요한 제어에 대해 로컬 project 자율성을 덮어쓰는 “policy-as-guardrails”를 제공합니다. - organization root에서 강제하면 Shared VPC host를 포함한 모든 folders/projects로 상속됩니다. - Lien은 삭제 보호 메커니즘이며, lien 제거를 제어하는 것은 프로세스 기반 통제에 의존하는 것보다 더 강력합니다. - 이 접근은 위험 감소와 일관된 컴플라이언스를 위해 중앙 정책을 사용하라는 Google Cloud Architecture Framework 거버넌스 원칙과 정렬됩니다. 흔한 오해: - project-level binding에서 권한을 제거하는 것(option C)은 그럴듯해 보이지만, 권한은 folder/org 상속으로 부여되거나 충분한 권한을 가진 사용자에 의해 다시 부여될 수 있어 불완전하며, 지속적이고 중앙에서 강제되는 가드레일을 만들지 못합니다. - “Terraform PR을 사용” 같은 프로세스 통제(option A)는 변경 관리를 개선하지만, 권한이 있는 사용자가 console/gcloud로 lien을 제거하는 것을 기술적으로 막지는 못합니다. - VPC Service Controls(option B)는 API에 대한 데이터 유출(exfiltration) 경계를 다루는 것이지, lien 제거 또는 project 삭제를 제어하는 것이 아닙니다. 시험 팁: “반드시 강제해야 함(must enforce)” 및 “org-level authority를 가진 principal만” 같은 요구사항이 보이면, 절차적 통제보다 Organization Policy constraint를 우선 고려하세요. Shared VPC host 보호의 경우 XPN 관련 constraint(compute.*)를 찾고, project-level IAM 자율성이 통제를 약화시키지 못하도록 가장 적절한 상위 노드(대개 organization root)에 적용하세요.

9
문제 9

Your platform team distributes Envoy WASM plugins as OCI-compliant artifacts to 150 edge gateways across 3 regions, and some plugins are currently sourced weekly from 4 public registries while others come from 2 internal teams; the security team has flagged the use of public registries as a supply-chain risk and requires repository-level IAM, audit logging, and enforcement within a VPC Service Controls perimeter with no public egress at deployment time using Private Google Access. You want to manage all plugins uniformly with native access control, unified auditability, and VPC Service Controls while remaining compatible with OCI clients; what should you do?

정답. Artifact Registry는 Google의 managed artifact service로, 네이티브 OCI 지원, repository-level IAM, Cloud Audit Logs 통합을 제공합니다. VPC Service Controls로 보호해 exfiltration 위험을 줄일 수 있으며, Private Google Access 및/또는 Google APIs용 Private Service Connect를 사용하면 public egress 없이 접근할 수 있습니다. public plugins를 Artifact Registry로 mirroring하면 OCI client compatibility를 유지하면서 runtime에서 public registries에 대한 의존성을 제거합니다.

오답. GitHub Enterprise Packages는 Google Cloud-native artifact service가 아니며 VPC Service Controls와 통합되지 않습니다. centralized identity가 있더라도 Google Cloud의 repository-level IAM controls, 동일한 방식의 Cloud Audit Logs, perimeter enforcement를 제공하지 못합니다. 또한 추가로 복잡한 networking을 구축하지 않는 한 일반적으로 gateway에서 internet access가 필요해 “배포 시 public egress 없음” 요구사항을 위반합니다.

오답. Cloud Storage는 binaries를 저장할 수 있지만, storage.googleapis.com에서 HTTPS로 plugin을 제공하는 것은 OCI registry가 아니며 registry endpoints, manifests, auth flows를 기대하는 OCI clients와 균일하게 호환되지 않습니다. Cloud Storage는 IAM을 사용할 수 있고 VPC-SC 뒤에 둘 수도 있지만, 이 솔루션은 배포 메커니즘을 변경하고 OCI-native workflows를 잃게 되어 “OCI clients와의 호환 유지”에 부적합합니다.

오답. GKE에서 self-managed registry를 운영하면 운영 부담(patching, scaling, HA, backups)이 증가하며, VPC-SC는 임의의 workloads가 아니라 Google-managed services/APIs에 적용되므로 VPC Service Controls enforcement 요구사항을 충족하지 못합니다. NetworkPolicies와 private ingress는 도움이 되지만, 동일한 perimeter 기반 exfiltration protections, 통합된 Google Cloud auditability, repository-level에서의 단순화된 IAM을 제공하지는 못합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 OCI artifacts에 대한 안전한 소프트웨어 공급망 관리를 테스트하며, 특히 Artifact Registry를 repository-level IAM, Cloud Audit Logs, VPC Service Controls(VPC-SC)와 함께 사용해 public registry 의존성을 제거하고 데이터 유출(exfiltration)을 방지하는지를 묻습니다. 또한 배포가 public egress 없이 이루어질 수 있도록 private access 패턴(Private Google Access / Private Service Connect)도 테스트합니다. 정답이 맞는 이유: 옵션 A는 (기존에 public이었던 것과 internal을 포함한) 모든 Envoy WASM plugin을 OCI-compliant artifacts로 Artifact Registry에 중앙화합니다. Artifact Registry는 OCI(container images 및 generic OCI artifacts)를 네이티브로 지원하고, repository 수준에서 IAM과 통합되며, admin/data access audit logs를 생성합니다. Artifact Registry API/project를 VPC-SC perimeter 안에 두고 gateway가 Google APIs에 private로 접근하도록(일반적으로 Google APIs용 Private Google Access 및/또는 Google APIs용 Private Service Connect를 통해) 구성하면, gateway는 public internet을 경유하지 않고 artifacts를 pull할 수 있습니다. 이는 uniform management, native access control, unified auditability, VPC-SC enforcement, OCI client compatibility 요구사항을 직접 충족합니다. 주요 기능 / 구성: - Artifact Registry repositories(regional)와 최소 권한(least privilege)을 위한 repo scope의 IAM bindings. - Artifact Registry용 Cloud Audit Logs(기본적으로 Admin Activity; read 이벤트가 필요하면 Data Access logs 활성화). - Artifact Registry service 및 관련 projects를 포함하는 VPC Service Controls perimeter; access levels 및 ingress/egress rules로 접근 경로를 제어. - gateway의 private access: Private Google Access가 활성화된 subnet에 위치하도록 보장; 선택적으로 Google APIs용 Private Service Connect endpoints를 사용해 트래픽을 Google 네트워크에 유지하고 egress controls를 단순화. - Mirroring 전략: public registries에서 Artifact Registry로 주기적으로 import/sync하여 runtime pull이 public egress를 필요로 하지 않도록 함. 흔한 오해: 팀들은 종종 “어떤 private registry든” VPC-SC 요구사항을 충족한다고 가정하지만, VPC-SC는 Google-managed services를 보호하고 perimeter controls를 강제합니다—self-managed registries는 VPC-SC 보호를 얻지 못합니다. 또 다른 오해는 Cloud Storage의 HTTPS hosting을 OCI registry semantics와 혼동하는 것입니다; OCI clients는 registry APIs, auth flows, artifact metadata를 기대합니다. 시험 팁: 요구사항에 repository-level IAM, audit logging, OCI compatibility, 그리고 public egress 없는 VPC-SC가 포함되면, 기본 선택은 Artifact Registry(또는 과거의 Container Registry) + VPC-SC + private Google API access입니다. 문제가 Google Cloud에서 지원되지 않는 커스텀 동작을 명시적으로 요구하지 않는 한 self-managed보다 managed services를 선호하세요.

10
문제 10

Your fintech startup's real-time payments API runs on GKE with a 99.9% monthly availability SLO and a latency SLI of p95 < 250 ms. Over the last quarter, there have been 3 production incidents per month where p95 latency exceeded 1,200 ms and error rate surpassed 5% for 30-minute windows. Engineers push feature branches and execute schema migrations directly against the production cluster during business hours, and data scientists run configuration experiments in production. QA teams also perform load tests that ramp from 50 rps to 500 rps against the production endpoint twice a week, saturating the autoscaler and causing throttling. You must redesign the environment to reduce production bugs and outages while allowing QA to load test new features at realistic scale. What should you do?

Synthetic canary는 감지와 alerting을 개선하여 observability와 더 빠른 incident response에 유용합니다. 하지만 근본 원인인 통제되지 않은 프로덕션 변경과 프로덕션 용량을 포화시키는 의도적인 load test를 해결하지 못합니다. canary는 고객이 여전히 latency와 error를 겪는 동안 더 빨리 알림만 줄 수 있습니다. 가용성/latency SLO를 충족하려면 환경 격리와 gate된 릴리스로 예방이 필요합니다.

개발자와 테스터가 공유하는 단일 저용량 dev cluster는 비용을 줄이지만, 현실적인 규모로 load test를 해야 한다는 요구사항을 충족하지 못합니다. 프로덕션 용량의 25%에서는 성능 결과가 프로덕션 동작(autoscaler threshold, saturation point, p95 latency)을 반영하지 않습니다. 또한 dev와 QA workload를 섞으면 contention과 불안정성이 증가하며, config 실험과 migration을 위한 안전한 pre-production gate도 여전히 제공하지 못합니다.

프로덕션 접근을 잠그는 것은 방향성은 맞지만(직접 변경 감소), real-time payments API에서 연 1회의 통제된 업데이트를 예약하는 것은 실행 불가능합니다. 이는 기능 제공, 보안 패치, 긴급 수정까지 막아 장기 리스크를 증가시킵니다. 목표는 변경을 멈추는 것이 아니라 CI/CD, 테스트, 승인, progressive delivery 및 rollback을 통해 변경을 안전하게 만드는 것입니다.

dev와 staging/test 환경을 분리하고 CI/CD를 통해 promotion을 gate하는 것은 문제를 직접 해결합니다: 실험, migration, load test가 프로덕션에 영향을 주지 않도록 하면서도 현실적인 성능 검증을 가능하게 합니다. 프로덕션을 미러링하는 staging 환경은 500 rps 테스트와 config 실험을 안전하게 지원합니다. CI/CD gate(automated test, approval, policy check)는 변경 실패율을 낮추고 프로덕션 error budget을 보호하여 SLO 준수를 개선합니다.

문제 분석

핵심 개념: 이 문제는 프로덕션 신뢰성을 보호하면서도 현실적인 테스트를 가능하게 하기 위해 CI/CD를 활용한 환경 전략과 릴리스 거버넌스를 평가합니다. 이는 SRE 변경 관리와 Google Cloud Architecture Framework의 Reliability 기둥과 일치합니다: 변경으로 인한 리스크를 줄이고, blast radius를 격리하며, 프로덕션 전에 검증합니다. 정답이 맞는 이유: 현재 프로세스는 기본적인 프로덕션 통제를 위반합니다: 엔지니어가 prod에서 직접 schema migration과 실험을 수행하고, QA load test가 프로덕션 autoscaler에 과부하를 주어 throttling과 사용자에게 보이는 latency/errors를 유발합니다. 올바른 재설계는 환경을 분리하고 CI/CD gate를 통해 promotion을 강제하는 것입니다. 프로덕션을 미러링하는 staging/test 환경(용량, config, version, autoscaling, network policy)이 있으면 QA가 높은 RPS load test를 실행하고 새로운 기능을 검증하더라도 프로덕션 error budget을 소모하거나 99.9% SLO에 영향을 주지 않습니다. development는 빠른 반복을 위한 더 낮은 리스크로 유지됩니다. 핵심 기능 / Best Practice: - dev, staging, prod를 위해 별도의 GKE cluster를 사용(또는 최소한 강한 격리를 갖춘 별도의 namespace/project)하며, 일반적으로 IAM 및 quota 격리를 위해 별도의 project를 사용합니다. - staging에서 프로덕션을 미러링: 동일한 node pool, autoscaling 설정(HPA/VPA/Cluster Autoscaler), ingress, service mesh policy, dependency(또는 프로덕션과 유사한 replica). - CI/CD(Cloud Build/GitHub Actions + Artifact Registry + Config Sync/Argo CD/Flux를 통한 GitOps)로 dev → staging → prod로 container image와 Kubernetes manifest를 promotion. - approval gate, automated test(unit/integration), policy check(Binary Authorization, OPA/Gatekeeper), progressive delivery(canary/blue-green)를 추가하여 리스크를 줄입니다. - 통제된 pipeline(예: expand/contract pattern)과 예약된 change window를 통해 schema migration을 처리합니다. 흔한 오해: Observability(canary)는 문제를 감지하는 데 도움이 되지만, load test와 직접적인 prod 변경으로 인한 자가 유발 장애를 예방하지는 못합니다. 단일 소규모 dev cluster로는 500 rps에서의 성능이나 프로덕션 autoscaling 동작을 검증할 수 없습니다. “prod를 잠그고 매년 업데이트”는 fintech에서 비현실적이며 보안/운영 리스크를 증가시킵니다. 시험 팁: 프로덕션이 실험/load test에 사용되고 있다면, DevOps 시험은 보통 다음을 기대합니다: 환경 분리 + CI/CD gate 기반 promotion + 프로덕션 보호(IAM, policy, progressive rollout). 변경 실패율을 낮추고 테스트를 프로덕션 error budget에서 격리하는 답을 찾으세요.

합격 후기(6)

R
R**********Nov 24, 2025

학습 기간: 1 month

The exam has many operational scenarios, and Cloud Pass prepared me well for them. The explanations were clear and helped me understand not just the “what” but the “why” behind each solution.

진
진**Nov 20, 2025

학습 기간: 1 month

문제와 해설이 있어서 좋았고, 시험에서 무난하게 합격했어요. 시험에서 안보이던 유형도 나왔는데 잘 풀긴 했네요

J
J************Nov 17, 2025

학습 기간: 1 month

The practice questions were challenging in a good way, and many matched the style of the real exam. I passed!

N
N************Nov 14, 2025

학습 기간: 1 month

very close to the real exam format

D
D***********Oct 18, 2025

학습 기간: 1 month

I used Cloud Pass during my last week of preparation, and it helped me fill in gaps I didn’t even know I had.

← 모든 Google Professional Cloud DevOps Engineer 문제 보기

지금 학습 시작하기

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

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