CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
  1. Cloud Pass
  2. GCP
  3. Google Professional Cloud Security Engineer
Google Professional Cloud Security Engineer

GCP

Google Professional Cloud Security Engineer

340+ 기출 문제 (AI 검증 답안 포함)

Free questions & answers실제 시험 기출 문제
AI-powered explanations상세 해설
Real exam-style questions실제 시험과 가장 유사
340+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

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

시험 도메인

Configuring Access출제율 25%
Securing Communications and Establishing Boundary Protection출제율 22%
Ensuring Data Protection출제율 23%
Managing Operations출제율 19%
Supporting Compliance Requirements출제율 11%

실전 문제

1
문제 1
(2개 선택)

Your company operates a single Google Cloud organization with 10 folders and 150 projects, and the SOC requires that all Google Cloud Console sign-in events and API calls that change resource configurations be streamed to an external SIEM in under 60 seconds, with coverage for all existing and future projects. Requirements:

  • Collect and export the relevant logs for the entire organization hierarchy (folders and projects).
  • Deliver logs to the SIEM in near real time (<60 seconds).
  • Include Console login events and admin activity that modifies configurations. What should you do? (Choose two.)

organization-level sink는 모든 프로젝트를 포괄한다는 점에서 방향은 맞지만, Cloud Storage는 거의 실시간 SIEM ingest에 적합하지 않습니다. Storage sink는 내구성 있는 아카이브와 배치 처리를 위해 최적화되어 있으며, SIEM은 일반적으로 스트리밍 엔드포인트를 통해 ingest합니다. 추가 구성 요소(예: notifications + processing)를 구축할 수는 있지만, Pub/Sub에 비해 복잡성이 증가하고 <60초 요구 사항을 안정적으로 충족하지 못할 수 있습니다.

정답입니다. includeChildren이 있는 organization-level aggregated sink는 프로젝트별 설정 없이도 향후 프로젝트를 포함하여 모든 폴더와 프로젝트의 로그를 캡처합니다. Pub/Sub로 라우팅하면 거의 실시간 전달을 지원하며 일반적인 SIEM 통합 패턴입니다(subscriber가 메시지를 pull하거나 connector가 이후 단계로 스트리밍). 이는 <60초 요구 사항을 충족하고 organization 수준에서 export 관리를 중앙화합니다.

Data Access audit logs를 조직 전체로 활성화하는 것은 명시된 요구 사항에 필요하지 않으며 로그 볼륨과 비용을 크게 증가시킬 수 있습니다. 요구 사항은 구성 변경 API 호출(기본 활성화된 Admin Activity logs로 커버)과 Console sign-in events(identity audit logs)입니다. Data Access logs는 사용자 데이터에 대한 read/write 액세스(예: object reads)를 위한 것이지, 주로 관리자 구성 변경을 위한 것이 아닙니다.

정답입니다. Cloud Console sign-in events는 일반적으로 Cloud Audit Logs가 아니라 Google Workspace(또는 Cloud Identity) audit logs에 캡처됩니다. Workspace audit logs를 Cloud Logging으로 export하도록 활성화하면 해당 sign-in events를 Cloud Logging에서 사용할 수 있고, organization-level sink가 이를 Pub/Sub로 라우팅하여 SIEM이 ingest할 수 있습니다. 이것이 동일한 파이프라인에 Console login events를 포함하기 위한 핵심 단계입니다.

AuthenticationInfo를 파싱하면 많은 Cloud Audit Logs 항목에서 principal을 식별하는 데 도움이 될 수 있지만, 핵심 요구 사항을 해결하지는 못합니다. org-wide 커버리지를 만들지 못하고, 스트리밍 export 메커니즘을 제공하지 못하며, Cloud Logging에 존재하지 않는 Console sign-in events를 추가하지도 못합니다. 이는 SIEM enrichment를 위한 구현 세부 사항이지, 요구되는 두 가지 아키텍처 조치 중 하나가 아닙니다.

문제 분석

핵심 개념: 이 문제는 Cloud Logging sink와 Cloud Audit Logs를 사용한 조직 전체 로깅 아키텍처, 그리고 보안 관련 이벤트를 낮은 지연 시간으로 외부 SIEM으로 스트리밍하는 방법을 평가합니다. 또한 “Google Cloud Console sign-in events”가 실제로 무엇이며 어디에서 생성되는지에 대한 이해도 테스트합니다. 정답인 이유: 조직 계층 전반의 모든 기존 및 향후 프로젝트를 포괄하려면 includeChildren이 활성화된 organization-level aggregated log sink를 생성해야 합니다. 이렇게 하면 프로젝트별 구성 없이도 모든 폴더와 프로젝트(현재 및 향후)의 로그가 수집됩니다. 거의 실시간 전송(<60초)을 위해서는 Pub/Sub가 올바른 sink 대상입니다. Pub/Sub는 스트리밍 소비 패턴과 낮은 지연 시간으로 외부 시스템에 전달하는 기능을 지원합니다. Cloud Storage는 주로 배치/아카이브 용도이므로 거의 실시간 요구 사항을 충족하지 못합니다. Console sign-in events는 Cloud Audit Logs의 “Admin Activity” 항목이 아닙니다. Cloud Console에 대한 대화형 sign-in은 일반적으로 Google Workspace(또는 Cloud Identity) audit logs에 기록되는 identity 이벤트입니다. 이를 Cloud Logging으로 라우팅하여 동일한 org-level sink를 통해 Pub/Sub로 내보내려면 Google Workspace audit logs를 Cloud Logging으로 export하도록 활성화해야 합니다. 이렇게 하면 Console login events에 대한 필요한 커버리지를 확보할 수 있습니다. 주요 기능 및 모범 사례: - includeChildren이 있는 organization-level sinks는 150개 이상의 프로젝트와 향후 성장에 대해 중앙 집중식 거버넌스와 확장성을 제공합니다. - Pub/Sub sinks는 SIEM 스트리밍을 위한 표준 패턴이며, SIEM은 subscriber/connector를 통해 메시지를 pull하거나 push된 메시지를 수신할 수 있습니다. - Admin Activity audit logs는 기본적으로 활성화되어 있으며 구성 변경 API 호출을 캡처합니다. 또한 보존되며 비활성화할 수 없습니다. - 텔레메트리를 중앙화하고 신속한 탐지를 가능하게 함으로써 Google Cloud Architecture Framework의 “Operational Excellence” 및 “Security, Privacy, and Compliance”에 부합합니다. 흔한 오해: 많은 사람들이 Cloud Audit Logs에 이미 Console sign-in events가 포함되어 있다고 가정하지만, 일반적으로 그렇지 않습니다. 또 다른 함정은 요구 사항이 구성 변경 활동(Admin Activity)과 sign-ins에 한정되어 있는데도 Data Access logs(종종 비용이 높고 볼륨이 큼)를 활성화하는 것입니다. 시험 팁: “모든 프로젝트(향후 포함)”가 보이면 org-level sink + includeChildren을 떠올리세요. “SIEM으로 <60초”가 보이면 Pub/Sub(또는 분석 목적의 BigQuery일 수는 있지만 스트리밍은 아님)를 떠올리세요. Cloud Audit Logs(API 활동)와 identity sign-in logs(Workspace/Cloud Identity)를 구분하세요.

2
문제 2

Your healthcare analytics startup is building a multi-region telemetry pipeline on Google Cloud that spans Compute Engine VMs, a GKE Autopilot cluster, Cloud Storage buckets, BigQuery datasets (~50 TB), and Pub/Sub topics processing ~80,000 messages per second. Under your GDPR data protection by design program, the security review mandates that: (1) you—not Google—must control key creation, 90-day rotation, and IAM-scoped usage of encryption keys; (2) keys must reside in Google Cloud KMS/HSM with no dependency on external key stores; and (3) a single key management approach must be supported uniformly across all listed services. Which option should you choose to meet these requirements?

Cloud External Key Manager (EKM)는 외부 키 관리 시스템(종종 온프레미스 또는 third-party HSM)에 저장된 키와 Google Cloud 서비스를 통합합니다. 이는 강력한 고객 통제와 Google로부터의 분리를 제공할 수 있지만, “외부 키 스토어에 대한 의존성 없음” 및 “키는 Google Cloud KMS/HSM에 상주해야 함”이라는 요구사항을 위반합니다. 따라서 이 시나리오에 적합하지 않습니다.

Customer-managed encryption keys (CMEK)는 고객이 생성하고 제어하는 Cloud KMS(선택적으로 Cloud HSM-backed) 키를 사용합니다. IAM 범위의 사용을 강제하고, key versions를 관리하며, 90일 로테이션 정책을 구성할 수 있습니다. CMEK는 Cloud Storage, BigQuery, Pub/Sub, Compute Engine을 포함한 주요 데이터 및 메시징 서비스 전반에서 지원되어, 키를 전적으로 Google Cloud 내에 유지하면서 단일하고 일관된 접근 방식을 가능하게 합니다.

Customer-supplied encryption keys (CSEK)는 요청 시점에 raw key material을 Google Cloud 서비스에 제공해야 합니다. 이는 운영 복잡성을 증가시키고 로테이션을 어렵게 하며, 나열된 모든 서비스에서 일관되게 지원되지 않습니다(특히 BigQuery 및 Pub/Sub 같은 많은 managed services는 CSEK가 아니라 CMEK에 의존합니다). 또한 키가 Cloud KMS/HSM에 상주해야 한다는 요구사항을 충족하지 못합니다.

Google default encryption은 Google-managed keys를 사용하며 at rest 암호화를 자동으로 제공하지만, 키 생성, 로테이션 주기, 또는 IAM 범위의 키 사용을 고객이 제어할 수 없습니다. 이는 고객—Google이 아니라—이 키 라이프사이클과 접근을 제어해야 한다는 명시적 요구사항을 충족하지 못합니다. 또한 규제 환경에서 흔한 컴플라이언스 기반 “고객 통제” 기대에도 부합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서의 암호화 키 관리 선택지—특히 Google-managed encryption, Cloud KMS/Cloud HSM의 customer-managed encryption keys (CMEK), customer-supplied encryption keys (CSEK), 그리고 External Key Manager (EKM) 간의 차이—를 평가합니다. 또한 여러 서비스(Compute Engine, GKE, Cloud Storage, BigQuery, Pub/Sub) 전반에 걸친 일관된 적용 가능성과 컴플라이언스 기반 통제(GDPR의 “data protection by design”)도 함께 테스트합니다. 정답이 맞는 이유: Customer-managed encryption keys (CMEK)는 세 가지 요구사항을 동시에 모두 충족하는 유일한 옵션입니다: (1) Cloud KMS 권한을 통한 IAM 범위의 사용 제어와 함께 키 생성 및 로테이션(90일 로테이션 포함)을 고객이 제어할 수 있고, (2) 키가 Google Cloud KMS에 상주하며 Cloud HSM으로 백업될 수 있고(여전히 Google Cloud 네이티브이며 외부 키스토어 의존성이 없음), (3) CMEK가 나열된 서비스 전반에서 폭넓게 지원되어 단일하고 일관된 접근 방식을 가능하게 합니다. 주요 기능 / 구현 방법: - 멀티 리전 아키텍처에 맞춰 Cloud KMS key rings/keys(리전)를 사용하고, 더 높은 보증이 필요하면 Cloud HSM-backed keys를 사용합니다. - IAM 최소 권한을 강제합니다: roles/cloudkms.cryptoKeyEncrypterDecrypter(또는 가능하면 더 좁은 권한)를 통해 서비스에 CryptoKey 접근을 부여하고, 키 관리자에 대해 직무 분리를 적용합니다. - 로테이션을 구성합니다: rotation period를 90일로 설정하고, 지원되는 경우 새 key versions가 자동으로 사용되도록 보장합니다. - 서비스 통합: Cloud Storage bucket default KMS key, BigQuery dataset/table CMEK, Pub/Sub topic CMEK, Compute Engine disk/image/snapshot CMEK, 그리고 GKE (Autopilot)는 지원되는 암호화 사용 사례(예: node boot disks 및 구성에 따라 특정 control-plane 관련 암호화 기능)에서 CMEK와 통합됩니다. 흔한 오해: - “External Key Manager”는 더 강한 통제처럼 들리지만, 명시적으로 외부 키 스토어에 의존합니다—이 시나리오에서는 허용되지 않습니다. - “Customer-supplied encryption keys”는 최대 통제처럼 보일 수 있지만, 운영적으로 취약하고 모든 서비스에서 일관되게 지원되지 않으며, 키를 Cloud KMS/HSM에 유지해야 한다는 요구사항을 충족하지 못합니다. - Google default encryption은 항상 활성화되어 있지만, 키 라이프사이클이나 IAM 범위의 키 사용을 고객이 제어할 수 없습니다. 시험 팁: 요구사항에 다음이 포함되면: 키 생성/로테이션 제어 + IAM 범위의 키 사용 제어 + 키가 Cloud KMS/HSM에 상주 + 광범위한 서비스 지원, 시험에서는 거의 항상 CMEK (Cloud KMS/Cloud HSM)를 가리킵니다. 외부 키 보관이 요구된다면 EKM/Cloud HSM과 외부 시스템이 등장할 수 있지만, 여기서는 외부 의존성이 명시적으로 금지되어 있습니다.

3
문제 3

You lead network security for a fintech trading platform on Google Cloud. You currently detect anomalies using VPC Flow Logs exported to BigQuery with a 5-minute aggregation interval across three VPCs. A red team exercise now requires examining full packet payloads and L4/L7 headers for east-west traffic between two production subnets (10.20.0.0/24 and 10.20.1.0/24) in a single VPC and forwarding a copy of up to 8 Gbps of this traffic to a third-party NIDS running on a Compute Engine VM, without altering original packets. Which Google Cloud product should you use?

Cloud IDS는 Google Cloud에서 네트워크 위협을 모니터링하기 위한 관리형 침입 탐지(Palo Alto Networks 기술 기반)를 제공합니다. Google이 관리하는 탐지 및 알림이 필요할 때 적합하며, 원시 미러링 트래픽을 서드파티 NIDS VM으로 전달해야 하는 경우에는 적합하지 않습니다. Cloud IDS는 내부적으로 Packet Mirroring을 통해 트래픽을 소비하지만, 패킷을 변경하지 않고 트래픽 사본을 자체 NIDS로 보내야 한다는 명시적 요구사항을 충족하지 못합니다.

