GCP

Google Cloud Digital Leader

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

실제 시험 기출 문제

상세 해설

실제 시험과 가장 유사

287+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

시험 도메인

Digital Transformation with Google Cloud출제율 17%

Exploring Data Transformation with Google Cloud출제율 16%

Innovating with Google Cloud Artificial Intelligence출제율 16%

Modernize Infrastructure and Applications with Google Cloud출제율 17%

Trust and Security with Google Cloud출제율 17%

Scaling with Google Cloud Operations출제율 17%

실전 문제

문제 1

A global retail company needs to centralize ingestion of custom application logs from 3 GKE clusters (total 150 microservices), 200 Compute Engine VMs, and 12 Cloud Run services. Requirements: accept JSON-formatted payloads with custom fields and resource labels; create log-based metrics for alerting; query and manage retention in a single place; avoid third-party collectors beyond the Google Ops Agent. Which Google Cloud tool should the company use?

문제 분석

핵심 개념: 이 문제는 Google Cloud의 중앙집중형 observability 스택을 테스트하며, 특히 이기종 compute(GKE, Compute Engine, Cloud Run) 전반에서 로그를 수집, 저장, 쿼리, 관리하고 알림에 사용되는 log-based metrics를 생성하기 위한 Cloud Logging(Google Cloud Operations suite의 일부)에 관한 것입니다. 정답이 맞는 이유: Cloud Logging은 여러 Google Cloud 리소스의 로그를 한 곳으로 중앙화하는 네이티브 서비스입니다. GKE, Compute Engine(Ops Agent를 통해), Cloud Run은 Cloud Logging과 직접 통합됩니다. 이는 structured JSON logs, custom fields, resource labels(monitored resource types 및 labels를 통해)을 지원하여 150개 microservices, 200개 VMs, 12개 Cloud Run services 전반에서 일관된 쿼리 및 필터링을 가능하게 합니다. 또한 Cloud Logging은 log-based metrics를 지원하며, 이는 Cloud Monitoring alerting policies와 함께 사용할 수 있어 third-party collectors 없이도 알림 요구사항을 충족합니다. 주요 기능 / 요구사항 충족 방식: 1) Ingestion: GKE와 Cloud Run은 container/service logs를 Cloud Logging으로 자동 내보내며, Compute Engine은 Google Ops Agent를 사용해 로그를 수집하고 전송합니다. 2) Structured logging: JSON payloads는 structured fields로 보존되어 Logs Explorer에서의 고급 쿼리 및 programmatic access를 가능하게 합니다. 3) Log-based metrics: 로그 필터( custom JSON fields 포함)로부터 counter/distribution metrics를 생성한 뒤 Cloud Monitoring에서 알림을 설정할 수 있습니다. 4) 중앙 관리 및 retention: Log Buckets, Sinks, Views를 사용해 접근 및 retention을 중앙에서 관리합니다. bucket retention(예: 30/90/365일)을 구성하고, 일부를 다른 buckets로 라우팅하거나 더 긴 retention 및 분석을 위해 BigQuery/Cloud Storage로 보낼 수 있습니다. 5) Governance: IAM controls, 일부 logging storage 시나리오에서의 CMEK 옵션, aggregated sinks를 통한 organization-level aggregation은 Google Cloud Architecture Framework의 operational excellence 및 security pillars에 부합하는 엔터프라이즈 운영을 지원합니다. 흔한 오해: 일부는 로그를 전송하려면 “Cloud SDK”가 필요하다고 생각하지만, 이는 CLI/tooling suite이지 logging backend가 아닙니다. 또 다른 일부는 Data Catalog(metadata) 또는 Dialogflow(conversational AI)를 운영 로깅과 혼동합니다. 시험 팁: “centralize logs”, “query in one place”, “structured JSON”, “log-based metrics”, “alerting” 같은 요구사항이 보이면 기본 정답은 Cloud Logging(종종 Cloud Monitoring과 함께)입니다. 또한 “Ops Agent 외 third-party collectors를 피하라”는 제약은 네이티브 Cloud Operations tooling을 강하게 시사합니다.

문제 2

A media-streaming company is migrating a 12-node analytics backend to a fully managed relational database service on Google Cloud that prohibits custom agents and targets a 99.95% monthly SLA; to reduce operational toil without writing maintenance scripts, which routine system-maintenance task will the managed platform perform automatically across all instances?

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 완전 관리형 관계형 데이터베이스 서비스(예: Cloud SQL 또는 AlloyDB)가 운영 측면에서 무엇을 대신해 주는지를 테스트합니다. “custom agents를 금지”하고 높은 가용성 SLA(월 99.95%)를 제시하는 것은 Google이 기반 인프라와 데이터베이스 유지보수의 상당 부분을 운영하는 관리형 플랫폼을 가리킵니다. 정답이 맞는 이유: 관리형 데이터베이스 플랫폼은 DBA와 스크립트가 필요했을 반복적이고 정형화된 유지보수 작업을 대신 수행하여 운영 부담을 줄입니다. 대표적인 예가 patch management로, 데이터베이스 엔진에 security patches를 적용하고 minor-version upgrades를 수행하는 것입니다. Cloud SQL에서는 maintenance updates(보안 패치 포함)를 Google이 처리하며, 유지보수 시점을 통제하기 위해 maintenance window로 일정을 잡을 수 있습니다. 이는 “maintenance scripts를 작성하지 않고” “모든 instances에 걸쳐”라는 표현과 직접적으로 부합하며, 플랫폼이 fleet-wide로 업데이트를 조율하기 때문입니다. 주요 기능 / Best Practices: - Automated maintenance: Google이 patches와 minor updates를 적용하며, 일반적으로 중단을 최소화하기 위해 maintenance window를 선택합니다. - High availability: 99.95% SLA는 보통 HA 구성(regional/replica-based)과 연관되며, 이는 downtime을 줄이도록 maintenance가 배포되는 방식에도 영향을 줍니다. - Shared responsibility: 사용자는 schema, queries, access controls는 여전히 관리하지만, Google은 기반 OS, storage, 그리고 많은 engine maintenance 작업을 관리합니다. - Architecture Framework 정렬: 이는 Operational Excellence(자동화, toil 감소)와 Security(적시 patching)를 지원합니다. 흔한 오해: 사람들은 “fully managed”가 Google이 IAM 설계, data lifecycle/archival policies, 또는 프로젝트 전반의 cost optimization까지 관리한다고 종종 가정합니다. 실제로는 shared responsibility 모델에서 IAM roles/policies와 data retention 전략은 고객 책임이며, cost optimization도 데이터베이스 서비스가 프로젝트 전반에 걸쳐 자동으로 수행하지 않습니다. Exam Tips: Digital Leader 문제에서 “fully managed database”를 보면 automated backups(구성 가능), patching/minor upgrades, replication/HA 옵션, 그리고 단순화된 운영을 떠올리세요. cross-project spend optimization이나 비즈니스별 data lifecycle 규칙을 설명하는 선택지는 보통 관리형 데이터베이스의 자동 기능이 아닙니다.

문제 3

Your micromobility startup runs 8 telemetry-processing VMs on Windows Server Standard in a colocation facility. These workloads are needed only from 08:00 to 18:00, Monday–Friday, and you shut them down nights and weekends (about 65% idle time). Your Windows Server licenses expire in 30 days, and you want to minimize ongoing license spend while keeping the ability to stop instances when idle. What should you do?

문제 분석

