기출 문제

문제 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 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에 매핑하세요.

문제 3

Your telemedicine startup is expanding to 40 countries and must keep all imaging files and EMR records for Brazilian residents stored within Brazil due to local health data residency rules; clinicians worldwide are allowed to view this data, and your target p95 latency for viewers is under 250 ms from any continent. You need to choose an architecture and deployment approach that meets these requirements while enabling global access. What should you do?

문제 분석

핵심 개념: 이 문제는 data residency와 global access의 차이를 테스트합니다. 규제 요구사항은 브라질 거주자의 imaging 파일과 EMR records가 반드시 Brazil에 저장된 상태로 유지되어야 한다는 것이며, 동시에 다른 국가의 clinicians도 허용 가능한 성능으로 이에 접근할 수 있어야 합니다. 가장 적절한 정답은 Brazil을 authoritative storage location으로 유지하면서 records를 국제적으로 복제하는 대신 강력한 global networking 및 access capabilities를 갖춘 provider를 사용하는 선택지입니다. 정답인 이유: Option C가 가장 적절한 선택인 이유는 compliance와 worldwide access를 모두 명시적으로 다루기 때문입니다. 주요 public cloud provider는 계약상 및 운영상 records를 Brazil region에 저장하도록 지원하면서도 전 세계 clinicians가 고성능 global network를 통해 연결할 수 있게 할 수 있습니다. 핵심은 records 자체가 Brazil에 저장된 상태로 유지된다는 점입니다. global access를 위해 규제 대상 dataset을 다른 대륙으로 복사할 필요는 없습니다. 주요 특징: - authoritative imaging 및 EMR data를 regional storage와 databases를 사용하여 Brazil region에 저장합니다. - region selection, organization policies, IAM, encryption, audit logging과 같은 provider controls를 사용하여 residency 및 healthcare governance requirements를 지원합니다. - applications 및 APIs에 대한 worldwide access를 위해 provider의 global backbone, load balancing, optimized routing을 활용합니다. - acceleration 또는 caching을 사용하는 경우, 규제 대상 records가 Brazil 내에 저장된 상태로 유지되어야 한다는 요구사항을 위반하지 않도록 매우 신중하게 제한해야 합니다. 흔한 오해: 흔한 실수 중 하나는 low-latency global access가 항상 데이터를 전 세계적으로 복제하거나 caching하는 것을 의미한다고 가정하는 것입니다. 규제 대상 health records의 경우 이는 residency rules를 위반할 수 있습니다. 또 다른 오해는 private cloud가 compliance에 자동으로 더 낫다는 것입니다. 실제로 compliance는 데이터가 어디에 저장되는지, 그리고 어떤 계약적 및 기술적 controls가 존재하는지에 달려 있습니다. 시험 팁: 문제가 국내 저장과 global users를 함께 요구할 때는 system of record를 요구된 geography에 유지하면서 대형 provider의 global access capabilities를 사용하는 답을 우선 선택하세요. 데이터를 대륙 간에 명시적으로 복제하는 선택지는 주의해야 합니다. 또한 residency는 충족하지만 성능과 global reach를 무시하는 답도 피하세요.

문제 4

An online sports streaming platform needs to process clickstream events in real time (average 15,000 events per second with bursts up to 180,000 events per second during playoffs), apply sliding-window aggregations and enrichment, and load the results into BigQuery with end-to-end latency under 5 seconds; the team does not want to manage clusters or worker VMs and requires a fully managed service that automatically scales compute with streaming throughput. Which Google Cloud product should they use?

문제 분석

