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

Practice Test #2

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

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

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를 떠올리세요.

3
문제 3

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를 추가하세요.

4
문제 4

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 자체를 완전히 피하는 것입니다.

5
문제 5

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의 보안 및 컴플라이언스 원칙(데이터 분류, 예방 제어, 자동화된 정책 집행)에 매핑하세요.

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

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

6
문제 6

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. 서브네트워크)를 항상 일치시키세요.

7
문제 7

Your production Google Cloud project runs a managed instance group behind an external HTTP(S) load balancer; a team of 10 release engineers must roll out new application versions by updating instance templates and triggering deployments via Cloud Build, but they must not be able to create, update, or delete any VPC firewall rules in the shared network; only a 2-person NetOps group may change firewall rules, and auditors require least privilege with clear separation of duties and auditable assignments. What should you do?

오답입니다. Network Admin을 부여하면 방화벽 규칙을 생성, 업데이트, 삭제할 수 있는 권한을 포함해 광범위한 네트워크 권한이 제공됩니다. “방화벽 규칙을 수정하지 말라”는 지침에 의존하는 것은 최소 권한을 위반하며 직무 분리 또는 감사 요구사항을 충족하지 못합니다. 시험에서는 사용자 행동에 의존하는 옵션은 컴플라이언스 중심 시나리오에서 보통 오답입니다.

오답입니다. Access Context Manager(BeyondCorp/Context-Aware Access)는 주로 지원되는 리소스에 대해 컨텍스트(IP, 디바이스 상태, ID) 기반으로 액세스를 제어하기 위한 것이지, Compute Engine 방화벽 규칙 관리에 대한 세밀한 IAM 권한을 분리하기 위한 것이 아닙니다. 변경이 가능한 위치를 제한하더라도, 기본 IAM 권한이 부여되어 있다면 릴리스 엔지니어는 여전히 방화벽 규칙을 변경할 authorization을 갖게 됩니다.

정답입니다. Custom IAM role은 권한 범위를 정밀하게 설정할 수 있습니다. 릴리스 엔지니어는 배포 관련 권한(인스턴스 템플릿, MIG 업데이트, Cloud Build 작업)만 받고, NetOps는 방화벽 관리 권한만 받습니다. 이는 최소 권한을 강제하고, 명확한 직무 분리를 제공하며, 그룹에 대한 IAM binding을 통해 쉽게 감사할 수 있습니다. 또한 Shared VPC 거버넌스에 부합하게 host project의 방화벽 제어를 NetOps가 유지하도록 합니다.

