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

Practice Test #1

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

Your 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과 외부 시스템이 등장할 수 있지만, 여기서는 외부 의존성이 명시적으로 금지되어 있습니다.

2
문제 2

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”로 취급하는 선택지는 주의하세요.

3
문제 3

Your fintech organization operates 12 Google Cloud projects under 2 folders and uses 25 service accounts; an internal review found some accounts assigned roles/editor and external contractors from two partner domains with excessive access, and you must gain within 5 minutes detailed visibility into IAM policy changes, user activity, service account key usage, and access to three restricted projects, retain these records for at least 400 days, and correlate them centrally with AWS and on-prem security events without deploying any agents on VMs—what should you do?

IAM 정책 변경에 대한 Cloud Functions는 부분적이고 취약합니다. IAM 변경에만 초점을 맞출 뿐, 서비스 전반의 포괄적인 사용자 활동, Data Access, 서비스 계정 키 사용을 다루지 못합니다. 또한 커스텀 탐지 로직과 스토리지를 구축/유지해야 하며, 모든 관련 감사 이벤트에 대해 중앙집중식 준실시간 export 및 400일 보관을 본질적으로 제공하지 않습니다. Policy Simulator는 분석용이지 감사 로그 시스템이 아닙니다.

Cloud Monitoring Metrics Explorer는 특정 인증/사용 메트릭에 대해 알림을 설정할 수 있지만, 메트릭은 관리 작업 및 데이터 읽기/쓰기의 완전하고 변경 불가능한 감사 추적이 아닙니다. 컴플라이언스 및 포렌식에 필요한 수준의 IAM 정책 변경(delta), 상세 API 호출자 ID, 서비스 계정 키 생성/사용 이벤트를 신뢰성 있게 캡처하지 못하며, SIEM 수준의 크로스 환경 로그 상관분석과 장기 보관을 위해 설계된 것도 아닙니다.

Cloud Audit Logs는 Admin Activity(IAM 정책 변경, 역할 부여, 키 생성), System Events, Data Access(민감 리소스에 대한 읽기/쓰기)에 대한 권위 있는 기록을 제공합니다. org/folder 수준의 aggregated sinks는 모든 프로젝트의 로그를 중앙집중화하고 이를 Pub/Sub로 준실시간 export하여 SIEM ingestion을 가능하게 함으로써 AWS/온프레미스 이벤트와의 상관분석을 지원합니다. Logging bucket retention 또는 export 대상은 VM 에이전트 없이도 400일 이상의 보관을 충족할 수 있습니다.

OS Config는 VM에 에이전트가 필요하므로 “no agents” 제약을 위반합니다. 설령 허용되더라도, 패치 및 구성 모니터링은 IAM 정책 변경, API 수준 사용자 활동, 관리형 서비스 전반의 서비스 계정 키 사용에 대한 권위 있는 가시성을 제공하지 못합니다. 이는 시스템 관리 도구이지 중앙집중식 클라우드 감사 및 컴플라이언스 로깅 솔루션이 아니며, 크로스 환경 SIEM 상관분석 요구사항도 해결하지 못합니다.

문제 분석

핵심 개념: 이 문제는 VM 에이전트를 설치하지 않고 Cloud Logging/Cloud Audit Logs를 사용해 중앙집중식 보안 가시성과 감사 가능성을 확보하고, 외부 SIEM으로 준실시간 내보내기를 수행하는지를 평가합니다. 이는 중앙집중식 로깅, 최소 권한 검증, 지속적 모니터링을 강조함으로써 Google Cloud Architecture Framework(Operational Excellence 및 Security)와 정렬됩니다. 정답이 맞는 이유: 옵션 C는 모든 요구사항을 직접 충족합니다. 약 5분 이내에 IAM 정책 변경(Admin Activity logs), 사용자 활동 및 API 호출(Admin Activity 및 Data Access logs), 서비스 계정 키 사용(Audit logs의 IAM/Service Account Key 작업 및 해당되는 경우 관련 Data Access), 제한된 프로젝트에 대한 접근(민감 서비스의 Data Access logs)을 가시화합니다. 또한 aggregated sinks를 통해 Pub/Sub(또는 기타 지원 대상)로 로그를 준실시간으로 내보내 외부 SIEM에 전달함으로써 AWS 및 온프레미스 이벤트와의 중앙 상관분석을 가능하게 하며, 에이전트가 필요 없습니다. 주요 기능 / 구성: 1) 조직(organization) 수준에서 Cloud Audit Logs 활성화: Admin Activity 및 System Event는 기본적으로 켜져 있으며 보관되어야 합니다. Data Access logs는 기본적으로 활성화되지 않고 볼륨/비용이 클 수 있으므로, 3개의 제한된 프로젝트(및 중요 서비스)에 대해 명시적으로 활성화합니다. 2) organization 또는 folder 수준에서 aggregated log sinks를 사용해 12개 프로젝트와 2개 folder의 로그를 모두 수집합니다. 이는 관리를 단순화하고 프로젝트 변경 시에도 커버리지를 보장합니다. 3) SIEM으로 스트리밍하기 위해 Pub/Sub로 라우팅(일반적인 패턴)하거나, 분석/아카이빙을 위해 BigQuery/Cloud Storage로 라우팅합니다. 이후 Logging buckets의 커스텀 보관 기간을 사용하거나 Cloud Storage로 export 후 lifecycle policies / BigQuery retention controls를 적용해 보관 기간을 400일 이상으로 설정합니다. 4) 비용을 제어하면서도 컴플라이언스 관련 이벤트를 보존할 수 있도록 log views 및 exclusions를 신중히 사용합니다. 흔한 오해: Monitoring metrics(옵션 B)나 커스텀 자동화(옵션 A)를 사용하고 싶을 수 있지만, 이는 IAM, 데이터 접근, 키 사용 전반에 대한 권위 있고 포괄적인 감사 추적을 제공하지 못하며, Audit Logs + sinks만큼 깔끔하게 장기 보관 및 크로스 환경 상관분석 요구사항을 충족하지 못합니다. 시험 팁: “IAM policy changes”, “who did what”, “service account key usage”, “central correlation”, “no agents”, “long retention”을 보면 Cloud Audit Logs + aggregated sinks + SIEM integration을 떠올리세요. Data Access logs는 명시적으로 활성화해야 하며, 비용과 컴플라이언스의 균형을 위해 민감 프로젝트/서비스로 범위를 제한할 수 있다는 점을 기억하세요.

