Google Associate Data Practitioner

Practice Test #1

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

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

기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

기출 문제

문제 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?

문제 분석

핵심 개념: 이 문제는 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을 떠올리세요.

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

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

← 모든 Google Associate Data Practitioner 문제 보기

지금 학습 시작하기

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

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

앱 받기

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

문제 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?

문제 분석

핵심 개념: 이 문제는 적절한 리소스 범위에서 최소 권한 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

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?

문제 분석

핵심 개념: 이 문제는 오픈 소스 도구를 사용해 기존 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

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, 그리고 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를 떠올리세요.

문제 5

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을 사용하여 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을 선호하세요.

문제 6

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?

문제 분석

핵심 개념: 이 문제는 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이 필요한 경우에만 선택하는 것이 좋습니다.

문제 7

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?

문제 분석

핵심 개념: 이 문제는 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에 주로 사용하세요.

문제 8

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?

문제 분석

핵심 개념: 이 문제는 규정 준수 요구 사항을 충족하면서 스토리지 비용을 줄이기 위해 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는 관련은 있지만 덜 완전한 제어 수단으로 보세요. 정확히 이상적인 기능이 선택지에 없으면, 올바른 기본 제어 계열을 사용하고 관련 없는 서비스를 피하는 선택지를 고르세요.

문제 9

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?

문제 분석

핵심 개념: 이 문제는 최소한의 운영 오버헤드와 통제된 비용으로 장기 보존을 위한 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를 방해할 수 있습니다.

문제 10

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?

문제 분석

핵심 개념: 이 문제는 별도의 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을 사용하세요.