CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
  1. Cloud Pass
  2. GCP
  3. Google Associate Data Practitioner
Google Associate Data Practitioner

GCP

Google Associate Data Practitioner

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

Free questions & answers실제 시험 기출 문제
AI-powered explanations상세 해설
Real exam-style questions실제 시험과 가장 유사
90+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

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

시험 도메인

Data Preparation and Ingestion출제율 30%
Data Analysis and Presentation출제율 27%
Data Pipeline Orchestration출제율 18%
Data Management출제율 25%

실전 문제

1
문제 1

A global sportswear retailer is standardizing on BigQuery for analytics and needs a fully managed way to run a nightly batch ETL at 02:00 UTC that pulls 50 tables (~12 TB total) from mixed sources (Cloud SQL, an SFTP server, and a partner REST API), triggers transformations across multiple Google Cloud services, and then loads curated datasets into BigQuery. Your engineering team (8 developers) is strongest in Python and wants to write maintainable code, use pre-built connectors/operators for Google services, set task dependencies with retries/alerts, and avoid managing servers. Which tool should you recommend to orchestrate these batch ETL workflows while leveraging the team’s Python skills?

Dataform은 주로 BigQuery(및 관련 SQL 워크플로) 내부에서 SQL 기반 변환, 테스트(assertions), 의존성 관리를 위한 도구입니다. SFTP나 파트너 REST APIs 같은 혼합된 외부 소스에서의 엔드투엔드 수집을 기본적으로 오케스트레이션하지 않으며, 여러 Google Cloud 서비스를 재시도/알림이 있는 task로 조정하도록 설계된 것도 아닙니다. orchestrator를 보완할 수는 있지만, 여기서 메인 워크플로 orchestrator로는 최적의 선택이 아닙니다.

Cloud Data Fusion은 시각적 UI와 다양한 connector/plugin을 갖춘 완전 관리형 ETL/ELT 서비스로, 소스에서 수집해 BigQuery로 로드할 수 있습니다. 하지만 유지보수 가능한 Python 코드를 작성하고 operator 기반 오케스트레이션 패턴을 사용하려는 팀의 요구와는 덜 부합합니다. Data Fusion도 파이프라인 스케줄링은 가능하지만, 문제는 Python 역량, task 의존성, 여러 Google 서비스 오케스트레이션을 강조하므로 Airflow/Composer가 더 강하게 부합합니다.

Cloud Composer(관리형 Apache Airflow)는 복잡한 의존성, 재시도, 알림을 갖는 야간 배치 ETL을 오케스트레이션하면서 서버 관리를 피해야 하는 요구에 가장 잘 맞습니다. Python DAG를 사용하므로(Python에 강한 팀에 이상적) 사전 구축된 Google Cloud operator/hook이 많고, 외부 시스템(SFTP, REST APIs) 호출도 가능합니다. Composer는 수집을 조정하고 서비스 전반의 변환을 트리거한 뒤, 정제된 결과를 BigQuery로 로드합니다.

Dataflow는 대규모 배치 및 스트리밍 데이터 처리를 위한 완전 관리형 서비스이며, template을 통해 일반적인 패턴을 빠르게 적용할 수 있습니다. 하지만 Dataflow는 범용 워크플로 orchestrator가 아닙니다. Cloud SQL 추출, SFTP pull, REST API 호출, 여러 다운스트림 Google 서비스 트리거를 재시도/알림과 함께 자연스럽게 다단계 의존성으로 관리하지는 못합니다. 이 시나리오에서 Dataflow는 Cloud Composer 같은 orchestrator가 호출하는 처리 단계가 되는 것이 적절합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서의 배치 파이프라인 오케스트레이션을 평가합니다. 구체적으로, 워크플로를 스케줄링하고 작업 의존성, 재시도, 알림을 관리하며, 사전 구축된 operator를 통해 다양한 서비스와 통합되는 완전 관리형 orchestrator를 선택하되, Python에 강한 팀이 유지보수 가능한 코드를 작성할 수 있어야 합니다. 정답이 맞는 이유: Cloud Composer(관리형 Apache Airflow)는 이기종 시스템 전반에 걸친 다단계 ETL/ELT 워크플로를 오케스트레이션하도록 목적에 맞게 설계되었습니다. 시간 기반 스케줄링(예: 매일 02:00 UTC), DAG 기반 의존성, 재시도, SLA, 알림/notification을 기본적으로 지원합니다. 또한 Google Cloud operator/hook 생태계(BigQuery, Cloud SQL, GCS, Dataflow, Dataproc, Pub/Sub, Secret Manager 등)가 매우 풍부하며, Python 라이브러리/operator를 사용해 외부 시스템(SFTP, REST APIs)도 호출할 수 있습니다. 이는 “여러 Google Cloud 서비스에 걸쳐 변환을 트리거”하고 “서버 관리를 피하면서” Python 역량을 활용하라는 요구사항과 일치합니다. 주요 기능 / 모범 사례: - 유지보수 가능하고 버전 관리되는 워크플로를 위해 Python으로 Airflow DAG를 사용합니다. - 내장 GCP operator(예: BigQueryInsertJobOperator, CloudSQL operator, Dataflow operator)와 SFTP/REST용 custom operator를 사용합니다. - Secret Manager에 credential을 저장하고, Airflow에서 connection을 사용하며, 최소 권한 IAM을 적용합니다. - 재시도, exponential backoff, task 단위 timeout, SLA를 구성하고, email/Chat/Cloud Monitoring을 통해 알림을 통합합니다. - 매일 밤 12 TB 로드의 경우, 병렬성(task concurrency)을 신중히 오케스트레이션하고, Composer worker에서 처리하기보다 확장 가능한 서비스(BigQuery SQL, Dataflow)로 무거운 변환을 오프로딩합니다. 흔한 오해: Dataflow는 데이터 처리에는 뛰어나지만, 복잡한 의존성과 외부 시스템 조정이 필요한 다중 서비스 워크플로를 위한 orchestrator가 주 목적은 아닙니다. Data Fusion은 관리형 ETL UI를 제공하지만, 팀은 명시적으로 Python 중심의 유지보수 가능한 코드와 operator 기반 오케스트레이션을 원합니다. Dataform은 BigQuery에서의 SQL 기반 변환에 초점이 있으며, SFTP/REST/Cloud SQL에서의 엔드투엔드 수집과 교차 서비스 오케스트레이션에는 적합하지 않습니다. 시험 팁: “스케줄 + 의존성 + 재시도/알림 + 다양한 서비스 + Python DAGs”를 보면 Cloud Composer/Airflow를 떠올리세요. “분산 처리/스트리밍 변환”을 보면 Dataflow를 떠올리세요. “BigQuery SQL 변환 관리”를 보면 Dataform을 떠올리세요. “커넥터가 있는 GUI ETL”을 보면 Data Fusion을 떠올리세요.

2
문제 2

At a multinational retailer, you maintain a BigQuery dataset ret_prod.sales_tx in project ret-prod that stores tokenized credit card transactions, and you must ensure that only the 8-person Risk-Analytics Google Group (risk-analytics@retail.example) can run SELECT queries on the tables while preventing the other 120 employees in the organization from querying them and adhering to the principle of least privilege; what should you do?

정답입니다. 최소 권한 설계는 Risk-Analytics Google Group에 특정 BigQuery dataset에 대해서만 read access를 부여하는 것입니다. 예를 들어 ret_prod.sales_tx에 roles/bigquery.dataViewer를 부여하면 해당 group은 table을 읽을 수 있지만 다른 사용자는 읽을 수 없습니다. 실제로 SELECT query를 실행하려면 이 group에는 query job을 생성할 수 있는 permission도 필요하며, 일반적으로 project ret-prod에 대한 roles/bigquery.jobUser를 통해 부여합니다. 이는 해당 role이 dataset 수준에서는 부여되지 않기 때문입니다. 이 조합은 의도된 8명의 사용자로 access를 제한하고, project 전체에 걸친 광범위한 data permission을 피하며, 표준 BigQuery IAM 설계와도 일치합니다.

오답입니다. CMEK는 Cloud KMS를 통해 암호화 키를 제어하고(예: 키 로테이션, 키 비활성화) 추가 통제를 제공할 수 있지만, 그 자체만으로 어떤 principal이 BigQuery 테이블을 쿼리할 수 있는지를 제한하지는 않습니다. 데이터셋을 읽고/쿼리할 수 있는지는 여전히 IAM 권한이 결정합니다. CMEK는 방어 심화(defense-in-depth) 수단이지 접근 제어의 대체재가 아닙니다.

이 시험 시나리오에서는 오답입니다. BigQuery는 특정 세밀한 권한에 대해 SQL GRANT/REVOKE를 지원하지만, BigQuery에서 데이터셋/테이블 접근을 제어하는 표준이자 기본 메커니즘은 IAM이며 시험도 일반적으로 이를 목표로 합니다. 또한 GRANT 여부와 관계없이, SELECT 문을 실행하려면 쿼리 job을 생성할 권한이 필요합니다.

오답입니다. 민감한 거래 테이블을 Cloud Storage로 내보내면 데이터 중복과 거버넌스 위험(data sprawl)이 발생하고 운영 오버헤드가 증가하며, 요구사항을 충족하는 데 필요하지 않습니다. Signed URL은 객체 접근을 제어하지만, BigQuery의 중앙화된 접근 모델과 쿼리 활동에 대한 감사(auditing)를 우회하게 되며, 최소 권한 기반의 BigQuery 쿼리 방식과도 부합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 적절한 리소스 범위에서 최소 권한 IAM을 사용하여 BigQuery query access를 제한하는 방법을 테스트합니다. BigQuery에서 SELECT query를 실행하려면 사용자는 dataset table을 읽을 수 있는 권한과 query job을 생성할 수 있는 권한이 모두 필요합니다. 정답인 이유: 올바른 접근 방식은 Risk-Analytics Google Group에 필요한 최소 IAM role만 부여하는 것입니다. 즉, 특정 dataset에 대한 data-reading role(예: ret_prod.sales_tx에 대한 roles/bigquery.dataViewer)과 허용된 상위 범위에서의 job-creation role(일반적으로 project ret-prod에 대한 roles/bigquery.jobUser)을 부여합니다. 이렇게 하면 8명으로 구성된 group만 민감한 tokenized transaction data를 query할 수 있고, 나머지 120명의 직원에게는 access가 부여되지 않습니다. 또한 Google Group을 사용하면 관리와 auditing이 더 간단해집니다. 주요 기능 / 모범 사례: - 데이터 access 범위는 가능한 한 좁게 지정하고, 특히 민감한 데이터의 경우 dataset 또는 table 수준을 선호합니다. - 사용자가 query를 실행하려면 table read permission과 bigquery.jobs.create permission이 모두 필요합니다. - roles/bigquery.dataViewer는 dataset 수준에서 적절하며, roles/bigquery.jobUser는 dataset 수준이 아니라 project, folder 또는 organization 수준에서 부여해야 합니다. - Google Groups를 사용하여 membership을 중앙에서 관리하고 IAM 유지 관리 오버헤드를 줄이세요. 일반적인 오해: - CMEK는 encryption key를 보호하지만 누가 데이터를 query할 수 있는지는 결정하지 않습니다. access는 여전히 IAM이 제어합니다. - SQL GRANT/REVOKE는 BigQuery에서 사용할 수 있지만, dataset access 시나리오에서 테스트되는 기본 access-control 모델은 여전히 IAM이며, SQL grant를 사용해도 job creation permission의 필요성이 없어지지는 않습니다. - 데이터를 Cloud Storage로 export하는 것은 BigQuery dataset에 대한 access-control solution이 아니며 data sprawl 위험을 증가시킵니다. 시험 팁: 문제에서 BigQuery에서 누가 SELECT를 실행할 수 있는지 묻는다면 두 부분으로 생각하세요: data access와 job execution입니다. 데이터 읽기에는 가장 좁은 리소스 범위를 선택하고, query job creation은 project와 같은 더 높은 범위에서 부여된다는 점을 기억하세요. 요구 사항이 최소 권한을 강조할 때는 project 전체에 걸친 광범위한 data role을 피하세요.

3
문제 3

You work for a video-streaming platform. An existing Bash/Python ETL script on a Compute Engine VM aggregates ~120,000 playback events each day from a legacy NFS share, transforms them, and loads the results into BigQuery. The script is run manually today; you must automate a 02:00 UTC daily trigger and add centralized monitoring with run history, task-level logs, and retry visibility for troubleshooting. You want a single, managed solution that uses open-source tooling for orchestration and does not require rewriting the ETL code. What should you do?

Cloud Run jobs는(대개 Cloud Scheduler를 통해) 스케줄링 및 모니터링할 수 있지만, 이는 오픈 소스 오케스트레이션 솔루션이 아니며 여러 단계에 걸친 Airflow 스타일의 작업 수준 실행 이력, 의존성 관리, 재시도 가시성을 본질적으로 제공하지 않습니다. 또한 일반적으로 스크립트를 컨테이너화해야 하고 NFS 데이터 소스에 대한 접근을 보장해야 하므로 추가적인 재작업과 네트워킹 복잡성이 생길 수 있습니다.

Dataflow는 Apache Beam 파이프라인을 위한 managed 서비스이며 확장 가능하고 병렬적인 ETL에 이상적입니다. 하지만 일반적으로 기존 Bash/Python ETL을 Beam 파이프라인으로 재작성(또는 최소한 상당한 리팩터링)해야 합니다. Dataflow는 job monitoring을 제공하지만, ETL 코드를 재작성하지 않고 오픈 소스 오케스트레이션 도구로 DAG/task 수준의 재시도 가시성을 요구하는 조건과는 맞지 않습니다.

Dataproc은 managed Hadoop/Spark 클러스터에서 스크립트를 실행할 수 있고 Cloud Scheduler로 트리거할 수 있지만, 주된 목적이 오케스트레이션 플랫폼은 아닙니다. 다른 orchestrator를 추가하지 않는 한 작업 수준 로그와 재시도를 포함한 통합 DAG 뷰가 여전히 부족합니다. 또한 Dataproc은 클러스터 관리 고려사항(startup time, costs, autoscaling, ephemeral clusters)을 도입하는데, 단순한 일일 스크립트에는 불필요합니다.