4
문제 4

A regional engineering group at a healthcare company registered a separate Google Workspace with Cloud Identity and created a new Organization resource. Within 90 days, they launched 180 projects across 8 folders to host regulated analytics workloads and connected them to a shared VPC. Your centralized platform security team must assume control of who can grant permissions across this Organization and ensure the ability to audit access and configuration activity across all projects and folders. Which type of access should be granted to your team at the Organization level to meet this requirement?

Organization Administrator가 가장 좋은 답인 이유는 Organization 리소스에 대한 중앙집중식 관리 제어를 제공하며, 여기에는 IAM policy를 관리하고 folder와 project 전반에서 액세스 위임을 거버넌스하는 기능이 포함되기 때문입니다. 요구 사항은 단순히 role을 정의하는 것이 아니라, 계층 구조 전체에서 누가 권한을 부여할 수 있는지에 대한 통제권을 확보하는 것입니다. 많은 project와 folder가 있는 크고 새로 생성된 organization에서 이 role은 platform security team이 중앙집중식 IAM 거버넌스를 수립하고 시행할 수 있게 합니다. 감사 가능성은 Cloud Audit Logs를 통해 유지되며, 이는 계층 구조의 모든 수준에서 관리 및 IAM 변경 사항을 기록합니다.

Security Reviewer는 보안 상태, 구성 및 발견 사항에 대한 가시성을 위한 읽기 전용 role입니다. 팀이 리소스를 검사하고 감사를 지원하는 데 도움이 될 수는 있지만, IAM policy를 변경하거나 누가 권한을 부여할 수 있는지 제어할 수는 없습니다. 요구 사항이 권한 부여 권한에 대한 통제권 확보를 명시적으로 요구하므로, reviewer role은 충분하지 않습니다. 이는 관리가 아니라 관찰에 해당합니다.

Organization Role Administrator는 organization 수준에서 custom IAM role을 관리하며, 예를 들어 custom role 정의를 생성, 업데이트 또는 삭제할 수 있습니다. 그러나 role을 정의하는 것과 organization, folder, project의 IAM policy binding을 통해 principal에게 권한을 부여하는 것은 다릅니다. 이 role 자체만으로는 계층 구조 전반에서 누가 액세스를 할당할 수 있는지 제어하는 데 필요한 광범위한 권한을 제공하지 않습니다. 따라서 명시된 요구 사항에는 너무 범위가 좁습니다.

Organization Policy Administrator는 리소스 위치 제한이나 허용된 서비스와 같은 organization policy constraint를 관리합니다. 이러한 policy는 거버넌스와 규정 준수에 유용하지만, IAM 권한 부여 또는 누가 user와 service account에 role을 binding할 수 있는지를 직접 제어하지는 않습니다. 이 문제는 구체적으로 액세스 위임 제어에 관한 것이며, 이는 organization policy 기능이 아니라 IAM 관리 기능입니다. 따라서 이 role은 핵심 요구 사항을 충족하지 않습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud Organization 수준에서 중앙집중식 IAM 거버넌스에 관한 것입니다. 요구 사항은 전체 리소스 계층 구조 전반에서 누가 권한을 부여할 수 있는지 통제하고, 모든 folder와 project 전반의 액세스 및 구성 변경에 대한 감사 가능성을 유지하는 것입니다. Google Cloud에서 권한을 부여하는 능력은 주로 organization node에서 IAM policy와 관리 권한을 관리함으로써 제어됩니다. 정답인 이유: Organization Administrator가 가장 적합한 이유는 Organization 리소스에 대한 광범위한 관리 제어를 제공하며, 여기에는 IAM policy를 관리하고 folder와 project 전반에서 관리 액세스를 위임하거나 제한하는 기능이 포함되기 때문입니다. 이를 통해 중앙 보안 팀은 계층 구조 전체에서 누가 권한을 부여할 수 있는지에 대한 통제권을 확보할 수 있습니다. 감사 가능성은 Cloud Audit Logs를 통해 지원되며, 이는 organization 전반의 IAM 및 관리 변경 사항을 자동으로 기록합니다. 주요 특징: Organization 수준의 관리는 상속된 리소스에 중앙에서 적용되므로, 많은 folder와 project로 빠르게 성장한 환경에 적합합니다. 이는 IAM 및 리소스 관리에 대한 중앙집중식 거버넌스를 지원합니다. Cloud Audit Logs는 어떤 admin role이 사용되었는지와 관계없이 액세스 및 구성 활동에 대한 감사 추적을 제공합니다. 흔한 오해: Organization Role Administrator는 'Role'이라는 단어가 포함되어 있어 관련 있어 보이지만, 계층 구조 전반의 IAM policy binding을 폭넓게 제어하는 것이 아니라 custom IAM role을 관리하는 데 초점이 맞춰져 있습니다. Security Reviewer는 읽기 전용이므로 거버넌스를 강제할 수 없습니다. Organization Policy Administrator는 policy constraint를 관리하지만, 권한 부여를 관리하지는 않습니다. 시험 팁: 문제에서 누가 권한을 부여할 수 있는지를 묻는다면, custom role 정의보다 IAM policy 관리부터 먼저 생각하세요. role 관리, policy 관리, 보안 상태 검토를 구분하세요. 시험에서는 읽기 전용 또는 policy 중심의 특화된 role보다 더 광범위하더라도, 실제로 IAM 위임에 대한 중앙 통제를 가능하게 하는 role을 선택하세요.

5
문제 5

