CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Professional Data Engineer
Google Professional Data Engineer

Practice Test #2

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

You are designing a platform to store 1-second interval temperature and humidity readings from 12 million cold-chain sensors across 40 warehouses. Analysts require real-time, ad hoc range queries over the most recent 7 days with sub-second latency. You must avoid per-query charges and ensure the schema can scale to 25 million sensors and accommodate new metrics without frequent schema changes. Which database and data model should you choose?

BigQuery는 time-series 데이터를 저장할 수 있고 SQL range query를 지원하지만, 일반적으로(on-demand) per-query 비용이 발생하며 주로 낮은 지연 시간의 operational store가 아닙니다. 12M sensors가 1 Hz로 쓰는 경우 ingest가 매우 큽니다. BigQuery가 높은 볼륨을 처리할 수는 있지만, 가장 최근 데이터에 대해 일관된 sub-second ad hoc query latency를 달성하는 것은 전형적인 강점이 아닙니다. per-query charges를 피하려면 flat-rate reservations가 필요하지만, 이 옵션에는 그 내용이 명시되어 있지 않습니다.

초당 1개 column을 두고 매초 같은 row를 업데이트하는 wide BigQuery 테이블은 anti-pattern입니다. BigQuery는 빈번한 row update가 아니라 append-only analytics에 최적화되어 있습니다. 이 설계는 복잡성을 증가시키고 contention 위험을 높이며, schema evolution(메트릭 추가 또는 granularity 변경)을 고통스럽게 만듭니다. 또한 효율적인 range query를 위한 partitioning/clustering과 자연스럽게 맞지 않아 더 높은 비용과 운영 오버헤드로 이어질 수 있습니다.

좁고 append-only인 Cloud Bigtable 테이블에 row key = sensorId + timestamp(종종 reversed time 포함)는 표준적인 time-series 패턴입니다. 이는 수천만 디바이스까지 수평 확장되며, row key가 query 패턴(예: 센서별 최근 7일)과 일치할 때 낮은 지연 시간의 range scan을 지원합니다. Bigtable의 sparse columns는 schema migration 없이 새 metrics를 새 qualifier로 추가할 수 있게 해주며, 비용은 쿼리당이 아니라 provisioned 방식입니다.

센서당 분당 1개 wide Bigtable row에 60 columns(초당 1개)을 두면 row 수는 줄일 수 있지만, 같은 row에 대한 빈번한 mutation(매초 업데이트)을 유발하여 효율이 떨어지고 contention/hotspot 위험을 증가시킬 수 있습니다. 또한 새 metrics 추가가 더 복잡해지고(초 단위로 qualifier가 곱해짐) 시간이 지나며 매우 wide한 row를 만들 수 있습니다. 확장성과 단순성을 위해서는 일반적으로 좁고 append-only인 time-series row가 선호됩니다.

문제 분석

핵심 개념: 이 문제는 예측 가능한 비용으로, 높은 ingest(수집)량의 time-series 데이터에 대해 낮은 지연 시간의 range scan을 수행할 수 있는 올바른 storage system과 data model을 선택하는지를 평가합니다. BigQuery(쿼리당/온디맨드 비용이 발생하는 serverless analytics)와 Cloud Bigtable(키/범위 접근 패턴에 최적화된, 낮은 지연 시간의 수평 확장 가능한 wide-column store)을 대비합니다. 정답이 맞는 이유: Cloud Bigtable을 좁고 append-only인 schema로 설계하는 것(Option C)이 요구사항을 가장 잘 충족합니다: (1) 매초 12M sensors가 쓰는 것은 극단적인 write throughput이며, Bigtable은 지속적인 높은 QPS와 대규모 time-series에 맞게 설계되었습니다. (2) 분석가가 최근 7일에 대해 sub-second latency로 실시간 ad hoc range query를 수행해야 하는데, Bigtable은 쿼리가 row-key range에 정렬되어 있으면 millisecond read를 제공할 수 있습니다. (3) “per-query charges를 피하라”는 요구는 BigQuery의 on-demand query pricing과 맞지 않으며, Bigtable은 provisioned(nodes/processing units) 방식이라 쿼리당 비용이 아닙니다. (4) “잦은 schema 변경 없이 새로운 metrics를 수용”은 Bigtable의 sparse하고 유연한 column-family/qualifier 모델에 부합합니다—새 metrics는 테이블 DDL churn 없이 새 column으로 추가할 수 있습니다. 주요 기능 / best practices: 지배적인 access pattern(센서별 최근 시간 범위)에 맞게 row key를 설계하세요. 일반적인 패턴은 sensorId + reversed timestamp(또는 time-bucket prefix + reversed time)로, 최근 데이터가 연속적으로 배치되게 하여 “최근 7일”에 대한 효율적인 scan을 가능하게 합니다. “m”(metrics) 같은 column family를 두고 qualifier로 temperature, humidity 등을 사용합니다. retention을 강제하고 storage를 제어하기 위해 GC policy(예: max age 7 days)를 적용합니다. hot-spotting도 고려하세요: 많은 write가 동일한 key range를 타겟하면, range query를 가능하게 유지하면서도 부하를 분산하기 위해 salting/hashing 또는 bucket prefix를 추가합니다. 흔한 오해: BigQuery는 ad hoc analytics에 매력적으로 보이지만, 신선한(high-velocity) 데이터에 대한 sub-second latency와 “per-query charges 없음” 요구는 flat-rate reservations에 커밋하고 streaming/partitioning 고려사항을 감수하지 않는 한 부적합합니다. wide-row Bigtable 설계(분 단위 bucket에 60 columns)는 효율적으로 보일 수 있지만, schema evolution을 복잡하게 만들고 크고 자주 변경되는 row를 만들 수 있습니다. 시험 팁: IoT/time-series에서 매우 높은 ingest와 낮은 지연 시간의 key/range read가 필요하면 Bigtable을 떠올리세요. 대규모 dataset 전반에 대한 복잡한 SQL analytics가 필요하면 BigQuery를 떠올리세요. data model을 선택할 때는 항상 요구사항을 pricing model(per-query vs provisioned), latency 기대치, 그리고 주요 access pattern에 매핑하세요.

2
문제 2

Your micromobility platform migrated a 4.5 TB ride-events warehouse from an on-prem system to BigQuery; the core fact_rides table (≈2.2 billion rows, ~75 million new rows per day) is modeled in a star schema with small dimension tables and currently stored as one unpartitioned table. Analysts run dashboards that filter for the last 30 days using WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY), yet queries still scan nearly the entire table and take 30–45 seconds, increasing query costs. Without increasing storage costs, what should you change to speed up these 30-day queries in line with Google-recommended practices?

dimension 속성을 포함하도록 embedding하여 denormalization하면 join 오버헤드를 줄이고 때로는 대시보드 지연 시간을 개선할 수 있지만, 핵심 문제—unpartitioned이기 때문에 쿼리가 fact 테이블 거의 전체를 스캔하는 것—를 해결하지 못합니다. 여전히 최근 30일을 찾기 위해 4.5 TB 대부분을 읽게 됩니다. 또한 반복되는 dimension 속성 때문에 스토리지가 증가할 수 있어 “스토리지 비용을 증가시키지 않고”라는 제약을 위반할 수 있습니다.

scooter_id 기준으로 여러 테이블로 sharding하는 것은 일반적으로 BigQuery에서 anti-pattern입니다. 운영 복잡도(테이블이 많아짐, 권한 관리가 어려움, lifecycle 관리가 어려움)를 증가시키고, 액세스 패턴(시간 기반 필터링)과도 맞지 않습니다. 또한 쿼리가 많은 shard를 union해야 할 수 있어 성능이 나빠질 수 있습니다. BigQuery는 대규모 테이블에 대해 수동 sharding보다 partitioning/clustering을 권장합니다.

