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

GCP

Google Associate Cloud Engineer

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

시험 도메인

Setting up a cloud solution environment출제율 23%
Planning and implementing a cloud solution출제율 30%
Ensuring successful operation of a cloud solution출제율 27%
Configuring access and security출제율 20%

실전 문제

1
문제 1

Your team runs a Linux build server on a Compute Engine VM named build-ci-07 (Ubuntu 22.04 LTS) in us-central1-b with an external IP of 34.118.52.10, and a freelance penetration tester connected to your corporate network via an IPsec VPN (10.20.0.0/16) needs temporary SSH access within the next 24 hours but does not have a Google account; what should you do to grant access securely and quickly?

오답입니다. TCP forwarding을 위한 IAP(및 IAP를 통한 gcloud compute ssh)는 사용자가 Google Cloud에 인증하고 적절한 IAM 권한(예: IAP-secured Tunnel User 및 Compute 권한)을 가져야 합니다. 테스터에게 Google account가 없으므로, IAP tunnel을 설정하는 데 필요한 identity 및 authorization 단계를 완료할 수 없으며, 다른 조건이 충족되더라도 사용할 수 없습니다.

오답/불완전합니다. gcloud compute ssh를 사용하려면 Compute Engine API를 호출하고 ephemeral keys/metadata를 관리하기 위해 Google authentication(Google account)이 필요합니다. 또한 VM의 public IP를 직접 대상으로 하면 SSH를 인터넷에 개방하도록 유도할 수 있습니다. 더 안전한 접근은 SSH를 VPN CIDR로 제한하고, gcloud에 의존하기보다 제공받은 public key로 표준 SSH를 사용하는 것입니다.

정답입니다. 표준 SSH key 기반 액세스는 Google account 없이도 동작합니다. 테스터가 key pair를 생성하고 public key만 공유하면, 이를 인스턴스 수준(metadata) 또는 임시 사용자의 ~/.ssh/authorized_keys에 추가합니다. metadata SSH key에 만료를 설정하고 방화벽 규칙을 10.20.0.0/16에서만 tcp:22를 허용하도록 제한하여 24시간 창을 강제할 수 있습니다.

오답이며 안전하지 않습니다. private key는 절대 공유하면 안 됩니다. private key는 identity를 증명하는 비밀이며, 테스터가 private key를 보내면 당신이 그들을 사칭할 수 있고, 전송 또는 저장 과정에서 키가 노출되어 기본 보안 관행과 대부분의 컴플라이언스 표준을 위반하게 됩니다. 또한 SSH 인증은 클라이언트 측에서 private key를 사용하는 방식이며, 서버에 private key를 추가하는 것은 올바른 모델이 아닙니다.

문제 분석

핵심 개념: 이 문제는 사용자가 Google identity가 없을 때 Compute Engine VM에 대해 안전하고 임시적인 SSH 액세스를 제공하는지를 테스트합니다. OS Login/IAP와 인스턴스/프로젝트 metadata 및 Linux authorized_keys를 통한 전통적인 SSH 키 관리의 대비에 초점을 둡니다. 정답이 맞는 이유: 테스터에게 Google account가 없으므로, Identity-Aware Proxy (IAP) TCP forwarding 및 Google identity에 의존하는 gcloud 기반 SSH 흐름에 필요한 Google Cloud IAM에 인증할 수 없습니다. 가장 빠르고 안전한 접근은 표준 SSH를 사용하는 것입니다. 테스터가 SSH key pair를 생성하고 public key만 제공하면, 이를 VM에 추가합니다(최소 권한과 손쉬운 제거를 위해 인스턴스 수준 metadata가 바람직하며, 또는 대상 사용자의 ~/.ssh/authorized_keys에 직접 추가). 이렇게 하면 Google account를 만들지 않고도 액세스를 부여할 수 있고, 키를 제거하여 빠르게 철회할 수 있습니다. 주요 기능 / 모범 사례: - 프로젝트 전체 키보다 범위가 좁고 임시 액세스에 적합한 인스턴스 수준 SSH keys (metadata)를 사용합니다. - 24시간 요구사항을 강제하기 위해 metadata SSH keys에 만료를 설정합니다(지원되는 형식에는 expireOn 필드가 포함됨). - 네트워크 노출을 제한합니다: 테스터는 IPsec VPN(10.20.0.0/16)을 통해 사내 네트워크에 있으므로, VM에 external IP가 있더라도 방화벽 규칙이 인터넷이 아니라 해당 CIDR에서만 tcp:22를 허용하도록 보장합니다. - sudo가 제한된 전용 임시 Linux user를 선호하고, 감사 가능성을 위해 액세스를 로깅합니다(Cloud Logging/OS logs). 흔한 오해: - “IAP 사용”이 가장 안전해 보이지만, 사용자가 Google(IAM)로 인증해야 합니다. Google account가 없으면 IAP를 사용할 수 없습니다. - “public IP로 그냥 SSH”는 빠르지만, SSH를 광범위하게 열면 공격 표면이 증가합니다. 또한 키 관리를 여전히 해야 하므로 인증 문제를 해결하지 못합니다. - private key 공유는 절대 허용되지 않습니다. private key는 반드시 비밀로 유지되어야 합니다. 시험 팁: ACE에서는 사용자가 Google identity가 없으면 일반적으로 IAM으로 게이트된 액세스 방식(IAP, OS Login)을 사용할 수 없습니다. SSH public key 배포로 돌아가되, 범위를 좁게(인스턴스 수준), 시간 제한(키 만료), 그리고 방화벽 제한(source ranges)과 함께 적용하여 실제 운영에서의 보안과 속도 요구사항을 충족하세요.

2
문제 2

You need to configure an automated policy for a specific dual-region Cloud Storage bucket so that project documents are transitioned to Archive storage after 180 days and then permanently deleted exactly 730 days (2 years) after their creation; how should you set up the policy?

오답입니다. Delete Age 조건이 이전 lifecycle action(180일에 전환) 시점에 상대적이라고 가정하여 730에서 180을 빼고 550을 사용합니다. Cloud Storage lifecycle에서 Age는 전환 시점이 아니라 항상 객체 creation time을 기준으로 측정됩니다. 이는 생성 후 550일에 객체를 삭제하게 되어 2년 요구사항을 위반합니다.

정답입니다. 객체 생성 시점을 기준으로 측정되는 Age 조건을 사용해 두 개의 Cloud Storage lifecycle rule을 구성합니다: Age 180에서 SetStorageClass를 ARCHIVE로, Age 730에서 Delete를 수행합니다. 이는 180일 후 전환 및 생성 후 730일 삭제 요구사항과 일치합니다. 이는 표준의 fully managed 접근 방식이며 dual-region bucket에서도 동일하게 동작합니다.

오답입니다. gsutil rewrite는 객체를 rewrite하는 수동/일회성 작업(주로 storage class, encryption, 또는 metadata 변경에 사용)입니다. 향후 객체에 대해 자동으로 지속 적용되는 policy를 만들지 않습니다. 또한 Delete를 550일로 설정하는 것은 옵션 A와 동일한 Age 오해를 반복하며 너무 이르게 삭제합니다.

오답입니다. 730일은 원하는 삭제 Age와 일치하지만, gsutil rewrite는 자동화된 lifecycle policy를 구현하지 못하고 실행 시점에 존재하는 객체만 rewrite합니다. 또한 시간이 지나며 모든 객체에 대해 180일에 Archive로 자동 전환해야 한다는 요구사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Cloud Storage Object Lifecycle Management를 테스트합니다. lifecycle rule을 사용하면 조건(예: Age(객체 생성 후 경과 일수), creation date, 또는 newer versions)에 따라 객체를 storage class 간에 자동으로 전환(예: Standard에서 Archive로)하고 객체를 삭제할 수 있습니다. 이는 custom script 없이 비용과 보존(retention)을 관리하기 위한 운영 중심 제어입니다. 정답이 맞는 이유: 요구사항은 (1) 180일 후 Archive로 전환, (2) 생성 후 정확히 730일에 영구 삭제입니다. Cloud Storage lifecycle에서 Age 조건은 이전 lifecycle action이 수행된 시점이 아니라 객체의 creation time을 기준으로 평가됩니다. 따라서 생성 시점을 기준으로 측정되는 Age 조건을 가진 두 개의 별도 rule을 구성해야 합니다: - Rule 1: Age = 180, action SetStorageClass = ARCHIVE - Rule 2: Age = 730, action Delete 이렇게 하면 더 이른 전환과 무관하게 생성 후 730일에 삭제가 수행됩니다. 주요 기능 / Best Practices: Lifecycle policy는 Cloud Storage가 자동으로 강제 적용합니다(cron job 없음, Compute 없음). bucket 단위(dual-region bucket 포함)로 적용되며 추가 인프라 없이 확장됩니다. 180일 후 Archive 사용은 비용 최적화(Google Cloud Architecture Framework: cost optimization 및 operational excellence)에 부합합니다. 730일에 삭제는 retention/cleanup을 강제합니다. lifecycle action은 정확한 timestamp에 실행되는 것이 보장되지 않으며 비동기적으로 적용되고 보통 하루 이내에 처리되므로, 시험 문맥에서 “exactly”는 “Age=730 기준”을 의미하며 “to-the-second”를 의미하지 않습니다. 흔한 오해: 흔한 함정은 730에서 180을 빼서 Delete를 550일로 설정하고, storage-class transition 이후에 delete 타이머가 시작된다고 가정하는 것입니다. 이는 Age가 항상 creation 이후 경과 시간이라는 점 때문에 틀립니다. 또 다른 오해는 gsutil rewrite를 사용하는 것입니다. rewrite는 객체를 복사/재작성하여 storage class를 변경하는 방식이며, 자동화된 지속 정책이 아닙니다. 시험 팁: retention/transition 질문에서는 기본적으로 Cloud Storage lifecycle rule을 떠올리세요. 기억할 점: Age/CreatedBefore는 객체 creation time을 기준으로 평가됩니다. 여러 마일스톤이 있으면 여러 rule을 사용하세요. 또한 lifecycle management(자동화된 policy)와 일회성 관리 명령(gsutil rewrite), 그리고 retention policy/hold(삭제를 예약하는 것이 아니라 삭제를 방지함)를 구분하세요.

3
문제 3

You manage a single custom-mode VPC named 'corp-net' in project alpha-prod with one subnetwork 'asia-pri' in asia-southeast1 (10.20.0.0/20). A Compute Engine VM 'app-1' (10.20.0.5) in this subnet exposes an internal-only HTTPS service on TCP 8443 that must not be publicly reachable. You must deploy a new VM in southamerica-east1 that needs private access to 'app-1'. You want a Google-recommended solution with minimal operational overhead and no public exposure. What should you do?

정답입니다. 단일 VPC network는 global이므로 corp-net에 southamerica-east1 subnet을 추가하면 새 VM이 internal IP routing을 통해 app-1과 private하게 통신할 수 있습니다. 이는 운영 오버헤드가 최소입니다: VPN, peering, load balancer가 필요 없습니다. app-1로의 tcp:8443을 새 subnet(또는 특정 VM identity)에서 허용하도록 firewall rules만 보장하면 되며, 서비스를 public이 아닌 상태로 유지할 수 있습니다.

오답입니다. internal TCP/UDP load balancer는 regional이며 안정적인 internal VIP를 제공하고 같은 리전 내 backend로 트래픽을 분산하기 위한 용도입니다(또는 특정 cross-region 설계를 통해 가능하지만 복잡도가 증가). 또한 핵심 요구를 해결하지 못합니다. 더 큰 문제는 두 VPC(sa-net과 corp-net) 간의 network connectivity입니다. 이 옵션은 불필요한 구성요소를 도입하고 운영 오버헤드를 높입니다.

오답입니다. 같은 VPC 내 subnet 간 connectivity에는 Cloud VPN이 필요하지 않습니다. GCP는 하나의 VPC 안에서 리전 간 private routing을 이미 제공합니다. 같은 VPC 내부의 두 리전 사이에 VPN을 구축하는 것은 불필요한 복잡도이며 비용을 추가하고 운영 부담(터널 관리, 라우팅, 모니터링)을 증가시킵니다. VPN은 온프레미스-to-cloud 또는 VPC-to-VPC connectivity에 적합하며, intra-VPC에는 해당하지 않습니다.

오답입니다. VPC peering은 두 개의 별도 VPC를 private하게 연결하지만, 여러 subnet을 가진 하나의 VPC를 사용하는 것보다 더 복잡합니다. 또한 관리 오버헤드와 제한(예: transitive routing 불가, VPC별로 분리된 firewall rule 관리)을 도입합니다. 이미 corp-net이 있고 다른 리전에 새 VM만 필요하므로, 또 다른 VPC를 만들고 peering하는 것은 최소 구성의 Google 권장 접근 방식이 아닙니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud VPC 네트워킹이 리전 간에 어떻게 동작하는지를 테스트합니다. 단일 VPC network는 global이며, subnet은 regional입니다. 서로 다른 리전에 있는 리소스도 같은 VPC에 속해 있고(또는 지원되는 private connectivity로 연결되어 있으며) firewall rules가 허용한다면, Google의 backbone을 통해 private하게 통신할 수 있습니다. 정답인 이유: 옵션 A는 Google이 권장하는 운영 부담이 가장 낮은 접근 방식입니다. 기존 custom-mode VPC(corp-net)를 southamerica-east1에 새로운 regional subnet을 생성하여 확장한 뒤, 새 VM을 그 subnet에 배치합니다. 두 VM이 동일한 VPC에 있으므로 public IP, VPN, peering 없이도 internal RFC1918 address(10.20.0.5)를 사용해 서로 라우팅할 수 있습니다. 이는 HTTPS 서비스를 internal-only로 유지하면서 운영 오버헤드를 최소화합니다. 주요 기능 / 구성: - subnet range가 겹치지 않도록 생성합니다(10.20.0.0/20이 이미 존재하므로 10.20.16.0/20은 유효). - firewall rules가 새 VM의 source range(예: 10.20.16.0/20)에서 app-1의 tcp:8443으로의 ingress를 허용하도록 보장합니다. 최소 권한을 위해 network tags 또는 service accounts를 사용합니다. - 실수로 public에 노출되는 것을 줄이려면 external IP를 할당하지 말고 internal DNS/IP에 의존합니다. - 이는 Google Cloud Architecture Framework 가이드와도 일치합니다: 단순하고 managed되며, 가장 복잡도가 낮은 설계를 선호하고, private connectivity와 least-privilege firewalling을 사용합니다. 흔한 오해: 많은 사람들이 리전 간 private connectivity에 Cloud VPN(옵션 C)이 필요하다고 가정합니다. GCP에서는 서로 다른 network를 연결할 때(온프레미스-to-VPC, 또는 HA VPN을 통한 VPC-to-VPC)만 필요하며, 같은 VPC 내부의 두 subnet 간에는 필요하지 않습니다. 또 다른 오해로 VPC peering(옵션 D)이 필요하다고 생각할 수 있는데, peering은 별도의 VPC를 연결하기 위한 것이며 제약(예: transitive routing 불가, 분리된 firewall 관리)이 추가됩니다. 시험 팁: - 기억하세요: VPC = global; subnet = regional. - 리전이 달라도 같은 VPC라면 기본적으로 private routing이 제공되며, 주로 firewall rules만 관리하면 됩니다. - 단순한 VPC 설계로 충분할 때 불필요한 구성요소(VPN, peering, load balancers)를 피하는 해법을 선택하세요. - “internal-only service”의 경우 public load balancers가 아니라 internal IPs + 제한적인 firewall rules에 집중하세요.