핵심 개념: 이 문제는 Google Cloud의 완전 관리형 스트리밍 데이터 처리(실시간 분석용)에 대한 지식을 평가합니다. 즉, 이벤트를 ingest하고, window 기반 집계/보강(enrichment)을 수행한 뒤, 인프라를 관리하지 않고도 매우 낮은 지연 시간으로 BigQuery에 기록하는 능력입니다. 정답이 맞는 이유: Dataflow가 정답인 이유는, Dataflow가 Google Cloud의 완전 관리형 스트림 및 배치 데이터 처리 서비스(Apache Beam 기반)이기 때문입니다. Dataflow는 event-time processing, sliding/tumbling windows, stateful processing, 그리고(적절히 구성 시) exactly-once semantics를 지원합니다. Pub/Sub에서 ingest한 뒤 실시간으로 sliding-window 집계와 enrichment를 적용하고, 적절한 파이프라인 설계와 리소스 사이징을 전제로 end-to-end 지연 시간 <5초 같은 목표로 BigQuery에 결과를 쓸 수 있습니다. 결정적으로 Dataflow는 운영 관점에서 serverless입니다. 클러스터나 worker VM을 관리하지 않으며, 처리량에 따라 worker를 자동으로 확장하므로 초당 180,000 events/sec까지의 burst 요구사항과 일치합니다. 주요 기능 / Best Practices: - Apache Beam windowing(sliding windows), triggers, watermarks, late data handling을 사용하는 streaming pipelines. - bursty 트래픽을 처리하기 위한 autoscaling 및 dynamic work rebalancing. - Native connectors: Pub/Sub source 및 BigQuery sink; 더 높은 처리량과 더 낮은 지연 시간의 streaming writes를 위해(해당되는 경우) BigQuery Storage Write API 사용. - 신뢰성과 성능: 적절한 worker machine types 선택, (적합한 경우) Streaming Engine 활성화로 worker memory pressure 감소, idempotent writes 설계 또는 exactly-once 패턴 사용. - Architecture Framework 정렬: operational excellence(managed service), performance efficiency(autoscaling), reliability(managed execution, checkpointing). 흔한 오해: Pub/Sub는 ingestion 레이어이기 때문에 전체 솔루션으로 오해되는 경우가 많지만, transformations, windowed aggregations, enrichment를 수행하지는 않습니다. Dataprep은 저지연 스트리밍이 아니라 대화형/시각적 데이터 준비용입니다. Data Catalog는 처리(processing)가 아니라 metadata 관리입니다. Exam Tips: “sliding-window aggregations”, “real-time enrichment”, “load into BigQuery”, “autoscaling과 함께 클러스터/VM 관리 없음”을 보면 Dataflow를 떠올리세요. Pub/Sub(ingest) + Dataflow(process) + BigQuery(analytics) 조합은 Digital Leader 시험에서 흔한 streaming reference architecture입니다.

문제 5

A city transit authority trained a model to forecast peak ridership for 210 stations using 18 months of tap-in/out logs (5.6 million events) stored in BigQuery and refreshed daily, but to speed up feature engineering they omitted available station metadata (e.g., neighborhood type, accessibility level) and context fields (e.g., holiday indicator, major event flags), after which the model’s MAE was consistently >25% worse than baseline—what data quality dimension best explains the poor performance?

문제 분석

핵심 개념: 이 문제는 ML 결과에 영향을 주는 데이터 품질 차원, 특히 Google Cloud에서의 분석/ML 파이프라인(BigQuery가 소스, 일일 갱신)에서의 feature 완전성을 평가합니다. Google Cloud Architecture Framework에서는 모델링 전에 신뢰할 수 있는 데이터 기반을 구축하고 데이터가 목적에 적합한지 보장하는 것과 연결됩니다. 정답이 맞는 이유: 팀은 feature engineering 속도를 높이기 위해 사용 가능한 역 메타데이터(동네 유형, 접근성 수준)와 컨텍스트 필드(공휴일 지표, 주요 이벤트 플래그)를 의도적으로 제외했습니다. 즉, 학습 데이터셋에 승차 패턴에 강하게 영향을 주는 중요한 설명 변수가 누락되어 있습니다. 핵심 필드가 없으면 모델이 학습할 신호가 줄어들어 오차가 커지며(기준선 대비 MAE가 25% 이상 악화), 이는 전형적인 “completeness(완전성)” 문제입니다. 데이터셋이 현실 세계 현상을 표현하는 데 필요한 모든 속성을 포함하지 못한 것입니다. 핵심 요소 / 모범 사례: BigQuery 중심 ML 워크플로(예: BigQuery ML 또는 Vertex AI로 export)에서는 dimension table(역 메타데이터)을 join하고 파생 컨텍스트 feature(캘린더 테이블, 공휴일/이벤트 플래그)를 추가함으로써 completeness를 개선합니다. 모범 사례로는 feature store 또는 정제된 feature 테이블을 유지하고, 데이터 검증 체크(예: 필수 column 존재, non-null 비율)와 시간에 따른 feature 가용성/drift 모니터링을 수행하는 것이 있습니다. 일일 갱신은 timeliness를 지원하지만, completeness는 모델이 올바른 정보 범위를 갖도록 보장합니다. 흔한 오해: “Accuracy”는 모델이 부정확하다는 의미로 들릴 수 있지만, accuracy는 기록된 값이 현실을 반영하는지(예: 잘못된 탭 카운트)라는 데이터 품질 차원이지, 충분한 필드를 포함했는지의 문제가 아닙니다. “Validity”는 규칙/타입/범위 준수(예: timestamp 형식이 올바름)에 관한 것입니다. “Timeliness”는 최신성에 관한 것이며, 로그가 매일 갱신되므로 timeliness가 주요 이슈는 아닙니다. 시험 팁: 시나리오에서 누락된 필드, 제외된 속성, 중요한 컨텍스트 미수집이 언급되면 “completeness”를 떠올리세요. 값이 틀렸다고 하면 “accuracy”입니다. 형식/범위 위반이면 “validity”입니다. 오래되었거나 늦게 도착한 데이터면 “timeliness”입니다.

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

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