Cloud Composer는 Google의 managed Apache Airflow 서비스(오픈 소스)이며 오케스트레이션 요구사항을 직접 충족합니다: 매일 02:00 UTC 스케줄, 중앙집중식 실행 이력, 작업별 로그, 그리고 Airflow UI에서 명확히 보이는 구성 가능한 재시도. ETL 로직을 재작성하지 않고도 기존 스크립트(예: Compute Engine VM으로 SSHOperator를 사용)를 오케스트레이션할 수 있으며, Cloud Logging/Monitoring과 통합해 중앙집중식 observability를 제공합니다.

문제 분석

핵심 개념: 이 문제는 오픈 소스 도구를 사용해 기존 ETL 코드를 위한 managed orchestration과 운영 가시성(실행 이력, 작업 로그, 재시도)을 테스트합니다. Google Cloud에서 managed Apache Airflow 제공 서비스는 Cloud Composer입니다. 정답이 맞는 이유: Cloud Composer는 Apache Airflow(오픈 소스)를 사용해 워크플로를 DAG로 스케줄링하고 오케스트레이션하는 단일 managed 솔루션을 제공합니다. 기존 Bash/Python 스크립트를 유지한 채 ETL 로직을 재작성하지 않고도 SSHOperator(기존 Compute Engine VM에서 실행), BashOperator(환경에서 스크립트에 접근 가능할 때), 또는 KubernetesPodOperator(추후 컨테이너화하는 경우) 같은 operator로 호출하여 오케스트레이션할 수 있습니다. Airflow는 기본적으로 실행 이력, 작업별 로그, 재시도 설정, 실패에 대한 가시성을 제공하므로 모니터링 및 트러블슈팅 요구사항과 직접적으로 일치합니다. 주요 기능 / 구성 / 모범 사례: - 스케줄링: DAG 스케줄을 02:00 UTC(cron expression)로 설정하고 catchup 동작을 적절히 활성화/비활성화합니다. - Observability: Airflow UI에서 DAG runs, task instances, retries, durations, logs를 확인할 수 있으며, Cloud Logging/Monitoring과 통합해 중앙집중식 알림(예: DAG failure, SLA misses에 대한 알림)을 구성합니다. - 신뢰성: task retries, retry delays, timeouts, idempotency safeguards를 구성합니다(특히 BigQuery로 로드할 때 중요). - 보안: 최소 권한 원칙의 service accounts, 자격 증명은 Secret Manager 사용, 필요 시 private IP Composer를 사용합니다. Google Cloud Architecture Framework의 pillars인 operational excellence(표준화된 운영), reliability(재시도/모니터링), security와 정렬됩니다. 흔한 오해: Cloud Scheduler + “무언가”로 작업을 트리거할 수는 있지만, Scheduler만으로는 작업 수준 오케스트레이션, 실행 이력, 재시도 가시성을 제공하지 못합니다. Dataflow는 확장 가능한 파이프라인에 매우 적합하지만 일반적으로 Beam으로 재작성해야 합니다. Dataproc은 스크립트를 실행할 수 있지만 오케스트레이션 도구가 아니며 클러스터 라이프사이클 복잡성을 추가합니다. 시험 팁: “open-source orchestration,” “DAG,” “run history,” “task logs,” “retries”를 보면 Apache Airflow/Cloud Composer를 떠올리세요. 기존 코드를 최소한의 리팩터링으로 오케스트레이션해야 하고 풍부한 운영 UI 및 트러블슈팅 기능이 필요할 때는 Composer를 우선 고려합니다.

4
문제 4

A gaming analytics startup collects in-app telemetry from 2 million daily active users across 6 Google Cloud regions (us-central1, europe-west1, asia-east1, australia-southeast1, southamerica-east1, us-east4), producing approximately 120,000 JSON events per minute. You must deliver dashboards in BigQuery with near real-time freshness (under 90 seconds end-to-end). Before loading, each event must be cleaned (drop null fields), enriched with a region_code derived from the producing region, and flattened from nested JSON into a columnar schema. To accelerate delivery and enable future maintainability, the pipeline must be built using a visual, low-code interface. What should you do?

Pub/Sub는 분산된 producer로부터 높은 볼륨의 telemetry stream을 낮은 지연과 내구성 있는 delivery semantics로 ingest하는 데 매우 적합합니다. Dataflow는 streaming ETL을 위해 설계된 관리형 Google Cloud 서비스이므로, JSON을 parse하고, 불필요한 field를 제거하고, region_code와 같은 파생 값을 record에 추가하며, nested data를 BigQuery에 적합한 schema로 재구성한 뒤 load할 수 있습니다. 제시된 옵션 중에서 이것만이 필요한 transformation을 지원하면서도 제시된 규모에서 거의 실시간 freshness 목표를 현실적으로 충족할 수 있습니다. 또한 scaling, checkpointing, streaming execution이 플랫폼에 의해 처리되므로 custom subscriber service를 직접 구축하고 운영하는 것보다 유지보수성이 더 높습니다.

Cloud Run은 Pub/Sub message를 수신하고 custom transformation logic을 실행할 수 있지만, 이 접근 방식은 관리형 data processing pipeline을 사용하는 대신 application code를 작성하고 유지해야 합니다. 분당 120,000 event 규모에서는 운영 문제와 불안정한 처리량을 피하기 위해 concurrency, retry, idempotency, batching, BigQuery write 동작을 매우 신중하게 관리해야 합니다. 또한 transformation logic이 custom service code 안에 있기 때문에, 시각적이고 low-code인 접근 방식을 선호한다는 요구사항도 충족하지 못합니다. 기술적으로는 가능하지만, Dataflow와 같은 관리형 streaming ETL 서비스보다 요구사항에 덜 부합합니다.

Pub/Sub의 BigQuery subscription은 message를 거의 또는 전혀 transformation 없이 table에 직접 write할 수 있을 때 유용합니다. 이 시나리오에서는 load 전에 event를 정리하고, 파생된 region_code를 추가하고, nested JSON을 columnar schema로 평탄화해야 하는데, 이 direct 경로는 이를 제공하지 않습니다. transformation 단계가 필수이므로, 지연 목표를 충족할 수 있더라도 direct Pub/Sub-to-BigQuery ingestion만으로는 충분하지 않습니다. 따라서 이 옵션은 필요한 preprocessing을 수행하기에는 너무 제한적입니다.

Event를 Cloud Storage에 write한 다음 external table을 통해 query하는 방식은 근본적으로 거의 실시간 streaming 설계라기보다 batch 지향 analytics 패턴입니다. 예약된 일일 BigQuery transformation job은 end-to-end 90초 미만이라는 요구 freshness 목표에서 한참 벗어나므로, 즉시 핵심 SLA를 충족하지 못합니다. 또한 external table은 데이터를 object storage에 그대로 두며, transform되고 query에 최적화된 BigQuery table에 의존하는 지속적으로 새로고침되는 operational dashboard에는 가장 적합한 방식이 아닙니다. 따라서 이 옵션은 지연과 아키텍처 적합성 모두에서 잘못되었습니다.

문제 분석

핵심 개념: 이 문제는 관리형 streaming 서비스와 함께 BigQuery로의 거의 실시간 ingestion 및 transformation pipeline을 설계하는 능력을 평가하며, 시각적/low-code 빌드 경험이 명시적으로 요구됩니다. 핵심 서비스는 전역 event ingestion을 위한 Pub/Sub와 BigQuery로의 streaming ETL/ELT를 위한 Dataflow(Dataflow Studio 사용)입니다. 정답인 이유: Option A는 모든 제약 조건을 가장 잘 충족합니다: (1) Pub/Sub는 여러 region에서 높은 처리량의 telemetry를 낮은 지연으로 ingest할 수 있고, (2) Dataflow streaming pipeline은 전송 중인 event를 transform할 수 있으며(null field 제거, region_code 추가, nested JSON 평탄화), (3) Dataflow Studio는 시각적이고 low-code인 인터페이스를 제공하여 전달 속도를 높이고 유지보수성을 향상시킵니다. Dataflow의 streaming-to-BigQuery 패턴은 sub-minute에서 약 1분 수준의 freshness를 위해 설계되었으며, 적절한 windowing, autoscaling, BigQuery write 설정을 사용하면 120,000 events/min에서 end-to-end 90초 미만 달성이 현실적입니다. 주요 기능 / 구성 / 모범 사례: - Pub/Sub topic(보통 하나의 global topic 또는 region별 topic)을 사용하고 producing region과 같은 attribute를 포함합니다. Dataflow는 이를 region_code로 매핑할 수 있습니다. - Dataflow Studio에서 내장 transform(Parse JSON, Filter/Map, Flatten/Select fields)을 사용하여 BigQuery용 안정적인 columnar schema를 생성합니다. - 더 높은 처리량과 더 낮은 지연을 위해 legacy streaming inserts보다 권장되는 Storage Write API를 사용하여 BigQuery에 write합니다. - cross-region 지연과 egress를 줄이기 위해 Pub/Sub 및 BigQuery dataset 위치와 가까운 Dataflow job region을 선택합니다. 이는 Google Cloud Architecture Framework의 reliability 및 performance 원칙과도 일치합니다. - schema evolution(nullable field, default value)을 계획하고 malformed JSON은 dead-letter output으로 처리합니다. 흔한 오해: - “Direct Pub/Sub to BigQuery”는 가장 단순해 보이지만, 필요한 cleaning/enrichment/flattening을 수행하지 못합니다. - “Cloud Run subscriber”도 가능은 하지만, 대규모 streaming에 대해 code 의존도가 높고 운영 복잡성이 큽니다(concurrency, retry, ordering, backpressure). 이는 low-code 및 유지보수성 목표와 충돌합니다. - “Cloud Storage + batch”는 analytics에서 흔하지만, 90초 미만 freshness는 충족할 수 없습니다. 시험 팁: 거의 실시간 + transformation + BigQuery + low-code/visual 요구사항이 보이면, Pub/Sub + Dataflow(Dataflow Studio)를 떠올리세요. 또한 direct connector는 복잡한 transformation이 필요 없을 때만 적합하며, batch 지향 storage 패턴은 엄격한 freshness SLA를 충족하지 못한다는 점도 기억하세요.

5
문제 5

Your healthcare analytics startup stores patient encounter data that is updated once per day at 02:00 UTC and is spread across 6 BigQuery datasets; several tables contain PHI fields like full_name, phone_number, and notes. You need to let a new contract analyst query only non-sensitive operational metrics (e.g., clinic_id, visit_date, procedure_code, total_cost) for the last 180 days while ensuring they cannot access any PHI or underlying base tables. What should you do?

프로젝트 수준의 BigQuery Job User는 분석가가 query job을 생성하고 실행할 수만 있게 하며, 어떤 table이나 view를 읽을 권한은 부여하지 않습니다. 분석가가 query를 제출할 수 있더라도, BigQuery는 읽기 권한이 없는 dataset에 대한 접근을 거부합니다. 또한 이 옵션은 column을 non-PHI 필드로 제한하거나 기본 source table을 숨기는 메커니즘도 제공하지 않습니다. 따라서 불완전하며 access-control 요구 사항을 충족하지 못합니다.

이것이 올바른 최소 권한 패턴입니다: 별도 dataset의 view를 통해 승인된 column/row만 게시하고, 해당 dataset에만 Data Viewer를 부여하며, 분석가가 query를 실행할 수 있도록 project에 Job User를 추가로 부여합니다. source dataset에 대한 권한이 없으므로 분석가는 PHI가 포함된 base table을 query할 수 없습니다. 이는 일반적인 BigQuery 거버넌스 관행(authorized views/curated datasets)과 일치합니다.

승인된 데이터를 별도의 프로젝트로 복사하면 PHI를 분석가로부터 격리할 수는 있지만, 불필요한 데이터 중복과 추가적인 pipeline 및 governance 오버헤드를 발생시키므로 최선의 답은 아닙니다. 더 중요한 점은 BigQuery Data Owner를 부여하면 분석가에게 데이터 리소스를 생성, 수정, 삭제할 수 있는 과도한 권한을 주게 되어 최소 권한 원칙을 위반한다는 것입니다. 문제는 정제된 metric에 대한 통제된 query 접근을 요구하며, shared view 패턴이 이를 더 깔끔하게 달성합니다. 자격증 시험에서는 명시적으로 요구되지 않는 한 read-only 분석가 시나리오에 owner 수준 역할은 피해야 합니다.

프로젝트 수준에서 BigQuery Data Viewer를 부여하는 것은 너무 광범위합니다. PHI를 포함한 dataset과 table을 포함해 프로젝트 전반의 dataset과 table을 분석가가 읽을 수 있게 할 수 있기 때문입니다. 이는 민감한 필드나 기본 base table에 접근해서는 안 된다는 요구 사항과 직접적으로 충돌합니다. 또한 승인된 column과 최근 180일만의 선별된 projection을 강제하는 기능도 전혀 없습니다. 민감한 healthcare 데이터의 경우, 선별된 view를 dataset 수준에서 공유하는 것이 더 안전하고 정확한 패턴입니다.

문제 분석