4
문제 4

Your company runs a public Nginx download service on a Managed Instance Group of three Compute Engine VMs in us-central1, and the project hosts several other workloads; you need to receive an email when Google Cloud’s measured egress network charges attributable to those Nginx instances exceed 120 dollars for the current calendar month; what should you do?

project 수준 budget은 총 project 지출이 임계값에 도달하면 이메일을 보낼 수 있지만, project에 다른 워크로드가 호스팅되는 경우 Nginx MIG에서 발생한 egress 요금만을 신뢰성 있게 분리해내지 못합니다. service로 필터링하더라도 다른 VM/service의 egress가 포함될 수 있습니다. 이는 “해당 Nginx 인스턴스에 귀속” 요구사항을 충족하지 못하며 false positive/negative 위험이 있습니다.

billing account budget은 project budget보다 범위가 더 넓고, 여러 project에 걸친 전체 지출 거버넌스를 위한 것입니다. budgets가 일부 필터링을 지원하더라도, project 내 특정 MIG 인스턴스에 비용을 귀속시키도록 설계되지 않았습니다. 이는 관련 없는 지출에 대해 알림을 발생시키며 Nginx 인스턴스별 egress 요금 요구사항을 충족하지 못합니다.

리소스 수준 비용 세부정보를 포함한 Billing export to BigQuery는 권위 있는 청구 비용을 제공하며, (사용 설정/가용 시) 리소스 식별자/라벨을 통해 특정 인스턴스에 지출을 귀속시킬 수 있습니다. 라벨이 지정된 Nginx 인스턴스에 대한 네트워크 egress SKU를 쿼리하고 현재 달 합계를 계산하면 요구사항과 정확히 일치합니다. Cloud Scheduler + Cloud Function은 서버를 관리하지 않고도 주기적 평가와 이메일 알림을 제공합니다.

Nginx access logs로 egress 요금을 추정하는 것은 Google Cloud의 청구된 egress와 동일하지 않습니다. 로그는 애플리케이션 페이로드 크기를 반영할 뿐, 청구 가능한 바이트와 반드시 일치하지 않으며 네트워크 과금의 세부사항(티어드 가격, 오버헤드, 재시도, 부분 응답, 기타 egress 경로)을 포착하지 못합니다. 이 접근은 오류 가능성이 높고 운영적으로 취약하며, Google의 측정된 요금이라는 요구사항과 모순됩니다.

문제 분석

핵심 개념: 이 문제는 리소스/워크로드 수준에서 Cloud Billing 비용 귀속(cost attribution)과 알림을 테스트합니다. Cloud Billing의 Budgets 및 알림은 주로 billing account(또는 project) 범위로 설정되며 필터링은 가능하지만, 비용을 해당 리소스에 안정적으로 귀속시킬 수 있는 방법(라벨/리소스 수준 비용 데이터)이 없으면 “특정 Managed Instance Group의 인스턴스에 귀속되는 요금”에 대해 기본적으로 네이티브 알림을 제공하지 않습니다. 정답이 맞는 이유: 옵션 C는 리소스 수준 비용 세부정보를 포함한 Cloud Billing export를 BigQuery로 내보낸 뒤, 현재 달(캘린더 월) 동안 Nginx 인스턴스(라벨, instance ID, 또는 MIG 관련 라벨로 식별)에 해당하는 네트워크 egress SKU만을 프로그램적으로 집계합니다. 이는 “해당 Nginx 인스턴스에 귀속되는 Google Cloud의 측정된 egress 네트워크 요금”이라는 요구사항과 정확히 일치하며, 동일 project 내의 다른 워크로드는 제외합니다. 매시간 점검을 스케줄링하고 임계값 초과 시 이메일을 보내면 적시에 알림을 받을 수 있습니다. 주요 기능 / 모범 사례: - BigQuery로의 Cloud Billing export는 (추정치가 아닌) 권위 있는 측정 비용을 제공합니다. - (사용 설정/가용 시) 리소스 수준 비용 귀속을 통해 라벨/리소스 식별자로 필터링할 수 있어, Google Cloud Architecture Framework의 운영 우수성 원칙(측정 가능한 운영과 실행 가능한 알림)에 부합합니다. - Cloud Scheduler + Cloud Functions는 주기적인 컴플라이언스/재무 점검을 위한 일반적인 serverless 패턴입니다. - 비용 귀속을 견고하게 만들기 위해 MIG 템플릿/인스턴스에 라벨(예: app=nginx-download)을 지정하세요. 흔한 오해: 많은 사람이 budgets가 project 내부의 어떤 리소스 하위 집합에도 알림을 줄 수 있다고 가정합니다. 실제로 budgets는 전체 지출(billing account/project/service)에 가장 적합하며, 특정 MIG의 egress 요금을 분리해내지 못할 수 있습니다. 또 다른 오해는 로그 기반 추정(옵션 D)이 청구된 egress와 동일하다는 것입니다. 이는 CDN/proxying, 프로토콜 오버헤드, 재시도, 압축, 또는 Google의 billing SKU 및 티어링을 반영하지 못합니다. 시험 팁: - 요구사항에 “measured charges”와 “특정 리소스에 귀속(attributable)”이 나오면 Billing export(BigQuery)와 라벨/리소스 수준 비용 데이터를 떠올리세요. - budgets는 광범위한 지출 통제에 사용하고, 세밀한 귀속에는 exports + analytics를 사용하세요. - “current calendar month” 문구를 주의하세요: 쿼리는 invoice month/시간 윈도우로 필터링하고 월 중간 누적(partial-month accrual)을 처리해야 합니다. - quota/비용을 고려하세요: BigQuery 쿼리와 스케줄된 함수는 소액의 비용이 발생하므로, 쿼리를 효율적으로 유지하세요(파티션된 테이블, 필터링된 날짜 범위).

5
문제 5

Your company is launching a high-traffic digital ticketing API in a new Google Kubernetes Engine (GKE) regional cluster in us-central1 with cluster autoscaling enabled (minimum 2 nodes, maximum 20 nodes), and the application can scale from 3 to 50 pods during peak events; you must expose the API to the public over HTTPS using a single global public IPv4 address without modifying application code, and you want Google-managed TLS certificates to terminate HTTPS while supporting rolling updates and pod autoscaling. What should you do?

정답입니다. GKE Ingress와 함께 사용하는 Kubernetes Service를 사용하면 Google Cloud가 애플리케이션 앞에 external HTTP(S) load balancer를 프로비저닝할 수 있습니다. 해당 load balancer에는 하나의 예약된 global static IPv4 address를 할당할 수 있으며, 이는 하나의 global public endpoint 요구 사항을 직접 충족합니다. Google-managed certificates를 연결할 수 있으므로 TLS는 load balancer에서 종료되고, certificate 프로비저닝 및 갱신은 Google이 자동으로 처리합니다. 이 접근 방식은 rolling updates 및 autoscaling과도 잘 작동하는데, pod와 node가 시간에 따라 변경되더라도 load balancer가 정상적이고 준비된 backend로만 트래픽을 전달하기 때문입니다.

오답입니다. ClusterIP Service는 cluster 내부 또는 연결된 internal network에서만 도달할 수 있으며 public internet endpoint가 아닙니다. Public DNS가 private ClusterIP로 클라이언트를 의미 있게 가리켜 서비스를 인터넷에서 접근 가능하게 만들 수는 없습니다. 또한 이 옵션은 global public IPv4 address나 Google-managed HTTPS termination point도 제공하지 않습니다. 따라서 이 시나리오의 networking 및 TLS 요구 사항을 모두 충족하지 못합니다.

오답입니다. 모든 node에서 NodePort를 노출하고 모든 node IP를 DNS에 게시하는 방식은 명시적으로 요구되는 단일 global public IPv4 address를 제공하지 않습니다. 또한 cluster autoscaling이 node를 추가하고 제거하므로 node IP 집합이 시간에 따라 변경되어 운영적으로도 취약합니다. DNS 기반 분산은 centralized TLS termination, 상태를 인식한 request routing, 업데이트 중 적절한 backend draining과 같은 managed Layer 7 HTTPS 기능을 제공하지 않습니다. 따라서 이 설계는 신뢰성, 관리 용이성 또는 certificate 요구 사항을 충족하지 못합니다.

오답입니다. pod에서 HAProxy를 실행하고 하나의 node external IP를 통해 트래픽을 전달하는 방식은 불필요한 custom load-balancing 계층을 만들고 단일 장애 지점을 초래할 가능성이 높습니다. 하나의 node IP는 Google-managed global anycast IPv4 address와 동일하지 않으며, 이 설계에서는 failover, health checks, proxy lifecycle을 직접 관리해야 합니다. 또한 managed TLS certificates와 원활한 backend updates를 지원하는 기본 GKE Ingress 통합도 우회하게 됩니다. 이 옵션은 복잡성만 증가시키면서, 명시된 global public endpoint 및 managed HTTPS 목표를 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 단일 global IPv4 address, Google-managed TLS, 그리고 autoscaling 및 rolling updates와의 호환성 요구사항을 충족하면서 Kubernetes Ingress를 사용하는 Google Cloud Load Balancing으로 GKE workload를 HTTPS로 공개적으로 노출하는 방법을 평가합니다. 정답이 맞는 이유: 옵션 A는 표준 GKE 패턴을 사용합니다: Service(일반적으로 Ingress와 함께 사용할 때 NodePort)와 Kubernetes Ingress를 통해 Google Cloud external HTTP(S) Load Balancer를 프로비저닝합니다. 이 load balancer는 global(anycast)이며 단일 reserved global static IPv4 address를 할당할 수 있습니다. Google-managed certificates(클러스터 버전에 따라 GKE Ingress + ManagedCertificate 또는 Certificate Manager integration)를 사용하면 Google이 TLS를 자동으로 프로비저닝/갱신하고 load balancer에서 HTTPS를 종료(terminate)할 수 있어 애플리케이션 코드 변경이 필요 없습니다. 주요 기능 및 모범 사례: - Global external HTTP(S) Load Balancer: 단일 global IPv4, cross-region edge termination, L7 routing을 제공합니다. - Google-managed TLS: 운영을 단순화하고 Google Cloud Architecture Framework의 reliability 및 security pillar(자동화된 cert lifecycle, 강력한 기본값)와 정렬됩니다. - GKE autoscaling과 함께 동작: Ingress LB는 node instance groups(또는 활성화 시 NEGs)를 대상으로 합니다. cluster autoscaler가 노드를 추가/제거하고 HPA가 pods를 스케일링하면 backend membership이 자동으로 업데이트됩니다. - Rolling updates: Kubernetes Deployments는 pods를 점진적으로 업데이트하며, load balancer health checks와 readiness gates가 트래픽이 준비된 endpoints로만 전달되도록 보장합니다. 흔한 오해: - Service IP 타입 혼동: ClusterIP는 internal-only이며 public internet에서 접근할 수 없습니다. - DNS가 node IP를 나열하면 “load balance”가 된다고 생각: autoscaling 하에서 nodes는 ephemeral이므로 단일 global IP 요구사항을 깨뜨립니다. - 클러스터 내부에 custom LBs(HAProxy) 구축: 운영 부담을 늘리고 single points of failure를 만들며, global anycast IP 또는 managed TLS를 제공하지 않습니다. 시험 팁: GKE에서 “single global public IPv4”, “HTTPS”, “Google-managed certificates”를 보면 기대되는 해법은 external HTTP(S) Load Balancer와 reserved global static IP를 사용하는 Ingress입니다. 기억하세요: ClusterIP는 internal이고, NodePort는 보통 Ingress와 함께 사용되며, production-grade의 autoscaled GKE 서비스에서는 DIY load balancers를 피해야 합니다.

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

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

6
문제 6

You plan to migrate the following on-premises workloads to Google Cloud: • One Microsoft SQL Server Always On cluster supporting a 12 TB transactional database for a global user base with peak 45,000 writes/second • Apache Pulsar handling ~1.5 million messages per minute for event streaming and fan-out • A self-managed PostgreSQL instance used exclusively for BI dashboards and ad-hoc analytics (7 years of data, ~40 TB compressed) You must adopt Google-recommended, fully managed services that minimize operational overhead, provide global scalability, and offer built-in high availability with cross-region consistency targets (RPO≈0, ≥99.99% availability). What should you do?

