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

Practice Test #3

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

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 요구사항을 유지하는 선택지를 찾으세요.

2
문제 2
(2개 선택)

Your company operates eight autonomous product studios, each with approximately 3,000 users and contractors, and about 1,200 Google Cloud projects distributed across those studios. You must delegate access control administration with the following requirements: ✑ Each studio must administer access only for its own projects and not see or change other studios' projects. ✑ Access must be manageable at scale across hundreds of projects per studio. ✑ When a user transfers to a different studio or leaves the company, their access must be removed within 1 hour. ✑ The authoritative source for users and groups is the on-premises Active Directory, and Google accounts are in Cloud Identity. What should you do? (Choose two.)

VPC Service Controls는 데이터 유출 위험을 줄이고 perimeter 외부에서 Google-managed services로의 액세스를 제어하기 위해 service perimeters를 생성합니다. 이는 IAM 관리에 대한 확장 가능한 위임 모델을 제공하지 않으며, 권한이 있는 경우 스튜디오 관리자가 다른 스튜디오 프로젝트의 IAM을 조회/변경하는 것을 본질적으로 막지도 못합니다. 이는 조직 액세스 관리가 아니라 경계 보호를 다룹니다.

스튜디오별로 folder를 생성하고 해당 스튜디오의 프로젝트를 그 아래에 배치하는 것은 관리 위임을 위한 표준적인 Google Cloud 접근 방식입니다. Folder 수준 IAM policies는 모든 하위 프로젝트로 상속되어 수백 개의 프로젝트에 일관된 액세스를 제공할 수 있습니다. 또한 스튜디오 관리자에게 자신의 folder에 대해서만 권한(예: Project IAM Admin)을 부여하여, 다른 스튜디오의 folders 및 프로젝트에 대한 가시성/제어를 방지할 수 있습니다.

Cloud Identity Organizational Units (OUs)는 Cloud Identity/Google Workspace 내에서 ID 및 디바이스 정책을 적용하는 데 사용됩니다. Google Cloud IAM은 Cloud Identity OUs에 principals로 직접 IAM policies를 할당하거나, 범위 지정 메커니즘으로 사용하는 것을 지원하지 않습니다. Google Cloud의 액세스 제어는 리소스 계층(org/folder/project)으로 범위가 정해지고, users, groups, service accounts 같은 principals에 부여됩니다.

프로젝트 네이밍 규칙을 IAM Conditions와 함께 사용하는 방식은 취약하고 대규모 운영이 어렵습니다. Conditions는 요청 속성을 평가하며 유지보수가 복잡해질 수 있고, 네이밍 규칙은 보안 경계가 아닙니다(프로젝트 이름이 변경되거나 잘못 생성될 수 있음). 또한 이는 위임된 관리나 스튜디오 간 가시성 방지를 자연스럽게 지원하지 못하며, folders 및 group-based IAM에 비해 안티패턴입니다.

Google Cloud Directory Sync (GCDS)는 온프레미스 Active Directory의 사용자 및 그룹 멤버십을 Cloud Identity로 동기화하며, AD가 authoritative일 때 매우 중요합니다. Google Cloud IAM bindings를 Cloud Identity groups에 연결하면, AD group 멤버십 변경(이동/퇴사)이 전파되어 액세스가 빠르게 제거됩니다. 동기화가 적절히 스케줄링되면 1시간 이내 권한 해제 요구사항을 충족할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud 리소스 계층(organization/folders/projects)을 사용한 확장 가능한 IAM 위임과, 온프레미스 Active Directory와 통합된 Cloud Identity를 사용한 중앙 집중식 ID 라이프사이클 관리를 평가합니다. 정답이 맞는 이유: 각 스튜디오가 자신의 프로젝트에 대해서만 액세스를 관리하고 이를 대규모로 수행할 수 있도록 하려면, 프로젝트를 리소스 계층에 맞춰 정렬해야 합니다. 즉, 스튜디오별로 folder를 하나씩 만들고 해당 스튜디오의 프로젝트를 그 아래로 이동합니다. 그런 다음 folder 수준에서 스튜디오별 Google Groups에 IAM roles를 부여합니다. Folder 수준 IAM policies는 하위의 모든 프로젝트로 상속되므로, 프로젝트별로 관리하지 않고도 수백 개의 프로젝트에 일관된 액세스를 적용할 수 있습니다. 또한 AD가 권한의 기준(authoritative source)이고 “1시간 이내 액세스 제거” 요구사항을 충족하려면, Google Cloud Directory Sync (GCDS)를 사용해 AD의 사용자 및 그룹 멤버십을 Cloud Identity로 동기화해야 합니다. 사용자가 스튜디오를 이동하거나 퇴사할 때 관련 AD groups에서 제거(또는 계정 비활성화)하면, 변경 사항이 Cloud Identity로 전파되고 그 그룹에 연결된 액세스가 제거됩니다. 주요 기능 / 모범 사례: - 관리 경계와 정책 상속을 위해 Cloud Resource Manager 계층(Org → Folders → Projects)을 사용합니다. - 권한 부여 단위로 Google Groups를 사용하고, 감사 가능성과 확장성을 위해 개별 사용자 대신 그룹에 roles를 바인딩합니다. - 거의 실시간에 가까운 동기화를 위해 GCDS를 사용(주기 설정 가능)하고, 빠른 권한 회수를 위해 Cloud Identity/Google Workspace 계정 suspension과 함께 사용합니다. - 선택적으로 organization policies 및 최소 권한(least-privilege) roles를 결합해 영향 범위(blast radius)를 줄입니다. 흔한 오해: VPC Service Controls는 종종 IAM 위임 도구로 오해되지만, 주로 데이터 유출(data exfiltration)/경계 제어(boundary control) 메커니즘이며, 단독으로는 프로젝트 간 가시성이나 IAM 변경을 막지 못합니다. Cloud Identity OUs는 ID/디바이스 정책 관리를 위한 것이지, Google Cloud IAM bindings의 대상이 아닙니다. 프로젝트 이름 기반 IAM Conditions는 취약하고 진정한 관리 경계가 아닙니다. 시험 팁: “수백 개의 프로젝트”와 “사업부 단위로 관리자 위임”이 보이면 “folders + group-based IAM”을 떠올리세요. “권한의 기준이 AD”이고 “빠른 권한 해제”가 보이면 “GCDS (및/또는 federation) + AD에서의 group 라이프사이클”을 떠올리되, 수동 IAM 편집이 아니라 그룹 멤버십에 의해 액세스가 구동되도록 해야 합니다.

3
문제 3

A team operates 60 Compute Engine VMs in a managed instance group that must securely read database passwords and third‑party API tokens both at boot and on demand; security policy requires centrally stored secrets with per‑secret IAM controls, access over TLS, versioning and rotation every 90 days, audit logs for every read, optional CMEK support, and a prohibition on storing secrets in instance metadata or guest attributes—what should you recommend?