핵심 개념: 이 문제는 Google Compute Engine 요금과 Windows 라이선싱이 어떻게 동작하는지, 특히 유휴 시 중지할 수 있는 워크로드에 대해 평가합니다. 또한 운영 자동화(시작/중지 스케줄링)와 Google Cloud Architecture Framework의 비용 최적화도 다룹니다. 정답인 이유: 옵션 D는 Google 제공 Windows Server 이미지 사용을 통해 지속적인 라이선스 지출을 최소화합니다. 이 경우 Windows 라이선스 비용이 VM의 시간당 가격(종량제, pay-as-you-go)에 포함됩니다. 워크로드가 월–금 08:00–18:00에만 실행되므로, 업무 시간 외에는 VM을 중지하여 중지 상태에서는 컴퓨팅 요금을 피할 수 있습니다. 이는 유휴 시 인스턴스를 중지할 수 있어야 한다는 요구사항에 부합하며, 만료 예정인 Windows 라이선스를 갱신하지 않아도 되게 합니다. 주요 기능 및 모범 사례: - Compute Engine Windows 이미지는 per-vCPU/per-hour 비용에 라이선싱이 포함되어 있어, 별도의 Windows 계약을 관리할 필요가 없습니다. - 중지된 VM은 vCPU/RAM 요금이 발생하지 않으며, 일반적으로 persistent disk 및 예약된 external IP에 대해서는 계속 비용을 지불합니다. 그럼에도 24/7 사용 기준으로 산정된 Windows 라이선스를 지불하는 것보다 대개 훨씬 저렴합니다. - 스케줄을 강제하기 위해 자동화를 사용하세요: Cloud Scheduler + Cloud Functions/Cloud Run이 Compute Engine API를 호출하도록 구성하거나, 자동화 스크립트를 통한 인스턴스 스케줄을 사용합니다. 이는 인적 오류를 줄이고 운영 우수성을 지원합니다. - autoscaling이 필요할 때만 Managed Instance Groups와 rightsizing을 고려하세요. 여기서는 단순한 예약 시작/중지가 충분합니다. 흔한 오해: BYOL(옵션 C)은 더 저렴해 보일 수 있지만, 종종 활성 Software Assurance와 license mobility 규칙 충족이 필요합니다. 또한 “30일 내 라이선스 만료” 문제를 본질적으로 해결하지 못합니다—VM을 중지하더라도 라이선스 비용은 계속 부담하게 됩니다. 온프레미스 갱신 옵션(A/B)은 컴퓨팅을 종료하고 소비 기반 라이선싱으로 전환함으로써 얻는 큰 절감 효과를 무시합니다. 시험 팁: Google Cloud에서 Windows는 다음을 기억하세요: Google 제공 이미지 = 라이선스 포함 및 사용량 기반 과금; BYOL = 자격 요건을 충족해야 하며 라이선스 비용 리스크를 계속 부담합니다. 오프아워가 예측 가능한 워크로드에서는 시작/중지 스케줄링이 흔한 비용 최적화 패턴입니다. 또한 중지된 인스턴스도 스토리지 비용은 발생한다는 점을 기억하세요.

문제 4

A regional retail company is launching an inventory forecasting service on Google Cloud; finance mandates a single billing account with project-level budgets set to $18,000/month for production and $3,500/month for development, and only 8 engineers should have any permissions in development while none of them may access production; you must ensure that development workloads cannot affect production in terms of IAM, quotas, or network reachability. What should you do to meet these requirements while keeping spend tracking simple?

문제 분석

핵심 개념: 이 문제는 Google Cloud 리소스 계층 구조와 격리 경계를 테스트합니다: billing accounts, projects, IAM, quotas, 그리고 네트워크 분리. Google Cloud에서 project는 IAM policy 연결, quota 적용, 그리고 대부분의 리소스 범위 지정에 대한 기본 단위이며, budget 제어를 위한 가장 깔끔한 경계이기도 합니다. 정답이 맞는 이유: 개발 리소스를 별도의 project에 두고(단일 billing account는 유지) 동시에 모든 요구사항을 가장 잘 충족합니다: (1) 재무팀은 하나의 billing account에서 project별 budget(프로덕션 $18k, 개발 $3.5k)을 원하며, 이는 Cloud Billing budgets를 project 단위로 설정해 기본적으로 지원됩니다. (2) 개발에는 8명의 엔지니어만 권한을 가져야 하고 프로덕션에는 아무도 권한이 없어야 합니다—project를 분리하면 완전히 분리된 IAM policies를 적용할 수 있어 project 수준에서의 실수로 인한 권한 상속을 방지합니다. (3) 개발 워크로드는 IAM, quotas, 또는 네트워크 도달성 측면에서 프로덕션에 영향을 주면 안 됩니다—quotas는 project 단위(그리고 project 내 region/service 단위)로 적용되므로 dev 사용량이 prod quotas를 소진할 수 없고, IAM 분리도 명확합니다. 네트워크 도달성 또한 각 project에서 별도의 VPC를 사용하고 이를 peering하지 않음으로써(또는 필요 시 엄격한 세그먼테이션을 적용한 Shared VPC 사용) 제어할 수 있지만, project 경계가 기본적인 control plane 분리입니다. 핵심 기능 / 모범 사례: - Cloud Billing: 두 project를 동일한 billing account에 연결하고, 지출 추적을 단순화하기 위해 project별로 별도의 budgets 및 alerts를 생성합니다. - IAM: 8명의 엔지니어에게 dev project에서만 roles를 부여하고 prod project에는 roles를 부여하지 않습니다. 접근이 새어 나갈 수 있는 광범위한 org/folder 수준 bindings는 피합니다. - Quotas: quotas는 project 단위이므로 dev 부하 테스트가 prod를 고갈시키지 못합니다. - Networking: project별로 별도의 VPC networks(기본 또는 커스텀)를 사용합니다. peering/VPN/shared connectivity가 없으면 dev와 prod 간 직접적인 L3 도달성이 없습니다. 이는 Google Cloud Architecture Framework의 보안(least privilege, 강한 격리) 및 비용 관리(budgeting 및 allocation) 가이드와 일치합니다. 흔한 오해: 사람들은 종종 tags/labels 또는 별도 네트워크만으로 완전한 격리가 된다고 생각합니다. Labels는 보고를 돕지만 강제(enforcement)는 하지 않습니다. 별도 VPC는 네트워크 격리에 도움이 되지만 IAM이나 quotas를 격리하지는 않습니다. 별도 billing account는 “단일 billing account” 요구사항을 위반하며, 통합 지출 추적을 복잡하게 만듭니다. 시험 팁: 요구사항에 IAM과 quotas 격리가 언급되면 “separate projects”를 떠올리세요. 또한 별도 budgets가 필요하지만 billing account는 하나여야 한다면, 단일 billing account 하에서 project-level budgets를 사용합니다. 네트워크 격리는 일반적으로 별도 VPC와 제어된 연결로 달성하지만, 시험에서의 핵심 패턴은 project 경계입니다.

문제 5

A regional logistics company needs to build two custom AI solutions—package damage detection from images (2.5 million labeled photos) and claim text classification (600,000 labeled records)—and go live in 4 weeks. They require a fully managed, end-to-end platform that supports data preparation, GPU training, automated hyperparameter tuning, pipeline orchestration, online and batch prediction with scalable HTTPS endpoints, model registry, and monitoring, and integrates easily with BigQuery, without stitching together multiple low-level services. Which Google Cloud product should they choose?

문제 분석

핵심 개념: 이 문제는 촉박한 일정 하에서 Google Cloud에서 커스텀 모델을 엔드투엔드(데이터 준비부터 배포 및 모니터링까지)로 구축하기 위한 적절한 관리형 AI/ML 플랫폼을 선택하는지를 평가합니다. 특히 인프라와 도구를 수동으로 조합하는 방식이 아니라 통합된 MLOps 플랫폼을 가리킵니다. 정답이 맞는 이유: Vertex AI는 커스텀 트레이닝과 프로덕션 MLOps를 위해 설계된 Google Cloud의 완전 관리형 엔드투엔드 ML 플랫폼입니다. 회사는 수백만 개의 라벨링된 예시와 4주 마감이라는 조건에서 두 가지 커스텀 솔루션(컴퓨터 비전 손상 감지 및 NLP 텍스트 분류)이 필요합니다. Vertex AI는 관리형 datasets, 트레이닝(GPU 지원 포함), hyperparameter tuning, 오케스트레이션을 위한 pipelines, model registry, 그리고 관리형 online/batch prediction을 제공합니다. 또한 BigQuery와 깔끔하게 통합되어 데이터 접근 및 feature 워크플로를 지원하므로 “여러 저수준 서비스를 이어 붙이는(stitching together)” 것을 피해야 한다는 요구사항을 충족합니다. 주요 기능(요구사항과의 매핑): - 데이터 준비 및 관리: Vertex AI Datasets 및 BigQuery, Cloud Storage와의 통합. - GPU 트레이닝: GPU-enabled machine types를 사용하는 Vertex AI Custom Training; 관리형 training jobs. - 자동화된 hyperparameter tuning: Vertex AI Hyperparameter Tuning. - 파이프라인 오케스트레이션: 반복 가능한 ML 워크플로를 위한 Vertex AI Pipelines(관리형 Kubeflow Pipelines). - 배포: 확장 가능한 HTTPS online prediction을 위한 Vertex AI Endpoints; 오프라인 스코어링을 위한 Batch Prediction. - 거버넌스 및 라이프사이클: 버전 관리 및 승격을 위한 Vertex AI Model Registry. - 모니터링: Vertex AI Model Monitoring(예: drift/skew/feature distribution monitoring) 및 logging/metrics 통합. 흔한 오해: Compute Engine과 Dataproc는 ML 워크로드를 실행할 수 있지만, 인프라/데이터 처리 서비스이므로 (트레이닝 코드, 오케스트레이션, 배포, 모니터링, registry 등) 많은 구성요소를 직접 조합해야 합니다. 이는 제시된 제약 조건에서는 너무 느리고 복잡합니다. Recommendations AI는 리테일 스타일의 추천을 위한 사전 구축 솔루션이며, 커스텀 비전/NLP 트레이닝을 위한 것이 아닙니다. 시험 팁: “end-to-end managed ML”, “pipelines”, “model registry”, “online endpoints”, “monitoring”, “BigQuery integration” 같은 요구사항이 보이면 Digital Leader에서의 정답은 거의 항상 Vertex AI입니다. 사전 구축 AI APIs는 제한된 작업에 적합하고, 인프라 서비스는 커스텀에 적합하지만 DIY 구축이며, Vertex AI는 커스텀 + 관리형 MLOps를 빠르게 구현하는 데 적합합니다.

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

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