문제 6

A satellite-imaging startup needs to accelerate training for a TensorFlow segmentation model with 150 million parameters; each epoch currently takes 45 minutes on general-purpose VMs with GPUs, and the team’s goal is to reduce epoch time to under 12 minutes without changing the training code or framework. Which domain-specific hardware on Google Cloud is designed specifically to speed up machine learning training for this use case?

문제 분석

핵심 개념: 이 문제는 machine learning (ML) training을 위한 Google Cloud의 도메인 특화 accelerator에 대한 지식을 평가합니다. Google Cloud에서 TensorFlow training workload를 가속하기 위한 목적 특화 hardware는 Cloud TPU (Tensor Processing Unit)입니다. 정답이 맞는 이유: 이 startup은 epoch 시간을 크게 줄여야 하며(45분에서 12분 미만), training code나 framework를 변경할 수 없습니다. Cloud TPU는 대규모 ML training, 특히 TensorFlow를 가속하도록 특별히 설계되었으며, 높은 처리량의 matrix multiplication과 distributed training을 위한 최적화된 interconnect를 제공합니다. TPU는 TensorFlow와 통합되어 있고(표준 TensorFlow/Keras API를 통해 지원), 다른 framework로 재작성하는 것에 비해 최소한의 code 변경으로 TPU로 training을 옮길 수 있는 경우가 많습니다. 시험 관점에서 “training code나 framework를 변경하지 않고”라는 조건은 Google Cloud의 도메인 특화 ML training hardware인 TPU와 가장 잘 부합합니다. 주요 기능 / Best Practices: Cloud TPU는 다음을 제공합니다: - deep learning에서 흔한 dense linear algebra에 최적화된 specialized ML compute (systolic arrays). - 여러 TPU chip/pod에 걸쳐 training을 확장하기 위한 high-bandwidth memory 및 빠른 TPU interconnect. - 강력한 TensorFlow ecosystem 지원(TPU-enabled TensorFlow, Keras, 그리고 일반적인 training pattern). 아키텍처 관점에서 이는 Google Cloud Architecture Framework의 Performance Optimization 및 Cost Optimization pillar에 매핑됩니다: workload에 맞는 compute를 사용하고, time-to-train 목표를 충족하도록 효율적으로 scale합니다. 흔한 오해: Spot/Preemptible VM이 “더 빠르고/더 저렴하다”고 생각해 선택하기 쉽지만, 이는 주로 비용을 줄이는 것이지 per-epoch 시간을 줄이는 것이 아니며 중단될 수 있습니다. Container는 packaging과 portability에 도움이 되지만, training 가속 자체를 제공하지는 않습니다. Bare Metal Solution은 특수한 legacy 또는 licensing 요구에 사용되며 ML 특화 가속을 제공하지 않습니다. 시험 팁: Google Cloud에서 “ML training을 위한 domain-specific hardware”를 보면 “TPU”를 떠올리세요. GPU는 범용 accelerator이고, TPU는 neural network의 training/inference를 위해 목적 특화로 설계되었습니다. 또한 비용 레버(Spot VM)와 성능 레버(TPU, 상위 GPU, distributed training)를 구분하세요.

문제 7

A manufacturing company trains a Vertex AI AutoML image classification model on 250,000 product photos to detect defects and later discovers that 8% of the training labels were incorrect due to a data pipeline merge error; what is the most likely impact on the model’s predictions?

문제 분석