Cloud KMS는 cryptographic keys를 관리하고 encrypt/decrypt/sign operations를 수행하기 위한 서비스입니다. IAM, audit logs, 그리고 keys의 rotation을 지원하지만, passwords와 API tokens를 위한 full secret storage system( secret-version retrieval semantics 포함)은 아닙니다. envelope-encryption 솔루션을 구축할 수는 있지만, 운영 복잡성이 증가하며 Secret Manager처럼 “per-secret IAM controls가 있는 centrally stored secrets”와 간단하고 감사 가능한 reads를 기본적으로 충족하지 못합니다.

Compute Engine guest attributes는 VM이 조회할 수 있는 소량의 데이터를 저장할 수 있지만, 민감한 secrets governance를 목적으로 설계되지 않았습니다. robust per-secret IAM, built-in versioning/rotation workflows, 그리고 표준화된 secret access audit patterns 같은 전용 secret lifecycle 기능이 부족합니다. 문제에서 guest attributes에 secrets를 저장하는 것을 명시적으로 금지하므로, 기술적 가능성과 무관하게 이 옵션은 비준수입니다.

Compute Engine custom metadata는 configuration 및 bootstrapping에 흔히 사용되지만, secrets manager는 아닙니다. metadata는 VM의 프로세스가 접근할 수 있으며 인스턴스가 침해되면 유출될 수 있고, versioning 및 rotation management 같은 강력한 secret lifecycle controls도 부족합니다. policy에서 instance metadata에 secrets를 저장하는 것을 명시적으로 금지하므로, 이 옵션은 허용되지 않습니다.

Secret Manager는 database passwords와 API tokens를 중앙에서 저장하고 접근하기 위한 올바른 서비스입니다. per-secret IAM, secret versioning, Google APIs를 통한 TLS 기반 접근을 제공하며, read events에 대해 Cloud Audit Logs와 통합됩니다(Data Access logs 활성화 시). automated rotation patterns(rotation schedules 및 Pub/Sub notifications)과 optional CMEK(Cloud KMS 사용)를 지원하여, 제시된 모든 요구사항에 부합하고 metadata/guest attributes를 피합니다.

문제 분석

핵심 개념: 이 문제는 Compute Engine에서 실행되는 애플리케이션을 위한 올바른 managed secret storage 서비스를 선택하는지를 평가하며, centralized secret management, fine-grained IAM, auditability, rotation/versioning, 그리고 secure retrieval를 강조합니다. Google Cloud에서 Secret Manager는 application secrets를 위해 목적에 맞게 설계된 서비스인 반면, Cloud KMS는 주로 key management 및 cryptographic operations를 위한 서비스입니다. 정답이 맞는 이유: Secret Manager는 제시된 모든 요구사항을 직접 충족합니다: secrets는 중앙에 저장되고; 접근은 per-secret IAM(Secret Manager Secret/Secret Version permissions)으로 제어되며; retrieval은 TLS를 통한 Google APIs로 수행되고; secrets는 versioning을 지원하며(각 업데이트는 새 version을 생성); rotation은 built-in rotation schedules 및 Pub/Sub notifications(일반적으로 Cloud Functions/Cloud Run jobs와 함께 사용)로 90일 주기로 구현할 수 있고; Cloud Audit Logs는 secret read에 대한 Admin Activity 및 Data Access logs를 기록합니다(프로젝트에서 Data Access logging이 활성화된 경우). 또한 customer-managed keys로 at rest에서 secrets를 암호화하기 위해 Cloud KMS를 통한 optional CMEK를 지원합니다. 마지막으로 instance metadata 또는 guest attributes 같은 금지된 패턴을 피합니다. 주요 기능 / Best Practices: Workload Identity(MIG에 연결된 service accounts)를 사용하고 secret 수준에서 least privilege를 부여하세요(예: 필요한 secrets에만 roles/secretmanager.secretAccessor). secrets를 이미지에 포함시키기보다 Secret Manager API를 통해 runtime에 접근하는 것을 선호하세요. "latest" 같은 version aliases는 신중히 사용하고, controlled rollouts를 위해 versions를 pinning하세요. Secret Manager rotation + upstream system(DB password/API token)을 업데이트한 뒤 새 secret version을 추가하는 automated rotator로 rotation을 구현하세요. compliance를 위해 Data Access audit logs가 활성화되어 있고 central logging sink로 라우팅되는지 확인하세요. 흔한 오해: Cloud KMS는 “security”이고 CMEK를 지원하기 때문에 자주 선택되지만, KMS는 encryption keys를 관리하는 서비스이지 application secrets lifecycle을 관리하는 서비스가 아닙니다(native per-secret secret retrieval semantics, passwords/tokens를 위한 rotation workflows, 또는 secret version access patterns가 없음). Metadata와 guest attributes는 bootstrapping에 편리하지만, 명시적 policy 금지를 위반하며 강력한 secret governance를 위해 설계되지 않았습니다. Exam Tips: Security Engineer exam에서는 요구사항을 해당 artifact를 위해 설계된 managed service에 매핑하세요: keys/cert crypto operations -> Cloud KMS/Certificate Authority Service; application secrets(passwords, tokens) -> Secret Manager. versioning, rotation, per-secret IAM, 그리고 reads에 대한 audit logs 같은 키워드를 찾으세요—이는 Secret Manager를 강하게 시사합니다. 또한 policy constraints(no metadata/guest attributes)를 확인해 흔한 bootstrapping 지름길을 배제하세요.

4
문제 4
(2개 선택)

Your security team just created a custom-mode VPC named seg-west (10.30.0.0/16) with one subnet us-west1-prim (10.30.10.0/24) and intentionally no user-defined firewall rules; a VM named gw-01 in that subnet has an ephemeral external IP, and the team tests: (1) from gw-01, curl https://8.8.8.8:443, (2) from the public internet, attempt SSH (TCP/22) and HTTP (TCP/80) to gw-01, and (3) attempt SMTP egress on TCP/25 from gw-01; which two behaviors are guaranteed solely by Google Cloud's implied VPC firewall rules before any custom rules are added? (Choose two.)

정답입니다. Google Cloud VPC에는 implied egress allow rule이 있어, 명시적인 egress deny를 추가하지 않는 한(또는 priority와 rule을 사용해 더 제한적인 egress allow-only posture를 구성하지 않는 한) 어떤 destination(0.0.0.0/0)으로의 outbound traffic을 허용합니다. ephemeral external IP가 있으면 gw-01은 internet에 직접 도달할 수 있으므로, 8.8.8.8:443로의 outbound HTTPS는 기본적으로 허용됩니다.

정답입니다. Google Cloud VPC에는 implied ingress deny rule이 있어, ingress allow rule을 만들지 않는 한 모든 새로운 inbound connection을 차단합니다. 따라서 public internet에서 gw-01로 들어오는 비요청(unolicited) inbound SSH(tcp/22) 및 HTTP(tcp/80)는 거부됩니다. 이는 VM에 external IP가 있는지 여부와는 별개이며, external IP는 도달 가능하게 만들 뿐 허용되게 만들지는 않습니다.