Cloud SQL for SQL Server는 운영 부담을 줄이지만, 기본적으로 리전 중심이며 일반적으로 리전 내 HA + 리전 간 DR(read replicas/backup/restore)에 의존합니다. 이는 거의 0 RPO에 가까운 글로벌 분산 strong consistency와는 다릅니다. Pub/Sub와 BigQuery는 스트리밍과 분석에 대한 올바른 선택이지만, 트랜잭션 데이터베이스 요구사항(글로벌 규모, 매우 높은 쓰기, 리전 간 일관성, ≥99.99%)은 Cloud SQL이 아니라 Spanner를 선택하게 만듭니다.

Spanner + Pub/Sub + BigQuery가 제시된 요구사항에 가장 잘 부합합니다. Spanner는 글로벌 OLTP와 고가용성을 위해 설계된 Google의 관리형, 수평 확장 가능, strong consistency, 멀티 리전 관계형 데이터베이스입니다. Pub/Sub는 브로커 관리 없이 Pulsar를 대체할 수 있는 고처리량 이벤트 수집 및 fan-out용 관리형 서비스입니다. BigQuery는 대규모 장기 데이터셋과 ad-hoc BI 쿼리에 적합한 관리형 분석 웨어하우스로, 운영 오버헤드를 최소화합니다.

Spanner는 글로벌 트랜잭션 데이터베이스에 적합하지만, Memorystore는 Pulsar의 대체재가 아닙니다. Memorystore(Redis/Memcached)는 선택적 복제를 제공하는 in-memory cache이지, subscriptions, retention, fan-out 시맨틱을 갖춘 durable streaming 플랫폼이 아닙니다. 또한 40 TB 분석 워크로드를 Cloud SQL로 옮기면 운영 부담이 증가하고, BigQuery의 columnar, serverless warehouse 모델에 비해 ad-hoc analytics에서 성능이 떨어지거나 비용이 더 들 가능성이 큽니다.

이 선택지는 두 워크로드를 잘못 매핑합니다. Memorystore는 Pulsar의 durable event streaming 및 fan-out을 대체할 수 없습니다. Cloud SQL for SQL Server와 PostgreSQL은 관리형이지만, 트랜잭션 시스템 요구사항이 암시하는 글로벌, strong consistency, 멀티 리전 가용성 및 거의 0에 가까운 RPO를 본질적으로 제공하지는 않습니다. 또한 대규모 분석(40 TB, ad-hoc queries)에 Cloud SQL을 사용하는 것은 일반적으로 BigQuery보다 확장성과 운영 단순성 측면에서 열등합니다.

문제 분석

핵심 개념: 이 문제는 초대규모 확장, 멀티 리전 고가용성, 그리고 거의 0에 가까운 RPO를 충족하는 Google 권장 완전관리형 데이터 서비스를 선택하는지를 평가합니다. 핵심 구분은 리전 단위 관리형 데이터베이스(Cloud SQL)와 전 세계적으로 분산되며 강한 일관성을 제공하는 데이터베이스(Cloud Spanner)의 차이, 그리고 스트리밍/이벤트 fan-out(Pub/Sub)과 캐싱(Memorystore), 분석용 웨어하우징(BigQuery)의 차이입니다. 정답이 맞는 이유: 매우 높은 쓰기 처리량과 리전 간 일관성 목표(RPO≈0, ≥99.99%)를 갖는 12 TB 글로벌 트랜잭션 시스템에는 Cloud Spanner가 적합합니다. Cloud Spanner는 수평 확장, 멀티 리전 배포, 그리고 적절한 구성(멀티 리전 instance configuration) 시 고가용성 SLA와 함께 강한 일관성을 제공하도록 설계된 관리형 서비스입니다. Cloud SQL for SQL Server도 관리형이지만 기본적으로 리전 중심이며 read replica/DR 패턴에 의존합니다. 요구사항이 암시하는 글로벌, 강한 일관성의 멀티 리전 active-active 특성을 동일하게 네이티브로 제공하지는 않습니다. Apache Pulsar의 약 1.5M messages/min fan-out 요구에는 Pub/Sub가 적합합니다. Pub/Sub는 브로커를 운영하지 않고도 높은 처리량, at-least-once 전달, (필요 시) ordering, 그리고 리전 간 내구성을 지원하는 Google의 완전관리형 글로벌 메시징 서비스입니다. BI/ad-hoc analytics에 사용되는 40 TB 압축 PostgreSQL에는 BigQuery가 권장되는 완전관리형 분석 웨어하우스입니다. columnar storage, compute/storage 분리, 내장 고가용성, 그리고 네이티브 BI 통합을 제공합니다. 대규모 Postgres 인스턴스를 분석용으로 튜닝/partitioning/vacuuming 하는 운영 오버헤드를 피할 수 있습니다. 주요 기능 / 구성: Cloud Spanner: 멀티 리전 instance configuration을 선택하고, 쓰기 처리량에 맞게 nodes/processing units를 산정하며, 분산 쓰기에 적합한 스키마를 설계(핫스팟 방지)하고, Spanner의 strong consistency 및 자동 복제를 활용합니다. Pub/Sub: fan-out을 위해 topics/subscriptions를 사용하고, 필요할 때만 ordering keys를 고려하며, ack deadlines/flow control을 튜닝합니다. BigQuery: 7년치 데이터를 위해 테이블을 partition/cluster하고, 대시보드 가속이 필요하면 BI Engine을 사용하며, reservations 또는 autoscaling으로 비용을 제어합니다. 흔한 오해: Cloud SQL은 “완전관리형”이지만, 99.99%+ 멀티 리전 기대치와 함께 글로벌 일관성이 필요한 초고쓰기 워크로드에는 최적의 선택이 아닙니다. Memorystore는 종종 스트리밍과 혼동되지만, 이는 durable event bus가 아니라 in-memory cache입니다. 시험 팁: 워크로드 유형을 서비스에 매핑하세요: strong consistency를 갖는 글로벌 OLTP → Spanner; event streaming/fan-out → Pub/Sub; 대규모 analytics/BI → BigQuery. “global”, “RPO≈0”, “≥99.99%” 같은 키워드는 보통 리전 HA + DR이 아니라 멀티 리전 네이티브 서비스를 의미합니다.

7
문제 7

During a quarterly compliance audit at a fintech company, you must determine exactly which principals can currently view customer data stored in the Google Cloud project pay-ops-prod. The data resides in 9 Cloud Storage buckets and 15 BigQuery datasets, with access assigned via predefined and custom IAM roles at the project, bucket, and dataset levels; you need an action that identifies who has read/view permissions now without scanning data contents or relying on historical access logs—what should you do?

Data Access audit log는 로깅이 활성화된 이후의 실제 데이터 읽기(예: object read, BigQuery table read)를 기록하기 위한 것입니다. 현재 누가 권한을 가지고 있는지를 직접 열거하지 않으며, 과거 액세스에 의존하지 않고 entitlement 스냅샷이 필요할 때는 도움이 되지 않습니다. 또한 이전에 로그가 활성화되어 있지 않았다면, 이를 통해 과거 액세스를 재구성할 수 없습니다.

정답입니다. 프로젝트, bucket, dataset 수준에서 IAM policy binding을 검토하고 역할(사전 정의 및 커스텀)을 read/view 권한에 매핑하는 것이 현재 유효 액세스를 판단하는 올바른 방법입니다. 이 접근은 데이터 콘텐츠를 스캔하거나 audit 기록에 의존하지 않고, 지금 권한이 부여된 principal을 식별합니다. 또한 상속된 권한과 read 액세스를 포함하는 광범위한 역할을 분석하는 데도 도움이 됩니다.

Identity-Aware Proxy는 지원되는 HTTPS 진입점을 통해 노출된 웹 애플리케이션 및 서비스에 대한 access를 보호하는 것이지, Cloud Storage bucket이나 BigQuery dataset에 대한 직접적인 data-plane authorization을 담당하지 않습니다. Cloud Storage와 BigQuery access는 IAM에 의해 결정되며, Cloud Storage의 경우 uniform bucket-level access가 비활성화되어 있으면 legacy ACL의 영향도 받을 수 있습니다. 따라서 IAP 설정을 검토해도 어떤 principal이 object를 읽거나 dataset 내용을 보거나 query할 수 있는지에 대한 권위 있는 목록을 제공할 수 없습니다. 이는 다른 control plane을 다루며, 이 감사에 실제로 관련된 permission을 놓치게 됩니다.

Cloud DLP는 콘텐츠를 스캔(또는 샘플링)하여 민감 데이터를 발견하고 분류하며, 데이터 유형과 위험에 대한 finding을 생성하도록 설계되었습니다. 어떤 principal이 액세스할 수 있는지에 대한 권위 있는 보고서를 생성하지 않습니다. 또한 문제에서 데이터 콘텐츠 스캔을 명시적으로 금지하고 있는데, 이는 DLP 목적의 핵심입니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서의 authorization 분석을 테스트합니다. 즉, access policy와 부여된 role에 포함된 permission을 평가하여 현재 어떤 principal이 Cloud Storage bucket과 BigQuery dataset에 대한 유효한 read access를 가지고 있는지 판단하는 것입니다. 이는 과거에 누가 실제로 접근했는지를 확인하는 것이 아니며, 데이터 자체를 검사하는 것도 아닙니다. 정답인 이유: 현재 정확히 어떤 principal이 customer data를 볼 수 있는지 확인하려면, 관련된 모든 범위에서 현재 access configuration을 검사하고 부여된 role을 실제 read permission에 매핑해야 합니다. BigQuery의 경우, project 및 dataset 수준의 IAM binding을 검토하고 predefined role 또는 custom role에 bigquery.tables.getData 또는 관련 metadata/view permission이 포함되어 있는지 확인해야 합니다. Cloud Storage의 경우, project 및 bucket 수준의 IAM binding을 검토해야 하며, uniform bucket-level access가 활성화되어 있지 않다면 bucket 및 object ACL도 함께 확인해야 합니다. ACL이 독립적으로 read access를 부여할 수 있기 때문입니다. 이렇게 하면 historical log에 의존하거나 데이터 내용을 스캔하지 않고 현재 시점의 entitlement view를 얻을 수 있습니다. 주요 기능 / 모범 사례: Console, gcloud 또는 API를 통해 project와 각 bucket 및 dataset의 IAM policy를 검사하세요. Custom role을 펼쳐서 read/view permission이 포함되어 있는지 확인하고, 더 넓은 project 수준 role에서 상속된 access도 고려하세요. Cloud Storage의 경우, uniform bucket-level access가 활성화되어 있는지 확인하세요. 활성화되어 있지 않다면 IAM만으로는 모든 유효한 reader를 보여주지 못하므로 검토에 legacy ACL도 포함해야 합니다. 또한 유효한 access를 계산할 때 group membership과 allUsers 또는 allAuthenticatedUsers 같은 special principal도 고려하세요. 흔한 오해: Audit log는 logging이 활성화된 이후 실제로 누가 데이터에 접근했는지를 보여줄 뿐이며, 현재 권한이 있는 모든 사용자를 보여주지는 않습니다. Cloud DLP는 entitlement를 보고하는 것이 아니라 데이터 내용을 분류하고 검사합니다. IAP는 Cloud Storage bucket 및 BigQuery dataset에 대한 직접적인 authorization과는 관련이 없습니다. 시험 팁: 문제에서 '지금 누가 접근할 수 있는가'를 묻는다면, 현재 IAM policy, resource 수준 grant, custom role permission 확장, 그리고 UBLA가 비활성화된 경우 Cloud Storage ACL 같은 서비스별 access mechanism을 떠올리세요. '누가 접근했는가'를 묻는다면 audit log를 떠올리세요. 항상 entitlement 분석과 activity 분석을 구분하세요.

8
문제 8

Your security team needs to grant SSH access to a single VM named edge-proxy-01 in project film-prod-2468 (zone europe-west1-b) only for members of the Google Group qa1 (8 users), ensuring they cannot access any other VM in the project and preferring a Google-recommended, centrally managed approach that works from Cloud Shell without distributing private keys; what should you do?

정답입니다. edge-proxy-01에서 `enable-oslogin=true`를 활성화하면 해당 VM의 SSH 인가가 OS Login으로 전환됩니다. qa1 Google Group에 인스턴스 범위로 `compute.osLogin`을 부여하면 해당 사용자들만 그 특정 VM에 SSH할 수 있고 프로젝트의 다른 곳에는 접근할 수 없습니다. Cloud Shell에서 `gcloud compute ssh`를 사용하면 액세스가 Google identity와 IAM에 연결되므로 private key를 배포하지 않고도 동작합니다.

오답입니다. OS Login 활성화는 좋지만, VM의 service account를 “No service account”로 변경하는 것은 사용자 SSH 액세스와 무관합니다. service accounts는 VM이 액세스할 수 있는 대상(outbound API calls)을 제어할 뿐, 누가 SSH로 접속할 수 있는지는 제어하지 않습니다. 또한 이 옵션은 qa1 group에 인스턴스 범위로 OS Login 권한을 명시적으로 부여하지 않으므로 액세스 제어 요구사항을 충족하지 못합니다.

오답입니다. Block project-wide SSH keys는 상속된 메타데이터 키를 제한하는 데 도움이 될 수 있지만, 각 사용자에게 고유 SSH 키를 생성하고 배포하는 것은 private key 배포를 피하라는 요구사항을 위반하며 Google이 권장하는 중앙 관리 방식도 아닙니다. 또한 OS Login + IAM + Google Groups에 비해 운영 부담(rotate, revoke, audit)이 증가합니다.

오답이며 안전하지 않습니다. 여러 사용자가 하나의 private key를 공유하면 accountability와 non-repudiation이 깨져 개별 사용자별로 행위를 귀속시키는 것이 불가능해집니다. 또한 key management Best Practices 및 private key 배포를 피하라는 요구사항을 위반합니다. project-wide keys를 차단하더라도 이 접근은 IAM을 통한 중앙 관리가 아니며 운영상 위험합니다.