문제 6

A smart home company runs its control platform on a managed messaging service from its cloud provider that guarantees 99.99% monthly availability, but last month monitoring showed only 99.6% availability (about 173 minutes of cumulative downtime), intermittently preventing devices from receiving commands—what is a likely impact on the organization?

문제 7

A logistics company operates 24 Kubernetes clusters (12 on-premises, 8 on Google Cloud, and 4 on AWS) to support microservices across 60 warehouses and needs a single, centralized platform to consistently manage policies, configurations, service mesh, and observability across all environments without relocating workloads; which Google Cloud service should they choose?

문제 분석

핵심 개념: 이 문제는 Google Cloud의 하이브리드 및 멀티클라우드 Kubernetes 관리 역량—특히 워크로드를 이동하지 않고 서로 다른 환경(on-prem, Google Cloud, AWS)에서 실행되는 클러스터 전반에 걸친 중앙집중식 정책/구성 관리, service mesh, 그리고 observability를 테스트합니다. 정답이 맞는 이유: GKE Enterprise는 환경 전반에 걸친 Kubernetes 클러스터 플릿(fleet)을 관리하도록 설계되었습니다. 이는 on-prem(대개 Google Distributed Cloud를 통해), Google Cloud(GKE), 그리고 다른 클라우드(예: AWS 포함) 전반에서 일관된 거버넌스와 운영을 위한 단일 control plane 경험을 제공합니다. “단일, 중앙집중식 플랫폼”과 “policies, configurations, service mesh, and observability” 요구사항은 GKE Enterprise의 fleet management 및 Anthos 기반(heritage)에 정확히 대응하며, 워크로드 재배치 없이 표준화를 가능하게 합니다. 주요 기능 / Best Practices: - Fleet management: 클러스터를 fleet에 등록하여 중앙집중식 관리와 일관성을 확보합니다. - Policy and configuration: Policy Controller(OPA/Gatekeeper)와 Config Management를 사용해 원하는 상태(desired state)(예: namespaces, RBAC, resource constraints)를 모든 클러스터에 걸쳐 강제하고 동기화합니다. - Service mesh: Anthos Service Mesh(Istio 기반)는 클러스터 전반에서 일관된 트래픽 관리, mTLS, 그리고 서비스 간 observability를 제공합니다. - Observability: fleet 전반에서 중앙집중식 telemetry, dashboards, tracing 통합(일반적으로 Cloud Operations suite를 통해)을 제공합니다. - Architecture Framework 정렬: 이기종 환경 전반에서 운영 우수성(표준화된 운영), 보안(policy enforcement, mTLS), 신뢰성(일관된 rollout 패턴)을 개선합니다. 흔한 오해: Cloud Run 또는 Cloud Functions는 운영을 단순화하므로 선택될 수 있지만, 이들은 serverless compute 플랫폼이지 멀티클러스터 관리 계층이 아닙니다. Compute Engine은 인프라 compute이며 Kubernetes fleet 거버넌스, mesh, 또는 중앙집중식 policy management를 제공하지 않습니다. 시험 팁: “hybrid/multi-cloud Kubernetes”, “centralized governance”, “policy/config consistency”, “service mesh across clusters”를 보면 GKE Enterprise(Anthos capabilities)를 떠올리세요. 또한 “without relocating workloads”라는 명시적 제약은 마이그레이션이나 단일 환경 compute 서비스가 아니라 management plane을 가리킵니다.

문제 8

Your 12-person logistics startup must add image label detection for 50,000 product photos per month and sentiment analysis on 5,000 support emails per week within 30 days and without hiring any new staff; how do Google Cloud's out-of-the-box AI APIs make AI/ML adoption feasible for your team?

문제 분석

핵심 개념: 이 문제는 Google Cloud의 사전 학습된, 즉시 사용 가능한 AI 서비스(흔히 “AI APIs”라고 부름)를 평가합니다. 예를 들어 이미지 라벨 감지를 위한 Cloud Vision API, 감성 분석을 위한 Natural Language API(또는 Vertex AI 언어 기능) 등이 있습니다. 이러한 서비스는 REST/gRPC 엔드포인트와 클라이언트 라이브러리를 제공하는 관리형 서비스로, 팀이 모델을 구축하거나 학습하지 않고도 AI 기능을 추가할 수 있게 해줍니다. 정답인 이유: 소규모 스타트업은 두 가지 AI 기능을 빠르게(30일 이내) 제공해야 하며 ML 전문가를 채용하지 않아야 합니다. Google Cloud의 사전 학습된 API는 정확히 이런 시나리오를 위해 설계되었습니다. 데이터(이미지 또는 텍스트)를 API로 전송하면 즉시 예측(라벨 또는 감성)을 반환받습니다. 커스텀 모델 개발 라이프사이클(데이터 라벨링, feature engineering, 학습, hyperparameter tuning, 평가, 배포, 모니터링)이 필요하지 않습니다. 이는 time-to-value와 운영 부담을 크게 줄여주며, 관리형 서비스를 사용해 차별화되지 않는 무거운 작업(undifferentiated heavy lifting)을 줄이라는 Google Cloud Architecture Framework 원칙과도 부합합니다. 주요 기능: 1) 사전 학습된 모델: Vision 라벨 감지와 감성 분석이 out-of-the-box로 동작합니다. 2) 간단한 통합: 클라이언트 라이브러리, REST 호출, IAM으로 제어되는 service account. 3) 확장성: API는 월/주 단위 배치 워크로드를 처리하도록 확장됩니다. Cloud Run/Functions + Cloud Scheduler로 배치 작업을 실행하거나, 더 큰 파이프라인에는 Dataflow를 사용할 수 있습니다. 4) 거버넌스 및 보안: IAM 권한(least privilege), audit logs, 그리고 데이터 유출(data exfiltration) 보호를 위한 선택적 VPC Service Controls. 5) 비용 모델: 요청/처리 단위당 pay-per-use 과금으로, 월 50,000장 이미지와 주 5,000건 이메일 같은 변동성 워크로드에 매력적입니다. 흔한 오해: 일부는 “AI”가 항상 커스텀 학습(D)을 필요로 한다고 가정하거나, 관리형 AI가 데이터 준비(B)의 필요성을 없앤다고 생각합니다. 실제로는 유효한 입력(올바른 이미지 포맷, 텍스트 인코딩, 언어 고려사항)을 제공하고 품질 검사를 처리해야 하지만, 모델을 만들 필요는 없습니다. 또 다른 오해는 AI APIs가 보안 요구사항(C)을 줄인다는 것인데, 실제로는 여전히 적절한 IAM 및 데이터 처리 통제가 필요합니다. 시험 팁: Digital Leader 문제에서는 비즈니스 제약(소규모 팀, 빠른 일정, 채용 없음)을 관리형 서비스와 사전 학습된 API에 매핑하세요. OCR, 라벨링, 번역, 감성, 엔터티 추출, speech-to-text 같은 작업이 보이면, 커스텀 ML 개발이 비현실적인 경우 대개 Google의 out-of-the-box AI APIs 또는 Vertex AI pre-built 오퍼링이 최선의 답입니다.

문제 9

