Cloud Pass
합격에 필요한 학습 흐름을 하나로합격 후기FAQ
Google Professional Data Engineer
Google Professional Data Engineer

Practice Test #1

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

50문제120분700/1000합격 점수
실전형 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

GPT Pro, Claude Opus, Gemini Pro가 답안과 해설을 교차 검증합니다. 선택지별 근거부터 요구사항 분해와 정답 아키텍처까지 확인하세요.

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

실전형 문제

1
문제 1

Your marketing analytics team needs to run a weekly PySpark batch job on Google Cloud Dataproc to score customer churn propensity using input data in Cloud Storage and write results to BigQuery; testing shows the workload completes in about 35 minutes on a 16-worker n1-standard-4 cluster when triggered every Friday at 02:00 UTC; you are asked to cut infrastructure costs without rewriting the job or changing the schedule—how should you configure the cluster for cost optimization?

Dataflow로 마이그레이션은 일부 파이프라인에서 비용 효율적일 수 있지만, 일반적으로 작업 재작성(또는 변경)이 필요합니다(Dataproc의 PySpark는 변경 없이 Dataflow로 직접 이식할 수 없음). 문제는 재작성이나 스케줄 변경을 명시적으로 금지합니다. 또한 Dataflow는 다른 실행 모델(Beam)과 운영 방식이므로, “클러스터 구성” 관점의 비용 최적화에 대한 최선의 답이 아닙니다.

Dataproc worker 노드에서 Preemptible(Spot) VM은 컴퓨팅 비용을 크게 줄이며 내결함성 배치 처리를 위해 설계되었습니다. master는 일반 VM으로 유지하고 대부분의 worker를 preemptible로 만들어 절감을 극대화하세요. worker가 회수되면 Spark는 작업을 재스케줄링할 수 있으며, 주 1회 35분 배치 작업은 코드나 타이밍을 변경하지 않고도 할인된 중단 가능 용량에 매우 잘 맞습니다.

더 높은 메모리 머신 타입은 실행 시간을 줄일 수 있지만, 시간당 VM 비용을 증가시키며 이미 35분 내에 완료되는 작업의 총비용을 낮춘다는 보장이 없습니다. 이 선택지는 비용이 아니라 성능을 최적화합니다. 작업이 메모리 병목이라는 근거와 더 적은 노드로 운영할 수 있다는 근거가 없다면, 더 큰 머신으로 전환하는 것은 위험하고 종종 더 비싼 변경입니다.

local SSD는 shuffle이 많은 Spark 워크로드에서 I/O 성능을 개선할 수 있지만, 비용이 추가되며 Cloud Storage에서 읽고 BigQuery로 쓰는 짧은 주간 배치에서는 필요하지 않습니다. Dataproc 작업은 프리미엄 스토리지를 추가하는 것보다 컴퓨팅 가격 최적화에서 더 큰 이점을 얻는 경우가 많습니다. 이는 성능 튜닝 옵션이지, 가장 직접적인 비용 절감 레버가 아닙니다.

문제 분석

핵심 개념 - 이 문제는 예약된 비대화형 Dataproc 배치 워크로드에 대한 비용 최적화를 테스트합니다. 핵심 레버는 Dataproc 클러스터 라이프사이클(일시적(ephemeral) vs 장기 실행(long-running)), VM 가격 모델(standard vs Spot/Preemptible), 그리고 컴퓨팅 지출을 줄이면서 동일한 작업 코드와 스케줄을 유지하는 것입니다. 정답이 맞는 이유 - Dataproc worker 노드에 preemptible(Spot) VM을 사용하는 것은 내결함성이 있는 배치 처리에서 컴퓨팅 비용을 줄이는 전형적인 방법입니다. 약 35분 실행되는 주간 작업은 클러스터가 작업 시간 창에만 존재하고 재시도를 허용할 수 있으므로 매우 적합합니다. Dataproc/Spark는 executor 손실을 처리할 수 있으며, preemptible worker가 회수되면 Spark는 남아 있는 executor에서 작업을 다시 스케줄링할 수 있습니다. 비용 절감 효과는 on-demand VM 대비 상당할 수 있고, PySpark 작업을 다시 작성하거나 금요일 02:00 UTC 스케줄을 변경할 필요가 없습니다. 핵심 기능 / 모범 사례 - standard(비-preemptible) master 노드와 대부분 또는 전체 worker 노드를 preemptible로 구성한 Dataproc 클러스터를 설정합니다. 선택적으로 과도한 churn 위험을 줄이기 위해 소수의 비-preemptible worker를 유지하고, 허용된다면 autoscaling policies를 활성화할 수 있습니다(여기서는 필수는 아님). 유휴 시간에 대한 비용 지불을 피하기 위해 ephemeral clusters(create cluster, submit job, delete cluster)를 사용하세요. 이는 최대 절감을 위해 preemptible workers와 함께 자주 사용됩니다. Architecture Framework 관점에서 이는 비용 최적화(할인 리소스 사용)와 Spark의 분산 재시도 동작을 통한 신뢰성 유지에 부합합니다. 흔한 오해 - Dataflow로 마이그레이션하면 운영 오버헤드는 줄일 수 있지만, Dataproc의 PySpark는 Dataflow로 재구현 없이 lift-and-shift가 불가능하므로 “재작성 금지” 제약을 위반합니다. 더 높은 메모리 머신 타입을 선택하거나 local SSD를 추가하면 성능은 개선될 수 있지만, 일반적으로 시간당 비용이 증가하며 35분 작업의 총비용을 줄인다는 보장이 없습니다. 이는 지출이 아니라 속도를 최적화하는 선택입니다. 시험 팁 - Dataproc 배치 작업에서는 먼저 다음을 확인하세요: (1) ephemeral clusters, (2) preemptible/Spot workers, (3) right-sizing. preemptibles는 워크로드가 재시작 가능하고 시간 제한이 있을 때 가장 적합합니다. master는 항상 standard VM으로 유지하세요. preemptibles는 언제든 회수될 수 있으므로 워크로드가 중단을 허용해야 합니다. Spark는 일반적으로 이를 처리할 수 있지만, 매우 타이트한 SLA 또는 비-idempotent 부작용이 있는 경우 주의가 필요할 수 있습니다.

2
문제 2

Your company runs a private Google Kubernetes Engine (GKE) cluster in a custom VPC in us-central1 using a subnetwork named analytics-subnet; due to the organization policy constraints/compute.vmExternalIpAccess, all nodes have only internal IPs with no external IPs. A nightly Kubernetes Job must download 500 MB CSV files from Cloud Storage and load transformed results into BigQuery using the BigQuery Storage Write API, but pods fail with DNS resolution/connection errors when contacting storage.googleapis.com and bigquery.googleapis.com. What should you do to allow access to Google APIs while keeping the nodes on internal IPs only?

Network tag와 firewall rule은 트래픽을 허용하거나 차단할 수는 있지만, node에 external IP가 없고 NAT/PGA도 없을 때 Google APIs에 도달하기 위한 경로를 제공하지는 않습니다. 또한 tag는 Google API 접근을 선택적으로 활성화하는 메커니즘도 아닙니다. 이 선택지는 authorization(firewall)과 connectivity(routing/egress)를 혼동하고 있습니다.

“Cloud Storage 및 BigQuery IP range”로의 egress firewall rule을 만드는 것은 올바른 해결책이 아닙니다. Google APIs는 일반적으로 anycast VIP를 사용하고 IP가 변경될 수 있어 IP allowlist 유지가 취약합니다. 더 중요한 점은, egress rule을 관대하게 설정하더라도 internal-only node는 해당 endpoint에 도달하기 위한 유효한 egress 메커니즘(Private Google Access 또는 Cloud NAT)이 여전히 필요하다는 것입니다.