문제 분석

핵심 개념: 이 문제는 Compute Engine에서 OS Login 및 IAM 기반 SSH 액세스 제어를 테스트합니다. OS Login은 인스턴스/프로젝트 메타데이터를 통해 SSH 키를 배포하고 관리하는 대신, IAM ID(google Groups 포함)를 사용해 Linux SSH 액세스를 중앙에서 관리하기 위한 Google의 권장 접근 방식입니다. 정답인 이유: 옵션 A는 대상 VM(edge-proxy-01)에만 OS Login을 활성화하고, qa1 Google Group에 해당 단일 인스턴스 범위로 적절한 OS Login IAM role을 부여합니다. 이렇게 하면 구성원은 해당 VM에는 SSH할 수 있지만, 프로젝트의 다른 VM에는 OS Login 권한이 없으므로 SSH할 수 없습니다. 또한 private key를 배포하지 않고 Cloud Shell에서 작업해야 한다는 요구사항도 충족합니다. 사용자는 `gcloud compute ssh`를 실행할 수 있으며, 이는 Google identity와 OS Login을 사용해 ephemeral SSH credentials를 프로비저닝합니다. 주요 기능 / Best Practices: - 인스턴스 수준 메타데이터 `enable-oslogin=true`는 동작을 단일 VM로 제한하여 least privilege에 부합합니다. - IAM binding을 프로젝트가 아니라 인스턴스 리소스에 적용하면 해당 VM로만 액세스를 제한합니다. - Google Groups를 IAM policy에서 직접 사용할 수 있어 8명의 사용자 관리가 단순해집니다. - Cloud Shell + `gcloud compute ssh`는 OS Login과 깔끔하게 통합되며 수동 키 배포를 피할 수 있습니다. - 이는 Google Cloud Architecture Framework 보안 원칙(centralized identity, least privilege, auditable access: IAM 변경 및 OS Login 활동에 대한 Cloud Audit Logs)과 일치합니다. 흔한 오해: 많은 사람이 “Block project-wide SSH keys”가 최고의 보안 제어라고 가정합니다. 키 확산을 줄일 수는 있지만, 여전히 키 생성/배포에 의존하며 OS Login과 같은 중앙집중식 IAM 기반 액세스 모델을 제공하지 못합니다. 또 다른 오해는 VM service account를 제거하면 SSH 액세스에 영향을 준다는 것인데, 그렇지 않습니다. Exam Tips: - “centrally managed SSH”와 “no private key distribution”이 나오면 OS Login을 떠올리세요. - 단일 VM로 SSH를 제한하려면 IAM binding 범위를 프로젝트가 아니라 인스턴스로 지정하세요. - role 선택을 기억하세요: `compute.osLogin`은 일반 SSH용, `compute.osAdminLogin`은 sudo/admin 액세스용입니다. 요구사항을 만족하는 최소 권한 role을 선택하세요.

9
문제 9

In your company’s Google Cloud organization, the qa-analytics-123 project contains 12 custom IAM roles that you must replicate exactly (same role IDs, titles, and permissions) to a new staging project stg-analytics-123 in the same organization, and you want to accomplish this in the fewest possible steps without promoting the roles to the organization level or manually re-selecting permissions; what should you do?

정답입니다. gcloud iam roles copy는 custom role 정의를 한 parent(project)에서 다른 parent로 복제하기 위해 의도된 기능입니다. permissions와 메타데이터를 보존하며, destination을 project 레벨(stg-analytics-123)로 유지하여 role을 organization으로 승격하지 말라는 요구사항을 충족할 수 있습니다. 또한 permissions를 수동으로 다시 선택하는 과정을 피하여 오류와 단계를 최소화합니다.

오답입니다. Role을 organization으로 복사하면 스코프가 project-level에서 org-level로 변경되어 모든 project에서 role을 사용할 수 있게 됩니다. 문제는 role을 organization 레벨로 승격하지 말라고 명시합니다. Org-level role은 표준화에 유용할 수 있지만, 제시된 제약을 위반하며 여기서 가장 적절한 조치가 아닙니다.

오답입니다. Google Cloud Console은 “replicate exactly” 및 “fewest steps” 요구사항을 충족하는, “다른 project에서 동일한 role ID로 role을 clone/copy”하는 간단한 워크플로를 일관되게 제공하지 않습니다. 기존 role을 기반으로 만들 수 있더라도, 일반적으로 role마다 편집 및 저장을 해야 하며, project 간 정확한 ID 보존은 Console의 주요 경로가 아닙니다.

오답입니다. 12개의 role을 수동으로 생성하고 permissions를 다시 선택하는 것은 시간이 많이 들고 오류가 발생하기 쉬우며, 수동 permission 선택을 피하라는 요구사항과 정면으로 배치됩니다. 이 접근은 QA와 staging 간 구성 drift 위험을 높이며, 반복 가능한 IAM 구성에 대한 모범 사례에도 부합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 IAM custom role 관리와 이식성을 테스트합니다. Custom role은 project 또는 organization 범위로 스코프가 지정됩니다. Project-level custom role은 projects/PROJECT_ID/roles/ROLE_ID 아래에 존재하며 다른 project에서 자동으로 사용할 수 없습니다. 최소한의 노력으로 다른 project에 role을 “정확히” (동일한 role ID, title, permissions) 복제하려면 gcloud CLI의 role copy 기능을 사용해야 합니다. 정답이 맞는 이유: 옵션 A는 gcloud iam roles copy를 사용하여 qa-analytics-123의 각 custom role 정의를 stg-analytics-123으로 복사합니다. 이는 permissions를 수동으로 다시 선택하지 않고도 role 정의를 보존하는 가장 적은 단계의 접근 방식입니다. 또한 role을 project 스코프에 유지하므로 organization 레벨로 승격하지 말라는 요구사항을 충족합니다. Copy 작업은 기존 custom role을 다른 상위 리소스(다른 project)로 복제하는 이 사용 사례를 위해 설계되었습니다. 주요 기능 / 모범 사례: - Custom role은 메타데이터(roleId, title, description, stage)와 permissions 목록을 가진 리소스입니다. Copying은 인적 오류를 줄이고 환경(QA vs staging) 간 동등성을 보장합니다. - 소스에 대해 iam.roles.get, 대상 project에 대해 iam.roles.create(그리고 경우에 따라 iam.roles.update) 같은 적절한 permissions가 필요합니다. - Role ID는 대상 project 내에서 고유해야 합니다. “정확히” 복제한다는 것은 대상 project에 동일한 ID의 role이 아직 없음을 의미합니다. - Architecture Framework 관점(Security, Reliability, Operational Excellence)에서 automation/CLI 사용은 drift를 줄이고 환경 간 반복 가능성을 향상시킵니다. 흔한 오해: 일부는 project 간 공유를 위해 role을 organization으로 승격해야 한다고 가정합니다(옵션 B). 이는 불필요하며 요구사항을 위반합니다. 또 다른 일부는 Console에서 “clone role” 워크플로(옵션 C)를 찾지만, Console은 일반적으로 role 생성/편집이 필요하고, 수동 단계 없이 ID를 보존하며 project에서 project로 진정한 bulk/clone 기능을 제공하지 않을 수 있습니다. 시험 팁: - 스코프 경계를 기억하세요: project custom role은 copy 또는 재생성하지 않는 한 project 간 재사용이 불가능합니다. - 반복 가능한 IAM 구성을 위해 gcloud/automation을 선호하여 permission 선택 실수를 피하세요. - 문제가 “fewest steps”와 “replicate exactly”를 강조하면, 수동 재생성보다 직접적인 copy/export-import 메커니즘을 찾으세요.

10
문제 10

Your team is deploying a real-time telemetry aggregator on Cloud Run in us-central1 that must process events from a Pub/Sub topic named iot-telemetry within 2 seconds of publish, handle bursty loads up to 25,000 messages per minute with at-least-once delivery, and require authenticated requests using your own service account while keeping minimum instances at 0; to follow Google-recommended practices, what should you do?

기능적으로는 동작하지만 Pub/Sub가 Cloud Run으로 직접 push할 수 있을 때 Google 권장 방식이 아닙니다. 추가 홉(Pub/Sub -> Cloud Functions -> Cloud Run)을 도입하여 2초 요구사항에 대한 지연 위험을 높이고 비용 및 운영 복잡성을 증가시킵니다. 또한 확장 및 보안이 필요한 구성요소가 하나 더 생기며, 함수 호출이나 아웃바운드 HTTP 호출이 throttle되면 버스트 동안 병목이 될 수 있습니다.

pull subscription은 Cloud Run 서비스가 Pub/Sub를 능동적으로 polling해야 합니다. 이는 보통 지속 실행되는 worker 또는 스케줄 기반 polling을 의미하므로 min instances를 0으로 유지하는 것과 충돌하고 end-to-end 지연 시간을 증가시킬 수 있습니다. 동작하도록 만들 수는 있지만, 특히 준실시간 전달이 필요한 경우 Pub/Sub에서 Cloud Run으로 이벤트를 수집하는 권장 serverless 패턴은 아닙니다.

이는 권장 패턴입니다. Pub/Sub push subscription이 HTTPS를 통해 Cloud Run으로 메시지를 전달하고, OIDC 인증은 전용 service account를 사용합니다. 해당 service account에 Cloud Run Invoker를 부여하면 Pub/Sub(그 아이덴티티 사용)만 서비스 호출이 가능해집니다. Cloud Run autoscaling과 Pub/Sub retries(at-least-once)를 통해 scale-to-zero, 낮은 지연 시간, 버스트 처리까지 지원합니다.

Cloud Run for GKE와 sidecar relay를 실행하는 것은 이 요구사항에 불필요한 복잡성이며 관리형 serverless 모범 사례와도 맞지 않습니다. 클러스터 관리 오버헤드, 네트워킹 고려사항, 실패할 수 있는 추가 구성요소를 더합니다. 또한 Cloud Run fully managed의 단순성과 비용 모델을 훼손하며, 의도된 Associate 수준 해법일 가능성이 낮습니다.

문제 분석

핵심 개념: 이 문제는 Pub/Sub와 Cloud Run 간의 권장 통합 패턴을 테스트합니다. 구체적으로는 OIDC를 사용한 인증된 호출로 HTTPS 엔드포인트에 push 전달을 수행하면서, Cloud Run의 scale-to-zero 동작을 유지하고 낮은 지연 시간 및 버스트성 처리량 요구사항을 충족하는 방식입니다. 정답이 맞는 이유: 옵션 C는 Pub/Sub push subscription을 사용하여 메시지를 Cloud Run 서비스의 HTTPS 엔드포인트로 직접 전달합니다. Pub/Sub push는 이벤트 기반(폴링 없음)이므로 “publish 후 2초 이내” 요구사항을 충족하는 데 도움이 되며, Pub/Sub가 전달을 fan out하고 Cloud Run autoscaling이 필요에 따라 인스턴스를 추가하므로 버스트성 부하(25,000 messages/min)도 지원합니다. At-least-once delivery는 Pub/Sub의 고유 특성이므로, Cloud Run은 idempotent해야 하며 재전달을 방지하려면 성공적으로 처리한 후에만 2xx를 반환해야 합니다. “자체 service account를 사용한 authenticated requests” 요구사항은 push subscription이 전용 service account에 대해 발급된 OIDC token을 첨부하도록 구성하고, 해당 service account에 서비스의 Cloud Run Invoker role을 부여함으로써 충족됩니다. 이는 Pub/Sub가 호출하는 Cloud Run 엔드포인트를 보안 처리하기 위한 Google 권장 방식입니다. 주요 기능 및 구성: - 지연 시간을 줄이기 위해 동일 리전(us-central1)의 Cloud Run HTTPS URL로 Pub/Sub push subscription 구성. - OIDC token 인증: push subscription에 service account를 구성하고, Cloud Run은 Cloud Run Invoker를 통해 IAM을 검증. - min instances를 0으로 유지: push 전달은 scale-to-zero와 함께 동작하며, polling 패턴은 종종 항상 켜져 있는 compute를 필요로 함. - 처리량 제어: Cloud Run concurrency와 max instances를 튜닝하고, Pub/Sub ack deadline 및 retry/backoff 동작을 고려. 흔한 오해: - Cloud Functions를 릴레이로 사용하는 것(옵션 A)은 불필요한 홉, 추가 비용, 추가 장애 지점을 만들며, Pub/Sub가 Cloud Run으로 직접 push할 수 있을 때 권장 아키텍처가 아닙니다. - pull subscription(옵션 B)은 단순해 보이지만 polling worker가 필요하여 scale-to-zero와 충돌하고 지연 시간을 증가시킬 수 있습니다. - 복잡한 GKE 기반 릴레이(옵션 D)는 Associate 수준 시나리오에 과도한 설계이며 Cloud Run의 관리형 단순성을 훼손합니다. 시험 팁: “Pub/Sub to Cloud Run” + “authenticated requests” + “min instances 0”을 보면, Pub/Sub push subscription + OIDC token + 전용 service account에 대한 Cloud Run Invoker를 떠올리세요. 또한 Pub/Sub는 at-least-once이므로 idempotent handler로 설계하고 성공 시에만 2xx를 반환해야 한다는 점을 기억하세요.

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

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

11
문제 11

Your organization runs a low-latency telemetry collector on Google Kubernetes Engine (GKE) in us-central1 with cluster autoscaling enabled. The application listens on TCP port 7000 and has 5 replicas. A separate Compute Engine VM named parser-1 runs in the same region but in a different VPC named analytics-vpc (CIDR 10.20.0.0/16) than the GKE cluster's VPC named stream-vpc (CIDR 10.10.0.0/16). There is no VPC peering or Cloud VPN between the networks, and the IP ranges do not overlap. The VM must initiate TCP connections to the collector service. You want the simplest solution with the least operational effort. What should you do?

