Google Associate Cloud Engineer

Practice Test #2

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

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

연습 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

연습 문제

문제 1

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?

문제 분석

핵심 개념: 이 문제는 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(삭제를 예약하는 것이 아니라 삭제를 방지함)를 구분하세요.

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

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

합격 후기(11)

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******Nov 24, 2025

학습 기간: 1 month

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

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***Nov 13, 2025

학습 기간: 1 month

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

b******Nov 10, 2025

학습 기간: 1 month

Passed the exam in first attempt!

다른 모의고사

Practice Test #1

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

← 모든 Google Associate Cloud Engineer 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 Google Associate Cloud Engineer 학습 문제를 무료로 이용하세요.

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

무료 앱 받기

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

문제 2

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?

문제 분석

핵심 개념: 이 문제는 단일 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를 피해야 합니다.

문제 3

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?

문제 분석

핵심 개념: 이 문제는 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을 선택하세요.

문제 4

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?

문제 분석

핵심 개념: 이 문제는 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입니다.

문제 5

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 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)을 구분하세요.

문제 6

A nationwide retail company currently manages 120 staff accounts in Google Workspace and expects to scale to 1,200 accounts within 18 months; approximately 85% of users will need access to Google Cloud resources (BigQuery dashboards and Cloud Run services) across three projects, and the access solution must handle 10x growth without adding new infrastructure, degrading sign-in performance, or increasing security risk—what should you do?

문제 분석

핵심 개념: 이 문제는 대규모에서의 Google Cloud identity and access management를 평가합니다: Google Workspace/Cloud Identity를 identity provider로 사용하고, IAM으로 authorization을 관리하며, Google Groups(Cloud Identity groups)로 관리를 단순화하는 것입니다. 또한 인프라를 추가하지 않으면서 보안 모범 사례(MFA)를 적용하는지도 테스트합니다. 정답인 이유: 옵션 B는 확장 가능한 access control을 위한 Google 권장 패턴과 일치합니다. 즉, 사용자를 Google Workspace/Cloud Identity에서 관리하고, 역할을 나타내는 그룹(예: bq-dashboard-viewers, cloudrun-invokers)에 사용자를 배치한 뒤, 프로젝트 수준에서 해당 그룹을 IAM roles에 바인딩합니다. 이 방식은 추가 identity 인프라를 배포하거나 운영하지 않고도 120명에서 1,200명+으로 확장되며, 사용자별 IAM bindings(관리 불가능해지고 오류가 발생하기 쉬움)를 피할 수 있습니다. 인증이 Google의 managed identity platform 내에서 유지되므로 sign-in 성능은 일관되게 유지되고, MFA를 중앙에서 강제하여 보안 위험을 줄일 수 있습니다. 주요 기능 / Best Practices: - 여러 프로젝트에 걸친 IAM bindings에서 Cloud Identity/Google Workspace groups를 principal로 사용합니다. - predefined roles(예: BigQuery Data Viewer, BigQuery Job User, Cloud Run Invoker)에 그룹을 매핑하고, 필요 시 환경/프로젝트별로 별도 그룹을 사용하여 least privilege를 적용합니다. - Google Workspace/Cloud Identity security settings를 통해 MFA(그리고 이상적으로는 admins를 위한 context-aware access / security keys)를 강제합니다. - 흩어진 IAM entries 대신 group membership을 감사(audit)하여 access reviews를 중앙화합니다. 이 접근 방식은 Google Cloud Architecture Framework의 security pillar(centralized identity, strong authentication, simplified authorization management)와 정렬됩니다. 일반적인 오해: 흔한 함정은 “확장”을 위해 AD 또는 third-party IdP를 도입해야 한다고 가정하는 것입니다. Google Cloud에서 Workspace 사용자의 identity 확장은 주로 인프라를 새로 요구하는 capacity 문제가 아니라, 관리 모델 문제(group-based IAM)입니다. 또 다른 오해는 Workspace와 Cloud Identity 간에 “federation”이 필요하다는 것인데, Workspace는 이미 해당 사용자에 대해 Cloud Identity 기능을 제공합니다. Exam Tips: “인프라 추가 없이 확장”과 “여러 프로젝트에 걸친 access”가 보이면, Google Groups + IAM bindings를 떠올리세요. 외부 corporate IdP를 사용해야 한다는 명시적 요구사항이 없는 한, managed identity(Workspace/Cloud Identity)와 MFA 강제를 sync/federation 체인을 구축하는 것보다 우선합니다.

문제 7

Your security policy mandates that a single compiled log-processing binary must run directly on Compute Engine virtual machines (no containers or serverless), and you need the fleet to auto-scale on average VM CPU (scale out when above 65% and scale in when below 45%) between 2 and 40 instances with the fastest reaction and minimal operational overhead during unpredictable 5–10 minute spikes; what should you do?