핵심 개념: 이 문제는 민감 데이터에 대한 BigQuery 접근 제어 패턴을 평가합니다: 최소 권한 IAM, dataset/table 권한, 그리고 view( materialized view 포함)를 사용해 승인된 column/row만 노출하면서 기본 base table에 대한 접근을 차단하는 방법입니다. 의료 분야에서는 PHI 보호가 Google Cloud Architecture Framework의 Security, Privacy, and Compliance 원칙과도 부합합니다. 정답인 이유: 옵션 B는 분석가를 위한 선별된 read-only 인터페이스를 만듭니다: PHI가 아닌 column만 선택하고 최근 180일로 필터링한 (materialized) view를 별도의 dataset에 배치합니다. 해당 dataset에 BigQuery Data Viewer를 부여하면 분석가는 view 결과를 읽을 수 있지만 원본 dataset/table에는 접근할 수 없습니다. 또한 project 수준에서 BigQuery Job User를 부여해야 query job을 실행할 수 있습니다. 핵심은 base dataset에 대한 권한을 부여하지 않기 때문에 PHI table을 직접 query할 수 없다는 점입니다. 이는 “운영 지표만 query할 수 있고 PHI나 underlying base table에는 접근할 수 없다”는 요구사항을 충족합니다. 주요 기능 / 구성: - view를 호스팅할 전용 “analytics_shared” dataset을 사용합니다. - view에서 허용된 column만 projection하고 날짜 조건을 적용합니다(예: visit_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 180 DAY)). - 분석가가 source dataset에 어떤 role도 갖지 않도록 합니다. standard view를 사용하는 경우, view authorization 동작(authorized views)에 의존하여 사용자는 source table을 읽지 못하지만 view는 source table을 읽을 수 있게 합니다. materialized view는 반복 query에 대한 성능/비용을 개선할 수 있지만 제약이 있으므로, MV 제약이 맞지 않으면 standard authorized view가 정석적인 접근입니다. - 필요 시 추가 제어를 적용합니다: PHI에 대한 column-level security/policy tags 및/또는 row-level security. 다만 이 문제의 요구사항은 선별된 view 접근 방식만으로 충족됩니다. 흔한 오해: project 수준 Data Viewer(옵션 D)는 편리해 보이지만 PHI를 포함한 모든 dataset/table을 노출합니다. Job User만(옵션 A)으로는 job 실행만 가능하고 데이터 읽기는 불가하며, 통제된 접근을 해결하지 못합니다. 데이터를 새 project로 복사(옵션 C)하는 방식은 부담이 크고 중복 및 거버넌스 부담을 증가시키며, Data Owner는 권한이 과도하게 넓습니다. 시험 팁: BigQuery에는 두 가지 권한이 필요하다는 점을 기억하세요: job 실행 권한(bigquery.jobs.create를 위한 Job User)과 데이터 읽기 권한(특정 dataset/table/view에 대한 Data Viewer). 민감 데이터의 경우 최소 권한을 우선하고, project 수준의 광범위한 role 대신 authorized views(또는 적절한 경우 materialized views)를 통해 정제된 dataset을 게시하는 방식을 선호합니다.

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

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

6
문제 6

You work for a cold-chain logistics company that streams real-time IoT telemetry (temperature, GPS, battery) from 8,000 refrigerated containers into Pub/Sub at a peak of 50,000 messages per second. You must process the stream with sub–5-second end-to-end p95 latency to: (1) filter out invalid readings (e.g., battery_level < 10%), (2) enrich each event with a static route lookup (~500 route IDs updated hourly), and (3) compute 1-minute per-container aggregates (avg temperature, count) before loading both raw and aggregated records into BigQuery tables partitioned by event_time (daily partitions). You need a Google-recommended design that provides low latency, high throughput, windowed aggregation, and easy autoscaling from Pub/Sub to BigQuery. What should you do?

Cloud Composer는 streaming processing engine이 아니라 orchestration 서비스(managed Airflow)입니다. Pub/Sub를 매분 pull하면 batch latency가 발생해 sub–5-second p95 요구사항을 위반하고, 50,000 msg/s에서 message backlog 위험이 있습니다. 또한 custom Python script에는 built-in event-time windowing, watermark handling, scalable parallelism이 없습니다. 이 설계는 운영적으로 취약하며 Google의 권장 streaming analytics 패턴과도 맞지 않습니다.

Dataflow는 Google Cloud에서 streaming ETL을 위한 권장 managed 서비스입니다. Pub/Sub를 high throughput으로 읽고, 레코드 단위 filtering을 지원하며, 매시간 업데이트되는 작은 reference data에 대해 side input을 사용해 이벤트를 enrichment할 수 있습니다. 또한 out-of-order IoT 데이터를 위한 네이티브 event-time windowing(1-minute window), trigger, allowed lateness를 제공합니다. Dataflow autoscaling과 BigQuery sink(streaming write)는 최소한의 ops로 low-latency, high-throughput 요구사항을 충족합니다.

Spark Structured Streaming을 사용하는 Dataproc는 Pub/Sub stream을 처리하고 BigQuery에 쓸 수 있지만, cluster 관리, executor tuning, autoscaling policy 처리, bursty load에서의 reliability/latency 보장이 필요합니다. 쉬운 autoscaling과 managed operation을 강조하는 시험의 “Google-recommended design” 관점에서는 Dataflow가 선호됩니다. Dataproc는 Hadoop/Spark ecosystem 호환성이나 lift-and-shift workload가 필요할 때 더 적합합니다.

Cloud Run은 Pub/Sub push subscription에서 scale할 수 있지만, 올바른 event-time semantics, late data handling, 일관된 aggregation output을 갖춘 컨테이너별 1-minute windowed aggregation을 구현하는 것은 복잡합니다. 외부 state(예: Redis/Firestore/Bigtable)와 신중한 idempotency가 필요해 운영 리스크와 latency가 증가합니다. 50k msg/s에서는 instance scaling, concurrency tuning, BigQuery streaming quota 관리가 Dataflow의 네이티브 streaming 모델을 사용하는 것보다 더 어렵습니다.

문제 분석

핵심 개념: 이 문제는 Pub/Sub ingestion에 대해 낮은 지연 시간 처리, enrichment, windowed aggregation, 그리고 BigQuery로의 직접 로딩을 지원하는 Google 권장 managed streaming ETL 서비스를 선택하는지를 평가합니다. 의도된 솔루션은 Cloud Dataflow의 Apache Beam입니다. 정답인 이유: Dataflow는 Pub/Sub에서 high-throughput streaming pipeline을 처리하도록 목적에 맞게 설계되었으며, 올바르게 설계하면 autoscaling과 sub–5-second p95 latency를 제공합니다. 또한 (1) 레코드 단위 filtering, (2) side input을 통한 enrichment(약 500개 route ID 같은 작은 reference dataset을 broadcasting), (3) trigger와 allowed lateness를 포함한 event-time windowing을 통한 컨테이너별 1분 aggregate를 네이티브로 지원합니다. Dataflow는 first-class BigQuery sink도 제공하여 BigQuery streaming write path를 사용해 raw 및 aggregated output을 모두 쓸 수 있으며, partitioned table을 위해 event_time을 보존할 수 있습니다. 주요 기능 / 구성 / best practice: - Pub/Sub를 unbounded source로 사용하고 message payload에서 event-time timestamp를 설정합니다. - downstream cost와 latency를 줄이기 위해 filtering을 초기에 적용합니다. - route lookup에는 side input을 사용합니다. lookup이 작고 매시간 업데이트되므로, 주기적 read(예: BigQuery/Cloud Storage/Firestore에서)로 refresh하고 side-input windowing을 사용해 broadcasted map을 업데이트할 수 있습니다. - container_id로 keying한 fixed 1-minute window를 사용하고, out-of-order IoT telemetry를 처리하기 위해 event-time trigger(예: watermark 이후)와 allowed lateness를 설정합니다. - raw 및 aggregate stream을 event_time(일 단위)로 partitioned된 별도 BigQuery table에 씁니다. schema가 안정적이도록 보장하고 적절한 write disposition을 사용합니다. - Dataflow autoscaling과 managed runner 운영은 Google Cloud Architecture Framework 원칙(operational excellence, performance efficiency, reliability)에 부합합니다. 흔한 오해: “간단한” 이벤트 처리에는 Cloud Run을 쓰고 싶을 수 있지만, 50k msg/s에서 windowed aggregation과 exactly-once-ish semantics를 올바르게 구현하기는 어렵습니다. Dataproc/Spark도 가능하지만 cluster management와 tuning이 필요하므로, 이 use case에서 가장 Google 권장 방식은 아닙니다. Composer는 orchestration이지 low-latency streaming이 아닙니다. 시험 팁: transformation, enrichment, windowing이 포함된 Pub/Sub-to-BigQuery streaming이라면 기본 선택은 Dataflow(Apache Beam)입니다. “windowed aggregation”, “event time”, “autoscaling”, “low latency” 같은 키워드를 통해 Dataflow를 orchestration(Composer)이나 container compute(Cloud Run)와 구분하세요.

7
문제 7

Your e-commerce company has 160 data staff split across four regional squads (Americas, EMEA, APAC, LATAM). Leadership is concerned that any user can currently move or delete dashboards in the Global Reports Shared folder. You need an easy-to-manage setup that allows everyone to view everything in Global Reports, but only lets each squad move or delete dashboards that belong to their own squad. What should you do?

Groups와 subfolders를 만드는 것은 좋지만, 각 squad의 subfolder에 View만 부여하면 요구사항을 충족하지 못합니다. View access로는 dashboards를 열 수는 있지만 해당 folder에서 콘텐츠를 이동하거나 삭제하거나 전반적으로 관리할 수 없습니다. 이 옵션은 (자기 squad 영역을 포함해) 모든 곳에서 파괴적 작업을 막게 되므로, “각 squad가 자기 squad에 속한 dashboards만 이동 또는 삭제할 수 있게”라는 요구사항에 실패합니다.

상위 folder를 All Users에 대해 View로 설정하는 것은 맞지만, 각 개별 squad 구성원에게 Manage Access/Edit를 부여하는 것은 160명 사용자에 대해 확장되지 않습니다. 관리 오버헤드와 잘못된 구성 위험(누군가가 실수로 잘못된 subfolder에 접근하거나 역할 변경 후에도 접근 권한이 남는 문제)이 증가합니다. 문제는 관리가 쉬운 구성을 명시적으로 요구하므로, group 기반 권한이 강하게 선호됩니다.

이 옵션이 가장 적합한 이유는 read-only shared parent folder와 squad별 subfolders, 그리고 group-based administration을 결합하기 때문입니다. Global Reports Shared를 All Users에 대해 View로 설정하면 모든 사람이 모든 content를 볼 수 있으면서도 top-level shared area는 수정할 수 없게 됩니다. Squad마다 하나의 group을 만드는 것은 160명의 사용자에 대해 확장 가능한 접근 방식이며, access 변경은 사용자별 ACL 업데이트가 아니라 group membership을 통해 처리됩니다. 각 squad의 own subfolder에 대한 상위 permission은 해당 squad가 자신의 dashboards를 관리할 수 있게 하면서, 다른 squads가 자신의 영역 밖의 content를 변경하지 못하게 합니다.

Squad dashboards를 personal folders로 옮기면 공유 리포팅 모델이 깨지고 거버넌스가 더 어려워지며, 쉬워지지 않습니다. Personal folders는 개인에 종속되므로 소유권, 연속성, 검색 가능성이 복잡해집니다. 또한 콘텐츠가 personal 공간에 흩어지고 Global Reports 공유 구조 내에서 중앙 관리되지 않게 되므로, “모든 사람이 Global Reports에서 모든 것을 볼 수 있어야 한다”는 요구사항과도 모순됩니다.

문제 분석

핵심 개념: 이 문제는 groups, subfolders, 그리고 inherited permissions를 사용한 Looker folder governance를 테스트합니다. 요구 사항은 모든 사용자가 모든 shared content를 볼 수 있게 하면서, content management 작업은 해당 regional squad로 제한하는 것입니다. 가장 관리하기 쉬운 설계는 모든 사용자를 위한 read-only parent folder와, 해당 squad group에만 상위 권한을 부여한 squad별 subfolder를 사용하는 것입니다. 정답인 이유: Option C가 가장 적절한 정답인 이유는 Global Reports Shared folder를 All Users에 대해 View로 설정하여, shared root에서 사용자가 content를 재구성하거나 삭제할 수 없도록 하면서도 전체 가시성을 제공하기 때문입니다. 그런 다음 squad마다 하나의 subfolder를 만들고 Looker groups를 통해 permissions를 할당하는데, 이는 160명의 사용자를 개별적으로 관리하는 것보다 훨씬 더 확장성이 높습니다. 각 squad group에 자신의 subfolder에 대해서만 상위 access를 부여하면, 해당 squad가 자신의 dashboards를 관리할 수 있으면서 다른 squads의 content는 변경하지 못하게 할 수 있습니다. 주요 기능: Looker의 folder permissions는 특별히 override하지 않는 한 inherited되므로, View-only parent folder는 모든 사용자에게 안전한 기준선을 만듭니다. Subfolders는 content administration에 대한 명확한 ownership 경계를 만듭니다. Group-based access control은 관리자가 각 사용자에 대한 folder ACLs를 수정하는 대신 group membership만 업데이트하면 되므로 onboarding, offboarding, 그리고 regional staffing changes를 단순화합니다. 일반적인 오해: 흔한 실수 중 하나는 squad folder에 대한 View access만으로 충분하다고 생각하는 것이지만, 그렇지 않습니다. View는 content management가 아니라 소비만 지원하기 때문입니다. 또 다른 실수는 permissions를 개별 사용자에게 직접 할당하는 것인데, 기술적으로는 가능하지만 이 규모에서는 관리가 쉽지 않습니다. 또한 이 요구 사항에서는 Manage Access에 집중할 필요가 없습니다. 필요한 것은 permission administration 위임이 아니라 dashboards 관리이기 때문입니다. 시험 팁: Looker permission 문제에서는 먼저 viewing 요구 사항과 content-management 요구 사항을 분리하세요. 그런 다음 광범위한 read-only parent folder, ownership별 subfolders, 그리고 개별 권한 부여 대신 groups를 사용하는 설계를 찾으세요. 요구 사항이 dashboards 이동 또는 삭제에 관한 것이라면, 필요한 것보다 더 넓은 권한은 피하면서 관련 subfolder에 대한 folder-level edit capability를 떠올리세요.

8
문제 8

Your mobile game studio needs to measure player sentiment about a new in-game economy update. You have 30 million rows of player comments from in-app support and app store reviews stored in BigQuery; messages average 140 characters and contain gamer slang, emojis, and mixed casing. You must build and deploy a sentiment classification solution within two weeks with minimal ML operations overhead using managed Google Cloud services. What should you do?

부분적으로는 타당하지만 불필요하며 잠재적으로 해로울 수 있습니다. AutoML NLP는 원시 텍스트에서 직접 학습할 수 있는데, 공격적인 SQL 전처리는 감성을 담고 있는 이모지, 대소문자, 슬랭 패턴을 제거할 수 있습니다. 또한 2주 일정 내에서 추가 엔지니어링 단계와 리스크를 늘립니다. 전처리는 기본값으로 적용하기보다(예: 보일러플레이트 제거처럼) 명확하고 검증된 필요가 있을 때만 사용하세요.

제약 조건에 비추어 오답입니다. 커스텀 TensorFlow 감성 모델을 구축하려면 데이터 라벨링 전략, 모델 아키텍처 선택, 학습 인프라, 하이퍼파라미터 튜닝, 그리고 지속적인 서빙/모니터링이 필요합니다. Compute Engine에 배포하면 관리형 Vertex AI endpoint 대비 운영 오버헤드(스케일링, 패치, 신뢰성)가 증가합니다. 최소 MLOps로 2주 내에 견고하게 완료하기는 어렵습니다.