정답입니다. type LoadBalancer인 Service는 collector를 안정적인 public IP를 가진 managed external TCP load balancer로 노출합니다. VPC 간 peering/VPN이 없더라도 parser-1은 port 7000에서 external IP로 outbound TCP 연결을 시작할 수 있습니다. externalTrafficPolicy=Cluster는 autoscaling 중에 replica가 이동하더라도 어떤 노드든 트래픽을 수신하고 ready pod로 포워딩할 수 있어 가용성을 향상합니다.

오답입니다. dual-NIC proxy VM에 iptables forwarding을 구성하는 방식은 복잡하고 운영 부담이 큽니다. 라우팅, firewall rules, NAT/forwarding, 상태(health), scaling, proxy의 patching을 모두 관리해야 합니다. 또한 HA를 구성하지 않으면 단일 장애 지점이 됩니다. 이는 가장 단순한 솔루션이 아니며, managed load balancing 또는 managed private connectivity 옵션에 비해 일반적으로 anti-pattern입니다.

“운영 노력이 최소”라는 조건에서 오답입니다. internal load balancer는 private connectivity를 통해서만 도달 가능합니다. VPC peering을 생성하면 설정 및 지속적인 네트워크 관리(라우트, IAM permissions, 잠재적인 DNS 고려사항)가 필요합니다. private 설계로는 좋을 수 있지만, 기존 연결이 없는 상황과 요구사항을 고려하면 가장 단순하지 않습니다.

오답입니다. 소스 제한은 좋은 보안 아이디어이지만, Cloud Armor는 GKE Service type LoadBalancer가 생성하는 TCP Network Load Balancer에 대한 직관적/표준적인 제어가 아닙니다. Cloud Armor는 주로 HTTP(S) load balancing 및 특정 proxy LB에서 사용됩니다. TCP NLB의 경우 일반적으로 VPC firewall rules 및 기타 제어에 의존합니다. 이 옵션은 오해를 유발하며 가장 단순한 정답 접근이 아닙니다.

문제 분석

핵심 개념: 이 문제는 private connectivity 없이 네트워크 간 GKE Service 노출 패턴을 테스트합니다. stream-vpc와 analytics-vpc 사이에 VPC peering/VPN/Interconnect가 없으므로, VM은 GKE VPC의 어떤 private (RFC1918) IP에도 도달할 수 없습니다. 따라서 collector는 도달 가능한 엔드포인트로 노출되어야 하며, 가장 단순한 방법은 public external load balancer IP입니다. 정답이 맞는 이유: 옵션 A는 type LoadBalancer인 GKE Service를 사용하며, 이는 (port 7000 같은 TCP 서비스에 대해) Google Cloud external TCP/UDP Network Load Balancer를 프로비저닝합니다. analytics-vpc의 VM은 네트워크 간 별도 구성 없이 인터넷(또는 Google의 edge)을 통해 Service의 external IP로 outbound 연결을 시작할 수 있습니다. 이는 운영 노력이 가장 적습니다: peering 없음, 라우팅 변경 없음, proxy VM 없음. 또한 Service가 지속적으로 정상 backend(노드/파드; kube-proxy/health checks를 통해)를 추적하므로 cluster autoscaling과도 잘 동작합니다. 주요 기능 및 모범 사례: - Service type LoadBalancer는 안정적인 VIP와 managed load balancing을 제공합니다. - externalTrafficPolicy=Cluster는 어떤 노드든 트래픽을 수신하고 클러스터 전반의 ready pod로 포워딩할 수 있게 하여, autoscaling/업데이트로 파드가 이동할 때 복원력을 높입니다. - 여전히 노드에 대한 VPC firewall rules(LB health checks 및 트래픽용) 및/또는 적용 가능하다면 Kubernetes NetworkPolicy로 접근을 제한해야 합니다. 하지만 핵심 연결 요구사항은 최소 설정으로 충족됩니다. 흔한 오해: - “Internal” load balancer(옵션 C)는 격리된 VPC 간에 도달할 수 없으며, VPC peering/VPN 같은 private connectivity가 필요합니다. - Cloud Armor(옵션 D)는 어떤 load balancer든 보호한다고 흔히 생각하지만, Cloud Armor는 주로 HTTP(S) Load Balancing 및 일부 proxy 기반 LB를 대상으로 합니다. GKE Service가 생성하는 기본 TCP Network Load Balancer에 대한 올바르고 단순한 제어가 아닙니다. - transit proxy(옵션 B)를 구축하는 것도 가능하지만 운영 부담이 크며, managed connectivity 대비 일반적으로 권장되지 않습니다. 시험 팁: 두 VPC에 peering/VPN이 없고 IP range가 겹치지 않으면, public endpoint만 도달 가능하다고 가정하세요. GKE에서는 가장 단순한 cross-network 접근이 보통 external IP를 가진 Service type LoadBalancer입니다. internal load balancer는 private connectivity가 있을 때만 사용하세요. 또한 autoscaling은 고정 노드 IP나 수동 backend 관리에 의존하지 않는 솔루션을 선호한다는 점을 기억하세요.

12
문제 12

Your team runs a video-recommendation API on a managed instance group behind an HTTP(S) load balancer, with autoscaling configured to add instances when average CPU utilization exceeds 75% and to stop scaling out when CPU drops to 75% or the group reaches a maximum of 6 VMs; HTTP health checks use an initial delay of 20 seconds, but each VM takes about 2 minutes and 40 seconds to finish startup scripts and accept requests, and during traffic spikes you notice the group repeatedly adds more instances than necessary because new VMs are not yet serving traffic and CPU on existing VMs stays high. You want to keep the instance group size appropriate during autoscaling while maintaining the same performance targets. What should you do?

최대 인스턴스 수를 1로 설정하면 managed instance group의 horizontal scaling이 사실상 비활성화됩니다. 이는 트래픽 급증 중에도 동일한 성능 목표를 유지해야 한다는 요구 사항과 직접 충돌합니다. 부하가 증가해도 서비스가 더 이상 용량을 추가할 수 없기 때문입니다. 이는 불필요한 scale-out을 유발하는 타이밍 문제를 해결하는 대신 성장을 막아 증상만 다루는 방식입니다. 이렇게 하면 피크 수요에서 지연 시간과 오류가 증가할 가능성이 높습니다.

최대 인스턴스 수를 3으로 줄이는 것은 단지 더 작은 상한을 두는 것일 뿐이며, autoscaler가 애초에 계속 인스턴스를 추가하는 이유를 해결하지 못합니다. startup 시간이 여전히 길다면 기존 VM은 CPU 임계값을 계속 초과할 수 있고 새 VM은 아직 도움이 되지 못하므로, 그룹은 더 낮은 상한에 도달할 때까지 여전히 비효율적으로 scale될 수 있습니다. 이는 실제 급증 상황에서 과소 프로비저닝의 위험을 만듭니다. 근본 원인이 readiness 지연일 때 용량 제한은 올바른 해결책이 아닙니다.

TCP health check는 인스턴스가 포트에서 연결을 수락하는지만 확인할 뿐, HTTP 애플리케이션이 완전히 초기화되어 요청을 올바르게 처리할 수 있는지는 확인하지 않습니다. HTTP(S) load balancer 뒤의 web API에는 애플리케이션 수준의 readiness를 검증할 수 있으므로 HTTP health check가 더 적절합니다. TCP로 전환하면 인스턴스가 너무 일찍 정상으로 보일 수 있어 서비스가 실제로 준비되기 전에 트래픽이 전달될 수 있습니다. 또한 긴 startup 시간으로 인해 발생하는 autoscaling 타이밍 문제를 직접적으로 해결하지도 못합니다.

지연 시간을 180초로 늘리는 것은 VM의 실제 startup 시간인 약 160초에 시스템 타이밍을 맞추는 유일한 선택지입니다. 이렇게 하면 인스턴스가 생성되는 시점과 실제로 용량에 기여할 준비가 되는 시점 사이의 불일치를 줄일 수 있으며, 트래픽 급증 중 반복적인 scale-out을 방지하는 데 도움이 됩니다. 시험 관점에서 보면, 이는 적절한 warm-up 또는 initialization period를 구성하는 데 가장 가까운 정답입니다. 기존 성능 목표는 유지하면서 overscaling을 유발하는 startup 지연 문제를 해결합니다.

문제 분석

핵심 개념: 이 문제는 인스턴스가 트래픽을 처리할 수 있기 전에 초기화에 상당한 시간이 걸릴 때 managed instance group (MIG) autoscaling 동작에 관한 것입니다. 핵심 이슈는 새로 생성된 VM이 약 2분 40초 동안 준비되지 않는다는 점이므로, autoscaler는 워밍업 기간 동안 해당 인스턴스의 메트릭을 무시하여 이미 서비스 중인 인스턴스의 CPU만을 기준으로 반복적으로 scale-out하지 않도록 해야 합니다. 정답인 이유: 선택지 중 가장 적절한 것은 지연 시간을 180초로 늘려 시스템이 실제 시작 시간과 더 잘 맞도록 하는 것입니다. 이렇게 하면 새로 생성된 인스턴스가 너무 이르게 사용 가능한 것으로 처리되는 것을 방지하고, 기존 인스턴스가 계속 과부하 상태인 동안 autoscaler가 더 많은 VM을 계속 추가할 가능성을 줄일 수 있습니다. 실제로는 autoscaler initialization period가 이 동작에 대해 더 정확한 설정이지만, 제공된 선택지 중에서는 이것이 의도된 해결책에 가장 가깝습니다. 주요 특징: - CPU 기반 MIG autoscaling은 새 인스턴스가 아직 시작 중이고 아직 용량에 기여하지 못하는 경우 과도하게 반응할 수 있습니다. - scaling 관련 타이밍을 조정할 때 startup script와 애플리케이션 워밍업 시간을 고려해야 합니다. - health 및 readiness 신호는 인스턴스가 실제로 production 트래픽을 처리할 수 있는 시점을 반영해야 합니다. - 적절한 워밍업 타이밍은 진동 현상과 불필요한 scale-out 이벤트를 줄여 줍니다. 흔한 오해: - 단순히 최대 인스턴스 수를 낮추는 것은 근본 원인을 해결하지 못하며 급증 시 성능을 저하시킬 수 있습니다. - TCP health check는 포트 도달 가능성만 확인하므로 애플리케이션 readiness 측면에서는 HTTP check보다 덜 적합합니다. - health check와 autoscaler 워밍업은 운영상 관련이 있지만, 동일한 메커니즘은 아닙니다. 시험 팁: Google Cloud 시험 문제에서 startup 지연 동안 autoscaling이 너무 많은 인스턴스를 추가한다면, initialization time, warm-up period, 또는 readiness와 관련된 설정을 찾으세요. 용량을 인위적으로 제한하는 것보다 실제 애플리케이션 readiness에 맞춰 scaling 동작을 정렬하는 해결책을 우선하세요.

13
문제 13

You are launching a real-time logistics tracking service on Google Kubernetes Engine (GKE Autopilot) in us-central1 that requires MongoDB-specific document queries and replica set transactions. The database must be fully managed with 24/7 vendor support, a published 99.95% uptime SLA, automated backups with at least 7-day retention, and private connectivity (VPC peering) to your GKE workloads; it should handle approximately 2,000 reads per second and 500 writes per second without you managing virtual machines. You want to deploy this through a Google Cloud–integrated offering to simplify billing and support; what should you do?

Cloud Bigtable은 fully managed이며 확장성이 매우 높은 NoSQL database이지만 MongoDB가 아니고 MongoDB document query semantics, replica set behavior, MongoDB multi-document transactions를 제공하지 않습니다. HBase API를 사용하더라도 MongoDB-specific features 요구사항을 충족하지 못합니다. Bigtable은 높은 throughput을 처리하고 강한 availability 특성을 제공할 수 있지만, 핵심 호환성 요구사항을 충족하지 못합니다.

Google Cloud Marketplace의 MongoDB Atlas가 최적의 선택입니다. MongoDB-native queries, replica sets, transactions를 제공하는 fully managed MongoDB service입니다. 공개된 SLA(일반적으로 production tier에서 99.95%), 보존 기간을 설정할 수 있는 automated backups, 선택 가능한 24/7 support를 제공합니다. VPC peering을 통해 VPC로 private connectivity를 지원하며, Marketplace 조달은 billing 및 vendor engagement를 단순화합니다.

standalone Compute Engine VMs에서 MongoDB를 실행하는 것은 self-managed입니다. OS 및 MongoDB patching, backups, monitoring, scaling, failover/replica set operations를 직접 처리해야 합니다. managed-service 관점에서 “24/7 vendor support 및 공개된 99.95% uptime SLA를 갖춘 fully managed” 요구사항을 충족하지 못하며, virtual machines 관리를 피하려는 요구와도 모순됩니다.

Managed Instance Group은 stateless workloads에 대해 VM availability 및 scaling을 개선하지만, MongoDB는 stateful이며 신중한 replica set configuration, persistent disks, backups, coordinated failover가 필요합니다. 여전히 VMs와 database lifecycle을 관리해야 하므로 vendor SLA/support 및 automated backups가 있는 fully managed database 요구사항을 위반합니다. MIG는 managed database service의 대체가 아닙니다.

문제 분석