오답입니다. TCP/25는 implied VPC firewall rule에 의해 보편적으로 차단되지 않습니다. SMTP 제한이 있다면 일반적으로 anti-abuse 조치, organization policy 제약, 또는 외부 provider 제어 때문이지, 기본 implied firewall 동작 때문이 아닙니다. 순수하게 VPC firewall 관점에서는 egress가 기본적으로 허용되므로, user rule과 무관하게 TCP/25가 암묵적으로 차단된다고 주장할 수 없습니다.

오답입니다. 이는 default-deny egress posture를 설명하는데, 이는 GCP VPC의 기본 동작이 아닙니다. 기본적으로 egress는 implied rule로 허용됩니다. default-deny egress는 더 높은 priority의 egress deny rule을 만들고, 이후 필요한 destination/port에 대해 명시적인 egress allow rule을 추가함으로써 구현할 수 있지만, 그것은 implied baseline이 아닙니다.

오답입니다. inbound HTTP(tcp/80)에 대한 implied allow는 없습니다. inbound traffic은 명시적으로 허용하지 않는 한 기본적으로 거부됩니다. HTTP 접근을 위해서는 ingress firewall rule(예: 0.0.0.0/0 또는 제한된 CIDR에서 tcp:80 허용)이 필요하며, 많은 아키텍처에서는 보통 external HTTP(S) load balancer 앞단에 두고 health check 및 proxy range에 대한 적절한 firewall rule을 구성합니다.

문제 분석

핵심 개념: 이 문제는 사용자 정의 firewall rule 없이 VPC network를 생성했을 때의 Google Cloud VPC firewall 동작을 테스트합니다. GCP에서 VPC firewall rule은 stateful이며 VPC 수준에서 평가됩니다. 커스텀 rule을 전혀 만들지 않더라도, Google은 기본 ingress/egress 동작을 정의하는 implied (system) rule을 제공합니다. 정답이 맞는 이유: A가 맞는 이유는 implied egress allow rule이 존재하기 때문입니다. 기본적으로 VM instance에서 나가는 egress traffic은 더 높은 priority의 egress deny rule을 만들지 않는 한 모든 destination(0.0.0.0/0)으로 허용됩니다. 따라서 routing/NAT이 가능하다는 전제(여기서는 ephemeral external IP가 있으므로 직접 internet egress 가능) 하에, gw-01은 https://8.8.8.8:443로 curl 같은 outbound connection을 시작할 수 있습니다. B가 맞는 이유는 implied ingress deny rule이 존재하기 때문입니다. 기본적으로 VM instance로 들어오는 새로운 inbound connection은 ingress allow rule을 만들지 않는 한 거부됩니다(예: 신뢰할 수 있는 source range에서 tcp:22 허용). 따라서 public internet에서 들어오는 inbound SSH(22) 및 HTTP(80) 시도는 기본적으로 차단됩니다. 핵심 기능 및 best practice: - Implied rule: (1) deny all ingress, (2) allow all egress. 이는 기본 경계 보호입니다. - Stateful firewalling: 이미 설정된 connection에 대한 return traffic은 자동으로 허용되므로, outbound에서 시작된 flow는 명시적인 ingress rule 없이도 동작합니다. - Least privilege: best practice는 필요한 port와 제한된 source range에 대해서만 명시적인 ingress allow를 추가하는 것(예: IAP TCP forwarding 또는 bastion)이며, 데이터 유출(exfiltration) 방지를 위해 명시적인 egress control(deny/allow list)도 고려하는 것입니다. 흔한 오해: 많은 사람들이 “user-defined rule이 없다”를 “어떤 traffic도 허용되지 않는다”로 혼동합니다. GCP에서는 ingress에 대해서만 그렇고, egress는 기본적으로 허용됩니다. 또 다른 오해는 특정 port(예: SMTP/25)가 항상 VPC firewall에 의해 차단된다는 것인데, 실제로 SMTP 제한은 일부 상황에서 organization policy/플랫폼 제약일 수 있으며 implied VPC firewall rule이 아닙니다. 시험 팁: 두 가지 implied VPC firewall rule(deny ingress, allow egress)과 stateful 특성을 암기하세요. 문제가 “어떤 custom rule도 만들기 전”을 언급하면, 이 implied 동작에 집중하면 됩니다. 또한 VPC firewall 동작을 다른 제어(Org Policies, provider anti-abuse SMTP limit, route, Cloud NAT, external IP 존재 여부)와 분리해서 생각하세요.

5
문제 5

Your video analytics platform operates 400 Compute Engine VMs across 12 projects in us-central1, europe-west1, and asia-southeast1. Rapid hiring has caused base image drift, inconsistent CIS-level hardening, and missed critical OS patches. Security requires that: (1) all new instances launch only from organization-approved hardened images; (2) critical OS patches are applied within 48 hours across all projects; and (3) baseline controls remain enforced throughout each VM's lifecycle. You need a centrally managed approach to standardize images and automate enforcement from provisioning through ongoing operations. What should you do?

정답입니다. OS Config (VM Manager)는 여러 프로젝트 전반에서 중앙집중식 patch deployments/jobs, 컴플라이언스 리포팅, OS policy assignments를 제공하여 기준 구성과 패치 SLA를 지속적으로 강제합니다. 강화된 이미지와 이미지 패밀리를 갖춘 전용 이미지 프로젝트는 새 VM이 승인된 golden image에서 시작되도록 프로비저닝을 표준화합니다. 이 둘을 함께 사용하면 프로비저닝 제어, 48시간 패치, 수명주기 강제를 모두 충족합니다.

오답입니다. Sole-tenant nodes는 워크로드 격리와 특정 컴플라이언스 요구사항을 다루며, 이미지 드리프트나 패치 자동화를 다루지 않습니다. Policy Controller (Anthos)는 주로 Kubernetes admission control 및 구성 정책을 위한 것이며, Compute Engine VM 이미지 소스를 제한하거나 VM의 OS 패치를 강제하는 올바른 메커니즘이 아닙니다. 이 옵션은 48시간 패치 요구사항이나 VM 수명주기 강제를 충족하지 못합니다.

오답입니다. 강화된 이미지를 베이킹하기 위한 Cloud Build 파이프라인은 표준화에 유용하지만, Artifact Registry는 컨테이너 및 언어 아티팩트를 위한 것이지 Compute Engine VM 이미지(Compute Engine 이미지 리소스에 존재)를 위한 것이 아닙니다. 더 중요한 점은, 이미지 베이킹만으로는 기존 VM이 48시간 내에 중요 패치를 받도록 보장하거나, OS Config 같은 추가 강제 도구 없이 VM 수명주기 전반에서 기준 통제가 계속 강제되도록 할 수 없습니다.