VPC Service Controls perimeter는 perimeter 외부에서 지원되는 Google service에 대한 접근을 제한하여 데이터 유출 위험을 줄이는 데 도움이 됩니다. 하지만 private node에서 Google APIs로의 기본적인 network reachability 문제를 해결하지는 못합니다. Private Google Access(또는 NAT/PSC) 없이는 여전히 연결 실패가 발생할 수 있습니다. 이는 egress connectivity 기능이 아니라 보안 경계 기능입니다.

analytics-subnet에서 Private Google Access를 활성화하는 것은 internal-only GKE node(및 pod)가 external IP 없이 Cloud Storage 및 BigQuery 같은 Google APIs에 접근하도록 하는 올바른 방법입니다. cluster를 private로 유지하면서 Google API front end로 가는 Google-internal route를 제공합니다. 이는 org policy 제약을 만족하면서 연결 오류를 직접적으로 해결합니다.

문제 분석

핵심 개념: 이 문제는 private GKE 네트워킹과 external IP가 없는 VM/pod의 워크로드가 Google APIs(Cloud Storage 및 BigQuery)에 어떻게 접근하는지를 테스트합니다. 핵심 기능은 subnet에서의 Private Google Access(PGA)로, internal IP 주소만 가진 리소스가 Google의 네트워크를 통해 Google APIs 및 서비스에 접근할 수 있게 해줍니다. 정답이 맞는 이유: private GKE cluster에서 node가 internal IP만 가지고(그리고 org policy가 external IP를 차단하는 경우), pod의 egress는 일반적으로 node의 네트워크를 통해 나갑니다. Cloud NAT 또는 Private Google Access가 없으면 public Google API endpoint(예: storage.googleapis.com, bigquery.googleapis.com)로의 호출은 public internet으로 나갈 유효한 egress 경로가 없어 실패할 수 있습니다. node가 사용하는 특정 subnet(analytics-subnet)에서 Private Google Access를 활성화하면, internal-only node(따라서 pod)가 external IP를 할당하지 않고도 Google의 front end로 internal routing을 사용해 Google APIs에 도달할 수 있습니다. 주요 기능 / 구성: - analytics-subnet에서 Private Google Access 활성화(subnet-level 설정). - DNS resolution이 동작하는지 확인(Cloud DNS 기본 설정이면 충분); 핵심은 DNS 자체가 아니라 routing/egress입니다. - 표준 Google API hostname을 사용; PGA는 application code 변경 없이 접근을 처리합니다. - 이는 필요한 연결성을 유지하면서 public 노출을 최소화하는 Google Cloud Architecture Framework 보안 원칙과 일치합니다. 흔한 오해: - Firewall rule(태그 포함)은 internet 또는 Google API 도달성을 만들어주지 않습니다. 이미 route가 있는 트래픽에 대해 permit/deny만 합니다. - Google APIs에 대해 “IP range 허용”은 실용적이지 않습니다. 많은 Google API는 anycast front end로 제공되고 IP가 변경될 수 있으며, route(NAT/PGA) 없이는 egress를 허용해도 도움이 되지 않습니다. - VPC Service Controls는 데이터 유출(data exfiltration) 통제와 service perimeter를 위한 것이지, private node에서의 network egress를 제공하는 기능이 아닙니다. 시험 팁: external IP가 없는 private GKE/VM의 경우: - Google APIs에 도달하려면: Private Google Access를 활성화(또는 더 고급 설계에서는 Google APIs용 Private Service Connect 사용). - public internet/비-Google endpoint에 도달하려면: Cloud NAT 사용. 문제에서 “node를 internal IP only로 유지”라고 명시하고 목적지가 Google APIs라면, Private Google Access가 정석 답안입니다.

3
문제 3

Your mobility startup needs to build a predictive maintenance model with BigQuery ML and deploy a near–real-time prediction endpoint on Vertex AI; you will ingest continuous telemetry from 12 scooter OEMs averaging 80,000 messages per minute with an end-to-end latency target under 3 seconds, and incoming payloads may include malformed JSON, missing fields, and outliers (for example, speed > 120 km/h); what should you do to reliably ingest, validate, and deliver this data for training and inference?

원시 OEM 데이터를 BigQuery로 직접 스트리밍하고 ingestion table에서 BigQuery ML을 학습하는 것은 견고한 검증과 정제 필요성을 무시합니다. 잘못된 JSON과 누락 필드는 ingestion 실패나 일관되지 않은 스키마를 유발할 수 있고, 이상치는 학습을 오염시킬 수 있습니다. BigQuery는 분석에 뛰어나지만, 수집 시점의 스트리밍 데이터 품질 제어와 dead-letter 처리를 구현하기에 적절한 장소는 아닙니다.

모델과 동일한 dataset에 모든 스트리밍 데이터를 기록하고 이를 쿼리하여 준 실시간으로 사용하는 것은 수집, 학습, 서빙 관심사를 혼합합니다. 여전히 확장 가능한 검증/정제 계층이 없고, 잘못된 레코드나 이상치 라우팅을 해결하지 못합니다. 또한 BigQuery 쿼리를 준 실시간 서빙 메커니즘으로 사용하는 것은 Vertex AI 온라인 예측 endpoint를 대체할 수 없으며, 엄격한 종단 간 3초 미만 SLA에서는 어려움을 겪을 수 있습니다.

Pub/Sub + Cloud Functions는 가벼운 변환에는 동작할 수 있지만, 지속 처리량(~초당 1,333개)과 엄격한 지연 시간, 그리고 복잡한 검증/정제 요구사항에는 운영 측면에서 적합하지 않습니다. Functions는 동시성 튜닝, cold start, 재시도/중복 복잡성을 유발하며, 견고한 dead-letter 라우팅과 상태 기반(stateful) 처리를 구축하기가 더 어렵습니다. Dataflow는 바로 이런 종류의 연속적 고용량 스트림 처리를 위해 설계되었습니다.