핵심 개념: 이 문제는 지도 머신러닝에서 데이터 품질과 라벨 정확성, 특히 Vertex AI AutoML 이미지 분류를 평가합니다. 지도 학습에서는 모델이 이미지(특징)에서 라벨(ground truth)로의 매핑을 학습합니다. ground truth가 잘못되면 모델은 잘못된 타깃을 재현하도록 학습되며, 이는 예측 성능에 직접적인 영향을 줍니다. 정답인 이유: 파이프라인 병합 오류로 인해 학습 라벨의 8%가 잘못되었다면, 학습 데이터셋에 label noise가 포함된 것입니다. label noise는 학습 과정에서 신호 대비 잡음 비율을 낮춥니다. 즉, 모델이 상충되는 지도 신호를 받게 됩니다(유사한 이미지가 서로 다른 라벨에 매핑되거나, 불량품이 정상으로 라벨링되고 그 반대가 발생). 가장 가능성이 높은 영향은 부정확성 위험 증가입니다—precision/recall 저하, false positive/false negative 증가, 신규 제품 사진에 대한 generalization 악화가 나타납니다. 250,000장의 이미지에서 8%는 약 20,000개의 오라벨 예시로, 규모가 상당하며 특히 edge case와 소수 defect class에서 모델 품질을 유의미하게 저하시킬 수 있습니다. 주요 기능 / Best Practices: Vertex AI AutoML은 학습과 평가를 지원할 수 있지만, 잘못된 ground truth를 “수정”할 수는 없습니다. Best practices에는 라벨 검증(사람 검토, 합의 기반 라벨링), 파이프라인 내 데이터 검증 체크 사용, 예상치 못한 하락을 탐지하기 위한 training/validation metric 모니터링, 그리고 체계적인 라벨 문제를 식별하기 위한 confusion matrix 활용이 포함됩니다. Google Cloud Architecture Framework 관점에서는 Operational Excellence와 Reliability에 부합합니다: 견고한 데이터 파이프라인을 구축하고, quality gate를 구현하며, 모델 성능과 data drift를 지속적으로 모니터링합니다. 흔한 오해: “나쁜 데이터”를 privacy leak과 연결짓기 쉽지만, 잘못된 라벨은 주로 보안 문제가 아니라 품질 문제입니다. 또 다른 오해는 AutoML이 라벨 오류를 자동으로 극복한다는 것입니다. 대규모 데이터셋은 소량의 noise에는 어느 정도 견고할 수 있지만, 8%는 여전히 정확도를 의미 있게 해칠 수 있습니다. 또한 학습 시간이 감소할 것으로 기대하기도 어렵습니다. 오히려 noisy label은 최적화를 더 어렵게 만들 수 있지만, 일반적으로 학습 시간을 줄이지는 않습니다. 시험 팁: ML 문제에서는 이슈를 ML lifecycle 단계에 매핑하세요: 라벨링 오류는 모델 품질/정확도에 영향을 줍니다. privacy leak은 민감 데이터 노출 또는 membership inference 위험과 관련이 있으며, 오라벨 클래스와는 다릅니다. compatibility는 배포/런타임 제약과 관련이지, 학습 라벨과는 관련이 없습니다. “incorrect labels”를 보면 기본적으로 선택해야 할 영향은 정확도/성능 저하입니다.

문제 8

A fintech company migrating to Google Cloud configures IAM so that billing clerks receive only the BigQuery Data Viewer role on 3 specific datasets and no write permissions to any other 12 datasets or projects, enforced via IAM Conditions tied to a finance Google Group and restricted to office hours (09:00–18:00); which security principle best describes granting just the minimum permissions required for their duties?

문제 분석