오답입니다. Security Command Center Enterprise는 가시성(자산 탐지, posture findings, vulnerability insights)을 개선하고 대응 도구와 통합될 수 있지만, Compute Engine VM에서 OS 패치를 강제하거나 구성 상태를 지속적으로 적용하는 주요 서비스는 아닙니다. SCC는 대체로 탐지/모니터링에 해당하며, 명시된 48시간 패치 및 지속적 강제 요구사항을 충족하려면 여전히 OS Config(또는 동등한 도구)가 필요합니다.

문제 분석

핵심 개념: 이 문제는 중앙집중식 VM 보안 운영을 테스트합니다. 즉, 표준화된 golden image와 함께 프로젝트 및 리전 전반에서 대규모로 지속적인 구성/패치 강제를 수행하는 것입니다. 핵심 Google Cloud 서비스는 Compute Engine 이미지 관리(이미지 프로젝트, 이미지 패밀리, IAM/Org Policy)와 패치 및 OS 정책 준수를 위한 VM Manager (OS Config)입니다. 정답인 이유: 옵션 A는 필요한 두 가지 제어 플레인을 결합합니다. (1) 전용 이미지 프로젝트에서 강화된 조직 승인 이미지를 유지하고 이미지 패밀리를 통해 노출하여 일관된 프로비저닝을 가능하게 하는 통제된 이미지 공급망, (2) OS Config를 사용해 정의된 시간 창(48시간) 내에 중요 패치를 적용하고 OS 정책을 통해 기준 구성(baseline configuration)을 지속적으로 평가/강제하는 지속적 강제. 이는 세 가지 요구사항(새 인스턴스에 대한 승인 이미지, 12개 프로젝트 전반의 신속한 패치 롤아웃, 수명주기 전반의 강제(단발성 점검이 아님))을 모두 충족합니다. 주요 기능 / 구현 방법: - Golden images: 중앙 “image factory” 프로젝트를 만들어 강화된 이미지(CIS-aligned)를 Compute Engine 이미지로 게시하고, 이미지 패밀리를 사용해 인스턴스 템플릿이 항상 최신 승인 버전을 선택하도록 합니다. IAM으로 접근을 제어하고, 필요 시 Organization Policy 제약(예: 이미지 프로젝트 제한)을 적용합니다. - Patching: OS Config patch jobs 및 patch deployments(스케줄과 중단 제어 포함)를 사용해 라벨, 존/리전, 또는 프로젝트 기준으로 플릿을 타겟팅하고 패치 SLA를 강제합니다. - Baseline controls: OS Config OS policies(OS policy assignments)를 사용해 패키지, 파일, 서비스, 구성 상태를 지속적으로 강제하고 컴플라이언스 리포팅을 제공합니다. - Operations alignment: 이는 빌드를 표준화하고, 자동화된 개선(remediation)을 수행하며, 감사 가능한 컴플라이언스 신호를 제공함으로써 Google Cloud Architecture Framework의 운영 우수성과 보안 원칙을 지원합니다. 흔한 오해: - 모니터링 전용 도구(예: Security Command Center)는 자체적으로 패치/구성을 강제하지 않습니다. - CI/CD 기반 이미지 베이킹만으로는 기존 VM이 48시간 내에 패치 상태를 유지하도록 보장할 수 없습니다. - Sole-tenant nodes는 격리/컴플라이언스 배치에 관한 것이지, 이미지 거버넌스 및 패치 자동화에 관한 것이 아닙니다. 시험 팁: 요구사항에 “프로비저닝 시 승인된 이미지만 사용”과 “지속적 강제 + 패치 SLA”가 모두 포함되면, 이미지 거버넌스(중앙 이미지 프로젝트 + 패밀리 + IAM/Org Policy)와 OS Config 기반 패치 및 정책 기반 구성 관리를 함께 제시하는 조합을 찾으세요. 탐지(SCC)와 강제(OS Config/Org Policy)를 구분하세요.

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

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

6
문제 6

In a fintech company's Google Cloud environment, the SOC needs the on-premises SIEM to ingest only Compute Engine Admin Activity audit logs and VPC Flow Logs from two projects (proj-sec-01 and proj-sec-02). Access must be read-only, limited to the most recent 30 days, and must not require creating or distributing any long-lived service account keys. Your enterprise IdP is SAML 2.0 and supports OIDC via workforce identity federation; the SIEM can call Google Cloud APIs using short-lived OIDC tokens. You want to minimize data exposure in Google Cloud and avoid copying all logs to external systems. What should you do?

모든 로그를 BigQuery로 라우팅하면 데이터가 다른 analytics store로 복사되며, 일반적으로 노출 표면(dataset access, query results, extracts)이 증가합니다. SIEM이 BigQuery에서 필터링하더라도, authorized views, row-level security 같은 추가 제어를 구축하지 않는 한 더 넓은 dataset에 대한 액세스를 부여한 셈이 됩니다. 또한 비용(streaming ingestion/storage/query)과 복잡성이 추가되며, 최근 로그에 대한 최소 권한 read 액세스를 제공하는 가장 직접적인 방법이 아닙니다.

Cloud Logging은 전용 bucket에서 로그를 30일 동안만 기본적으로 보관하고, log view를 통해 필요한 subset만 노출할 수 있으므로 가장 적합합니다. 이 view는 proj-sec-01 및 proj-sec-02의 Compute Engine Admin Activity audit logs와 VPC Flow Logs만 포함하도록 필터링할 수 있어, 최소 권한 및 read-only 요구 사항을 충족합니다. Workforce Identity Federation을 사용하면 SIEM이 enterprise IdP의 short-lived OIDC 기반 credentials를 사용해 장기-lived service account keys를 생성하거나 배포하지 않고도 Cloud Logging API를 호출할 수 있습니다. 또한 이 접근 방식은 로그를 외부 system이나 보조 analytics store로 불필요하게 복사하는 것도 방지합니다.

Pub/Sub sink와 Dataflow forwarding은 로그를 on-prem SIEM 쪽으로 밀어내는 export 파이프라인으로, 모든 로그를 외부 시스템으로 복사하는 것을 피하고 데이터 노출을 최소화하라는 요구사항과 상충합니다. 또한 운영 복잡성(pipeline reliability, scaling, backpressure, DLQs)과 추가 비용을 유발합니다. 로그를 필터링할 수는 있지만, Logging view에 비해 노출을 최소화하는 접근은 아닙니다.

JSON service account key를 제공하는 것은 장기 키를 피하라는 명시적 요구사항을 위반합니다. 또한 자격 증명 유출 위험과 키 관리 부담(rotation, revocation, audit)을 증가시킵니다. 로그를 Cloud Storage에 저장하는 것 역시 Cloud Logging의 기본 제어에서 벗어나 다른 형태의 복사/export이며, Logging retention과 views에 비해 세밀하고 시간 제한된 액세스를 강제하기가 더 어렵습니다.