Pub/Sub 수집과 Dataflow 스트리밍 파이프라인 조합은 대규모에서 신뢰성 있고 저지연의 텔레메트리 처리를 위한 권장 아키텍처입니다. Dataflow는 JSON을 파싱하고, 스키마를 강제하며, 누락 필드를 처리하고, 이상치를 필터/플래그 처리하며, 정상 이벤트 처리를 계속하면서 불량 레코드를 dead-letter topic/table로 라우팅할 수 있습니다. 정제된 데이터는 BigQuery ML 학습을 위해 BigQuery로 스트리밍될 수 있고, 동시에 Vertex AI 준 실시간 예측을 지원하는 서빙 경로로 전달될 수도 있습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 견고한 스트리밍 수집 및 처리 아키텍처를 설계하는 것을 평가합니다: 내구성 있는 이벤트 수집을 위한 Pub/Sub, 검증/정제와 함께 확장 가능한 스트림 처리를 위한 Dataflow (Apache Beam), 그리고 BigQuery ML 및 다운스트림 Vertex AI 온라인 예측에 데이터를 제공하는 분석 저장소로서의 BigQuery. 정답인 이유: 12개 OEM에서 분당 80,000개 메시지(~초당 1,333개)와 종단 간 지연 시간 목표 3초 미만을 만족하려면, 신뢰성을 유지하면서도 잘못된 JSON, 누락 필드, 이상치를 처리할 수 있는 수평 확장 가능한 저지연 스트리밍 파이프라인이 필요합니다. Pub/Sub는 백프레셔 처리, at-least-once 전달, 그리고 다운스트림 지연 시 버퍼링을 제공합니다. Dataflow 스트리밍은 이 규모에서의 연속 처리를 위해 목적에 맞게 설계되어 파싱, 스키마 강제, 보강(enrichment), 윈도잉(windowing), 그리고 정상 데이터 처리를 막지 않으면서 유효하지 않은 레코드를 데드 레터 경로로 라우팅하는 기능을 제공합니다. 정제되고 검증된 이벤트는 학습 데이터셋과 피처 생성에 사용되도록 BigQuery로 스트리밍할 수 있으며, 동일한 파이프라인이 정제된 피처를 서빙 경로(예: 다른 Pub/Sub topic 또는 온라인 스토어)로 게시하여 Vertex AI endpoint에서 준 실시간 예측에 사용할 수도 있습니다. 핵심 기능 / 모범 사례: - 격리, quota 관리, 그리고 문제 해결을 쉽게 하기 위해 Pub/Sub topic( OEM별 1개 또는 attributes를 사용하는 공유 topic). - 스키마 검증, 불량 레코드용 side output, 그리고 dead-letter topic/table을 갖춘 Dataflow 스트리밍. - 모델 학습을 안정화하기 위한 이상치 처리(필터링, 상한/하한 적용, 또는 플래그 지정) 및 누락 필드 기본값 처리. - end-to-end로 exactly-once semantics는 보장되지 않으므로, 멱등성(idempotent) 쓰기(예: BigQuery insertId/dedup key)로 설계하고 재생 가능한 소스를 사용. - Google Cloud Architecture Framework에 부합: reliability(DLQ, 재시도), operational excellence(모니터링/알림), performance efficiency(autoscaling), security(IAM, 필요 시 CMEK). 흔한 오해: BigQuery streaming insert만으로는 견고한 검증, dead-letter 라우팅, 또는 복잡한 변환을 제공하지 않습니다. 원시의 잘못된 payload를 BigQuery로 직접 푸시하면 다운스트림 학습이 복잡해지고 파이프라인이 깨질 수 있습니다. Cloud Functions도 메시지를 파싱할 수는 있지만, 이 정도의 지속 처리량과 엄격한 지연 시간에서는 Dataflow에 비해 동시성, 재시도, 순서 보장, 운영 안정성을 관리하기가 더 어렵습니다. 시험 팁: 고처리량, 저지연 스트리밍에서 데이터 품질 요구사항이 있다면 정석 패턴은 Pub/Sub -> Dataflow (validate/transform + DLQ) -> BigQuery (analytics/training) 및 병렬 서빙 경로입니다. 지속적인 규모, 복잡한 처리, 강력한 운영 제어가 필요할 때는 임시적인 serverless functions보다 관리형 스트리밍 엔진(Dataflow)을 선호하세요.

4
문제 4

A media intelligence firm receives irregularly timed 2–5 GB CSV files from 50 partners into a dedicated Cloud Storage bucket via Storage Transfer Service, after which a Dataproc PySpark job must standardize the files and write them to BigQuery, followed by table-specific BigQuery SQL transformations that vary by table and can run for up to 3 hours across roughly 600 destination tables, and you must design the most efficient and maintainable workflow to process all tables promptly and deliver the freshest results to analysts—what should you do?

단일 공유 DAG로 시간 단위 스케줄링을 하는 것은 테이블별 DAG보다 유지보수성이 높지만, 파일이 불규칙하게 도착하므로 최대 1시간까지 대기할 수 있어 신선도 요구사항을 충족하지 못합니다. SQL 단계가 3시간 실행될 수 있는 상황에서는 시간 단위 트리거가 누적되어 엔드투엔드 지연이 증가할 수 있습니다. 또한 도착 즉시 처리에 일반적으로 선호되는 이벤트 기반 트리거를 명시적으로 다루지 않습니다.

약 600개 테이블 각각에 대해 별도의 DAG를 만드는 것은 Composer에서 전형적인 안티패턴입니다. 운영 오버헤드(코드 중복, 배포, 모니터링 노이즈)를 증가시키고 Airflow scheduler에 부담을 줄 수 있습니다. 시간 단위 스케줄링 역시 처리를 지연시키며 변환이 수 시간 걸릴 때 백로그를 유발할 수 있습니다. 테이블별 격리는 깔끔해 보이지만 이 규모에서는 효율적이지도 유지보수 가능하지도 않습니다.

이것이 최선의 설계입니다. 단일 파라미터화 DAG는 파라미터/구성을 통해 테이블별 SQL 로직을 지원하면서도 워크플로를 유지보수 가능하게 유지합니다. Cloud Storage object notifications에서 Cloud Function을 거쳐 DAG를 트리거하면 각 파일이 도착한 직후 준실시간 처리가 가능해 신선도를 극대화합니다. 이후 Airflow가 Dataproc과 BigQuery 작업 전반의 의존성과 제어된 병렬성을 관리할 수 있습니다.

이벤트 기반 트리거는 신선도 측면에서 좋지만, 테이블당 별도의 DAG를 만드는 것은 약 600개 테이블에서 유지보수 가능하지 않으며 Composer의 scheduler와 운영 프로세스에 과부하를 줄 수 있습니다. 또한 수백 개 DAG 전반에 걸쳐 일관된 변경(예: Dataproc job args 또는 retry policies 업데이트)을 적용하기 어렵게 만듭니다. 단일 파라미터화 DAG는 훨씬 적은 오버헤드로 동일한 동작을 달성합니다.

문제 분석

핵심 개념: 이 문제는 Cloud Storage 도착 이벤트에 의해 트리거되며 Dataproc과 BigQuery를 조정하기 위해 Cloud Composer (Airflow)를 사용하는 이벤트 기반 오케스트레이션과 유지보수 가능한 워크플로 설계를 평가합니다. 신선도(파일 도착 후 즉시 처리), 확장성(600개 테이블, 최대 3시간까지 실행되는 장시간 SQL), 유지보수성(DAG 난립 방지)을 강조합니다. 정답인 이유: 옵션 C는 이벤트 기반 트리거(Cloud Storage object notification -> Cloud Function -> DAG 트리거)를 제공하므로 파트너 파일이 도착하는 즉시 처리가 시작되며, 시간 단위 스케줄을 기다리지 않습니다. 이는 가장 최신 결과를 제공해야 한다는 요구사항을 가장 잘 충족합니다. 또한 600개의 개별 DAG를 만드는 대신 단일 공유 파라미터화 DAG를 사용하므로 유지보수성이 훨씬 높습니다. 파라미터화(예: table name, SQL path, destination dataset, partition date)를 통해 동일한 DAG를 테이블별 또는 파일/테이블 매핑별로 실행할 수 있으며, Airflow task mapping/dynamic task generation 및 적절한 concurrency 설정으로 병렬성도 확보할 수 있습니다. 주요 기능 / 모범 사례: - Pub/Sub를 통한 Cloud Storage notifications(일반적으로 내부적으로 사용됨)는 준실시간 트리거를 가능하게 합니다. - Cloud Function은 Composer/Airflow REST API를 호출(또는 Pub/Sub 기반 DAG를 트리거)하여 런타임 파라미터를 전달하는 경량 접착(glue) 역할을 합니다. - Airflow operators: PySpark 표준화를 위한 DataprocSubmitJobOperator; 테이블별 SQL 변환을 위한 BigQueryInsertJobOperator. - BigQuery slots/quotas 및 Dataproc cluster 용량을 과도하게 사용하지 않도록 Airflow pools/queues와 max_active_runs/concurrency를 사용해 제어된 병렬성을 구성하고, 테이블별 병렬성에 제한을 두는 것을 고려합니다. - 테이블별 SQL을 버전 관리되는 파일(예: Cloud Source Repositories/GitHub)에 유지하고 파라미터로 참조하여 유지보수성을 향상합니다. 흔한 오해: 시간 단위 스케줄링(A/B)은 더 단순해 보이지만 데이터 지연을 증가시키고 변환이 최대 3시간까지 걸릴 때 백로그를 만들 수 있습니다. 테이블당 DAG 생성(B/D)은 로직을 분리하는 것처럼 보이지만 운영 측면에서 관리 불가능해지고(배포, 모니터링, 코드 중복) 스케줄러에 과부하를 줄 수 있습니다. 시험 팁: 불규칙한 도착과 신선도 요구사항에는 이벤트 기반 오케스트레이션을 선호하세요. 유사한 파이프라인이 많을 때는 수백 개의 DAG 대신 단일 파라미터화 DAG를 선택하세요. 또한 quotas와 concurrency를 고려해 설계해야 한다는 점을 기억하세요: BigQuery job 제한, slot 가용성, Composer scheduler 제한이 종종 “가장 효율적이고 유지보수 가능한” 정답을 좌우합니다.