VPC Service Controls 로그는 데이터 유출 위험을 줄이기 위해 Google 관리형 서비스(예: BigQuery, Cloud Storage)에 대한 서비스 perimeter 이벤트 및 접근과 관련됩니다. VPC east-west 패킷 페이로드나 L4/L7 헤더를 캡처하지 않으며 네트워크 IDS로 트래픽을 전달할 수도 없습니다. “fintech”와 컴플라이언스 때문에 관련 있어 보일 수 있지만, 패킷 수준 검사를 위한 텔레메트리 유형이 아닙니다.

VPC Flow Logs는 샘플링/집계된 네트워크 플로우 메타데이터(5-tuple, bytes, packets, TCP flags 등)를 제공하며, 대규모 트래픽 분석 및 이상 탐지에 유용합니다. 그러나 전체 패킷 페이로드를 포함하지 않으며 L7 콘텐츠를 재구성할 수 없습니다. 문제는 페이로드를 검사하고 최대 8 Gbps 트래픽의 사본을 전달해야 한다고 명시하므로, Flow Logs로는 불가능합니다.

Google Cloud Armor는 외부 HTTP(S) load balancer 및 일부 다른 프런트 도어 시나리오를 위한 엣지 보안 서비스(WAF 및 DDoS 보호)입니다. subnet 간 내부 east-west 트래픽에 대한 패킷 캡처를 제공하지 않으며, 서드파티 NIDS로 트래픽을 미러링하지도 않습니다. 일반적인 네트워크 보안 도구로 혼동되기 쉽지만, 인터넷 노출 애플리케이션 보호에 특화되어 있습니다.

Packet Mirroring이 정답인 이유는 packet headers와 payloads를 포함한 VM network traffic의 out-of-band copies를 생성하여 심층 검사를 가능하게 하기 때문입니다. 이는 두 subnets 간 east-west traffic을 분석하고 원본 packets를 변경 없이 유지해야 한다는 요구 사항을 직접적으로 충족합니다. Google Cloud에서 mirrored traffic은 internal passthrough Network Load Balancer 뒤의 collector architecture로 전달되며, 이것이 Compute Engine의 third-party NIDS가 traffic을 수신하고 검사할 수 있는 방식입니다. 또한 selective mirroring과 filtering을 지원하므로 전체 VPC가 아니라 관련 production subnet traffic으로 범위를 제한할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 east-west traffic에 대해 심층 검사를 수행할 수 있도록 full-fidelity packet copies를 제공하는 Google Cloud 기능을 선택하는 것에 관한 것입니다. 요구 사항은 L4/L7 headers와 함께 전체 packet payloads를 검사하고, 원본 packets를 수정하지 않은 채 traffic의 사본을 third-party NIDS로 보내는 것입니다. 정답인 이유: Packet Mirroring은 이 정확한 사용 사례를 위해 설계된 Google Cloud 기능입니다. 이는 VPC의 선택된 VM instances에서 traffic을 미러링하고, 해당 packet copies를 internal passthrough Network Load Balancer 뒤의 collector로 out-of-band 방식으로 전송하여, production flows는 변경 없이 계속되는 동안 third-party NIDS 또는 packet analysis tools가 traffic을 검사할 수 있게 합니다. VPC Flow Logs와 달리, Packet Mirroring은 집계된 metadata가 아니라 실제 packet data를 제공합니다. 주요 기능: Packet Mirroring은 subnet, instance, tags, direction, protocol, CIDR ranges를 기준으로 filtering 및 scoping을 지원하므로, 단일 VPC 내 두 production subnets 간 traffic에 집중해야 하는 요구 사항에 적합합니다. 이는 deep packet inspection, forensic analysis, 그리고 partner 또는 self-managed security appliances와의 통합을 목적으로 합니다. 8 Gbps 요구 사항의 경우, collector architecture와 load balancer backend capacity를 적절히 sizing해야 합니다. 흔한 오해: Cloud IDS는 managed IDS service이지만, 요구 사항이 mirrored traffic을 자체 third-party NIDS VM으로 전달하라고 명시할 때 선택하는 제품은 아닙니다. VPC Flow Logs는 payloads가 아니라 flow metadata만 제공합니다. Cloud Armor는 edge application protection용이며, VPC Service Controls logs는 packet capture가 아니라 Google API perimeter events에 관한 것입니다. 시험 팁: 문제에서 full packet payloads, packet copies, east-west inspection, 또는 traffic을 third-party appliance로 보내는 내용을 언급하면 Packet Mirroring을 떠올리세요. 집계된 network metadata를 언급하면 VPC Flow Logs를 떠올리세요. managed IDS detections를 언급하면 Cloud IDS를 떠올리세요. edge에서의 WAF 또는 DDoS를 언급하면 Cloud Armor를 떠올리세요.

4
문제 4

You deploy a Cloud Run job in us-central1 that executes every 4 hours for ~20 minutes to compress and upload up to 500 MB of log archives into a Cloud Storage bucket named cr-logs-archive; the job must have write-only access (no read, list, or delete) to the bucket during execution, you want to avoid long-lived credentials, and you must grant only the minimum permissions required to complete the uploads—what should you do?

roles/storage.admin은 지나치게 권한이 큽니다. 객체 읽기/나열, 객체 삭제, bucket 구성 관리 같은 광범위한 기능을 포함합니다. 이는 쓰기 전용 접근 및 최소 권한 요구사항을 위반합니다. Cloud Run 실행 ID로 서비스 계정을 사용하면 장기 자격 증명은 피할 수 있지만, 역할 선택이 최소 권한을 충족하지 못하고 job이 침해될 경우 영향 범위를 키웁니다.

장기 JSON key를 생성해 container image에 포함(bake)하는 것은 안티패턴입니다. 장기 자격 증명을 피하라는 요구사항과 정면으로 충돌하며, 중대한 secret 관리 위험(이미지 registry, 로그, 런타임 filesystem에서의 키 유출)을 만듭니다. 키가 쓰기 권한으로 제한되어 있더라도, 키 rotation과 revocation은 운영 부담이 되고 보안 사고의 흔한 원인이 됩니다.

여기서는 서비스 계정 impersonation이 불필요하며 일반적으로 필요한 권한을 증가시킵니다. impersonate하려면 job의 ID가 대상 서비스 계정에 대해 roles/iam.serviceAccountTokenCreator 같은 권한을 가져야 하며, 이는 IAM 표면적을 확장합니다. Cloud Run은 의도한 서비스 계정으로 그냥 실행하고 단기 token을 자동으로 획득할 수 있어, 더 적은 구성 요소와 더 낮은 위험으로 동일한 목표를 달성합니다.

이 옵션이 최선입니다: cr-logs-archive bucket에 roles/storage.objectCreator를 Cloud Run job의 실행 서비스 계정에 부여합니다. 그러면 job은 단기이며 자동으로 제공되는 자격 증명(키 없음)을 사용하고, 객체 생성 권한만 받아 쓰기 전용 요구사항(읽기/나열/삭제 없음)을 충족합니다. 또한 프로젝트 전체가 아니라 단일 bucket으로 binding 범위를 제한하여 최소 권한을 지원합니다.

문제 분석

핵심 개념: 이 문제는 장기 키가 아닌 단기, 워크로드에 연결된 자격 증명(서비스 계정 ID)을 사용하여 Cloud Run jobs에서 Cloud Storage에 접근할 때 IAM 최소 권한을 테스트합니다. 올바르고 최소한으로 접근을 구성하는 데 초점을 둡니다. 정답이 맞는 이유: Cloud Run jobs는 실행 ID(서비스 계정)로 실행됩니다. job이 Cloud Storage bucket에 객체를 쓸 때, job의 서비스 계정을 사용해 인증해야 하며 metadata server/Workload Identity 통합을 통해 단기 OAuth token을 자동으로 받습니다—키가 필요 없습니다. “쓰기 전용” 동작을 강제하려면 읽기/나열/삭제가 아니라 새 객체 생성 권한만 부여해야 합니다. 대상 bucket에 대한 사전 정의된 역할 roles/storage.objectCreator는 storage.objects.create(및 관련 최소 권한)를 부여하면서 storage.objects.get, storage.objects.list, storage.objects.delete는 부여하지 않습니다. 이 역할을 bucket(리소스 수준 IAM)에서 Cloud Run job의 실행 서비스 계정에 직접 부여하는 것이 가장 단순하고 가장 안전한 접근입니다. 주요 기능 / 모범 사례: - Cloud Run job 실행 서비스 계정(내장 secret 없음)을 사용해 단기 token을 획득합니다. - IAM을 가장 좁은 범위에 적용합니다: 프로젝트 전체가 아니라 cr-logs-archive에 대한 bucket-level binding. - roles/storage.objectCreator는 업로드(생성 전용)에 대한 최소 권한과 일치합니다. - 서비스 계정 키를 피하고, Google의 managed identity 및 token minting을 선호합니다. 흔한 오해: - “storage.admin”은 편리해 보이지만 읽기/나열/삭제 및 bucket 관리까지 허용하여 최소 권한을 위반합니다. - JSON key를 이미지에 포함(bake)하는 것은 명시적으로 권장되지 않습니다. 장기 자격 증명을 만들고 키 유출 위험을 초래합니다. - Impersonation은 multi-hop 또는 cross-project 시나리오에서 유용할 수 있지만, 복잡성을 추가하고 Cloud Run이 올바른 서비스 계정으로 직접 실행될 때는 불필요한 추가 권한(iam.serviceAccounts.getAccessToken / Token Creator)이 필요합니다. 시험 팁: Cloud Run/Cloud Functions/GKE에서는 기본적으로 런타임 서비스 계정을 사용하고 특정 리소스에 대해 좁게 범위를 제한한 IAM을 적용하세요. 요구사항에 “장기 자격 증명 회피”가 있으면 JSON key를 제거하세요. “쓰기 전용”이라면 storage.objectCreator(create) 같은 역할을 찾고, storage.objectAdmin(create/delete) 또는 storage.admin(전체 제어)은 피하세요. 또한 영향 범위를 줄이기 위해 project-level 부여보다 resource-level IAM binding(bucket)을 선호하세요.

5
문제 5

A media-streaming startup must launch a public REST API on Cloud Run behind an external HTTP(S) Load Balancer within 48 hours, and the security team mandates minimizing the container image’s attack surface (target image size under 200 MB, no interactive shell or package manager, and only required runtime files) without changing networking or deployment tools; what should the team do to meet this requirement?

Cloud Build는 컨테이너 이미지를 compile 및 build할 수 있지만, 그 자체만으로 공격 표면을 줄이는 조치는 아닙니다. Dockerfile/base image에 shell과 package manager가 포함되어 있으면 Cloud Build로도 여전히 큰 이미지를 만들 수 있습니다. Cloud Build는 전달 메커니즘이며, 여기서의 보안 요구사항은 runtime 이미지 내용(최소 filesystem, shell 없음)에 관한 것으로, Cloud Build만으로는 이를 보장하지 못합니다.

Distroless 또는 scratch 기반 이미지는 runtime footprint를 최소화하도록 설계되었습니다. 즉, 대화형 shell과 package manager를 제외하고 애플리케이션과 필요한 runtime library만 포함합니다. multi-stage build와 결합하면 더 작은 이미지를 안정적으로 만들 수 있고, 공격자가 사용할 수 있는 binary 수를 줄일 수 있습니다. 이는 networking이나 배포 도구를 변경하지 않으면서, 명시된 제약(크기, shell 없음, package manager 없음, 필요한 파일만)을 직접적으로 충족합니다.

Artifact Registry에서 사용하지 않는 image tag를 삭제하면 clutter를 줄이고 governance에 도움이 될 수 있지만, Cloud Run에 배포되는 이미지의 보안 상태를 바꾸지는 않습니다. 공격 표면은 registry에 tag가 몇 개 있는지가 아니라, 실행 중인 컨테이너 이미지 layer 내부에 무엇이 들어 있는지에 의해 결정됩니다. 이는 운영 위생(operational hygiene)이지 컨테이너 하드닝이 아닙니다.

Cloud Deploy 같은 CD 도구는 릴리스 관리(progressive delivery, approvals, rollbacks)를 개선하지만, 컨테이너 이미지 크기를 줄이거나 shell/package manager를 제거하지는 않습니다. 이 문제의 제약은 48시간 내에 컨테이너의 runtime 내용을 최소화하는 것이며, 새로운 CD 도구를 도입하는 것은 불필요하고 이미지 하드닝 요구를 직접적으로 충족하기도 어렵습니다.

문제 분석

핵심 개념: 이 문제는 Cloud Run 서비스에 대한 컨테이너 하드닝과 공급망 보안을 평가합니다. Google Cloud Architecture Framework (Security, Reliability)의 핵심 모범 사례는 프로덕션 컨테이너에서 배포되고 실행되는 구성 요소를 최소화하여 공격 표면을 줄이는 것입니다. 정답이 맞는 이유: 요구사항은 컨테이너 이미지의 공격 표면을 최소화하는 것에 명시적으로 초점이 있습니다: 200 MB 미만의 목표 크기, 대화형 shell 없음, package manager 없음, 그리고 필요한 runtime 파일만 포함. distroless(또는 가능한 경우 scratch) 기반으로 이미지를 빌드하면 이러한 제약을 직접적으로 충족합니다. Distroless 이미지는 애플리케이션과 runtime 의존성(예: language runtime 및 필요한 library)만 포함하고 shell과 package manager를 제외하므로, 악용 가능한 도구를 줄이고 침해 이후의 행위를 제한합니다. 이는 networking(external HTTP(S) Load Balancer)이나 배포 도구(Cloud Run)를 변경하지 않으면서, 명시된 보안 요구를 충족하는 가장 직접적인 통제입니다. 핵심 기능 / 모범 사례: - multi-stage build 사용: builder stage(예: golang, node, maven)에서 compile/build를 수행하고, 최종 artifact만 distroless runtime stage로 복사합니다. - distroless variant(예: gcr.io/distroless/base-debian12, java, nodejs)를 선호하여 필요한 CA certs와 libc는 유지하면서도 shell/package manager는 제거합니다. - 가능한 경우 non-root로 실행하고 최소한의 filesystem layout을 설정하며, 필요한 certs/config만 포함합니다. - vulnerability scanning(Artifact Registry scanning) 및 policy control과 함께 적용할 수 있지만, 이 문제의 1차 통제는 이미지 구성(image composition)입니다. 흔한 오해: 팀은 종종 “Cloud Build를 사용하면” 자동으로 안전한 이미지를 만든다고 생각합니다. Cloud Build는 build 서비스이며, Dockerfile을 그에 맞게 설계하지 않으면 runtime layer를 줄이거나 shell/package manager를 제거하지 않습니다. 마찬가지로 Artifact Registry에서 tag를 정리하는 것은 위생(hygiene)을 개선하지만 프로덕션에서 실행되는 내용을 바꾸지는 않습니다. CD 도구는 롤아웃 안전성을 개선하지만, 제시된 이미지 하드닝 제약을 충족하지는 못합니다. 시험 팁: “no shell”, “no package manager”, “only runtime files” 같은 요구사항이 보이면, 시험은 distroless/scratch와 multi-stage build를 가리키는 것입니다. 통제를 보안 계층에 매핑하세요: CI/CD 오케스트레이션이나 registry 정리 작업이 아니라 runtime 컨테이너 내용(image hardening)입니다. 또한 이는 networking을 바꾸지 않고 컨테이너 artifact만 바꾸므로 Cloud Run 및 external HTTP(S) Load Balancing과도 호환됩니다.

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

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