A national bike-sharing consortium needs to publish real-time docking station availability (updated every 2 seconds) from 300 municipal operators and simultaneously receive rider rental/return events in real time to forward to each operator’s system. They require a standardized, secure, versioned interface over HTTPS that supports authentication and partner-specific rate limits; what should they implement?

문제 10

A food-delivery marketplace is building a new order-tracking system that stores JSON documents and requires real-time updates to listeners, offline synchronization for iOS/Android/web clients, automatic serverless scaling from 0 to 150,000 daily active users, and multi-region availability with typical write latencies under 100 ms; which Google Cloud product should they choose for a flexible, scalable NoSQL database with strong web and mobile SDK support?

문제 분석

핵심 개념: 이 문제는 JSON-like documents, real-time listeners, offline sync, 그리고 multi-region availability를 갖춘 자동 serverless scaling이 필요한 web/mobile apps에 적합한 managed NoSQL database를 선택하는지를 평가합니다. 정답인 이유: Firestore (Cloud Firestore)는 document storage (JSON-like documents), listeners를 통한 real-time updates, 그리고 offline-first client 동작이 필요한 application backends를 위해 목적에 맞게 설계되었습니다. iOS, Android, Web, 그리고 server 환경을 위한 first-class SDKs를 제공하여, clients가 변경 사항을 구독하고 연결이 복구되면 자동으로 동기화할 수 있습니다. Firestore는 fully managed 및 serverless이므로 capacity planning 없이 자동으로 확장되며, “0에서 150,000 daily active users까지 확장” 요구사항과 잘 부합합니다. Multi-region deployments의 경우 Firestore는 강한 availability 특성을 가진 multi-region locations를 제공하고, 일반적으로 regional users에 대해 낮은 latencies를 제공합니다. 문제의 “typical write latencies under 100 ms”는 clients가 선택한 location 근처에 있을 때 Firestore의 일반적인 성능 프로파일과 일치합니다. 주요 기능 / Best Practices: Firestore는 document/collection modeling, automatic indexing(필요 시 composite indexes 포함), 그리고 real-time streams를 지원합니다. Offline persistence는 mobile 및 web SDKs에서 제공되어 local caching과 queued writes를 가능하게 합니다. Multi-region configuration은 resilience를 향상시키며 Google Cloud Architecture Framework의 reliability 및 operational excellence(관리형 서비스, ops 부담 감소) 원칙과도 부합합니다. Security는 일반적으로 Firebase Authentication + Firestore Security Rules(또는 server access를 위한 IAM)로 적용합니다. Scale 및 cost control을 위해 효율적인 document structures를 설계하고, hot documents를 피하며, batched writes/transactions를 적절히 사용하세요. 자주 하는 오해: Cloud Spanner는 globally consistent하고 relational이지만, offline mobile sync 및 client SDKs를 통한 real-time listeners에 최적화되어 있지 않습니다. Cloud Storage는 objects(blobs)를 저장하며, real-time subscriptions가 가능한 queryable documents가 아닙니다. BigQuery는 analytics warehouse이며, low-latency app reads/writes를 위한 operational database가 아닙니다. Exam Tips: “real-time listeners”, “offline sync”, “mobile/web SDKs”가 보이면 Firestore(또는 Firebase Realtime Database)를 떠올리세요. 또한 flexible JSON documents와 serverless scaling을 강조한다면 Firestore가 최적의 선택입니다. Spanner는 relational schemas, SQL, 그리고 높은 규모의 OLTP에서 global strong consistency가 필요할 때 사용하며, offline-first client synchronization 용도는 아닙니다.

문제 11

An international airline is launching a real-time reservation platform serving customers in 12 regions across North America, Europe, and APAC. Seat inventory and payment records must be updated with strongly consistent ACID transactions across regions, 24/7 availability, and sub-100 ms regional read latency, and the system must horizontally scale to over 50 million bookings per day with multi-petabyte operational data growth projected over 3 years. Which Google Cloud product should they choose?

문제 분석

핵심 개념: 이 문제는 전 세계적으로 분산된 운영 데이터베이스 중에서, 리전 간 강력한 일관성(ACID), 고가용성, 사용자 근처에서의 저지연 읽기, 그리고 대규모 수평 확장성을 제공하는 선택지를 고르는지를 평가합니다. 정답이 맞는 이유: Cloud Spanner는 Google Cloud의 전 세계적으로 분산된 관계형 데이터베이스로, 행성 규모의 미션 크리티컬 OLTP를 위해 설계되었습니다. Cloud Spanner는 관계형 스키마와 SQL을, 동기식 복제와 TrueTime을 사용한 리전 간 강력한 외부 일관성과 독특하게 결합합니다. 항공사 예약 시스템에서는 좌석 재고와 결제가 엄격한 정확성(이중 예약 방지, 업데이트 유실 방지)을 요구하며, 12개 리전에서 동시 쓰기가 발생하더라도 이를 보장해야 합니다. Spanner는 multi-region instance로 실행하여 리전 간 ACID 트랜잭션을 유지하면서 24/7 가용성과 자동 failover를 제공할 수 있습니다. 주요 기능 / Best Practices: - 재고 및 재무 기록에 적합한 리전 간 강력한 일관성의 ACID 트랜잭션(외부 일관성). - Multi-region 구성(예: nam3, eur3, asia3 또는 custom)을 통해 전역 정확성을 유지하면서 사용자 근처에 replica를 배치하여 리전 내 sub-100 ms 읽기를 제공. - node/processing unit 추가를 통한 수평 확장; 매우 높은 처리량(하루 수천만 건의 쓰기)과 multi-petabyte 운영 데이터셋 지원. - 동기식 복제와 자동 failover를 통한 고가용성; Google Cloud Architecture Framework의 reliability 및 performance 목표와 정렬. - hotspot을 피하기 위한 schema 설계와 key 설계(예: 쓰기가 많은 테이블에서 단조 증가 primary key 회피; hashed key 고려) 및 저지연 읽기를 위한 read-only transaction 사용. 흔한 오해: Cloud SQL은 관계형이며 ACID를 제공하지만, 주로 regional이며 이 규모에서 multi-region 동기식 쓰기와 함께 전 세계적으로 분산된 강력한 일관성을 제공하지는 않습니다. BigQuery와 Cloud Storage는 각각 analytics와 object storage에 매우 뛰어나지만, 실시간 예약을 위한 OLTP 트랜잭션 시스템은 아닙니다. Exam Tips: “global”, “strong consistency across regions”, “ACID”, “high availability”, “massive horizontal scale”을 보면 Cloud Spanner를 떠올리세요. 워크로드가 analytical(리포팅/BI)이라면 BigQuery, objects/blobs라면 Cloud Storage, 전통적인 regional 관계형 DB라면 Cloud SQL을 생각하면 됩니다.

문제 12

A regional hospital network plans to use Google Cloud’s advanced ML services (such as Vertex AI) for radiology model training and inference, but regulations require all 120 TB of patient images and metadata to remain stored only in its on-premises data center; the hospital has a 5 Gbps Dedicated Interconnect to Google Cloud and must ensure no PHI is persisted in the public cloud. Which overall cloud strategy should they adopt to meet these constraints while still using Google Cloud’s ML capabilities?

문제 분석