view(또는 materialized view)에서 dimension 데이터를 materializing하는 것만으로는 날짜로 필터링할 때 대규모 fact 테이블에서 스캔되는 바이트 수를 줄이지 못합니다. 병목은 dimension lookup이 아니라 fact 테이블 I/O입니다. Materialized view는 대규모 데이터셋을 pre-aggregate하거나 pre-filter할 때 유용하지만, “dimension 데이터 materializing”만으로는 unpartitioned fact 테이블 대부분을 스캔하는 것을 막지 못합니다.

fact 테이블을 event_date로 partitioning하는 것은 빈번한 시간 범위 쿼리가 있는 대규모 append-only event/fact 테이블에 대해 BigQuery가 권장하는 접근 방식입니다. Partition pruning을 통해 최근 30일로 필터링하는 쿼리는 전체 테이블 대신 관련된 daily partition만 스캔하므로 bytes processed를 줄이고 비용을 낮추며 지연 시간을 개선합니다. 스토리지 비용을 증가시키지 않으면서 쿼리를 빠르게 해야 한다는 요구사항을 충족합니다.

문제 분석

핵심 개념: 이 문제는 분석 워크로드를 위한 BigQuery 스토리지 최적화—특히 테이블 partitioning(그리고 암묵적으로 partition pruning)을 통해 스캔되는 바이트 수, 지연 시간, 비용을 줄이는 것—을 평가합니다. 이는 액세스 패턴에 맞게 데이터 스토리지를 설계하여 비용과 성능을 최적화하라는 Google Cloud Architecture Framework 가이드와 일치합니다. 정답이 맞는 이유: 분석가들은 event_date를 기준으로 최근 30일을 일관되게 필터링합니다. 현재 fact 테이블이 unpartitioned이므로, BigQuery는 필요한 범위가 작은 시간 구간뿐이더라도 조건식을 평가하기 위해 대부분/전체 블록을 스캔해야 합니다. fact_rides 테이블을 event_date로 partitioning하면 partition pruning이 가능해집니다. 즉, BigQuery는 최근 30일과 교차하는 partition만 읽어 bytes processed를 크게 줄이고 쿼리 시간을 개선합니다. 이는 시간 기반 필터가 있는 대규모, append-heavy fact 테이블에 대한 BigQuery의 정석적인 권장 사항입니다. 주요 기능 및 모범 사례: - 공통 필터에 사용되는 컬럼(event_date)에 DATE/TIMESTAMP partitioning을 사용합니다. 하루에 75M 신규 행이 추가되는 경우 daily partition이 일반적입니다. - pruning의 이점을 얻기 위해 쿼리에 partitioning 컬럼에 대한 필터가 포함되도록 합니다(대시보드는 이미 그렇게 하고 있음). - 실수로 full scan이 발생하는 것을 방지하기 위해 “require partition filter” 설정을 고려합니다. - Partitioning은 본질적으로 스토리지 비용을 증가시키지 않으며, 데이터가 저장되는 방식을 재구성합니다. (약간의 metadata 오버헤드는 있을 수 있지만, 테이블 크기에 비해 의미 있는 스토리지 증가가 아닙니다.) - 선택적으로 clustering(예: scooter_id, city_id 기준)을 사용하면 partition 내부에서 선택도가 높은 쿼리를 더 개선할 수 있지만, “최근 30일” 문제의 1차 해결책은 partitioning입니다. 흔한 오해: Denormalization은 join 비용을 줄일 수 있지만, 여기서의 지배적인 문제—시간 제한 쿼리를 위해 4.5 TB 테이블 거의 전체를 스캔하는 것—를 해결하지 못합니다. 많은 테이블로 sharding하는 것은 BigQuery에서 partitioned table에 비해 anti-pattern이며 거버넌스와 쿼리를 복잡하게 만듭니다. View/materialized dimension view는 fact 테이블의 스캔 볼륨을 줄이지 못합니다. 시험 팁: BigQuery + 매우 큰 fact 테이블 + 반복되는 시간 범위 조건(최근 N일)을 보면, 첫 번째 최적화는 WHERE에서 사용하는 date/timestamp 필드로 partitioning하는 것입니다. 다음 단계 개선은 clustering과 partition filter enforcement로 비용을 제어하는 것입니다. 또한 BigQuery는 주로 bytes processed 기준으로 과금하므로, 스캔 데이터 감소는 성능과 비용 모두에서 이점이 있다는 점을 기억하세요.

3
문제 3

You are migrating a Scala Spark 3 nightly ETL pipeline that processes 2 TB of JSON logs from an Azure HDInsight cluster to Google Cloud. You need the job to read from a Cloud Storage bucket and append results to a BigQuery table with no application logic changes. The job is tuned for Spark with each executor using 8 vCPUs and 16 GB memory, and you want to retain similar executor sizing. You want to minimize installation and infrastructure management (no cluster lifecycle or connector setup) while running the job. What should you do?

GKE에서 Spark 실행은 가능하지만(예: Spark on Kubernetes), Kubernetes cluster를 생성하고 운영해야 하며, Spark images, service accounts, networking을 구성하고, 종종 connector 및 dependencies를 관리해야 합니다. 이는 설치 및 인프라 관리를 최소화해야 한다는 요구사항을 위반합니다. 이미 Kubernetes로 표준화되어 있고 container 기반 portability가 필요할 때는 더 적합하지만, 최소 운영으로 nightly Spark ETL을 단순 lift-and-shift하는 경우에는 적합하지 않습니다.

단일 Compute Engine VM(또는 소수의 VM)에서는 Spark를 설치 및 관리하고, 스케일링을 구성하며, job scheduling을 처리하고, GCS 및 BigQuery connectors와 authentication을 설정해야 합니다. 또한 2 TB nightly workload에 대해 capacity planning 및 reliability 우려를 초래합니다. 이 옵션은 운영 부담이 가장 크며, 인프라 및 connector 설정을 피해야 한다는 요구사항과 정렬되지 않습니다.

Dataproc clusters는 managed Hadoop/Spark clusters이며 Spark 3 job을 실행할 수 있고 GCS 및 BigQuery connectors도 사용할 수 있습니다. 하지만 여전히 클러스터 라이프사이클(생성/삭제 또는 상시 실행), 사이징, autoscaling policies, initialization actions, image/version 관리를 수행해야 합니다. Nightly batch job의 경우 상시 클러스터 비용을 지불하거나 ephemeral cluster 생성을 자동화해야 하며, 둘 다 serverless 대비 운영 오버헤드를 증가시킵니다.

Dataproc Serverless는 클러스터를 프로비저닝하지 않고 Spark batch job을 실행하므로 인프라 관리를 최소화하고 클러스터 라이프사이클 작업을 제거합니다. Spark 3를 지원하며, Google 제공 connector를 통해 Cloud Storage 및 BigQuery와 통합되며, 일반적으로 수동 설치가 필요하지 않습니다. 기존 8 vCPU/16 GB executor 사이징에 맞추도록 Spark executor cores 및 memory를 설정할 수 있습니다. 이는 제약 조건(애플리케이션 로직 변경 없음, 운영 오버헤드 최소화)을 가장 잘 충족합니다.

문제 분석