문제 분석

핵심 개념: 이 문제는 Managed Instance Groups(MIGs)와 instance templates를 사용한 Compute Engine autoscaling을 테스트합니다. MIGs는 자동 확장, 상태 관리, 낮은 운영 오버헤드와 함께 동일한 VM 기반 워크로드를 실행하기 위한 Google Cloud의 표준 메커니즘입니다. 정답인 이유: 이 워크로드는 Compute Engine VMs에서 직접 실행되어야 하므로, instance template로 구성된 MIG가 가장 적합한 기본 선택입니다. MIG의 CPU 기반 autoscaling을 사용하면 최소 및 최대 fleet 크기와 약 65%와 같은 목표 평균 CPU utilization을 정의할 수 있으므로, 트래픽 급증 시 인스턴스를 추가하고 수요가 감소하면 인스턴스를 제거할 수 있습니다. 이는 가장 적은 사용자 지정 작업으로 가장 빠르게 사용할 수 있는 관리형 VM autoscaling 옵션이며, 적절히 조정된 instance initialization period와 인스턴스를 빠르게 온라인 상태로 전환하는 startup method와 함께 사용하면 짧고 예측 불가능한 burst에 매우 적합합니다. 주요 기능 / 구성: - Instance template: VM 구성과 binary가 설치되거나 시작되는 방식을 정의합니다. 예를 들어 custom image 또는 startup script를 사용할 수 있습니다. - MIG autoscaler: min=2, max=40, 목표 CPU utilization을 약 0.65로 구성합니다. 평균 utilization이 목표 아래로 유지되면 autoscaler stabilization behavior에 따라 자동으로 scale-in이 수행되며, 별도로 구성된 45% threshold에 따르지 않습니다. - Health checks 및 autohealing: 실패한 인스턴스는 자동으로 다시 생성되어 운영 부담을 줄입니다. - Custom images 및 빠른 bootstrapping: 5–10분의 급증에 빠르게 대응하는 데 중요합니다. VM startup time이 실제 responsiveness에 영향을 주기 때문입니다. - Regional MIGs는 워크로드가 zonal failures를 견뎌야 하는 경우 가용성을 향상시킬 수 있습니다. 흔한 오해: 정책상 containers가 명시적으로 허용되지 않고 불필요한 플랫폼 복잡성만 추가하므로, 여기서는 Kubernetes autoscaling이 적절하지 않습니다. Scheduled autoscaling은 예측 가능한 수요 패턴에만 효과적이며, 짧고 무작위적인 급증에는 적합하지 않습니다. Custom automation도 가능할 수 있지만, 표준적인 CPU 기반 VM scaling 요구 사항에서는 일반적으로 기본 제공되는 MIG autoscaler보다 못합니다. 시험 팁: 문제에서 애플리케이션이 Compute Engine VMs에서 실행되어야 하고 최소한의 운영으로 CPU 기준 자동 확장이 필요하다고 하면, instance template와 managed instance group autoscaling을 떠올리세요. threshold 관련 표현을 과도하게 해석하지 않도록 주의하세요. 시험에서는 MIG의 CPU autoscaling이 일반적으로 별도의 명시적 scale-out 및 scale-in 비율이 아니라 목표 utilization으로 표현됩니다. 제약 조건을 충족하는 가장 단순한 기본 관리형 서비스를 우선 선택하세요.

문제 8