오답입니다. IAM deny policies로 특정 권한을 차단할 수는 있지만, Editor를 부여하는 것은 지나치게 광범위하며 여러 서비스에 걸친 많은 무관한 권한을 부여하므로 최소 권한을 위반합니다. Deny policies는 강력하지만, 과도하게 허용적인 기본 role을 부여하는 것을 정당화하기 위한 수단이 아니라 추가적인 가드레일로 사용하는 것이 가장 좋습니다. 감사자는 일반적으로 먼저 최소 allow 권한을 기대하고, 그 다음 defense-in-depth를 위해 선택적으로 deny를 추가하는 것을 기대합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 IAM 최소 권한(least privilege)과 직무 분리(separation of duties)를 테스트합니다. 목표는 릴리스 엔지니어가 배포(인스턴스 템플릿 업데이트 및 Cloud Build를 통해 managed instance group 롤아웃 트리거)를 수행할 수 있게 하되, shared VPC 방화벽 규칙을 관리하지 못하도록 하는 것입니다. 또한 컴플라이언스 기대치에 맞춰 감사 가능하고 역할 기반의 액세스를 강조합니다. 정답이 맞는 이유: 두 개의 custom IAM role을 생성하면 배포 권한과 네트워크 보안 관리 권한을 명확하게 분리할 수 있습니다. “deployer” role에는 인스턴스 템플릿 업데이트, managed instance group 업데이트/롤링, Cloud Build 실행(및 필요한 service account impersonation) 등 필요한 권한만 포함할 수 있습니다. 별도의 “network security” role에는 Compute Engine 방화벽 규칙 권한(예: compute.firewalls.create/update/delete)만 포함하고 NetOps 그룹에만 부여할 수 있습니다. 이는 최소 권한을 직접적으로 강제하며, 감사자가 요구하는 명확하고 감사 가능한 할당(그룹 멤버십 + IAM policy binding)을 제공합니다. 주요 기능 / 모범 사례: - 10명의 릴리스 엔지니어와 2명의 NetOps 엔지니어를 위해 Google Groups를 사용한 뒤, 감사 가능성과 운영 단순성을 위해 그룹에 role을 바인딩합니다. - 가능하면 predefined role을 선호합니다(예: compute.instanceAdmin.v1, compute.loadBalancerAdmin, cloudbuild.builds.editor). 다만 방화벽 관리 같은 민감한 권한을 제외해야 한다면 custom role을 사용합니다. - Shared VPC에서는 방화벽 규칙이 일반적으로 host project에 존재합니다. 릴리스 엔지니어가 host project에서는 방화벽 권한을 전혀 갖지 않도록 하면서도, service project(들)에서는 필요한 권한을 갖도록 보장합니다. - Google Cloud Architecture Framework의 “Security, privacy, and compliance”(최소 권한, 직무 분리, 중앙 집중 거버넌스)와 정렬됩니다. 흔한 오해: 사람들은 종종 “Network Admin + 정책/프로세스”가 허용된다고 생각하지만, 감사자는 기술적 강제를 요구합니다. 또 다른 오해는 Access Context Manager(컨텍스트 기반 액세스)를 authorization과 혼동하는 것입니다. 이는 액세스가 어디에서 오는지 제한할 수는 있지만, 최소 권한 권한 부여를 대체하지는 못합니다. Deny policies가 도움이 될 수는 있지만, Editor 같은 광범위한 role을 부여하는 것은 여전히 나쁜 관행이며 다른 의도치 않은 권한을 만들 수 있습니다. 시험 팁: “~할 수 없어야 한다” + “감사자가 최소 권한과 직무 분리를 요구한다”를 보면, 절차적 통제보다는 IAM role 설계(custom role 및 그룹 기반 바인딩)를 기본 해법으로 선택하세요. Shared VPC의 host/service project 경계를 활용해 네트워크 제어는 NetOps에 유지하고, 앱 팀은 배포 자율성을 유지하도록 하세요.

8
문제 8
(2개 선택)

Your retail chain streams point-of-sale logs every 5 minutes from 300 branches via Pub/Sub into a Dataflow pipeline that writes to Cloud Bigtable for fraud analytics, and you discover that two PII fields (national ID numbers and phone numbers) are included; you must obfuscate these fields during ingestion to prevent analysts from seeing raw values, yet be able to re-identify the original values for regulatory investigations within 7 years while maintaining consistent tokens to enable joins and group-bys; which two components should you use? (Choose two.)

Secret Manager는 API keys, passwords, certificates와 같은 secrets를 저장하고 접근하기 위해 설계되었습니다. 민감한 material을 저장할 수는 있지만, 대규모 deterministic encryption/decryption workflow에서 사용되는 encryption keys를 관리하는 1차 서비스는 아닙니다. Cloud KMS에 비해 전용 cryptographic key lifecycle controls(key versions, encryption을 위한 rotation semantics, HSM options)과 DLP 기반 de-identification에 기대되는 표준 통합 패턴이 부족합니다.

Cloud Key Management Service (KMS)는 PII를 난독화하고 이후 재식별하는 데 사용되는 cryptographic keys를 보호하고 제어하기 위한 올바른 key management 구성요소입니다. IAM 기반 access control, audit logging, key versioning, rotation planning을 지원하며, 이는 7년 규제 기간에 필수적입니다. KMS는 Cloud DLP와 KMS-wrapped keys로 통합되어 separation of duties와 조사 중 통제된 decryption을 가능하게 합니다.

Cryptographic hashing을 사용하는 Cloud DLP는 일관된 pseudonymous values(동일 입력이 동일 출력으로 hash됨)를 생성할 수 있어 joins 및 group-bys를 지원합니다. 그러나 hashing은 one-way이므로 조사(investigations)를 위해 원본 national IDs와 phone numbers를 재식별해야 한다는 요구사항을 충족하지 못합니다. salts/keys(HMAC)를 사용하더라도 decrypt가 아니며, 비가역적이어서 여기에는 부적합합니다.