핵심 개념: 이 문제는 Spark 애플리케이션 동작을 유지하면서 Cloud Storage 및 BigQuery와 통합하고, 운영 오버헤드를 최소화하기 위해 Google Cloud에서 적절한 managed Spark runtime을 선택하는지를 평가합니다. 정답이 맞는 이유: Dataproc Serverless for Spark는 클러스터를 프로비저닝, 관리, 스케일링하지 않고 Spark batch job을 실행하도록 설계되었습니다. 기존 Spark job(Scala Spark 3)을 제출하면 Dataproc Serverless가 기반 인프라를 처리합니다. Cloud Storage는 기본 제공되는 GCS connector로 네이티브하게 읽기를 지원하고, BigQuery는 Dataproc에서 제공하는 BigQuery connector를 사용해 쓰기를 지원하므로, 수동 connector 설치와 클러스터 라이프사이클 관리를 피할 수 있습니다. 이는 “클러스터 라이프사이클 또는 connector 설정 없음” 및 “애플리케이션 로직 변경 없음” 요구사항에 가장 잘 부합합니다. 주요 기능 / 구성: - Serverless 실행: 클러스터 생성/삭제가 없고, 노드 관리가 필요 없으며, 운영 부담이 감소합니다( Google Cloud Architecture Framework: operational excellence 및 reliability와 정렬). - Spark 3 지원 및 job 단위 리소스 사이징: Spark properties(예: executor cores 및 memory)를 지정하여 executor를 8 vCPUs 및 16 GB memory로 유지하는 등 기존 튜닝과 유사하게 맞출 수 있습니다. - Built-in 통합: GCS connector를 통한 GCS 접근과 Dataproc BigQuery connector를 통한 BigQuery 연동을 제공하며, 일반적으로 커스텀 설치가 아니라 job properties를 통해 구성합니다. - 비용 모델: 유휴 클러스터 시간에 비용을 지불하는 대신 job 실행 중 사용한 리소스에 대해서만 비용을 지불하므로, nightly ETL에 적합합니다. 흔한 오해: Managed Dataproc cluster(option C)도 “managed”이지만, 여전히 클러스터 라이프사이클(생성, 스케일, 삭제)을 관리해야 하고, initialization actions, image versions, dependency/connector 관리도 처리하는 경우가 많습니다. GKE(A)와 VM(B)에서도 Spark를 실행할 수 있지만, 훨씬 더 많은 인프라 및 dependency 관리가 필요합니다. 시험 팁: “Spark job”, “minimal ops”, “no cluster lifecycle”, “no connector setup”을 보면 Dataproc Serverless가 기본적으로 최선의 정답입니다. 장시간 실행되는 클러스터, 커스텀 networking/initialization, HDFS 유사 로컬 스토리지 패턴, 노드 타입에 대한 강한 제어 및 여러 job에 걸친 지속적 튜닝이 필요할 때는 Dataproc clusters를 선택하세요.

4
문제 4

You are the data platform lead at a global ride-sharing company where five regional operations teams share a single BigQuery project billed with on-demand pricing. The project is capped at 2,000 concurrent on-demand slots; during end-of-quarter surge analysis, some analysts cannot obtain slots and their queries are queued or canceled. You must avoid creating additional projects, enforce a priority scheme across teams (e.g., Finance > Operations > Marketing), and ensure predictable performance during spikes; what should you do?

오답. 예약된 batch 쿼리를 interactive로 전환하면 interactive jobs가 즉시 실행되려 하기 때문에 피크 시간대 slot 경쟁이 증가합니다. Batch priority는 리소스가 उपलब्ध할 때 기회적으로 실행되도록 설계되어 사용률을 평탄화하는 데 도움이 됩니다. 이 선택지는 대기/취소를 악화시킬 가능성이 높고, 팀 간 우선순위 체계나 보장된 용량을 구현하지도 않습니다.

오답. on-demand slot 동시성을 늘리기 위해 추가 프로젝트를 만드는 것은 요구사항(“추가 프로젝트 생성 회피”)에 의해 명시적으로 금지됩니다. 허용된다 하더라도 거버넌스를 분절시키고 IAM, 데이터 공유, 비용 통제를 복잡하게 만들며, 팀 간에 깔끔하고 강제 가능한 우선순위 모델을 제공하지 못합니다. 또한 용량 계획을 위해 Reservations를 사용하는 것과 비교하면 안티패턴입니다.

정답. BigQuery Reservations(flat-rate)는 전용 slot 용량을 제공하여 스파이크 동안 예측 가능한 성능을 가능하게 합니다. 충분한 slots(예: 4,000)를 구매하고 부서에 할당된 계층형 reservations를 생성하면, 동일한 프로젝트 내에서 Finance에 대한 최소 용량을 보장하고 우선순위를 강제할 수 있습니다. 이는 reliability 및 성능 목표에 부합하며, 용량 사용에 대한 명확한 관리 제어와 모니터링을 제공합니다.

오답. quota 증가 요청은 on-demand 동시성 상한을 올릴 수는 있지만, 예측 가능한 성능을 보장하거나 Finance > Operations > Marketing 우선순위 체계를 강제하지는 못합니다. On-demand는 변동성의 영향을 받는 공유 best-effort 모델로 남으며, quota 증가는 제한되거나 승인에 시간이 걸릴 수 있습니다. Reservations가 보장된 용량과 워크로드 관리를 위한 의도된 해결책입니다.

문제 분석

핵심 개념: 이 문제는 BigQuery 용량 관리와 워크로드 거버넌스를 평가합니다: on-demand(공유, 버스티) vs. BigQuery Reservations(전용 slots), 그리고 reservations/assignments 및 job priority를 사용한 우선순위 지정입니다. 또한 예측 가능한 성능과 통제된 지출을 보장함으로써 Google Cloud Architecture Framework의 Reliability 및 Cost Optimization 기둥을 다룹니다. 정답이 맞는 이유: On-demand pricing은 공유 풀을 사용하며 프로젝트별 동시 slot 상한(여기서는 2,000)을 적용합니다. 스파이크 동안 slot 경합으로 인해 쿼리가 대기열에 쌓이거나 실패할 수 있으며, Finance가 다른 팀보다 먼저 리소스를 받도록 보장할 수 없습니다. BigQuery Reservations(flat-rate capacity)는 전용 slots(예: 4,000)를 구매하고 reservations 및 assignments(project/folder/org)를 통해 조직 단위에 할당할 수 있게 해줍니다. 계층형 reservations를 사용하면 부서 수준 reservations(Finance, Operations, Marketing)를 만들고 선택적으로 공유 “overflow” reservation을 둘 수 있습니다. 이를 통해 추가 프로젝트를 만들지 않고도 우선순위가 높은 팀에 대한 최소 용량을 보장하고, 분기말 급증 시 예측 가능한 성능을 제공합니다. 주요 기능 / 모범 사례: - slot 용량(Reservations)을 구매하여 on-demand 동시성 제한에 대한 의존을 제거하고, 부하 시 대기열을 줄입니다. - assignments가 있는 여러 reservations를 사용해 누가 어떤 용량을 소비하는지 제어하고, 계층을 구현하여 미사용 용량이 하위 티어로 흐르도록(또는 정책에 따라 엄격한 격리를 유지하도록) 합니다. - job labels, 별도 service accounts, 그리고( assignments를 통한) query routing과 결합하여 거버넌스를 강제합니다. - BigQuery Reservation metrics(slot utilization, pending units)로 모니터링하고 용량을 조정합니다. 스파이크에 대비해(에디션에서 지원된다면) autoscale을 고려합니다. 흔한 오해: - “그냥 quota를 늘린다”(D)는 실현 가능하지 않을 수 있고, 우선순위 지정을 제공하지 않으며, on-demand가 공유되고 버스티하기 때문에 성능이 여전히 예측 불가능합니다. - “batch를 interactive로 바꾼다”(A)는 즉시 실행을 강제하여 경합을 악화시킵니다. - “프로젝트를 더 만든다”(B)는 제약을 위반하며 거버넌스 관점에서 안티패턴입니다. 또한 데이터 액세스와 billing을 복잡하게 만듭니다. 시험 팁: 예측 가능한 성능, 보장된 용량, 팀 간 우선순위 지정 같은 요구사항이 보이면 BigQuery Reservations(slot 기반 용량)와 계층형 reservations/assignments를 떠올리세요. On-demand는 애드혹, 변동성 있는 워크로드에는 적합하지만, 엄격한 SLO나 스파이크 동안의 우선순위 강제에는 적합하지 않습니다.