6
문제 6

Your company has a three-level resource hierarchy: Organization > Business Unit folders > Team folders, and you are onboarding 12 platform squads that each receive a dedicated Terraform provisioner service account; each squad must be able to create and fully manage projects only under its assigned team folder (for example, folders/789012345678) while adhering to least privilege and preventing project creation in any other location; you need a scalable, centrally managed approach that supports Infrastructure as Code and avoids granting broad administrative control at the folder or organization level; what should you do?

team folder에 roles/resourcemanager.folderAdmin을 부여하는 것은 명시된 요구사항에 비해 필요 이상으로 광범위합니다. 이 role은 folder 자체를 관리하기 위한 것으로, 그 아래에서 project를 생성하는 것만을 넘어서는 folder management capability를 포함합니다. 문제에서 folder 또는 organization level의 광범위한 administrative control을 피하라고 명시했으므로, 이는 least privilege를 위반합니다. 또한 provisioner service account가 손상될 경우 blast radius가 project creation에만 국한되지 않고 folder administration까지 확장되므로 불필요한 위험을 초래합니다.

organization level의 roles/resourcemanager.projectCreator는 project를 생성할 수 있는 능력을 제공하며, resource.parent를 squad의 team folder로 제한하는 IAM Condition은 project를 생성할 수 있는 위치에 대한 강력한 경계를 강제합니다. 이는 확장 가능하고(12개 squad에 대해 반복 가능한 패턴), 중앙에서 관리되며, IaC 친화적이고, folder/organization admin roles를 피하면서도 다른 위치에서의 project creation을 방지하므로 least privilege에 부합합니다.

organization level에 roles/editor를 부여하는 것은 지나치게 허용 범위가 넓으며 least-privilege 설계와 명백히 충돌합니다. 이는 organizational resources 전반에 걸쳐 광범위한 access를 제공하며, project creation을 특정 folder 하나로 제한하는 강력하고 중앙에서 강제되는 경계를 만들지 못합니다. 나중에 squad가 더 세분화된 IAM을 적용하도록 하는 방식은 예방적이기보다 사후 대응적이며, 일관성 없는 governance로 이어집니다. 따라서 이 선택지는 과도한 권한을 부여할 뿐 아니라 중앙 통제 측면에서도 운영적으로 취약합니다.

roles/resourcemanager.folderIamAdmin은 principal이 folder의 IAM policy를 관리할 수 있게 하며, 이는 민감한 administrative capability입니다. 이 permission은 service account가 자신이나 다른 주체에게 추가 access를 부여할 수 있으므로 privilege escalation을 가능하게 할 수 있습니다. 또한 이는 오직 하나의 할당된 folder 아래에서만 통제된 project creation이 가능해야 한다는 핵심 요구사항을 직접 해결하지도 않습니다. 문제는 광범위한 administrative control을 피하면서 중앙에서 관리되는 least-privilege 접근 방식을 요구하므로, 이 선택지는 적절하지 않습니다.

문제 분석

핵심 개념: 이 문제는 resource hierarchy governance(Organization > Folders > Projects)를 위한 Google Cloud IAM 설계를 테스트하며, 특히 least privilege를 사용해 project creation location을 제어하는 방법을 다룹니다. 또한 IAM Conditions(conditional role bindings)와 Terraform 기반 provisioning에 적합한 확장 가능하고 중앙에서 관리되는 access pattern도 함께 다룹니다. 정답인 이유: 각 squad가 자신의 team folder 아래에서만 project를 생성하고 완전히 관리할 수 있도록 하려면 두 가지가 필요합니다. (1) project를 생성할 수 있는 권한, 그리고 (2) 다른 위치에서는 생성하지 못하도록 하는 강력한 경계입니다. organization level에서 roles/resourcemanager.projectCreator를 부여하면 project creation permission(resourcemanager.projects.create)을 제공할 수 있습니다. 여기에 대상 parent를 확인하는 IAM Condition(예: resource.parent == "folders/789012345678")을 추가하면, 해당 권한을 어디에서 사용할 수 있는지 제한할 수 있습니다. 이는 일관된 패턴을 중앙에서 관리할 수 있으면서도(org-level bindings), condition을 통해 각 squad를 특정 folder로 제한할 수 있기 때문에 확장성이 높습니다. 또한 광범위한 folder/organization admin privilege를 부여하지 않아도 됩니다. 주요 기능 및 모범 사례: - IAM Conditions는 IAM bindings에 대해 attribute-based access control을 허용하여, “이 folder 아래에서만 생성”과 같은 제약을 가능하게 합니다. - 중앙 집중식 governance: org-level binding + condition은 12개 squad에 대해 folder admin을 위임하는 것보다 감사 및 표준화가 더 쉽습니다. - Least privilege: projectCreator는 folderAdmin/editor보다 더 제한적이며, folder structure나 IAM을 광범위하게 수정할 수 있는 권한을 부여하지 않습니다. - “project를 완전히 관리”하려면 일반적으로 생성 후 automation을 통해 project-level roles를 함께 부여합니다. 예: 새로 생성된 project에 roles/resourcemanager.projectIamAdmin 및/또는 predefined admin roles. 이 문제의 핵심 요구사항은 할당된 folder 외부에서의 생성을 방지하는 것이며, conditional projectCreator가 그 경계를 강제하는 제어 수단입니다. 흔한 오해: - “team folder에 folderAdmin만 부여하면 된다”는 방식은 범위를 적절히 제한하는 것처럼 보이지만, project provisioning에 필요한 수준을 넘어서는 광범위한 folder management capability(리소스 이동, folder 삭제, hierarchy 조작 가능성 포함)를 부여합니다. - “org에 editor를 사용하라”는 것은 지나치게 광범위하며 least privilege를 위반합니다. 또한 location constraint도 강제하지 못합니다. - “folder IAM admin을 부여하라”는 것은 IAM policy 변경을 가능하게 하므로 privilege escalation으로 이어질 수 있으며, project creation을 직접 부여하지도 않습니다. 시험 팁: - project를 어디에서 생성할 수 있는지 제어하려면 roles/resourcemanager.projectCreator와 resource.parent에 대한 IAM Conditions를 떠올리세요. - 확장 가능한 multi-team governance를 위해 conditional하고 중앙에서 관리되는 bindings를 선호하세요. - privilege escalation에 주의하세요. IAM 설정을 허용하는 역할(folderIamAdmin, projectIamAdmin)은 강력하므로 엄격하게 통제해야 합니다. - 요구사항을 필요한 permission을 부여하는 최소 role에 매핑한 다음, Google Cloud Architecture Framework의 least privilege 및 centralized policy management라는 security principle에 맞춰 경계를 강제하는 conditions를 추가하세요.

7
문제 7
(2개 선택)

Your retail company is standing up a brand-new Google Cloud organization backed by a fresh Cloud Identity domain, and you must create exactly two super administrator accounts for break-glass use while meeting internal security baselines aligned to CIS; the environment has only standard internet egress with TLS (no VPN/Interconnect) and you must complete setup within 24 hours—when creating these super admin accounts, which two actions should you take to meet best practices and reduce risk? (Choose two.)

오답입니다. Access Context Manager access level은 Google Cloud resource에 대한 access를 제한할 수 있지만, super administrator의 sign-in을 차단하면 break-glass account의 목적을 무너뜨립니다. emergency(identity recovery, org-level misconfiguration) 상황에서는 super admin으로 authenticate할 수 있어야 합니다. best practice는 super admin 사용을 완전히 막는 것이 아니라 엄격히 통제하고 모니터링하는 것입니다.

오답입니다. organization root에서 IAM role binding을 제거하면 Google Cloud resource permission은 줄일 수 있지만, Cloud IAM 외부에 존재하는 Cloud Identity/Google Workspace super administrator privilege는 제거되지 않습니다. 또한 super admin은 초기 setup 및 recovery 동안 특정 permission이 필요할 수 있습니다. 더 나은 패턴은 least privilege를 적용한 day-to-day account를 분리하고 emergency를 위한 hardened super admin을 두는 것입니다.

정답입니다. hardware security key(FIDO2/U2F)는 phishing-resistant MFA를 제공하며 privileged account에 강력히 권장되어 CIS control 및 Google best practice에 부합합니다. super admin당 최소 2개의 key를 등록하면 강력한 authentication을 유지하면서 lockout에 대한 운영 리스크를 줄일 수 있습니다. 이는 identity compromise가 치명적일 수 있는 완전히 새로운 org에서 특히 중요합니다.

오답입니다. private network path는 일부 노출을 줄일 수 있지만, Google sign-in은 TLS를 사용해 public Internet 상에서도 안전하도록 설계되어 있습니다. 또한 시나리오에서 VPN/Interconnect가 없고 setup을 24시간 내 완료해야 한다고 명시합니다. private connectivity를 요구하는 것은 super admin account를 안전하게 생성/관리하기 위한 현실적이거나 필요한 prerequisite가 아닙니다.

정답입니다. 일상 업무용으로 별도의 non-privileged identity를 발급하고 super admin account는 break-glass 용도로만 엄격히 예약하면 least privilege를 강제하고 attack surface를 줄일 수 있습니다. 최고 privilege credential의 노출을 드물고 통제된 이벤트로 제한하여 phishing, malware에 의한 token theft, 또는 실수로 인한 오남용 가능성을 낮춥니다. 이는 표준 privileged access management best practice입니다.

문제 분석

핵심 개념: 이 문제는 Cloud Identity/Google Workspace super administrator를 사용하는 신규 Google Cloud 조직에 대해 안전한 identity 및 privileged access management를 테스트합니다. 이는 CIS 스타일의 baseline 및 “secure by design”이라는 Google Cloud Architecture Framework 원칙에 부합하며, 강력한 authentication, least privilege, separation of duties를 강조합니다. 정답이 맞는 이유: C가 맞는 이유는 super administrator account가 Cloud Identity/Google Workspace에서 가장 높은 privilege를 가진 identity이며, 자주 공격 대상이 되기 때문입니다. hardware security key(FIDO2/U2F)를 사용하는 phishing-resistant MFA를 강제하는 것은 CIS benchmark와 privileged account에 대한 Google 가이드에서 최상위 control입니다. admin당 최소 2개의 key를 요구하면(키 분실/파손) lockout 위험을 줄이면서도 강력한 assurance를 유지할 수 있습니다. E가 맞는 이유는 separation of duties와 least privilege를 구현하기 때문입니다. admin은 routine task(email, browsing, 일상적인 console 작업)에 super admin account를 사용하면 안 됩니다. 일상적인 identity에는 필요한 최소 IAM/admin role만 부여하고, super admin account는 break-glass recovery(예: billing/identity recovery, org-level emergency)를 위해 휴면 상태로 두고 엄격히 통제해야 합니다. 이는 노출 시간을 줄이고 credential theft 또는 실수로 인한 파괴적 작업 가능성을 낮춥니다. 주요 기능 / Best Practice: - privileged identity에는 phishing-resistant MFA(security key)를 사용하고 SMS/voice는 피합니다. - backup key를 등록하고 recoverability를 유지하기 위해 안전하게 보관합니다(예: 서로 다른 물리적 위치/secure storage). - 사용을 제한한 dedicated break-glass account를 유지하고, 강력한 monitoring 및 문서화된 procedure를 갖춥니다. - compliance 의도를 충족하기 위해 logging/alerting(Admin audit logs, Cloud Audit Logs) 및 정기 access review와 결합합니다. 흔한 오해: A는 보안에 좋아 보이지만 역효과입니다. super admin의 sign-in을 차단하면 emergency recovery가 불가능해집니다. B는 control plane을 오해합니다. super admin 권한은 Cloud Identity/Workspace에 있으며 Google Cloud IAM binding에만 있는 것이 아닙니다. IAM role을 제거해도 super admin capability는 제거되지 않으며, 필요한 org setup을 방해할 수 있습니다. D는 여기서는 비현실적이고 불필요합니다. TLS가 이미 transit 중 credential을 보호하며, 시나리오에서 private connectivity가 없고 24시간 내 완료가 필요하다고 명시합니다. 시험 팁: “break-glass” account에서는 (1) phishing-resistant MFA, (2) privileged identity와 daily identity의 분리, (3) 최소 노출과 강력한 운영 control을 찾으세요. break-glass account 사용 능력을 없애거나 사용할 수 없는 network prerequisite를 요구하는 선택지는 고르지 마세요.

8
문제 8

Your fintech company stores regulated workloads on Compute Engine persistent disks, and the security team requires that a 256-bit AES key generated in your on-premises HSM (rotated every 90 days) be used directly to encrypt data at rest, with Google Cloud not storing the key and data becoming irrecoverable if the key is unavailable. What should you do?

오답. Cloud KMS로 DEK를 관리하는 것은 일반적으로 Google Cloud 스토리지 암호화가 구현되는 방식이 아닙니다. KMS 키는 DEK를 랩하는 KEK로 사용됩니다(envelope encryption). 더 중요한 점은 Cloud KMS가 Google-managed HSM 인프라에 키 머티리얼을 저장한다는 것이며, 이는 Google Cloud가 키를 저장하면 안 되고 온프레미스 HSM에서 생성된 키를 직접 사용해야 한다는 요구사항을 위반합니다.

오답. Cloud KMS가 KEK를 관리한다는 설명은 CMEK를 의미합니다. Google은 Cloud KMS에 KEK를 저장하고 이를 사용해 리소스별 DEK를 랩합니다. 이는 많은 컴플라이언스 요구를 충족할 수 있지만, 키가 온프레미스 HSM에서 생성되어야 하고 Google Cloud가 키를 저장하지 않아야 한다는 엄격한 요구사항은 충족하지 못합니다. CMEK에서는 접근 상실이 복호화를 막을 수는 있지만, 키 자체는 여전히 Google Cloud에 존재합니다.