Your biomedical analytics team is migrating a bursty batch-processing render farm to a Compute Engine cluster that uses autoscaling Managed Instance Groups (MIGs) across 3 zones and can scale from 8 to 200 VMs in under 5 minutes, and security requires that you retain full control of the boot disk encryption key lifecycle (including quarterly rotation, immediate disablement during incidents, and audit visibility); which boot disk encryption solution should you configure to meet these requirements without slowing rapid instance creation?

CSEK는 디스크를 생성하거나 연결하는 각 API 요청마다 원시 암호화 키 머티리얼을 제공해야 합니다. 버스트성 오토스케일링 MIG(수 분 내 8대에서 200대 VM으로 확장)에서는 키를 안전하게 배포하고 대규모로 주입하는 작업이 운영적으로 복잡하고 오류가 발생하기 쉬우며, 민첩성을 저하시킵니다. 또한 감사 가능성도 Cloud KMS만큼 중앙집중적이지 않습니다. 키를 “제어”하긴 하지만, 빠른 자동화 인스턴스 생성에 가장 적합한 선택은 아닙니다.

Cloud KMS의 CMEK는 중앙집중식 키 라이프사이클 제어(키 버전 및 로테이션 정책을 통한 로테이션), 강력한 사고 대응 통제(향후 decrypt 작업을 차단하기 위한 키 버전 비활성화/파기), 그리고 Cloud KMS 감사 로그를 통한 견고한 감사 가시성을 제공합니다. 또한 Compute Engine 및 MIG 자동화와 깔끔하게 통합되어, 인스턴스 생성 요청마다 키 머티리얼을 전달할 필요 없이 빠른 VM 프로비저닝을 지원합니다.

Google-managed encryption keys(기본 암호화)는 운영 오버헤드가 최소이고 기본 보안 수준은 좋지만, 키 라이프사이클에 대한 완전한 제어를 유지해야 한다는 요구사항을 충족하지 못합니다. 분기별 로테이션 정책을 직접 수행하거나, 사고 시 즉각적인 비활성화를 하거나, 키 사용 결정에 대해 고객이 통제하는 거버넌스 수준을 동일하게 확보할 수 없습니다. 이 옵션은 명시된 보안 요구사항을 충족하지 못합니다.

업로드 전에 파일을 사전 암호화하면 애플리케이션 수준의 입력/출력 데이터에 대해 저장 데이터 보호를 제공할 수 있지만, Compute Engine 인스턴스의 부트 디스크 암호화 키 라이프사이클 제어 요구사항을 충족하지 못합니다. 요구사항은 특히 부트 디스크 암호화 키와 이를 로테이션/비활성화/감사할 수 있는 능력에 관한 것입니다. 이 접근은 파이프라인 복잡성도 증가시키며, VM 부트 디스크 접근에 대한 중앙집중식 “킬 스위치”도 제공하지 못합니다.

문제 분석

핵심 개념: 이 문제는 대규모 Compute Engine 환경에서 Google Cloud 디스크 암호화 선택지를 평가하며, 특히 CSEK(고객 제공 키)와 CMEK(Cloud KMS의 고객 관리 키)의 차이와 이것이 운영 제어, 감사 가능성, 그리고 오토스케일링 Managed Instance Group (MIG) 성능에 어떤 영향을 미치는지를 묻습니다. 정답이 맞는 이유: Cloud KMS의 고객 관리 암호화 키(CMEK)가 제시된 요구사항에 가장 부합합니다. 즉, 키 라이프사이클에 대한 완전한 제어(분기별 로테이션), 사고 시 즉각적인 비활성화, 감사 가시성을 제공하면서도 오토스케일링 MIG에서 빠른 VM 생성이 가능하기 때문입니다. CMEK를 사용하면 부트 디스크가 Cloud KMS에서 사용자가 제어하는 키로 암호화됩니다. 스케줄에 따라 키를 로테이션할 수 있고, 키 버전을 비활성화하거나 파기하여 복호화가 필요한 향후 디스크 연결/VM 부팅 작업을 차단할 수 있으며, Cloud Audit Logs를 통해 키 사용 가시성을 확보할 수 있습니다. 이는 Google Cloud Architecture Framework의 보안 및 컴플라이언스 원칙(중앙집중식 키 관리, 감사 가능한 통제, 운영 복원력)과 일치합니다. 주요 기능 / 구성 / 모범 사례: - 디스크와 동일한 리전에 Cloud KMS key ring/keys를 사용하고, Compute Engine service agent에 키에 대한 필요한 KMS 권한(예: cloudkms.cryptoKeyEncrypterDecrypter)을 부여합니다. - 로테이션 정책(예: 90일)을 활성화하고 키 버전을 관리합니다. 로테이션은 신규 encrypt 작업과 재암호화 워크플로에 영향을 주며, 재암호화를 수행하지 않는 한 기존 디스크가 자동으로 재암호화되는 것은 아니라는 점을 이해해야 합니다. - 사고 대응: 키 버전을 비활성화하면 신규 decrypt 작업을 즉시 차단할 수 있으며(복호화가 필요한 신규 인스턴스 부팅/연결에 영향), 강력한 “킬 스위치”를 제공합니다. - 감사: Cloud KMS는 encrypt/decrypt 및 키 접근에 대한 상세한 감사 로그를 생성하여 컴플라이언스 증빙을 지원합니다. - 성능: CMEK는 클라우드 규모의 자동화를 위해 설계되었습니다. MIG 인스턴스 생성은 KMS 통합이 Google 인프라에서 처리되므로 빠르게 유지되며, 인스턴스별로 키 머티리얼을 주입할 필요가 없습니다. 흔한 오해: CSEK는 키를 직접 제공하므로 “더 많은 제어”처럼 보일 수 있지만, 모든 create/attach 호출에 대해 안전한 배포를 수행해야 하는 등 운영 부담이 크게 사용자에게 전가되며, 버스트성 오토스케일링에는 적합하지 않습니다. Google-managed keys는 가장 단순하지만 “완전한 제어”와 “즉각적인 비활성화” 요구사항을 충족하지 못합니다. 파일을 사전 암호화하는 방식은 부트 디스크 암호화나 VM 라이프사이클 제어 문제를 해결하지 못합니다. 시험 팁: Compute Engine 디스크의 경우: 중앙집중식 라이프사이클 관리, 감사 로그, 그리고 대규모 환경에서 빠르게 접근을 비활성화할 수 있는 기능이 필요하면 CMEK(Cloud KMS)를 선택합니다. 요청마다 원시 키 머티리얼을 제공해야 하고 상당한 자동화 복잡성을 감수할 수 있을 때만 CSEK를 선택하는데, 이는 오토스케일링 MIG 시나리오에서는 드문 경우입니다.

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

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