핵심 개념: 이 문제는 클라우드 배포 모델(하이브리드 vs. 퍼블릭/프라이빗/멀티 클라우드)과, Google Cloud의 관리형 ML 서비스(예: Vertex AI)를 사용하면서도 엄격한 데이터 상주성 및 보안 요구사항(퍼블릭 클라우드에 PHI를 저장하지 않음)을 충족하는 방법을 평가합니다. 정답인 이유: 하이브리드 클라우드 접근 방식은 온프레미스 인프라(규제 대상 PHI가 반드시 남아 있어야 하는 위치)와 퍼블릭 클라우드 서비스(탄력적 컴퓨팅 및 관리형 ML 기능)를 결합합니다. 병원은 120 TB의 이미지/메타데이터를 온프레미스에만 저장한 채, 5 Gbps Dedicated Interconnect를 사용해 Google Cloud로 프라이빗하고 고처리량의 연결을 구성할 수 있습니다. 이는 스토리지가 온프레미스에 유지되므로 “퍼블릭 클라우드에 PHI가 저장되면 안 됨” 제약과 부합하며, 아키텍처 및 거버넌스에 따라 통제된 일시적 처리만 Google Cloud에서 수행할 수 있습니다. 주요 기능 / 구현 방법: - 연결: Dedicated Interconnect는 인터넷 VPN 대비 프라이빗 연결과 예측 가능한 대역폭/지연 시간을 제공하여 대규모 데이터 접근 패턴을 지원합니다. - 데이터 거버넌스: PHI가 Cloud Storage/BigQuery 등에 기록되지 않도록 설계합니다. 엄격한 IAM, VPC Service Controls(해당되는 경우), 조직 정책을 사용해 우발적 데이터 유출을 줄입니다. - 처리 패턴: 학습/추론 중 온프레미스에서 데이터를 스트리밍하거나 접근하고, 임시 컴퓨트 디스크 및 로그에 PHI가 남지 않도록 보장합니다. 가능하다면 온프레미스에서 비식별화/토큰화를 고려하고, 비-PHI 특징(feature)만 클라우드로 전송합니다. - Architecture Framework 정렬: 이는 주로 Trust and Security 결정(데이터 상주성, 컴플라이언스, 최소 권한)이지만, 신뢰성과 성능(전용 프라이빗 연결)도 함께 다룹니다. 흔한 오해: - “Private cloud”는 데이터가 온프레미스에 남는다는 점에서 그럴듯해 보이지만, Google Cloud의 관리형 ML 서비스를 사용해야 한다는 요구사항을 충족하지 못합니다. - “Public cloud”는 PHI를 Google 관리 스토리지/서비스에 저장/처리하는 것을 의미하므로 부적절합니다. - “Multi-cloud”는 여러 퍼블릭 클라우드를 사용하는 것이며, 온프레미스에만 저장해야 한다는 요구사항을 해결하지 못합니다. 시험 팁: 문제에서 데이터가 온프레미스에 남아야 한다(규제/주권/PHI)고 하면서도 퍼블릭 클라우드 서비스를 사용하길 원한다면, 기본 정답은 하이브리드 클라우드입니다. Dedicated Interconnect, on-prem data center, “no data persisted in cloud” 같은 키워드는 하이브리드 연결과 엄격한 데이터 거버넌스 통제를 강하게 시사합니다.

문제 13

An international retail marketplace is migrating its order processing and customer analytics to Google Cloud, storing personally identifiable information (PII) for 50 million users across 12 countries in the EU, US, and APAC, with workloads in europe-west1, us-central1, and asia-southeast1. To ensure compliance with global standards during migration—given obligations such as GDPR, CPRA/CCPA, and the Australia Privacy Act—what approach should the company take regarding security and privacy regulations?

문제 분석

핵심 개념: 이 문제는 다중 관할권, 다중 리전 클라우드 마이그레이션에서 보안 및 프라이버시 컴플라이언스를 위한 거버넌스를 평가합니다. 핵심 아이디어는 컴플라이언스가 데이터 주체가 거주하는 위치와 데이터가 수집/처리/저장되는 위치에 의해 좌우되며, 프라이버시 법률(GDPR, CPRA/CCPA, Australia Privacy Act)과 보안 표준을 함께 다뤄야 한다는 점입니다. 정답이 맞는 이유: 옵션 A가 정답인 이유는 EU, US, APAC 전반에서 PII를 처리하는 국제 소매업체는 각 관련 관할권에서 적용되는 법적 및 규제 요구사항을 충족해야 하기 때문입니다. GDPR은 EU 데이터 주체에 적용되며 엄격한 규칙(적법한 근거, 데이터 최소화, DPIA, 국경 간 이전 메커니즘, 침해 통지)을 부과합니다. CPRA/CCPA는 특정 California 거주자에게 적용되며 소비자 권리, 고지, 데이터 공유에 초점을 둡니다. Australia’s Privacy Act는 호주 개인 정보 처리에 적용됩니다. 이들은 서로를 “대체”하지 않으며, 의무는 중첩될 수 있고 조직은 각 처리 활동별로 적용되는 가장 엄격한 요구사항을 충족해야 합니다. 주요 기능 / 모범 사례 (Google Cloud 맥락): 정책 기반 접근을 사용하세요: 데이터 분류, 처리 활동 기록, privacy-by-design. IAM least privilege, 데이터 유출 위험 감소를 위한 VPC Service Controls, 요구 시 Cloud KMS/Cloud HSM 및 CMEK, Cloud Audit Logs를 통한 감사 로깅, 발견/마스킹/토큰화를 위한 DLP 같은 기술적 통제를 구현하세요. 적절한 리전(europe-west1, us-central1, asia-southeast1)을 선택해 데이터 레지던시와 접근 통제를 적용하고, 문서화된 법적 메커니즘과 강력한 암호화로 cross-region 전송을 관리하세요. 관련되는 경우 Organization Policy constraints, Security Command Center, Assured Workloads를 사용해 가드레일을 강제하세요. 흔한 오해: 자주 있는 함정은 국제 표준(ISO 27001/27701)을 채택하면 법률을 자동으로 충족한다고 믿는 것입니다. 표준은 보안/프라이버시 관리 시스템을 입증하는 데 도움이 되지만, 법정 요구사항을 대체하지는 않습니다. 또 다른 오해는 보안을 프라이버시와 분리해서 다루는 것입니다. 프라이버시 요구사항은 종종 보안 보호조치와 사용자 권리 처리 프로세스를 요구합니다. 시험 팁: Digital Leader에서는 “적용 가능한 모든 규정 준수”와 shared responsibility를 강조하는 답을 고르세요: Google은 cloud를 보호하고, 고객은 접근 구성, 데이터 처리, 컴플라이언스 프로세스를 구성합니다. 여러 국가/리전이 관련되면, 하나의 프레임워크로 모두를 커버한다고 가정하지 말고 관할권별 및 데이터 흐름별로 요구사항을 매핑해야 한다고 가정하세요.

문제 14

A healthcare imaging startup has 0 legacy applications and no on-premises servers to migrate. They plan to launch a new AI-assisted diagnostics platform entirely on Google Cloud within 6 months and explicitly want cloud-native microservices from day 1 (managed services over VMs, no lift-and-shift). Which application modernization approach should they choose?

문제 분석

핵심 개념: 이 문제는 애플리케이션 현대화 전략 선택(greenfield vs. brownfield, refactor vs. rehost)과 비즈니스 맥락에 맞게 접근 방식을 정렬하는 능력을 평가합니다. Google Cloud 관점에서 “day 1부터 cloud-native microservices”는 기존 워크로드를 마이그레이션하는 것이 아니라, managed services(예: Cloud Run, GKE Autopilot, Pub/Sub, Cloud SQL/Spanner, Vertex AI)를 중심으로 설계하는 것을 의미합니다. 정답이 맞는 이유: 이 스타트업은 legacy applications가 0개이고 on-premises servers도 없습니다. 즉, 기존 환경에서 마이그레이션, rehost, refactor할 대상이 없습니다. 목표는 6개월 내 Google Cloud에서 새로운 플랫폼을 출시하는 것이며, VMs보다 cloud-native microservices와 managed services를 명시적으로 선호합니다. 이는 greenfield 접근 방식의 정의와 일치합니다. 즉, 처음부터 클라우드를 위해 설계된 완전히 새로운 애플리케이션을 현대적 패턴(microservices, event-driven architecture, managed databases, CI/CD)으로 구축하는 것입니다. 주요 특징 / Best Practices: Greenfield build는 다음을 가능하게 합니다: - Managed compute에서의 microservices: 운영 부담을 줄이기 위해 Cloud Run(serverless containers) 또는 GKE Autopilot(managed Kubernetes) 사용. - Event-driven 통합: 서비스 간 결합도를 낮추고 복원력을 높이기 위해 Pub/Sub 사용. - Managed data stores: 관계형 요구에는 Cloud SQL, 문서형 워크로드에는 Firestore, 글로벌 규모에는 Spanner 사용. - Security-by-design: IAM least privilege, 민감한 healthcare data를 위한 VPC Service Controls, Cloud KMS, Cloud Audit Logs. - Delivery velocity: CI/CD를 위한 Cloud Build + Artifact Registry + Cloud Deploy; Terraform을 통한 Infrastructure as Code. 이는 Google Cloud Architecture Framework 원칙(operational excellence: managed services, reliability: decoupling, security: defense-in-depth, cost optimization: 적절한 경우 pay-per-use serverless)과도 정렬됩니다. 흔한 오해: “migrate first” 또는 “refactor on premises” 같은 옵션은 현대화처럼 들릴 수 있지만, 이는 기존 애플리케이션 자산이 있다는 전제를 깔고 있습니다. “Brownfield” 현대화는 기존 환경과의 통합 또는 기존 환경의 변환이 필요할 때 적용됩니다. 여기서는 legacy footprint가 없으므로, 그런 접근은 불필요한 단계와 리스크만 추가합니다. Exam Tips: 키워드를 확인하세요: “no legacy,” “no on-prem,” “net-new,” “cloud-native from day 1” → greenfield build. 시나리오에 기존 apps/VMs/data centers가 언급되면 rehost/refactor/brownfield를 고려하세요. 또한 Digital Leader 문제는 종종 제약과 원하는 결과(속도, managed services, 최소 운영)에 맞는 가장 단순한 전략을 고르는지를 평가합니다.