정답. Customer-supplied encryption keys (CSEK)는 고객이 자체 raw AES-256 키 머티리얼(예: 온프레미스 HSM에서 생성)을 제공하여 persistent disk의 저장 데이터를 암호화할 수 있게 합니다. Google은 키를 저장하지 않으며, 사용 시점에 키가 제공되어 디스크의 DEK를 랩하는 데 사용됩니다. 키를 사용할 수 없거나 분실하면 디스크 데이터는 복구할 수 없으므로, 제시된 요구사항과 일치합니다.

오답. CSEK는 Cloud KMS 의미에서 KEK를 관리하는 데 사용되지 않습니다. 대신 고객이 제공한 키가 리소스의 DEK를 랩하는 데 사용됩니다. 여기서 “KEK”를 선택하는 것은 Google의 envelope encryption 용어를 오해한 것입니다. 올바른 관점은 CSEK가 디스크의 DEK에 적용된다는 것이지, 서비스 측에서 KEK를 관리한다는 것이 아닙니다.

문제 분석

핵심 개념: 이 문제는 Compute Engine persistent disk의 저장 데이터(data-at-rest)에 대한 암호화 키 통제를 테스트하며, 특히 Google-managed encryption, Cloud KMS/CMEK, Customer-Supplied Encryption Keys (CSEK) 간의 차이를 묻습니다. 또한 Google Cloud 스토리지 시스템에서 사용하는 DEK vs KEK 모델을 간접적으로 테스트합니다. 정답이 맞는 이유: 요구사항은 256-bit AES 키가 온프레미스 HSM에서 생성되고, 90일마다 로테이션되며, 저장 데이터 암호화에 직접 사용되어야 하고, Google Cloud가 키를 저장하면 안 되며, 키를 사용할 수 없으면 데이터가 복구 불가능해야 한다고 말합니다. 이는 CSEK 동작과 정확히 일치합니다. 즉, 각 API 요청(또는 이를 제공하는 툴링)을 통해 raw AES-256 키 머티리얼을 직접 제공하고, Google은 이를 사용해 리소스의 data encryption key (DEK)를 암호화(랩)하며 고객 키를 영구 저장하지 않습니다. 키를 분실하면 Google은 디스크를 복호화할 수 없으므로 데이터는 사실상 복구 불가능합니다. 주요 특징 / 동작 방식: Compute Engine persistent disk는 디스크별(per-disk) DEK로 암호화됩니다. CSEK를 사용하면 고객이 AES-256 키를 제공하고, Google은 이를 사용해 해당 DEK를 랩(암호화)합니다. 운영 측면에서 고객은 attach/read 작업마다 키를 안전하게 저장 및 전달해야 하며, 로테이션(예: 90일 주기로 새 키로 디스크를 재암호화/재랩)을 처리해야 합니다. 이는 컴플라이언스 기반의 “hold-your-own-key” 요구사항과 강력한 직무 분리(separation of duties)에 부합합니다. 흔한 오해: Cloud KMS (CMEK)는 “customer-managed keys”에 자주 선택되지만, KMS는 Google-managed HSM에 키 머티리얼을 저장합니다. 이는 “Google Cloud가 키를 저장하지 않아야 함” 및 “온프레미스 HSM에서 생성된 키를 직접 사용” 요구사항을 위반합니다. 또한 “KEK vs DEK” 표현이 혼동을 줄 수 있는데, Google의 envelope encryption에서 KMS 키는 DEK를 랩하는 KEK로 사용되며, CSEK는 고객이 제공한 키가 DEK를 랩하는 데 사용됩니다. 시험 팁: 문제에서 (1) 키가 Google 외부에서 생성되고, (2) Google이 이를 저장하면 안 되며, (3) 키를 잃으면 데이터가 복구 불가능해야 한다고 요구하면 CSEK를 떠올리세요. “고객이 로테이션/권한을 통제하지만 Google이 KMS에 키를 저장”이라고 하면 Cloud KMS/Cloud HSM 기반의 CMEK를 떠올리세요. 먼저 키 보관(custody) 모델에 요구사항을 매핑한 뒤 서비스를 선택하세요.

9
문제 9

Your company delegates project-level administration to each feature team by granting the Project Owner role on their own Google Cloud projects; the organization has approximately 2,300 projects across 90 VPC networks. Security Command Center Premium has surfaced 180 OPEN_REDIS_PORT (TCP/6379) findings where VMs with external IPs are reachable from the internet. You must enforce preventative guardrails that automatically apply to all current and future projects to stop these common exposure misconfigurations without relying on per-project maintenance. What should you do?

0.0.0.0/0에서의 org-level hierarchical firewall deny는 중앙집중식이며 예방적이지만, 범위가 지나치게 광범위합니다. 모든 워크로드에 대한 인터넷 ingress를 전부 차단하여, 합법적인 public-facing services(예: 443의 웹 앱)까지 막고 광범위한 장애를 유발할 수 있습니다. 이 문제는 모든 public ingress를 어디서나 제거하는 것이 아니라, open Redis 같은 일반적인 노출 오구성을 차단하는 것이 목표입니다.

이것이 최선의 가드레일입니다: 승인된 internal/on-prem CIDRs만 allowlist로 허용하고 나머지는 implicit deny에 의존하는 organization-level hierarchical firewall policy입니다. 2,300개 프로젝트 전반으로 확장 가능하며 향후 프로젝트에도 자동 적용되어 “프로젝트별 유지보수 없음” 요구사항을 충족합니다. 팀이 VPC firewall rules를 오구성하더라도 VM external IP(예: TCP/6379)로의 직접 인터넷 도달 가능성을 방지합니다.

Cloud Armor는 external HTTP(S) Load Balancers(및 일부 proxy-based LBs)에 연결되는 WAF/DDoS 정책입니다. VM external IP의 임의 TCP 포트(예: 6379의 direct Redis)는 보호하지 않습니다. finding이 인터넷에서 도달 가능한 VMs에 관한 것이므로, 올바른 control plane은 Cloud Armor가 아니라 VPC/hierarchical firewalling입니다.

모든 VPC network에 priority-0 deny rule을 추가하면 인터넷 ingress를 차단할 수는 있지만, 프로젝트별/네트워크별 유지보수를 피해야 한다는 요구사항을 위반합니다. 약 90개 VPCs와 2,300개 프로젝트(및 향후 성장) 환경에서는 운영적으로 취약하고 drift가 발생하기 쉽습니다. 중앙집중식 hierarchical firewall policies는 조직 전반에 일관된 baseline을 강제하도록 특별히 설계되었습니다.

문제 분석

핵심 개념: 이 문제는 VPC hierarchical firewall policies(방화벽을 위한 Google Cloud Organization Policy 유사 제어)를 사용해 대규모로 예방적 네트워크 가드레일을 적용하여, 여러 프로젝트/VPC 전반에 걸쳐 일관된 ingress 제어를 강제하는지를 평가합니다. 이는 Google Cloud Architecture Framework의 “defense in depth” 원칙과 중앙집중식 거버넌스에 부합합니다. 정답이 맞는 이유: 승인된 internal/on-prem 대역에서의 ingress만 허용하고(나머지는 implicit deny에 의존) organization-level hierarchical firewall policy를 적용하면, external IP가 있는 워크로드(예: TCP/6379의 Redis 포함)가 인터넷에서 도달 가능해지는 것을 방지할 수 있습니다. 이 정책은 org(또는 folder) 레벨에 적용되므로, 프로젝트별 규칙 유지보수 없이도 기존 및 향후의 모든 프로젝트와 VPC networks를 자동으로 포괄합니다. 이는 2,300개 프로젝트와 위임된 Project Owner 권한이 있는 상황에서 필수적입니다. 주요 기능 및 모범 사례: Hierarchical firewall policies는 VPC firewall rules에 추가로 평가되며, project owners가 쉽게 우회할 수 없는 baseline 제어를 강제하는 데 사용할 수 있습니다. “allowlist” 모델(신뢰 가능한 source CIDRs만 허용)은 강력한 경계 보호 패턴으로, 팀이 실수로 과도하게 허용적인 VPC firewall rules를 만들더라도 OPEN_REDIS_PORT 같은 일반적인 노출 오구성을 차단합니다. 정책 범위는 organization 또는 특정 folders로 한정할 수 있으며, 필요에 따라 on-prem 대역(Cloud VPN/Interconnect 경유)과 RFC1918 대역을 포함할 수 있습니다. 이 접근은 detective(사후 탐지)보다 preventative(노출 자체를 차단)입니다. 흔한 오해: 0.0.0.0/0에서의 blanket deny(option A)는 안전해 보이지만, 일반적으로 운영 측면에서 부정확합니다. 조직 전체에서 합법적인 public services(HTTPS, APIs, IAP/SSH 패턴 등)까지도 차단할 수 있기 때문입니다. Cloud Armor(option C)는 일반적인 VM ingress firewall이 아니라 HTTP(S) load-balanced 트래픽을 보호하며, VM external IP로의 직접 TCP/6379 트래픽은 보호하지 않습니다. VPC별 규칙(option D)은 프로젝트별 유지보수를 피해야 한다는 요구사항을 충족하지 못합니다. 시험 팁: “모든 현재 및 향후 프로젝트에 적용”과 “예방적 가드레일”을 보면 organization/folder-level controls를 떠올리세요: hierarchical firewall policies와 organization policies입니다. 인터넷 노출 findings의 경우, 프로젝트별 firewall rule 위생이나 load balancers만 커버하는 WAF 제품보다 중앙집중식 네트워크 경계 제어를 우선하세요.

10
문제 10

Your retail analytics platform runs on two Compute Engine instances behind a load balancer and authenticates to Google APIs using a user-managed service account key stored in Secret Manager (secret name: retail-sa-key), and your security policy mandates rotation every 90 days with no more than 2 minutes of reduced capacity. To follow Google-recommended practices when rotating this user-managed service account key, what should you do?

오답입니다. 설명된 것과 같은 사용자 관리형 service account key에 대한 표준적이고 Google 권장인 “enable-auto-rotate” 기능은 없습니다. Google 가이드는 가능하면 장기 수명의 key를 피하고, key가 필요하다면 통제된 프로세스(새 key 생성, 배포, 기존 key 삭제)로 교체하라는 것입니다. 존재하지 않거나 부정확한 명령에 의존하면 90일 정책이나 2분 용량 감소 요구사항을 충족할 수 없습니다.

오답입니다. service account key rotation은 일반적으로 “NEW_KEY”를 rotate 명령에 제공하는 방식으로 수행되지 않습니다. Google Cloud에서는 service account에 대해 새 key를 생성하고, 이를 안전하게 배포(여기서는 Secret Manager 사용)한 다음, 워크로드를 업데이트하고, 이후 기존 key를 삭제합니다. 단일 단계 “rotate” 명령은 오해를 유발하며 안전한 롤아웃, 검증, Secret Manager 버저닝을 다루지 못합니다.

정답입니다. 이는 권장되는 운영 패턴입니다: 새 service account key를 생성하고, Secret Manager의 새 버전으로 저장한 뒤, 변경을 롤아웃( load balancer 뒤의 두 인스턴스에 대해 롤링 재시작)하고, API 접근을 검증한 다음, IAM에서 기존 key를 삭제합니다. 이는 다운타임을 최소화하며(전환 동안 key를 겹치게 유지) 검증 후 기존 자격 증명을 신속히 폐기하여 위험을 줄입니다.

오답입니다. VM에 기존 key를 30일 동안 유지하면 노출이 증가하고 rotation의 목적을 훼손합니다. 또한 최소 권한과 자격 증명 위생 원칙과도 충돌합니다. 새 key가 정상 동작함이 확인되면 기존 key는 폐기되어야 합니다. 롤백이 필요하다면 Secret Manager 버저닝과 통제된 배포를 사용해야지, 디스크에 key 파일을 오래 남겨두는 방식(탈취에 취약하고 감사가 어려움)을 사용하면 안 됩니다.

문제 분석

핵심 개념: 이 문제는 워크로드에서 사용하는 사용자 관리형 service account key를 안전하게 교체(rotate)하는 방법과, 최소 다운타임으로 이를 수행하는 방법을 평가합니다. Google 권장 모범 사례에서는 장기 수명의 service account key는 위험하므로 가능하면 피해야 하며(Workload Identity/attached service accounts 선호), 반드시 key를 사용해야 한다면 유효 기간을 겹치게 두고 통제된 롤아웃으로 안전하게 교체해야 합니다. 정답이 맞는 이유: 옵션 C는 표준적이고 권장되는 rotation 패턴을 설명합니다. 새 key를 생성하고, 이를 Secret Manager의 새 버전으로 저장한 다음, 애플리케이션이 새 버전을 사용하도록 업데이트하고, API 호출이 성공하는지 검증한 뒤, service account에서 기존 key를 삭제합니다. 이 방식은 전환(cutover) 동안 두 key가 동시에 존재할 수 있어 거의 무중단에 가깝습니다. load balancer 뒤에 인스턴스 2대가 있으므로 롤링 재시작/갱신(한 번에 VM 1대씩)을 수행해 용량 감소를 2분 제약 내로 유지할 수 있습니다. 주요 기능 및 구성: Secret Manager는 버저닝을 지원하므로 기존 소비자를 깨뜨리지 않고 새 버전을 추가할 수 있습니다. 애플리케이션은 secret(이상적으로는 “latest”)을 참조하고 자격 증명을 리로드할 수 있어야 하며(또는 롤링 방식으로 재시작), 검증 후 IAM에서 기존 key를 삭제하면 즉시 무효화되어 노출을 줄일 수 있습니다. 이는 Google Cloud Architecture Framework의 보안 원칙(자격 증명 유출 위험 감소, 자격 증명 라이프사이클 관리 강제, 반복 가능한 runbook으로 보안 운영화)과 일치합니다. 흔한 오해: 일부는 service account key에 “auto-rotate” 명령이 있다고 가정하지만(암시된 방식으로는 사용자 관리형 key에 그런 기능이 없음), 또는 “rotate”가 단일 gcloud 명령이라고 생각합니다. 실제로 rotation은 프로세스입니다: 새 key 생성 → 배포 → 검증 → 기존 key 폐기. “만일을 대비해” 기존 key를 유지하면 침해 시 피해 범위(blast radius)가 커지고 rotation의 의도에 위배됩니다. 시험 팁: Security Engineer 시험에서 “user-managed service account key” + “Secret Manager” + “rotation”을 보면, 버전 관리 secret + 롤링 배포 + 기존 key 삭제 워크플로를 예상하세요. 또한 모범 사례 대안도 기억하세요: Compute Engine에서 attached service accounts(metadata server) 또는 외부 워크로드에는 Workload Identity Federation을 사용해 key 자체를 완전히 피하는 것입니다.

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

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

11
문제 11