6
문제 6

You are designing the key management strategy for a U.S.-based fintech launching a payment tokenization API on Google Cloud. Requirements:

  • Rotate the root (key-encryption) key at least every 45 days via a managed schedule.
  • The system that stores the root key must be FIPS 140-2 Level 3 validated.
  • Keep the root key within multiple regions in the United States for redundancy (US-only residency). Which option best satisfies these requirements?

Cloud Key Management Service(소프트웨어 기반 CMEK)를 사용하는 customer-managed encryption keys는 IAM으로 제어되는 키 사용과 자동화된 rotation schedules를 지원합니다. 그러나 소프트웨어 기반 Cloud KMS는 FIPS 140-2 Level 3 검증을 받은 키 저장/연산이라는 명시적 요구사항을 충족하지 못합니다. multi-region(예: "us")일 수 있고 일정에 따라 rotation할 수는 있지만, 결정적 제약 조건인 Level 3 HSM 요구사항을 만족하지 못합니다.

Cloud HSM을 사용하는 customer-managed encryption keys가 최적의 선택입니다. Cloud HSM은 키 material과 암호화 연산에 대해 FIPS 140-2 Level 3 검증을 받은 하드웨어 보호를 제공하기 때문입니다. 또한 Cloud KMS를 통해 관리되므로 자동 rotation(예: 45일마다)을 구성할 수 있습니다. 키를 US multi-region location("us")에 생성하면 미국 내 residency를 유지하면서 multi-region redundancy를 달성할 수 있습니다.

Customer-supplied encryption keys(CSEK)는 사용자가 키를 직접 생성, 저장, 배포, rotation해야 합니다. 이는 관리형 rotation schedule 요구사항과 충돌합니다. 또한 CSEK는 루트 키를 저장하는 시스템이 Google 측에서 FIPS 140-2 Level 3 검증을 받는다는 보장을 제공하지 않습니다. 키 material이 요청 시점에 제공되며, 규정 준수 저장 및 운영 통제에 대한 부담은 사용자에게 있기 때문입니다.

Google-managed encryption keys는 운영 오버헤드가 가장 적지만, rotation 빈도(확실히 45일 일정 보장)는 사용자가 제어할 수 없고, 특정 루트/KEK가 사용자 통제 하에 FIPS 140-2 Level 3 검증 시스템에 저장된다고 주장할 수도 없습니다. Google-managed encryption은 많은 워크로드에서 안전하고 규정을 준수하지만, customer-managed 및 HSM Level 3 루트 키 통제라는 명시적 fintech 요구사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 규제 수준의 보호가 필요한 key-encryption key(KEK/루트 키)에 대해 올바른 키 관리 서비스를 선택하는지를 평가합니다: FIPS 140-2 Level 3 검증, 자동화된 rotation, 그리고 미국 내에서만의 multi-region redundancy. Google Cloud에서 핵심 선택지는 소프트웨어 기반 Cloud KMS(일반적으로 FIPS 140-2 Level 1/2 경계)와 하드웨어 기반 Cloud HSM(FIPS 140-2 Level 3) 사이입니다. 정답이 맞는 이유: Cloud HSM은 고객 관리 키(customer-managed keys)를 제공하며, 암호화 연산과 키 material이 FIPS 140-2 Level 3 검증을 받은 HSM에 의해 보호됩니다. 이는 “루트 키를 저장하는 시스템은 FIPS 140-2 Level 3 검증을 받아야 한다”는 요구사항을 직접 충족합니다. Cloud HSM 키는 Cloud KMS APIs를 통해 생성 및 관리되므로, scheduled rotation 같은 관리형 lifecycle 기능도 그대로 사용할 수 있습니다. 미국 내에서만의 residency와 redundancy를 위해, US multi-region location(예: "us")에 키를 생성하면 키 material이 여러 US regions에 복제되어 data residency 및 가용성 목표에 부합합니다. 주요 기능 / 구성: - key ring과 key를 US multi-region location("us")에 생성하여 키 material을 미국 내에 유지하면서 multi-region redundancy를 제공합니다. - KEK/루트 키에 대해 Cloud HSM 보호 키(protection level: HSM)를 사용합니다. - rotation period(45일 이하)를 구성하고 next rotation time을 설정합니다. Cloud KMS가 일정에 따라 rotation을 관리합니다. - IAM으로 least privilege를 적용(예: key admins와 key users 간 separation of duties)하고, 키 접근/관리용 Cloud Audit Logs를 활성화합니다. 흔한 오해: 많은 사람들이 “Cloud KMS를 사용하는 CMEK”가 관리형 키 서비스이므로 자동으로 Level 3를 충족한다고 가정합니다. 하지만 Cloud KMS 소프트웨어 기반 키는 FIPS 140-2 Level 3 HSM 보호를 제공하지 않습니다. 또 다른 함정은 키를 “통제”하기 위해 customer-supplied keys(CSEK)를 선택하는 것입니다. CSEK는 rotation과 secure storage를 사용자에게 전가하며, 본질적으로 HSM Level 3 검증을 제공하지 않습니다. 시험 팁: - 문제가 FIPS 140-2 Level 3를 명시적으로 요구하면 Cloud HSM(또는 규정을 충족하는 HSM을 사용하는 External Key Manager를 고려하지만, 여기서는 선택지가 아님)을 떠올리세요. - “미국 내 여러 regions”는 단일 region이 아니라 "us" 같은 multi-region locations를 찾으세요. - “관리형 rotation schedule”은 CSEK가 아니라 Cloud KMS/Cloud HSM rotation 기능을 의미합니다. - 요구사항을 다음에 매핑하세요: protection level(HSM), location(multi-region US), lifecycle(rotation policy).