5
문제 5

In a fintech company, Business Intelligence developers hold the Project Owner role in their respective Google Cloud projects to work across multiple services. Your compliance policy requires that all Cloud Storage Data Access audit logs be retained for 180 days, and only the internal audit team may read these logs across all current and future projects. What should you do?

프로젝트별로 Data Access logs를 활성화하고 Cloud Logging 액세스를 제한하는 것은 모든 프로젝트 전반에서 감사 팀만 로그를 읽을 수 있어야 한다는 요구사항을 안정적으로 충족하지 못합니다. BI 개발자는 Project Owners이므로 스스로 액세스를 부여하거나 설정을 변경할 수 있습니다. 또한 불변 retention policy를 통한 엄격한 180일 보존 요구사항도 해결하지 못합니다. 추가로, 현재 및 향후 프로젝트에 대해 프로젝트별로 관리하는 것은 운영 부담이 큽니다.

BI 팀의 프로젝트 내 bucket으로의 프로젝트 수준 sink는 각 프로젝트 내에서만 로그를 중앙화하며 제어권을 Project Owners에게 남겨 separation of duties를 위반합니다. 프로젝트 소유자는 sink, bucket IAM을 변경하거나 다른 보호가 없다면 데이터를 삭제/변조할 수 있습니다. 또한 반복 구성과 지속적인 거버넌스 없이는 “현재 및 향후 모든 프로젝트”로 확장되지 않습니다.

전용 감사 프로젝트로 프로젝트 수준 sinks를 통해 내보내면 separation of duties는 개선되지만, 여전히 모든 프로젝트에 sink를 생성하고 유지관리해야 하며 향후 프로젝트를 자동으로 포함하지 못합니다. BI 개발자는 Project Owners이므로 자신의 프로젝트 sink를 비활성화하거나 변경해 컴플라이언스 공백을 만들 수 있습니다. 이 옵션은 더 가깝지만 “현재 및 향후 프로젝트” 자동화 요구사항을 충족하지 못합니다.

조직 또는 폴더 수준의 aggregated sink는 새로 생성되는 프로젝트를 포함해 모든 하위 프로젝트에서 일치하는 Data Access logs를 자동으로 수집하여 “현재 및 향후 프로젝트” 요구사항을 충족합니다. 전용 audit-logs 프로젝트의 Cloud Storage bucket으로 내보내면 강력한 separation of duties가 가능합니다. 180일 bucket retention policy는 필요한 보존을 강제하며, IAM으로 읽기 액세스를 감사 팀으로만 제한할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 중앙집중식 감사 로깅 거버넌스를 테스트합니다: Cloud Storage Data Access audit logs를 활성화하고 내보내기, 보존(retention) 강제, 그리고 현재 및 향후 모든 프로젝트 전반에서 읽기 액세스 제한. 핵심 서비스/기능은 Cloud Audit Logs (Data Access logs), Cloud Logging sinks (folder/org의 aggregated sinks), Cloud Storage retention policies, 그리고 IAM separation of duties입니다. 정답인 이유: (1) 현재 및 향후 모든 프로젝트를 커버하고, (2) 로그를 180일 보존하며, (3) 내부 감사 팀만 읽을 수 있도록 보장하는 솔루션이 필요합니다. 조직 또는 폴더 수준의 aggregated sink는 모든 하위 프로젝트의 일치하는 로그를 자동으로 내보내며, 새로 생성되는 프로젝트도 포함하므로 “현재 및 향후 프로젝트” 요구사항을 충족합니다. 전용 audit-logs 프로젝트의 Cloud Storage bucket으로 내보내면 제어를 중앙화하고 프로젝트 소유자가 로그를 변조하거나 액세스할 위험을 줄입니다. bucket retention policy(180일)는 보존 기간 동안 객체의 불변성을 강제하여 컴플라이언스 보존 요구사항을 충족합니다. 핵심 기능/구성: - Cloud Storage Data Access audit logs에 대한 포함 필터를 가진 aggregated sink (org/folder) 생성(예: resource.type="gcs_bucket" 및 logName이 data_access와 매칭). - 감사 팀이 제어하는 전용 프로젝트의 대상 Cloud Storage bucket 선택. - 180일 Cloud Storage retention policy 적용(더 강한 컴플라이언스 보장을 위해 선택적으로 Bucket Lock 활성화). - IAM 제한: sink의 writer identity에 bucket에 객체를 쓸 권한 부여; 읽기 액세스(예: Storage Object Viewer)는 감사 팀에만 부여; 내보낸 데이터셋에 대해 BI 프로젝트 소유자에게 광범위한 Logging Viewer 역할을 부여하지 않기. 흔한 오해: 많은 사람들이 로그를 활성화하고 Cloud Logging 액세스를 제한하면 충분하다고 생각하지만, 프로젝트 소유자는 종종 자신의 프로젝트 내 로그에 여전히 액세스할 수 있고 Cloud Logging의 보존은 명시적인 180일 컴플라이언스 보존 요구사항과 동일하지 않습니다. 또한 프로젝트 수준 sink는 “향후 프로젝트” 요구사항을 충족하지 못하며 프로젝트 소유자가 수정할 수 있습니다. 시험 팁: 요구사항에 “현재 및 향후 모든 프로젝트 전반”이 언급되면 조직/폴더 수준 정책과 aggregated sinks를 떠올리세요. 컴플라이언스에서 고정된 보존 기간이 언급되면 기본 로그 보존에 의존하기보다 Cloud Storage retention policies(및 Bucket Lock)를 떠올리세요. separation of duties를 위해서는 감사 로그를 전용 프로젝트로 중앙화하고 IAM을 엄격히 범위 지정하세요.

합격 루틴을 앱에서 이어가세요

실전 모의고사, AI 해설, 약점 회독과 학습 분석을 모두 제공합니다.

6
문제 6
(2개 선택)

A global ride-hailing platform is migrating driver and trip ledgers from multiple transactional sources (Cloud SQL for MySQL and an on-prem PostgreSQL cluster) into BigQuery; these systems emit log-based CDC events (operation type INSERT/UPDATE/DELETE, commit_ts, and primary key) at a steady 7,500 rows/sec with spikes to 18,000 rows/sec; product managers require that changes become queryable in a BigQuery reporting table within 60 seconds, and the data team must reduce slot consumption for applying changes by at least 40% compared to per-row DML; you will stream the CDC events continuously into BigQuery; which two steps should you take so that changes reach the reporting table with minimal latency while keeping compute overhead low? (Choose two.)