운영 복잡도가 높아 오답입니다. Dataproc 클러스터는 프로비저닝, 튜닝, 작업 오케스트레이션, 의존성 관리(Spark NLP), 지속적인 비용 제어가 필요합니다. Spark는 대규모 텍스트 코퍼스를 처리할 수 있지만, 관리형 감성 솔루션으로 가는 가장 빠른 경로는 아닙니다. 또한 커스텀 모델링과 파이프라인 유지보수 쪽으로 방향이 이동하여 “최소 ML 운영 오버헤드” 요구사항과 충돌합니다.

정답. BigQuery의 원시 텍스트를 export하고 AutoML Natural Language(Vertex AI)를 사용해 관리형 인프라로 빠르게 커스텀 감성 분류기를 학습 및 배포합니다. AutoML은 텍스트 처리의 상당 부분을 내부적으로 처리하며, 평가 지표와 endpoint로의 손쉬운 배포를 제공합니다. 이는 빠른 제공, 노이즈가 많은 사용자 생성 텍스트, 최소 운영 부담이라는 요구사항에 가장 잘 부합합니다.

문제 분석

핵심 개념: 이 문제는 BigQuery에 저장된 텍스트로부터 감성 분류를 수행하기 위해 Google Cloud에서 관리형이며 운영 부담이 적은 NLP 접근 방식을 선택하는지를 평가합니다. 핵심 서비스는 BigQuery(데이터 소스)와 Vertex AI AutoML for Natural Language(관리형 학습 + 배포)입니다. 정답이 맞는 이유: 옵션 D는 제약 조건(2주 내 제공, 최소한의 ML 운영 오버헤드, 노이즈가 많은 사용자 생성 텍스트(슬랭, 이모지, 대소문자 혼용) 처리)에 가장 잘 부합합니다. AutoML Natural Language는 최소한의 피처 엔지니어링으로 커스텀 텍스트 분류를 수행하도록 설계되었습니다. 자체적으로 텍스트 전처리(토크나이징/정규화)를 수행하며, 커스텀 전처리 파이프라인을 구축·유지하지 않아도 대소문자 패턴과 이모지 사용을 포함한 원시 텍스트 분포로부터 학습할 수 있습니다. BigQuery에서 AutoML/Vertex AI로 내보내는 것은 일반적인 워크플로이며, 학습·평가·배포까지 엔드투엔드로 관리형으로 유지할 수 있습니다. 핵심 기능 / 모범 사례: - 관리형 학습 및 배포: Vertex AI AutoML은 커스텀 모델을 학습하고 오토스케일링이 가능한 endpoint에 배포하여 MLOps 부담을 줄입니다. - 비정형 텍스트 처리: AutoML의 NLP 파이프라인은 지저분한 실제 텍스트를 처리하도록 구축되어 있으며, 사용자는 라벨링과 평가에 집중하면 됩니다. - 데이터 이동: BigQuery export를 Cloud Storage로 사용(또는 사용 가능한 경우 BigQuery ML/Vertex 통합)하여 AutoML에 입력합니다. 데이터셋 크기를 고려하세요: 3,000만 행은 라벨링/학습을 직접 수행하기에 너무 크거나 비용이 많이 들 수 있으므로, 실무에서는 대표성 있는 일부를 샘플링해 라벨링한 뒤 반복적으로 개선합니다. - 거버넌스: 가능하면 데이터를 리전 내에 유지하고, export에 대한 PII 처리 및 접근 제어(IAM)를 보장합니다. 흔한 오해: A는 “전처리”가 필요해 보이기 때문에 더 좋아 보일 수 있지만, 과도한 SQL 전처리는 유용한 감성 신호(이모지, 대소문자, 반복 문자)를 제거할 수 있고 시간/복잡도를 증가시킵니다. B와 C는 강력하지만 인프라 관리, 모델 엔지니어링, 배포/모니터링 오버헤드 때문에 “최소 운영” 및 “2주” 제약을 위반합니다. 시험 팁: 문제가 속도, 최소 운영, NLP를 위한 관리형 서비스를 강조하면 기본 선택은 Vertex AI AutoML(또는 커스텀 학습이 필요 없다면 사전 구축된 Natural Language API)입니다. 문제가 명시적으로 맞춤형 모델링, 커스텀 피처 파이프라인, 또는 관리형 옵션을 넘어서는 대규모 분산 학습을 요구하지 않는 한 커스텀 TensorFlow/Dataproc는 피하세요.

9
문제 9

You manage a municipal water utility and must forecast the next 30 days of daily water demand for 85 service districts to plan pumping capacity and avoid shortages. Five years of historical daily meter readings are stored in a BigQuery table utility.daily_demand (district_id STRING, reading_date DATE, liters_used INT64) that exhibits weekday/weekend and summer seasonality. You need a scalable approach that leverages this seasonality and historical data and writes the forecasts into a new BigQuery table. What should you do?

정답입니다. BigQuery ML ARIMA_PLUS는 시계열 예측을 위해 설계되었고 추세와 계절성(평일/주말, 연간 패턴)을 자동으로 모델링할 수 있습니다. district_id를 time_series_id_col로 사용하면 85개 district에 대한 예측을 확장할 수 있습니다. ML.FORECAST는 30일 horizon을 생성하며 결과를 새 BigQuery table에 직접 기록할 수 있어 data movement와 운영 오버헤드를 최소화합니다.

이 요구사항에는 최선의 선택이 아닙니다. Colab Enterprise에서 커스텀 Python 모델로 예측할 수는 있지만, 데이터 exporting/reading, training runs 관리, versioning, scheduling, 결과를 BigQuery로 다시 기록하는 작업 등 추가 단계가 필요합니다. 시험 시나리오에서 과거 seasonality의 확장 가능한 활용과 BigQuery로의 직접 output을 강조한다면, BigQuery ML 시계열이 더 단순하고 더 managed된 솔루션입니다.

오답입니다. BigQuery ML linear regression은 본질적으로 시계열 예측 모델이 아닙니다. lag features, day-of-week indicators, seasonal terms를 수동으로 생성하고 각 district에 대해 feature generation을 관리하지 않으면 autocorrelation이나 seasonal structure를 자동으로 포착하지 못합니다. 이는 일별 수요 예측에서 명확한 seasonality가 있을 때 ARIMA_PLUS보다 더 복잡하고 덜 견고합니다.

오답입니다. Logistic regression은 binary 또는 multi-class classification(카테고리/확률 예측)용이며, liters_used 같은 연속적인 수치 값을 예측하는 forecasting이 아닙니다. 문제를 classes(예: high/low demand)로 변환하더라도 capacity planning을 위한 일별 수요량 예측 요구사항을 충족하지 못하고 중요한 수치 정보를 버리게 됩니다.

문제 분석

핵심 개념: 이 문제는 BigQuery ML을 사용하여 BigQuery에서 대규모 시계열 예측을 수행하기 위해 Google Cloud에서 적절한 analytics/ML 접근 방식을 선택하는지를 평가합니다. 핵심은 계절성을 기본적으로 처리하고 time series identifier를 통해 여러 관련 시계열을 지원하는 내장 시계열 모델링(ARIMA_PLUS)을 활용하는 것입니다. 정답이 맞는 이유: BigQuery ML 시계열 모델(ARIMA_PLUS)은 시간에 따른 수치 값을 예측하도록 목적에 맞게 설계되었으며, 추세와 계절 패턴(예: 평일/주말, 연간/여름 계절성)을 자동으로 감지하고 모델링할 수 있습니다. 85개 district가 있으므로, 데이터를 내보내지 않고도 많은 시계열에 대해 학습과 예측을 수행하는 확장 가능하고 운영 부담이 적은 솔루션이 필요합니다. district_id를 time series ID로 사용하면 하나의 모델 정의로 여러 district 수준 시계열을 관리할 수 있습니다. ML.FORECAST는 향후 30일의 일별 예측을 생성하고 결과를 새 BigQuery table에 직접 기록할 수 있어, BigQuery 내부에서 end-to-end 요구사항을 충족합니다. 주요 기능 / Best Practices: - CREATE MODEL을 사용하고 model_type='ARIMA_PLUS'로 설정하며, time_series_timestamp_col(reading_date), time_series_data_col(liters_used), time_series_id_col(district_id)을 지정합니다. - ARIMA_PLUS는 자동 계절성 감지와 holiday effects(해당되는 경우)를 지원하며, capacity planning에 유용한 prediction intervals도 생성할 수 있습니다. - BigQuery에서 데이터와 ML을 유지하는 것은 Google Cloud Architecture Framework의 operational excellence 및 performance efficiency 원칙과 일치합니다: 구성 요소가 더 적고, data movement가 줄며, 실행이 확장 가능합니다. - 예측 결과를 BigQuery에 기록하면 추가 인프라 없이 downstream dashboards(Looker) 또는 scheduled pipelines(예: scheduled queries)을 사용할 수 있습니다. 흔한 오해: 커스텀 Python 모델(notebooks)도 가능하지만, 운영 오버헤드(데이터 추출, 학습 인프라, 배포, 스케줄링)가 추가되며 BigQuery ML이 이미 문제에 적합한 경우 불필요합니다. Linear regression은 기본적으로 시계열 예측 방법이 아니며, lag/seasonal features를 수동으로 엔지니어링하지 않으면 autocorrelation/seasonality를 본질적으로 모델링하지 못합니다. Logistic regression은 classification용이며 수요의 수치 예측이 아닙니다. Exam Tips: “forecast next N days”, “seasonality”, “BigQuery table”을 보면 BigQuery ML ARIMA_PLUS와 ML.FORECAST를 강하게 고려하세요. 여러 entity(stores, districts, devices)가 있으면 time_series_id_col을 찾으세요. 요구사항에 확장성과 최소 운영으로 예측을 BigQuery로 다시 기록하는 것이 포함되면 managed, in-warehouse ML을 선호하세요.

10
문제 10

Your media streaming service archives daily viewer comments as newline-delimited JSON files (~5 files/day, ~80 MB each) in a Cloud Storage bucket gs://stream-comments-prod. The comments arrive in 12 languages and must be normalized and translated to French within 30 minutes of file arrival before being stored in BigQuery for analytics. You need a pipeline that is fully serverless, auto-scales to about 60,000 comments per day, and requires minimal maintenance with no clusters to manage. What should you do?

Dataproc + Spark는 번역 및 데이터 적재가 가능하지만, Dataproc는 ephemeral clusters를 사용하더라도 클러스터 라이프사이클 관리(생성/확장/패치)가 필요해 운영 오버헤드가 발생합니다. 따라서 “완전한 serverless” 및 “최소 유지보수”에 가장 잘 맞지 않습니다. 또한 하루 ~5개 파일만 처리하기 위해 클러스터를 띄우는 것은 비효율적이며 Dataflow 대비 비용과 복잡도를 증가시킬 수 있습니다.

Dataflow는 autoscaling을 제공하는 managed, serverless 데이터 처리 서비스로, Cloud Storage에서 BigQuery로의 이벤트 기반 ETL에 적합합니다. template(커스텀 로직에는 보통 Flex Template)을 사용하면 NDJSON을 파싱하고 필드를 정규화하며, 댓글별로 Cloud Translation API v3를 호출(제어된 병렬성/batching 적용)한 뒤 결과를 30분 SLA 내에 BigQuery로 기록할 수 있습니다. 이는 클러스터 불필요, 낮은 운영 요구사항을 충족합니다.

BigQuery ML은 viewer comments로부터 고품질 다국어 번역 모델을 처음부터 학습하도록 설계되지 않았고, managed Cloud Translation API를 대체하지도 않습니다. 번역 모델을 학습하고 유지하는 것은 복잡하고 많은 데이터가 필요하며 정확도 요구사항을 충족하기 어렵습니다. 또한 이벤트 기반 처리를 해결하지 못하고, 복잡도를 모델 학습과 SQL 워크플로로 전가합니다.

BigQuery remote functions는 외부 API를 호출할 수 있지만, scheduled queries로 행 단위 번역을 수행하는 것은 운영 및 비용 측면에서 비효율적이며, 규모가 커질수록 더 느리거나 예측 불가능해질 수 있습니다. 15분마다 scheduled queries를 실행하면 지연이 추가되고, 부하 상황에서 파일 도착 후 30분 이내 완료를 보장하지 못합니다. 또한 수집과 변환 간 결합도가 증가하고, BigQuery 실행 패턴으로 인해 API quota 한도에 걸릴 수 있습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 완전한 serverless, autoscaling 수집-변환 파이프라인을 선택하는지를 평가합니다. 핵심 서비스는 이벤트 기반 ETL을 위한 Dataflow(Apache Beam managed service), 랜딩 존으로서의 Cloud Storage, 다국어 번역을 위한 Cloud Translation API v3, 그리고 분석용 웨어하우스로서의 BigQuery입니다. 정답이 맞는 이유: 옵션 B는 serverless, 클러스터 관리 불필요, autoscaling, 파일 도착 후 30분 이내의 준실시간 처리라는 모든 제약을 가장 잘 충족합니다. Dataflow template은 gs://stream-comments-prod에 새 객체가 도착할 때(일반적으로 Eventarc/Cloud Functions 알림을 통해) 트리거될 수 있으며, newline-delimited JSON을 읽고 필드를 정규화한 뒤 레코드별로 Translation API를 호출하고 BigQuery에 직접 기록할 수 있습니다. Dataflow는 처리량에 따라 worker를 확장/축소하므로 하루 약 60,000개 댓글과 버스트성 유입(하루 5개 파일)에 적합합니다. 또한 멱등성(idempotent) 쓰기와 BigQuery streaming 또는 지연 시간 요구에 따른 batch load를 통해 exactly-once/at-least-once 패턴을 지원합니다. 주요 기능 / 모범 사례: - 최소 운영과 반복 가능한 배포를 위해 Dataflow Flex Templates(또는 template로 패키징한 커스텀 Beam pipeline)를 사용합니다. - 가능하면 batching과 함께 Translation API v3를 사용하고, Translation API quota를 준수하며 throttling을 피하기 위해 동시성을 제어합니다. - 낮은 지연 시간 쓰기를 위해 BigQuery Storage Write API 또는 streaming inserts를 사용하고, 비용/성능을 위해 ingestion date 기준으로 테이블을 partitioning합니다. - 실패한 번역에 대해 dead-letter 처리(예: Pub/Sub 또는 GCS)와 exponential backoff를 적용한 재시도를 구현합니다. - 지연 시간과 egress 비용을 줄이기 위해 처리 리전을 유지합니다(GCS, Dataflow, BigQuery dataset을 동일 리전에 배치). 이는 Google Cloud Architecture Framework의 reliability 및 cost optimization 원칙과도 부합합니다. 흔한 오해: Dataproc(A)는 Spark 기반 ETL을 수행할 수 있지만 “클러스터 관리 불필요”가 아니며 운영 오버헤드가 추가됩니다. BigQuery ML(C)은 Translation API 같은 범용 machine translation 용도가 아닙니다. Remote functions + scheduled queries(D)는 가능할 수 있으나, 대규모에서 행 단위 API 호출에 적합하지 않고 스케줄링 단위 및 쿼리/런타임 변동성 때문에 “파일 도착 후 30분 이내”라는 엄격한 요구사항을 놓칠 수 있습니다. 시험 팁: “serverless”, “autoscale”, “minimal maintenance”, “transform on ingest”를 보면 streaming/batch ETL의 기본 선택지는 Dataflow입니다. 분석 저장소는 BigQuery를 사용하고, 외부 ML/AI 호출은 BigQuery ML로 커스텀 번역 모델을 학습하려 하기보다 목적에 맞는 API(Translation API)를 사용합니다. 지연 시간 SLO가 명시적일 때는 scheduled polling보다 이벤트 기반 트리거를 선호합니다.

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

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