Your logistics company runs a route-optimization model as a managed Vertex AI Batch Predictions job on Google Cloud. Twenty external carriers upload up to 1,000 CSV files per day (each <= 100 MB) to a dedicated Cloud Storage bucket via 15-minute signed URLs; a Cloud Function triggers the batch predictions and writes results to partner-specific buckets. You are conducting a configuration review with stakeholders and must clearly describe your security responsibilities for this managed AI workflow. What should you do?

오답. managed service는 운영 부담을 줄여주지만 보안 책임을 제거하지는 않습니다. rate limit과 budget alert는 비용/가용성 통제이지, partner 업로드와 managed batch inference에 대한 핵심 보안 태세가 아닙니다. 여전히 IAM, 데이터 액세스 경계, 모니터링을 관리해야 합니다. 이 선택지는 대부분의 보안이 전적으로 Google로 이전된다는 식으로 shared responsibility model을 잘못 설명합니다.

오답. CSV 정규화 코드를 보호하는 것은 중요합니다(input validation, 안전한 parsing). 하지만 이 문제는 managed workflow 전체(end-to-end)에 대한 보안 책임을 설명하라고 묻습니다. IAM 논의를 “개발 팀 내부”로만 제한하면 가장 큰 위험(외부 partner 액세스, Cloud Functions/Vertex AI/Cloud Storage 간 service account permission, auditability)을 무시하게 됩니다. configuration review로서는 범위가 너무 좁습니다.

정답. Google의 shared responsibility model을 정확히 적용합니다: Google은 관리형 Vertex AI 기반 인프라를 보호하고, 고객은 identity, permission, data access pattern을 보호합니다. service account와 partner에 대한 least-privilege IAM, short-lived signed URL과 TLS를 통한 안전한 업로드/다운로드, 제한적인 bucket policy, 오남용 또는 악성 활동을 탐지하기 위한 Cloud Audit Logs와 Cloud Logging 기반 운영 모니터링을 강조합니다.

오답. 일반적으로 self-managed VM에서처럼 Vertex AI의 managed service control plane “주변”에 custom network firewall이나 deep IDS/IPS를 배치할 수 없습니다. 더 적절한 통제는 IAM, organization policy, VPC Service Controls, private access pattern, logging/monitoring입니다. 또한 Google-managed runtime에 대한 vulnerability scanning은 대체로 Google 책임이지 고객 책임이 아닙니다.

문제 분석

핵심 개념 - 이 문제는 관리형 ML 워크플로(Vertex AI Batch Predictions)에서 Google Cloud의 shared responsibility model과 IAM, 데이터 액세스, 운영 모니터링 전반에서 고객 책임 vs. Google 책임을 어떻게 설명하는지 평가합니다. 정답인 이유 - Vertex AI Batch Predictions는 managed service이지만, 여전히 “in the cloud” 보안은 고객 책임입니다: 누가 데이터를 업로드할 수 있는지, 누가 job을 트리거할 수 있는지, 어떤 identity가 pipeline을 실행하는지, output이 어디에 기록되는지, 그리고 활동을 어떻게 모니터링하는지 등입니다. 선택지 C는 service account와 partner에 대한 IAM, 안전한 업로드/다운로드 패턴(short-lived signed URL, TLS), least-privilege bucket policy, 탐지 및 대응을 위한 logging/monitoring을 중심으로 리뷰를 올바르게 구성합니다. 이는 configuration review에서 이해관계자에게 필요한 내용(명확한 책임 경계와 구체적 통제)을 정확히 담고 있습니다. 주요 기능 - Cloud Functions와 Vertex AI에 대해 최소 권한의 전용 service account를 사용하세요(예: 특정 bucket에만 storage.objectViewer/objectCreator, 필요한 범위에서만 Vertex AI job 권한). uniform bucket-level access를 선호하고, public access를 비활성화하며, signed URL은 object name, method, content-type, 짧은 만료 시간으로 범위를 제한하세요. Cloud Storage와 Vertex AI 액세스는 TLS(기본값)로 수행되도록 하고, 데이터 유출 위험 감소를 위해 VPC Service Controls를 고려하세요. Cloud Audit Logs(Admin Activity, 필요 시 Data Access)를 활성화하고 검토하며, 비정상 업로드, job 트리거, cross-bucket write를 탐지하기 위해 Cloud Logging metric/alert를 구성하세요. 흔한 오해 - 많은 사람이 “PaaS면 Google이 보안을 처리한다”(A)고 가정하지만, 고객은 여전히 identity, permission, data governance를 관리합니다. 또 다른 사람들은 application code(B)에만 좁게 집중하면서 partner access와 service-to-service permission을 간과합니다. managed runtime(D) 주변에 custom firewall/IDS를 설계하는 것은 Google-managed control plane에 전통적인 network appliance를 삽입할 수 없다는 점을 오해한 것입니다. 대신 IAM, organization policy, VPC SC, logging을 사용합니다. 시험 팁 - managed service에서는 shared responsibility, least privilege IAM, 안전한 데이터 액세스 패턴(signed URL, bucket policy), audit logging을 언급하는 선택지가 대체로 정답입니다. serverless/managed service에 대해 network perimeter control을 과도하게 강조하거나 cost control을 “security responsibility”로 취급하는 선택지는 주의하세요.

12
문제 12

You are deploying an internal Cloud Run service that must read files from each employee's Google Drive and write a summary to BigQuery without any interactive user consent; the service must not rely on the currently signed-in user's credentials and must follow Google's recommended server-to-server approach. Your Google Workspace has 3,000 users, and the application should request only the https://www.googleapis.com/auth/drive.readonly scope and log which user was impersonated for each request; what should you do?

사용자에게 Service Account User role을 부여하면 해당 사용자들이 Google Cloud IAM 목적에서 service account를 가장하거나 actAs할 수 있습니다. 하지만 Drive API를 통해 Google Drive 사용자 데이터에 접근할 수 있게 해주지 않으며, Workspace OAuth 승인 필요성을 제거하지도 않습니다. 또한 많은 사용자에게 service account 가장 권한을 허용하므로 확장성이 떨어지고 위험이 증가합니다.

Google Group을 사용해 Service Account User를 부여하는 것은 옵션 A보다 IAM 편의성 측면에서 개선이지만, 여전히 잘못된 제어 영역(control plane)을 다룹니다. IAM actAs 권한은 직원 파일에 대한 Workspace Drive 액세스를 부여하지 않습니다. 요구사항은 대화형 동의 없이 Workspace 사용자 데이터에 대한 서버-투-서버 액세스이며, 이를 위해서는 domain-wide delegation과 승인된 OAuth scopes가 필요합니다.

super admin account로 인증하는 것은 명시적으로 권장되지 않습니다. 최소 권한을 위반하고, Drive read-only보다 훨씬 더 많은 것에 접근할 수 있는 고위험 자격 증명을 만들며, 안전하게 관리하기 어렵습니다(교체, 저장, 감사). 또한 대규모로 Workspace 사용자 데이터에 접근하기 위한 Google의 권장 서버-투-서버 접근 방식도 따르지 않습니다.

이것이 올바른 패턴입니다. service account를 Google Workspace domain-wide delegation으로 구성하고, Admin console에서 drive.readonly scope만 승인한 뒤, Drive API 호출 시 각 대상 사용자를 가장하도록(subject 설정) 합니다. 이렇게 하면 대화형 동의를 피할 수 있고, 로그인한 사용자에 의존하지 않으며, 가장한 사용자를 로깅하여 감사가 가능하고, scope가 지정된 관리자 승인으로 최소 권한을 강제합니다.

문제 분석

핵심 개념: 이 문제는 권장되는 서버-투-서버 패턴을 사용하여 Google Cloud의 서버 워크로드에서 사용자 데이터에 대한 Google Workspace 액세스를 테스트합니다. 즉, Google Workspace Domain-Wide Delegation (DWD)이 설정된 service account로 사용자를 가장(impersonate)하여 대화형 동의 없이 Google APIs(Drive)를 호출하는 방식입니다. 정답이 맞는 이유: 내부 Cloud Run 서비스는 각 직원의 Drive 파일을 읽어야 하며, 현재 로그인한 사용자의 자격 증명을 사용하면 안 됩니다. Workspace 사용자 데이터의 경우 올바른 접근 방식은 domain-wide delegation으로 구성된 service account를 사용한 다음, OAuth token을 발급(mint)할 때 대상 사용자를 가장(“sub”/“subject”)하는 것입니다. Workspace 관리자는 Admin console에서 정확한 OAuth scope(여기서는 drive.readonly)를 명시적으로 승인하여 최소 권한을 충족합니다. 애플리케이션은 자격 증명을 생성할 때 subject를 사용자 이메일로 설정하므로, 요청별로 어떤 사용자를 가장했는지 로깅할 수 있습니다. 주요 기능 / 구성: 1) Cloud Run에서 사용하는 service account를 생성합니다(런타임 service account로 사용). 2) 해당 service account에서 Domain-Wide Delegation을 활성화하고 OAuth client ID를 확보합니다. 3) Google Admin console에서: Security > API controls > Domain-wide delegation으로 이동하여 client ID를 추가하고 https://www.googleapis.com/auth/drive.readonly만 승인합니다. 4) 코드에서: “subject”(사용자 이메일)가 포함된 service account credentials를 사용하여 Drive API 호출 시 각 직원을 가장하고, 요약은 Cloud Run service account의 IAM 권한을 사용해 BigQuery에 작성합니다(Workspace scopes와는 별개). 이는 Google이 권장하는 서버-투-서버 모델에 부합하며, 사용자별 동의 플로우 없이 3,000명의 사용자를 지원합니다. 흔한 오해: Service Account User 같은 IAM role(옵션 A/B)은 누가 Google Cloud service account를 가장할 수 있는지를 제어할 뿐, Google Workspace 사용자 Drive 데이터에 접근하는 방법을 제공하지 않습니다. 또한 사용자 파일에 대한 Drive API 액세스를 부여하지도 않습니다. super admin account(옵션 C)를 사용하는 것은 비보안적이고 감사(audit)가 어렵고 최소 권한을 위반합니다. 또한 운영 리스크와 부실한 키 관리 문제를 초래합니다. 시험 팁: 여러 사용자에 대해 대화형 동의 없이 Workspace 데이터(Gmail/Drive/Calendar)에 접근해야 한다면 “Domain-wide delegation” + “impersonate user” + “Admin console에서 scopes 승인”을 찾으세요. Google Cloud IAM(리소스 액세스)과 Google Workspace OAuth scopes(사용자 데이터 액세스)를 구분하세요. 항상 최소 권한 scope와 감사 가능성을 위한 요청별 subject 로깅을 우선하세요.

13
문제 13

Your marketing analytics unit (120 users) plans to adopt Google Cloud for BigQuery and Vertex AI within 30 days, and company policy requires that all identities remain company-owned and all sign-ins use the corporate SAML 2.0 IdP; while attempting to create a new Cloud Identity tenant for example.com, the Platform Engineer discovers that example.com is already verified and actively used by an internal Google Workspace deployment with 850 active accounts and existing SAML SSO, and needs guidance on how to proceed with the least disruption and without violating the policy. What should you advise?

Domain contestation은 도메인 소유권이 분쟁 중이거나, 승인되지 않은 당사자가 테넌트에서 도메인을 제어하는 상황을 위해 설계되었습니다. 여기서는 도메인이 850개 계정과 SAML SSO로 내부에서 이미 사용 중이므로, contestation은 매우 큰 중단을 유발하며 불필요합니다. 계정 충돌, 서비스 중단, 복잡한 마이그레이션 위험이 있습니다. “최소한의 중단” 요구사항에 부합하지 않으며 내부 분리를 위한 올바른 도구가 아닙니다.

새 도메인(analytics-example.com)을 사용하면 기술적으로는 별도의 Cloud Identity 테넌트를 구성할 수 있지만, 기본 기업 도메인 하에서 “모든 ID는 회사 소유로 유지”한다는 취지에 어긋나며 ID 분절을 초래합니다. 사용자는 대체 사용자명 또는 alias가 필요해져 라이프사이클 관리, 그룹 멤버십, 액세스 거버넌스가 복잡해집니다. 또한 운영 오버헤드를 증가시키고 테넌트 간 SSO 및 정책 적용의 불일치를 초래할 수 있습니다.

마케팅 프로그램 매니저에게 Super Admin을 부여하는 것은 과도하며 최소 권한을 위반합니다. Super Admin은 ID, 보안 설정, 도메인 전역 구성에 대한 광범위한 제어 권한을 가지므로 상당한 위험을 초래합니다. 요구사항은 최소한의 중단으로 유닛을 온보딩하고 정책을 유지하는 것이지, 최상위 테넌트 제어를 위임하는 것이 아닙니다. 적절한 온보딩은 기존 관리자가 범위가 제한된 admin roles와 group/OU 기반 제어로 수행해야 합니다.