문제 15

A fintech company with 12 departments must comply with a policy that forbids any Compute Engine VM from having a public (external) IP; over the next quarter, 5 new folders and about 30 new projects will be created by different teams using automated pipelines. You need a scalable control that applies by default to all current and future resources and prevents assigning external IPs to VMs across the organization; what should you do?

문제 분석

핵심 개념: 이 문제는 Google Cloud 리소스 계층 구조와 Organization Policy Service(정책-코드 기반 가드레일)를 평가합니다. Organization policies를 사용하면 조직, 폴더, 프로젝트 전반에 걸쳐 보안 제약을 중앙에서 강제할 수 있으며, 기본적으로 계층 구조를 따라 하위로 상속됩니다. 정답이 맞는 이유: 현재는 물론 향후 새 폴더/프로젝트가 추가되더라도 어떤 Compute Engine VM도 external IP로 생성되지 않도록 하려면, 적용 가능한 가장 상위 지점인 organization root node에 constraint를 적용해야 합니다. org 수준에서 constraints/compute.vmExternalIpAccess를 설정하면 확장 가능한 default-deny 제어가 생성되어, 자동화 파이프라인으로 생성되는 5개의 새 폴더와 약 30개의 새 프로젝트를 포함해 모든 하위 폴더와 프로젝트에 자동으로 적용됩니다. 이는 팀이 프로젝트별 설정을 기억하는 것에 의존하지 않고 “현재 및 미래의 모든 리소스에 기본적으로 적용”이라는 요구사항을 충족합니다. 주요 기능 / 모범 사례: - 상속(Inheritance): organization node에서 설정된 정책은(허용되는 경우 명시적으로 override되지 않는 한) 모든 하위 항목으로 전파됩니다. 이는 Google Cloud Architecture Framework의 Security, privacy, and compliance pillar와 일치하며, 예방적 제어를 중앙에서 강제합니다. - 예방적 가드레일(Preventive guardrail): constraints/compute.vmExternalIpAccess는 VM 생성 시 external IP 할당을 차단하며(또한 어떤 principal/project가 이를 사용할 수 있는지 제한할 수도 있음), 데이터 유출 위험을 줄이고 private-by-default 네트워크 보안 태세를 강제합니다. - 운영 확장성(Operational scalability): 정책 변경 한 번으로 향후 성장까지 커버하며, 다수의 프로젝트 전반에서 드리프트를 방지합니다. 흔한 오해: 팀들은 종종 문서화나 CI/CD 템플릿 변경(옵션 D)으로 이를 강제하려고 합니다. 하지만 이는 신뢰할 수 있는 제어가 아닙니다. 기껏해야 탐지적(detective) 접근이며 예외, 드리프트, 인적 오류에 취약합니다. 또 다른 경우로 폴더/프로젝트(B/C)에 정책을 적용하는데, 이는 기존 리소스에만 동작하며 새 폴더/프로젝트가 생길 때마다 지속적으로 업데이트가 필요합니다. 시험 팁: “현재 및 미래의 모든 projects/folders”와 “확장 가능한 제어”가 보이면 org root에서의 Organization Policy를 떠올리세요. 리소스 계층 구조를 활용해 관리 오버헤드를 최소화하십시오. 또한 firewall rules 같은 네트워크 수준 제어는 external IP 할당 자체를 막지 못한다는 점을 기억하세요. 구성 제약에 대한 올바른 예방 메커니즘은 organization policies입니다.

문제 16

An e-commerce startup named ParcelPeak operates a Cloud SQL for PostgreSQL instance (db-custom-4-15360) ingesting about 400,000 order, payment, and refund rows per day from 7 microservices across 3 regions. Executives request weekly KPI dashboards and ad-hoc cohort revenue analysis without exporting data to on-prem systems. In this situation, which capability of Cloud SQL most directly helps the team turn this operational data into business insights?

문제 분석

핵심 개념: 이 문제는 Cloud SQL의 역할을 관리형 relational database로 인식하고, 조직이 그 안에 저장된 운영 데이터를 통해 일반적으로 어떻게 비즈니스 인사이트를 도출하는지에 관한 것입니다. Cloud SQL 자체는 business intelligence 플랫폼이 아니지만, 표준 database connectivity를 사용해 analytics 및 reporting 도구와 연결할 수 있습니다. 팀에 가장 직접적으로 도움이 되는 기능은 BI 도구 및 analytics 플랫폼과의 통합으로, 이를 통해 cloud-hosted relational data에서 dashboard를 구축하고 분석을 실행할 수 있습니다. 정답인 이유: 경영진은 데이터를 다시 on-premises로 옮기지 않고 KPI dashboard와 ad-hoc revenue analysis를 원합니다. Cloud SQL for PostgreSQL은 표준 PostgreSQL-compatible connection을 지원하므로 Looker Studio, Looker 및 기타 analytics 플랫폼이 데이터를 query하고 인사이트를 제공할 수 있습니다. 따라서 A 옵션이 가장 적합합니다. 이는 Cloud SQL이 비즈니스 인사이트에 기여하는 실질적인 방식을 설명하기 때문입니다. 즉, reporting 및 analysis를 위한 관리형 relational source 역할을 합니다. 주요 기능: Cloud SQL은 표준 SQL access, secure connectivity, backup, high availability option을 갖춘 관리형 PostgreSQL을 제공합니다. 익숙한 relational interface를 사용하기 때문에 많은 BI 및 reporting 도구가 직접 연결할 수 있습니다. 이로 인해 운영 reporting을 위한 source of truth로 유용하지만, 더 무거운 analytical workload는 전용 analytics service가 더 적합한 경우가 많습니다. 일반적인 오해: 흔한 실수는 Cloud SQL에 built-in dashboarding, machine learning 또는 ETL 기능이 포함되어 있다고 가정하는 것입니다. Cloud SQL은 기본적으로 chart를 생성하거나, model을 학습시키거나, unstructured data를 structured dataset으로 변환하지 않습니다. 이러한 기능은 Cloud SQL에 연결되는 다른 Google Cloud 또는 partner service에서 제공합니다. 시험 팁: Digital Leader 문제에서는 각 product를 그 주요 목적에 맞게 매핑하세요. Cloud SQL은 관리형 relational database 및 transactional workload용이고, Looker 및 Looker Studio와 같은 BI 도구는 dashboard와 analysis에 사용됩니다. 문제가 Cloud SQL이 인사이트 생성에 어떻게 도움이 되는지 묻는다면, 가장 좋은 답은 보통 native analytics 기능보다는 analytics 도구와의 통합에 관한 것입니다.

문제 17

A regional nonprofit with 12 offices and 650 staff must roll out email, calendaring, and a document collaboration suite within 14 days, meet a 99.9% availability target, stay under a $12,000 monthly IT budget, and has only one part-time sysadmin; they want the provider to handle upgrades, backups, security baselines, and scaling so the team can focus on using the apps. In this scenario, which cloud service model is the best fit, and why would choosing SaaS be appropriate?

문제 분석