핵심 개념: 이 문제는 Google Cloud IAM을 통해 적용되는 최소 권한(least privilege) 보안 원칙을 평가합니다. 또한 IAM Conditions(속성 기반 접근 제어)와 BigQuery의 리소스 수준 권한(데이터셋 수준 역할)도 함께 다룹니다. 정답이 맞는 이유: 시나리오는 청구 담당자(billing clerks)에게 필요한 최소 권한만 부여하는 것을 명시적으로 설명합니다. 즉, 특정 3개의 데이터셋에만 BigQuery Data Viewer를 부여하고, 다른 곳에는 쓰기 권한을 주지 않으며, finance Google Group에 연결된 IAM Conditions를 사용해 접근이 유효한 시간(근무 시간)까지 추가로 제한합니다. 이는 최소 권한의 전형적인 예시로, 사용자가 업무 수행에 필요한 권한만 받도록 하고(권한), 가능한 한 좁게 범위를 제한하며(리소스), 시간까지 제한하는(시간) 방식입니다. 주요 기능 / 모범 사례: - IAM roles: BigQuery Data Viewer는 BigQuery 데이터에 대한 읽기 전용 접근을 위해 설계된 사전 정의 역할(predefined role)입니다. - Resource scoping: 프로젝트 전체가 아니라 데이터셋 수준에서 권한을 적용하면 blast radius를 줄이고, 접근 최소화 및 범위 제한이라는 Google Cloud Architecture Framework의 보안 원칙과 일치합니다. - Group-based access: 역할을 Google Group에 바인딩하면 라이프사이클 관리(그룹 가입/탈퇴)가 단순해지고 관리 오버헤드가 줄어듭니다. - IAM Conditions: 컨텍스트 제약(예: 시간 기반 접근)을 추가해 위험을 더 줄입니다. Conditions는 접근을 최소화할 뿐 아니라 조건부로 만들기 때문에 최소 권한을 보완합니다. 흔한 오해: - Zero-trust는 지속적인 검증과 컨텍스트 인지 접근을 강조하기 때문에 비슷하게 들릴 수 있지만, 문제는 특히 “업무에 필요한 최소 권한만 부여”를 묻고 있으므로 최소 권한이 정답입니다. - “Security by default”는 안전한 기본 구성과 안전한 기본값을 의미하며, 직무에 맞춰 권한을 조정하는 것과는 다릅니다. - “Cyber resilience”는 사고에 대비하고, 대응하고, 복구하는 것에 관한 개념이지, 권한 최소화 자체를 의미하지 않습니다. 시험 팁: “필요한 권한만”, “필요 이상은 없음”, “특정 리소스로 범위 제한”, “접근 제한” 같은 표현이 보이면 최소 권한을 떠올리세요. 모든 요청을 검증하거나, 디바이스 상태(device posture), 지속적 인증을 강조하면 zero-trust를 떠올리세요. 백업, DR, 사고 대응, 복구 목표를 강조하면 resilience입니다. 기본적으로 안전한 설정과 가드레일을 강조하면 security by default입니다.

문제 9

A municipal transit agency operates a 20-year-old on-prem scheduling system and has a budget cap of $10,000 for integration this fiscal year, with no ability to replace the core system for the next 12 months. A private operator partner runs a modern optimization platform in their own cloud environment and needs secure, programmatic access to route and ridership data (~1.2 million records/day) without the agency migrating or rehosting the legacy app. What solution should the agency choose to make their data accessible to the partner platform?

문제 분석

핵심 개념 - 이 문제는 통합과 상호운용성을 테스트합니다: 레거시 온프레미스 시스템의 데이터를 핵심 애플리케이션을 마이그레이션하거나 현대화하지 않고도 외부 파트너에게 안전하고 프로그래밍 방식으로 노출하는 것입니다. Google Cloud 관점에서 이는 컴퓨팅 또는 컨테이너 현대화 선택이 아니라 API 주도 통합 패턴(보통 API gateway/management 계층으로 구현됨)입니다. 정답이 맞는 이유 - application programming interface (API)는 20년 된 스케줄링 시스템을 그대로 유지하면서 노선 및 승차 데이터에 대한 통제된 프로그래밍 접근을 제공하는 가장 직접적이고, 변경 영향이 가장 적은 방법입니다. 파트너는 지속적인 접근(~1.2M records/day)이 필요하며, 이는 그들의 cloud environment에서 호출할 수 있는 REST/JSON(또는 유사한) 인터페이스에 적합합니다. API는 레거시 데이터 소스(또는 복제/내보낸 dataset) 앞단에 배치될 수 있고, authentication, authorization, throttling, auditing을 강제할 수 있습니다—이는 제3자와 municipal data를 공유할 때의 핵심 요구사항입니다. 또한 rehosting, refactoring, platform migration을 피하므로 $10,000 통합 상한과도 부합합니다. 핵심 기능 - 실제로 기관들은 흔히 API gateway와 identity controls(예: OAuth 2.0/JWT, service accounts, mTLS), 그리고 레거시 시스템을 보호하기 위한 rate limiting/quotas를 사용해 이를 구현합니다. API management는 versioning, monitoring, developer onboarding을 제공할 수 있습니다. 레거시 시스템이 직접 query load를 감당할 수 없다면, API는 core system을 건드리지 않은 채 exported/replicated store(배치 또는 incremental)에서 제공할 수 있습니다. 이 접근은 Google Cloud Architecture Framework의 security(least privilege, strong auth), reliability(레거시 backend 보호), cost optimization(최소 변경, 사용한 만큼 지불) 원칙을 지원합니다. 흔한 오해 - Compute Engine, GKE, Anthos는 사람들이 “Google Cloud에 뭔가 올리자”라고 생각할 때 자주 선택되지만, 요구사항에는 12개월 동안 레거시 앱을 rehosting/migrating하지 말라고 명시되어 있습니다. 이런 옵션들은 인프라/앱 플랫폼 솔루션이지, 통합 인터페이스 자체가 아닙니다. 시험 팁 - 문제가 “secure, programmatic access”, “partner integration”, “no migration”을 강조하면 compute나 Kubernetes가 아니라 “API”(그리고 필요 시 API management)를 떠올리세요. 또한 예산과 일정 제약을 확인하세요: 기존 시스템을 감싸는 통합 패턴이 보통 현대화 플랫폼보다 유리합니다.