문제 분석

핵심 개념: 이 문제는 Cloud Logging의 기본 로그 저장 제어 기능(log buckets, retention, log views)과 Workforce Identity Federation을 사용한 외부 identity access를 함께 테스트합니다. 목표는 로그를 광범위하게 export/copy하지 않고, 장기-lived service account keys도 사용하지 않으면서, 여러 project에 걸친 특정 로그 유형에 대해 최소 권한의 기간 제한된 access를 제공하는 것입니다. 정답인 이유: Option B는 로그를 Cloud Logging에 유지하므로 데이터 노출을 최소화하고 다른 storage 또는 analytics system으로의 불필요한 export를 방지합니다. 전용 log bucket은 30일 retention을 적용할 수 있고, log view는 proj-sec-01 및 proj-sec-02의 Compute Engine Admin Activity audit logs와 VPC Flow Logs만 노출할 수 있습니다. SIEM은 Workforce Identity Federation을 통해 enterprise IdP의 short-lived OIDC tokens를 사용해 authenticate할 수 있으며, 이후 read-only access로 Cloud Logging API를 통해 로그를 읽을 수 있습니다. 주요 기능/구성: - 전용 Cloud Logging bucket을 생성하고 retention을 30일로 설정합니다. - 중앙 집중화가 필요하다면 log sinks를 사용하여 proj-sec-01 및 proj-sec-02에서 필요한 로그만 해당 bucket으로 라우팅합니다. - 다음으로 필터링되는 log view를 생성합니다: - Compute Engine용 Compute Engine Admin Activity audit logs - VPC Flow Logs - 외부 workforce principal에 대해 roles/logging.viewAccessor 또는 이에 상응하는 최소 logging read permissions와 같이, log view에 대한 최소 권한 read access를 부여합니다. - SAML/OIDC를 지원하는 enterprise IdP로 Workforce Identity Federation을 구성하여, SIEM이 service account keys 없이 short-lived credentials를 획득하도록 합니다. 흔한 오해: - BigQuery는 analytics에 유용하지만, 그곳으로 로그를 export하면 데이터의 또 다른 사본이 생성되고, 추가 제어를 적용하지 않으면 노출 범위가 넓어집니다. - Pub/Sub와 Dataflow는 SIEM으로의 streaming export에 흔히 사용되지만, 운영 복잡성을 높이고 Cloud Logging에서 데이터를 이동시키므로, 엄격하게 범위가 제한된 view만 노출하는 방식이 아닙니다. - 요구 사항에서 장기-lived credentials를 명시적으로 금지하는 경우 service account keys는 적절하지 않습니다. 시험 팁: 요구 사항에 외부 enterprise IdP, short-lived OIDC 기반 access, 그리고 workforce identities로 동작하는 외부 사용자 또는 시스템에 대해 service account keys를 사용하지 않는다는 내용이 있으면 Workforce Identity Federation을 떠올리세요. 요구 사항이 광범위한 export 없이 로그의 일부 subset에만 최소 권한 access를 강조하면 Cloud Logging buckets, retention policies, log views, 그리고 IAM 범위 지정 access를 떠올리세요.

7
문제 7
(2개 선택)

Your team is rolling out a global event-ticketing web front end that peaks at 10,000 requests per second across us-central1, europe-west1, and asia-southeast1; to block XSS/SQLi and abusive IP ranges before traffic hits your services, you plan to enforce Google Cloud Armor WAF and rate limiting at the edge—what two infrastructure prerequisites must be in place for the Cloud Armor security policy to actually evaluate and filter requests? (Choose two.)

오답입니다. external SSL proxy load balancer는 XSS 및 SQL injection과 같은 HTTP 공격을 대상으로 하는 Cloud Armor WAF 보호에 필요한 진입점이 아닙니다. 이러한 보호는 HTTP(S)를 인식하는 요청 검사에 의존하며, 이는 일반적인 SSL proxying이 아니라 external HTTP(S) load balancing에서 제공됩니다. 문제는 웹 프런트 엔드와 WAF 동작을 구체적으로 설명하고 있으므로, 이는 SSL Proxy가 아니라 external HTTP(S) load balancer에 해당합니다.

오답입니다. 이 선택지는 policy 적용을 위해 반드시 존재해야 하는 인프라 전제 조건이 아니라 rule 매칭 특성을 설명합니다. Cloud Armor는 실제로 HTTP(S) 트래픽에 대해 Layer 7 요청 속성을 평가하지만, 그 사실만으로 필요한 배포 아키텍처가 성립되지는 않습니다. 또한 Cloud Armor는 URI와 header만이 아니라 그 이상에도 매칭할 수 있으므로, 이 설명은 정확한 전제 조건이 아니며 일부 오해의 소지가 있습니다.

오답입니다. Premium Network Service Tier는 일반적으로 global external HTTP(S) load balancing과 함께 사용되지만, 문제에서 테스트하는 Cloud Armor policy 평가의 전제 조건은 아닙니다. 핵심 요구 사항은 지원되는 external HTTP(S) load-balancer 진입점과 policy가 연결되는 적격한 external backend service입니다. Premium Tier 자체를 두 가지 필수 전제 조건 중 하나로 보는 것은 그 역할을 과장하는 것이며, 이 선택지는 D보다 덜 정확합니다.

정답입니다. Cloud Armor security policy는 지원되는 external load balancer가 사용하는 backend service에 연결되므로, backend service는 external load balancing용으로 구성되어 있어야 합니다. 시험 관점에서는 이를 loadBalancingScheme이 EXTERNAL로 설정된 것으로 표현하며, 이는 해당 backend service가 external load-balancing 경로의 일부임을 나타냅니다. 적격한 external backend service가 없으면, 들어오는 웹 트래픽에 대해 Cloud Armor policy를 적용할 지원되는 위치가 없습니다.

정답입니다. Cloud Armor WAF와 HTTP rate limiting은 요청이 external Application Load Balancer 또는 classic external HTTP(S) load balancer와 같은 external HTTP(S) load balancer를 통해 들어올 때 평가됩니다. 이 Layer 7 proxy 경로는 Google Cloud Armor가 HTTP 요청 속성에 접근할 수 있게 하며, XSS 및 SQL injection 같은 위협에 대해 사전 구성된 WAF signature를 사용할 수 있게 합니다. 트래픽이 이 진입점을 우회하면, policy는 문제에서 설명한 방식으로 요청을 검사하고 필터링할 수 없습니다.

문제 분석