7
문제 7

You are the security lead for a fintech company with PCI DSS scope operating across 3 Google Cloud projects under a single organization. An external assessor requests downloadable evidence (CSV or JSON) listing who currently has which permissions to all 58 Cloud Storage buckets and 12 BigQuery datasets in the prod folder, including access granted via groups and inherited roles, as of today; you must produce this access review without changing any policies and be able to filter by principals and permissions for the audit. Which Google Cloud tool should you use?

Policy Troubleshooter는 “principal P가 지금 resource R에서 permission Z를 갖는가?” 같은 표적화된 질문에 답하고, 어떤 binding이 액세스를 부여/거부하는지에 대한 설명 경로를 제공합니다. 액세스 이슈 디버깅에는 매우 유용하지만, 감사용 액세스 리뷰를 위해 여러 Cloud Storage buckets 및 BigQuery datasets 전반의 모든 principals와 permissions에 대한 포괄적이고 내보내기 가능한 인벤토리를 생성하도록 의도된 도구는 아닙니다.

Policy Analyzer는 액세스 리뷰와 컴플라이언스 리포팅을 위해 구축되었습니다. IAM policies를 분석하여 범위(org/folder/project) 전반에서 누가 무엇에 액세스할 수 있는지(google Groups를 통한 액세스 및 상속된 roles 포함)를 판단합니다. principal, role/permission, resource 기준 필터링을 지원하며, 결과를 내보내기/다운로드(CSV/JSON)할 수 있어 정책을 변경하지 않고도 감사자 제출용 증적을 생성하는 데 가장 적합한 도구입니다.

IAM Recommender(IAM Recommender / Policy Intelligence recommendations)는 관측된 사용량을 기반으로 과도하게 넓은 permissions를 식별하고 role 축소를 제안합니다. 최소 권한 및 하드닝에는 유용하지만, 리소스 전반의 유효 액세스에 대한 시점 목록을 생성하는 리포팅 도구는 아닙니다. 또한 암묵적으로 정책 변경을 유도하는데, 문제에서 명시적으로 정책을 변경하면 안 된다고 했습니다.

Policy Simulator는 적용 전에 제안된 IAM policy 변경의 영향(“이 binding을 추가/제거하면 어떻게 되는가?”)을 테스트하는 데 사용됩니다. 변경 관리와 장애 예방에 유용하지만, 현재 상태 증적을 위한 액세스 리뷰/내보내기 메커니즘으로 주로 사용되지는 않습니다. 이 문제는 정책을 변경하지 않고 기존 유효 permissions를 리포팅해야 하며, 이는 Policy Analyzer와 더 잘 부합합니다.

문제 분석

핵심 개념: 이 문제는 컴플라이언스 증적을 위한 IAM 가시성을 테스트합니다. 즉, 정책을 수정하지 않고도 감사자에게 제출할 수 있도록 내보내기 가능한 형태로, 여러 리소스 전반에서 유효 액세스(그룹 멤버십 및 상속 포함)를 열거하는 액세스 리뷰를 생성하는 것입니다. Google Cloud에서는 IAM Policy Analyzer(Policy Intelligence의 일부)가 이를 해결하며, 범위(project/folder/org) 전반에서 누가 무엇에 액세스할 수 있는지 분석하고 결과를 필터링 및 내보내기할 수 있습니다. 정답이 맞는 이유: Policy Analyzer는 액세스 리뷰와 컴플라이언스 리포팅을 위해 설계되었습니다. Cloud Storage buckets 및 BigQuery datasets 같은 리소스에 대해, Google Groups를 통해 부여된 액세스와 리소스 계층(organization/folder/project) 상위에서 상속된 roles를 포함하여 IAM policies를 평가함으로써 “누가 어떤 액세스 권한을 갖는지”를 답할 수 있습니다. principal, role/permission, resource 기준으로 쿼리할 수 있으며, PCI DSS 감사에 대한 시점 증적(point-in-time evidence)으로 적합한 다운로드 가능한 출력(CSV/JSON)을 생성할 수 있습니다. 중요한 점은 읽기 전용 분석이라는 것으로, IAM policies 변경이 필요하지 않습니다. 주요 기능: - Organization/folder/project 범위 지정: 하나의 org 아래 여러 projects와 “prod” folder를 운영하는 핀테크에 이상적입니다. - 유효 액세스 분석: 직접 bindings, group에서 파생된 액세스, 상속된 bindings를 포함합니다. - 필터링: 감사자는 principal(user/service account/group) 및 permission/role 기준 필터링을 자주 요구하며, Policy Analyzer는 이러한 차원을 지원합니다. - 내보내기 가능한 증적: 결과를 내보내기/다운로드(CSV/JSON)하여 감사 산출물로 사용할 수 있습니다. - Google Cloud Architecture Framework(Security, Governance, Risk & Compliance)와 정렬: 운영 중단 없이 지속적 가시성, 최소 권한 검증, 감사 가능성을 제공합니다. 흔한 오해: Policy Troubleshooter는 둘 다 Policy Intelligence에 속해 있어 Policy Analyzer와 자주 혼동됩니다. Troubleshooter는 단일 “principal X가 resource Y에 액세스할 수 있는가” 질문에 답하고 그 이유를 설명하는 데 최적화되어 있으며, 수십 개의 buckets/datasets 전반에 대한 포괄적 인벤토리를 생성하는 용도가 아닙니다. IAM Recommender는 최소 권한 변경을 제안(정책 변경을 시사)하고, Policy Simulator는 가상의 정책 변경을 테스트하는 용도이므로, 둘 다 현재 상태 증적을 생성하는 데 적합하지 않습니다. 시험 팁: 문제에서 “downloadable evidence”, “access review”, “who currently has which permissions”, “including groups and inherited roles”, “no policy changes”를 강조하면 Policy Analyzer를 떠올리세요. Troubleshooter는 단발성 액세스 디버깅, Simulator는 what-if 테스트, Recommender는 권한 최적화(rightsizing)에 사용합니다. 또한 컴플라이언스(PCI DSS) 맥락과 folder/org 범위에서 동작해야 한다는 요구는 Policy Analyzer를 강하게 시사합니다.