핵심 개념: 이 문제는 클라우드 서비스 모델(SaaS vs PaaS vs IaaS)을 이해하고, 이를 비즈니스 제약 조건(빠른 롤아웃, 고가용성, 제한된 IT 인력, 예측 가능한 비용, 운영을 제공자가 관리하길 원하는 요구)에 맞게 매칭하는지를 평가합니다. 정답이 맞는 이유: SaaS(Software as a Service)가 최적의 선택입니다. 비영리 단체는 14일 내에 99.9% 가용성을 갖춘 이메일, 캘린더, 문서 협업 스위트를 도입해야 하며, 파트타임 sysadmin 1명만 있고 엄격한 월 예산 제약이 있습니다. SaaS에서는 제공자가 전체 애플리케이션 스택(애플리케이션, runtime, OS, infrastructure)을 운영하며, 업그레이드, 패치, 백업, 보안 기준선, 확장까지 포함해 관리합니다. 이는 “제공자가 업그레이드, 백업, 보안 기준선, 확장을 처리하여 팀이 앱 사용에 집중할 수 있어야 한다”는 요구사항과 직접적으로 부합합니다. Google Cloud 관점에서 이는 일반적으로 Gmail, Calendar, Drive, Docs를 위한 Google Workspace에 해당하며, 빠른 배포와 최소한의 고객 운영을 목표로 설계되어 있습니다. 주요 기능 / 모범 사례: SaaS 오퍼링은 내장 SLA(대개 99.9%를 충족하거나 초과), 중앙집중식 admin 제어, 그리고 MFA/2-Step Verification, SSO/SAML, DLP 및 retention(플랜에 따라 다름), audit logs와 같은 보안 기능을 제공합니다. 용량 계획, 서버 유지보수, 소프트웨어 버전 관리 같은 운영 작업은 벤더가 처리하므로, 차별화되지 않는 반복 작업을 줄여 Google Cloud Architecture Framework의 “operational excellence” 원칙을 지원합니다. 비용은 보통 사용자당/월 과금이어서 IaaS/PaaS에서 동등한 시스템을 구축·운영하는 것보다 예측 가능성이 높습니다. 흔한 오해: PaaS는 서버 관리 부담을 줄여주기 때문에 매력적으로 보일 수 있지만, 이는 즉시 사용 가능한 협업 스위트를 채택하는 것이 아니라 커스텀 애플리케이션을 빌드/배포하기 위한 모델입니다. IaaS는 최대한의 제어를 제공하지만 운영 부담(패치, 백업, HA 설계)을 증가시켜 인력 및 일정 제약과 충돌합니다. 또한 모델 간 “dynamic shifting”은 이 시나리오에서 주요 선택 기준이 아닙니다. 시험 팁: 요구사항이 가장 빠른 time-to-value, 최소 IT 운영, 벤더 관리 업데이트/가용성, 표준 비즈니스 기능(이메일/문서)을 강조하면 SaaS를 선택하세요. 서버를 관리하지 않고 커스텀 코드 배포를 강조하면 PaaS를 고려하세요. OS/네트워크 제어를 강조하면 IaaS를 고려하세요. 항상 제약 조건(인력, SLA, 일정, 예산 예측 가능성)을 shared responsibility model에 매핑하세요.

문제 18

A nationwide media company runs compute-heavy web, analytics, and ML training workloads across 9 Google Cloud projects that all use the same billing account; per-project monthly costs fluctuate from $2,000 to $18,000, but the combined monthly spend has remained about $100,000 with less than 4% variance over the past 6 months, and most compute runs on Compute Engine in us-central1 and europe-west1; the company wants to optimize costs without reorganizing projects or changing application architecture—what should they do?

문제 분석

핵심 개념: 이 문제는 Compute Engine에 대한 Committed Use Discounts(CUDs)를 사용한 비용 최적화와 동일한 Cloud Billing 계정 하에서 여러 프로젝트에 걸쳐 해당 할인을 공유할 수 있는 능력을 평가합니다. 또한 커밋먼트를 안정 상태(베이스라인) 사용량에 맞춰 산정하고 조직/애플리케이션 변경을 피하는 개념도 간접적으로 테스트합니다. 정답이 맞는 이유: 회사는 9개의 프로젝트를 보유하고 있으며 프로젝트별 지출은 변동성이 크지만, 월별 총 지출은 매우 안정적입니다(약 $100,000, 변동 <4%). 이 패턴은 각 프로젝트의 최소 사용량을 예측하려 하기보다 전체 합산 베이스라인 사용량에 맞춘 단일 1년 커밋먼트를 구매하기에 이상적입니다. billing account 수준의 CUD 공유를 활성화하면, 해당 billing account에 연결된 프로젝트 전반에서 적격 사용량이 발생하는 곳에 커밋먼트가 적용됩니다. 이를 통해 워크로드가 월별로 프로젝트 간 이동하더라도 커밋먼트 활용도를 극대화하여, 프로젝트를 재구성하거나 애플리케이션 아키텍처를 변경하지 않고도 일관된 절감을 제공합니다. 주요 기능 / 모범 사례: - Compute Engine CUDs는 1년 또는 3년 동안 일정 수준의 리소스 사용량을 커밋하는 대가로 할인된 요금을 제공합니다. - billing account 수준 공유를 통해 동일한 billing account 하의 여러 프로젝트에서 적격 사용량이 할인을 소비할 수 있어, 커밋먼트 “커버리지”를 높이고 낭비를 줄입니다. - 모범 사례는 안정 상태 베이스라인(지속적으로 실행될 것이라고 확신하는 부분)에만 커밋하고, 버스트/변동 사용량은 on-demand 요금으로 남겨두는 것입니다. - 리전/사용량 정합성을 고려하세요: 대부분의 compute가 us-central1 및 europe-west1에 있으므로, 커밋먼트는 베이스라인 사용량이 실제로 실행되는 위치(및 관련 리소스 유형)에 맞춰 구매해야 합니다. 흔한 오해: 흔한 함정은 커밋먼트를 프로젝트별로 구매해야 한다고 가정하는 것입니다(프로젝트 사용량이 감소할 때 커밋먼트가 미사용 상태가 됨). 또 다른 오해는 더 나은 할인을 받기 위해 프로젝트를 통합해야 한다는 것입니다. billing account를 변경하면 할인이 개선된다고 생각하는 것도 오해인데, 보통은 지출이 분절되어 유연성이 감소합니다. 시험 팁: 여러 프로젝트에서 비용은 변동하지만 총 지출이 안정적이라면 “billing account 수준의 공유 할인”과 “합산 베이스라인에 맞춘 사이징”을 떠올리세요. 또한 제약 조건인 “재구성 없음, 아키텍처 변경 없음”은 마이그레이션이나 통합이 아니라 billing/할인 구성에 강하게 초점을 맞춘다는 신호입니다. 이는 Google Cloud Architecture Framework의 비용 최적화 원칙(커밋된 용량의 활용 극대화 및 낭비 감소, 운영 단순성 유지)과도 일치합니다.

문제 19

A multinational logistics company is onboarding a new workload to Google Cloud for 5 departments (Route Planning, Fleet Maintenance, Customer Support, Finance, Compliance) with 180 employees; access must be tailored per department within 72 hours, changes in membership occur quarterly, and the solution must minimize admin overhead while maintaining clear audit trails and avoiding over-privileged access. What is the quickest and most efficient way to implement department-specific access?

문제 분석

핵심 개념: 이 문제는 Google Cloud Identity and Access Management (IAM) 모범 사례를 평가합니다: predefined roles 사용, 개인이 아닌 그룹에 대한 권한 부여, 그리고 강력한 감사 가능성을 갖춘 최소 권한(least privilege) 적용입니다. 또한 운영 효율성(낮은 관리 오버헤드)과 거버넌스(명확한 감사 추적)도 다룹니다. 정답이 맞는 이유: 옵션 A는 (1) 직무 기능에 맞춰 정렬된 predefined IAM roles와 (2) 부서별 Google Groups를 결합하므로 가장 빠르고 효율적인 접근입니다. 적절한 리소스 수준(project/folder)에서 각 그룹에 역할을 한 번만 할당한 뒤, 직원이 부서에 합류/이동/퇴사할 때는 그룹의 멤버십만 관리하면 됩니다. 분기별 멤버십 변경은 180명의 IAM policy를 반복적으로 수정하는 대신 간단한 그룹 업데이트로 처리됩니다. 이는 관리 노력을 최소화하고 구성 드리프트(configuration drift)나 제거 누락 위험을 줄입니다. 주요 기능 / 모범 사례: - 그룹 기반 접근 제어: IAM roles를 Google Groups(예: route-planning@, finance@)에 바인딩합니다. 이는 확장 가능한 IAM을 위한 표준 패턴입니다. - predefined roles 우선: Google이 관리하는 predefined roles를 우선 사용하세요. 이는 Google이 유지보수하며 일반적인 직무 요구에 매핑됩니다. predefined roles로 최소 권한 요구를 충족할 수 없을 때만 custom roles를 사용합니다. - 최소 권한 및 범위: 과도한 권한을 피하기 위해 가능한 가장 낮은 수준(부서별 특정 projects 또는 folders)에서 역할을 부여합니다. - 감사 가능성: Cloud Audit Logs는 IAM policy 변경을 기록하며, 그룹 멤버십 변경은 Cloud Identity / Workspace logs를 통해 감사할 수 있어 누가 언제 접근 권한을 가졌는지에 대한 명확한 추적성을 제공합니다. 흔한 오해: 일부는 primitive roles(Owner/Editor/Viewer)를 부여하는 것이 “빠르다”고 생각하지만, 이는 광범위한 권한을 만들어 보안 위험을 높이고 컴플라이언스를 복잡하게 합니다. 또 다른 오해는 개인별 custom roles가 가장 안전하다는 것이지만, 이는 운영적으로 관리 불가능하고 오류가 발생하기 쉽습니다. service account 자격 증명 공유는 편의로 오해되기도 하지만, 이는 책임 추적성을 깨뜨리고 보안 모범 사례를 위반합니다. 시험 팁: Digital Leader 문제에서는 “빠름 + 효율적 + 최소 권한 + 낮은 관리 오버헤드”를 찾으세요. 일반적으로 정답 패턴은 다음과 같습니다: 리소스 구성(folders/projects), predefined roles를 그룹에 할당, 그리고 그룹 멤버십을 통해 사용자를 관리. custom roles는 예외적인 경우에만 사용하고, 명시적으로 정당화되지 않는 한 primitive roles와 공유 자격 증명은 피하세요.