핵심 개념: Google Cloud Armor security policy는 지원되는 external load-balancing 경로에서만 적용되며, WAF 기능(XSS/SQLi 보호 및 HTTP rate limiting 등)의 경우 주로 external HTTP(S) load balancer에서 적용됩니다. policy가 실제로 요청을 검사하고 필터링하려면, 트래픽이 external HTTP(S) proxy 계층을 통과해야 하며 policy는 적격한 external backend service에 연결되어 있어야 합니다. 정답인 이유: E가 정답인 이유는 Cloud Armor WAF와 HTTP rate limiting이 external Application Load Balancer 또는 classic external HTTP(S) load balancer와 같은 external HTTP(S) load balancer가 처리하는 요청에서 평가되기 때문입니다. 이는 Google이 HTTP 속성을 검사하고, 사전 구성된 WAF signature를 적용하며, backend로 트래픽을 전달하기 전에 rate-based rule을 시행할 수 있는 Layer 7 진입점입니다. 트래픽이 이 지원되는 HTTP(S) load-balancing 스택을 통해 들어오지 않으면, Cloud Armor policy는 의도한 방식으로 웹 요청을 평가하지 않습니다. D가 정답인 이유는 Cloud Armor security policy가 external load balancer에서 사용하는 backend service에 연결되며, 해당 backend service는 external backend service여야 하기 때문입니다. 실제로 이는 backend service가 external load balancing용으로 구성되어 있어야 함을 의미하며(loadBalancingScheme=EXTERNAL), 이 시나리오에서 policy의 지원되는 연결 지점입니다. external HTTP(S) load balancer 뒤에 적격한 external backend service가 없으면, Cloud Armor policy를 적용할 유효한 enforcement point가 없습니다. 주요 기능: - Cloud Armor WAF와 HTTP rate limiting은 지원되는 external HTTP(S) load balancer에서 평가되는 Layer 7 보호 기능입니다. - security policy는 instance나 unmanaged public endpoint에 직접 연결되는 것이 아니라 backend service에 연결됩니다. - External Application Load Balancer와 classic external HTTP(S) load balancer는 Cloud Armor 웹 보호와 관련해 시험에서 자주 나오는 진입점입니다. 흔한 오해: - Premium Tier는 종종 global load balancing과 연관되지만, 여기서 테스트하는 Cloud Armor policy 평가의 핵심 전제 조건은 아닙니다. - external SSL Proxy load balancer는 문제가 XSS 및 SQLi 같은 WAF 보호를 명시적으로 묻는 경우의 표준 정답이 아닙니다. 이러한 보호는 HTTP에 특화되어 있기 때문입니다. - rule이 어떤 필드와 매칭될 수 있는지에 대한 설명은 인프라 전제 조건과 동일하지 않습니다. 시험 팁: 문제에서 Cloud Armor WAF, XSS/SQLi 또는 HTTP rate limiting이 언급되면, 먼저 지원되는 Layer 7 진입점인 external HTTP(S) load balancer를 식별하세요. 그런 다음 해당 load balancer 뒤에 있는 유효한 policy 연결 대상인 external backend service를 찾으세요. 실제 배포 전제 조건과 rule 동작에 대한 설명 또는 관련 없는 load balancer 유형을 구분하세요.

8
문제 8

You manage security for a media analytics firm hosting 3 internal web dashboards (2 on Cloud Run and 1 on a managed instance group behind a global external HTTP(S) Load Balancer) that must be reachable over the public internet but only by 500 employees in your Google Workspace domain; you need to enforce per-user and group-based access with OAuth 2.0 sign-in, optionally apply device-based restrictions via Access Context Manager, avoid using client VPNs or custom reverse proxies, and capture detailed access audit logs in Cloud Logging. Which Google Cloud service should you use to centrally enforce authentication and fine-grained access control for these applications?

Identity-Aware Proxy (IAP)는 웹 앱을 위한 중앙집중식, ID 기반 접근 제어를 제공합니다. Google ID OAuth 2.0 인증을 강제하고, IAM을 사용해 애플리케이션별로 특정 사용자 또는 Google Workspace 그룹을 인가합니다. IAP는 Access Context Manager와 통합되어 디바이스/컨텍스트 기반 access levels를 적용할 수 있으며, Cloud Logging에 상세한 audit logs를 생성합니다. Cloud Run 및 HTTP(S) Load Balancing 뒤의 앱을 보호하면서도 VPN과 커스텀 reverse proxies를 피할 수 있습니다.

Cloud NAT는 외부 IP 없이 프라이빗 리소스가 인터넷으로 나가는(outbound, egress) 액세스를 가능하게 합니다. 최종 사용자를 인증하거나 OAuth sign-in을 수행하거나, 웹 애플리케이션에 대한 inbound 접근에 대해 그룹 기반 인가를 강제하지 않습니다. Cloud NAT는 네트워크 변환 서비스이지 애플리케이션 접근 제어 계층이 아니므로, 사용자별 접근 정책이나 대시보드에 대한 상세한 사용자 접근 감사 요구사항을 충족하지 못합니다.

Google Cloud Armor는 HTTP(S) Load Balancers를 위한 WAF 및 DDoS 보호 서비스입니다. IP allow/deny lists, geo 제한, rate limiting, 사전 구성된 WAF rules를 적용할 수 있지만, OAuth 2.0을 통한 사용자별 인증이나 Google Workspace ID에 연동된 그룹 기반 접근을 제공하지는 않습니다. 위협 보호를 위해 IAP를 보완할 수는 있지만, ID 인지형 접근 제어를 위해 IAP를 대체할 수는 없습니다.

Shielded VMs는 secure boot, vTPM, integrity monitoring을 사용해 부트 수준 및 rootkit 스타일 공격으로부터 VM 인스턴스를 보호합니다. 이는 Compute Engine 워크로드의 호스트 보안 상태를 개선하지만, 중앙집중식 사용자 인증, OAuth sign-in, 웹 대시보드에 대한 인가를 제공하지는 않습니다. 또한 ID 기반 접근 제어 및 애플리케이션 접근에 대한 사용자 수준 audit logging 요구사항을 해결하지 못합니다.

문제 분석