Cloud DLP automatic text redaction은 민감한 substring을 제거하거나 마스킹합니다(예: digits를 X로 대체). 이는 분석가가 원본 PII를 보지 못하게 할 수 있지만, 일반적으로 일관된 joins/group-bys 수행 능력을 파괴하고 원본 값을 신뢰성 있게 재식별할 수 없게 합니다. Redaction은 표시/로그 sanitization에는 적합하지만, 규제 조사에 필요한 되돌릴 수 있는 tokenization에는 적합하지 않습니다.

Cloud DLP deterministic encryption(AES-SIV)은 일관되고 되돌릴 수 있는 난독화를 위해 설계되었습니다. Deterministic encryption은 동일 plaintext에 대해(동일 key/context에서) 동일 ciphertext를 생성하므로, 분석(joins, group-bys)을 위한 안정적인 토큰을 제공하면서도 decrypt를 통해 권한 있는 재식별을 허용합니다. Cloud KMS-managed keys와 결합하면 강력한 보안 제어, 감사 가능성, 그리고 compliance에 필요한 장기 key governance를 제공합니다.

문제 분석

핵심 개념: 이 문제는 스트리밍 ingestion 중 PII를 토큰화/가명처리하면서 분석 유용성(joins/group-bys)을 유지하고, 이후 재식별을 가능하게 하는지를 테스트합니다. Google Cloud에서는 일반적으로 Cloud DLP de-identification에서 deterministic encryption을 사용하고, Cloud KMS의 customer-managed keys로 이를 지원하는 방식으로 구현합니다. 정답이 맞는 이유: (1) 분석가가 원본 값을 볼 수 없도록 national ID와 phone numbers를 난독화해야 하고, (2) 동일 입력이 항상 동일 출력으로 매핑되도록 토큰을 일관되게 유지해 joins 및 aggregations가 가능해야 하며, (3) 최대 7년 동안 원본 값을 복구할 수 있어야 합니다. Cloud DLP deterministic encryption(AES-SIV)은 (동일 key/context가 주어졌을 때) 동일 plaintext에 대해 안정적인 ciphertext를 생성하므로 일관된 토큰으로 기능합니다. hashing과 달리 deterministic encryption은 되돌릴 수 있어 재식별 요구사항을 충족합니다. Cloud KMS는 7년 기간 동안 encryption/decryption에 사용되는 key material을 보호, rotation, 접근 감사할 수 있도록 필요한 cryptographic key management를 제공합니다. 주요 기능 / 구성 / 모범 사례: - Dataflow pipeline에서 Bigtable에 쓰기 전에 두 PII 필드에 Cloud DLP de-identification transform: deterministic encryption(AES-SIV)을 사용합니다. - wrapping/KEK는 Cloud KMS(CMEK)에 저장 및 관리합니다. IAM으로 접근을 제어하고, separation of duties를 적용하며, Cloud Audit Logs로 감사를 수행합니다. - 장기 보관을 계획합니다: key lifecycle policies, backups, 그리고 재식별을 깨뜨리지 않는 rotation 전략을 보장합니다(rotation은 신중히 처리해야 하며, 과거 데이터 decrypt를 위해 이전 key versions를 사용 가능하게 유지해야 합니다). - DLP와 KMS-wrapped keys를 함께 사용하여, 엄격히 통제된 investigation workflow만 decrypt할 수 있도록 고려합니다. 흔한 오해: - DLP의 cryptographic hashing은 일관된 토큰을 제공하는 것처럼 보이지만, 되돌릴 수 없으므로 재식별 요구사항을 충족하지 못합니다. - Automatic text redaction은 데이터를 완전히 제거하여 joins/group-bys 및 조사(investigations)를 깨뜨립니다. - Secret Manager는 secrets를 저장하지만 encryption 작업을 위한 cryptographic key management system이 아니며, KMS와 같은 key lifecycle controls를 제공하지 않습니다. 시험 팁: “분석을 위한 일관된 토큰” + “나중에 재식별해야 함”을 보면 deterministic encryption/tokenization( redaction 아님, hashing 아님)을 떠올리세요. “7년”, “regulatory investigations”, “keys의 control/audit”가 보이면 de-identification 방법을 Cloud KMS와 결합해 CMEK, IAM 제어, 감사 가능성을 확보하세요. 이는 Google Cloud Architecture Framework의 data protection 원칙(강력한 encryption, 중앙화된 key management, least privilege access)과 일치합니다.