11
문제 11

Your analytics team has a 180 MB CSV file (~1.2 million rows) stored in Cloud Storage (gs://retail-dumps/2025-08/sales.csv) that must be filtered to exclude rows where test_flag = true and aggregated to daily revenue by product_id, then loaded into BigQuery for analysis once per day; to minimize operational overhead and cost while keeping performance efficient for this small dataset and simple transformations, which approach should you choose?

Dataproc(Hadoop/Spark)는 180 MB 일일 CSV와 단순 필터/집계 로직에 비해 과도한 선택입니다. 클러스터를 프로비저닝하고 관리해야 하며(또는 최소한 ephemeral clusters), job submission을 처리해야 하고, 클러스터가 실행되는 동안 compute resources 비용을 지불해야 합니다. Dataproc은 기존 Spark/Hadoop 워크로드, 복잡한 분산 처리, 또는 특정 open-source ecosystem 도구가 필요할 때 적합하며, BigQuery로의 단순 일일 ELT에는 적합하지 않습니다.

BigQuery가 최적의 선택입니다. Cloud Storage에서 staging table로 로드한 뒤 SQL로 필터링 및 집계를 수행해 최종 테이블을 만듭니다. 이는 serverless이며 운영 오버헤드가 낮고, 소규모 일일 배치에 비용 효율적입니다. BigQuery Scheduled Queries(또는 Cloud Scheduler)로 자동화할 수 있습니다. BigQuery는 스캔과 집계에 최적화되어 있고 변환이 단순하므로 성능도 효율적입니다.

Cloud Data Fusion은 시각적 ETL 인터페이스와 다양한 커넥터를 제공하지만, 단순히 BigQuery SQL을 사용하는 것에 비해 운영 오버헤드와 기본 비용(instance-based pricing)이 더 큽니다. 단일 소규모 CSV와 기본 변환에는 Data Fusion의 pipeline 설계, runtime environment, 관리가 불필요합니다. 더 많은 소스, 복잡한 ETL 패턴, 거버넌스, 또는 대규모에서의 low-code 접근이 필요할 때 더 적합합니다.

Dataflow(Apache Beam)는 확장 가능한 batch/stream 파이프라인, windowing, 복잡한 변환에 매우 뛰어나지만, 여기서는 필요 이상의 개발 및 운영 복잡성을 추가합니다. Beam pipeline을 구축하고 유지보수해야 하며, templates를 관리하고, 실행 중 worker resources 비용을 지불해야 합니다. 소규모 일일 CSV에 대한 단순 필터링과 집계라면 BigQuery SQL이 더 단순하고, 더 저렴하며, 운영하기 쉽습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 소규모 일일 배치 데이터셋에 대해 운영 부담이 가장 낮고 비용 효율적인 수집 + 변환 패턴을 선택하는지를 평가합니다. 핵심 아이디어는 변환이 단순(필터 + 집계)하고 데이터 볼륨이 크지 않을 때 BigQuery에서 “serverless SQL ELT”를 선호하는 것입니다. 정답이 맞는 이유: BigQuery는 Cloud Storage에서 데이터를 직접 로드한 다음 standard SQL을 사용해 test_flag = true인 행을 필터링하고 product_id별 일일 매출을 집계할 수 있습니다. 하루 1회 180 MB CSV(~120만 행) 규모라면 BigQuery는 클러스터, 워커, 파이프라인 인프라를 관리하지 않고도 뛰어난 성능을 제공합니다. 운영 오버헤드는 최소입니다. 쿼리를 스케줄링(BigQuery scheduled queries)하거나 Cloud Scheduler + BigQuery Jobs API로 실행할 수 있습니다. 비용도 일반적으로 낮은 편인데, 스토리지와 쿼리 처리 비용만 지불하며 데이터셋이 작고 변환이 단순하기 때문입니다. 주요 기능 / 모범 사례: - staging table 사용: CSV를 raw/staging BigQuery 테이블로 로드합니다(일별 파일을 append한다면 날짜 기준 partitioning을 선택적으로 적용). - SQL로 변환: CREATE OR REPLACE TABLE(또는 MERGE)로 집계 테이블을 생성합니다. - external tables는 로드를 피하고 싶을 때만 고려하되, 일일 반복 분석에는 보통 native BigQuery tables로 로드하는 편이 더 빠르고 관리하기 쉽습니다. - schema 정의(autodetect 또는 명시적 정의)를 사용하고, 적절한 write disposition을 설정합니다(일일 재생성이면 WRITE_TRUNCATE, partitioning과 함께 누적이면 WRITE_APPEND). - Google Cloud Architecture Framework와 정렬: serverless managed services는 단순 워크로드에서 운영 부담을 줄이고 신뢰성을 높입니다. 흔한 오해: Dataflow, Dataproc, Data Fusion은 강력하지만, 작은 CSV에 SQL로 처리 가능한 단순 변환을 수행하기에는 불필요한 복잡성과 비용을 유발합니다. 이들은 복잡한 streaming, 무거운 변환, custom code, 또는 대규모 분산 처리가 필요할 때 더 적합합니다. 시험 팁: “small dataset”, “simple transformations”, “minimize operational overhead”를 보면 managed pipelines/clusters보다 BigQuery SQL(또는 BigQuery + scheduled queries)을 기본 선택으로 두세요. Dataflow/Dataproc/Data Fusion은 SQL을 넘어서는 고급 ETL, streaming, 또는 복잡한 orchestration이 필요한 경우에만 선택하는 것이 좋습니다.

12
문제 12

You operate a real-time fraud detection service for a fintech app where 1,500 JSON events per second are published to a Pub/Sub topic from mobile devices. You must validate JSON schema, drop records missing required fields, mask PII, and deduplicate by event_id within a 10-minute window before loading to BigQuery. The pipeline must autoscale, handle bursts up to 5,000 events/sec, and keep end-to-end 99th-percentile latency under 4 seconds with minimal operations overhead. What should you do?

Compute Engine 스크립트는 운영 오버헤드(VM 관리, scaling, patching, monitoring)를 증가시키고, burst 상황에서 p99 latency를 안정적으로 충족하기 어렵게 만듭니다. 올바른 windowed deduplication과 fault-tolerant processing(checkpointing, replay handling, exactly-once semantics)을 구현하는 것도 복잡해집니다. 또한 자체 autoscaling과 backpressure 전략을 설계해야 하며, 엄격한 latency 요구사항이 있는 fraud pipeline에는 위험합니다.

Cloud Storage로 트리거되는 Cloud Run은 파일 기반의 batch 지향 패턴으로, 지속적인 Pub/Sub event stream과 맞지 않습니다. 이벤트를 파일로 적재하는 중간 단계가 필요해 buffering 지연이 추가되고, 4초 p99 latency 요구사항을 위반할 가능성이 큽니다. Cloud Run은 autoscale이 가능하지만, 외부 state store와 추가 복잡성 없이 10분 범위의 stateful, windowed deduplication을 수행하도록 설계되지 않았습니다.

Dataflow가 최적의 선택입니다: Pub/Sub streaming ingestion, 레코드 단위 validation/transforms, 그리고 Apache Beam primitives를 사용한 10분 window 내 stateful/windowed deduplication을 네이티브로 지원합니다. burst를 처리하도록 autoscaling하며, managed fault tolerance와 replay handling을 제공하고, BigQuery sink와 직접 통합됩니다. Streaming Engine과 적절한 triggers/windowing을 사용하면 최소 운영 오버헤드로 낮은 end-to-end latency를 달성할 수 있습니다.

raw 이벤트를 BigQuery로 streaming한 뒤 scheduled queries로 나중에 정리하는 방식은 scheduled queries가 주기적으로 실행되며 sub-second~수 초 수준의 end-to-end 처리를 위해 설계되지 않았기 때문에 latency 요구사항을 충족하지 못합니다. 또한 invalid 레코드와 masking되지 않은 PII가 BigQuery에 저장되도록 허용하여 compliance 및 governance 리스크를 만듭니다. ingestion 이후 SQL로 deduplication하는 것은 가능하지만, 사후 대응적이며 대규모에서는 비용이 커질 수 있고, downstream consumer가 중복을 보게 되는 것을 막지 못합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 적절한 managed streaming 데이터 처리 서비스를 선택하는지를 평가합니다. 요구사항(Pub/Sub ingestion, 이벤트별 validation/transforms, window 기반 deduplication, 낮은 latency, autoscaling, 최소 운영)은 Apache Beam 기반의 Cloud Dataflow와 직접적으로 부합합니다. 정답이 맞는 이유: Dataflow는 Pub/Sub에서 읽고 BigQuery로 쓰는 real-time pipeline을 위해 설계되었으며, 설명된 변환을 그대로 지원합니다: schema validation(필수 필드 누락/무효 레코드 filtering), PII masking(map/transform), 그리고 10분 window 내 event_id 기준 deduplication(stateful processing + windowing). Dataflow의 streaming engine은 autoscaling을 통해 가변 처리량(초당 1,500 이벤트의 steady 상태와 초당 5,000 이벤트 burst)을 처리하면서도, 적절한 windowing/triggers 및 BigQuery streaming writes로 구성하면 낮은 end-to-end latency를 유지할 수 있습니다. 또한 self-managed compute 대비 운영 오버헤드를 최소화합니다. 주요 기능 / 구성 / best practices: - Pub/Sub -> Dataflow streaming pipeline을 Pub/Sub IO connector로 구성. - ParDo/Filter로 validation 및 불량 레코드 drop; 선택적으로 invalid 레코드를 감사(audit)용 dead-letter Pub/Sub topic 또는 BigQuery error table로 라우팅. - transforms에서 deterministic tokenization 또는 hashing(예: salt를 포함한 SHA-256)으로 PII masking; 정책 기반 inspection이 필요하면 Cloud DLP를 고려하되 latency 영향에 유의. - Beam windowing + state/timers로 deduplication(예: event_id로 keying 후 10분 state를 유지하며 중복 drop). 디바이스 이벤트가 늦게 도착할 수 있으면 watermarks를 사용하는 event-time을 적용하고 allowed lateness를 적절히 설정. - BigQuery에는 streaming inserts 또는(지원되는 경우) Storage Write API로 write하며, batching으로 비용을 줄이고 throughput을 개선. - Dataflow autoscaling, Streaming Engine, 적절한 worker machine types를 사용; backpressure 및 Pub/Sub subscription backlog를 모니터링. 흔한 오해: raw 데이터를 BigQuery로 streaming한 뒤 SQL로 “나중에 고치기”는 유혹적이지만, scheduled queries는 p99 4초 미만 latency를 충족할 수 없고 bad/PII 데이터가 저장되는 것을 방지하지도 못합니다. 또한 Cloud Run은 scale이 가능하지만, windowed dedup/state가 필요한 지속적인 high-throughput streaming에는 적합하지 않습니다. 시험 팁: Pub/Sub + real-time transforms + windowing/dedup + BigQuery + 엄격한 latency + autoscaling 조합이 보이면 기본 선택은 Dataflow streaming입니다. custom VM은 특수한 경우에만 고려하고, Cloud Run은 stateful streaming pipeline이 아니라 request-driven microservices에 주로 사용하세요.

13
문제 13

You oversee a smart-city media archive in Cloud Storage containing approximately 200 TB/month of raw 4K camera footage, 50 TB of processed highlight clips, and 80 TB of daily backups. Compliance requires that any footage tagged as “evidence” remain immutable for at least 7 years; other data follow these patterns: raw footage is frequently accessed for 14 days then rarely, processed clips are accessed daily for 90 days then infrequently, and backups are rarely accessed but must be retained for at least 365 days. You need to minimize storage costs and satisfy the retention/immutability requirements using a managed, low-overhead approach without building custom code. What should you do?

Lifecycle 전환은 비용 최적화 측면에서 맞지만, Object Versioning만으로는 불변성 요구사항을 충족하지 못합니다. Versioning은 객체가 덮어써지거나 삭제될 때 이전 버전을 유지하지만, retention policies/holds가 적용되지 않으면 권한 있는 사용자가 여전히 버전을 삭제(또는 live object와 버전들을 삭제)할 수 있습니다. 또한 이 옵션은 적절한 규정 준수 제어로 명시된 7년 evidence 불변성 요구사항을 다루지 못합니다.

age/접근 패턴에 따라 객체를 다른 storage classes로 이동시키는 방향성은 맞지만, Cloud KMS와 CMEK를 사용한다고 해서 불변성이나 보존(retention)이 강제되지는 않습니다. CMEK는 암호화 키만 관리하며, 객체의 삭제 또는 수정을 방지할 수 없습니다. 이는 암호화/컴플라이언스와 WORM 보존 제어를 혼동하는 흔한 사례입니다. 또한 관리형 자동화 메커니즘(lifecycle rules)을 명시적으로 제공하지도 않습니다.

메타데이터를 검사하고 매일 객체를 이동시키는 Cloud Run 함수는 커스텀 오케스트레이션이며 운영 오버헤드를 추가하므로, 관리형 저오버헤드 접근을 요구하는 조건과 모순됩니다. Object holds는 삭제 방지에 관련이 있지만, storage class 전환을 구현하기 위해 Cloud Run이 필요하지 않습니다. Cloud Storage Lifecycle Management가 이를 네이티브로, 그리고 대규모에서 더 신뢰성 있게 수행할 수 있습니다.

이 선택지는 Cloud Storage lifecycle management와 기본 object 보호 메커니즘을 결합하므로 가장 적절한 선택입니다. Lifecycle rules는 데이터가 오래될수록 더 저렴한 storage class로 전환하는 관리형, 저오버헤드 방식이며, 이는 비용 최소화 요구 사항을 직접적으로 지원합니다. Object holds의 사용은 증거 object를 삭제로부터 보호하는 데 적절하지만, 엄격한 7년 규정 준수 설계에서는 일반적으로 Bucket Lock이 포함된 retention policy를 더 많이 사용합니다. 제시된 선택지 중에서 D는 custom code를 요구하지 않으면서 올바른 관리형 아키텍처에 가장 가깝습니다.

문제 분석

핵심 개념: 이 문제는 규정 준수 요구 사항을 충족하면서 스토리지 비용을 줄이기 위해 Cloud Storage의 기본 데이터 lifecycle 및 retention 기능을 어떻게 사용하는지 평가합니다. 관리형 접근 방식은 자동 storage class 전환을 위한 lifecycle management rules와 증거 데이터용 Cloud Storage immutability controls를 사용하는 것입니다. 정답인 이유: 선택지 D는 제시된 선택지 중 가장 적절한 정답입니다. 시간이 지남에 따라 데이터를 더 저렴한 class로 자동 이동하기 위해 Cloud Storage lifecycle management를 사용하므로, 제시된 access pattern에 부합하고 custom code를 피할 수 있습니다. 또한 CMEK나 Object Versioning 같은 관련 없는 서비스 대신 증거 object에 대해 기본 immutability 관련 기능을 사용합니다. 다만 엄격한 7년 규정 준수 요구 사항의 경우, 가장 강력한 production 설계는 일반적으로 7년 retention policy와 Bucket Lock이 적용된 전용 bucket을 사용하는 것입니다. 그래도 D가 제공된 선택지 중 가장 정답에 가깝습니다. 주요 기능: Lifecycle rules는 object를 age 기준으로 Nearline, Coldline, Archive로 전환할 수 있으며, 이는 Cloud Storage에서 스토리지 비용을 최적화하는 표준적이고 오버헤드가 낮은 방법입니다. Object holds는 hold가 유지되는 동안 삭제를 방지할 수 있고, retention policies는 bucket 수준에서 최소 보관 기간을 강제할 수 있습니다. Bucket Lock은 retention policy를 변경 불가능하게 만들며, 이는 규제 대상 증거 보관을 위한 일반적인 WORM/compliance 메커니즘입니다. 흔한 오해: Object Versioning은 immutability와 동일하지 않습니다. retention controls로 보호되지 않으면 version도 여전히 삭제될 수 있기 때문입니다. CMEK는 encryption keys와 암호화된 데이터에 대한 access를 관리하지만, retention을 강제하거나 object 삭제를 방지하지는 않습니다. Cloud Storage lifecycle rules가 이미 관리형 전환을 제공하므로 Cloud Run을 사용한 custom automation은 불필요합니다. 시험 팁: 문제가 비용 최소화와 custom code 회피를 강조하면 custom job이나 function보다 lifecycle management를 우선 고려하세요. 문제가 수년간의 immutable retention을 언급하면, 먼저 retention policy와 Bucket Lock을 떠올리고, object holds는 관련은 있지만 덜 완전한 제어 수단으로 보세요. 정확히 이상적인 기능이 선택지에 없으면, 올바른 기본 제어 계열을 사용하고 관련 없는 서비스를 피하는 선택지를 고르세요.

14
문제 14

You manage an energy utility that ingests approximately 8 million smart meter readings per day into BigQuery for billing and analytics. A new compliance rule requires that all meter readings be retained for a minimum of seven years for auditability while keeping storage cost and operations overhead low; what should you do?

정답입니다. reading_date 기준 partitioning은 시간 기반 보존과 효율적인 쿼리를 지원합니다. Partition expiration을 7년으로 설정하면 7년보다 오래된 partition만 자동으로 삭제되어, 신규 일일 ingest를 위한 테이블 활성 상태를 유지하면서 최소 보존 요구사항을 충족합니다. 이는 운영 오버헤드(커스텀 정리 작업 불필요)를 최소화하고, partition pruning을 통해 쿼리 비용을 줄일 수 있습니다.

오답입니다. Table-level expiration은 7년 후 전체 테이블을 삭제합니다. meter reading을 지속적으로 ingest하는 시스템에서는 결국 과거 및 현재 데이터가 한 번에 모두 제거되어 billing/analytics 워크플로를 깨뜨립니다. Rolling retention window를 구현하지 못하며, 규제 대상 장기 데이터셋이 아니라 임시 또는 단기 테이블을 위한 기능입니다.

오답입니다. Dataset-level default table expiration은 dataset 내 새로 생성되는 테이블에 TTL을 적용하여 7년 후 전체 테이블을 삭제합니다. 이는 중요한 테이블을 의도치 않게 삭제할 수 있어 위험하며, 테이블 내부의 오래된 데이터만 rolling 방식으로 삭제하는 기능도 제공하지 않습니다. 시계열 데이터에 대한 컴플라이언스 보존이 아니라 임시 테이블 난립을 제어하는 데 더 적합합니다.

“낮은 운영 오버헤드” 및 BigQuery에서의 1차 보존 관점에서 오답입니다. 매일 Cloud Storage로 export하고 lifecycle/retention rules를 적용하면 파이프라인 복잡도, 모니터링, 감사/analytics를 위한 rehydration 단계가 추가됩니다. Cloud Storage retention policies가 컴플라이언스를 지원할 수는 있지만, 시스템을 archival storage 쪽으로 이동시키고 BigQuery partition expiration을 직접 사용하는 것에 비해 쿼리를 복잡하게 만듭니다.

문제 분석

핵심 개념: 이 문제는 최소한의 운영 오버헤드와 통제된 비용으로 장기 보존을 위한 BigQuery 데이터 라이프사이클 관리를 평가합니다. 핵심 기능은 partitioned tables와 partition expiration (TTL)이며, 이는 partition 수준에서 데이터 보존을 자동화합니다. 정답이 맞는 이유: reading_date로 partitioned된 테이블을 생성하고 partition expiration을 7년으로 설정하면, 규정 준수 요구사항(최소 7년 보존)을 충족하면서 운영을 낮게 유지할 수 있습니다. Partition expiration은 설정된 기간보다 오래된 partition만 자동으로 삭제하므로, 수동 정리 작업 없이도 테이블을 지속적인 ingestion과 analytics에 사용할 수 있습니다. 이는 Google Cloud Architecture Framework의 운영 우수성(자동화) 및 비용 최적화(불필요한 storage 자동 제거) 원칙과 일치합니다. 핵심 기능 / 모범 사례: - 날짜 컬럼(예: reading_date) 기준 partitioning은 시계열 meter 데이터에 대한 표준 BigQuery 패턴입니다. Partition pruning(쿼리가 관련 partition만 스캔)을 가능하게 하여 쿼리 성능과 비용을 개선합니다. - Partition expiration은 partition 수준에서 retention policy를 적용하므로 “rolling window” 보존 요구사항에 이상적입니다. - 이를 clustering(예: meter_id 기준)과 결합하면 일반적인 접근 패턴에서 쿼리 스캔 비용을 추가로 줄일 수 있습니다. - BigQuery storage는 managed입니다. 내장 TTL을 사용하면 export pipeline이나 lifecycle script를 구축하고 유지할 필요가 없습니다. 흔한 오해: 옵션 B와 C는 “7년 보존”을 충족하는 것처럼 보이지만, table expiration은 전체 테이블을 한 번에 삭제하므로 지속적인 ingestion과 지속적인 analytics와 양립할 수 없습니다. Dataset default expiration도 유사하게 위험한데, 많은 테이블에 의도치 않게 적용될 수 있으며, 오래된 데이터만이 아니라 전체 테이블을 삭제하기 때문입니다. 시험 팁: - 지속적으로 증가하는 시계열 테이블에서 “데이터를 N년 보관” 요구사항이 나오면: partitioned table + partition expiration을 떠올리세요. - Table/dataset expiration은 테이블이 완전히 사라져야 하는 임시 테이블(예: staging, scratch, intermediate results)에 사용하고, 규제 대상 rolling retention에는 사용하지 마세요. - Cloud Storage로 export는 아카이빙 또는 cross-system 요구에 유용하지만, BigQuery에 데이터를 유지하는 것에 비해 운영 복잡도를 높이고 대화형 analytics를 방해할 수 있습니다.

15
문제 15

A media analytics startup operates an existing Dataproc cluster (1 master, 3 workers) that runs Spark batch jobs on roughly 60 GB of log files stored in Cloud Storage, and they must generate a daily summary CSV at 06:00 UTC and email it to 20 regional managers; they want a fully managed, easy-to-implement approach that minimizes operational overhead and avoids standing up a separate orchestration platform—what should they do?

Cloud Composer는 Spark job과 후속 email delivery를 orchestration할 수 있지만, managed Airflow environment이므로 별도의 orchestration platform입니다. 이는 별도의 orchestrator를 구축하지 않고 operational overhead를 낮게 유지해야 한다는 요구 사항과 직접적으로 충돌합니다. Composer는 여러 시스템 전반에서 복잡한 cross-service DAG, branching, 풍부한 workflow management가 필요할 때 더 적합합니다.

Dataproc workflow templates는 반복 가능하고 파라미터화된 멀티 스텝 workflow(예: Spark job 후 post-step)를 정의하는 Dataproc-native 방식입니다. workflow를 scheduling하면 orchestration을 managed로 유지하면서 compute platform에 가깝게 두고, 매일 06:00 UTC 요구사항을 충족합니다. 이메일 배포를 트리거하는 가벼운 최종 step을 추가하면 별도의 orchestration product를 도입하지 않고도 리포팅 요구사항을 만족할 수 있습니다.

Cloud Run은 custom logic에 유용하며 Dataproc API를 호출하거나 email을 보낼 수 있지만, 그 자체로는 built-in cron-style scheduling을 제공하지 않습니다. 여전히 Cloud Scheduler 또는 다른 trigger가 필요하며, job submission, monitoring, failure handling을 위한 code를 작성해야 합니다. 이는 Dataproc 중심의 batch pipeline에 Dataproc workflow template를 사용하는 것보다 더 많은 custom integration 작업이 필요합니다.

Cloud Scheduler와 Cloud Run을 함께 사용하여 processing을 트리거하고 email을 보내는 것은 분명 가능합니다. 하지만 job submission, completion tracking, retries, error handling을 위해 여러 서비스를 custom code로 연결해야 합니다. 따라서 Dataproc 측 processing을 캡슐화하는 Dataproc workflow template를 사용하는 것보다 운영 측면에서 더 복잡합니다. 유효한 architecture이기는 하지만, 단순한 일일 batch report에 대해 가장 쉽거나 Dataproc-native한 선택은 아닙니다.

문제 분석

핵심 개념: 이 문제는 별도의 orchestration platform을 도입하지 않고 Dataproc batch workload에 대해 managed orchestration을 구현하는지를 평가합니다. 핵심 서비스는 Dataproc Workflow Templates(멀티 스텝 job을 정의하고 실행)와 Dataproc scheduling(주기적으로 실행)이며, 여기에 결과를 배포하기 위한 간단한 post-processing step이 추가됩니다. 정답이 맞는 이유: Option B가 요구사항에 가장 부합합니다: fully managed, 구현이 쉽고, 운영 오버헤드가 최소이며, 별도의 orchestration platform이 필요 없습니다. Dataproc workflow template은 Cloud Storage에서 약 60 GB를 읽고 일일 요약 CSV를 쓰는 Spark job을 캡슐화할 수 있습니다. 그런 다음 workflow를 06:00 UTC에 실행되도록 schedule할 수 있습니다. CSV가 생성된 후 이메일 배포를 트리거하기 위해 가벼운 최종 step(예: 작은 PySpark job, HTTP endpoint를 호출하는 Dataproc job, 또는 간단한 script action/job step)을 추가할 수 있습니다. 이렇게 하면 외부 orchestrator를 구축·운영하지 않고 orchestration을 Dataproc “내부”에 유지할 수 있습니다. 주요 기능 / Best Practices: - Dataproc Workflow Templates는 파라미터(input path, output path, date partition)를 포함한 DAG-like job 시퀀스를 정의할 수 있어, 파이프라인을 반복 가능하고 감사 가능하게 만듭니다. - workflow를 scheduling하면 매일 06:00 UTC 요구사항에 맞춘 시간 기반 자동화를 제공합니다. - email step은 가볍고 decoupled하게 유지하세요: Cloud Storage에 CSV를 생성한 뒤 링크/첨부로 전송합니다. 실무에서는 최종 step에서 작은 HTTP service(또는 간단한 mail API)를 호출하는 경우가 많습니다. - Google Cloud Architecture Framework 원칙에 부합: operational excellence(managed control plane), reliability(반복 가능한 templates), cost optimization(항상 켜진 orchestration 인프라를 추가하지 않고 기존 cluster 재사용). 흔한 오해: Cloud Composer(A)는 강력하지만, 추가 설정, DAG 관리, 지속적인 운영 고려사항이 필요한 별도의 orchestration platform(managed Airflow)입니다. Cloud Scheduler + Cloud Run(D)도 가능하지만 여러 서비스를 도입하고 custom glue logic이 필요해 구현 및 유지보수 오버헤드가 증가합니다. Cloud Run 단독(C)은 자체적으로 “스스로 schedule”할 수 없으며 Scheduler 또는 다른 trigger가 여전히 필요합니다. Exam Tips: 문제에서 “별도의 orchestration platform을 구축하는 것을 피하라”고 하고 workload가 Dataproc 기반이라면, 먼저 Dataproc-native orchestration(workflow templates)과 managed scheduling을 찾으세요. 복잡한 cross-service DAG가 필요할 때는 Composer를 사용하고, 여러 서비스에 걸친 lightweight trigger가 필요하며 더 많은 custom integration 작업을 감수할 수 있을 때는 Scheduler/Run을 사용하세요.

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

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

16
문제 16

A national retail chain stores background checks and performance notes for 12,000 employees in BigQuery; compliance requires that within 24 hours of termination, the personal records of the departing employee must be rendered irreversibly unreadable while keeping the data stored for 7 years for audit purposes and without affecting access to other employees’ records—what should you do?

정답입니다. BigQuery AEAD functions는 직원별 키를 사용해 특정 컬럼을 application/SQL 수준에서 암호화할 수 있습니다. 퇴사한 직원의 키만 삭제하면 해당 직원의 암호화된 필드는 영구적으로 읽을 수 없게 되지만, 다른 직원의 데이터는 계속 접근 가능합니다. 이는 24시간 내 비가역성 요구사항을 충족하고 7년 보관을 위한 ciphertext를 유지합니다. 또한 비민감 컬럼에 대한 쿼리를 방해하지 않으며, 엔터티 수준의 세밀한 crypto-shredding을 지원합니다.

오답입니다. Dynamic data masking은 쿼리 시점에 특정 사용자가 볼 수 있는 내용을 바꾸는 것으로, authorization/presentation control이지 비가역적 파기가 아닙니다. 퇴사자의 권한을 회수하는 것은 관련이 없습니다. 위협 모델이 퇴사자가 아니라, 규정 준수 관점에서 조직이 authorized internal users에게도 데이터를 읽을 수 없게 만들어야 하기 때문입니다. Privileged users는 여전히 unmasked data에 접근할 수 있고, 기본 저장 데이터는 읽을 수 있는 상태로 남습니다.

오답입니다. dataset/table에 대한 단일 CMEK는 모든 데이터를 동일한 키로 암호화합니다. 그 CMEK를 삭제하면 전체 dataset이 읽을 수 없게 되어 다른 직원 레코드에 대한 접근까지 영향을 주며, 다른 사람에게 영향을 주지 말라는 요구사항을 위반합니다. CMEK는 customer-controlled encryption과 key rotation에는 훌륭하지만, 직원별로 테이블/dataset을 분리(비현실적)하지 않는 한 직원별 selective crypto-shredding을 제공하지 못합니다.

오답입니다. policy tags를 사용한 column-level access controls는 어떤 principal이 민감 컬럼을 볼 수 있는지 제한하지만, 데이터를 비가역적으로 읽을 수 없게 만들지는 않습니다. 퇴사자의 권한을 회수하는 것 역시 요구사항을 놓칩니다. 회사는 기한 이후 누구도 퇴사자의 개인 기록을 읽을 수 없도록 보장하면서도, 감사 목적의 저장 데이터는 유지해야 합니다. Policy tags는 governance와 least privilege를 위한 것이지, cryptographic erasure를 위한 것이 아닙니다.

문제 분석

핵심 개념: 이 문제는 BigQuery에서의 crypto-shredding(cryptographic erasure)을 테스트합니다. 즉, 규정 준수/감사 보관을 위해 기본 저장 데이터는 유지하면서, 특정 레코드를 되돌릴 수 없게 읽을 수 없도록 만드는 것입니다. 핵심 아이디어는 삭제 요구사항(직원별)에 맞는 세분성으로 암호화한 다음, 해당 키만 파기하는 것입니다. 정답이 맞는 이유: 옵션 A는 BigQuery AEAD functions를 사용해 민감 필드(예: background check 세부 정보, performance notes)를 직원별(per-employee) 키로 암호화합니다. 직원이 퇴사하면 해당 직원의 key material(일반적으로 Cloud KMS 또는 외부 key store에 저장)을 삭제합니다. 키가 없으면 ciphertext는 BigQuery에 7년 동안 남아 있어도 복호화는 계산적으로 사실상 불가능해져 “24시간 내 되돌릴 수 없게 읽을 수 없음” 요구사항을 충족합니다. 동시에 다른 직원의 레코드는 그들의 키가 영향을 받지 않으므로 계속 복호화 가능합니다. 주요 기능 / 구현 방법: - BigQuery AEAD functions(예: AEAD.ENCRYPT/DECRYPT)를 사용해 민감 컬럼만 암호화하고, 비민감 필드(employee_id, 날짜, metadata)는 쿼리 가능하게 유지합니다. - 직원별 키를 안전하게 저장합니다(Cloud KMS, 또는 envelope encryption: 직원별 DEK를 KMS의 KEK로 wrapping). 직원별 키를 삭제/retire하거나 wrapped DEK를 파기하면 crypto-shredding이 달성됩니다. - HR 퇴사 이벤트로 트리거되는 workflow/automation(예: Cloud Scheduler + Cloud Functions/Run)으로 24시간 내 키 삭제를 자동화합니다. - 이는 Google Cloud Architecture Framework의 보안 원칙(least privilege, 강력한 key management, compliance 및 auditability를 고려한 설계)과 정렬됩니다. 흔한 오해: 많은 사람들이 access controls(masking, policy tags, IAM revocation)가 “되돌릴 수 없게 읽을 수 없음”을 충족한다고 생각하지만, 그렇지 않습니다. admin 또는 privileged user가 여전히 데이터에 접근할 수 있고, 데이터는 원칙적으로 읽을 수 있는 상태로 남습니다. 또 다른 오해는 CMEK deletion이 타겟팅된 해결책이라는 점인데, BigQuery에서 CMEK는 dataset/table 수준에 적용되므로 이를 삭제하면 해당 키로 암호화된 모든 데이터에 영향을 줍니다. 시험 팁: “X년 동안 데이터는 유지하되 빠르게 읽을 수 없게 하라”를 보면 crypto-shredding을 떠올리세요. 키 범위(scope)가 삭제 범위(scope)(row/entity별)와 일치하는 접근을 선택해야 합니다. BigQuery AEAD는 selective key destruction이 가능한 field-level encryption의 전형적인(시험 친화적인) 패턴이며, IAM/masking controls는 authorization을 위한 것이지 irreversible destruction을 위한 것이 아닙니다.

17
문제 17

Your e-commerce platform streams about 15 million clickstream events per day into a BigQuery table (analytics.clicks_raw) that is partitioned by ingestion time; to reduce storage costs and meet a retention policy, you must automatically remove any data older than 180 days with minimal ongoing maintenance and query overhead; what should you do?

오답입니다. 행을 표시하는 scheduled UPDATE는 실제 삭제가 아니며, 지속적인 유지보수(scheduled jobs)와 쿼리 복잡도(view 사용 또는 predicate 추가)를 증가시킵니다. 대규모 테이블에서 BigQuery DML은 비용이 클 수 있고 변경된 블록 때문에 스토리지가 증가할 수도 있습니다. 또한 실제로 데이터/파티션을 삭제하지 않는 한 스토리지 감소를 보장하지 않습니다.

오답입니다. 180일보다 오래된 행을 필터링하는 view는 쿼리 시점에 데이터만 숨길 뿐, 기본 파티션을 제거하거나 스토리지 비용을 줄이지 않습니다. 또한 사용자가 base table이 아니라 해당 view를 쿼리한다는 전제에 의존하며, 데이터가 계속 저장되므로 컴플라이언스/보존 요구사항도 충족되지 않습니다.

오답입니다. partition filter를 요구하는 설정은 실수로 인한 전체 테이블 스캔을 방지하기 위한 비용 제어 및 성능 보호 장치입니다. 오래된 파티션을 삭제하거나 보존 정책을 강제하지 않습니다. 보완 설정으로는 유용할 수 있지만, 단독으로는 180일보다 오래된 데이터를 자동으로 제거해야 한다는 요구사항을 충족하지 못합니다.

정답입니다. ingestion-time 파티션 테이블에서 파티션 만료 기간을 180일로 설정하면 BigQuery가 180일보다 오래된 파티션을 자동으로 삭제합니다. 이는 보존을 강제하고 스토리지 비용을 줄이며, 지속적인 유지보수가 거의 필요하지 않습니다. 또한 추가 필터링 로직이 필요 없으므로 쿼리 오버헤드를 피할 수 있습니다—만료된 파티션은 단순히 더 이상 존재하지 않습니다.

문제 분석

핵심 개념: 이 문제는 BigQuery 시간 파티션 테이블의 라이프사이클 관리—특히 파티션 만료(TTL)를 사용해 보존 기간(retention)을 강제하고 운영 오버헤드를 최소화하면서 스토리지 비용을 줄이는 방법—을 평가합니다. 정답이 맞는 이유: analytics.clicks_raw는 ingestion time 기준으로 파티션되어 있으므로, BigQuery는 구성된 기간을 초과한 전체 파티션을 자동으로 삭제할 수 있습니다. 파티션 만료 기간을 180일로 설정하면 180일보다 오래된 모든 파티션이 수동 작업 없이, 데이터를 다시 쓰지 않고, 쿼리 시점 필터를 추가하지 않고 제거됩니다. 이는 보존 정책(“180일보다 오래된 데이터를 자동으로 제거”)을 직접 충족하며, 오래된 파티션을 물리적으로 삭제하여 스토리지 비용을 절감합니다. 주요 기능 / Best Practices: - 파티션 만료(테이블 수준 파티션 TTL)는 파티션 테이블의 보존 정책을 위해 설계되었습니다. 행을 숨기는 것이 아니라 파티션을 삭제합니다. - ingestion-time partitioning과 특히 잘 맞는데, 파티션 경계가 load/stream ingestion time과 정렬되기 때문입니다. - 유지보수 최소화: 한 번 설정하면 BigQuery가 정리를 자동으로 처리합니다. - 쿼리 오버헤드 최소화: view나 추가 predicate가 필요 없으며, 쿼리는 자연스럽게 존재하는 파티션만 스캔합니다. (비용 제어를 위해 “require partition filter”를 함께 사용할 수는 있지만, 그것만으로는 보존을 구현하지는 않습니다.) - Google Cloud Architecture Framework 원칙과 정렬됩니다: 운영 우수성(자동화), 비용 최적화(스토리지 감소), 신뢰성(일관된 정책 강제). 흔한 오해: 오래된 데이터를 필터링하는 view(옵션 B)는 “보존”처럼 보일 수 있지만 데이터를 삭제하지 않으므로 스토리지 비용은 그대로이며 보존 정책도 진정으로 충족되지 않습니다. 마찬가지로 “require partition filter”(옵션 C)는 비용이 큰 전체 스캔을 방지하는 데 도움이 되지만 데이터를 제거하지는 않습니다. 행을 표시하기 위한 scheduled UPDATE(옵션 A)는 지속적인 오케스트레이션을 추가하고, 비용(DML 처리)을 증가시키며, 테이블 비대화를 유발할 수 있고, 이후에 delete/vacuum 유사 작업을 수행하지 않는 한 기본 데이터는 여전히 보존됩니다. 시험 팁: “partitioned table” + “retention policy” + “X일보다 오래된 데이터를 자동으로 제거” + “유지보수 최소”를 보면, BigQuery의 정석 답은 ALTER TABLE을 통한 파티션 만료(TTL)입니다. (1) 데이터 삭제(TTL)와 (2) 사용자가 보거나 스캔하는 범위만 제한(view/partition filter requirement)하는 것을 구분하세요.

18
문제 18

Your hospital analytics team receives a 5-GB daily CSV export (about 8 million rows, 30 columns) of patient-monitoring events in a Cloud Storage bucket and needs to load it into a partitioned BigQuery table for clinical KPI dashboards. You must stand up a scalable batch pipeline within one day that applies type casting and reference data joins, and that also provides built-in data quality insights (e.g., profiling of nulls, outliers, and schema anomalies) during ingestion; what should you do?

정답. Cloud Data Fusion은 Cloud Storage의 일일 CSV를 직접 수집하고, 스키마/타입 캐스팅을 적용하며, 내장 변환/커넥터를 사용해 참조 조인을 수행한 뒤, 파티션된 BigQuery 테이블에 기록할 수 있습니다. 이는 빠른 제공(시각적 파이프라인, 관리형 실행)에 최적화되어 있고, 파이프라인 개발/수집 중 데이터 프로파일링 및 데이터 품질 체크를 지원하므로 null, 이상치, 스키마 이상에 대한 내장 인사이트 요구사항과 일치합니다.

오답. BigQuery load jobs와 scheduled queries로 변환과 조인을 구현할 수는 있지만, 데이터 품질 프로파일링/인사이트가 수집 워크플로에 본질적으로 내장되어 있지는 않습니다. 추가 SQL 체크를 작성하고, 결과를 저장하며, monitoring을 직접 구축해야 합니다. 단순 ELT에는 동작할 수 있으나, 하루 안에 수집 중 null/이상치/스키마 이상에 대한 내장 프로파일링 요구사항을 가장 잘 충족하지는 못합니다.

오답. 먼저 CSV를 BigQuery에 로드한 다음 BigQuery에서 BigQuery로 Data Fusion을 사용하는 방식은 불필요한 스테이징 단계를 추가하고 스토리지/처리를 중복시킵니다. 또한 초기 로드 이후에야 데이터 품질 인사이트를 제공하게 되어 “수집 중(during ingestion)”과 충돌합니다. Data Fusion을 선택한다면 일반적으로 Cloud Storage에서 직접 수집하고, 정제된 파티션 테이블에 적재하기 전에 변환을 적용하는 것이 보통입니다.

오답. Dataflow templates(Cloud Storage CSV to BigQuery)는 확장 가능한 수집을 제공하지만, 주로 데이터 이동과 기본 파싱에 초점이 맞춰져 있습니다. 참조 데이터 조인, 특히 내장 프로파일링/품질 인사이트(null/이상치/스키마 이상 리포팅)를 구현하려면 일반적으로 커스텀 Apache Beam 코드와 추가 monitoring/quality 프레임워크가 필요합니다. 이는 제공 시간과 복잡도를 증가시켜 “하루 안에” 및 “내장 데이터 품질 인사이트” 요구사항에 덜 적합합니다.

문제 분석

핵심 개념: 이 문제는 BigQuery로의 수집 과정에서 내장된 데이터 품질 및 프로파일링을 제공하면서, 빠르게 구축할 수 있는 배치 수집 및 변환 서비스를 선택하는지를 평가합니다. 핵심 서비스는 Cloud Data Fusion(시각적 파이프라인을 갖춘 관리형 ETL/ELT)과 BigQuery(파티션 기반 분석 스토리지)입니다. 정답이 맞는 이유: Cloud Data Fusion은 Cloud Storage에서 BigQuery로 확장 가능한 배치 파이프라인을 빠르게 구축하도록 설계되었으며, 타입 캐스팅과 참조 데이터 조인 같은 변환을 지원합니다. 특히 Data Fusion은 데이터 준비 및 데이터 품질 기능(Wrangler 및 Cloud Data Quality 기능/플러그인)을 내장하고 있어, 파이프라인 개발 및 검증 과정의 일부로 null, 스키마 드리프트/이상, 분포/이상치 패턴에 대한 데이터셋 프로파일링을 수행할 수 있습니다. “하루 안에”라는 요구사항 관점에서, 로우코드 UI, 사전 구축된 커넥터, 관리형 런타임은 커스텀 Dataflow 코드 대비 엔지니어링 시간을 줄여줍니다. 주요 기능 / 모범 사례: - CSV 파싱과 스키마 매핑을 포함한 Cloud Storage 소스를 사용하고, 변환 단계에서 타입 캐스팅을 적용합니다. - 조인/룩업 변환을 사용해 참조 데이터(종종 BigQuery 테이블에 저장됨)와 조인합니다. - 파티션된 BigQuery 테이블(일반적으로 ingestion-time 또는 event-date 파티셔닝)에 기록하고 write disposition을 구성합니다. - 개발 중 및/또는 파이프라인 단계로 데이터 품질 체크/프로파일링을 활성화하고, 운영 가시성을 위해 메트릭을 logs/monitoring으로 수집합니다. - Google Cloud Architecture Framework에 정렬: 운영 우수성(관리형 서비스, monitoring), 신뢰성(반복 가능한 배치 실행), 보안(최소 권한 service accounts, 헬스케어 요구 시 CMEK). 흔한 오해: BigQuery scheduled queries(옵션 B)는 로드 이후 변환을 수행할 수 있지만, 추가 도구 없이 수집 시점의 프로파일링/품질 인사이트를 본질적으로 제공하지는 않습니다. Dataflow templates(옵션 D)는 확장성이 뛰어나지만, 템플릿은 이동과 기본 파싱에 초점이 있으며, 견고한 프로파일링/품질은 보통 커스텀 Beam 로직 또는 추가 제품이 필요해 “하루 안에” 제공하기 어렵습니다. 먼저 BigQuery로 로드한 뒤 Data Fusion을 사용하는 방식(옵션 C)은 불필요한 스테이징 단계를 추가하고 초기 로드 이후에야 품질 인사이트를 얻어 지연을 초래합니다. 시험 팁: 문제에서 “빠르게 구축”, “내장 커넥터”, “data quality/profiling”을 강조하면 Cloud Data Fusion을 떠올리세요. “대규모에서의 커스텀 로직”과 엔지니어링 중심 파이프라인을 강조하면 Dataflow/Beam을 떠올리면 됩니다. 또한 “수집 중(during ingestion)”과 “데이터 품질 인사이트”는 순수 SQL 스케줄링보다는 Data Fusion의 데이터 준비 및 품질 도구를 강하게 시사합니다.

19
문제 19

At a university, you store 120,000 course-enrollment records in a BigQuery table university.enrollments partitioned by term, with a STRING column dept_code (e.g., BIO, CHEM, MATH) indicating the student’s department; you must ensure that each academic advisor—who belongs to a Google Group mapped to a single department—can run queries against the table but only see rows where dept_code matches their department, without creating per-department tables or requiring query changes—what should you do?

오답. BigQuery의 policy tags( Data Catalog를 통해)는 column-level 보안을 제공합니다. 즉, column 값을 볼 수 있는 사용자를 제어할 뿐, 어떤 row가 반환되는지는 제어하지 않습니다. dept_code에 태그를 달면 일부 사용자에게 dept_code column을 숨길 수는 있지만, 자문위원이 자신의 부서 레코드만 보도록 row를 자동 필터링하지는 못합니다. 또한 group-to-department 기반 row 필터링을 구현하지도 않습니다.

정답. BigQuery row-level security는 테이블에 연결된 row access policy를 사용합니다. dept_code로 필터링하는 정책을 만들고 각 정책을 해당 Google Group(부서당 group 1개)에 부여할 수 있습니다. 자문위원은 university.enrollments에 대해 변경 없는 쿼리를 실행할 수 있고, BigQuery가 row filter를 자동으로 강제 적용하여 해당 사용자/group에 허용된 row만 반환합니다.

오답. Dynamic data masking은 사용자에 따라 민감한 column 값이 표시되는 방식을 변경합니다(예: null 처리, hashing, 부분 공개). 하지만 전체 row에 대한 액세스를 제한하지는 않습니다. dept_code를 masking하더라도 자문위원은 다른 부서의 enrollment row를 볼 수 있으며(단지 dept_code만 마스킹됨), 이는 일치하는 row만 보게 해야 한다는 요구사항을 위반합니다.

오답. Dataset(또는 table)에 BigQuery Data Viewer를 부여하면 테이블의 모든 row에 대한 읽기 액세스가 제공됩니다. 이는 coarse-grained IAM이며 부서별 row 필터링을 강제하지 않습니다. 쿼리를 가능하게 해준다는 점에서 매력적으로 보일 수 있지만, 자문위원의 부서에만 가시성을 제한해야 한다는 핵심 보안 요구사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 BigQuery의 세분화된 액세스 제어, 특히 row access policy를 사용하는 row-level security(RLS)를 테스트합니다. 요구사항은 자문위원(advisor)이 쿼리를 변경하지 않고 동일한 테이블을 조회할 수 있게 하되, 부서(dept_code)와 Google Group 멤버십에 따라 볼 수 있는 row를 제한하는 것입니다. 정답이 맞는 이유: BigQuery row access policy를 university.enrollments에 연결하고 dept_code = "BIO" 같은 filter predicate를 설정한 뒤, 해당 정책을 대응하는 Google Group(예: advisors-bio@)에 부여할 수 있습니다. 부서별 group마다 정책을 하나씩 생성합니다. 자문위원이 테이블에 대해 어떤 쿼리를 실행하더라도 BigQuery가 정책을 자동으로 강제 적용하여 해당 principal에 허용된 row만 반환합니다. 이는 모든 제약을 충족합니다: 부서별 테이블 분리 없음, 쿼리 재작성 없음, 그리고 스토리지/엔진 레벨에서 액세스가 강제됨. 주요 기능 및 모범 사례: Row access policy는 쿼리 시점에 BigQuery가 평가하며, 사용자가 BigQuery를 직접 쿼리하는 한( Console, BI tools, notebooks 등) 도구 전반에서 일관되게 적용됩니다. 관리 용이성(least privilege)을 위해 Google Groups를 사용하고, Google Cloud Architecture Framework의 보안 원칙인 중앙집중식 ID 및 정책 기반 액세스와 정렬하세요. Dataset/table IAM은 최소로 유지하고(예: dataset/table 레벨에서 BigQuery Data Viewer 부여) 데이터 레벨 제한은 row policy에 의존하세요. 대표 사용자로 테스트하고, term 기준 partitioning이 보안과 독립적임을 확인하세요( partitioning은 성능/비용을 위한 것이지 액세스 제어가 아님). 흔한 오해: Column-level 제어( policy tags)와 dynamic data masking은 column 값을 보호하거나 변환할 뿐, 반환되는 row 자체를 제한하지는 않습니다. Dataset-level IAM( Data Viewer)은 테이블의 모든 row에 대한 액세스를 부여하므로 요구사항을 위반합니다. 시험 팁: 요구사항이 “같은 테이블, 같은 쿼리, 하지만 사용자마다 다른 row가 보이게”라면 BigQuery Row-Level Security( row access policies)를 떠올리세요. “column을 숨기거나 분류”라면 policy tags 또는 masking을 떠올리세요. 항상 제어를 범위에 매핑하세요: IAM(리소스), policy tags/masking(column), RLS(row).

20
문제 20

Your IoT-based fleet tracking platform streams about 50,000 GPS events per minute (peaks to 120,000/min) that must be deduplicated, validated, and enriched by joining each event with a 2,000-row region-code lookup, with an end-to-end latency target under 2 seconds; the cleaned, enriched data will be stored for ad hoc SQL analysis and to train weekly forecasting models, so you must choose the appropriate data manipulation approach and Google Cloud services for this pipeline—what should you select?

Dataflow streaming은 deduplication, validation, enrichment 같은 저지연 변환을 위해 목적에 맞게 설계되었습니다. 2,000-row lookup은 side input/broadcast join으로 이상적이며, 느린 외부 join을 피할 수 있습니다. BigQuery는 ad hoc SQL에 적합한 sink이며 ML training workflow의 공통 기반이기도 합니다. 이 ETL 패턴은 2초 미만 latency 목표를 충족하고 autoscaling과 Storage Write API로 피크 throughput까지 확장됩니다.

Cloud Data Fusion은 batch pipeline, CDC, orchestrated transformations에 가장 적합한 관리형 ETL/ELT 도구이지만, 높은 event rate에서 엄격한 2초 미만 streaming enrichment 및 dedup의 1차 선택지인 경우는 일반적이지 않습니다. 또한 curated output을 Cloud Storage에 쓰는 것은 추가 query engine(BigQuery external tables, Dataproc 등) 없이는 “ad hoc SQL analysis”를 직접 충족하지 못하며, 이는 latency와 복잡성을 증가시킵니다.

Cloud Storage 다음 Bigtable로 ELT를 하는 것은 제시된 목표와 맞지 않습니다. Bigtable은 key/value access pattern에 최적화된 저지연 operational NoSQL database이지, ad hoc SQL analytics용이 아닙니다. 또한 ELT는 로드 후 변환을 의미하지만, 요구사항은 end-to-end 2초 미만으로 deduplicate/validate/enrich를 수행하는 것입니다. raw 데이터를 storage에 먼저 적재한 뒤 처리하면 보통 latency와 운영 복잡성이 증가합니다.

Cloud SQL은 저지연으로 고속 IoT event stream을 ingest 및 처리하기에 적절하지 않으며 bottleneck이 될 수 있고, 이 규모의 streaming transformations를 위해 설계되지 않았습니다. Analytics Hub는 data sharing/exchange 서비스이지, streaming events의 pipeline processing 또는 storage 목적지가 아닙니다. 이 선택지는 real-time deduplication/enrichment나 ad hoc SQL 및 ML training을 위한 analytical warehouse 요구를 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 ETL vs ELT 선택과, 이벤트별 변환(중복 제거, 검증, lookup join을 통한 enrichment)을 수행하면서 2초 미만의 지연 시간을 만족하는 올바른 streaming 서비스를 선택하고, SQL 분석 및 ML 학습을 위한 curated 데이터를 적재하는 능력을 평가합니다. 정답이 맞는 이유: Dataflow streaming에서 BigQuery로 적재하는 ETL 접근이 요구사항에 가장 잘 부합합니다. Dataflow(Apache Beam)는 고처리량, 저지연 stream processing을 위해 설계되었고 autoscaling으로 50k events/min, 피크 120k events/min(초당 약 2,000 events)까지 처리할 수 있습니다. 또한 event-time processing, windowing, stateful processing을 지원하여 deduplication(예: keys + timers/state 사용)과 validation을 수행할 수 있습니다. 2,000-row region-code lookup은 side input(broadcast) 또는 주기적으로 갱신되는 in-memory map으로 구현하기에 충분히 작아, 외부 왕복 호출 없이 빠른 enrichment join이 가능합니다. BigQuery는 ad hoc SQL 분석의 대상이며, 주간 모델 학습(예: BigQuery ML 또는 Vertex AI pipelines로 export)에도 흔히 사용되므로 적절한 analytical store입니다. 주요 기능 / Best Practices: - autoscaling과 Streaming Engine을 사용하는 Dataflow streaming pipeline로 더 낮은 latency와 향상된 throughput 달성. - state size를 제어하기 위해 TTL을 적용한 device/event id 기준 keyed stateful DoFn으로 deduplication 수행. - side inputs(작은 lookup) 또는 BigQuery/Cloud Storage에서 주기적으로 갱신되는 lookup을 통해 enrichment 수행. - 더 높은 throughput과 더 낮은 latency를 위해 Storage Write API로 BigQuery에 write. - exactly-once/at-least-once 현실을 고려: BigQuery에서 중복을 방지하기 위해 idempotent writes와 unique keys 사용. 이는 Google Cloud Architecture Framework 원칙인 reliability(관리형 autoscaling, fault tolerance), performance(저지연 streaming), operational excellence(관리형 서비스, monitoring)와 정렬됩니다. 흔한 오해: ELT는 BigQuery가 로드 후 변환을 수행할 수 있어 매력적이지만, end-to-end 2초 미만의 latency와 real-time dedup/validation/enrichment 요구사항은 curated table에 적재하기 전에 stream 내에서 변환하는 방식이 더 적합합니다. Cloud Data Fusion은 batch/CDC 및 orchestration에 강점이 있지만, 이 규모에서 sub-second streaming enrichment의 1차 선택지는 아닙니다. Bigtable은 ad hoc SQL 분석에 이상적이지 않고, Analytics Hub는 ingestion/processing이 아니라 data sharing을 위한 서비스입니다. 시험 팁: “streaming + low latency + 이벤트별 enrichment/dedup”을 보면 Dataflow를 떠올리세요. “ad hoc SQL analytics”를 보면 BigQuery를 떠올리세요. 작은 reference data(2,000 rows)는 Dataflow side inputs/broadcast join을 강하게 시사합니다. access pattern에 맞춰 storage를 매칭하세요: analytical queries와 ML feature extraction은 보통 operational NoSQL store보다 BigQuery를 가리킵니다.

모의고사

Practice Test #1

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

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Google Associate Cloud Engineer

Associate

Google Professional Cloud Network Engineer

Google Professional Cloud Network Engineer

Professional

Google Cloud Digital Leader

Google Cloud Digital Leader

Foundational

Google Professional Cloud Security Engineer

Google Professional Cloud Security Engineer

Professional

Google Professional Cloud Architect

Google Professional Cloud Architect

Professional

Google Professional Cloud Database Engineer

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Google Professional Cloud Developer

Professional

Google Professional Machine Learning Engineer

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

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

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.