GCP

Google Associate Data Practitioner

90+ 무료 연습 문제 (AI 검증 답안 포함)

모든 문제 & 정답 무료

상세 해설

실제 시험과 가장 유사

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

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

모의고사

Practice Test #1

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

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Associate

Google Professional Cloud Network Engineer

Professional

지금 학습 시작하기

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

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?

문제 분석

핵심 개념: 이 문제는 관리형 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

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 접근 제어 패턴을 평가합니다: 최소 권한 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을 게시하는 방식을 선호합니다.

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

문제 분석

핵심 개념: 이 문제는 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

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

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

문제 분석

핵심 개념: 이 문제는 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

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

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

문제 분석

핵심 개념: 이 문제는 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보다 이벤트 기반 트리거를 선호합니다.

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

문제 분석

핵심 개념: 이 문제는 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

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에 주로 사용하세요.

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

문제 분석

핵심 개념: 이 문제는 규정 준수 요구 사항을 충족하면서 스토리지 비용을 줄이기 위해 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

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를 방해할 수 있습니다.

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

문제 분석

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

문제 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에서의 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

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?

문제 분석

핵심 개념: 이 문제는 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

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?

문제 분석

핵심 개념: 이 문제는 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

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의 세분화된 액세스 제어, 특히 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

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?

문제 분석

핵심 개념: 이 문제는 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를 가리킵니다.