오답입니다. 각 CDC 이벤트를 reporting 테이블에 즉시 per-row INSERT/UPDATE/DELETE로 적용하면, 특히 7,500–18,000 rows/sec에서 DML 오버헤드와 slot 소비가 최대화됩니다. 또한 경합을 증가시키고 처리량을 낮출 수 있습니다. 지연은 낮을 수 있지만, per-row DML 대비 compute/slot 사용량을 최소 40% 줄여야 한다는 요구사항과 충돌합니다.

정답입니다. CDC 이벤트를 append-only staging 테이블로 스트리밍하는 것은 log-based CDC에 권장되는 ingestion 패턴입니다. 쓰기를 단순하고 확장 가능하게 유지하며(streaming inserts는 append 워크로드에 최적화), 전체 변경 이력(op type, commit_ts, PK)을 보존합니다. 이 staging 레이어는 reporting 테이블을 업데이트하기 전에 효율적인 downstream batching/deduplication을 가능하게 합니다.

오답입니다. reporting 테이블에서 오래된 레코드를 주기적으로 삭제하는 것은 CDC semantics(특히 primary key 기반 updates와 deletes)를 올바르게 구현하지 못하며, 60초 내에 inserts/updates/deletes를 적용해야 한다는 요구사항도 해결하지 못합니다. 또한 신중하게 partitioning하지 않으면 비용이 큰 테이블 스캔 위험이 있으며, CDC 이벤트에 의해 구동되는 proper upsert/delete 로직을 대체할 수 없습니다.

정답입니다. 주기적인 DML MERGE는 많은 CDC 변경을 단일 집합 기반 연산으로 배치 처리하여, per-row DML 대비 slot 소비를 크게 줄이는 경우가 일반적입니다. MERGE는 하나의 statement에서 INSERT/UPDATE/DELETE를 적용할 수 있으며, freshness 요구사항을 충족하도록 30–60초마다 스케줄링할 수 있습니다. key별 최신 이벤트 deduplication과 결합하면 지연과 compute 오버헤드를 모두 최소화합니다.

오답입니다. CDC 이벤트를 reporting 테이블에 직접 기록하고 materialized view로 최신 버전만 노출하는 방식은, deletes와 “latest per key” 로직을 포함하는 전체 CDC에는 일반적으로 적합하지 않습니다. BigQuery materialized views는 지원되는 SQL 패턴과 incremental maintenance에 제한이 있으며, curated 테이블에 MERGE로 upserts/deletes를 적용하는 것을 대체할 수 없습니다.

문제 분석

핵심 개념: 이 문제는 BigQuery로의 CDC ingestion을 낮은 지연으로 제공하면서 비용 효율적으로 변경 사항을 적용하는지를 평가합니다. 핵심 BigQuery 패턴은 다음과 같습니다: 변경 불가능한(immutable) CDC 이벤트를 staging(append-only) 테이블로 스트리밍한 다음, 행 단위 DML이 아니라 집합 기반 연산(MERGE)을 사용해 주기적으로 curated reporting 테이블에 적용합니다. 정답이 맞는 이유: 각 CDC 이벤트를 reporting 테이블에 per-row INSERT/UPDATE/DELETE로 직접 스트리밍하는 방식(옵션 A)은 slot 소비 측면에서 비용이 크고, 7,500 rows/sec에서 18,000 rows/sec까지 스파이크가 있는 상황에서는 경합과 비효율을 유발할 수 있습니다. 대신 (B) 모든 CDC 이벤트(op type, commit_ts, PK, payload 포함)를 staging 테이블로 스트리밍해야 합니다. 이렇게 하면 ingestion이 단순하고 확장 가능하며, streaming inserts가 append 워크로드에 최적화되어 있어 낮은 지연을 유지할 수 있습니다. 그 다음 (D) 빈번한 scheduled DML MERGE(예: 30–60초마다)를 실행하여 primary key별로 최신 이벤트를 deduplicate/선택(보통 commit_ts와 tie-breaker 사용)하고, INSERT/UPDATE/DELETE를 하나의 집합 기반 statement로 적용합니다. MERGE는 많은 행 변경을 단일 쿼리 실행으로 배치 처리하여 오버헤드를 줄이며, 일반적으로 이벤트마다 DML을 실행하는 것 대비 slot 사용량을 크게 절감합니다. 이를 통해 <60s freshness를 달성하면서도 per-row DML 대비 compute 오버헤드를 최소 40% 이상 줄여야 한다는 요구사항을 충족합니다. 핵심 기능 / 모범 사례: - streaming을 위한 append-only staging 테이블을 사용하고, ingestion time 또는 commit_ts로 partitioning하며 primary key로 clustering하여 MERGE 스캔을 가속합니다. - MERGE source에서 배치 윈도우 내 primary key별 최신 이벤트만 선택합니다(QUALIFY ROW_NUMBER() OVER (PARTITION BY pk ORDER BY commit_ts DESC) = 1). - Cloud Scheduler + BigQuery scheduled queries로 MERGE를 스케줄링하거나 Cloud Composer/Workflows로 오케스트레이션합니다. - MERGE 윈도우를 제한합니다(예: 최근 N분)하여 스캔 바이트와 지연을 줄입니다. 흔한 오해: - “Real-time per-row DML이 가장 낮은 지연이다”: 지연은 낮을 수 있지만 오버헤드가 가장 크며 비용/처리량 목표를 달성하지 못하는 경우가 많습니다. - “Materialized views로 CDC 최신 상태를 저렴하게 해결할 수 있다”: BigQuery materialized views에는 제약이 있으며, deletes를 포함한 임의의 “latest per key” 로직을 proper upsert/delete 적용을 대체할 방식으로 지원하지 않습니다. 시험 팁: BigQuery로 CDC를 처리할 때는 기본적으로: raw/staging으로 stream한 뒤, curated 테이블에 MERGE로 batch-apply를 선택하세요. partitioning/clustering과 timestamp 기반 key별 dedup을 언급해 지연과 비용 목표를 동시에 충족하고, Google Cloud Architecture Framework의 cost optimization 및 operational excellence pillar와 정렬됨을 보여주면 좋습니다.

7
문제 7

Your retail analytics team receives mixed-format files (Avro and JSON) from branch exports and a partner SFTP feed, totaling about 300 GB per day and up to 2 million objects per month; you must land all files in a Cloud Storage bucket encrypted with your own Customer-Managed Encryption Key (CMEK), and you want to build the ingestion with a GUI-driven pipeline where you can explicitly configure an object sink that uses your KMS key; What should you do?

Storage Transfer Service는 SFTP를 포함한 외부 storage system에서 Cloud Storage로 데이터를 전송하도록 특별히 설계된 managed Google Cloud service입니다. custom code 없이 transfer orchestration, scheduling, 운영 안정성을 처리하므로, 하루 300 GB 및 월 수백만 개의 object라는 제시된 규모에 매우 적합합니다. CMEK 요구 사항은 대상 Cloud Storage bucket에 기본 Cloud KMS key를 구성함으로써 충족되며, 따라서 전송된 object는 customer-managed key로 암호화됩니다. 문제에서 GUI 선호를 언급하긴 하지만, 핵심 기술 요구 사항은 SFTP 및 파일 export에서 Cloud Storage로 대규모 파일을 적재하는 것이며, 이는 Storage Transfer Service와 가장 직접적으로 부합합니다.