5
문제 5

A regional public transit agency runs a 160-node on-prem Hadoop environment (Spark and Hive on HDFS) to process ridership and farebox logs; workloads are sized for weekday peak demand, but over 70% of pipelines are nightly batch and midday utilization often drops below 20%. The lease on the municipal server room ends in 60 days, and an extension is expensive; the agency wants to reduce operational overhead, favor serverless where practical, and lower storage and compute costs without jeopardizing its SLA of completing nightly batch by 5:00 a.m. They have approximately 900 TB of Parquet and ORC data and 250 scheduled Spark/Hive jobs; the immediate goal is to move within the deadline, minimize risk, and realize near-term cost savings. Which migration strategy should they choose to maximize cost savings in the cloud while still meeting the 60-day timeline?

persistent disk에서 HDFS를 사용하는 Dataproc은 단순한 lift-and-shift로 60일 마감을 충족할 수 있습니다. 그러나 Hadoop에서 가장 비싸고 운영 부담이 큰 부분인 PD 상의 HDFS 용량을 그대로 유지해 지속적으로 비용을 지불하게 됩니다. 또한 장기 실행 클러스터를 유도하는 경향이 있어, 기관의 낮은 정오 사용률과 비용 절감 목표에 부합하지 않습니다.

이는 권장되는 “빠른 마이그레이션 + 비용 최적화” 패턴입니다: Dataproc으로 이동해 Spark/Hive를 유지하되, HDFS를 Cloud Storage로 대체해 스토리지 비용을 절감하고 스토리지를 컴퓨팅에서 분리합니다. 관리형 Hive metastore를 추가하면 운영 오버헤드를 줄이고 신뢰성을 향상시킵니다. 리팩터링을 최소화하고, 야간 배치를 위한 autoscaling/ephemeral clusters를 지원하며, 마감과 비용 목표를 가장 잘 충족합니다.

Dataproc에서 HDFS로 Spark를 실행하면서 동시에 모든 Hive 테이블을 BigQuery로 변환하는 것은 범위와 리스크를 크게 늘립니다. 900 TB의 Parquet/ORC를 변환하고 의미론, 파티션, 다운스트림 의존성을 검증하는 작업은 시간이 많이 들며 60일 마감과 5:00 a.m. SLA를 위태롭게 할 수 있습니다. BigQuery 마이그레이션은 가치가 있지만, 클라우드에서 안정화한 뒤의 후속 현대화 단계로 진행하는 것이 더 적절합니다.

Spark 파이프라인을 Dataflow로 재작성하고 Hive를 BigQuery로 완전히 마이그레이션하는 것은 가장 serverless한 접근이지만, 250개 잡을 60일 내에 수행하기에는 상당한 엔지니어링 노력, 테스트, 운영 변경이 필요해 현실적이지 않습니다. 야간 SLA를 놓칠 리스크가 큽니다. 이 옵션은 즉각적이고 저위험의 마이그레이션 및 단기 절감보다 장기 아키텍처를 우선합니다.

문제 분석

핵심 개념: 이 문제는 속도(60일 마감), 비용 최적화, 운영 단순성의 균형을 맞추는 실용적인 Hadoop-to-Google-Cloud 마이그레이션 패턴을 평가합니다. 핵심 서비스는 Dataproc(관리형 Spark/Hive), Cloud Storage(오브젝트 스토리지 데이터 레이크), Dataproc Metastore(관리형 Hive metastore)입니다. B가 정답인 이유: 옵션 B는 촉박한 일정 하에서 마이그레이션 리스크를 최소화하면서 단기 비용 절감 효과를 가장 크게 제공합니다. 컴퓨팅을 Dataproc으로 옮기면 기존 Spark/Hive 코드와 잡 오케스트레이션 패턴을 유지할 수 있어(리팩터링 최소화), HDFS를 Cloud Storage로 대체하면 persistent disk 상의 HDFS에 대한 비용 및 운영 오버헤드를 제거하고 클러스터 라이프사이클에 묶인 상시 스토리지를 피할 수 있습니다. Cloud Storage는 이 규모(900 TB)에서 PD 기반 HDFS보다 TB당 비용이 더 저렴하고, 높은 내구성을 제공하며, 스토리지를 컴퓨팅과 분리해 클러스터를 적정 규모로 조정하거나 오토스케일링하거나 야간 배치용으로 일시적(ephemeral)으로 운영할 수 있어 정오 무렵 <20% 사용률 문제를 직접 해결합니다. 관리형 Hive metastore를 사용하면 자체 관리 metastore VM 대비 관리 부담을 줄이고 신뢰성을 높여 5:00 a.m. SLA를 보호하는 데 도움이 됩니다. 핵심 기능 / 모범 사례: - Dataproc과 Cloud Storage connector(GCS)를 기본 데이터 레이크로 사용하고, Parquet/ORC를 GCS에 직접 저장합니다. - Dataproc autoscaling 및/또는 ephemeral clusters(배치 윈도우마다 생성)를 사용해 유휴 노드 비용을 피합니다. - Hive metastore를 Dataproc Metastore로 마이그레이션하여 관리형 백업, HA, 더 단순한 운영을 확보합니다. - 초기에는 잡을 대부분 변경하지 않고, 안정화 후(예: 선택적으로 BigQuery/Dataflow) 현대화를 진행합니다. - Google Cloud Architecture Framework에 부합: 비용 최적화(스토리지/컴퓨팅 분리, 유휴 감소), 운영 우수성(관리형 서비스), 신뢰성(관리형 metastore, 반복 가능한 클러스터 프로비저닝). 흔한 오해: - “가장 빠른 방법은 PD에 HDFS를 그대로 lift-and-shift” (A). 빠르지만 높은 스토리지 비용을 고착화하고 장기 실행 클러스터를 유도해 비용 목표를 훼손합니다. - “즉시 serverless로 전환” (D). 60일 내에 250개의 Spark/Hive 잡을 재작성하는 것은 리스크가 크고 SLA를 위협합니다. - “지금 모든 것을 BigQuery로 변환” (C). 대규모 테이블 변환과 검증은 시간과 리스크를 증가시키며, 즉시 마이그레이션 전술이 아니라 현대화 단계입니다. 시험 팁: 문항이 촉박한 일정 + 최소 리스크를 강조하면, 기존 코드 경로를 보존하는 관리형 동등 서비스(Dataproc)를 선택하고 가장 큰 비용 요인을 빠르게 최적화(스토리지)하는 선택지를 고르세요. Hadoop 마이그레이션에서 흔한 모범 사례 랜딩 존은 Dataproc + Cloud Storage + 관리형 metastore이며, 이후 serverless 분석으로 점진적으로 전환합니다.

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

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

6
문제 6

You are building a global restaurant reservation microservice on Google Cloud that must handle sudden growth from 50,000 to 20,000,000 daily active users and peak write traffic of 6,000 requests per second while you avoid provisioning or managing database servers; you need a fully managed, automatically scaling operational database with low-latency reads/writes and simple transactional updates on small entity groups— which Google Cloud database service should you choose?