이는 가장 중단이 적고 정책 정합성이 가장 높은 접근입니다. 도메인이 이미 검증되어 있고 SAML SSO로 활발히 사용 중이므로, 올바른 조치는 기존 Super Administrator와 조율하여 마케팅 유닛을 현재 테넌트에 온보딩하는 것입니다. OUs와 groups를 사용해 사용자를 분리하고, SAML 로그인을 강제하며, 적절한 정책을 적용합니다. 그런 다음 올바른 Google Cloud 프로젝트에서 그룹 기반 IAM을 통해 BigQuery/Vertex AI 액세스를 부여합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서의 ID 아키텍처를 평가합니다: Cloud Identity/Google Workspace 테넌시, 도메인 검증 소유권, 그리고 권위 있는 로그인 방식으로서의 연동 SSO (SAML 2.0)입니다. 또한 Google Cloud Architecture Framework의 보안 기반(중앙화된 ID, 일관된 정책, 최소 권한)에 맞춘 조직 거버넌스(최소한의 중단, 중앙화된 정책 적용)도 다룹니다. 정답이 맞는 이유: example.com이 기존 Google Workspace 테넌트에서 이미 검증되어 있고 SAML SSO로 활발히 사용 중이므로, 회사는 해당 도메인에 대한 권위 있는 ID 경계를 이미 보유하고 있습니다. 검증된 도메인은 큰 중단 없이 별도의 Cloud Identity 테넌트에서 깔끔하게 “재생성”할 수 없습니다. 가장 중단이 적고 정책을 준수하는 경로는 기존 Super Administrator와 협업하여 마케팅 분석 유닛을 현재 테넌트에 온보딩하는 것입니다. 이렇게 하면 회사 소유 ID(동일한 기업 도메인)를 유지하고, 로그인에 기업 SAML 2.0 IdP를 계속 사용하며, 기존 사용자/그룹/앱 통합이 깨지는 것을 방지할 수 있습니다. 이후 해당 유닛은 Cloud Identity/Workspace ID, 그룹, 그리고 (이상적으로는) Google Cloud IAM에 매핑된 Cloud Identity Groups를 통해 BigQuery 및 Vertex AI에 액세스할 수 있습니다. 주요 기능 / 구성: Organizational Units (OUs)와 Groups를 사용해 마케팅 유닛을 분리하고, context-aware access 및 보안 정책을 적용하며, 앱 액세스를 관리합니다. SAML SSO가 계속 강제되도록 보장하고, Google Cloud 프로젝트에서 BigQuery/Vertex AI에 대해 그룹 기반 IAM 바인딩을 사용합니다. 필요하다면 별도의 ID 테넌트가 아니라, 별도의 Google Cloud organizations/projects와 그룹을 통한 중앙화된 IAM을 사용합니다. 흔한 오해: 유닛을 위해 새 테넌트를 만드는 것이 더 간단해 보일 수 있지만, 도메인 검증과 ID 라이프사이클이 분절되고 SSO 정책 일관성을 유지하기가 더 어려워집니다. Domain contestation은 일반적인 “이동” 메커니즘이 아니며, 내부 재아키텍처가 아니라 소유권 분쟁을 위한 것입니다. 시험 팁: 도메인이 이미 Workspace/Cloud Identity에서 검증되어 있다면, 해당 테넌트가 권위 있는 테넌트라고 가정하세요. 병렬 ID 테넌트를 만드는 것보다 OUs/groups 및 Google Cloud 리소스 계층(org/folders/projects)을 통해 온보딩하는 것을 선호하세요. 중앙화된 ID를 보존하고, 중단을 최소화하며, federation 요구사항을 유지하는 선택지를 찾으세요.

14
문제 14

Your compliance team is launching an internal meeting-notes summarization pipeline on Google Cloud that uses a generative model to create summaries from audio transcripts, it must process up to 3,000 transcripts per day (average 1 MB each) with under 200 ms filtering latency per request, and company policy mandates that no personally identifiable information (PII)—such as names, email addresses, phone numbers, or government IDs—may appear in either the prompts sent to the model or the summaries returned, so you need a managed, scalable control that detects and automatically redacts PII on both ingress and egress before any storage or display; what should you do?

Cloud KMS는 저장 데이터 암호화와 encryption key에 대한 액세스 제어를 통해 데이터를 보호하며, 이는 기밀성과 key 관리 측면에서 유용합니다. 그러나 암호화는 transcript나 summary의 내용을 검사하지 않으며, 모델로 전송되거나 사용자에게 표시되기 전에 민감한 값을 제거하지도 않습니다. 애플리케이션이 처리를 위해 데이터를 복호화하면, 별도의 검사 및 redaction 단계가 적용되지 않는 한 PII는 여전히 존재합니다. 따라서 KMS는 보완적인 제어 수단으로는 유용하지만, 문제의 핵심 요구 사항을 충족하지는 않습니다.

Cloud DLP는 텍스트 및 기타 콘텐츠에서 민감한 데이터를 발견하고 비식별화하기 위한 Google Cloud의 네이티브 관리형 서비스입니다. 이 파이프라인에서는 transcript 텍스트가 prompt로 변환되기 전에 이를 검사하고, 생성된 summary가 저장되거나 표시되기 전에 해당 출력도 검사하여 유입과 유출 양쪽에서 민감한 값이 제거되도록 할 수 있습니다. 이는 masking, redaction, replacement, tokenization과 같은 비식별화 기법을 지원하며, PII가 prompt나 반환된 summary에 나타나지 않도록 해야 한다는 요구 사항과 직접적으로 부합합니다. 따라서 generative AI 워크플로에서 규정 준수 중심의 콘텐츠 필터링을 위한 가장 적절한 관리형이며 확장 가능한 제어 수단입니다.

VPC Service Controls는 지원되는 서비스를 service perimeter 내부에 배치하고 액세스 경로를 제한함으로써 데이터 exfiltration 위험을 줄이는 데 도움을 줍니다. 이 제어는 데이터가 어디로 이동할 수 있는지를 관리하지만, request 또는 response payload에 PII가 포함되어 있는지를 판단하기 위해 이를 분석하지는 않습니다. 민감한 데이터가 perimeter 내부에서 그대로 모델에 전달되고 summary로 반환될 수 있으며, 이는 여전히 명시된 정책을 위반하게 됩니다. 따라서 VPC-SC는 defense in depth일 뿐, 콘텐츠 redaction을 위한 주된 솔루션은 아닙니다.

서드파티 Marketplace 제품이 scanning 또는 redaction 기능을 제공할 수는 있지만, 문제에서는 가장 적절한 관리형이며 확장 가능한 Google Cloud 제어 수단을 묻고 있습니다. 외부 제품을 도입하면 조달, 통합, 운영, 규정 준수 검토 측면의 오버헤드가 추가되며, Google Cloud certification 시나리오에서 표준적인 네이티브 정답도 아닙니다. 또한 이 선택지는 encryption을 강조하지만, 그것만으로는 사용 전에 prompt와 summary에서 PII가 제거된다는 것을 본질적으로 보장하지 않습니다. Cloud DLP는 민감한 데이터 검사와 비식별화를 위해 특별히 설계되었으므로 더 적합합니다.

문제 분석

핵심 개념: 이 문제는 규정 준수를 위한 관리형 데이터 보호 제어를 테스트합니다. 구체적으로는 생성형 AI 요약 파이프라인으로 유입(ingress) 및 유출(egress)되는 콘텐츠에서 PII를 탐지하고 비식별화하는 것입니다. Google Cloud에서 PII 발견 및 마스킹/삭제(redaction)를 위한 주요 관리형 서비스는 Cloud Data Loss Prevention (Cloud DLP)입니다. 정답인 이유: 옵션 B가 정답인 이유는 Cloud DLP가 텍스트에서 민감한 데이터 유형(이름, 이메일, 전화번호, 정부 발급 ID 등)을 검사할 수 있고, 탐지된 결과를 자동으로 비식별화(마스킹, redaction, 대체, 토큰화, 또는 format-preserve)할 수 있기 때문입니다. 요구사항은 PII가 모델로 전송되는 프롬프트(ingress)에도, 반환되는 요약(egress)에도 나타나면 안 되며, 제어는 관리형이고 확장 가능해야 하고 저장 또는 표시 전에 적용되어야 한다고 명시합니다. Cloud DLP는 애플리케이션 워크플로의 일부로 프로그래밍 방식의 검사 + 비식별화를 수행하도록 정확히 설계되었습니다. 주요 기능 / 구현 방법: - 모델 호출(프롬프트 구성) 전에 요청 경로에서 Cloud DLP inspect + de-identify APIs를 사용하고, 모델 출력에 대해서도 저장 또는 렌더링 전에 다시 적용합니다. - 오탐(false positive)을 줄이기 위해 infoTypes(기본 제공 및 커스텀), likelihood 임계값, 제외 규칙을 구성합니다. - 변환 방식 선택: 엄격한 제거가 필요하면 마스킹/redaction, 일관된 대체가 필요하면 토큰화/암호 기반 가명처리(pseudonymization)를 사용합니다. - 성능을 위해 가능하면 처리를 리전 내에 유지하고 수평 확장을 고려해 설계합니다(예: Cloud Run/GKE에서 DLP 호출). 제시된 처리량(하루 3,000 x 1 MB)은 크지 않으며, 핵심은 추가 홉을 최소화하고 검사 범위를 튜닝하여 요청당 지연 시간 목표를 충족하는 것입니다. 흔한 오해: 암호화(A)는 저장 시 기밀성을 보호하지만 프롬프트나 요약에서 PII를 제거하지는 않습니다. VPC Service Controls(C)는 데이터 유출 위험을 줄이지만 허용된 흐름 내에서 PII를 탐지/삭제할 수는 없습니다. 서드파티 도구(D)는 가능할 수 있으나 가장 적절한 네이티브 관리형 제어가 아니며 공급망/컴플라이언스 복잡성을 추가합니다. 시험 팁: 요구사항이 “PII를 탐지하고 redaction”하는 것(특히 컴플라이언스 목적)이라면 먼저 Cloud DLP를 떠올리세요. 방어 심층화(defense-in-depth)로 IAM 최소 권한, 로깅, 경계 제어를 함께 적용하되, ingress/egress에서 “콘텐츠에 PII가 없어야 함”을 실제로 강제하는 제어는 DLP입니다. 이러한 요구사항을 Google Cloud Architecture Framework의 보안 및 컴플라이언스 원칙(데이터 분류, 예방 제어, 자동화된 정책 집행)에 매핑하세요.

15
문제 15

Your company exposes a payment reconciliation API running on Compute Engine VMs behind a regional Internal HTTP(S) Load Balancer in VPC prod-finance (10.20.0.0/16), reachable only from your on-premises network over two HA VPN tunnels (TCP 443); to meet a security mandate, all inbound TLS traffic from on-prem must be intercepted (decrypted, inspected for malware/C2), then re-encrypted before it reaches the backends, and the policy must be centrally enforced for all projects in the Apps-Prod folder without changing the application architecture. What should you do?

Secure Web Proxy는 URL filtering과 위협 방지를 통해 클라이언트에서 인터넷/SaaS로 나가는 아웃바운드(egress) 웹 트래픽을 제어하고 검사하기 위한 관리형 forward proxy로 주로 설계되었습니다. HA VPN을 통해 on-prem에서 내부 load balancer로 들어오는 인바운드 TLS 트래픽에 대한 올바른 구성요소가 아닙니다. 또한 hierarchical firewall policies처럼 “폴더 내 모든 프로젝트에 중앙에서 강제” 요구사항을 동일한 방식으로 충족하지도 못합니다.

internal proxy load balancer는 TLS를 종료할 수 있지만, load balancer는 복호화된 페이로드에 대한 멀웨어/C2 검사 엔진으로 포지셔닝되어 있지 않습니다. ILB에서 TLS를 종료하면 암호화가 끝나는 지점이 바뀌지만, 요구된 보안 검사 기능이 본질적으로 제공되지는 않습니다. 또한 여러 프로젝트에 걸친 중앙집중식 폴더 수준 적용을 제공하지 않으며, 서비스/load balancer별로 구성해야 합니다.

Hierarchical Firewall Policies는 폴더(Apps-Prod) 수준에서 중앙집중식으로 상속되는 적용을 제공하며, 이는 프로젝트 전반에 일관된 정책이 필요하다는 요구사항과 직접적으로 일치합니다. Cloud NGFW Enterprise는 TLS inspection(복호화/검사/재암호화)을 포함한 고급 검사 기능을 트래픽에 추가하여, 애플리케이션 변경 없이 인라인으로 멀웨어/C2 탐지를 가능하게 합니다. 이 조합이 기술적 의무와 거버넌스/중앙 적용 요구사항을 모두 가장 잘 충족합니다.

VPC firewall rules는 특정 VPC network/project 범위로 제한되며, 폴더 내 모든 프로젝트에 중앙에서 강제되지 않습니다. 모든 곳에 복제해야 한다면 “중앙에서 강제” 의무를 위반하고 드리프트 위험을 증가시킵니다. 또한 표준 VPC firewall rules는 TLS 복호화/검사를 제공하지 않으며, L3/L4 allow/deny 제어입니다. NGFW 기능이 있더라도, 거버넌스 요구사항은 VPC별 규칙이 아니라 hierarchical firewall policies를 가리킵니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 east-west/north-south 트래픽에 대한 네트워크 보안 제어, 특히 중앙집중식 정책 적용과 인라인 TLS inspection을 테스트합니다. 관련 서비스는 TLS inspection을 포함한 Cloud NGFW Enterprise(Network Security의 일부)와 조직/폴더 수준 적용을 위한 Hierarchical Firewall Policies(HFP)입니다. 정답이 맞는 이유: 요구사항은 애플리케이션 아키텍처를 변경하지 않고, HA VPN을 통해 on-prem에서 내부 HTTP(S) load balancer로 들어오는 인바운드 TLS 트래픽을 가로채(복호화), 검사(멀웨어/C2), 그리고 재암호화하는 것입니다. 또한 Apps-Prod 폴더의 모든 프로젝트에 대해 정책을 중앙에서 적용해야 합니다. Cloud NGFW Enterprise는 고급 위협 방지와 TLS inspection 기능을 제공하고, Hierarchical Firewall Policies는 폴더 수준(Apps-Prod)에서 이러한 제어를 적용하고 중앙에서 관리할 수 있게 해 여러 프로젝트/VPC 전반에 일관된 적용을 보장합니다. 이는 중앙집중식 거버넌스와 일관된 가드레일이라는 Google Cloud Architecture Framework 보안 원칙과도 부합합니다. 주요 기능 / 구성 포인트: - Apps-Prod 폴더에 연결된 Hierarchical Firewall Policy를 사용해 검사 요구사항을 일관되게 강제합니다. - Cloud NGFW Enterprise TLS inspection을 활성화하여 트래픽을 인라인으로 복호화/검사/재암호화할 수 있게 합니다. - 이 접근은 애플리케이션과 load balancer에 투명하며(앱 변경 없음), 프로젝트 전반으로 확장 가능합니다. - 중앙 관리로 구성 드리프트를 줄이고 컴플라이언스/감사 요구를 지원합니다. 흔한 오해: A와 B는 “load balancer/proxy에서 검사”를 제안합니다. Internal HTTP(S) Load Balancing은 TLS를 종료(terminate)할 수 있지만, 멀웨어/C2 검사 엔진은 아니며, “Secure Web Proxy”는 주로 인바운드가 아니라 egress 웹 액세스 제어(forward proxy)를 위한 것입니다(VPN 소스의 인바운드 내부 서비스 보호 용도가 아님). D는 VPC firewall rule을 사용하지만, VPC firewall rule은 HFP처럼 프로젝트 전반에 중앙에서 강제되지 않으며, 자체적으로 TLS 복호화/검사 기능을 제공하지도 않습니다. 시험 팁: - 문제가 “프로젝트/폴더 전반에 중앙에서 강제”를 강조하면, VPC별 규칙이 아니라 Hierarchical Firewall Policies(또는 org policies)를 떠올리세요. - decrypt/inspect/re-encrypt가 필요하면, load balancer 기능이 아니라 Cloud NGFW Enterprise TLS inspection을 찾으세요. - 인바운드 서비스 보호와 아웃바운드 웹 프록시를 구분하세요: Secure Web Proxy는 일반적으로 egress 제어용이지, 인바운드 API inspection용이 아닙니다.

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

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