핵심 개념: 이 문제는 VPN이나 커스텀 프록시를 사용하지 않고, 퍼블릭 인터넷에 노출된 웹 애플리케이션에 대해 중앙집중식의 ID 기반 접근 제어를 테스트합니다. Google Cloud에서 HTTP(S) 앱 앞단에서 사용자별 OAuth 2.0 인증 및 인가를 제공하는 주요 서비스는 Identity-Aware Proxy (IAP)이며, 종종 Google Workspace ID와 함께 사용되고 선택적으로 Access Context Manager (BeyondCorp)와도 연동됩니다. 정답이 맞는 이유: Identity-Aware Proxy는 지원되는 Google Cloud 백엔드(Cloud Run 및 외부 HTTP(S) Load Balancers 포함) 앞단에 위치하여, 어떤 요청이든 애플리케이션에 도달하기 전에 Google ID 로그인(OAuth 2.0)을 강제합니다. 또한 IAM(사용자, 그룹, service accounts)을 통해 세밀한 접근을 지원하므로, Google Workspace 도메인의 500명 직원만 허용하고 그룹 기반 접근을 적용해야 한다는 요구사항과 정확히 일치합니다. IAP는 ID를 인지하는 방식이므로 VPN 같은 네트워크 기반 제어를 피할 수 있고, 커스텀 reverse proxy를 구축할 필요도 없습니다. 주요 기능 / 구성 / 모범 사례: 1) IAM 기반 인가: 각 앱에 대해 Workspace 그룹에 IAP-secured Web App User role을 부여합니다. 2) OAuth 동의 및 브랜드: IAP용 OAuth brand와 client를 구성합니다. 3) 디바이스/컨텍스트 제한: Access Context Manager와 통합하여 IAP로 보호되는 리소스에 access levels(예: 관리형 디바이스, 준수 OS, 신뢰할 수 있는 IP ranges)를 요구합니다. 4) 중앙집중식 로깅: IAP는 상세한 audit logs(구성에 따라 Admin Activity / Data Access)와 request logs를 생성하며, Log Router를 통해 SIEM 또는 스토리지로 내보낼 수 있어 Cloud Logging 감사 요구사항을 충족합니다. 5) Architecture Framework 정렬: 네트워크 위치에서 검증된 ID와 컨텍스트로 신뢰를 이동시키는(BeyondCorp) 방식으로 “Identity and access management” 및 “Network security” 원칙을 구현합니다. 흔한 오해: Cloud Armor는 IP/geo 기반으로 트래픽을 제한하고 L7 공격을 완화할 수 있지만, 사용자별 OAuth 로그인이나 그룹 기반 인가를 제공하지는 않습니다. Cloud NAT는 egress-only이며 inbound 사용자 인증과는 무관합니다. Shielded VMs는 VM 부트 무결성을 강화하지만, 누가 웹 대시보드에 접근할 수 있는지를 제어하지는 않습니다. 시험 팁: “public internet이지만 특정 직원만,” “OAuth 2.0 sign-in,” “group-based access,” “no VPN,” “Cloud Logging 감사 가능성”을 보면 IAP + IAM + (선택) Access Context Manager를 떠올리세요. 또한 IAP는 HTTP(S) Load Balancing 및 Cloud Run과 자연스럽게 동작하므로, BeyondCorp 스타일 접근에 대한 흔한 시험 패턴이라는 점도 기억하세요.

9
문제 9

Your security team plans to roll out VPC Service Controls across 12 production projects organized into 4 service perimeters and wants a 14-day evaluation period to test perimeter rule changes and observe potential violations in logs without interrupting any existing access paths (including BigQuery and Cloud Storage requests from on-prem via Private Service Connect). Which VPC Service Controls mode should you use to validate the impact safely while ensuring no requests are blocked during the evaluation window?

Cloud Run은 서버리스 컴퓨팅 플랫폼이며 VPC Service Controls의 운영 모드와는 관련이 없습니다. Cloud Run 서비스가 간접적으로 VPC 제어 뒤에 배치될 수는 있지만(예: 보호된 서비스에 액세스), VPC SC 평가 또는 강제를 위한 “모드”를 제공하지는 않습니다. Cloud Run을 선택하는 것은 애플리케이션 런타임 제품을 보안 경계 제어 기능과 혼동한 것입니다.

“Native”는 경계를 평가하거나 강제하는 데 사용되는 VPC Service Controls 모드가 아닙니다. VPC SC 경계는 구성된 다음 enforced 동작 또는 dry-run 평가로 적용됩니다. “native” 같은 용어를 본다면, 일반적으로 다른 제품 맥락(예: native integrations)과 관련이 있으며 안전한 경계 테스트에 필요한 운영 모드와는 관련이 없습니다.

Enforced 모드는 서비스 경계 규칙을 위반하는 요청을 적극적으로 차단합니다. 이는 데이터 유출을 방지할 준비가 되었고 비준수 경로에 대한 액세스 거부를 감내/예상할 수 있을 때 적절합니다. 이 시나리오에서는 14일 평가 동안 기존의 어떤 액세스 경로도 중단하지 말라고 명시되어 있으므로, enforced 모드는 너무 위험하며 장애를 유발할 가능성이 큽니다.

Dry run 모드는 제안된 경계 정책에 대해 요청을 평가하고 위반 로그를 생성하지만, 트래픽을 차단하지는 않습니다. 이를 통해 경계 규칙 변경을 테스트하고, 예상치 못한 의존성(Private Service Connect를 통한 하이브리드/온프레미스 액세스 포함)을 식별하며, enforced 모드로 전환하기 전에 액세스 레벨과 ingress/egress 규칙을 튜닝할 수 있는 안전한 평가 기간을 제공합니다. 이는 “중단 없이 관찰”이라는 요구사항에 가장 잘 부합합니다.

문제 분석

핵심 개념: VPC Service Controls (VPC SC)는 Google 관리형 서비스(예: BigQuery 및 Cloud Storage) 주변에 서비스 경계를 제공하여 데이터 유출(data exfiltration) 위험을 줄입니다. 경계는 여러 프로젝트에 걸쳐 적용할 수 있으며, ID, 네트워크, 액세스 레벨 조건에 따라 액세스를 제한할 수 있습니다. VPC SC는 차단을 강제하지 않고 무엇이 거부될지를 관찰하기 위해 “dry-run”을 사용하는 평가 접근 방식을 지원합니다. 정답이 맞는 이유: “Dry run” 모드는 경계 구성 변경을 안전하게 검증하도록 특별히 설계되었습니다. Dry-run에서는 VPC SC가 요청을 dry-run 경계 구성에 대해 평가하고 로그에 위반 사항을 기록하지만, 요청을 차단하지는 않습니다. 이는 팀이 14일 평가 기간 동안 규칙 변경을 테스트하고, Private Service Connect를 통해 들어오는 BigQuery/Cloud Storage 요청과 같은 온프레미스 액세스 패턴을 포함하여 기존의 어떤 액세스 경로도 중단하지 않으면서 잠재적 위반을 관찰하려는 요구사항과 일치합니다. 주요 기능 / 모범 사례: 1) Dry-run 경계: 강제(enforced) 경계를 안정적으로 유지하면서, 강제 적용을 켜기 전에 영향도를 확인하기 위해 dry-run 구성을 반복적으로 조정할 수 있습니다. 2) 로깅 및 모니터링: Dry-run은 VPC SC 위반 로그(및 관련 감사 로그)를 생성하며, 이를 SIEM/SOAR로 라우팅하여 분석할 수 있습니다. 이는 측정 가능한 통제를 통해 Google Cloud Architecture Framework의 “operational excellence” 및 “security by design” 원칙을 지원합니다. 3) 점진적 롤아웃: 12개 프로젝트와 4개 경계가 있는 상황에서, dry-run은 경계별 단계적 검증을 가능하게 하고 블라스트 반경(blast radius)을 줄입니다. 평가 후에는 테스트된 규칙을 enforced 모드로 승격할 수 있습니다. 흔한 오해: 많은 사람들이 “native” 또는 “enforced”가 “진짜” 테스트에 필요하다고 혼동합니다. 하지만 enforced 모드는 비준수 요청을 적극적으로 거부하므로, 중단을 피해야 한다는 요구사항과 모순됩니다. 또 다른 오해는 위반을 보려면 반드시 강제해야 한다는 것인데, dry-run은 차단 없이 위반을 드러내도록 명시적으로 만들어졌습니다. 시험 팁: 문제가 “위반 관찰,” “변경 테스트,” “무중단,” 또는 “영향 평가”를 강조한다면, 올바른 VPC SC 선택지는 거의 항상 “dry run”입니다. 반대로 즉시 데이터 유출을 적극적으로 방지해야 한다면 “enforced”가 적절합니다. 또한 복잡한 액세스 경로(하이브리드/온프레미스, PSC, VPN/Interconnect)는 강제 적용 전에 예상치 못한 의존성을 드러내는 데 dry-run이 특히 유용하다는 점을 기억하세요.