Cloud SQL은 완전 관리형 관계형 데이터베이스(MySQL/PostgreSQL/SQL Server)로 강력한 ACID 트랜잭션과 익숙한 SQL을 제공합니다. 하지만 여전히 인스턴스를 프로비저닝하고 사이징을 관리해야 하며, 수직 확장, 읽기 복제본, 그리고 잠재적으로 샤딩을 통해 확장합니다. 전 세계적으로 매우 높은 쓰기 QPS로의 갑작스러운 성장을 처리하는 것은 복잡할 수 있고 상당한 운영 계획이 필요할 수 있어, 데이터베이스 서버를 관리하지 않으려는 요구사항과 충돌합니다.

BigQuery는 서버리스의 고확장성 분석 데이터 웨어하우스(OLAP)입니다. 대규모 분석 쿼리와 리포팅을 위한 배치/스트리밍 수집에 강점이 있지만, 마이크로서비스를 위한 낮은 지연 시간의 트랜잭션 읽기/쓰기에는 적합하지 않습니다. BigQuery는 예약 업데이트에 필요한 운영 트랜잭션 시맨틱을 제공하지 않으며, 고-QPS 애플리케이션 트래픽의 기본 OLTP 데이터베이스로 사용하도록 의도되지 않았습니다.

Cloud Bigtable은 시계열, IoT, 대규모 키-값 워크로드에 적합한 고확장성, 낮은 지연 시간의 wide-column NoSQL 데이터베이스입니다. 매우 높은 처리량을 처리할 수 있지만 서버리스가 아닙니다. 피크 수요를 충족하기 위해 클러스터/노드를 프로비저닝하고 확장하며, 용량을 관리해야 합니다. 또한 설명된 단순 엔터티-그룹 트랜잭션 모델이 없으므로, 소규모 그룹 ACID 트랜잭션에는 최적의 선택이 아닙니다.

Cloud Datastore (Firestore in Datastore mode)는 애플리케이션 백엔드를 위해 구축된 서버리스, 완전 관리형 NoSQL 문서 데이터베이스입니다. 서버를 프로비저닝하지 않고도 큰 사용자 증가와 높은 쓰기율을 처리하도록 자동으로 확장됩니다. 낮은 지연 시간의 읽기/쓰기를 제공하며 엔터티 그룹 내에서 ACID 트랜잭션을 지원하므로, 작은 엔터티 그룹에 대한 단순 트랜잭션 업데이트 요구사항과 일치합니다. 전 세계 예약 마이크로서비스에 이상적입니다.

문제 분석

핵심 개념: 이 문제는 전 세계적으로 사용되는 마이크로서비스에 적합한 완전 관리형 운영(OLTP) 데이터베이스를 선택하는지를 평가합니다. 요구사항은 자동 확장, 낮은 지연 시간의 읽기/쓰기, 그리고 작은 엔터티 그룹에 대한 단순 트랜잭션으로, 이는 Google Cloud Datastore/Firestore in Datastore mode의 전형적인 요구사항입니다. 정답이 맞는 이유: Cloud Datastore는 웹/모바일 백엔드와 마이크로서비스를 위해 설계된 서버리스, 완전 관리형 NoSQL 문서 데이터베이스입니다. 데이터베이스 서버를 프로비저닝하지 않고도 트래픽 급증(예: 일일 활성 사용자 수가 수백만으로 급증하고 초당 수천 건의 쓰기 발생)에 맞춰 자동으로 확장됩니다. 낮은 지연 시간의 읽기/쓰기를 지원하며, 엔터티 그룹 내 업데이트에 대해 ACID 트랜잭션을 제공하여 “작은 엔터티 그룹에 대한 단순 트랜잭션 업데이트” 요구사항과 일치합니다. 또한 엔터티 조회와 ancestor query에 대해 강한 일관성을 제공하므로, 관련 레코드의 제한된 범위에서 정확성이 필요한 예약(reservation) 스타일 워크로드에 흔히 사용됩니다. 주요 기능 / 모범 사례: - 서버리스 운영: 인스턴스 사이징, 패치, 수동 샤딩이 필요 없습니다. - 처리량과 스토리지의 자동 확장; 스파이크가 있는 워크로드에 맞게 설계되었습니다. - 트랜잭션: 엔터티 그룹 내에서 ACID; 쓰기 경합(핫스팟)을 피하기 위해 엔터티 그룹을 신중히 설계하세요. - 인덱싱: 자동 인덱싱 + 복합 인덱스; 인덱스 쓰기 증폭과 스토리지 비용에 유의하세요. - 글로벌 애플리케이션: 가용성을 높이고 사용자가 체감하는 지연 시간을 줄이기 위해 (Firestore/Datastore 제공 방식에서) 멀티 리전 구성과 함께 자주 사용됩니다. 데이터 레지던시와 지연 시간 요구에 따라 리전/멀티 리전을 선택하세요. 흔한 오해: - Cloud Bigtable도 확장 가능하고 지연 시간이 낮지만, 서버리스가 아니며 일반적으로 용량 계획(노드)이 필요하고, 동일한 단순 엔터티-그룹 트랜잭션 모델을 제공하지 않습니다. - Cloud SQL은 강력한 관계형 트랜잭션을 제공하지만 인스턴스 프로비저닝과 확장 관리가 필요합니다. 신중한 샤딩/읽기 복제본 없이 대규모의 갑작스러운 확장에는 이상적이지 않습니다. - BigQuery는 분석(OLAP)용이며 운영 트랜잭션용이 아닙니다. 시험 팁: “서버 프로비저닝/관리 회피”, “자동 확장”, “낮은 지연 시간의 운영 DB”, “작은 엔터티 그룹에 대한 트랜잭션”을 보면 Datastore/Firestore를 떠올리세요. Bigtable은 관리형 용량을 사용하는 wide-column, 고처리량 시계열/IoT에, Cloud SQL은 인스턴스 관리가 필요한 관계형 OLTP에, BigQuery는 분석 워크로드에 배치하세요.

7
문제 7

You are the data platform lead at a nationwide healthcare network rolling out a virtual assistant for the patient portal using Dialogflow CX. You analyzed 180,000 historical chat transcripts and labeled intents: about 70% of patient requests are routine tasks (e.g., check lab results, reschedule appointment, password reset) that resolve within 10 intents and under 4 turns; the remaining 30% are complex, multi-turn workflows (e.g., prior-authorization appeals, insurance coordination) that average 20–30 turns and frequently need live-agent handoff. Your goal is to reduce live-agent volume by 40% in the first quarter without degrading patient experience. Which intents should you automate first?

정답입니다. 고볼륨의 루틴 intent는 일반적으로 높은 containment와 낮은 리스크로 자동화하기 가장 쉽습니다. 전체 요청의 약 70%를 차지하고 빠르게 해결되므로, 이를 먼저 자동화하면 라이브 에이전트 볼륨을 즉시 가장 크게 줄이고 일관성도 개선합니다. Dialogflow CX에서는 form-filling과 단순한 webhook fulfillment를 갖춘 간단한 flows/pages로 깔끔하게 매핑되어, 1분기 내 빠른 반복 개선과 더 안전한 롤아웃이 가능합니다.

오답입니다. 복잡한 워크플로는 케이스당 에이전트 시간이 더 많이 들 수 있지만, 성공적으로 자동화하기가 더 어렵습니다. turns가 많고, 모호성이 크며, 예외 케이스가 많고, 더 많은 통합(insurance, authorizations, policy rules)이 필요합니다. 초기 실패는 전환(transfer)을 늘리고 환자를 좌절시키며 어시스턴트에 대한 신뢰를 떨어뜨릴 수 있습니다. 이 접근은 전달 리스크가 더 크고, 에이전트 볼륨 40% 감소 같은 단기 KPI를 달성할 가능성이 낮습니다.