Your company operates a global fitness wearable platform where heart-rate telemetry events (about 1 KB each) arrive at highly variable rates from 50 to 25,000 events per second during weekly challenges, and you need a cost-effective solution that can absorb sudden 10–20 minute traffic spikes and process each event within 5 seconds without pre-provisioning capacity; what should you do to optimize ingestion and processing?

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 serverless, autoscaling 이벤트 수집과 준실시간 처리(near-real-time processing)를 테스트합니다. 핵심 서비스는 Pub/Sub(내구성이 있고 수평 확장이 가능한 메시징)와 Cloud Functions(자동으로 확장되는 이벤트 기반 컴퓨팅)입니다. 정답이 맞는 이유: 전 세계에서 변동성이 매우 큰 텔레메트리(초당 50~25,000 이벤트)가 들어오고, 10~20분 동안 갑작스러운 스파이크가 발생하며, 사전 프로비저닝 없이 각 이벤트를 5초 이내에 처리해야 하는 엄격한 처리 SLO가 있습니다. Pub/Sub는 생산자와 소비자를 분리하면서, 내구성 있는 subscription에 메시지를 버퍼링하여 버스티(bursty) 트래픽을 흡수하도록 설계되었습니다. Pub/Sub로 트리거되는 Cloud Function은 들어오는 메시지 볼륨에 따라 스케일 아웃하여 이벤트가 도착하는 즉시 처리합니다. 이 조합은 유휴 용량에 비용을 지불하는 것이 아니라 메시지당(Pub/Sub) 및 호출/컴퓨팅 시간당(Functions) 비용을 지불하므로 비용 효율적입니다. 핵심 기능 / 모범 사례: - 수집에는 Pub/Sub topics, 처리에는 subscriptions를 사용하세요. Pub/Sub는 at-least-once 전달을 제공하므로 함수는 idempotent하게 만들고(이벤트 ID로 중복 제거) 처리하세요. - 적절한 acknowledgement deadline과 재시도 동작을 구성하세요. 실패한 메시지는 재전달됩니다. - 더 나은 동시성 및 스케일링 제어를 위해 Cloud Functions 2nd gen(Cloud Run 기반)을 고려하세요. 필요 시 downstream 시스템을 보호하기 위해 max instances를 설정하세요. - subscription backlog(가장 오래된 unacked 메시지의 age)에 대해 모니터링(Cloud Monitoring)을 사용하여 5초 요구사항을 검증하세요. 흔한 오해: Firestore나 Cloud Storage는 이벤트를 저장할 수는 있지만, 초고속 스트리밍 수집에서 sub-5-second 처리와 함께 버스트 버퍼로 최적화되어 있지는 않습니다. 스케줄링/배칭은 지연을 유발하여 요구사항을 위반합니다. 단일 VM은 단순해 보이지만 사전 프로비저닝 없이 탄력적으로 확장할 수 없고 단일 장애 지점이 됩니다. 시험 팁: “spiky traffic”, “no pre-provisioning”, “process within seconds”를 보면 Pub/Sub + serverless compute(Cloud Functions/Cloud Run) 또는 더 복잡한 파이프라인에는 Dataflow를 떠올리세요. Pub/Sub는 Google Cloud Architecture Framework의 신뢰성과 성능 원칙(디커플링, 탄력성, 백프레셔 처리)에서 이벤트 스트림을 위한 정석적인 수집 버퍼입니다.

문제 9

Your startup is launching a multi-tenant SaaS analytics platform that stores relational subscription and billing data (SQL tables with foreign keys) and must serve users in 15+ regions worldwide. The active user base is unpredictable and may grow from 20,000 to over 3,000,000 within six months, and you must scale without planned downtime or major configuration changes. You require ACID transactions, high availability across multiple regions, and a managed service that can horizontally scale as demand increases. Which Google Cloud storage solution should you choose?

문제 분석

핵심 개념: 전 세계에 분산된, 관계형(SQL + foreign keys) 멀티 테넌트 SaaS에 대해 ACID 트랜잭션, multi-region 고가용성, 그리고 다운타임 없이 수평 확장성을 요구할 때 올바른 managed database를 선택하는 것. 정답인 이유: Cloud Spanner는 Google Cloud의 전 세계 분산, 강한 일관성을 제공하는 관계형 데이터베이스로 대규모 확장을 위해 설계되었습니다. 관계( foreign keys 포함)를 갖는 SQL 스키마, ACID 트랜잭션, 그리고 고가용성을 위한 region 간 동기식 복제를 지원합니다. 기존의 managed relational database와 달리, Spanner는 node/processing unit을 추가하여 수평 확장이 가능하므로, 계획된 다운타임이나 대규모 재설계 없이 수만 명에서 수백만 명 사용자까지 성장할 수 있습니다. 이는 예측 불가능한 성장과 글로벌 범위(15+ regions) 요구사항에 부합합니다. 주요 기능 및 모범 사례: Spanner는 strong consistency와 external consistency, 고가용성을 위한 multi-region instance configuration, 그리고 자동 sharding/replication을 제공합니다. regional 또는 multi-region instance config를 선택할 수 있으며, 여기서는 글로벌 사용자를 서비스하고 zone/region 장애를 견디기 위해 multi-region이 적합합니다. 확장은 주로 용량 기반(node/processing unit)이며, 스키마 설계는 hotspot을 피하는 primary key를 사용해야 합니다(예: 단조 증가 키 회피). 멀티 테넌트 SaaS의 경우, 부하를 분산하기 위해 tenant-aware key와 access pattern을 고려하세요. Spanner는 IAM과 통합되며, CMEK 옵션을 제공하고, 구성에 따라 managed backup 및 point-in-time recovery 기능을 제공합니다. 흔한 오해: Cloud SQL은 관계형이며 ACID를 제공하지만, 전 세계 multi-region active-active로 수백만까지 원활한 수평 확장을 하도록 설계되지 않았습니다. 일반적으로 수직 확장과 read replica/failover 패턴에 의존하며 운영상 제약이 생깁니다. Firestore는 multi-region이며 자동으로 확장되지만, NoSQL document database로서 foreign keys와 SQL join을 포함한 완전한 관계형 모델링을 제공하지 않습니다. Bigtable은 대규모 확장이 가능하지만, 관계형 제약이나 임의의 row 전반에 대한 ACID 트랜잭션이 없는 wide-column NoSQL store입니다. 시험 팁: “global users”, “multi-region high availability”, “ACID”, “horizontal scaling”이 함께 보이면 Cloud Spanner가 정석 선택입니다. 요구사항을 데이터베이스 유형에 매핑하세요: relational+global+scale => Spanner; relational+regional/limited scale => Cloud SQL; document NoSQL => Firestore; wide-column/time-series/low-latency NoSQL => Bigtable. 또한 “without planned downtime” 및 “major configuration changes” 같은 표현을 주의하세요. 이는 Spanner의 managed horizontal scaling 모델을 강하게 시사합니다.