8
문제 8

Your company is onboarding a construction subcontractor for a 4-month engagement; the subcontractor uses an external SAML 2.0/OIDC IdP (e.g., Okta) for its 180 users, and you must provide them least-privilege access to two Google Cloud projects via both the Google Cloud Console and gcloud while strictly avoiding creation or synchronization of any subcontractor identities in Cloud Identity/Google Workspace, preventing any password storage/replication in your environment, and allowing the subcontractor to retain full user lifecycle control; what is the most secure way to enable SSO under these constraints?

오답입니다. Google Cloud Directory Sync는 identity를 Cloud Identity/Google Workspace로 가져오거나 동기화하므로, 하청업체 identity의 생성 또는 동기화를 엄격히 피해야 한다는 요구사항을 위반합니다. 또한 라이프사이클 관리를 사용자 환경으로 가져오거나(또는 최소한 중복) 운영 오버헤드와 위험을 증가시킵니다. SSO를 가능하게 할 수는 있지만, 명시된 제약을 충족하지 못하며 최소-identity 접근 방식도 아닙니다.

오답입니다. 커스텀 authentication/provisioning 서비스를 구축하는 것은 불필요하고 위험합니다. 공격 표면을 늘리고 지속적인 유지보수가 필요하며, 일반적으로 어떤 형태로든 account provisioning 또는 token brokering으로 이어져 “identity 생성 없음” 및 “password 복제 없음” 의도를 위반할 수 있습니다. 또한 Google 권장 패턴에서 벗어나며, 시험에서 가장 안전한 접근으로 간주되기 어렵습니다.

정답입니다. Workforce Identity Federation은 외부 SAML/OIDC IdP를 신뢰하고 Cloud Identity/Workspace 사용자를 생성하거나 password를 저장하지 않고도 federated principal에 IAM role을 부여할 수 있습니다. Cloud Console과 gcloud 모두에서 단기 credential을 사용하며, 하청업체는 자신의 IdP에서 전체 라이프사이클 제어를 유지합니다. IAM binding은 두 프로젝트 전반에 최소 권한을 위해 group/attribute에 적용할 수 있습니다.

오답입니다. 개별 Google account를 생성하고 password를 직접 동기화하는 것은 환경 내 password 저장/복제를 방지해야 한다는 요구사항을 정면으로 위반하며 credential 탈취 위험을 증가시킵니다. 또한 관리해야 하는 로컬 identity를 만들어 하청업체의 전체 라이프사이클 제어를 약화시킵니다. 이는 단기 token을 사용하는 federation에 비해 anti-pattern입니다.

문제 분석

핵심 개념: 이 문제는 로컬 identity를 생성하지 않고 외부 사용자를 위한 identity federation, 특히 Cloud Console 및 gcloud 액세스를 위한 Google Cloud Workforce Identity Federation (WIF)을 테스트합니다. 이는 중앙 집중식 identity, 최소 권한, credential 위험 감소라는 Google Cloud Architecture Framework 보안 원칙과 일치합니다. 정답이 맞는 이유: Workforce Identity Federation을 사용하면 외부 SAML 2.0 또는 OIDC IdP(예: Okta)를 신뢰하고 사용자가 Google Cloud 리소스에 액세스하기 위한 단기 Google credential을 획득하도록 할 수 있습니다. 핵심은 하청업체 사용자를 Cloud Identity/Google Workspace에 생성하거나 동기화하지 않으며, 환경 내에 password를 저장하거나 복제하지 않는다는 점입니다. 하청업체는 자신의 IdP에서 전체 라이프사이클 제어(joiner/mover/leaver)를 유지하며, 해당 IdP에서 사용자가 비활성화되면 federation은 즉시 새로운 token 발급을 차단합니다. 이후 프로젝트 수준에서 federated principal(Workforce pool subject/group/attribute)에 직접 IAM role을 부여하여 두 프로젝트 전반에 최소 권한을 적용합니다. 주요 기능 / 구성 참고 사항: 1) 하청업체 IdP(SAML 또는 OIDC)를 신뢰하는 workforce identity pool 및 provider를 생성하고 attribute mapping을 구성합니다(예: IdP group을 google.subject 또는 custom attribute로 매핑). 2) principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/… 같은 IAM principal identifier 또는 attribute 기반 액세스를 사용하여 필요한 사용자/group에만 role을 바인딩합니다. 3) 사용자는 workforce federation sign-in을 통해 Cloud Console에 액세스하고, workforce identity federation login flow를 통해 gcloud를 사용하며, 장기 password/key 대신 단기 token을 받습니다. 4) predefined role, 필요 시 condition(IAM Conditions), 프로젝트별 개별 binding으로 최소 권한을 적용합니다. 흔한 오해: 많은 사람들이 SSO에 Cloud Identity/Workspace account가 필요하다고 생각합니다. 일부 레거시 패턴에서는 맞지만, WIF는 로컬 account provisioning과 password 처리를 피하도록 특별히 설계되었습니다. 또 다른 오해는 사람의 액세스에 service account가 필요하다는 것인데, 외부 workforce 사용자에게는 workforce federation이 올바른 패턴입니다. 시험 팁: 요구사항에 다음이 포함되면: 사용자 provisioning/sync 없음, password 복제 없음, 외부 IdP가 source of truth 유지, console + gcloud를 통한 액세스라면 “Workforce Identity Federation”을 떠올리세요. 사용자가 다른 Google Cloud organization(파트너) 소속이라면 cross-org IAM을 고려할 수 있지만, SAML/OIDC 기반의 비-Google identity라면 WIF가 안전하고 현대적인 접근 방식입니다.