오답입니다. 대표적인 mix는 장기적인 제품 균형에는 유용할 수 있지만, 집중도를 떨어뜨리고 time-to-impact를 늦춥니다. 긴/복잡한 intent를 초기에 포함하면 설계, 테스트, 운영 오버헤드가 증가해 나쁜 경험과 더 많은 handoff 가능성이 커집니다. 1분기 목표라면 우선순위는 분포를 그대로 반영하는 것이 아니라 ROI와 실현 가능성(볼륨과 단순성)에 의해 결정되어야 합니다.

오답입니다. keyword 빈도는 intent 자동화 우선순위를 정하는 타당한 기준이 아닙니다. NLU 혼동은 training data 품질, intent 설계, entity 모델링, disambiguation 전략으로 해결해야 하며, keyword가 한 번만 등장하는 intent를 선택한다고 해결되지 않습니다. 또한 “insurance”는 종종 high-stakes의 복잡한 도메인입니다. keyword 휴리스틱으로 이를 회피하는 것은 제시된 KPI나 대화 설계 및 롤아웃 모범 사례와 정렬되지 않습니다.

문제 분석

핵심 개념: 이 문제는 대화 분석(conversational analytics)을 활용해 자동화 우선순위를 정하는 능력을 평가합니다. 즉, 높은 볼륨, 낮은 복잡도, 높은 containment 가능성을 가진 intent를 선택해 빠르게 영향도를 극대화하는 것입니다. Dialogflow CX는 “data processing” 서비스는 아니지만, 여기서의 data-engineering 역량은 라벨링된 transcript 데이터를 활용해 측정 가능한 비즈니스 KPI(라이브 에이전트 볼륨 40% 감소)를 달성하면서 사용자 경험을 보호하는 운영 롤아웃 계획을 수립하는 것입니다. 정답이 맞는 이유: 고볼륨의 루틴 intent(약 70%가 <10 intents 및 <4 turns 내에서 해결)를 먼저 자동화하는 것이 1분기 내 라이브 에이전트 볼륨을 줄이는 가장 빠른 경로입니다. 이러한 intent는 더 짧고, 더 결정적이며, 설계/테스트/모니터링이 더 쉽습니다. 또한 복잡한 보험 워크플로보다 일반적으로 entity extraction(예약 날짜/시간, 환자 식별자, 포털 로그인 플로우)이 더 명확하고 예외 케이스가 적습니다. 요청의 대부분을 차지하므로 containment가 중간 정도만 개선되어도 에이전트 핸드오프의 절대량이 크게 감소해, 환자 경험을 저해하지 않으면서 제시된 목표와 정렬됩니다. 주요 기능 / 모범 사례: Dialogflow CX에서 루틴 intent는 범위가 잘 정의된 flows와 pages(제한된 routes, 강력한 form-filling, 결정적인 fulfillment—대개 scheduling, lab-result, identity 시스템으로의 webhook 호출)로 잘 매핑됩니다. confidence thresholds, fallback routes, 명시적 handoff 트리거 같은 guardrails를 구현할 수 있습니다. 대화 로그와 메트릭(containment rate, fallback rate, 평균 turns, CSAT proxy)을 사용해 반복 개선하세요. Google Cloud Architecture Framework 관점에서 이는 “optimize for business outcomes” 및 “reliability/operations” 의사결정입니다. 즉, 가장 신뢰도 높은 자동화를 먼저 출시한 뒤 확장합니다. 흔한 오해: 복잡한 30%가 에이전트 시간을 더 많이 소모하므로 먼저 자동화하고 싶을 수 있지만, 이는 더 높은 리스크를 동반합니다. 더 많은 turns, 더 큰 모호성, 더 많은 통합, 더 많은 정책/예외 처리(특히 healthcare)가 필요합니다. 이는 실패율을 높이고 환자 경험을 해칠 수 있어, 채택을 저해하고 1분기 KPI를 위태롭게 합니다. 시험 팁: 자동화/ML/NLU 작업의 우선순위를 묻는 경우, 가장 낮은 리스크로 가장 빠르게 측정 가능한 가치를 제공하는 경로를 선택하세요. 높은 빈도, 낮은 변동성, 경계가 명확한 작업입니다. “짧고, 루틴이며, turns가 적음”과 “high volume” 같은 신호를 초기 성과의 지표로 보세요. 긴 워크플로와 예외가 많은 프로세스는 계측(instrumentation)과 운영 성숙도가 확보된 이후 단계로 미루세요.

8
문제 8

At a logistics company, you created a Dataprep recipe on a 5% sample of a BigQuery table that stores daily truck telemetry, and each day a batch load with variable completion time (between 02:10 and 03:50 UTC) appends the new day's data with the same schema; you want the same transformations to run automatically on each daily upload after the load completes—what should you do?

Dataprep은 flows/jobs의 반복 실행을 스케줄링하는 기능을 지원합니다. BigQuery 테이블이 동일한 schema로 매일 append되므로, 동일한 recipe를 매일 자동으로 적용할 수 있습니다. 최신 예상 로드 완료 시간을 고려한 시각(예: 03:50 UTC 이후)에 매일 실행되도록 job을 스케줄링하거나, partition/date filtering을 사용해 올바른 범위를 처리할 수 있습니다. 이는 가장 단순한 managed 접근입니다.

App Engine cron job은 커스텀 오케스트레이션을 도입하며, 추가 로직(작업 상태 polling, retries, backoff)을 넣지 않는 한 BigQuery 로드가 완료되었는지도 보장하지 못합니다. Dataprep의 native scheduling에 비해 운영 부담과 장애 지점을 늘립니다. 서비스(Dataprep)가 이미 반복 배치 실행을 위한 built-in scheduling을 제공하는 경우 App Engine cron은 일반적으로 1순위 선택지가 아닙니다.

Cloud Scheduler는 HTTP endpoint 또는 Pub/Sub를 트리거할 수 있지만, “recipe를 Dataprep template로 export”한 뒤 외부에서 스케줄링하는 것은 이 사용 사례에서 표준적이거나 가장 단순한 Dataprep 자동화 패턴이 아닙니다. API로 실행을 트리거할 수 있더라도 authentication, error handling, 그리고 업스트림 완료 여부를 위한 polling이 필요할 수 있습니다. Native Dataprep scheduling이 더 적절하며 시험 관점에도 부합합니다.

Dataprep job이 직접적이고 표준적인 방식으로 Dataflow template이 되지는 않습니다. Dataflow templates는 Dataprep recipe가 아니라 Apache Beam pipeline을 위한 것입니다. Cloud Composer는 복잡한 DAG 오케스트레이션과 의존성 관리를 위해 강력하지만, 여기서는 과도하며 비용/운영 오버헤드를 추가합니다. 문제가 다단계 워크플로, 시스템 간 의존성, 또는 이벤트 기반 트리거를 요구하지 않는 한 Composer는 최적의 선택이 아닙니다.

문제 분석