문제 20

Your team operates a ride-sharing analytics service on Google Cloud across us-central1 and europe-west1, aiming for 99.9% monthly availability and 95th-percentile request latency under 300 ms during peak 18:00–22:00 traffic; within the SRE framework, which concept represents the metric that actually quantifies how well the service is performing?

문제 분석

핵심 개념: 이 문제는 Site Reliability Engineering (SRE)에서 신뢰성 측정 용어인 SLI, SLO, SLA를 테스트합니다. Google의 SRE 모델에서는 먼저 “좋음(good)”이 무엇인지(목표)를 정의한 다음, 실제 성능을 정량화하는 구체적인 측정값을 선택합니다. 정답이 맞는 이유: Service-level indicator (SLI)는 서비스가 얼마나 잘 동작하는지를 실제로 정량화하는 메트릭입니다. 예로는 가용성(성공한 요청의 %), 요청 지연 시간(예: 95th percentile이 300 ms 미만), 오류율, 처리량 등이 있습니다. 문제는 “서비스가 얼마나 잘 수행되는지를 실제로 정량화하는 메트릭”을 묻고 있으며, 이는 SLI의 정의와 정확히 일치합니다. 시나리오에서 월간 가용성과 피크 시간대의 p95 latency 측정값은 SLI입니다. 주요 특징 / Best Practices: 실무에서 SLI는 텔레메트리(Cloud Monitoring metrics, logs-based metrics, traces)로부터 계산되며, 다음을 만족해야 합니다: - 사용자 중심(User-centric)이어야 함(사용자가 경험하는 것을 측정: 예, 성공한 요청, end-to-end latency). - 명확히 정의되어야 함(무엇을 “성공”으로 볼지, 어떤 endpoint, 어떤 region, 18:00–22:00 같은 어떤 time window). - error budgets(SLO에서 도출됨)와 연결되어 release velocity와 reliability 간의 균형을 안내해야 함. multi-region 서비스(us-central1 및 europe-west1)의 경우, 팀은 종종 region별 및 전역(global) SLI를 정의하고, 측정이 트래픽 분포와 failover 동작을 반영하도록 보장합니다. 흔한 오해: 문제에 목표치(99.9% 및 p95 < 300 ms)가 포함되어 있어 SLI와 SLO를 혼동하는 경우가 많습니다. 이러한 목표치는 SLO이지만, 그 기반이 되는 측정 대상(가용성, latency percentile)은 SLI입니다. 또 다른 혼동은 SLA인데, SLA는 외부 계약이며 페널티를 포함할 수 있고, 내부 측정 자체가 아닙니다. 시험 팁: 다음 매핑을 암기하세요: SLI = “측정하는 것,” SLO = “측정값에 대한 목표,” SLA = “고객 대상 계약.” 질문이 메트릭/측정값을 묻는다면 SLI를 고르고, 목표/임계값을 묻는다면 SLO를 고르며, 계약상 보장을 묻는다면 SLA를 고르세요. 이는 Google Cloud Operations/SRE 관행 및 Google Cloud Architecture Framework의 reliability pillar(측정 가능한 목표와 모니터링)와 일치합니다.

합격 후기(7)

이

이**Nov 17, 2025

학습 기간: 1 month

시험 문제랑 많이 유사해서 좋았어요. 강의 다 듣고난 후에 문제 찾기 어려웠는데 앱 너무 잘 이용했네요

**************Nov 12, 2025

학습 기간: 1 month

Good questions and explanations. The resource is very similar to the real exam questions. Thanks.

S***Nov 10, 2025

학습 기간: 1 month

This is exactly what you need to pass the GCP CDL exam. The look and feel are exactly how you would experience the real exam. The questions are very similar and you'll even find a few on the exam itself. I would recommend this for anyone looking to obtain this certification. The exam is not an easy one, so the explanations to the questions are very helpful to solidify your understanding and help.

a***Nov 4, 2025

학습 기간: 2 months

I used Cloud Pass to prepare for the GCP CDL exam, and it made a huge difference. The practice questions covered a wide range of scenarios I actually saw on the test. The explanations were clear and helped me understand how LookML and data modeling work in real projects. If you focus on understanding the logic behind each question, this app is more than enough to pass.

d********Oct 31, 2025

학습 기간: 1 month

Cloud Pass was my main study tool for the GCP CDL exam, and I passed on the first try. The questions were realistic and helped me get comfortable with Looker concepts, permissions, explores, and model structures. I especially liked that I could reset my progress and re-solve the tricky questions. Strongly recommend this for anyone targeting CDL.

모의고사

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Associate

Google Professional Cloud Network Engineer

Professional

Google Associate Data Practitioner

Associate

Google Professional Cloud Security Engineer

Professional

Google Professional Cloud Architect

Professional

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Professional

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

Cloud Pass를 다운로드하여 모든 Google Cloud Digital Leader 기출 문제를 풀어보세요.

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

앱 받기

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

Cloud Pass

GCP

Google Cloud Digital Leader

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

실제 시험 기출 문제

상세 해설

실제 시험과 가장 유사

287+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

시험 도메인

Digital Transformation with Google Cloud출제율 17%

Exploring Data Transformation with Google Cloud출제율 16%

Innovating with Google Cloud Artificial Intelligence출제율 16%

Modernize Infrastructure and Applications with Google Cloud출제율 17%

Trust and Security with Google Cloud출제율 17%

Scaling with Google Cloud Operations출제율 17%

실전 문제

문제 1

문제 분석

문제 2

문제 분석

문제 3

문제 분석

문제 4

문제 분석

문제 5

문제 분석

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

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

문제 6

문제 7

문제 분석

문제 8

문제 분석

문제 9

문제 10

문제 분석

문제 11

문제 분석

문제 12

문제 분석

문제 13

문제 분석

문제 14

문제 분석

문제 15

문제 분석

문제 16

문제 분석

문제 17

문제 분석

문제 18

문제 분석

문제 19

문제 분석

문제 20

문제 분석

합격 후기(7)

이

이**Nov 17, 2025

학습 기간: 1 month

시험 문제랑 많이 유사해서 좋았어요. 강의 다 듣고난 후에 문제 찾기 어려웠는데 앱 너무 잘 이용했네요

**************Nov 12, 2025

학습 기간: 1 month

Good questions and explanations. The resource is very similar to the real exam questions. Thanks.

S***Nov 10, 2025

학습 기간: 1 month

a***Nov 4, 2025

학습 기간: 2 months

d********Oct 31, 2025

학습 기간: 1 month

모의고사

Practice Test #1

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

Practice Test #2

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

Practice Test #3

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

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Associate

Google Professional Cloud Network Engineer

Professional

Google Associate Data Practitioner

Associate

Google Professional Cloud Security Engineer

Professional

Google Professional Cloud Architect

Professional

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Professional

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

Cloud Pass를 다운로드하여 모든 Google Cloud Digital Leader 기출 문제를 풀어보세요.

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

앱 받기

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