9
문제 9

You are investigating 403 access denied errors when Compute Engine instances in a service project (svc-proj-200) attached to a Shared VPC in a host project (host-proj-100) attempt to read objects from a Cloud Storage bucket (gs://org-logs-bucket) located in a data project (data-proj-300). The data project is protected by a VPC Service Controls service perimeter named perimeter-data that currently includes only data-proj-300 and restricts Cloud Storage and BigQuery. The instances have roles/storage.objectViewer, the subnet has Private Google Access enabled, and egress firewall rules allow Google APIs. You must resolve the errors without weakening the perimeter's protections. What should you do?

Shared VPC host project(host-proj-100)만 추가하는 것은 핵심 VPC-SC check를 해결하지 못합니다. VPC-SC는 subnet을 제공하는 network host project가 아니라, API caller(일반적으로 workload와 service account가 사용되는 service project)와 연관된 프로젝트를 평가합니다. VM은 여전히 svc-proj-200 컨텍스트에서 실행되므로, 요청은 계속 perimeter 밖에서 오는 것으로 보이고 거부됩니다.

정답. svc-proj-200을 perimeter-data에 추가하면 Compute Engine workload의 Cloud Storage에 대한 API call이 intra-perimeter로 간주됩니다. 이렇게 하면 perimeter의 보호를 유지하면서 403을 해결할 수 있는데, 접근이 perimeter 내부 프로젝트로 계속 제한되기 때문입니다. 이는 VPC-SC의 설계(신뢰할 수 있는 프로젝트/workload가 perimeter 내부에서 보호된 서비스에 접근하도록 허용하되 광범위한 예외를 만들지 않음)와 일치합니다.

host와 service project를 포함하는 새로운 별도 perimeter를 만드는 것은 perimeter-data의 리소스에 대한 접근을 자동으로 부여하지 않습니다. 두 개의 분리된 perimeter는 기본적으로 서로 격리되어 있으며, bridging 또는 다른 예외를 도입하지 않는 한 그 사이의 접근은 여전히 차단됩니다. 이는 복잡성과 운영 오버헤드를 늘리고, 기존 perimeter로 보호되는 bucket 접근 문제를 직접 해결하지도 못합니다.

Perimeter bridge는 두 개의 서로 다른 service perimeter(예: perimeter-A와 perimeter-B) 간의 통제된 통신을 허용하는 데 사용됩니다. 여기서는 svc-proj-200이 어떤 perimeter에도 속하지 않으므로 bridging은 “outside-to-inside” 접근에 적용되지 않습니다. 설령 svc-proj-200을 위한 다른 perimeter를 만든다 해도, bridging은 perimeter 간 신뢰 경계를 확장하는 것이며, 합법적인 caller project를 기존 perimeter에 추가하는 것보다 일반적으로 더 광범위한 변경입니다.

문제 분석

핵심 개념: 이 문제는 VPC Service Controls (VPC-SC)의 service perimeter와, Cloud Storage 같은 Google-managed service에 대해 데이터 유출(data exfiltration) 경계를 어떻게 강제하는지를 테스트합니다. VPC-SC는 “project of the caller”(credentials/access token에 연결된 프로젝트)와, 그 프로젝트가 보호되는 리소스와 동일한 perimeter 안에 있는지를 평가합니다. 정답이 맞는 이유: Cloud Storage bucket은 perimeter-data 안에 있는 data-proj-300에 있습니다. Compute Engine VM은 svc-proj-200에서 실행되며, 서비스 프로젝트 컨텍스트에 속한 identity(VM service account 또는 attached service account)를 사용해 bucket에 접근합니다. 네트워킹이 host-proj-100의 Shared VPC를 사용하고 Private Google Access가 활성화되어 있더라도, VPC-SC는 네트워크 방화벽이 아니라 API 레벨 경계입니다. svc-proj-200이 perimeter 밖에 있으면, perimeter 안의 Cloud Storage로 가는 요청은 perimeter 밖에서 오는 것으로 처리되어, 명시적인 perimeter 예외가 적용되지 않는 한 거부(403)됩니다. 보호를 약화시키지 않고 접근을 해결하려면, caller project와 보호된 bucket project가 동일 perimeter 안에 있도록 기존 perimeter에 svc-proj-200을 추가해야 합니다. 주요 기능 / Best Practices: - Service perimeter는 perimeter membership과 Access Context Manager 정책을 기반으로 접근을 제한하여 지원되는 서비스(여기서는 Cloud Storage와 BigQuery)를 보호합니다. - Shared VPC host project membership은 API access 결정에서 service project를 자동으로 perimeter “내부”로 만들지 않습니다. - Private Google Access와 egress firewall rule은 Google API로의 연결성만 보장할 뿐, VPC-SC perimeter check를 충족하지는 않습니다. - 동일 perimeter에 service project를 추가하면 경계를 유지하면서 합법적인 intra-perimeter access를 활성화할 수 있습니다. 흔한 오해: 흔한 함정은 Shared VPC host project가 API access에 대한 보안 경계를 제어한다고 가정하는 것(option A)입니다. 또 다른 오해는 모든 cross-project access에 perimeter bridge가 필요하다고 생각하는 것(option D)인데, bridge는 perimeter 밖에서 perimeter 안으로의 접근을 허용하기 위한 것이 아니라, 두 개의 분리된 perimeter를 연결하기 위한 것입니다. Exam Tips: VPC-SC와 보호된 리소스에서 403이 보이면, (1) 어떤 프로젝트가 리소스를 보유하는지, (2) caller identity가 어떤 프로젝트와 연관되는지, (3) 둘 다 동일 perimeter에 있는지를 확인하세요. 동일 perimeter가 아니라면, 일반적인 해결책은 IAM, route, firewall rule을 바꾸는 것이 아니라 caller project를 perimeter에 추가(또는 perimeter 재설계)하는 것입니다.

10
문제 10

You administer 8 production projects under a parent folder named prod-services in organization org-123. Compliance requires centralizing all audit and application logs from those projects with a 400-day retention period. Analysts must query these logs using Logs Explorer from a dedicated project named sec-logging without being granted direct access to the production projects. What should you do?

Cloud Monitoring workspace는 프로젝트 전반의 metrics/uptime/SLO 형태의 관측 가능성을 위한 것이지, 커스텀 retention을 포함한 Cloud Logging 데이터를 중앙화하기 위한 것이 아닙니다. 프로젝트를 workspace에 추가해도 로그가 단일 log bucket으로 라우팅되지 않고, 400일 retention을 중앙에서 강제하지도 못하며, 분석가가 프로덕션 프로젝트 접근 없이 로그를 쿼리해야 한다는 요구사항도 해결하지 못합니다. 이는 모니터링 가시성에 대한 해결책이지, 컴플라이언스에 맞는 로그 집계 및 retention이 아닙니다.

조직 수준에서 쿼리하면 광범위한 가시성을 제공할 수 있지만, 일반적으로 분석가에게 프로덕션 프로젝트 전반(또는 최소한 org/folder 범위)에 걸쳐 로그를 볼 수 있는 권한을 부여해야 하므로, 프로덕션 프로젝트에 대한 직접 접근을 피하라는 요구사항을 위반합니다. 또한 중앙 retention을 명시적으로 구현하지도 않습니다. 별도로 구성하지 않으면 retention은 프로젝트별로 남게 되어 컴플라이언스를 일관되게 강제하기가 더 어려워집니다.

Cloud Storage bucket으로 export하는 aggregated sink는 장기 retention은 충족할 수 있지만, Cloud Storage export는 Logs Explorer로 쿼리할 수 없습니다. 분석가는 해당 로그를 분석하기 위해 다른 도구(BigQuery, Cloud Storage + 외부 처리, 또는 SIEM ingestion)를 사용해야 합니다. 이 선택지는 분석가가 Logs Explorer를 사용해 쿼리해야 한다는 명시적 요구사항을 충족하지 못하며, 구조화된 로그 분석과 접근 패턴도 더 복잡하게 만듭니다.

이것이 올바른 패턴입니다: prod-services 폴더에 aggregated sink를 생성하여 모든 하위 프로젝트 로그가 자동으로 라우팅되게 하고, 이를 sec-logging의 중앙 Cloud Logging log bucket으로 전송합니다. 컴플라이언스를 충족하기 위해 bucket retention을 400일로 구성합니다. 분석가에게는 대상 bucket/프로젝트에 대한 접근 권한을 부여하여 프로덕션 프로젝트에 어떤 IAM 바인딩도 없이 Logs Explorer로 중앙 로그를 쿼리할 수 있게 함으로써, 최소 권한과 직무 분리를 만족합니다.

문제 분석

핵심 개념: 이 문제는 Cloud Logging을 사용한 중앙집중식 로깅 아키텍처를 평가합니다: aggregated sink(폴더/조직 범위), log bucket을 통한 중앙 Log Analytics, retention 구성, 그리고 소스 프로젝트에 대한 접근 권한을 부여하지 않고도 분석가가 로그를 쿼리할 수 있게 하는 IAM. 정답인 이유: prod-services 폴더에 aggregated sink를 만들면 프로젝트별 sink를 만들 필요 없이 모든 하위 프로젝트(8개의 프로덕션 프로젝트)에서 로그를 수집할 수 있습니다. 이를 sec-logging 프로젝트의 중앙 log bucket으로 라우팅하면 로그를 저장하고 분석할 단일 위치가 생깁니다. log bucket retention을 400일로 설정하면 컴플라이언스 요구사항을 충족합니다. 분석가에게는 (예: 대상 bucket/프로젝트 범위에서 roles/logging.viewer 또는 roles/logging.viewAccessor, 그리고 구성에 따라 선택적으로 Log Analytics 관련 role) 권한을 부여하여 중앙 bucket에 대해 Logs Explorer로 쿼리할 수 있게 하되, 프로덕션 프로젝트에는 어떤 IAM 바인딩도 필요하지 않습니다. 이는 요구사항(중앙집중식 audit + application logs, 장기 retention, 프로덕션과 분리된 쿼리 접근)을 충족합니다. 주요 기능 / 구성: - 폴더 범위(prod-services)의 aggregated sink로 모든 하위 프로젝트에서 수집. - 대상: sec-logging의 Cloud Logging log bucket(단순 storage export가 아님). - bucket retention을 400일로 구성(bucket-level retention이 Cloud Logging에서 로그 retention을 제어하는 올바른 방식). - 분석가에게 대상(sec-logging 프로젝트 및/또는 특정 log bucket)에 최소 권한을 부여하여 Logs Explorer로 쿼리 가능하게 함. - 필요에 따라 Admin Activity, Data Access(요구되는 경우), application logs 포함을 보장; 일부 audit log 유형은 특별 고려사항이 있을 수 있으나, 중앙 bucket으로 라우팅하는 것이 표준 접근 방식. 흔한 오해: - Monitoring workspace를 Logging 중앙화와 혼동: Monitoring workspace는 로그 저장/retention을 중앙화하지 않습니다. - 조직 수준 Logs Explorer 접근이면 충분하다고 가정: 보통 프로덕션 프로젝트 전반에 대한 광범위한 권한이 필요해 격리 요구사항을 위반합니다. - retention을 위해 Cloud Storage로 export: Cloud Storage export는 Logs Explorer에서 쿼리할 수 없고 분석을 다른 도구로 옮기게 됩니다. 시험 팁: “로그 중앙화”, “장기 retention”, “소스 프로젝트 접근 없이 Logs Explorer로 쿼리”를 보면 다음을 떠올리세요: aggregated sink(폴더/조직) -> retention이 구성된 중앙 log bucket -> 대상에만 IAM 부여. 이는 Google Cloud Architecture Framework의 중앙 거버넌스, 최소 권한, 컴플라이언스용 감사 가능성 원칙과 일치합니다.

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

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