문제 10

A logistics startup is migrating 120 microservices and 300 VMs to Google Cloud; during the first 30 days they need out-of-the-box observability—without custom agents or dashboards—to understand system health and performance across services; in this context, what does out-of-the-box observability refer to?

문제 분석

핵심 개념: 이 문제는 Google Cloud에서의 “out-of-the-box observability”를 테스트하며, 이는 주로 Google Cloud Operations Suite(이전 명칭 Stackdriver)를 통해 제공됩니다: Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, 그리고 Error Reporting. Observability는 인프라와 애플리케이션 전반에서 telemetry(metrics, logs, traces)를 통해 시스템 상태와 성능을 이해할 수 있는 능력을 의미합니다. 정답인 이유: 이 시나리오는 많은 microservices와 VMs의 마이그레이션 첫 30일을 강조하며, “custom agents or dashboards 없이” observability를 요구합니다. Out-of-the-box observability는 최소한의 설정으로 즉시 동작하는 기본 제공 monitoring 및 logging 기능을 사용하는 것을 의미합니다. Google Cloud에서는 많은 서비스가 자동으로 platform metrics와 logs를 생성하며, Cloud Operations는 기본 dashboards, alerting policies, 그리고 service views를 제공합니다(예: GKE와 많은 managed services는 기본적으로 통합됨). 이는 기본 도구를 사용해 상태, 성능, 로그를 모니터링하는 option B와 직접적으로 일치합니다. 주요 기능: - 기본 metrics와 logs: Google Cloud 서비스는 system 및 service metrics와 audit logs를 자동으로 생성합니다. - Cloud Monitoring: 사전 구축된 dashboards, uptime checks, alerting, 그리고 SLO 스타일 monitoring 패턴. - Cloud Logging: 중앙화된 log 저장소, Log Explorer, 그리고 많은 서비스에 대한 기본 log 수집. - 서비스 중심 troubleshooting: traces/profiles/errors를 활성화하여 지연 시간과 장애를 진단할 수 있습니다. 일부 환경에서는 추가 instrumentation이 필요할 수 있지만, 문제는 명시적으로 이 용어가 무엇을 의미하는지 묻고 있습니다. - 모범 사례와의 정렬: Google Cloud Architecture Framework는 운영 우수성(operational excellence), 즉 monitoring, alerting, 그리고 reliability practices를 라이프사이클 초기에, 특히 마이그레이션 중에 적용하는 것을 강조합니다. 일반적인 오해: 사람들은 종종 observability를 프로젝트 관리(agile burndown), 고객 감정(customer sentiment, NPS/reviews), 또는 재무 거버넌스(cost forecasting)와 혼동합니다. 이것들은 중요한 비즈니스 기능이지만 observability는 아닙니다. 또 다른 오해는 observability가 항상 custom dashboards와 agents를 필요로 한다는 것입니다. 더 깊은 애플리케이션 수준의 telemetry에는 instrumentation이 필요할 수 있지만, “out-of-the-box”는 구체적으로 즉시 사용 가능한 기본 기능을 의미합니다. 시험 팁: Digital Leader 시험에서는 키워드를 연결해서 보세요: “observability,” “system health,” “performance,” “logs,” 그리고 “across services”는 Cloud Operations Suite를 강하게 시사합니다. “Out-of-the-box”는 custom-built dashboards나 bespoke agents가 아니라 최소한의 구성과 사전 구축된 views를 의미합니다. 또한 observability를 FinOps(cost), DevOps planning(sprints), 그리고 customer analytics(NPS)와 구분하세요.

Practice Test #3

3중 AI 검증 답안 및 해설

기출 문제

합격 후기(7)

다른 모의고사

Practice Test #1

Practice Test #2

지금 학습 시작하기