9
문제 9
(2개 선택)

Your company runs 20 CI pipelines in GitHub Actions and Azure DevOps outside Google Cloud that deploy to 8 Google Cloud projects using workload identity federation; service account keys are prohibited by policy. You must prevent attackers from spoofing another pipeline's identity (for example, by manipulating mutable claims like email or display name) to obtain unauthorized access to Google Cloud resources, while keeping existing federation flows and token lifetimes (1 hour) unchanged. What should you do? (Choose two.)

IAM/STS에 대해 Data Access audit log를 활성화하면 누가 언제 토큰을 교환했는지 조사하는 데 도움이 되고 alerting에도 활용할 수 있습니다. 하지만 trust policy가 mutable claim을 허용한다면 공격자가 identity spoofing에 성공하는 것을 막지는 못합니다. 문제는 흐름과 토큰 lifetime을 변경하지 않고 spoofing을 방지하라고 묻고 있으므로, 로깅만으로는 불충분하며 주로 탐지 통제입니다.

WIF/IAM에서 spoofing 완화책으로 service account를 impersonate할 수 있는 외부 identity 수에 상한을 두는 것은 일반적이거나 권장되는 통제가 아닙니다. 설령 그런 상한이 존재하더라도, 공격자가 claim을 조작해 허용된 identity 중 하나를 impersonate하는 것을 막지 못합니다. 핵심 문제는 수량 제한이 아니라 claim 선택과 authorization condition입니다.

workload identity pool/provider를 위한 전용 security project는 여러 프로젝트에 걸친 중앙 거버넌스와 일관된 정책 관리를 위한 좋은 조직 패턴입니다. 그러나 파이프라인 간 spoofing을 직접적으로 방지하지는 못합니다. spoofing은 attribute mapping/condition에서 immutable claim을 사용하고 올바른 IAM principal 바인딩을 적용함으로써 방지되며, 이러한 통제 없이 중앙화만 하면 취약점이 그대로 남습니다.

이것이 핵심 예방 통제입니다. attribute mapping과 provider attribute condition을 구성할 때 google.subject를 설정하고 IAM 바인딩(principalSet selector)을 작성하는 기준으로 immutable하고 provider가 통제하는 식별자(예: GitHub repository_id, repo에 연결된 workflow identifier, Azure AD object_id/app ID)만 사용하도록 합니다. 이렇게 하면 email/display name 같은 mutable claim을 변경해 다른 파이프라인 identity를 impersonate하는 공격을 방지할 수 있습니다.

각 service account와 대상 리소스에 least-privilege IAM을 적용하면 침해된 파이프라인 identity의 영향을 줄일 수 있습니다. 1-hour 토큰이 변경되지 않는 상황에서는 탈취된 토큰이 만료 시점까지 사용될 수 있다고 가정해야 하며, 권한을 제한하면 cross-project 또는 광범위한 접근을 막을 수 있습니다. 이는 Google Cloud의 핵심 보안 모범 사례이며, 강한 identity binding을 보완해 defense in depth를 제공합니다.

문제 분석