Cloud Data Fusion은 visual data integration 및 ETL service이지만, SFTP와 branch export에서 Cloud Storage로 단순한 대량 파일 전송을 수행하는 데는 가장 적합하지 않습니다. Data Fusion을 사용하면 주로 transformation이나 여러 processing stage에 걸친 orchestration이 아니라 managed file movement만 필요한 use case에 불필요한 pipeline 복잡성이 추가됩니다. Cloud Storage와 연동할 수 있고 GUI 기반이긴 하지만, 시험에서 SFTP에서 Cloud Storage로 파일을 이동하는 데 우선적으로 선택해야 하는 서비스는 Storage Transfer Service입니다. 또한 CMEK는 주로 대상 bucket 구성의 속성이며, dedicated transfer service 대신 Data Fusion을 선택해야 하는 이유가 아닙니다.

Dataflow는 custom ingestion pipeline을 구축하는 데 분명 사용할 수 있고 Cloud Storage에 쓸 수도 있지만, Apache Beam 기반의 code-first processing framework입니다. 이 문제는 custom transformation logic, streaming computation, 또는 고급 processing semantics를 요구하지 않습니다. 단지 file-based source에서 Cloud Storage로 파일을 적재하면 됩니다. 이런 managed transfer workload에서는 Dataflow가 과도한 설계이며 개발 및 유지보수 오버헤드를 추가합니다. Storage Transfer Service가 SFTP 및 유사한 source에서 일정에 따라 파일을 이동하는 데 더 단순하고 적절한 managed 옵션입니다.

BigQuery Data Transfer Service는 지원되는 SaaS application 및 일부 Google data source에서 BigQuery로 데이터를 반복적으로 로드하기 위한 서비스입니다. raw 파일 적재를 위해 Cloud Storage를 대상으로 하지 않으며, branch export 및 SFTP feed에서 임의의 Avro 및 JSON 파일을 bucket으로 수집하도록 설계되지 않았습니다. 문제는 CMEK와 함께 파일을 Cloud Storage에 저장할 것을 명시적으로 요구하며, 이는 BigQuery Data Transfer Service의 주요 범위를 벗어납니다. 따라서 대상 측면과 ingestion pattern 측면 모두에서 잘못된 서비스입니다.

문제 분석

핵심 개념: 이 문제는 SFTP를 포함한 외부 file-based source에서 파일을 수집하여 Cloud Storage에 대규모로 적재하면서, customer-managed encryption key(CMEK)로 보호되는 bucket을 사용하는 데 가장 적절한 managed ingestion service를 선택하는 것에 관한 문제입니다. 결정 요소는 source 유형, 대상이 analytics system이 아니라 Cloud Storage라는 점, 운영 규모, 그리고 custom processing pipeline이 아니라 managed transfer service가 필요하다는 점입니다. 정답인 이유: Storage Transfer Service는 외부 storage system 및 SFTP source에서 Cloud Storage로 데이터를 이동하도록 특별히 설계되었습니다. scheduled 및 managed transfer를 지원하고, 많은 수의 object에 대해 잘 확장되며, CMEK 암호화를 위해 기본 Cloud KMS key를 사용하도록 구성된 대상 bucket과 함께 작동합니다. 따라서 raw Avro 및 JSON 파일을 Cloud Storage에 적재하는 가장 직접적이고 운영적으로 적절한 선택입니다. 주요 기능: 1) SFTP 및 기타 storage-based source에서 Cloud Storage로 전송하는 기능을 기본적으로 지원합니다. 2) 하루 수백 GB 및 월 수백만 개의 object에 적합한 managed되고 확장 가능한 transfer job을 제공합니다. 3) Cloud KMS를 통해 기본 CMEK가 구성된 Cloud Storage bucket과 호환됩니다. 4) 전체 ETL pipeline을 구축하고 운영하는 것과 비교해 운영 오버헤드가 최소화됩니다. 흔한 오해: GUI 기반 product라고 해서 핵심 작업이 단순한 대량 파일 전송일 때 자동으로 최적의 답이 되는 것은 아닙니다. Cloud Data Fusion은 visual ETL/integration tool이지만, SFTP에서 Cloud Storage로 대규모 파일을 이동하는 대표적인 서비스는 아닙니다. Dataflow는 강력하지만 code-centric이며, 단순한 파일 적재에는 불필요합니다. BigQuery Data Transfer Service는 raw 파일을 Cloud Storage에 저장하는 것이 아니라 BigQuery로 데이터를 로드하는 데 초점이 맞춰져 있습니다. 시험 팁: 요구 사항이 storage system 또는 SFTP에서 Cloud Storage로 파일을 일정에 따라 복사하거나 이동하는 것이라면, 먼저 Storage Transfer Service를 떠올리세요. 요구 사항이 여러 source와 sink 전반에서 transformation이 포함된 visual ETL pipeline을 강조한다면, Cloud Data Fusion을 떠올리세요. 또한 Cloud Storage의 CMEK는 일반적으로 특별한 transfer engine을 선택하는 방식이 아니라 대상 bucket에 기본 KMS key를 구성하는 방식으로 구현된다는 점도 기억하세요.

8
문제 8