핵심 개념: 이 문제는 특정 API/워크로드 요구사항(MongoDB document queries 및 replica set transactions)에 맞는 managed database를 선택하면서 운영 요구사항(SLA, backups, support)을 충족하고, networking 및 billing을 위해 Google Cloud와 통합되는지를 평가합니다. 또한 GKE Autopilot 제약을 간접적으로 테스트합니다. managed service가 존재할 때 VM에서 self-managed stateful database를 피해야 합니다. 정답이 맞는 이유: Google Cloud Marketplace의 MongoDB Atlas는 MongoDB 고유 기능(document model, query language, indexes, replica sets, multi-document transactions)을 위해 설계된 Google Cloud 통합형 fully managed MongoDB service입니다. Atlas는 공개된 SLA(많은 production tier에서 99.95% 포함), 보존 기간을 설정할 수 있는 automated backups(>=7일), 24/7 vendor support 옵션을 제공합니다. 또한 VPC peering/PrivateLink 스타일 연결(Atlas VPC peering on GCP)을 통해 VPC로 private connectivity를 지원하므로, us-central1의 GKE Autopilot workloads가 public IP 노출 없이 private하게 database에 접근할 수 있습니다. 이는 “no VM management” 요구사항을 충족하며, Marketplace를 통한 조달로 consolidated billing 및 support engagement를 단순화합니다. 주요 기능 / 구성: - latency 및 egress를 줄이기 위해 동일 region(us-central1)에 Atlas를 배포합니다. - 약 2,000 reads/s 및 500 writes/s에 맞게 Atlas cluster tier를 sizing하고 replica set/high availability를 활성화합니다. - 최소 7일 retention으로 automated backups를 활성화하고 point-in-time restore 요구사항을 확인합니다. - GKE VPC에 Atlas VPC peering을 설정하고 IP access lists / network policies로 접근을 제한합니다. - Google Cloud Architecture Framework에 맞춥니다: reliability(SLA, multi-zone), security(private connectivity, least privilege), operational excellence(managed backups/patching). 흔한 오해: 자주 있는 함정은 Bigtable을 선택하는 것입니다. Bigtable은 확장성과 managed 특성이 뛰어나지만 MongoDB가 아니며 MongoDB query semantics나 replica set transactions를 지원하지 않습니다. 또 다른 함정은 Compute Engine/MIG에서 MongoDB를 실행해 “모든 것을 제어”하려는 것입니다. 하지만 이는 vendor SLA/support가 있는 fully managed service 요구사항을 위반하고(패칭, backups, failover, upgrades 등) 운영 부담을 증가시킵니다. 시험 팁: 문제가 특정 database API/behavior(MongoDB queries, replica sets, transactions)를 명시적으로 요구하면, 이를 native하게 제공하는 managed offering을 우선합니다. GKE Autopilot에서는 self-hosted stateful system보다 managed database를 선호합니다. 또한 “Marketplace”, “integrated billing”, “VPC peering”, “SLA”, “no VM management” 같은 키워드를 주의하세요. 이는 Marketplace를 통한 MongoDB Atlas 같은 partner-managed service를 강하게 시사합니다.

14
문제 14

Your team operates a regional managed instance group of 12 Compute Engine VMs behind a global external HTTP(S) load balancer to serve a video-transcoding API that receives about 2,500 requests per minute, and you have a new application build that you want to roll out gradually during business hours while the service is handling live traffic; you must ensure that serving capacity does not decrease at any time during the rollout and downtime is not allowed—what should you do?

maxSurge=0 및 maxUnavailable=1은 managed instance group이 대체 instance를 생성하기 전에 기존 VM 1개를 먼저 제거할 수 있게 합니다. 즉, rollout 중에 그룹의 서빙 instance 수가 일시적으로 12개에서 11개로 줄어들 수 있으며, 이는 사용 가능한 capacity가 직접 감소하는 것입니다. 서비스가 이미 실제 트래픽을 처리하고 있으므로, 이는 서빙 capacity가 어느 시점에도 감소해서는 안 된다는 요구 사항을 위반합니다. 또한 update policy가 rollout 중 unavailable instance를 명시적으로 허용하므로 zero-downtime 의도에도 부합하지 않습니다.

서빙 capacity를 전혀 줄이면 안 되는 rolling update policy로는 maxSurge=1 및 maxUnavailable=0이 올바른 설정입니다. 이 구성에서는 managed instance group이 기존 VM을 제거하기 전에 목표 크기를 초과하는 추가 VM 1개를 먼저 생성하므로, 각 단계 동안 capacity가 일시적으로 12에서 13으로 증가합니다. 새 instance는 이전 instance가 삭제되기 전에 초기화되고 health check를 통과할 수 있으며, 이는 MIG가 external HTTP(S) load balancer 뒤에 있을 때 특히 중요합니다. 이렇게 하면 실제 트래픽을 처리하는 동안에도 update 전 과정에서 unavailable instance를 0으로 유지하면서, 제어된 점진적 rollout을 수행할 수 있습니다.

업데이트된 instance 12개로 두 번째 managed instance group을 만들고 이를 동일한 backend service에 연결하면 zero downtime을 제공할 수는 있지만, 본질적으로 점진적 rollout을 수행하는 것은 아닙니다. 새 backend가 healthy 상태가 되면, load balancer는 제어된 단계별 instance 교체 정책에 따라 트래픽을 분산하는 것이 아니라 balancing 동작에 따라 두 그룹에 트래픽을 분산하기 시작할 수 있습니다. 또한 이 방식은 capacity와 운영 복잡성을 둘 다 두 배로 늘리지만, surge를 사용하는 MIG rolling update는 서빙 capacity 감소를 보장 없이 직접 지원하면서 점진적인 in-place rollout을 제공합니다. 이 시험 시나리오에서는 built-in rolling update mechanism이 더 정확하고 적절한 해결책입니다.

managed instance group에서 instance template만 단순히 업데이트해도 기존 VM은 변경되지 않으며, 새로 생성되는 instance만 새 template을 사용합니다. 이후 현재 instance를 수동으로 삭제하면 그룹이 이를 다시 생성하지만, 정의된 rolling update policy가 없으면 한 번에 몇 개의 instance가 unavailable 상태가 될 수 있는지 제어할 수 없습니다. 그러면 대체 instance가 부팅되고 health check를 통과하는 동안 서빙 capacity가 감소하고 서비스 중단이 발생할 수 있습니다. 따라서 이 접근 방식은 업무 시간 중 점진적 rollout이나 capacity 보존을 보장하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Compute Engine Managed Instance Group (MIG) 롤링 업데이트와 HTTP(S) load balancer 뒤에서 무중단(Zero-downtime) 배포를 수행하는 방법을 테스트합니다. 핵심 제어 요소는 롤링 업데이트 정책 파라미터인 maxSurge와 maxUnavailable이며, 이 값들이 업데이트 중 일시적으로 용량을 늘릴 수 있는지와 업데이트 동안 서비스에서 제외될 수 있는 인스턴스가 허용되는지를 결정합니다. 정답이 맞는 이유: 서빙 용량이 어떤 시점에서도 감소하지 않고 다운타임이 허용되지 않도록 보장하려면, 롤아웃 동안 사용 불가(unavailable) 인스턴스가 0개가 되도록 해야 합니다. maxUnavailable=0으로 설정하면 MIG가 대체 용량이 준비되기 전까지 어떤 인스턴스도 선제적으로 서비스에서 제외하지 않도록 강제합니다. 하지만 maxSurge=0도 함께 설정하면, 그룹이 기존 인스턴스를 먼저 대체할 추가 인스턴스를 만들 수 없게 됩니다. 그러면 공간을 만들기 위해 인스턴스를 제거해야 하며, 이는 “용량 감소 없음” 요구사항을 위반합니다. 따라서 올바른 접근은 maxSurge=1 및 maxUnavailable=0으로 롤링 업데이트를 수행하는 것입니다. 이렇게 하면 그룹 크기(예: 12에서 13으로)가 일시적으로 증가하여 새 VM을 올리고, 해당 VM이 정상 상태(health checks 포함, load balancer health checks까지)를 통과할 때까지 기다린 다음, 그 후에 기존 VM 1대를 삭제합니다. 핵심 기능 / 모범 사례: - MIG 롤링 업데이트는 업데이트 속도와 중단(disruption)을 제어하여 업무 시간 중 점진적 롤아웃을 지원합니다. - maxSurge는 일시적인 추가 용량을 제공하고, maxUnavailable은 서빙 인스턴스 감소 허용치를 제어합니다. - global external HTTP(S) load balancer에서는 정상(healthy) 인스턴스만 트래픽을 받습니다. 새 VM이 너무 일찍 healthy로 표시되지 않도록 health checks와 readiness가 올바른지 확인하세요. - surge는 업데이트 중 추가 VM 용량이 필요하므로 quotas(예: regional instance quota, CPU quota)를 고려하세요. 흔한 오해: - “롤링 업데이트”만으로는 용량 손실이 없음을 보장하지 않습니다. 정책 값이 중요합니다. - 두 번째 MIG를 사용하는 blue/green 방식도 가능하지만 운영적으로 더 무겁고, surge 기반 롤링 업데이트로 요구사항을 충족할 수 있다면 필요하지 않습니다. 시험 팁: “다운타임 없음”과 “용량이 감소하면 안 됨”을 보면 maxUnavailable=0과 양수 maxSurge를 찾으세요. 질문이 단순성과 내장 기능 사용을 강조한다면, 명시적으로 요구되지 않는 한 병렬 스택을 구축하기보다 MIG 롤링 업데이트를 선호하세요.

15
문제 15

Your media company plans to migrate an internal video review tool currently running on two Ubuntu VMs (each 4 vCPU, 16 GB RAM, 200 GB SSD) and a standalone MySQL 8 server (4 vCPU, 26 GB RAM, 1 TB SSD) to Google Cloud within the next quarter; the target design uses Compute Engine for the app VMs and Cloud SQL for MySQL with high availability, automated daily backups, and 7-day point-in-time recovery, and you must produce a 12-month cost estimate within an hour without provisioning any resources, capturing costs for VM instances, persistent disks, Cloud SQL (including HA and backups), and intra-region network egress. What should you do?

SKU를 스프레드시트로 내보내면 이론적으로 견적을 만들 수는 있지만, 1시간 마감이 있는 시험 시나리오에서 권장되거나 가장 빠른 접근은 아닙니다. 구성요소를 놓치기 쉽고(예: Cloud SQL HA로 인한 compute 2배, 백업 스토리지, PITR/binary log 스토리지, 리전에 따른 디스크 가격 차이), 수식 오류 및 오래된 가격을 사용할 위험도 커서 Pricing Calculator보다 적합하지 않습니다.

사전 구축된 “Web Application” 템플릿은 일반적으로 트래픽/요청 기반이며, 기존 VM 스펙과 특정하게 구성된 Cloud SQL HA + 백업 + 7일 PITR 요구사항에 기반한 lift-and-shift 스타일의 사이징을 정확히 반영하지 못할 수 있습니다. 템플릿은 대략적인 사이징에는 도움이 될 수 있지만, 이 문제는 VM instance types, 디스크 크기, HA 구성, 백업/PITR 비용을 명시적으로 포착해야 하므로, 커스텀 항목(line items)으로 처리하는 편이 더 적절합니다.

파일럿을 만들고 Billing 보고서에서 외삽하는 방식은 리소스 프로비저닝이 필요하며, 문제에서 이를 명시적으로 금지합니다. 설령 허용되더라도, 25% 트래픽으로 30분 부하 테스트를 하는 것은 연간 비용의 신뢰할 만한 근거가 되지 못합니다. 이는 안정 상태 사용률, 스토리지 증가, 백업 보존, HA standby 비용을 대표하지 않을 수 있습니다. 이 접근은 더 느리고 운영 부담이 크며, 빠른 계획 요구사항과도 덜 부합합니다.

이것이 올바른 접근입니다. Google Cloud Pricing Calculator를 사용하고 목표 설계 및 현재 사이징 가정에 맞는 Compute Engine과 Cloud SQL 항목을 추가합니다. 리전, machine types, SSD persistent disks, HA(regional)가 포함된 Cloud SQL for MySQL, 스토리지 크기를 지정하고, 백업/PITR 관련 스토리지 가정도 포함할 수 있습니다. 계산기는 월별 및 12개월 소계를 제공하고 network egress 추정치 추가를 지원하여 모든 제약을 충족합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud Pricing Calculator를 사용해 비용을 산정하고 솔루션을 계획하는 능력을 평가하며, 특히 Compute Engine, Persistent Disk, 그리고 고가용성(HA), 백업, 시점 복구(PITR)가 포함된 Cloud SQL for MySQL을 대상으로 합니다. 또한 리소스를 배포하지 않고도 빠르게 견적을 산출할 수 있는지 확인합니다. 정답이 맞는 이유: 옵션 D가 정답인 이유는 Pricing Calculator가 어떤 리소스도 프로비저닝하지 않고 빠르고 근거 있는 12개월 견적을 생성하기 위한 의도된 도구이기 때문입니다. 두 개의 애플리케이션 VM(Compute Engine instances)과 해당 SSD persistent disks에 대해 각각 별도의 항목을 추가한 다음, HA(regional), 스토리지 크기, 백업/PITR 설정으로 구성된 Cloud SQL for MySQL 인스턴스를 추가할 수 있습니다. 계산기는 월별 및 12개월 소계를 제공하고 리전 선택을 지원하는데, 이는 리전에 따라 가격이 달라지므로 필수입니다. 또한 견적의 일부로(해당되는 경우 intra-region 포함) 추정 network egress를 추가하는 것도 지원합니다. 주요 기능 / 모범 사례: Compute Engine 비용은 machine type(vCPU/RAM), 사용 시간, 그리고 디스크 유형/크기(SSD PD)에 의해 결정됩니다. Cloud SQL 비용에는 인스턴스(vCPU/RAM), 스토리지, 그리고 HA(regional)가 포함되며, 이는 서로 다른 zone에 primary와 standby를 사실상 프로비저닝합니다. 자동 일일 백업과 PITR(binary logging)은 스토리지 사용량과 비용을 증가시킬 수 있으며, 계산기를 통해 백업 스토리지와 보존(retention) 가정을 모델링할 수 있습니다. 네트워킹 측면에서 intra-region egress도 트래픽 경로(예: cross-zone 또는 특정 service-to-service 패턴)에 따라 과금될 수 있으므로, 이를 견적에 명시적으로 포함하는 것은 Google Cloud Architecture Framework(비용 최적화 및 신뢰성)의 좋은 계획 관행과 일치합니다. 흔한 오해: 많은 사람이 SKU를 내보내는 것(옵션 A)이 더 빠르다고 생각하지만, 이는 오류가 발생하기 쉽고 유지 관리에 시간이 많이 들며, HA, 백업, PITR 관련 비용 구성요소를 놓치기 쉽습니다. 또 다른 사람들은 템플릿(옵션 B)이 모든 것을 포착할 것이라고 가정하지만, 템플릿은 트래픽 기반이며 고정된 VM 스펙과 Cloud SQL HA/PITR 요구사항에 깔끔하게 매핑되지 않을 수 있습니다. 파일럿을 실행하는 것(옵션 C)은 “어떤 리소스도 프로비저닝하지 않고”라는 제약을 위반하며, 30분 내에 안정 상태 비용을 신뢰성 있게 포착하지도 못합니다. 시험 팁: 배포 없이 빠른 견적을 요구하는 문제라면, 목표 아키텍처에 맞는 명시적 항목(line items)을 포함한 Pricing Calculator를 선택하세요. HA, 백업, PITR, 디스크 유형/크기, 리전 선택 같은 요구사항을 주의 깊게 보세요. 이는 일반 템플릿이나 경험적 Billing 데이터에 의존하기보다, 특정 구성에 의해 결정되는 비용을 모델링해야 한다는 흔한 시험 신호입니다.

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

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