핵심 개념: 이 문제는 외부 CI/CD 시스템(GitHub Actions, Azure DevOps)을 위한 Workload Identity Federation (WIF)의 보안 구성과, Security Token Service (STS) 토큰 교환 및 service account impersonation 과정에서 identity spoofing을 방지하는 방법을 평가합니다. 핵심은 안정적이고 사용자가 수정할 수 없는 식별자에 접근을 바인딩하고, 결과로 생성되는 Google identity에 대해 least privilege를 강제하는 것입니다. 정답이 맞는 이유: (D)는 mutable claim(email, display name, branch name 등)을 조작하여 한 파이프라인이 다른 파이프라인을 impersonate하는 것을 방지하는 주요 통제입니다. WIF에서는 외부 토큰 claim을 Google attribute(google.subject 포함)로 매핑한 다음, IAM principalSet/principal 바인딩과 provider attribute condition을 사용해 특정 identity만 허용합니다. authorization을 mutable claim에 기반하면, 해당 claim에 영향을 줄 수 있는 공격자가 조건을 만족시켜 다른 파이프라인을 impersonate할 수 있습니다. immutable identifier(예: GitHub repository_id, pinned ref에 묶인 workflow_ref, environment ID, 또는 Azure AD object_id / application (client) ID)를 사용하면 그 값이 안정적이고 identity provider가 통제하므로 spoofing이 실질적으로 훨씬 어려워집니다. (E)는 단일 파이프라인 identity가 침해되었을 때의 blast radius를 제한함으로써 D를 보완합니다. 강한 identity binding이 있더라도, 탈취된 OIDC 토큰이나 침해된 runner는 변경되지 않은 1-hour lifetime 동안 해당 파이프라인을 impersonate할 수 있습니다. 대상 service account와 리소스에 least-privilege IAM을 적용하면 공격자가 프로젝트 간 lateral movement를 하거나 관련 없는 자산에 접근하는 것을 방지할 수 있습니다. 핵심 기능 및 모범 사례: provider attribute mapping을 사용해 google.subject를 immutable claim으로 설정하고, 필요 시 custom attribute(attribute.repository_id, attribute.aud, attribute.actor_id)를 매핑합니다. 그런 다음 principalSet://.../attribute.* selector를 사용해 provider attribute condition과 IAM 바인딩을 강제합니다. 파이프라인(또는 repo/environment)별 service account와 좁게 범위가 지정된 role(가능하면 resource-level IAM)을 결합합니다. 이는 Google Cloud Architecture Framework 원칙인 least privilege, strong identity, defense in depth에 부합합니다. 흔한 오해: pool을 중앙화(C)하면 관리성은 좋아지지만, 매핑/조건이 여전히 mutable attribute에 의존한다면 spoofing을 본질적으로 방지하지 못합니다. audit log(A)는 탐지/포렌식에 도움이 되지만 예방은 아닙니다. 인위적 상한(B)은 표준 IAM/WIF 통제가 아니며 claim spoofing을 해결하지 못합니다. 시험 팁: WIF 문제에서는 예방 메커니즘으로 “attribute mapping/conditions”와 “immutable identifiers”를 찾고, 영향 감소를 위해 least privilege와 함께 묶어 생각하세요. 로깅은 보통 탐지/모니터링을 묻는 경우가 아니라면 2차 통제입니다.

10
문제 10

A media analytics company performs a 7-day manual security review for every new service that verifies service-to-service transit paths, request handling, and VPC firewall rules across 3 projects and 2 Shared VPCs. With 12 squads releasing about 25 GKE and Cloud Run services per month, this process delays releases and consumes security bandwidth. They want teams to deploy without the full manual review while ensuring that violations (for example, 0.0.0.0/0 on TCP:22, publicly readable Cloud Storage buckets, or egress to restricted RFC1918 ranges) are prevented before merge/deploy rather than detected in production. They already use GitHub and Cloud Build and cannot fund a dedicated security reviewer per squad. What should you recommend?

배포 후 스캐닝(SCC findings, audits)은 탐지와 지속적 모니터링에 유용하지만, 반응적입니다. 문제는 merge/deploy 이전에 위반을 방지할 것을 명시적으로 요구하며, 프로덕션에서 이를 발견하는 것을 요구하지 않습니다. go-live 이후 remediation에 의존하면(예: 공개 buckets 또는 전 세계에 열린 SSH) 노출 구간이 발생하며, 릴리스를 막는 수동 리뷰 프로세스를 제거하지도 못합니다.

IaC와 CI/CD에서의 policy-as-code 검증은 올바른 예방적 통제입니다. GitHub PR에서 Cloud Build로 terraform plan 검증(terraform-validator/Config Validator/OPA policies)을 실행하면, 비준수 firewall rules, bucket ACL/public access 설정, routing/egress constraints를 merge 이전 및 배포 이전에 차단할 수 있습니다. 이는 squad마다 전담 리뷰어가 필요하지 않도록 보안 강제를 확장하고 리드 타임을 줄입니다.