핵심 개념: 이 문제는 BigQuery를 소스와 타깃으로 모두 사용하면서 Cloud Dataprep (Trifacta)를 통해 데이터 준비 워크로드를 자동화하는 것, 그리고 업스트림 ingestion 완료 시간이 변동될 때 반복 변환을 신뢰성 있게 스케줄링하는 방법을 평가합니다. 정답이 맞는 이유: Dataprep “flow”는 BigQuery 소스를 대상으로 반복 실행되도록 스케줄링할 수 있습니다. 일일 로드가 동일한 schema로 데이터를 append하므로, 샘플에서 만든 recipe는 전체 데이터셋에도 유효합니다. 시험 관점에서 가장 단순하고 요구사항에 부합하는 접근은 Dataprep에서 BigQuery 테이블을 읽고 변환된 결과를(대개 다른 BigQuery 테이블/partition으로) 쓰는 flow/job에 대해 반복 스케줄을 구성하는 것입니다. 이는 Dataprep에 내장된 managed scheduling 기능을 사용하므로 커스텀 오케스트레이션과 운영 오버헤드를 최소화하고, Google Cloud Architecture Framework 원칙(운영 우수성, 신뢰성, 단순성)에 부합합니다. 주요 기능 / 모범 사례: - Dataprep Flow scheduling(반복)을 사용해 동일한 recipe를 매일 실행합니다. - job이 BigQuery 테이블(또는 이상적으로 date-partitioned table)을 가리키도록 하여 각 실행이 의도한 날짜의 데이터를 처리하게 합니다. - 지연 도착 데이터(late-arriving data)가 가능하다면, 버퍼를 두고(예: 04:00 UTC 이후) 스케줄링하거나 partition/date filter로 처리하여 부분 읽기(partial reads)를 피합니다. - 가능하면 커스텀 cron보다 managed scheduling을 선호하여 구성 요소와 장애 지점을 줄입니다. 흔한 오해: - “완료 시간이 변동되면 외부 트리거가 필요하다.” 반드시 그렇지는 않습니다. 배치 파이프라인에서는 적절한 시간 버퍼를 둔 반복 스케줄만으로도 보통 충분합니다. 이벤트 기반 오케스트레이션이 유용할 수는 있지만, 이 문제는 무엇을 해야 하는지를 묻고 있으며 가장 직접적으로 지원되는 기능은 Dataprep scheduling입니다. - “스케줄링하려면 template export가 필요하다.” Dataprep은 이미 scheduling을 지원하며, export는 복잡도만 증가시킵니다. 시험 팁: - Professional Data Engineer에서는 요구사항을 만족하는 가장 managed되고 커스텀이 가장 적은 솔루션을 선택합니다. - 변환 도구가 native scheduling을 제공한다면, 명시적인 의존성, SLA, 또는 복잡한 다단계 워크플로가 없는 한 App Engine cron이나 Composer보다 보통 우선됩니다. - 문구를 주의하세요: “로드가 완료된 후”는 문제가 이벤트 기반 트리거를 명시적으로 요구하지 않는 한, 최신 예상 완료 시간 이후로 스케줄링하는 것으로 충족되는 경우가 많습니다.

9
문제 9

A logistics company streams shipment scan events in a compact JSON schema from 1,200 handheld devices (about 50,000 events per minute) into a Pub/Sub topic; a Dataflow streaming pipeline reads from a subscription, applies fixed 1-minute windows and aggregations, and feeds an operations dashboard that should reflect every scan in real time; during a 2-hour pilot, the dashboard intermittently shows 3–5% fewer scans than expected, while producer logs show all HTTP publish calls succeeding and Cloud Monitoring for the topic reports 0% publish errors with median publish latency under 100 ms. What should you do next to isolate the issue?

dashboard 계층을 확인하는 것은 도움이 될 수 있지만, 파이프라인 출력이 실제로 누락인지 아직 입증하지 못했기 때문에 다음 단계로는 최선이 아닙니다. 스트리밍 시스템에서 겉보기 “손실”은 종종 렌더링 문제가 아니라 windowing/late data 또는 집계 타이밍 때문입니다. 먼저 파이프라인 전반에서 카운트를 검증해 불일치를 분리한 뒤, 출력이 기대와 일치한다면 visualization tier의 caching/refresh 로직을 조사하세요.

고정되고 알려진 데이터셋을 replay하고 각 Dataflow transform에서 카운트를 비교하는 것은 불일치가 어디에서 발생하는지 분리해내는 가장 직접적인 방법입니다. 이는 Pub/Sub ingestion 문제를 Dataflow의 windowing/trigger/late-data 동작 및 sink/dashboard 문제와 구분하는 데 도움이 됩니다. 이 접근은 모범 사례(파이프라인 계측, event-time assignment 검증, 통제된 조건에서 window 출력이 기대 카운트와 일치하는지 확인)와 일치합니다.

Cloud Monitoring은 publish/ack rate, backlog, latency를 보여줄 수 있지만, publish가 성공했을 때 복구를 위해 특정 “누락 메시지”를 정확히 찾아내지는 못합니다. Pub/Sub는 at-least-once이며, 엔드투엔드로 처리되지 않은 개별 메시지를 열거하는 내장 메커니즘을 제공하지 않습니다. 메시지가 다운스트림에서 drop되었다면(예: late data/windowing), Pub/Sub metrics만으로는 어떤 메시지를 복구해야 하는지 직접적으로 드러나지 않습니다.

push subscription으로 전환하는 것은 적절한 해결책이나 분리 단계가 아닙니다. Dataflow의 Pub/Sub source connector는 pull subscription을 위해 설계되었고, push delivery는 HTTPS endpoint를 대상으로 하며 Dataflow에 대한 신뢰성을 본질적으로 개선하지 않습니다. 관측된 증상(스캔이 3–5% 적음)은 pull vs push 전달 모델보다는 event-time/windowing/triggering 또는 다운스트림 집계/표시 동작과 더 일치합니다.

문제 분석

핵심 개념: 이 문제는 프로듀서가 정상으로 보이는 스트리밍 수집 파이프라인(Pub/Sub -> Dataflow -> dashboard)에서 엔드투엔드 정확성과 트러블슈팅을 평가합니다. 핵심은 각 단계에서 카운트를 계측하고 검증하여 데이터 손실인지, 지연 데이터/윈도잉 효과인지, 또는 다운스트림 표시 문제인지 분리해내는 것입니다. 정답이 맞는 이유: Pub/Sub에서 publish error가 0%이고 publish latency도 낮게 보이므로, 다음 단계는 불일치가 어디에서 발생하는지(ingestion, Dataflow 처리(windowing/triggers/late data), sink, 또는 dashboard) 확인하는 것입니다. 이를 분리하는 가장 신뢰할 수 있는 방법은 고정되고 알려진 데이터셋을 replay하고 각 transform에서 카운트를 비교하는 것입니다(예: 읽은 메시지 수, 파싱된 수, window에 할당된 수, 집계된 수, 기록된 수). 이렇게 하면 라이브 디바이스 동작, 타이밍 스큐, 재시도, dashboard refresh 동작에서 오는 불확실성을 제거할 수 있습니다. Dataflow에서 3–5% “누락”은 종종 event-time windowing과 기본 triggers/allowed lateness 설정에서 비롯됩니다. window가 닫힌 뒤 도착한 이벤트는 drop되거나 dashboard가 읽지 않는 late pane으로 출력될 수 있습니다. 통제된 replay를 통해 event-time과 processing-time 동작을 검증하고 late data 처리가 올바르게 구성되었는지 확인할 수 있습니다. 주요 기능 / 모범 사례: Dataflow metrics(element counts, watermark, system lag)를 사용하고, transform에 명시적 counter/logging을 추가하세요. timestamp assignment(Pub/Sub publish time vs JSON의 event time), windowing(고정 1-minute), triggers(기본값 vs early/late firings), allowed lateness를 검증합니다. 또한 exactly-once semantics를 고려하세요: Pub/Sub는 at-least-once delivery를 제공하며, Dataflow는 idempotency/dedup keys를 구현한 경우에만 deduplicate할 수 있습니다. subscription ack deadline/throughput도 확인하되, 통제된 replay가 주로 불일치가 시작되는 단계를 정확히 찾아냅니다. 흔한 오해: 증상이 “dashboard에서 누락”이기 때문에 dashboard(A)를 탓하기 쉽지만, 먼저 파이프라인 출력 자체가 실제로 누락인지 아니면 다르게 표시되는 것인지 입증해야 합니다. 선택지 C는 Pub/Sub가 “누락 메시지”를 식별/복구할 수 있다고 가정하지만, Pub/Sub는 Monitoring에서 메시지 단위 gap detection을 제공하지 않으며 publish가 성공했다면 문제는 다운스트림일 가능성이 큽니다. 선택지 D(push subscription)는 해당되지 않습니다. Dataflow의 Pub/Sub IO는 pull 기반이며, push가 본질적으로 정확성을 개선하지 않습니다. 시험 팁: 스트리밍 불일치가 발생하면, 먼저 알려진 데이터셋으로 감사 가능한 기준선을 만들고 각 경계(topic/subscription, Dataflow read, transforms, sink)에서 카운트를 측정하세요. event-time windowing, watermarks, triggers, allowed lateness에 특히 주의하세요. 이는 실시간 dashboard에서 “누락” 데이터의 빈번한 원인입니다.