16
문제 16

Your media-streaming company plans to migrate 120 microservices to Google Cloud within 90 days across 5 VPC networks spanning us-central1 and europe-west2; you must decide where to apply security controls and policies and determine which responsibilities are handled by Google versus your team, considering that you store 12 TB of GDPR-regulated PII for 200,000 EU customers and must retain audit logs for 365 days. What should you do?

Security Foundations/랜딩 존 Blueprint는 유용한 출발점(조직 구조, IAM 패턴, 로깅, 네트워킹)이지만, 시험 관점에서 이를 “그대로(verbatim)” 구현하는 것이 정답인 경우는 드뭅니다. 특정 VPC 토폴로지, 리전, GDPR 통제, 로그 보존 요구사항에 맞춘 커스터마이징이 필요합니다. 또한 Blueprint 자체만으로 보안 태세를 “지속적으로 유지”하지는 못하며, 통제가 효과적으로 유지되려면 거버넌스, 모니터링, 지속적인 운영이 필요합니다.

Risk Manager/사이버 보험(및 유사한 리스크 전가 메커니즘)은 전체 리스크 전략의 일부가 될 수 있지만, 핵심 요구사항(통제를 어디에 적용할지 결정하고 Google vs 사용자 팀의 책임을 명확히 하는 것)에 대한 답이 아닙니다. 태세 보고서는 참고가 될 수 있으나, 통제 소유권 매핑, GDPR 책임성, 감사 로그 보존 설계의 기반 단계는 아닙니다.

Release notes를 추적하고 API를 활성화하기 전에 신규 서비스를 평가하는 것은 좋은 변경 관리 관행이지만, 보안 통제 프레임워크를 수립하거나 공유 책임을 명확히 하지는 못합니다. 이 문제는 규제 데이터와 감사 요구사항에 대해 통제 배치와 책임 경계를 다룹니다. Release notes는 사용자가 어떤 계층(IAM, 키, 로깅, 세그멘테이션)을 보안해야 하는지와 Google이 무엇을 보안하는지를 알려주지 않습니다.

이는 문제의 핵심 요구를 직접 충족합니다. 공유 책임 모델을 사용해 보안/컴플라이언스 통제를 사용자 의무에 매핑하고, Google이 관리하는 영역을 식별합니다. GDPR PII 및 멀티 리전 배포에서는 이 매핑이 데이터 상주, 암호화/키 소유권, IAM 및 네트워크 경계 통제, 감사 로그 보존 아키텍처(예: 365일을 위해 스토리지/BigQuery로 싱크) 같은 의사결정을 이끕니다. 구체적인 기술 통제를 구현하기 전에 필요한 올바른 기반 단계입니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud 공유 책임 모델과 이를 규제 대상 마이그레이션(GDPR PII, 멀티 리전, 여러 VPC)에서 감사 로깅 보존을 포함한 컴플라이언스/보안 통제 매핑으로 어떻게 변환하는지를 평가합니다. 이는 Google Cloud Architecture Framework(보안, 거버넌스, 운영 기둥) 및 컴플라이언스 계획과 강하게 연관됩니다. 정답이 맞는 이유: 옵션 D만이 “보안 통제와 정책을 어디에 적용할지 결정하고, 어떤 책임이 Google과 팀 중 누구에게 있는지 판단”해야 한다는 요구사항을 직접적으로 다룹니다. Google Cloud에서 Google은 클라우드 “자체(of)”의 보안(물리 시설, 하드웨어, 코어 네트워킹, 관리형 서비스 인프라)을 책임지고, 사용자는 클라우드 “내(in)”의 보안(IAM, 데이터 분류, 암호화 선택, 네트워크 세그멘테이션, 로깅 구성, 키 관리, 워크로드 하드닝, 컴플라이언스 증적)을 책임집니다. EU 고객의 GDPR 규제 PII의 경우, 통제를 데이터 상주/처리 요구사항(예: europe-west2)에 매핑하고, 누가 액세스/암호화/DLP/로깅을 구성하는지 정의하며, 감사 로그가 365일 보존되도록 보장해야 합니다(일반적으로 Cloud Logging 싱크를 BigQuery/Cloud Storage로 내보내고 보존/잠금 설정). 매핑 이후 구현할 핵심 기능 / 구현 사항: 일반적으로 Organization Policy 제약조건, IAM 최소 권한, 데이터 유출 경계를 위한 VPC Service Controls, 필요 시 Cloud KMS/CMEK, Cloud Audit Logs(적절한 경우 Admin Activity/Data Access), 365일 보존을 충족하기 위한 로그 싱크, 모니터링/알림을 사용합니다. 또한 스토리지/처리의 리전 적합성을 검증하고, 감사인을 위한 통제를 문서화합니다. 흔한 오해: Blueprint(A)는 랜딩 존을 빠르게 구축하는 데 도움이 되지만 보안 태세를 자동으로 “지속적으로 유지”해주지는 않으며, 규제 및 아키텍처 요구사항에 맞게 조정되어야 합니다. Release notes(C)는 운영 위생에 가깝지 책임 모델이 아닙니다. 리스크/보험(B)은 통제 소유권이나 컴플라이언스를 수립하지 못합니다. 시험 팁: 문제가 명시적으로 “Google의 책임 vs 사용자의 책임”을 묻는다면 공유 책임 모델이 기준점입니다. 그다음 이를 구체적인 통제 영역(IAM, 네트워크 경계, 암호화/키, 로깅/보존, 데이터 상주)과 연결하세요. 장기 감사 로그 보존의 경우 기본 Logging 보존 기간은 제한적이므로, 싱크와 보존/불변성(immutability) 통제를 계획해야 합니다.

17
문제 17

Your organization runs a self-hosted CI/CD system on a Google Kubernetes Engine (GKE) Autopilot cluster in a dedicated build project. The cluster executes more than 300 pipeline jobs per day, using ephemeral build pods that terminate within 60 minutes, and the pipelines deploy resources across multiple Google Cloud projects in the same folder. Security policy requires no long-lived user credentials, enforcing least privilege, and minimizing the risk of credential exfiltration from build nodes; you can enforce Organization Policy constraints at the project level. What should you do to minimize the risk of the CI/CD system's credentials being stolen?

오답입니다. 비밀번호를 회전시키고 OAuth refresh tokens를 저장하더라도 Cloud Identity user는 여전히 장기 수명의 user credentials와 secret에 의존하며, 이는 CI/CD 환경이나 vault에서 유출될 수 있습니다. 특히 refresh tokens는 새 access tokens로 교환될 수 있기 때문에 매우 민감합니다. 이는 장기 수명의 user credentials를 피하라는 요구사항을 위반하며, 자동화 시스템에 권장되는 워크로드 identity model이 아닙니다.

오답입니다. 자동화에 Cloud Identity user account를 사용하는 것은 user credentials와 일반적으로 장기 수명의 refresh tokens를 도입하므로 CI/CD best practice에 어긋납니다. 또한 service account creation을 비활성화하는 것은 빌드 pod에서의 자격 증명 탈취 위험을 직접적으로 줄이지 못하며, 워크로드에 대한 권장 접근(전용 service accounts 및 Workload Identity) 채택을 방해할 수도 있습니다.

정답입니다. 최소한의 필요한 roles만 가진 전용 service account는 least privilege를 지원하고 사람(user) 자격 증명을 피합니다. constraints/iam.disableServiceAccountKeyCreation을 강제하면 장기 수명이며 쉽게 유출될 수 있는 user-managed service account keys 생성이 방지됩니다. GKE Workload Identity와 결합하면, 빌드 pod는 node에 secret을 저장하지 않고 Google이 발급한 짧은 수명의 token을 사용할 수 있어 자격 증명 탈취 영향이 최소화됩니다.

오답입니다. constraints/iam.allowServiceAccountCredentialLifetimeExtension은 더 장기 수명의 자격 증명을 가능하게 하며, 자격 증명이 탈취되었을 때 오용될 수 있는 시간 창을 늘립니다. 시나리오는 exfiltration risk를 최소화하고 장기 수명의 자격 증명을 피하길 명시합니다. 보안 best practice는 자격 증명을 짧은 수명으로 유지하고 non-exportable하게 만드는 것이지, 수명을 연장하는 것이 아닙니다.

문제 분석

핵심 개념: 이 문제는 GKE (Autopilot)에서 실행되는 CI/CD에 대한 안전한 워크로드 인증과, Google Cloud가 권장하는 identity model(서비스 계정을 통한 짧은 수명의 자동 회전 자격 증명, 이상적으로는 Workload Identity 사용)을 활용하여 자격 증명 탈취 위험을 줄이는 방법을 테스트합니다. 또한 service account keys 같은 장기 수명이며 외부로 유출(exfiltrate) 가능한 secret을 방지하는 것이 핵심입니다. 정답이 맞는 이유: 옵션 C는 대상 프로젝트 전반에 필요한 IAM roles만 부여한 빌드 워크로드 전용 service account를 사용함으로써 least privilege와 “no long-lived user credentials” 요구사항에 부합합니다(적절한 범위, 예: project/folder에서 IAM bindings로 부여). CI/CD에서의 핵심 위험은 빌드 pod/node에서의 자격 증명 유출이며, 사용자가 관리하는 service account keys는 장기 수명이고 쉽게 탈취될 수 있습니다. project 수준에서 Organization Policy constraint인 constraints/iam.disableServiceAccountKeyCreation을 강제하면 새로운 user-managed private key 생성이 차단되어, 내보낼 수 있는 key file 대신(즉, export 가능한 키 파일이 아니라) Google이 발급(mint)하는 짧은 수명의 자격 증명(OAuth access tokens) 사용으로 유도됩니다. 이는 Google Cloud Architecture Framework의 “Security, privacy, and compliance”에서 제시하는 핵심 best practice로, managed identities를 선호하고 static secrets를 제거하라는 원칙과 일치합니다. 주요 기능 / 구성: - CI/CD 전용 custom service account를 사용하고, 필요한 roles만 부여합니다(대개 predefined roles, 필요 시 custom roles). - GKE Workload Identity(Autopilot에서 지원)를 사용하여 Kubernetes service accounts를 Google service accounts에 매핑함으로써, pod가 키를 저장하지 않고 짧은 수명의 token을 획득하도록 합니다. - constraints/iam.disableServiceAccountKeyCreation을 적용해 새 key 생성을 차단하고, 선택적으로 기존 keys를 감사(audit)하여 제거합니다. 흔한 오해: - Cloud Identity user(A/B)를 사용하는 방식은 단순해 보이지만, 장기 수명의 자격 증명(passwords/refresh tokens)을 도입하여 “no long-lived user credentials” 요구사항을 위반합니다. - 더 긴 자격 증명 수명(D)을 허용하면 blast radius와 탈취 시 영향이 커지며, exfiltration risk를 최소화하는 것과 정반대입니다. 시험 팁: GKE에서의 CI/CD에 대한 선호 패턴은: 전용 service account + least privilege + Workload Identity + org policy로 service account keys 차단입니다. “minimize credential exfiltration”을 보면, 짧은 수명이며 내보낼 수 없는(non-exportable) 자격 증명과 key material이 생성/저장되지 못하게 하는 constraints를 선택하세요.

18
문제 18

Your organization uses a Shared VPC where net-hub-prod is the host project, and all firewall rules, subnets, and an HA VPN with Cloud Router are configured in the host; you need to let the Data Science Blue group attach Compute Engine VMs in service project ml-svc-02 only to the us-central1 subnetwork 172.16.20.0/24 and prevent attachment to any other subnet—what should you grant to the group to meet this requirement?

호스트 프로젝트 수준에서 Compute Network User를 부여하는 것은 범위가 너무 넓습니다. 그러면 서비스 프로젝트에서 생성한 VM을 호스트 프로젝트의 Shared VPC 내 어떤 서브네트워크에도 연결할 수 있게 되며, us-central1의 172.16.20.0/24에만 제한되지 않습니다. 이는 다른 어떤 서브넷에도 연결하지 못하게 하라는 요구사항을 위반합니다. 프로젝트 수준 권한 부여는 흔하지만 최소 권한 제약을 충족하지 못합니다.

이는 호스트 프로젝트의 특정 서브네트워크 리소스에 직접 IAM을 적용할 수 있기 때문에 정답입니다. 172.16.20.0/24 서브네트워크에 roles/compute.networkUser를 부여하면, 서비스 프로젝트에서 VM을 생성할 때 해당 서브네트워크를 사용(해당 서브네트워크에 NIC를 attach)할 수 있으면서도 다른 서브네트워크를 사용할 권한은 부여되지 않습니다. 이는 요청된 제한을 정확히 강제합니다.

호스트 프로젝트 수준의 Compute Shared VPC Admin(roles/compute.xpnAdmin)은 Shared VPC를 관리하기 위한 것입니다. 즉, 호스트 프로젝트 활성화, 서비스 프로젝트 연결/해제, Shared VPC 수준 설정 관리 등을 수행합니다. 이는 필요 이상으로 권한이 크며 “오직 이 하나의 서브넷만”이라는 사용 제약을 직접 구현하지도 않습니다. 또한 관리 권한을 확장하여 위험을 증가시킵니다.

서비스 프로젝트 수준의 Compute Shared VPC Admin은 서브넷 연결을 제어하는 올바른 지점이 아닙니다. 서브네트워크는 호스트 프로젝트가 소유하므로, 서브넷을 사용할 수 있는 실질적인 권한은 호스트 프로젝트의 서브네트워크 리소스에 부여되어야 합니다. 또한 xpnAdmin은 관리 역할로서 요구사항 대비 과도하게 허용적입니다.

문제 분석