16
문제 16

Your compliance team has contracted an external penetration tester to review all resources in the Google Cloud project proj-audit-789 for 7 days and must ensure they cannot modify anything. Your organization has the Organization Policy constraint Domain Restricted Sharing configured at the organization node to allow only accounts in the corp.example.com Cloud Identity domain. How do you provide the tester with read-only visibility to that project without violating the policy?

오답. 개인 Google Account(대개 gmail.com)는 허용된 corp.example.com domain 밖입니다. organization level에서 Domain Restricted Sharing이 활성화되어 있으면 Viewer 같은 read-only role이라도 해당 principal을 project IAM policy에 추가하는 것이 차단됩니다. role 선택은 무관하며, 정책이 identity 자체를 막습니다.

오답. roles/iam.securityReviewer는 read-only role이지만 Domain Restricted Sharing을 우회하지 못합니다. 테스터의 Google Account가 corp.example.com에 속하지 않으면 project에 어떤 IAM binding도 부여할 수 없습니다. 또한 Security Reviewer는 Viewer보다 더 제한적이며, “모든 resources를 검토”한다는 의미의 광범위한 resource 가시성을 제공하지 못할 수 있습니다.

정답. 승인된 corp.example.com domain에서 임시 Cloud Identity user를 생성하면 Domain Restricted Sharing을 준수합니다. roles/viewer를 부여하면 많은 Google Cloud services 전반에 걸쳐 광범위한 read-only access를 제공하여, 테스터가 resources를 수정할 수 없어야 한다는 요구사항에 부합하면서도 7일 engagement 동안 configurations와 assets를 점검할 수 있습니다.

부분적으로는 맞지만 최선의 답은 아닙니다. 임시 corp.example.com user는 Domain Restricted Sharing을 충족하지만, roles/iam.securityReviewer는 더 좁고 IAM/security posture 가시성에 초점이 맞춰져 있습니다. 문제는 테스터가 “모든 resources를 검토”해야 한다고 하며, 이는 일반적으로 Security Reviewer보다 더 광범위한 read-only access가 필요합니다. Viewer가 포괄적인 project 가시성을 위한 더 적절한 read-only role입니다.

문제 분석

핵심 개념: 이 문제는 IAM identity 유형과 Organization Policy 제약—특히 Domain Restricted Sharing (DRS)—을 테스트합니다. DRS는 domain을 기준으로 어떤 principal에게 IAM access를 부여할 수 있는지 제한하며, 일반적으로 승인된 Cloud Identity/Google Workspace domain의 users/groups/service accounts만 허용합니다. 정답이 맞는 이유: DRS가 organization node에서 corp.example.com 내 계정만 허용하도록 구성되어 있으므로, 외부 테스터의 개인 Google Account (gmail.com) 또는 허용된 domain 밖의 어떤 계정에도 project-level IAM roles를 부여할 수 없습니다. 정책을 위반하지 않고 access를 제공하려면 corp.example.com에 속한 identity를 사용해야 합니다. 테스터를 위해 corp.example.com에 임시 Cloud Identity user를 생성하면 DRS 제약을 충족합니다. 그런 다음 proj-audit-789에 Viewer role (roles/viewer)을 부여하면 대부분의 Google Cloud resources에 대해 광범위한 read-only 가시성을 제공하여 “아무것도 수정할 수 없어야 한다”는 요구사항을 충족하면서도 configuration을 점검할 수 있게 합니다. 주요 기능 / 모범 사례: - Domain Restricted Sharing은 IAM policy binding 시점에 강제되며, 허용되지 않은 principal은 owner라 하더라도 추가할 수 없습니다. - 최소 권한 및 기간 제한 access를 사용하세요: 임시 user를 만들고, 필요한 roles만 부여한 뒤, 7일 후 access를 제거합니다. 실무에서는 access approval/workflow와 audit logs를 사용해 활동을 추적할 수도 있습니다. - Viewer는 많은 services 전반에 걸친 일반적인 read-only role이며, write permissions 없이 가시성이 필요한 auditor/assessor에게 흔히 사용됩니다. 흔한 오해: - “Security Reviewer는 read-only이니 더 낫다.” read-only는 맞지만, 범위가 더 좁고 (security/IAM 중심) penetration tester가 검토해야 할 모든 resources에 대한 가시성을 제공하지 못할 수 있습니다. - “read-only면 그들의 Google Account를 써도 된다.” DRS는 role과 무관하게 principal을 차단합니다. domain restriction은 어떤 permissions를 받는지가 아니라 누가 access를 부여받을 수 있는지에 관한 것입니다. 시험 팁: Domain Restricted Sharing이 보이면 먼저 principal의 domain이 허용되는지 판단하세요. 허용되지 않는다면, 준수 가능한 선택지는 허용된 domain의 identity를 사용하는 것(임시 Cloud Identity user, 해당 domain의 group membership, 또는 적절한 경우 허용된 service account)뿐입니다. 그 다음, 명시된 가시성 요구사항을 충족하는 최소 권한 role을 고르세요—광범위한 read-only에는 Viewer, 보안 상태 검토만이면 Security Reviewer입니다.

17
문제 17

In Cloud Shell, your default project is dev-sbx-1234 and your organization has about 200 projects; without changing the default configuration, you must use gcloud to output only the currently enabled Google Cloud APIs for the production project whose display name is "orion-billing-prod"—what should you do?

정답입니다. gcloud services 작업은 project ID/number 범위로 지정되므로, display name이 "orion-billing-prod"인 프로젝트의 project ID를 먼저 식별해야 합니다. 그런 다음 gcloud services list --project <PROJECT_ID>는 해당 프로젝트에서 현재 enabled된 API만 나열합니다. 이 접근은 Cloud Shell에서 활성 configuration을 변경하지 않으며, 단일 명령에 대해 다른 프로젝트를 안전하게 대상으로 지정하는 표준적인 방법입니다.

오답입니다. gcloud init은 일반적으로 활성 configuration(기본 project 포함)을 업데이트하는 대화형 워크플로이므로, default configuration을 변경하지 말라는 요구사항을 위반합니다. 또한 gcloud services list --available은 프로젝트에서 현재 enabled된 서비스가 아니라 enable 가능한 서비스를 나열하므로 “현재 enabled된 API” 요구사항을 충족하지 못합니다.

오답입니다. gcloud info는 환경 및 활성 account 세부 정보를 보여주지만, enabled API는 account 수준이 아니라 프로젝트 수준 설정입니다. 또한 gcloud services list는 어떤 프로젝트의 enabled 서비스를 나열할지 결정하기 위해 --account 플래그를 사용하지 않고, 활성 project 또는 --project를 사용합니다. 이 선택지는 리소스 계층 및 scoping 모델을 오해한 것입니다.

오답입니다. gcloud projects describe <PROJECT_ID>는 이미 project ID를 알고 있을 때 프로젝트를 확인하는 데는 도움이 되지만, display name으로부터 올바른 project ID를 찾는 데는 도움이 되지 않습니다. 더 중요한 점은, gcloud services list --available이 다시 enable 가능한 API를 나열할 뿐 현재 enabled된 API를 나열하지 않는다는 것입니다. 프로젝트가 올바르게 식별되었다 하더라도 핵심 요구사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 gcloud CLI의 project scoping과 gcloud services를 통해 노출되는 Service Usage API 표면을 테스트합니다. 특히, 활성 configuration을 변경하지 않고 Cloud Shell에서 현재 default project가 아닌 프로젝트에 대해 현재 enabled된 API만 나열하는 방법에 초점을 둡니다. 정답이 맞는 이유: Cloud Shell에서 gcloud 명령어는 명시적으로 override하지 않는 한 활성(기본) project를 대상으로 실행됩니다. default configuration을 변경하지 말라고 했으므로 활성 project를 변경하는 명령(예: gcloud init 또는 gcloud config set project)을 실행하면 안 됩니다. 프로덕션 프로젝트는 display name("orion-billing-prod")로 식별되지만, gcloud services list는 요청 범위를 지정하기 위해 project identifier가 필요합니다. 따라서 올바른 워크플로는 (1) gcloud projects list(필요 시 필터링)를 사용해 display name에 해당하는 project ID(또는 project number)를 찾고, (2) gcloud services list --project <PROJECT_ID>를 실행하여 해당 프로젝트에서 enabled된 서비스를 나열하는 것입니다. 주요 기능 / 모범 사례: - gcloud services list는 (--available 없이) 대상 프로젝트에 enabled된 API/service를 나열합니다. - --project를 사용하면 configuration을 수정하지 않고 non-default project를 대상으로 할 수 있어, 예측 가능성과 운영 안전성에 부합합니다. - 약 200개의 프로젝트가 있다면 다음처럼 필터링할 수 있습니다: gcloud projects list --filter="name=orion-billing-prod" --format="value(projectId)" 를 사용해 ID를 빠르게 추출합니다. - 이는 Google Cloud Architecture Framework의 운영 우수성 원칙(안전하고 되돌릴 수 있는 변경을 수행하고 Cloud Shell 같은 공유 환경에서 불필요한 configuration drift를 피함)과 일치합니다. 흔한 오해: - --available과 enabled services를 혼동: --available은 enable할 수 있는 서비스를 보여주며, 현재 enabled된 것이 무엇인지는 보여주지 않습니다. - account scoping이 enabled API에 영향을 준다고 생각: API는 사용자 account가 아니라 프로젝트별로 enable됩니다. - gcloud init 사용: configuration을 변경하며, 일회성 조회에는 불필요합니다. 시험 팁: - 패턴을 암기하세요: “non-default project에서 작업해야 하나요? --project를 사용.” - display name은 project ID와 다릅니다. 많은 gcloud 명령은 project ID/number를 요구합니다. - API enablement 문제에서는 enabled services 나열(gcloud services list)과 available services 나열(gcloud services list --available)을 구분하세요.

18
문제 18

Your financial services platform stores monthly PDF statements in a Cloud Storage bucket with Object Versioning enabled, and to reduce costs you need a policy that transitions only noncurrent object versions after 30 days, while those previous versions are read once a month for compliance reports and are occasionally amended at month-end, so what should you configure?

Coldline은 보통 분기당 1회 이하로 접근되는 데이터에 가장 적합하며 최소 storage duration이 90일입니다. 시나리오에서 noncurrent version이 컴플라이언스를 위해 월 1회 읽히고 월말에 다시 접근되기도 한다고 했으므로, Coldline은 retrieval cost가 더 커지고 90일 이전에 version이 교체되거나 삭제되면 early-deletion charge가 발생할 수 있습니다. noncurrent version을 대상으로 한다는 점은 맞지만 storage class가 덜 적합합니다.

Nearline은 일반적으로 월 1회 정도 읽히는 비정기 접근 데이터에 맞게 설계되어 컴플라이언스 보고 패턴과 일치합니다. 30일 후 noncurrent version만 Nearline으로 transition하는 lifecycle rule은 현재 version을 정상 운영을 위해 Standard에 유지하면서 storage cost를 줄입니다. Nearline의 30일 최소 storage duration도 “30일 이후” 요구사항과 정렬되므로, 비용/성능 측면에서 가장 적합한 선택입니다.

이 옵션은 30일 후 all objects(현재 version 포함)를 Coldline으로 변경하므로 noncurrent version만 transition하라는 요구사항을 위반합니다. 또한 활성/current statement에 대한 access cost와 latency에 부정적 영향을 줄 수 있습니다. 추가로 Coldline의 90일 최소 storage duration 때문에, object가 수정되어 재작성되면 새 version이 생성되고 이전 version이 90일 이전에 삭제될 경우 early-deletion charge 위험이 있습니다.

이 옵션은 30일 후 all objects를 Nearline으로 변경하므로 핵심 요구사항(오직 noncurrent version만 transition)을 충족하지 못합니다. 현재 statement는 더 빈번한 접근이 필요할 수 있으며, 이를 Nearline으로 옮기면 retrieval cost와 운영상의 마찰이 증가할 수 있습니다. Nearline이 월간 접근에 적합한 class인 것은 맞지만, lifecycle rule의 범위가 잘못되어 current version에도 영향을 줍니다.

문제 분석