10
문제 10

You are building a healthcare analytics warehouse in BigQuery that stores 80 million lab-result rows and PII for 600,000 patients across 12 tables. Compliance requires per-patient cryptographic deletion so that, upon an erasure request, only that patient’s sensitive columns become permanently undecipherable by removing their key material—without exporting data, rewriting other rows, or changing the storage location. You must rely on native Google Cloud capabilities (no custom cryptographic libraries or client-side encryption) and allow authorized analysts to decrypt data at query time using SQL; what should you implement?

정답입니다. BigQuery AEAD 함수는 BigQuery에서 SQL 기반 컬럼 암호화/복호화를 가능하게 합니다. Cloud KMS로 랩핑된 keyset과 환자별 키를 사용하면, 각 환자의 PII 컬럼이 해당 환자의 키로 암호화되는 envelope encryption을 구현할 수 있습니다. Crypto-deletion은 해당 환자의 키 자료만 삭제/파기함으로써 달성되며, 다른 행을 다시 쓰거나 데이터를 이동/내보내지 않고도 그 환자의 ciphertext를 영구적으로 복호화 불가능하게 만듭니다.

오답입니다. BigQuery CMEK는 단일 customer-managed key(또는 소수의 키 집합)로 전체 데이터셋/테이블을 at rest에서 암호화합니다. CMEK를 비활성화/파기하면 특정 환자의 컬럼만이 아니라 보호되는 리소스의 모든 데이터에 대한 접근을 잃게 됩니다. CMEK는 행/환자별 암호학적 삭제를 제공하지 않으며, 컬럼 수준에서 선택적으로 복호화 불가능하게 만드는 것을 지원하지 않습니다.

오답입니다. Cloud KMS는 envelope encryption에 사용할 수 있지만, “로드 전에 레코드를 암호화하기 위해 CMEK 사용”은 레코드별 암호화를 위한 네이티브 BigQuery 기능이 아닙니다. CMEK는 레코드 단위 암호화 메커니즘으로 사용되는 것이 아니라 BigQuery 스토리지 리소스에 적용됩니다. 또한 요구사항에는 SQL을 사용해 쿼리 시점에 복호화하는 것이 포함되어 있는데, 이는 일반적인 사전 로드 암호화 접근보다 AEAD 함수에 부합합니다.

오답입니다. 이는 ETL 파이프라인에서 커스텀 암호 라이브러리(클라이언트 측 암호화)에 의존하며, 프롬프트가 명시적으로 금지합니다. 개념적으로 crypto-deletion을 만족할 수 있더라도 “네이티브 Google Cloud 기능”이 아니며, BigQuery의 내장 AEAD 함수를 사용하지 않고 BigQuery 내부에서 SQL 기반 복호화를 수행하기 어렵게 만들어 키 관리, 접근 제어를 복잡하게 합니다.

문제 분석

핵심 개념: 이 문제는 암호학적 삭제(crypto-shredding)를 가능하게 하기 위해, 행/엔터티(환자)별 키를 사용하는 BigQuery 네이티브 컬럼 수준 암호화를 테스트합니다. 요구사항은 다른 행을 다시 쓰거나, 데이터를 내보내거나, 데이터 저장 위치를 변경하지 않고도 키 자료를 삭제함으로써 오직 한 환자의 민감 필드만 영구적으로 복호화 불가능하게 만드는 것입니다. 정답이 맞는 이유: BigQuery AEAD 함수(예: AEAD.ENCRYPT/AEAD.DECRYPT)는 SQL을 사용해 BigQuery 내부에서 애플리케이션 계층 암호화를 지원합니다. AEAD keyset이 Cloud KMS로 보호(랩핑)되면, BigQuery에 ciphertext를 저장하고 권한 있는 사용자에 대해 쿼리 시점에 복호화할 수 있습니다. 환자별로 서로 다른 키(또는 keyset)를 유지하고 해당 키로 그 환자의 PII 컬럼을 암호화하면, 환자별 crypto-deletion을 달성합니다. 삭제(erase) 시 해당 환자의 키 자료(또는 wrapped keyset)를 파기/비활성화/제거하여, 다른 모든 행은 그대로 둔 채 그 환자의 암호화된 컬럼만 복구 불가능하게 만들 수 있습니다. 주요 기능 / 구성: - BigQuery AEAD 함수를 사용해 민감 컬럼(PII)만 암호화하고, 성능을 위해 비민감 분석 컬럼은 plaintext로 유지합니다. - 환자별 wrapped keyset(또는 키 참조)을 보안 테이블에 저장하고, Cloud KMS를 통해 wrap/unwrap 합니다. IAM으로 접근을 제어하여 승인된 역할만 unwrap/decrypt 할 수 있게 합니다. - authorized views, column-level security 및/또는 dynamic data masking 패턴을 사용해 분석가가 허용된 경우에만 복호화할 수 있도록 보장합니다. - Crypto-deletion은 BigQuery 스토리지를 다시 쓰는 것이 아니라 환자별 키 자료를 파기(또는 wrapped keyset 삭제)함으로써 구현합니다. 흔한 오해: 데이터셋/테이블 수준의 CMEK(옵션 B)는 종종 레코드 단위 삭제로 오해됩니다. CMEK는 저장 시(at rest) 보호를 제공하지만 범위가 거칩니다. 키를 파기하면 단일 환자가 아니라 전체 테이블/데이터셋을 읽을 수 없게 됩니다. 옵션 C/D는 “로드 전에 암호화”와 유사하지만, C는 레코드 수준 암호화를 위한 네이티브 BigQuery 기능이 아니며 D는 “커스텀 암호 라이브러리/클라이언트 측 암호화 금지” 제약을 위반합니다. 시험 팁: - 데이터 재작성 없이 사용자/엔터티별 crypto-deletion이 요구되면, 엔터티별 키와 엔진 내 암호화/복호화 함수를 사용하는 envelope encryption 패턴을 찾으세요. - CMEK 답은 전체 리소스에 대한 at-rest 암호화를 고객이 제어하는 것이 목표일 때는 맞지만, 선택적 삭제에는 해당하지 않습니다. - “네이티브 기능”, “SQL로 쿼리 시점 복호화” 같은 제약에 주의하세요. 이는 BigQuery AEAD 함수와 KMS 통합을 강하게 시사합니다. - 운영상 한계도 고려하세요. 600k 키 관리는 자동화와 신중한 IAM/쿼터 계획이 필요하지만, 설명된 컴플라이언스 동작을 만족하는 유일한 옵션입니다.

합격 후기(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 #1

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

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

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

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

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

앱 받기

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