10
문제 10

You are launching a payment reconciliation service on Cloud Run in asia-southeast1. A regulatory requirement mandates that application logs be retained for 10 years and that all log data remain within Singapore (asia-southeast1) at all times. The service emits approximately 40 GB of logs per day, and your team wants a low-overhead, cost-effective, Google-managed approach. What should you do?

Cloud Storage에 로그를 직접 기록하면 bucket이 asia-southeast1에 있고 retention policy가 있다면 보존과 리전 요구사항을 충족할 수 있습니다. 그러나 애플리케이션 변경이 필요하고, Cloud Logging의 native querying/alerting을 잃으며, 운영 오버헤드가 더 큽니다. 또한 Cloud Run이 Cloud Logging으로 보내는 플랫폼/시스템 로그를 누락할 위험이 있습니다. 이는 Cloud Run 로깅 컴플라이언스를 위한 가장 Google-managed이며 오버헤드가 낮은 접근 방식이 아닙니다.

Cloud Run은 VM에서처럼 전통적인 logging agents 설치를 지원하지 않으며, sidecars는 복잡성과 운영 부담(빌드, 배포, 패치, 리소스 사이징)을 추가합니다. 또한 로그를 Cloud Logging으로 가져오기 위해 agent가 필요하지 않습니다. Cloud Run은 이미 stdout/stderr를 Cloud Logging으로 스트리밍합니다. 올바른 패턴은 Cloud Logging buckets와 Log Router를 구성하는 것이지 커스텀 log shipping 구성 요소를 추가하는 것이 아닙니다.

Pub/Sub를 통해 Cloud Storage로 로그를 export하면 추가 파이프라인(sink to Pub/Sub, subscriber, delivery guarantees, backpressure handling)이 도입되어 운영 오버헤드가 증가합니다. 40 GB/day에서는 비용이 더 들고 장애에 더 취약할 수 있습니다. Storage bucket을 regional로 유지하고 lifecycle/retention을 설정할 수는 있지만, regional Cloud Logging bucket으로 직접 라우팅하는 것에 비해 가장 단순한 Google-managed 솔루션이 아닙니다.

asia-southeast1에 regional Cloud Logging log bucket을 생성하고 Log Router를 통해 Cloud Run 로그를 해당 bucket으로 라우팅하면 두 요구사항(강제된 regional data residency와 managed logging storage를 통한 10년 retention)을 직접 충족합니다. 애플리케이션 변경이 필요 없고 운영이 최소화됩니다. Cloud Run 로그를 정밀하게 필터링할 수 있으며 default bucket에 저장되지 않도록 하여 compliance 및 비용 제어 모범 사례에 부합합니다.

문제 분석

핵심 개념: 이 문제는 Log Router와 regional log buckets를 사용한 Cloud Logging 데이터 상주(data residency) 및 보존(retention) 제어를 테스트합니다. Cloud Run의 경우 애플리케이션 로그가 자동으로 Cloud Logging으로 수집됩니다. 규정을 준수하면서 오버헤드가 낮은 접근 방식은 Cloud Logging의 managed storage를 사용해 로그가 저장되는 위치와 보존 기간을 제어하는 것입니다. 정답이 맞는 이유: 규제 요구사항은 (1) 10년 보존과 (2) 모든 로그 데이터가 항상 싱가포르(asia-southeast1) 내에 유지되어야 함을 요구합니다. asia-southeast1에 regional Cloud Logging log bucket을 생성하고 Cloud Run 서비스 로그를 해당 bucket으로 라우팅하면 두 요구사항을 모두 충족합니다. bucket의 location이 regional storage를 강제하고, bucket의 retention 설정이 커스텀 파이프라인을 구축하지 않고도 장기 보존을 강제합니다. Log Router를 업데이트하면 관련 로그만 해당 bucket에 저장되도록 보장할 수 있으며, 선택적으로 default bucket에서 제외(exclude)하여 비준수 저장 위치를 피할 수 있습니다. 주요 기능 및 모범 사례: - Regional log buckets: Cloud Logging은 지정된 location(리전)으로 log buckets를 지원합니다. regional bucket에 로그를 저장하는 것이 로그 데이터 상주의 주요 메커니즘입니다. - Custom retention: bucket retention을 3650일(10년)로 구성합니다. 이는 Cloud Logging에 의해 강제되며 운영 부담을 줄입니다. - Log Router sinks: Cloud Run 서비스를 대상으로 하는 inclusion filter(resource.type="cloud_run_revision" 및 서비스 이름/리전 label)를 생성하고 regional bucket으로 라우팅합니다. 필요 시 default bucket에 exclusions를 사용해 중복 저장을 방지합니다. - Compliance alignment: 이는 Google Cloud Architecture Framework의 compliance 및 data governance 원칙(관리형 제어 사용, 최소 운영 오버헤드, 명시적 데이터 위치 제약)과 부합합니다. 흔한 오해: “저렴한 장기 보관”을 위해 Cloud Storage로 로그를 export하려는 유혹이 있지만, 이는 파이프라인 복잡성을 추가하고 로그가 먼저 default global logging bucket에 저장되거나 라우팅이 잘못 구성되면 “항상 싱가포르 내에 유지” 요구사항을 위반할 수 있습니다. 또한 agents/sidecars를 추가하는 것은 Cloud Run의 fully managed 모델과 맞지 않으며 유지보수를 증가시킵니다. 시험 팁: 상주 + 보존 요구사항에는 DIY exports보다 Cloud Logging regional buckets + Log Router를 우선하세요. 기억할 점: Cloud Run은 이미 Cloud Logging과 통합되어 있으므로 앱을 수정하기보다 sinks/buckets 구성에 집중하세요. 또한 볼륨(40 GB/day)도 고려하세요. managed logging buckets는 ingestion 인프라를 직접 관리하지 않아도 확장되며, filters를 적용해 비용을 제어할 수 있습니다.

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