You are migrating a nightly batch ETL for an e-commerce company: at 02:00 UTC, about 300 GB of gzip-compressed JSON files with sensitive purchase data land in a Google Cloud Storage bucket (gs://orchid-orders-batch), and a PySpark job on a temporary Cloud Dataproc cluster (1 master, 8 workers) transforms them and writes aggregated results to a BigQuery dataset (analytics.orders_agg) in the same project. You currently trigger the job manually with your user account, but you want to automate it while following security best practices and the principle of least privilege. How should you run this workload securely?

bucket을 개인 사용자만 파일에 접근할 수 있도록 제한하면 자동화와 운영 복원력이 깨집니다. batch ETL은 사람 ID에 의존하면 안 됩니다(계정 비활성화 위험, MFA 프롬프트, 퇴사/권한 회수). 또한 사용자가 Dataproc 실행 및 BigQuery write를 위해 추가 권한이 필요해져 사용자 접근 범위가 불필요하게 확대되므로 최소 권한과 역할 분리를 위반합니다.

service account에 Project Owner를 부여하는 것은 과도하게 허용적이며 최소 권한 원칙을 위반합니다. Owner에는 프로젝트 전반의 광범위한 관리 기능(IAM 변경, 리소스 삭제)이 포함되어 자격 증명이 오용될 경우 blast radius가 크게 증가합니다. 시험에서는 필요한 권한이 좁은 범위(GCS read + BigQuery write)로 충분할 때 primitive role과 광범위한 역할을 피하는지를 자주 묻습니다.

이는 권장되는 접근 방식입니다: Dataproc 워크로드를 필요한 권한만 가진 전용 service account로 실행합니다. 특정 입력 bucket에 roles/storage.objectViewer를 부여하고, BigQuery에는 dataset 범위의 write 권한(예: roles/bigquery.dataEditor)과 job 실행을 위한 roles/bigquery.jobUser를 부여합니다. 이는 안전한 자동화, 감사(auditing), 최소 권한을 지원하며 Google Cloud 보안 모범 사례와 일치합니다.

Project Viewer 사용자 계정은 BigQuery에 write할 수 없으며 자동화된 워크로드에 적합하지 않습니다. 추가 역할을 더하더라도, 예약된 ETL에 사람 ID를 사용하는 것은 라이프사이클 및 보안 문제(비밀번호/MFA, 퇴사 처리, 소유권 불일치)로 인해 권장되지 않습니다. 올바른 패턴은 범위가 좁게 설정된 권한과 명확한 감사 가능성을 가진 service account입니다.

문제 분석

핵심 개념: 이 문제는 Dataproc에서 데이터 워크로드를 자동화하고 Cloud Storage 및 BigQuery에 안전하게 접근하기 위한 IAM 모범 사례를 테스트합니다. 핵심 아이디어는 사람(사용자) ID나 과도하게 광범위한 역할 대신, 최소 권한(least-privilege) 권한을 가진 전용 service account를 사용하는 것입니다. 정답이 맞는 이유: 옵션 C가 정답인 이유는 Dataproc job이 (1) gs://orchid-orders-batch에서 입력 object를 읽고 (2) 집계 결과를 특정 BigQuery dataset analytics.orders_agg에 쓰는 데 필요한 권한만 가진 전용 service account로 실행되어야 하기 때문입니다. 이는 Google Cloud Architecture Framework의 security pillar(보안 기둥)와 일치합니다: blast radius 최소화, 역할 분리, 장기간 유지되는 광범위한 접근 회피. 또한 사용자 계정에 의존하지 않고(예: Cloud Scheduler/Workflows/Composer가 Dataproc을 트리거) 신뢰할 수 있는 자동화를 가능하게 합니다. 주요 기능 / 구성: - 전용 service account 생성(예: dataproc-etl-sa). - Storage 권한을 가장 좁은 범위로 부여: gs://orchid-orders-batch에 bucket-level IAM으로 roles/storage.objectViewer(또는 필요 시 IAM Conditions로 object-level까지). - BigQuery 권한을 dataset 범위로 부여: 일반적으로 analytics dataset에 roles/bigquery.dataEditor(또는 더 제한적인 custom role), 그리고 load/query job 실행을 위해 project level에 roles/bigquery.jobUser도 추가. - Dataproc cluster/job이 해당 service account(Dataproc cluster service account)를 사용하도록 구성하고, worker가 GCS/BigQuery 접근에 이를 사용하도록 보장. 흔한 오해: 단일 사용자(A)만 접근하도록 제한하면 보안이 좋아진다고 생각하는 경우가 많지만, 이는 자동화를 해치고 역할 분리를 위반합니다. 또 다른 경우로 “동작하게 만들기 위해” Owner(B)를 부여하는데, 이는 최소 권한 원칙에 명백히 반하며 위험을 증가시킵니다. Viewer 사용자(D)를 사용하는 경우 BigQuery에 write할 수 없고, 여전히 사람 ID에 의존하게 됩니다. 시험 팁: 자동화된 pipeline에는 사용자 계정보다 service account를 우선하세요. 권한은 가장 작은 리소스 범위(bucket/dataset)에서 필요한 역할만(Storage read + BigQuery write + BigQuery job 실행) 부여하세요. 명시적으로 요구되지 않는 한 primitive role(Owner/Editor/Viewer)은 피하세요. BigQuery는 종종 dataset의 data 권한과 project-level의 job 실행 권한이 모두 필요하다는 점을 기억하세요.

9
문제 9

A Singapore-based fintech platform ingests real-time authorization events from point-of-sale terminals worldwide, and the primary ledger table grows by approximately 280,000 rows per second. Multiple partner banks integrate your query APIs to embed live risk and compliance checks into their own systems. Your query APIs must meet the following requirements:

  • Single global endpoint
  • ANSI SQL support
  • Consistent access to the most up-to-date data What should you do?

BigQuery는 ANSI SQL을 지원하고 스트리밍 데이터 수집이 가능하지만, 쿼리가 job으로 실행되는 OLAP 웨어하우스이며 데이터 최신성은 streaming buffer 및 수집 지연의 영향을 받을 수 있습니다. 또한 BigQuery dataset은 위치(US/EU/region)를 가져야 하며, 진정으로 위치가 없는 “global” dataset을 만들 수 없습니다. BigQuery는 파트너 은행을 위한 강한 일관성의 초단위 최신 서빙 API에 최선의 선택이 아닙니다.

Cloud Spanner는 수평 확장, ANSI SQL, 그리고 리전 간 강한 일관성을 제공합니다. asia-southeast1에 leader를 두고 Europe 및 US에 read-only replica를 둔 multi-region instance는 트랜잭션 정확성을 유지하면서 글로벌 가용성과 읽기 확장을 지원합니다. 이는 빠르게 성장하는 ledger 테이블과 가장 최신 데이터에 대한 일관된 접근 요구사항에 부합합니다. 단일 글로벌 엔드포인트는 일반적으로 API 프런트엔드에서 제공합니다.

Cloud SQL for PostgreSQL은 SQL을 지원하지만, 리전 간 read replica는 비동기입니다. 즉, replica에서 읽는 파트너는 오래된 데이터를 볼 수 있어 “가장 최신” 일관성 요구사항을 위반할 수 있습니다. Cloud SQL은 수직 확장 한계도 있으며, 행 크기와 트랜잭션 패턴에 따라 초당 약 280k rows의 지속적 수집을 처리하는 데 어려움을 겪을 수 있습니다. global HTTP(S) load balancer는 데이터베이스 복제 지연이나 쓰기 확장성 제약을 해결하지 못합니다.

Cloud Bigtable은 매우 높은 쓰기 처리량과 multi-cluster replication을 처리할 수 있지만, ANSI SQL을 제공하지 않으며 관계형 데이터베이스가 아닙니다. 클러스터 간 복제는 최종적 일관성(eventually consistent)이므로 전 세계적으로 “가장 최신” 읽기를 보장할 수 없습니다. Bigtable은 시계열 및 key-value 접근 패턴에 매우 뛰어나지만, SQL 기반 리스크/컴플라이언스 쿼리를 통합하는 파트너 은행에는 상당한 추가 시스템 없이는 적합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 전 세계에 분산되어 있고, 쓰기 비율이 매우 높으며, 지연 시간이 낮은 쿼리 API에서 강한 일관성과 ANSI SQL이 필요한 경우에 적합한 서빙 데이터스토어를 선택하는지를 평가합니다. 주로 운영/서빙 데이터베이스와 분석용 웨어하우스를 구분하는 문제입니다. 정답이 맞는 이유: Cloud Spanner가 최적의 선택인 이유는 (1) ANSI SQL, (2) 매우 높은 쓰기 처리량을 위한 수평 확장성, (3) TrueTime을 사용해 리전 간 외부 일관성(externally consistent) 읽기/쓰기를 제공하는 강한 일관성을 제공하기 때문입니다. multi-region Spanner instance와 asia-southeast1에 leader를 두면, 쓰기는 강한 일관성으로 커밋될 수 있고 Europe 및 US의 read-only replica는 API 요구사항에 따라 강한 일관성(더 높은 지연) 읽기 또는 stale read(더 낮은 지연)를 제공할 수 있습니다. “가장 최신 데이터에 대한 일관된 접근” 요구사항은 강한 읽기를 의미하며, Spanner는 이를 전 세계적으로 지원합니다. 주요 기능 / 구성: - Multi-region Spanner instance: 리전 간 자동 동기식 복제와 고가용성. - Leader region 배치(asia-southeast1)는 싱가포르 기반의 주요 운영 및 쓰기 로컬리티와 정렬됩니다. - europe-west1 및 us-central1의 read-only replica는 전 세계 읽기 확장을 지원합니다. - “단일 글로벌 엔드포인트”는 일반적으로 API 계층(예: global external HTTP(S) load balancer)에서 구현되며, 동일한 Spanner instance에 연결하는 stateless API 서비스로 라우팅합니다. Spanner 자체는 애플리케이션 관점에서 단일 논리적 데이터베이스 엔드포인트입니다. - Spanner는 정확성, 트랜잭션, SQL이 필요한 금융/원장(ledger) 유사 워크로드를 위해 설계되었습니다. 흔한 오해: BigQuery는 ANSI SQL을 지원하고 확장성이 높지만, 배치/스트리밍 수집과 쿼리 job 기반의 분석용 데이터 웨어하우스입니다. 높은 QPS의 파트너 API를 위한, 강한 일관성을 갖춘 최신 서빙 데이터베이스로 설계된 것이 아닙니다. Bigtable은 대규모로 확장되지만 ANSI SQL이 아니며 관계형 쿼리/조인을 제공하지 않습니다. Cloud SQL read replica는 비동기이므로 전 세계적으로 “가장 최신” 읽기를 보장할 수 없습니다. 시험 팁: “글로벌 사용자 + SQL + 강한 일관성 + 매우 높은 쓰기 비율 + 서빙 API”를 보면 Cloud Spanner를 떠올리세요. “analytics/BI + 대규모 스캔 + OLAP”이면 BigQuery를 떠올리세요. “SQL 없이 초대규모 wide-column key/value”이면 Bigtable을 떠올리세요. 또한 replica 의미론을 확인하세요: Cloud SQL replica는 일반적으로 async이므로 엄격한 최신성 요구사항을 깨뜨립니다.

10
문제 10

Your team is building a Google Cloud–hosted tool to auto-tag up to 80 customer support emails per second with topic labels so agents can route them, you must release this in 10 business days with zero additional headcount and no team ML experience, and the labels only need to capture subject matter such as product names or issue types; what should you do?

정답입니다. Entity Analysis는 entities(예: 제품명, 구성요소, 조직, 일반적인 이슈 용어)를 추출하고 이를 순위화할 수 있도록 salience를 제공하므로 “토픽 라벨”에 자연스럽게 매핑됩니다. 완전 관리형이며 학습 데이터나 ML 전문성이 필요 없고, API 호출로 빠르게 통합할 수 있습니다. 이는 “주제(subject matter)” 기반 라벨링 요구를 충족하면서 10일 일정과 추가 인력 0명 제약을 가장 잘 만족합니다.

오답입니다. Sentiment Analysis는 감정 톤(positive/negative/neutral)을 설명하는 polarity/score와 magnitude를 반환하며, 주제(subject matter)를 반환하지 않습니다. sentiment는 우선순위 지정이나 에스컬레이션 워크플로에는 유용할 수 있지만, 제품명이나 이슈 유형 같은 라벨을 신뢰성 있게 생성하지 못합니다. sentiment를 선택하면 토픽 기반 라우팅 라벨이라는 핵심 기능 요구사항을 충족하지 못합니다.

이 시나리오에서는 오답입니다. 커스텀 TensorFlow 텍스트 분류기는 정확한 도메인 특화 이슈 카테고리를 만들 수 있지만, 라벨된 학습 데이터, feature engineering/모델 선택, 평가, 그리고 MLOps 파이프라인이 필요합니다. 관리형 배포(Vertex AI/legacy ML Engine)를 사용하더라도, 팀의 ML 경험 부족과 10영업일 마감은 리스크가 크고 실현 가능성이 낮습니다.

오답입니다. GKE에서 커스텀 모델을 구축/배포하면 옵션 C보다 운영 부담이 더 커집니다: containerization, 클러스터 관리, autoscaling, 모니터링, 보안 패치, 신뢰성 엔지니어링이 필요합니다. 또한 학습 데이터와 ML 전문성도 여전히 필요합니다. 이는 “추가 인력 없음”과 빠른 제공 제약을 위반하며, 관리형 API로 요구사항을 충족할 수 있을 때의 모범 사례와도 맞지 않습니다.

문제 분석

핵심 개념: 이 문제는 촉박한 제약 조건 하에서 커스텀 ML을 구축하는 것과 관리형 ML/AI 기능을 선택하는 것을 평가합니다. Google Cloud에서는 Cloud Natural Language API가 사전 학습된 NLP 기능(entities, sentiment, syntax, classification)을 제공하며, 모델 학습 없이 REST로 호출할 수 있습니다. 정답이 맞는 이유: 이메일 텍스트에서 토픽과 유사한 라벨(제품명, 이슈 유형)이 필요하고, 10영업일 내 출시해야 하며, 추가 인력은 0명이고, ML 경험도 없습니다. Entity Analysis는 텍스트에 언급된 “대상(things)”(예: 제품명, 조직, 위치, 일반 명사)을 추출하고 분류하도록 설계되었으며, entity 이름과 salience 점수를 반환합니다. entities를 라벨로 사용하는 것이 데이터 라벨링, 모델 학습, MLOps, 지속적인 모델 유지보수를 피할 수 있어 프로덕션까지 가는 가장 빠른 경로입니다. 초당 80건 이메일 처리에서는 전형적인 온라인 추론 패턴으로, 서비스가 API를 호출하고 상위 entities( salience/type 기준)를 라우팅 라벨로 매핑하면 됩니다. 주요 기능 / 모범 사례: - Entity Analysis는 entity type, salience, 그리고(가능한 경우) metadata(예: Wikipedia/Knowledge Graph IDs)를 반환하므로 라벨 정규화에 도움이 됩니다. - 가능하면 batching을 구현하고(예: 허용된다면 구분자를 두고 짧은 이메일을 연결) 반복되는 템플릿에 대해 caching/deduplication을 추가해 비용을 줄이세요. - quotas와 latency를 고려하세요: Natural Language API quota가 QPS를 지원하는지 확인하고 필요 시 증설을 요청하며, exponential backoff와 circuit breaking을 포함한 retries를 사용하세요. - 데이터 거버넌스: 이메일에는 PII가 포함될 수 있으므로, 전송 데이터 최소화, TLS 사용, 필요 시 DLP 고려 등 Google Cloud Architecture Framework(보안 및 컴플라이언스)를 따르세요. 흔한 오해: Sentiment Analysis는 종종 “토픽”과 혼동되지만, 이는 주제가 아니라 감정 톤을 측정합니다. 커스텀 TensorFlow 모델은 더 나은 도메인 특화 라벨을 만들 수 있지만, 라벨된 학습 데이터, ML 전문성, 배포/MLOps가 필요하므로 10일 내에는 현실성이 낮습니다. 시험 팁: 요구사항이 빠른 제공, 최소 운영, ML 전문성 부재를 강조하면 관리형 사전 학습 API를 우선 선택하세요. 라벨 유형에 맞는 NLP 기능을 고르세요: entities는 “무엇이 언급되는가”, sentiment는 “어떻게 느끼는가”, 그리고 사전 학습 기능으로 정확도/도메인 요구를 충족할 수 없을 때만 커스텀 모델을 선택합니다.

합격 후기(9)

M
M*********Nov 25, 2025

학습 기간: 1 month

I tend to get overwhelmed with large exams, but doing a few questions every day kept me on track. The explanations and domain coverage felt balanced and practical. Happy to say I passed on the first try.

L
L*************Nov 25, 2025

학습 기간: 2 months

Thank you ! These practice questions helped me pass the GCP PDE exam at the first try.

S
S***********Nov 21, 2025

학습 기간: 1 month

The layout and pacing make it comfortable to study on the bus or during breaks. I solved around 20–30 questions a day, and after a few days I could feel my confidence improving.

정
정**Nov 19, 2025

학습 기간: 1 month

해설이 영어 기반이긴 하지만 나름 도움 됐어요! 실제 시험이랑 문제도 유사하고 좋네요 ㅎㅎ

E
E********Nov 16, 2025

학습 기간: 2 months

I combined this app with some hands-on practice in GCP, and the mix worked really well. The questions pointed out gaps I didn’t notice during practice labs. Good companion for PDE prep.

다른 모의고사

Practice Test #2

50 문제·120분·합격 700/1000
← 모든 Google Professional Data Engineer 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 Google Professional Data Engineer 자격증 학습을 이어가세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGoogle CloudMicrosoft Azure

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.