모든 egress를 inspection appliances로 강제하는 것은 런타임 경계/모니터링 접근입니다. 특정 트래픽을 탐지하거나 차단하는 데는 도움이 될 수 있지만, 공개적으로 읽을 수 있는 Cloud Storage buckets나 과도하게 허용적인 firewall rules 같은 구성 위반이 생성되는 것을 신뢰성 있게 방지하지는 못합니다. 또한 비용, 운영 복잡성, 잠재적 지연을 추가하고 중앙 병목이 되어 빠르고 안전한 배포를 가능하게 하려는 목표와 반대됩니다.

프로덕션을 on-premises에 유지하는 것은 핵심 문제(확장 가능한 예방적 통제)를 해결하지 못하며, 극단적이고 비현실적인 아키텍처 변경입니다. 운영 부담을 증가시키고 managed services(GKE/Cloud Run)의 이점을 줄이며, 잘못된 구성 위험을 본질적으로 제거하지도 못하고 단지 다른 곳으로 옮길 뿐입니다. 또한 자동화된 가드레일로 Google Cloud에서 팀들이 안전하게 배포하도록 하려는 의도와도 모순됩니다.

문제 분석

핵심 개념: 이 문제는 수동 리뷰나 배포 후 탐지에 의존하는 대신, policy-as-code와 infrastructure-as-code (IaC)를 사용한 “shift-left” 예방적 통제를 통해 CI/CD에서 보안 요구사항이 자동으로 강제되도록 하는지를 평가합니다. 이는 Google Cloud Architecture Framework의 보안 원칙(가드레일 자동화, 최소 권한 적용, 컴플라이언스의 지속적 검증)과 일치합니다. 정답이 맞는 이유: 옵션 B는 merge/deploy 이전에 위반을 방지해야 한다는 요구사항을 직접적으로 충족합니다. IaC(예: Terraform)를 의무화하고 GitHub PR에서 트리거되는 Cloud Build에 정책 검사를 내장함으로써, 비준수 변경(예: TCP:22에 대해 0.0.0.0/0을 허용하는 firewall rules, 공개 Cloud Storage buckets, 또는 허용되지 않는 egress routes)을 프로덕션에 도달하기 전에 차단할 수 있습니다. 이는 7일짜리 수동 병목을 제거하면서 12개 squad와 월간 다수 릴리스로 확장 가능합니다. 주요 기능 / 동작 방식: - CI에서의 Policy-as-code: terraform-validator, Config Validator(OPA/Rego 기반), 또는 OPA Gatekeeper 스타일 constraints를 사용해 계획된 리소스를 조직 정책에 대해 평가합니다. - Pre-merge 강제: pull requests에서 검사를 실행하고, 정책 위반 시 빌드를 실패 처리하여 merge를 차단합니다. - 프로젝트/Shared VPC 전반의 일관성: constraints를 중앙화하고 모든 repo/pipeline에서 재사용하여 Shared VPC firewall 및 routing 표준을 일관되게 강제합니다. - 보완적 통제: 문제에서 요구하진 않지만, 이 접근은 Organization Policy Service(예: domain restricted sharing, buckets에 대한 public access prevention) 및 탐지를 위한 SCC와 잘 결합됩니다. 다만 핵심은 CI에서의 예방입니다. 흔한 오해: 팀들은 활성화가 쉽다는 이유로 “탐지 및 개선”(SCC findings)으로 기본값을 잡는 경우가 많지만, 이는 배포 전에 문제를 방지해야 한다는 요구사항을 위반합니다. 또 다른 제안으로 런타임 inspection appliances를 들기도 하지만, 이는 공개 buckets나 과도하게 허용적인 firewall rules 같은 잘못된 구성 자체를 방지하는 것이 아니라 트래픽 패턴을 탐지하는 방식입니다. 시험 팁: 프롬프트가 “merge/deploy 이전,” “수동 리뷰 감소,” “여러 팀으로 확장”을 강조할 때, 최선의 답은 거의 항상 자동화된 예방 가드레일입니다: IaC + CI/CD에서의 policy-as-code. 이를 운영 사후 모니터링이 아니라 컴플라이언스 자동화 및 지속적 통제로 매핑하세요.

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

50 문제·120분·합격 700/1000
← 모든 Google Professional Cloud Security Engineer 문제 보기

지금 학습 시작하기

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