문제 10

Your data analytics team must provision 20 Compute Engine VMs on demand across us-central1-a and europe-west1-b. All VM specs (machine type e2-standard-4, 50-GB boot disk, preemptible=true, labels env=staging and team=etl, network tags=batch-v2, startup script from gs://configs/startup.sh) must live in a single, version-controlled configuration file that can be parameterized per project. You need a declarative, reviewable, template-driven approach that can be applied with a single gcloud command and supports safe updates and rollbacks without writing ad-hoc scripts. Following Google's recommended practices, which method should you use?

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 선언적, 템플릿 기반 시스템을 사용해 Infrastructure as Code (IaC)를 구현하는 능력을 평가합니다. 이 시스템은 버전 관리가 가능하고, 프로젝트별로 파라미터화할 수 있으며, 단일 명령으로 안전한 업데이트/롤백을 지원해야 합니다. 정답이 맞는 이유: Deployment Manager는 Google Cloud의 네이티브 선언적 IaC 서비스입니다. 단일 구성(YAML)에서 리소스(Compute Engine 인스턴스, 디스크, labels, tags, metadata startup scripts 등)를 정의하며, 템플릿(Jinja2 또는 Python)을 참조할 수 있습니다. 또한 파라미터화(예: project ID, region/zone 목록, 인스턴스 수)를 지원하고, 하나의 gcloud 명령(gcloud deployment-manager deployments create|update)으로 배포/업데이트할 수 있습니다. Deployment Manager는 배포 상태를 유지하여 제어된 업데이트와, 소스 컨트롤에 저장된 이전 config 버전으로 되돌리는 방식의 롤백을 가능하게 합니다. 이는 임시(ad-hoc) 스크립팅이 아닌 선언적 IaC를 사용하라는 Google 권장 사항과 일치합니다. 주요 기능 / 모범 사례: - 프로젝트 전반에서 재사용할 수 있도록 템플릿과 속성(properties)을 포함한 단일, 검토 가능한 config 파일. - us-central1-a 및 europe-west1-b zone에 분산된 20개 VM에 대한 선언적 리소스 정의. - 인스턴스 속성 지원: e2-standard-4, boot disk 크기, preemptible 스케줄링, labels, network tags, 그리고 gs://configs/startup.sh를 가리키는 metadata startup-script-url. - 안전한 변경 관리: 변경 사항 미리보기(업데이트 계획 수립 관행을 통해) 및 일관된 업데이트 적용; 이전에 검증된 구성으로 재배포하여 롤백. - Google Cloud Architecture Framework의 운영 우수성(operational excellence) 축에 부합: 반복 가능한 배포, 변경 통제, 구성 드리프트 감소. 흔한 오해: Managed Instance Groups는 autoscaling과 self-healing이 필요한 동일한 인스턴스에 매우 유용하지만, 주로 범용 IaC 시스템이 아니며, 추가 도구(인스턴스 템플릿 + 별도의 MIG 리소스 + 스크립팅/자동화) 없이 여러 zone/프로젝트에 걸쳐 “단일 버전 관리 구성 파일”과 “단일 gcloud 명령으로 적용되는 템플릿 기반” 요구사항을 자연스럽게 충족하지 못합니다. Unmanaged instance groups는 선언적 라이프사이클 관리나 롤백을 제공하지 않습니다. Cloud Composer는 인프라 프로비저닝이 아니라 워크플로(Airflow) 오케스트레이션을 위한 서비스입니다. 시험 팁: “declarative”, “template-driven”, “version-controlled configuration”, “single command”, “safe updates/rollbacks”를 보면 Deployment Manager(또는 Terraform이지만 선택지에 없음)를 떠올리세요. MIG는 fleet 관리(autoscaling/health checks)를 위한 것이지, IaC 레이어 없이 프로젝트 전반에 걸친 엔드투엔드 선언적 프로비저닝을 위한 것은 아닙니다.