핵심 개념: 이 문제는 Cloud Storage Object Versioning 및 Lifecycle Management를 평가하며, 특히 noncurrent(이전) object version을 대상으로 하는 lifecycle condition을 사용하고 접근 패턴과 비용 트레이드오프에 따라 적절한 storage class를 선택하는지를 묻습니다. 정답이 맞는 이유: live/current version이 아니라 30일 이후의 noncurrent version만 transition해야 합니다. 이전 version은 컴플라이언스 보고서를 위해 월 1회 읽히고, 월말에 수정 사항 반영을 위해 다시 접근될 수 있으므로 접근 패턴은 대략 월간입니다. Nearline Storage는 월 1회보다 덜 접근되는 데이터를 위해 설계되었고, Standard보다 storage cost가 낮으며 Coldline보다 access/early-deletion penalty가 낮습니다. 따라서 30일 후 noncurrent version을 Nearline으로 변경하는 lifecycle rule이 “월간 읽기”에 가장 잘 맞으면서 비용도 절감합니다. 주요 기능 / 구성 세부사항: Cloud Storage lifecycle rule은 “number of newer versions” 및/또는 “days since noncurrent time”(보통 “daysSinceNoncurrentTime”로 표현) 같은 condition을 사용해 noncurrent version에 적용할 수 있습니다. Object Versioning을 활성화하면 현재 version은 빈번/활성 사용을 위해 Standard에 유지하면서 이전 version만 transition할 수 있습니다. Nearline은 최소 storage duration이 30일이므로 30일 이후에 version을 이동하는 것은 이 모델과 정렬됩니다. 이는 Google Cloud Architecture Framework의 비용 최적화 원칙(요구되는 접근 및 성능을 충족하는 가장 저렴한 storage tier 선택)과도 일치합니다. 흔한 오해: Coldline은 GB당 비용이 더 저렴해 매력적으로 보일 수 있지만, 분기당 최대 1회 접근되는 데이터에 최적화되어 있고 최소 storage duration이 90일입니다. 월간 컴플라이언스 읽기가 있는 경우 Coldline은 retrieval 및 early-deletion cost를 증가시켜 전체적으로 비용 최적이 아닐 수 있습니다. 또 다른 흔한 실수는 noncurrent version만이 아니라 “all objects”를 transition하는 것으로, 이는 활발히 사용되는 current statement의 성능/비용에 악영향을 줄 수 있습니다. 시험 팁: 1) 접근 빈도를 storage class에 매핑: Standard(빈번), Nearline(월간), Coldline(분기), Archive(연 1회+). 2) versioned bucket에서는 요구사항이 “previous versions only”라고 하면 lifecycle rule이 noncurrent version을 명시적으로 대상으로 하도록 해야 합니다. 3) 최소 storage duration 과금(Nearline 30일, Coldline 90일, Archive 365일)을 확인하고 lifecycle timing을 이에 맞추세요.

19
문제 19

You plan to host a geospatial tile-rendering backend on Compute Engine; traffic averages 150 concurrent render jobs but spikes to 1,500 during quarterly map releases, and customers must be able to submit jobs 24/7 without interruption or CPU throttling. Your SLO requires 99.9% availability across at least two zones in us-central1, and you want to follow Google-recommended practices so capacity scales automatically without manual intervention. What should you do?

CPU alert threshold가 있는 여러 standalone VM은 용량을 추가하기 위해 여전히 수동 조치(또는 언급되지 않은 스크립팅)가 필요합니다. 또한 standalone instances는 managed autohealing과 instance templates를 통한 일관된 롤아웃이 없습니다. Google 권장 자동 scaling 관행 요구사항을 충족하지 못하며, us-central1에서 최소 두 개 존에 걸친 멀티 존 고가용성을 명시적으로 보장하지도 않습니다.

VM을 high-CPU 인스턴스로 교체하는 것은 vertical scaling 접근으로, 더 느리고 잠재적으로 중단을 유발합니다(인스턴스 교체/재시작). 또한 수동 개입에 의존하며, 멀티 존 복원력이나 managed autohealing을 본질적으로 제공하지 않습니다. vertical scaling은 autoscaling으로 인스턴스 수를 수평 확장하는 것만큼 10배 스파이크를 효과적으로 처리하지 못합니다.

instance group을 사용하는 것은 더 가깝지만, “high CPU utilization을 볼 때마다” 인스턴스를 늘린다고 되어 있어 수동이며 개입 없이 자동 scaling 요구사항을 위반합니다. 또한 두 개 존에 걸친다는 점을 명시하지 않습니다. zonal instance group은 us-central1에서 최소 두 개 존에 걸친 가용성 SLO 요구사항을 충족하지 못합니다.

두 개 존에 걸친 managed instance group(regional MIG)은 고가용성과 탄력성을 위한 권장 Compute Engine 패턴입니다. 평균 CPU utilization 기반 autoscaling은 수동 작업 없이 수요 스파이크에 맞춰 인스턴스를 자동으로 추가/제거합니다. MIG는 또한 autohealing, rolling updates, 그리고 instance templates를 통한 일관된 구성을 지원하여 Google 모범 사례 및 명시된 99.9% 멀티 존 SLO에 부합합니다.

문제 분석

핵심 개념: 이 문제는 Managed Instance Groups (MIGs), 멀티 존 배포, 그리고 autoscaling을 사용한 Compute Engine 확장성과 고가용성을 평가합니다. 또한 수동 개입을 피하고 가용성 SLO를 충족하는 이해도를 간접적으로 테스트합니다. 정답이 맞는 이유: us-central1의 regional (multi-zone) Managed Instance Group은 최소 두 개 존에 걸쳐 인스턴스를 분산할 수 있으므로, 단일 존 장애가 발생해도 서비스가 중단되지 않아 적절한 health checks 및 load balancing과 함께 99.9% 가용성 목표를 지원합니다. 평균 CPU utilization 기반 autoscaling은 분기별 스파이크(동시 작업 1,500개) 동안 자동으로 인스턴스를 추가하고, 정상 부하(150개 작업)에서는 다시 축소하여 수동 개입 없이 자동 용량 관리를 요구사항에 맞게 충족합니다. 주요 기능 / 구성: 1) “최소 두 개 존에 걸쳐” 요구사항을 만족하기 위해 us-central1의 두 개(또는 그 이상) 존을 아우르는 regional MIG. 2) 평균 CPU utilization(또는 작업이 큐에 쌓이는 경우 queue depth 같은 custom metric) 기반 autoscaler 정책으로 자동 scale out/in. 3) 일관된 VM 구성과 빠르고 반복 가능한 확장을 보장하는 instance template. 4) 비정상 VM을 자동으로 재생성하는 health checks 및 autohealing. 5) 중단을 피하기 위해 non-preemptible VMs(표준 on-demand)를 사용하고, “CPU throttling 없음”이 엄격한 요구사항이라면 overcommitted/shared-core machine types는 피합니다. 흔한 오해: “standalone instances”를 언급하거나 “high CPU를 보면 증가” 같은 옵션은 수동 운영을 의미하므로 자동 확장 요구사항을 위반합니다. 또한 단순히 high-CPU 머신으로 리사이징하는 것은 급격한 스파이크를 잘 해결하지 못하며, 여전히 프로비저닝 부족이 발생하거나 교체 과정에서 중단을 유발할 수 있습니다. 시험 팁: (1) 트래픽 변동, (2) 자동 scaling 필요, (3) 멀티 존 가용성 요구사항을 보면, 기본 권장 패턴은 autoscaling과 autohealing을 갖춘 Managed Instance Group(종종 regional)입니다. 작업 처리 워크로드에서는 CPU가 최선의 scaling 신호인지 고려해야 하지만, ACE 시험에서는 queue 기반 metric이 명시적으로 제시되지 않는 한 “평균 CPU utilization 기반 autoscaling”이 정석 답안입니다.

20
문제 20

Your retail startup operates two Cloud Run services in us-central1 and europe-west1 that emit about 1.5 million structured JSON log entries per day, and you need a scalable, Google-recommended approach to retain at least 30 days of logs, run standard SQL queries over the logs, and build time-series charts to detect latency and HTTP status trends while minimizing operational overhead and cost; what should you do?

BigQuery로 로그를 푸시하면 SQL과 dashboards를 구현할 수 있지만, 운영 오버헤드가 증가합니다(export pipelines 구축/유지, 장애 처리, schema evolution, partitioning, access controls 처리). 또한 streaming inserts 또는 export jobs와 BigQuery storage/query 비용으로 인해 비용이 증가할 수 있습니다. Log Analytics가 log buckets에서 직접 SQL을 제공할 수 있는 상황에서는, 이것이 Google이 권장하는 “minimal ops” 접근 방식이 아닙니다.

Cloud Logging과 Logs Explorer는 실시간 troubleshooting, filtering, ad-hoc 조사에 매우 뛰어나지만, Logs Explorer는 30일치의 대용량 로그 전반에 대해 “표준 SQL 쿼리”를 수행하는 1차 솔루션으로 포지셔닝되어 있지 않습니다. 일부 charts를 만들 수는 있지만, 문제는 명시적으로 SQL analytics와 최소 오버헤드로 확장 가능한 trend analysis를 요구하며, 이는 log bucket에서의 Log Analytics가 더 잘 충족합니다.

이것이 권장 접근 방식입니다: Cloud Run의 기본 로깅을 Cloud Logging에 유지하고, 30일 이상 retention을 가진 log bucket을 구성한 뒤, export 없이 SQL로 로그를 쿼리할 수 있도록 Log Analytics를 활성화합니다. 운영 오버헤드(커스텀 pipelines 없음)를 최소화하고, 확장 가능한 analytics를 지원하며, latency 및 HTTP status 트렌드에 대한 charts/dashboards 구축을 가능하게 합니다. 또한 analytics가 활성화된 bucket으로 필요한 로그만 라우팅하여 비용을 추가로 최적화할 수 있습니다.

Cloud SQL은 트랜잭션 워크로드를 위한 relational database이며, 대용량 로그 ingestion 및 analytics를 위한 것이 아닙니다. 하루 150만 건의 log entries를 ingest하려면 custom ingestion code, 신중한 schema 설계, 그리고 지속적인 database 운영(scaling, maintenance, indexing)이 필요합니다. Cloud SQL에서 time-series log analytics를 쿼리하는 것은 일반적으로 Cloud Logging의 native analytics 기능을 사용하는 것보다 효율이 떨어지고 비용이 더 많이 듭니다.

문제 분석

핵심 개념: 이 문제는 serverless 워크로드에 대해 Google Cloud가 권장하는 로깅 아키텍처를 테스트합니다: Cloud Run -> Cloud Logging (log buckets) + Log Analytics 활성화로 SQL을 사용해 로그를 쿼리하고 최소한의 운영으로 운영 대시보드를 구축합니다. 이는 Google Cloud Architecture Framework의 Operational Excellence (observability) 및 Cost Optimization 기둥과 정렬됩니다. 정답이 맞는 이유: Cloud Run은 요청 및 애플리케이션 로그를 자동으로 Cloud Logging에 기록합니다. 30일 이상 retention policy를 가진 log bucket을 구성하고 해당 bucket에서 Log Analytics를 활성화하면, 다른 시스템으로 export하지 않고도 로그 엔트리 위에서 표준 SQL 쿼리를 직접 실행할 수 있습니다. Log Analytics는 운영 모델을 단순하게 유지하면서(ETL pipelines 없음, custom scripts 없음) 로그에 대해 BigQuery와 유사한 SQL 경험을 제공합니다. 이후 Logging의 analytics/charting 기능을 사용해 차트(예: latency 분포, HTTP status별 error rate)를 만들고, 또는 Cloud Monitoring dashboards에 연결해 time-series 시각화를 할 수 있습니다. 주요 기능 / 구성: 1) Log buckets 및 retention: bucket별로 retention을 최소 30일로 설정하고, cost control을 위해 특정 로그(예: Cloud Run request logs만)를 전용 bucket으로 라우팅하려면 sinks를 사용합니다. 2) Log Analytics: bucket에서 활성화하여 SQL로 로그를 쿼리합니다(status로 group by, p95 latency 계산, region/service로 필터링). 3) Multi-region services: us-central1 및 europe-west1의 로그는 sinks와 filters를 사용해 단일 bucket으로 중앙화(또는 region별로 분리)할 수 있습니다. 4) 낮은 운영 오버헤드: ingestion, storage, querying가 관리형이며 database administration이 필요 없습니다. 흔한 오해: BigQuery로 export(옵션 A)하는 것도 가능하지만, pipeline 관리, 잠재적 ingestion 비용, schema/partitioning 결정이 추가됩니다. Logs Explorer만 사용(옵션 B)하는 것은 troubleshooting에는 훌륭하지만 “표준 SQL 쿼리”와 대규모 장기 analytics에는 최적의 선택이 아닙니다. Cloud SQL(옵션 D)은 대용량 log analytics용으로 설계되지 않았고 비용이 많이 들며 운영 부담이 큽니다. 시험 팁: “Cloud Run logs”, “X일 보관”, “SQL over logs”, “minimize ops”를 보면 Cloud Logging buckets + retention + Log Analytics를 떠올리세요. sinks/filters로 볼륨과 비용을 제어하고, 강한 downstream 요구사항이 없는 한 custom export pipelines를 구축하기보다 managed logging analytics를 선호하는 경우가 많다는 점을 기억하세요.

합격 후기(11)

E
e******Nov 25, 2025

학습 기간: 1 month

I could count probably like 15+ question exactly the same on the real exam. Cloud pass always the best pratical exam questions.

W
w******Nov 24, 2025

학습 기간: 1 month

Thank you for the excellent source for preparing for cert exams, detail explanation really helped. Passed the exam.

J
J****Nov 13, 2025

학습 기간: 1 month

Got my cert after going though the practice questions. I have a background in GCP so it was a bit easy to grasp for me.

J
J***Nov 13, 2025

학습 기간: 1 month

This helped my pass the ACE on 1/12 , highly recommended.

B
b******Nov 10, 2025

학습 기간: 1 month

Passed the exam in first attempt!

모의고사

Practice Test #1

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

Practice Test #2

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

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Google Professional Cloud DevOps Engineer

Professional

Google Professional Cloud Network Engineer

Google Professional Cloud Network Engineer

Professional

Google Associate Data Practitioner

Google Associate Data Practitioner

Associate

Google Cloud Digital Leader

Google Cloud Digital Leader

Foundational

Google Professional Cloud Security Engineer

Google Professional Cloud Security Engineer

Professional

Google Professional Cloud Architect

Google Professional Cloud Architect

Professional

Google Professional Cloud Database Engineer

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Google Professional Cloud Developer

Professional

Google Professional Machine Learning Engineer

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

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