핵심 개념: 이 문제는 Shared VPC IAM 위임과 최소 권한 원칙을 테스트합니다. 즉, 서비스 프로젝트의 리소스(Compute Engine VM)를 호스트 프로젝트에 존재하는 서브넷에 연결(attach)할 때 필요한 권한을 다룹니다. Shared VPC에서는 서브넷과 방화벽 규칙이 호스트 프로젝트에 의해 소유되지만, 서비스 프로젝트는 올바른 IAM 권한이 있는 경우에만 해당 호스트 서브넷에 연결되는 VM NIC를 생성할 수 있습니다. 정답이 맞는 이유: Data Science Blue 그룹이 단 하나의 서브네트워크(us-central1, 172.16.20.0/24)에서만 VM 네트워크 인터페이스를 생성/연결할 수 있고 다른 어떤 서브넷도 사용하지 못하게 하려면, 권한 범위를 해당 특정 서브네트워크 리소스로 제한해야 합니다. 호스트 프로젝트의 특정 서브네트워크에 Compute Network User(roles/compute.networkUser)를 부여하면, 서비스 프로젝트에서 VM 인스턴스(또는 instance templates/MIGs)를 생성할 때 그 서브네트워크를 사용할 수 있지만 Shared VPC의 다른 서브넷을 사용할 권한은 부여되지 않습니다. 주요 기능 / 모범 사례: - Shared VPC는 호스트 프로젝트가 소유한 네트워크 리소스를 사용하며, 서비스 프로젝트의 주체(principal)는 해당 네트워크 리소스에 대해 명시적인 IAM 권한이 필요합니다. - roles/compute.networkUser에는 compute.subnetworks.use 및 compute.subnetworks.useExternalIp(구성에 따라 다름) 같은 권한이 포함되어 VM NIC 연결을 가능하게 합니다. - 서브네트워크에 대한 리소스 수준 IAM은 프로젝트 수준의 광범위한 권한 부여 대신 서브넷 수준 경계를(최소 권한) 강제하는 권장 방식입니다. - 이는 Google Cloud Architecture Framework 보안 원칙(강력한 ID, 최소 권한, 명확한 세그먼테이션/경계 제어)과 일치합니다. 흔한 오해: 자주 빠지는 함정은 호스트 프로젝트 수준에서 roles/compute.networkUser를 부여하는 것으로, 이는 해당 호스트 프로젝트의 Shared VPC 내 모든 서브네트워크에 연결을 허용하여 요구사항을 위반합니다. 또 다른 오해는 Shared VPC Admin 역할을 사용하는 것인데, 이는 Shared VPC 구성 및 관리(서비스 프로젝트 연결, 호스트 프로젝트 활성화 등)를 위한 것이지, 워크로드가 연결할 수 있는 서브넷을 좁게 제어하기 위한 것이 아닙니다. 시험 팁: - Shared VPC에서 “특정 서브넷을 사용할 수 있어야 한다” 유형의 문제는: 서브네트워크 리소스에 roles/compute.networkUser를 떠올리세요. - “Shared VPC 관계/구성을 관리할 수 있어야 한다” 유형은: 적절한 프로젝트 범위에서 roles/compute.xpnAdmin(Shared VPC Admin)을 떠올리세요. - 요구사항(모든 서브넷 vs. 하나의 서브넷)에 맞춰 범위(프로젝트 vs. 서브네트워크)를 항상 일치시키세요.

19
문제 19

Your online gaming platform runs UDP-based matchmaker services on Compute Engine instances in us-east1 and must record the original client IPs for per-player rate limiting and security audits; a cost policy mandates use of the Standard network tier and you expect up to 25,000 concurrent client connections—under these constraints, which Google Cloud load balancer should you deploy to preserve the client IP by default?

External SSL Proxy Load Balancer는 SSL/TLS를 terminate하고 트래픽을 backend로 전달하는 proxy 기반의 global external load balancer입니다. UDP용으로 설계되지 않았고(TCP에서 SSL offload용), proxy이므로 기본적으로 backend에서 원래 클라이언트 source IP를 보존하지 않습니다. 또한 Premium network tier가 필요해 Standard tier 비용 제약을 위반합니다.

External TCP Proxy Load Balancer도 proxy 기반이며 TCP 트래픽용(UDP 아님)입니다. 연결을 proxy하므로 backend는 일반적으로 원래 클라이언트 IP가 아니라 source로 load balancer의 IP를 보게 되어, 플레이어별 rate limiting 및 audit 요구사항을 깨뜨립니다. 또한 external TCP proxy load balancing은 global external proxy 서비스로 Premium tier가 필요하므로 Standard tier 요구와 충돌합니다.

Internal TCP/UDP Load Balancer는 TCP/UDP를 지원하지만 VPC 또는 연결된 네트워크(VPN/Interconnect) 내의 internal(private) 트래픽에만 사용됩니다. public gaming client를 위한 internet-facing load balancer가 아닙니다. internal 클라이언트에 대해서는 source IP를 보존할 수 있더라도, public internet을 통해 접속하는 외부 플레이어를 서비스해야 한다는 요구사항을 충족할 수 없습니다.

External TCP/UDP Network Load Balancer는 UDP를 지원하고, 연결을 terminate/proxy하지 않기 때문에 기본적으로 원래 클라이언트 source IP를 보존하는 regional, passthrough Layer 4 load balancer입니다. Standard network tier로 사용할 수 있어 비용 정책을 충족합니다. 따라서 UDP 기반 matchmaking에서 backend rate limiting 및 true client IP 기반의 보안 audit logging 요구사항에 가장 적합합니다.

문제 분석

핵심 개념: 이 문제는 Standard network tier를 사용해야 한다는 제약 하에서, 원래 클라이언트 source IP를 보존하면서 UDP 트래픽에 적합한 Google Cloud load balancer를 올바르게 선택하는지를 평가합니다. 또한 proxy vs passthrough load balancing의 차이와, 그 차이가 rate limiting 및 audit logging 같은 보안 통제에서 source IP 가시성에 어떤 영향을 주는지도 간접적으로 테스트합니다. 정답이 맞는 이유: External TCP/UDP Network Load Balancer(선택지 D)는 passthrough(비-proxy) Layer 4 load balancer입니다. 연결을 terminate하거나 proxy하지 않기 때문에, backend VM은 기본적으로 원래 클라이언트 source IP가 포함된 패킷을 수신합니다. 이는 UDP에는 특별한 header(UDP에는 존재하지 않음)나 추가 구성 없이도, 플레이어별 rate limiting과 보안 감사(audit)를 위해 원래 클라이언트 IP를 기록해야 한다는 요구사항을 직접 충족합니다. 또한 Standard network tier를 지원하므로 비용 정책과도 일치합니다. 주요 기능 / 구성 / 모범 사례: - TCP 및 UDP에 대한 passthrough L4 load balancing: 클라이언트 IP를 네이티브로 보존합니다. - Standard tier에서 동작합니다(Premium이 필요한 global external proxy load balancer와 달리). - regional 배포에 적합합니다(us-east1에 인스턴스가 있음). multi-region의 경우 일반적으로 regional NLB를 각각 배포하고 DNS/traffic steering을 사용합니다. - 보안 엔지니어링 관점: VPC firewall rules와 결합하고, Cloud Armor는 NLB에는 적용되지 않으며(Cloud Armor는 HTTP(S) 및 일부 proxy LB용), VPC Flow Logs 및 애플리케이션 로그를 통한 logging/telemetry를 고려합니다. - 용량/스케일링: 25,000 concurrent clients는 흔한 스케일 포인트이므로, backend 인스턴스 sizing, UDP socket 처리, health checks가 적절히 구성되었는지 확인합니다. 흔한 오해: 많은 사람들이 “proxy” load balancer가 보안에 더 좋다고 가정하지만, UDP에서는 backend가 source로 load balancer의 IP를 보게 되어 요구사항을 깨뜨립니다. 또 다른 함정은 UDP를 지원한다는 이유로 internal load balancing을 선택하는 것인데, internal LB는 private, intra-VPC 트래픽용이며 인터넷 클라이언트를 앞단에서 받지 못합니다. 시험 팁: - backend에서 클라이언트 source IP를 반드시 보존해야 한다면, proxy L4/L7보다 passthrough L4(Network Load Balancer)를 우선합니다. - 문제에 Standard tier가 언급되면, global external proxy load balancer(Premium 필요)를 제외합니다. - UDP + internet-facing + 클라이언트 IP 보존 조합은 External TCP/UDP Network Load Balancer를 강하게 시사합니다.

20
문제 20

Your organization runs an Autopilot GKE cluster in us-central1 with three namespaces (ingest, transform, report) hosting about 80 Pods that must read from a Cloud Storage bucket (gs://media-raw) and write to another bucket (gs://media-processed) in a separate project; your security policy forbids distributing long-lived credentials to workloads and requires least privilege and low operational overhead. How should you grant the Pods secure access to the buckets while minimizing management effort?

정답입니다. Workload Identity for GKE는 Kubernetes service account를 Google service account에 mapping하여 Pods에 keyless, 단기 자격 증명을 제공합니다. 이후(프로젝트가 달라도) 특정 buckets에 필요한 Cloud Storage IAM roles만 부여합니다. 이는 “no long-lived credentials” 정책을 충족하고, bucket-level roles로 least privilege를 지원하며, 키 배포 및 rotation을 제거하여 운영 오버헤드를 최소화합니다.

오답입니다. Secret Manager와 30일 rotation 일정이 있더라도, 이 접근은 여전히 service account keys(장기 자격 증명)를 사용하며 rotation, 재배포, 실패 처리에 대한 운영 프로세스가 필요합니다. 또한 키가 유출되면 blast radius가 커집니다. 문제는 워크로드에 장기 자격 증명을 배포하는 것을 명시적으로 금지하며, service account keys는 이를 위반합니다.

오답입니다. Kubernetes Secret에 service account keys를 저장하는 것은 선택지 중 운영 및 보안 위험이 가장 큽니다. 키는 장기이며 복사될 수 있고, RBAC에 따라 namespace 내 다른 principal이 접근할 수 있습니다. Rotation은 수동/복잡하며, 워크로드에 장기 자격 증명을 배포하지 말라는 정책을 직접 위반합니다.

오답입니다. Secret Manager는 민감한 material을 저장하는 데 Kubernetes Secrets보다 낫지만, 핵심 문제를 해결하지 못합니다. service account keys는 여전히 워크로드에 배포되어야 하는 장기 자격 증명입니다. 이는 관리 오버헤드(키 lifecycle, rotation, rollout coordination)를 증가시키며, Workload Identity의 단기 및 자동 rotation tokens에 비해 least-privilege best practices와도 충돌합니다.

문제 분석

핵심 개념: 이 문제는 장기 자격 증명 없이 GKE 워크로드의 identity 및 access를 다루며, 특히 Workload Identity for GKE(Kubernetes service account를 Google Cloud service account로 federation)와 Cloud Storage에서의 least-privilege IAM(교차 프로젝트 access 포함)을 테스트합니다. 정답이 맞는 이유: 옵션 A는 Workload Identity for GKE를 사용하여 Pods가 Google APIs를 호출할 때 Google Cloud service account(GSA)로서 단기(short-lived)이며 자동으로 rotation되는 자격 증명을 획득하도록 합니다. 이는 장기 자격 증명 금지 정책(service account keys 미사용)을 충족하고 운영 오버헤드(키 배포/rotation)가 최소화됩니다. 그런 다음 별도 프로젝트에 있더라도 특정 buckets에 필요한 Cloud Storage 권한만 부여합니다(예: gs://media-raw read 및 gs://media-processed write). 이를 위해 bucket 리소스에 대한 IAM roles를 GSA에 binding합니다. 이는 least privilege 및 Google Cloud Architecture Framework의 보안 원칙(강력한 identity, 단기 자격 증명, 중앙집중식 policy)과 일치합니다. 주요 기능 / 구성 참고 사항: - Autopilot cluster에서 Workload Identity를 enable합니다(Autopilot은 이를 지원하며 권장 접근 방식입니다). - 권한 범위를 제한하기 위해 namespace별 또는 워크로드 클래스(ingest/transform/report)별로 Kubernetes service account(KSA)를 생성/선택합니다. - GSA에 iam.workloadIdentityUser를 사용하여 KSA를 GSA에 binding합니다(KSA identity에 대한 principalSet / principal format). - bucket-level IAM roles를 GSA에 부여합니다: 일반적으로 media-raw에는 roles/storage.objectViewer, media-processed에는 roles/storage.objectCreator(또는 overwrite/delete가 필요하면 objectAdmin)를 부여합니다. project-wide roles보다 bucket-level IAM을 선호합니다. - Cross-project: buckets의 프로젝트(또는 bucket)에 동일한 GSA에 대한 IAM을 적용합니다. VPC/network 변경은 필요하지 않습니다. 흔한 오해: Secret Manager에 service account keys를 저장(rotate 여부와 무관)하면 “secure”해 보일 수 있지만, 여전히 장기 자격 증명에 의존하며 운영 부담과 위험(유출, rotation 실패)을 증가시킵니다. Kubernetes Secrets는 key material에 대해 더 취약한데, namespace 내에서 비교적 넓게 읽기 가능할 때가 많고 keyless workload identity를 대체할 수 없습니다. 시험 팁: GKE에서 Google API access가 필요하면 service account keys보다 Workload Identity(keyless)를 기본으로 고려하세요. Cloud Storage는 광범위한 project roles보다 bucket-level IAM과 최소 roles(objectViewer/objectCreator) 관점으로 접근하세요. 문제가 “no long-lived credentials”와 “low operational overhead”를 강조하면, 거의 항상 Workload Identity가 의도된 해법입니다.

합격 후기(6)

P
P***********Nov 25, 2025

학습 기간: 2 months

I used Cloud Pass during my last week of study, and it helped reinforce everything from beyondcorp principles to securing workloads. It’s straightforward, easy to use, and genuinely helps you understand security trade-offs.

길
길**Nov 23, 2025

학습 기간: 1 month

문제 다 풀고 시험에 응했는데 바로 합격했어요! 시험이랑 문제는 비슷한게 40% 조금 넘었던거 같고, 처음 보는 유형은 제 개념 이해를 바탕으로 풀었어요.

D
D***********Nov 12, 2025

학습 기간: 1 month

I would like to thanks the team of Cloud Pass for these greats materials. This helped me passing the exam last week. Most of the questions in exam as the sample questions and some were almost similar. Thank you again Cloud Pass

O
O**********Oct 29, 2025

학습 기간: 1 month

Absolutely invaluable resource to prepare for the exam. Explanations and questions are spot on to give you a sense of what is expected from you on the actual test.

O
O**********Oct 29, 2025

학습 기간: 1 month

I realized I was weak in log-based alerts and access boundary configurations. Solving questions here helped me quickly identify and fix those gaps. The question style wasn’t identical to the exam, but the concepts were spot-on.

모의고사

Practice Test #1

50 문제·120분·합격 700/1000

Practice Test #2

50 문제·120분·합격 700/1000

Practice Test #3

50 문제·120분·합격 700/1000

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Google Associate Cloud Engineer

Associate

Google Professional Cloud Network Engineer

Google Professional Cloud Network Engineer

Professional

Google Associate Data Practitioner

Google Associate Data Practitioner

Associate

Google Cloud Digital Leader

Google Cloud Digital Leader

Foundational

Google Professional Cloud Architect

Google Professional Cloud Architect

Professional

Google Professional Cloud Database Engineer

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Google Professional Cloud Developer

Professional

Google Professional Machine Learning Engineer

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

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