Complete materials for Google Cloud Data Engineer (GCDE) & Database Engineer (GCDBE). One slide per row.Google Cloud Data Engineer (GCDE) · Database Engineer (GCDBE) 전체 장표 모음이에요. 한 줄에 한 장씩 연결돼요.
| No.번호 | Page페이지 | Description내용 | Link바로가기 |
|---|---|---|---|
| 1 | Course Overview (Cover)과정 소개 (첫장) | Google Cloud Data & Database Engineer 4-Day Course CoverGoogle Cloud Data & Database Engineer 4일 완성 과정 표지 | daunlee.com/g/data/1 ↗ |
| 2 | Data Pipeline Architecture Diagram데이터 파이프라인 아키텍처 개념도 | OLTP Ingestion ➔ OLAP (Lake · Warehouse · Lakehouse) ➔ AI SystemsOLTP 생성 ➔ OLAP(Lake · Warehouse · Lakehouse) ➔ AI 활용 흐름도 | daunlee.com/g/data/2 ↗ |
| 3 | Google Cloud Data Platform Concept (Mindmap)Google Cloud Data Platform Concept (마인드맵) | Core terminology across 6 pipeline stages · Principles · Interview points & GCP · Azure · AWS mindmap데이터 파이프라인 6대 단계별 핵심 용어 · 원리 · 인터뷰 포인트 & GCP · Azure · AWS(#gcp·#azure·#aws) 마인드맵 | daunlee.com/g/data/3 ↗ |
| 4 | GCP Current vs Legacy Terminology TableGCP 최신 · 이전 용어 비교표 | GCDE · GCDBE official current names mapped to legacy names and 32 open source equivalents · Excel downloadGCDE · GCDBE 현재·이전 명칭과 오픈소스 기술 32선 매핑 · 엑셀 다운로드 | daunlee.com/g/data/4 ↗ |
| 5 | 3-Cloud CSP Product Comparison TableCSP 3사 클라우드 제품 비교표 | 1:1 mapping of Google Cloud · Microsoft Azure · AWS Data, DB, AI, and Infra servicesGoogle Cloud · Microsoft Azure · AWS 데이터 · DB · AI 제품 1:1 매핑 | daunlee.com/g/data/5 ↗ |
| 6 | Data Pipeline Architecture Map (GCDE)데이터 파이프라인 지도 (GCDE) | End-to-end data pipeline flow from on-premises & multicloud into BigQuery for analytics & AI사내 · 타 클라우드 데이터가 BigQuery로 모여 분석 · AI로 쓰이는 흐름도 | daunlee.com/g/data/6 ↗ |
| 7 | Database Migration & Operations Map (GCDBE)DB 이관 · 운영 지도 (GCDBE) | Database assessment · DMS zero-downtime migration · Cloud SQL · AlloyDB · Spanner architectureDB 진단 · DMS 무중단 이관 · Cloud SQL · AlloyDB · Spanner 구성도 | daunlee.com/g/data/7 ↗ |
| 8#0 | Day 1 Overview Briefing1일차 (전체 일정 브리핑) | Day 1 8-period flow briefing (Infrastructure, IAM, Cloud SQL, AlloyDB)2026. 11. 9(월) · 1일차 8교시 전체 흐름 브리핑 (인프라·보안·Cloud SQL·AlloyDB) | daunlee.com/g/data/8#0 ↗ |
| 9#0 | Day 2 Overview Briefing2일차 (전체 일정 브리핑) | Day 2 8-period flow briefing (Zero-downtime DMS migration, Spanner, Bigtable)2026. 11. 10(화) · 2일차 8교시 전체 흐름 브리핑 (DMS 무중단 이관·Spanner·Bigtable) | daunlee.com/g/data/9#0 ↗ |
| 10#0 | Day 3 Overview Briefing3일차 (전체 일정 브리핑) | Day 3 8-period flow briefing (CDC, Lakehouse, BigQuery, Governance, BQML)2026. 11. 11(수) · 3일차 8교시 전체 흐름 브리핑 (CDC·Lakehouse·BigQuery·거버넌스·BQML) | daunlee.com/g/data/10#0 ↗ |
| 11#0 | Day 4 Overview Briefing4일차 (전체 일정 브리핑) | Day 4 8-period flow briefing (Serverless, Pub/Sub, Dataflow, Vector RAG)2026. 11. 12(목) · 4일차 8교시 전체 흐름 브리핑 (서버리스·Pub/Sub·Dataflow·Vector RAG) | daunlee.com/g/data/11#0 ↗ |
8 |
Day 1 Curriculum & Labs1일차 (주제 · 랩 상세) | Day 1 period-by-period topics and Google Skills hands-on labs (Labs 1~8) details2026. 11. 9(월) · 1일차 교시별 주제 및 Google Skills 실습 랩(Lab 1~8) 상세 | daunlee.com/g/data/8 ↗ |
| #1 | Lab 1 · Session 1 · GCP Resource Hierarchy · IAM & Cloud Shell FundamentalsLab 1 · 1교시 · GCP 리소스 계층 · IAM & Cloud Shell 기초 | From temporary login to GCP Project verification, IAM Role assignment, API activation, and Cloud Shell hands-on임시 계정 로그인부터 GCP Project 확인, IAM Role 부여, API 활성화 및 Cloud Shell 실습 | daunlee.com/g/data/8#1 ↗ |
| #2 | Lab 2 · Session 2 · GCP Virtual Private Cloud (VPC) · Firewall & Compute EngineLab 2 · 2교시 · GCP 가상 네트워크(VPC) · 방화벽 & Compute Engine 구축 | Designing global VPC with regional subnets, firewall rules, and deploying Compute Engine VMs글로벌 단일 VPC와 리전 서브넷을 설계하고 방화벽 규칙 및 Compute Engine VM을 배포하는 실습 | daunlee.com/g/data/8#2 ↗ |
| #3 | Lab 3 · Session 3 · Cloud Storage Data Lake & Cloud SQL Initial ProvisioningLab 3 · 3교시 · Cloud Storage 데이터 레이크 & Cloud SQL 기본 프로비저닝 | Ingesting raw data into Cloud Storage buckets and provisioning your first managed Cloud SQL RDBMSCloud Storage 버킷에 원천 데이터를 적재하고 첫 Cloud SQL 관리형 RDBMS를 생성·연동하는 실습 | daunlee.com/g/data/8#3 ↗ |
| #4 | Lab 4 · Session 4 · Connecting Applications to Cloud SQL for PostgreSQLLab 4 · 4교시 · Cloud SQL for PostgreSQL 애플리케이션 연동 실습 | Understanding Public vs Private IP connectivity and securely connecting client apps via Cloud SQL Auth ProxyPublic/Private IP 연결 차이를 이해하고 Cloud SQL Auth Proxy로 안전하게 앱을 연결하는 실습 | daunlee.com/g/data/8#4 ↗ |
| #5 | Lab 5 · Session 5 · Cloud SQL Security Governance & Least-Privilege IAMLab 5 · 5교시 · Cloud SQL 보안 통제 & 최소 권한 관리 실습 | Configuring passwordless IAM Database Authentication, mandatory SSL/TLS encryption, and network access controls비밀번호 없는 IAM Database Authentication과 SSL/TLS 강제 암호화 및 네트워크 접근 제어를 설정하는 실습 | daunlee.com/g/data/8#5 ↗ |
| #6 | Lab 6 · Session 6 · Cloud SQL High Availability (HA) · Read Replicas & PITRLab 6 · 6교시 · Cloud SQL 고가용성(HA) · Read Replica & 시점 복구(PITR) | Hands-on lab on Multi-Zone automated failover, read replica distribution, and WAL log-based point-in-time recovery (PITR).Multi-Zone 자동 장애 조치(Failover), 읽기 전용 복제본 분산, WAL 로그 기반 시점 복구(PITR) 실습 | daunlee.com/g/data/8#6 ↗ |
| #7 | Lab 7 · Session 7 · AlloyDB for PostgreSQL Architecture & Cluster ProvisioningLab 7 · 7교시 · AlloyDB for PostgreSQL 아키텍처 & 클러스터 프로비저닝 | Hands-on lab on provisioning an AlloyDB cluster with decoupled compute and Colossus storage, plus Primary and Read Pools.컴퓨팅과 분산 스토리지(Colossus 기반)가 분리된 AlloyDB 클러스터와 Primary·Read Pool을 구축하는 실습 | daunlee.com/g/data/8#7 ↗ |
| #8 | Lab 8 · Session 8 · AlloyDB Operations & Columnar Engine (HTAP) AccelerationLab 8 · 8교시 · AlloyDB 운영 관리 & 컬럼형 엔진(Columnar Engine, HTAP) 가속 | Hands-on lab on accelerating analytics queries (OLAP) up to 100x using the in-memory columnar engine without ETL.운영 DB(OLTP)에서 별도 ETL 없이 인메모리 컬럼형 엔진으로 대용량 분석 쿼리(OLAP)를 최대 100배 가속하는 실습 | daunlee.com/g/data/8#8 ↗ |
9 |
Day 2 Curriculum & Labs2일차 (주제 · 랩 상세) | Nov 10, 2026 (Tue) · Day 2 session topics & Google Skills hands-on labs (Lab 1~8) details.2026. 11. 10(화) · 2일차 교시별 주제 및 Google Skills 실습 랩(Lab 1~8) 상세 | daunlee.com/g/data/9 ↗ |
| #1 | Lab 9 · Session 1 · On-Premises MySQL ➔ Cloud SQL Zero-Downtime DMS CDC MigrationLab 1 · 1교시 · 온프레미스 MySQL ➔ Cloud SQL 무중단 DMS CDC 이관 | Hands-on lab on initial dump and Binlog CDC real-time replication with zero-downtime promotion via DMS.Database Migration Service(DMS)로 초기 덤프 후 Binlog CDC 실시간 복제를 거쳐 무중단 승격(Promote)하는 실습 | daunlee.com/g/data/9#1 ↗ |
| #2 | Lab 10 · Session 2 · Cross-Cloud (Amazon RDS) ➔ Cloud SQL Zero-Downtime DMS MigrationLab 2 · 2교시 · 타 클라우드(Amazon RDS) ➔ Cloud SQL 무중단 DMS 이관 | Multi-cloud lab on configuring AWS RDS parameter groups (binlog retention) and zero-downtime migration to Cloud SQL.AWS RDS for MySQL 파라미터 그룹(binlog 보관 주기)을 구성하고 GCP Cloud SQL로 무중단 이관하는 멀티클라우드 실습 | daunlee.com/g/data/9#2 ↗ |
| #3 | Lab 11 · Session 3 · PostgreSQL ➔ AlloyDB Zero-Downtime DMS MigrationLab 3 · 3교시 · PostgreSQL ➔ AlloyDB 무중단 DMS 마이그레이션 실습 | Hands-on lab on zero-downtime logical replication upgrade to high-performance AlloyDB using pglogical.pglogical 확장 기반 논리적 복제를 구성해 기존 PostgreSQL 워크로드를 고성능 AlloyDB로 무중단 업그레이드하는 실습 | daunlee.com/g/data/9#3 ↗ |
| #4 | Lab 12 · Session 4 · RDBMS Operations & Migration Practical Challenge LabLab 4 · 4교시 · RDBMS 운영 & 마이그레이션 실무 종합 (Challenge Lab) | Hands-on challenge lab on completing Cloud SQL security, replication, PITR, and migration without hints.가이드 힌트 없이 스스로 Cloud SQL 보안·복제·PITR·마이그레이션 요구사항을 완수하는 실무 종합 챌린지 | daunlee.com/g/data/9#4 ↗ |
| #5 | Lab 13 · Session 5 · Cloud Spanner Horizontally Scalable RDBMS & Query Plan OptimizationLab 5 · 5교시 · Cloud Spanner 글로벌 분산 RDBMS 구축 & 스키마·쿼리플랜 | Hands-on lab on Spanner: hotspot-preventing PK design, interleaved tables, and query execution plans.TrueTime 기반 무제한 수평 확장 RDBMS인 Spanner에서 Hotspot 방지 PK와 Interleaved 테이블·실행계획을 실습 | daunlee.com/g/data/9#5 ↗ |
| #6 | Lab 14 · Session 6 · Cloud Spanner Bulk Ingestion, Backup & Practical ChallengeLab 6 · 6교시 · Cloud Spanner 대량 적재·백업 & Spanner 실무 챌린지 | Hands-on lab on bulk loading data into Spanner via Python/Dataflow, backup/restore, and financial ledger schema challenge.Python/Dataflow로 Spanner에 데이터를 대량 적재하고 백업·복원 및 금융 원장 스키마 챌린지를 완수하는 실습 | daunlee.com/g/data/9#6 ↗ |
| #7 | Lab 15 · Session 7 · Cloud Bigtable Wide-Column NoSQL Schema Design & Bulk LoadingLab 7 · 7교시 · Cloud Bigtable 와이드 컬럼 NoSQL 스키마 설계 & 대량 적재 | Hands-on lab on Tall & Narrow schema, row key design, and cbt CLI ingestion for high-throughput time-series & IoT.초당 수백만 건 시계열·IoT 데이터를 위한 Tall & Narrow 스키마와 Row Key 설계 및 cbt CLI 적재 실습 | daunlee.com/g/data/9#7 ↗ |
| #8 | Lab 16 · Session 8 · Cloud Bigtable Real-Time Streaming, Monitoring & NoSQL CapstoneLab 8 · 8교시 · Cloud Bigtable 실시간 스트리밍·모니터링 & NoSQL 종합 | Hands-on lab on streaming data into Bigtable and diagnosing/tuning row key hotspots with Key Visualizer.스트리밍 데이터를 Bigtable로 실시간 적재하고 Key Visualizer 히트맵으로 핫스팟을 진단·튜닝하는 실습 | daunlee.com/g/data/9#8 ↗ |
10 |
Day 3 Curriculum & Labs3일차 (주제 · 랩 상세) | Nov 11, 2026 (Wed) · Day 3 session topics & Google Skills hands-on labs (Lab 1~8) details.2026. 11. 11(수) · 3일차 교시별 주제 및 Google Skills 실습 랩(Lab 1~8) 상세 | daunlee.com/g/data/10 ↗ |
| #1 | Lab 17 · Session 1 · Datastream Real-Time CDC ➔ BigQuery Zero-Downtime ReplicationLab 1 · 1교시 · Datastream 실시간 CDC ➔ BigQuery 무중단 복제 | Capturing transactional database WAL changes with serverless Datastream and replicating continuously into BigQuery운영 PostgreSQL의 변경분(WAL CDC)을 서버리스 Datastream으로 캡처해 BigQuery에 실시간 동기화하는 실습 | daunlee.com/g/data/10#1 ↗ |
| #2 | Lab 18 · Session 2 · Open Format Data Lakehouse & Apache Iceberg TablesLab 2 · 2교시 · 오픈 포맷 데이터 레이크하우스(Lakehouse) & Iceberg 테이블 | Hands-on lab on querying Cloud Storage Parquet/Iceberg via BigQuery Connection with ACID and row/column security.Cloud Storage 위 Parquet·Iceberg 데이터를 복사 없이 BigQuery Connection으로 연결해 ACID와 행·열 보안을 적용하는 실습 | daunlee.com/g/data/10#2 ↗ |
| #3 | Lab 19 · Session 3 · BigQuery Disaggregated Architecture & Semi-Structured (JSON/ARRAY/STRUCT) DWLab 3 · 3교시 · BigQuery 아키텍처(Colossus·Dremel) & 반정형(JSON·ARRAY·STRUCT) DW | Hands-on lab on decoupled storage/compute architecture, nested/repeated ARRAY<STRUCT> schema, and UNNEST queries.스토리지(Colossus)와 컴퓨트(Dremel) 분리 원리를 이해하고 ARRAY<STRUCT> 중첩·반복 스키마와 UNNEST를 실습 | daunlee.com/g/data/10#3 ↗ |
| #4 | Lab 20 · Session 4 · BigQuery Partitioning & Clustering Cost Optimization ChallengeLab 4 · 4교시 · BigQuery 파티셔닝 · 클러스터링 비용 최적화 & DW 챌린지 | Hands-on lab on reducing query scan bytes and cost by >95% using date-partitioned tables and multi-column clustering.Date-Partitioned 테이블과 다중 컬럼 Clustering으로 스캔 용량(Bytes Processed)과 요금을 95% 이상 줄이는 실습 | daunlee.com/g/data/10#4 ↗ |
| #5 | Lab 21 · Session 5 · Dataform (SQLX) ELT Workflow & Automated TransformationsLab 5 · 5교시 · Dataform(SQLX) 기반 ELT 워크플로 & 데이터 변환 자동화 | Hands-on lab on automating in-DW ELT with SQLX, ref() dependency DAGs, and built-in data quality assertions in Dataform.BigQuery 안에서 SQLX 파일과 ref() 의존성 그래프(DAG), 내장 데이터 품질 테스트(Assertions)로 ELT를 자동화하는 실습 | daunlee.com/g/data/10#5 ↗ |
| #6 | Lab 22 · Session 6 · Data Governance & Knowledge Catalog Security & QualityLab 6 · 6교시 · 데이터 거버넌스 & Knowledge Catalog 보안·품질 | Hands-on lab on organizing data lakes into zones, Knowledge Catalog aspects metadata, and row/column security.전사 데이터 자산을 Lake·Zone으로 묶고 Knowledge Catalog Aspects 메타데이터와 열/행 보안을 적용하는 실습 | daunlee.com/g/data/10#6 ↗ |
| #7 | Lab 23 · Session 7 · Gemini in BigQuery Productivity & Data Canvas Interactive AnalyticsLab 7 · 7교시 · Gemini in BigQuery 생산성 향상 & Data Canvas 대화형 분석 | Hands-on lab on generating SQL/Python via prompts and deriving insights using visual Data Canvas DAGs in BigQuery Studio.자연어 프롬프트로 SQL·파이썬 코드를 생성·튜닝하고 시각적 DAG 그래프인 Data Canvas로 인사이트를 도출하는 실습 | daunlee.com/g/data/10#7 ↗ |
| #8 | Lab 24 · Session 8 · BigQuery ML (BQML) Classification & Gemini Multimodal SQL Sentiment AnalysisLab 8 · 8교시 · BigQuery ML(BQML) 분류 모델 학습 & Gemini SQL 비정형 리뷰 분석 | Hands-on lab on training predictive models with CREATE MODEL SQL and analyzing unstructured sentiment via ML.GENERATE_TEXT.데이터 이동 없이 CREATE MODEL SQL로 예측 모델을 만들고 ML.GENERATE_TEXT로 비정형 고객 리뷰 감성을 분석하는 실습 | daunlee.com/g/data/10#8 ↗ |
11 |
Day 4 Curriculum & Labs4일차 (주제 · 랩 상세) | Nov 12, 2026 (Thu) · Day 4 session topics & Google Skills hands-on labs (Lab 1~7 + Review) details.2026. 11. 12(목) · 4일차 교시별 주제 · Google Skills 실습 랩(Lab 1~7 + 총정리) 상세 | daunlee.com/g/data/11 ↗ |
| #1 | Lab 25 · Session 1 · Event-Driven Serverless Ingestion (Cloud Run functions & Eventarc)Lab 1 · 1교시 · 이벤트 기반 서버리스 데이터 적재 자동화 (Cloud Run functions & Eventarc) | Hands-on lab on event-driven ingestion triggered by Cloud Storage file uploads via Eventarc and Cloud Run functions.Cloud Storage 버킷에 파일이 올라오는 즉시 Eventarc가 감지해 Cloud Run functions로 BigQuery에 적재하는 실습 | daunlee.com/g/data/11#1 ↗ |
| #2 | Lab 26 · Session 2 · Large-Scale Batch Pipelines (Managed Service for Apache Spark & Cloud Data Fusion)Lab 2 · 2교시 · 대규모 배치 데이터 파이프라인 (Managed Service for Apache Spark & Cloud Data Fusion) | Hands-on lab on PySpark transformation and BigQuery ingestion using serverless Managed Service for Apache Spark.클러스터 관리가 없는 Managed Service for Apache Spark로 PySpark 변환 후 BigQuery에 적재하는 실습 | daunlee.com/g/data/11#2 ↗ |
| #3 | Lab 27 · Session 3 · Cloud Pub/Sub Real-Time Messaging & BigQuery Direct SubscriptionsLab 3 · 3교시 · Cloud Pub/Sub 실시간 메시징 & BigQuery Direct Subscription 실습 | Hands-on lab on streaming event ingestion via Pub/Sub and direct loading into BigQuery without intermediate Dataflow.글로벌 이벤트 버스인 Pub/Sub으로 실시간 이벤트를 수집하고 Dataflow 없이 BigQuery로 직결 적재하는 실습 | daunlee.com/g/data/11#3 ↗ |
| #4 | Lab 28 · Session 4 · Dataflow (Apache Beam) Real-Time Streaming ETL & Dashboard PipelineLab 4 · 4교시 · Dataflow (Apache Beam) 실시간 스트리밍 ETL & 대시보드 파이프라인 | Hands-on lab on building real-time streaming ETL on Dataflow with event-time windowing, watermarks, and autoscaling.Event Time 기반 Windowing·Watermark와 Autoscaling을 지원하는 Dataflow로 실시간 스트리밍 ETL을 구축하는 실습 | daunlee.com/g/data/11#4 ↗ |
| #5 | Lab 29 · Session 5 · Advanced Streaming ETL — Dataflow ➔ Bigtable & Streamlit VisualizerLab 5 · 5교시 · 실시간 스트리밍 심화 — Dataflow ➔ Bigtable 결합 & Streamlit 앱 | Hands-on lab on streaming data processing via Dataflow into Bigtable/BigQuery with a Cloud Run (Streamlit) monitoring app.초고속 스트리밍 데이터를 Dataflow로 처리해 Bigtable과 BigQuery에 적재하고 Cloud Run(Streamlit) 앱으로 모니터링하는 실습 | daunlee.com/g/data/11#5 ↗ |
| #6 | Lab 30 · Session 6 · Operational DB Generative AI — Cloud SQL & Spanner Vector SearchLab 6 · 6교시 · 운영 DB 기반 생성형 AI — Cloud SQL & Spanner Vector Search 실습 | Hands-on lab on storing embeddings in operational RDBMS (pgvector / Spanner) and combining transactions with vector search.운영 RDBMS(Cloud SQL pgvector · Spanner) 안에 임베딩 벡터를 저장하고 트랜잭션과 실시간 유사도 검색(ANN/KNN)을 결합하는 실습 | daunlee.com/g/data/11#6 ↗ |
| #7 | Lab 31 Capstone · Session 7 · Enterprise RAG — BigQuery Vector Search & Gemini PipelineLab 7 Capstone · 7교시 · 엔터프라이즈 RAG — BigQuery Vector Search & Gemini 파이프라인 | 4-day capstone lab: generating embeddings, building VECTOR_SEARCH indexes, and running Gemini RAG entirely inside BigQuery SQL.4일 과정 총결산 캡스톤으로 BigQuery 안에서 임베딩 생성, VECTOR_SEARCH 인덱스 검색, Gemini 증강 생성을 SQL로 완성하는 실습 | daunlee.com/g/data/11#7 ↗ |
| #8 | Session 8 · Synthesis & Practice Questions · 4-Day End-to-End Architecture & PDE · PCDBE Exam Prep8교시 · 총정리 & 모의문제 · 4일 엔드투엔드 아키텍처 총정리 & PDE · PCDBE 실전 대비 | Reviewing the complete 4-day architecture across 31 labs and analyzing decision criteria from official PDE/PCDBE sample questions.4일 31개 실습으로 구축한 데이터·DB·AI 전체 아키텍처를 복습하고 공식 PDE·PCDBE 자격증 샘플 문항의 의사결정 기준을 정리 | daunlee.com/g/data/11#8 ↗ |
| 12 | Service & Tool Group Graph서비스 · 도구 그룹 그래프 | Connectivity graph across 9 core service groups covering all 35 GCDE & GCDBE services and tools.GCDE · GCDBE 등장 서비스 · 도구 35개 항목의 9대 그룹 연결도 | daunlee.com/g/data/12 ↗ |
| 13 | Storage & DB 9 Pricing Comparison Table저장소 · DB 9종 요금 비교표 | Pricing comparison across 9 storage & DB options (GCS, Lakehouse, BigQuery, Cloud SQL, Spanner, etc.).GCS · Lakehouse · BigQuery · Cloud SQL · Spanner 9종 요금 비교 | daunlee.com/g/data/13 ↗ |
| 14 | Data Transfer & Migration Options Comparison데이터 전송 · 이관 옵션 비교 | Decision guide comparing gcloud storage, STS, Transfer Appliance, BigQuery DTS, DMS, and Datastream.gcloud storage · STS · Appliance · DTS · DMS · Datastream 비교 | daunlee.com/g/data/14 ↗ |
15 |
When to Choose Which (8 Decision Scenarios)When to choose which (의사결정 8선) | When to choose which: 8 comic scenarios illustrating confusing GCP Data, DB, and AI services.헷갈리는 GCP 데이터 · DB · AI 서비스를 언제 쓰는지 만화 시나리오 8화로 정리한 가이드 | daunlee.com/g/data/15 ↗ |
| #1 | Decision 1 · File & Object Transfer (4 Options)의사결정 1 · 파일 · 객체 이관 4종 | Choosing between gcloud storage, Storage Transfer Service, Transfer Appliance, and BigQuery DTSgcloud storage · Storage Transfer · Transfer Appliance · BQ DTS 선택 | daunlee.com/g/data/15#1 ↗ |
| #2 | Decision 2 · Relational OLTP DBs (3 Options)의사결정 2 · 관계형 OLTP DB 3종 | Cloud SQL vs AlloyDB vs Cloud Spanner (QPS, Regionality, and TCO Budget criteria)Cloud SQL vs AlloyDB vs Cloud Spanner (QPS · 리전 · 예산 기준) | daunlee.com/g/data/15#2 ↗ |
| #3 | Decision 3 · Zero-Downtime DB Replication의사결정 3 · DB 무중단 복제 3종 | Database Migration Service (DMS) vs Datastream vs Schema Conversion ToolDatabase Migration Service (DMS) vs Datastream vs SMT 선택 | daunlee.com/g/data/15#3 ↗ |
| #4 | Decision 4 · NoSQL & Analytical Stores (4 Options)의사결정 4 · NoSQL · 분석 저장소 4종 | Workload decision: Cloud Bigtable vs BigQuery vs Firestore vs MemorystoreCloud Bigtable · BigQuery · Firestore · Memorystore 워크로드별 선택 | daunlee.com/g/data/15#4 ↗ |
| #5 | Decision 5 · BigQuery Table Formats (3 Options)의사결정 5 · BigQuery 테이블 3종 | Table formats: External Table vs Lakehouse (BigLake) vs Standard Native TableExternal vs Lakehouse vs Standard(Native) 테이블 선택 | daunlee.com/g/data/15#5 ↗ |
| #6 | Decision 6 · Data Pipelines (5 Frameworks)의사결정 6 · 파이프라인 5총사 선택 | Data pipeline selection: Managed Service for Apache Airflow (Airflow) vs Dataflow vs Dataproc (Spark) vs DataformManaged Service for Apache Airflow · Dataflow · Managed Service for Apache Spark · Data Fusion · Dataform | daunlee.com/g/data/15#6 ↗ |
| #7 | Decision 7 · Real-Time Streaming Ingestion의사결정 7 · 실시간 스트리밍 적재 | Pub/Sub Direct BigQuery Subscription ($0 pipeline cost) vs Dataflow StreamingPub/Sub BigQuery Subscription 직통 적재($0) vs Dataflow 스트리밍 | daunlee.com/g/data/15#7 ↗ |
| #8 | Decision 8 · AI · RAG & BigQuery Editions Pricing의사결정 8 · AI · RAG & BQ 과금 | Enterprise AI: Text-to-SQL vs Vector Search RAG & BigQuery On-Demand vs EditionsText-to-SQL vs Vector RAG (AlloyDB · BQ) & On-Demand vs Editions | daunlee.com/g/data/15#8 ↗ |
16 |
GCP Beginner FAQ (Top 10 Essential Questions)GCP 첫 입문자 필수 FAQ 10선 | Top 10 essential questions asked on Day 1 by engineers with AWS/Azure experience.AWS · Azure 경력은 있지만 GCP는 처음인 엔지니어가 첫날 묻는 10대 질문 | daunlee.com/g/data/16 ↗ |
| #1 | FAQ 1 · Enable API Requirement입문 1 · Enable API 스위치 | As Project Owner, why must I explicitly Enable API every time I use a new service?Owner 권한인데 왜 서비스를 쓸 때마다 API를 켜야(Enable) 동작하나요? | daunlee.com/g/data/16#1 ↗ |
| #2 | FAQ 2 · Project Name vs ID vs Number입문 2 · 프로젝트 이름 · ID · 번호 | Why does a Project have 3 identifiers: Name, ID, and Number?왜 프로젝트 하나에 이름(Name), ID, 번호(Number)가 3개나 있나요? | daunlee.com/g/data/16#2 ↗ |
| #3 | FAQ 3 · Service Account User Role입문 3 · Service Account User | Why grant permissions to Service Accounts and also need Service Account User (actAs)?왜 서비스 계정에 권한을 주고 나에게 또 Service Account User를 주나요? | daunlee.com/g/data/16#3 ↗ |
| #4 | FAQ 4 · gcloud login vs ADC입문 4 · gcloud login vs ADC | I ran gcloud auth login, so why do Python SDK and Terraform fail with ADC errors?gcloud auth login을 했는데 왜 Python · 코드에서는 ADC 에러가 나나요? | daunlee.com/g/data/16#4 ↗ |
| #5 | FAQ 5 · Global VPC & Regional Subnets입문 5 · Global VPC & Subnet | Why doesn't a VPC have a CIDR block, and how do multi-region VMs communicate without peering?VPC에 왜 CIDR이 없고 다른 리전 VM끼리 어떻게 피어링 없이 통신하나요? | daunlee.com/g/data/16#5 ↗ |
| #6 | FAQ 6 · Private Google Access & Auth Proxy입문 6 · PGA & Auth Proxy | Why enable Private Google Access for private VMs, and why use Auth Proxy for DBs?사설 VM에서 왜 Private Google Access를 켜고 DB엔 Proxy를 쓰나요? | daunlee.com/g/data/16#6 ↗ |
| #7 | FAQ 7 · The CLI Trio (gcloud · bq · gsutil)입문 7 · CLI 3총사 (gcloud · bq) | Why is CLI split into gcloud, bq, gsutil, and why colons (:) vs backticks (`)?왜 CLI가 gcloud · bq · gsutil로 나뉘고 콜론(:)과 백틱(`) 표기가 다른가요? | daunlee.com/g/data/16#7 ↗ |
| #8 | FAQ 8 · BigQuery Datasets & Unenforced PKs입문 8 · Dataset & PK 미강제 | What is a BigQuery Dataset, and why does PK allow duplicate rows without errors?BigQuery Dataset은 무엇이고 왜 PK를 걸어도 중복이 그대로 들어가나요? | daunlee.com/g/data/16#8 ↗ |
| #9 | FAQ 9 · External Tables & Lakehouse입문 9 · 외부 테이블 & 레이크 | Does creating an External Table duplicate data? Why is Lakehouse used as a product name?외부 테이블은 데이터 복제인가요? 왜 Lakehouse가 GCP 제품 이름인가요? | daunlee.com/g/data/16#9 ↗ |
| #10 | FAQ 10 · The 4 'Data-' Services입문 10 · Data- 4형제 구분법 | Cloud Run vs functions differences, and how to distinguish the 4 'Data-' servicesCloud Run vs functions 차이 & Datastream · flow · form · proc 구분법 | daunlee.com/g/data/16#10 ↗ |
17 |
Practitioner FAQ 13 (High-Frequency Questions)실무자 빈출 FAQ 13선 (목차) | 13 core architectural & operational questions most frequently asked by AWS/Azure veterans on Stack Overflow & HN.AWS · Azure 경력자가 커뮤니티(SO · HN)에서 가장 많이 묻는 13대 질문 | daunlee.com/g/data/17 ↗ |
| #1 | FAQ 1 · Project Isolation & BigQuery ConnectionFAQ 1 · Project & Connection | Why divide GCP by Project instead of AWS Account / Azure RG, and why separate BigQuery Connections?왜 GCP는 Project로 나누고, BigQuery에는 Connection을 따로 두나요? | daunlee.com/g/data/17#1 ↗ |
| #2 | FAQ 2 · GCS Archive Zero-Latency RetrievalFAQ 2 · GCS Archive 대기 0초 | Why does Cloud Storage Archive have 0-second latency while charging minimum storage duration?왜 Cloud Storage Archive는 대기 0초이고 최소 보관 요금이 붙나요? | daunlee.com/g/data/17#2 ↗ |
| #3 | FAQ 3 · Cloud SQL vs AlloyDB vs SpannerFAQ 3 · Cloud SQL vs AlloyDB | Where should AWS Aurora / Azure Hyperscale migrate: Cloud SQL, AlloyDB, or Spanner?Aurora · Hyperscale은 Cloud SQL · AlloyDB · Spanner 중 어디로 가나요? | daunlee.com/g/data/17#3 ↗ |
| #4 | FAQ 4 · DMS vs Datastream ComparisonFAQ 4 · DMS vs Datastream | AWS DMS handled both cutover and replication — why does GCP split them into DMS and Datastream?AWS DMS 하나로 했는데, 왜 GCP는 DMS와 Datastream으로 나뉘나요? | daunlee.com/g/data/17#4 ↗ |
| #5 | FAQ 5 · Spanner Interleaved Tables & Sequential KeysFAQ 5 · Spanner 인터리빙 | Why do sequential PKs cause hotspots in Spanner, and how do interleaved tables colocate parent-child rows?Spanner에서 순차 PK는 왜 핫스팟이 생기고 부모 · 자식은 어떻게 묶나요? | daunlee.com/g/data/17#5 ↗ |
| #6 | FAQ 6 · Bigtable vs BigQuery ComparisonFAQ 6 · Bigtable vs BigQuery | Bigtable vs BigQuery differences, and where do DynamoDB workloads migrate?Bigtable과 BigQuery는 무엇이 다르고, DynamoDB는 어디로 가나요? | daunlee.com/g/data/17#6 ↗ |
| #7 | FAQ 7 · Nested Records (ARRAY/STRUCT) & UNNESTFAQ 7 · 중첩 스키마 & UNNEST | Why use ARRAY<STRUCT> and UNNEST instead of normalized tables and JOINs?왜 JOIN 대신 ARRAY<STRUCT>로 중첩해 넣고 UNNEST로 펼쳐 쓰나요? | daunlee.com/g/data/17#7 ↗ |
| #8 | FAQ 8 · BigQuery Slots & Partitioning OptimizationFAQ 8 · Slot & 파티셔닝 | How does BigQuery execute queries with Slots, and Partitioning vs Clustering differences?서버리스인데 왜 Slot이 있고, 파티셔닝과 클러스터링은 어떻게 다른가요? | daunlee.com/g/data/17#8 ↗ |
| #9 | FAQ 9 · LIMIT 10 Full Scan & Editions PricingFAQ 9 · LIMIT 10 & Editions | Why does SELECT * LIMIT 10 scan the entire table, and when to switch to Editions?왜 SELECT * LIMIT 10도 전체 용량이 과금되고, Editions는 언제 쓰나요? | daunlee.com/g/data/17#9 ↗ |
| #10 | FAQ 10 · BigLake Open Table FormatsFAQ 10 · Lakehouse 테이블 | Why query Cloud Storage Parquet via Lakehouse (BigLake) instead of standard External Tables?GCS Parquet 조회 시 외부 테이블 대신 왜 Lakehouse 테이블을 쓰나요? | daunlee.com/g/data/17#10 ↗ |
| #11 | FAQ 11 · Data Pipeline 5 Engines ComparisonFAQ 11 · 파이프라인 5총사 비교 | When to use Dataflow vs Dataproc (Spark) vs Dataform vs Managed Service for Apache Airflow (Airflow)?Dataflow · Spark · Dataform · Managed Service for Apache Airflow는 각각 언제 쓰나요? | daunlee.com/g/data/17#11 ↗ |
| #12 | FAQ 12 · Pub/Sub Direct BigQuery SubscriptionFAQ 12 · Pub/Sub 직통 적재 | How does Pub/Sub guarantee message ordering, and when to ingest directly to BQ without Dataflow?Pub/Sub은 어떻게 순서를 보장하며, 언제 Dataflow 없이 BQ로 넣나요? | daunlee.com/g/data/17#12 ↗ |
| #13 | FAQ 13 · Text-to-SQL vs Enterprise Vector RAGFAQ 13 · Text-to-SQL & RAG | Document Search RAG vs Revenue Text-to-SQL — where should vector search run (BQ vs AlloyDB)?문서는 RAG로 찾고 매출 숫자는 무엇으로 답하며 벡터 검색은 어디서 하나요? | daunlee.com/g/data/17#13 ↗ |
18 | GCDE Practice Exam (100 Questions)GCDE 연습문제 100문항 | English & Korean questions with answer explanations & official docs.영어·한국어 기존 문항 · 문항별 답안·해설과 공식 문서 | daunlee.com/g/data/18 ↗ |
| #1 | Q1 · Least-privilege publisher | A device ingestion service only needs to publish messages to one Pub/Sub topic. It must not manage topics or read subscriptions. Which access design is most appropriate?장치 수집 서비스는 Pub/Sub 토픽 하나에 메시지를 게시하기만 하면 돼요. 토픽 관리나 구독 읽기는 허용하면 안 돼요. 가장 적절한 접근 설계는 무엇인가요? | daunlee.com/g/data/18#1 ↗ |
| #2 | Q2 · Separate workload identities | Two services share one service account: one reads raw files, and the other publishes approved reports. Security wants a compromised reader to lack report-publication permissions. What should you change?원본 파일 읽기 서비스와 승인 보고서 게시 서비스가 같은 서비스 계정을 공유해요. 보안팀은 읽기 서비스가 침해돼도 보고서를 게시할 수 없게 하고 싶어요. 무엇을 바꿔야 하나요? | daunlee.com/g/data/18#2 ↗ |
| #3 | Q3 · Inherited IAM access | An analyst has a broad read role inherited from a parent project. An administrator removes a narrower table-level allow binding, but the analyst can still read the table. Why?분석가에게 상위 프로젝트에서 상속된 넓은 읽기 역할이 있어요. 관리자가 테이블 수준의 더 좁은 허용 바인딩을 지웠는데도 분석가는 계속 읽을 수 있어요. 이유는 무엇인가요? | daunlee.com/g/data/18#3 ↗ |
| #4 | Q4 · Customer-managed encryption governance | A regulated dataset must use customer-managed encryption keys, with key administration separated from ordinary data access. Which TWO design choices address these requirements?규제 대상 데이터 세트에 고객 관리 암호화 키를 사용하고 키 관리와 일반 데이터 접근을 분리해야 해요. 요구사항에 맞는 설계 두 가지는 무엇인가요? | daunlee.com/g/data/18#4 ↗ |
| #5 | Q5 · Data exfiltration boundary | Sensitive BigQuery and Cloud Storage resources already use least-privilege IAM. The company also wants to constrain supported service operations that copy data to unauthorized projects outside its trusted boundary. Which additional control best fits?민감한 BigQuery·Cloud Storage 리소스에 최소 권한 IAM을 적용했어요. 신뢰 경계 밖의 승인되지 않은 프로젝트로 데이터를 복사하는 지원 서비스 작업도 제한하고 싶어요. 어떤 추가 통제가 가장 적합한가요? | daunlee.com/g/data/18#5 ↗ |
| #6 | Q6 · De-identification before development use | Developers need realistic support-message samples, but raw messages contain emails and phone numbers. They do not need to recover the original identifiers. What is the best preparation step before granting access?개발자가 실제와 비슷한 고객 문의 샘플을 필요로 하지만 원문에는 이메일과 전화번호가 들어 있어요. 원래 식별자를 복구할 필요는 없어요. 접근 권한을 주기 전에 가장 적절한 준비는 무엇인가요? | daunlee.com/g/data/18#6 ↗ |
| #7 | Q7 · Resource location constraints | A company restricts new supported resources to approved locations using an organization policy. An older dataset remains in a disallowed location. What explains this, and what should the migration design account for?회사가 조직 정책으로 새로 만드는 지원 리소스의 위치를 승인된 곳으로 제한했어요. 그런데 기존 데이터 세트가 허용하지 않은 위치에 그대로 있어요. 이유와 설계상 고려사항으로 맞는 것은 무엇인가요? | daunlee.com/g/data/18#7 ↗ |
| #8 | Q8 · Production and development separation | Developers frequently experiment with pipeline code and permissions. Production contains restricted customer data and must not be modifiable by development identities. Which project structure is most appropriate?개발자가 파이프라인 코드와 권한을 자주 실험해요. 운영에는 제한된 고객 데이터가 있고 개발 계정이 수정할 수 없어야 해요. 어떤 프로젝트 구조가 가장 적절한가요? | daunlee.com/g/data/18#8 ↗ |
| #9 | Q9 · Business recovery objectives | A business says its pipeline may be unavailable for at most two hours and may lose at most fifteen minutes of committed data after a disaster. Which TWO interpretations are correct?재해 후 파이프라인 중단은 최대 2시간까지, 이미 확정된 데이터 손실은 최대 15분 분량까지 허용된다고 해요. 올바른 해석 두 가지는 무엇인가요? | daunlee.com/g/data/18#9 ↗ |
| #10 | Q10 · Quality gates before publication | A daily sales table occasionally contains duplicate transaction IDs and missing customer IDs. Downstream reports must not consume a failed batch. Which design best enforces this requirement?일별 매출 테이블에 거래 ID 중복과 고객 ID 누락이 간헐적으로 생겨요. 하위 보고서는 검증에 실패한 배치를 사용하면 안 돼요. 어떤 설계가 가장 적합한가요? | daunlee.com/g/data/18#10 ↗ |
| #11 | Q11 · Atomic multi-table change | A BigQuery batch updates a ledger table and a summary table. Both mutations must become committed together, or neither should take effect. All operations are supported DML on native tables. What should you use?BigQuery 배치가 원장 테이블과 요약 테이블을 수정해요. 두 변경은 함께 확정되거나 둘 다 반영되지 않아야 해요. 모두 네이티브 테이블에서 지원되는 DML이에요. 무엇을 사용해야 하나요? | daunlee.com/g/data/18#11 ↗ |
| #12 | Q12 · Semantic data contract | An upstream producer keeps the numeric schema unchanged but switches revenue values from dollars to cents. The pipeline runs successfully and dashboards become wrong. What should the design add?상류 생산자가 숫자 스키마는 그대로 두고 매출 단위를 달러에서 센트로 바꿔요. 파이프라인은 성공하지만 대시보드 값은 틀려요. 어떤 설계를 추가해야 하나요? | daunlee.com/g/data/18#12 ↗ |
| #13 | Q13 · Open analytical storage design | A company wants BigQuery-managed analytical tables while keeping data in its own Cloud Storage bucket for supported open-source engines to read. It wants one open-format copy rather than recurring full exports. Which option best fits?회사는 BigQuery가 관리하는 분석 테이블을 사용하면서 데이터를 자체 Cloud Storage 버킷에 두고 지원되는 오픈소스 엔진에서도 읽고 싶어요. 반복 전체 내보내기 대신 개방형 형식의 사본 하나를 원해요. 가장 적절한 선택은 무엇인가요? | daunlee.com/g/data/18#13 ↗ |
| #14 | Q14 · Discoverable governed assets | Analysts cannot tell which of several similarly named tables is authoritative or who owns it. The team wants searchable definitions, owners, and quality context without copying every dataset into one project. What should it implement?분석가가 이름이 비슷한 여러 테이블 중 어떤 것이 기준 데이터인지, 담당자가 누구인지 알 수 없어요. 모든 데이터를 한 프로젝트에 복사하지 않고 정의·소유자·품질 맥락을 검색하고 싶어요. 무엇을 구현해야 하나요? | daunlee.com/g/data/18#14 ↗ |
| #15 | Q15 · Lineage impact assessment | A source owner plans to rename a column. The engineering team needs to identify downstream tables and reports that depend on it before making the change. Which metadata capability is most relevant?소스 담당자가 열 이름을 바꾸려고 해요. 엔지니어링 팀은 변경 전에 이 열을 사용하는 하위 테이블과 보고서를 찾아야 해요. 가장 관련 있는 메타데이터 기능은 무엇인가요? | daunlee.com/g/data/18#15 ↗ |
| #16 | Q16 · Portability with shared context | A platform team expects analytical engines to change over time. It wants to reduce repeated data conversion and preserve shared business meaning across engines. Which TWO choices best support that design?플랫폼 팀은 시간이 지나면서 분석 엔진이 바뀔 것으로 예상해요. 반복 데이터 변환을 줄이고 엔진 간 공통 업무 의미를 유지하고 싶어요. 어떤 선택 두 가지가 설계에 가장 도움이 되나요? | daunlee.com/g/data/18#16 ↗ |
| #17 | Q17 · Offline bulk transfer decision | A remote data center must move a very large static archive to Cloud Storage. Its available network cannot meet the deadline, while appliance delivery, shipping, and ingestion fit the schedule and are supported in its country. Which approach is most appropriate?외딴 데이터센터의 매우 큰 고정 아카이브를 Cloud Storage로 옮겨야 해요. 가용 네트워크로는 마감에 맞출 수 없지만 장비 배송·반송·적재 일정은 가능하고 해당 국가에서 지원돼요. 어떤 방식이 가장 적절한가요? | daunlee.com/g/data/18#17 ↗ |
| #18 | Q18 · Managed object migration | An organization must regularly copy objects from an Amazon S3 bucket into Cloud Storage. It wants managed transfer scheduling and integrity checks, without transforming the files. Which service should it evaluate first?조직이 Amazon S3 버킷의 객체를 Cloud Storage로 정기 복사해야 해요. 파일 변환 없이 관리형 전송 예약과 무결성 검사를 원해요. 먼저 검토할 서비스는 무엇인가요? | daunlee.com/g/data/18#18 ↗ |
| #19 | Q19 · CDC analytics migration path | A supported operational PostgreSQL database must remain the application system of record while changes are replicated into BigQuery for near-real-time analysis. No custom transformation is required. Which managed path minimizes custom pipeline components?지원되는 운영 PostgreSQL은 계속 애플리케이션의 기준 DB로 남고, 변경분은 BigQuery에 복제해 준실시간 분석해야 해요. 사용자 지정 변환은 없어요. 자체 파이프라인 구성 요소를 최소화하는 관리형 경로는 무엇인가요? | daunlee.com/g/data/18#19 ↗ |
| #20 | Q20 · Low-downtime database cutover | A supported PostgreSQL migration to Cloud SQL must minimize application downtime. The database continues receiving writes during most of the migration. Which plan is most appropriate?지원되는 PostgreSQL을 Cloud SQL로 이관하면서 애플리케이션 중단을 최소화해야 해요. 이관 대부분의 시간 동안 원본에는 쓰기가 계속 들어와요. 어떤 계획이 가장 적절한가요? | daunlee.com/g/data/18#20 ↗ |
| #21 | Q21 · Migration acceptance criteria | A migration team reports that all transfer jobs completed. Business owners need evidence that the destination is ready, not just that bytes moved. Which TWO checks best support acceptance?이관팀은 모든 전송 작업이 완료됐다고 보고해요. 업무 담당자는 바이트 이동뿐 아니라 대상이 사용 준비됐다는 증거가 필요해요. 승인에 가장 도움이 되는 검증 두 가지는 무엇인가요? | daunlee.com/g/data/18#21 ↗ |
| #22 | Q22 · Transfer feasibility estimation | A team estimates migration duration by dividing dataset size by the network link's advertised peak rate. The link is shared with production, and files are numerous and small. What should the plan do before committing to a deadline?팀이 데이터 크기를 회선의 광고상 최대 속도로 나눠 이관 시간을 추정해요. 회선은 운영과 공유하고 작은 파일도 많아요. 마감을 확정하기 전에 무엇을 해야 하나요? | daunlee.com/g/data/18#22 ↗ |
| #23 | Q23 · Sources and sinks | A distributor receives completed daily shipment files in Cloud Storage. A pipeline must validate each record, write accepted records to BigQuery, and preserve rejected records with error details in a separate Cloud Storage location. Which source-and-sink definition correctly represents this pipeline?한 유통업체는 매일 작성이 완료된 배송 파일을 Cloud Storage로 받아요. 파이프라인은 각 레코드를 검증하고, 정상 레코드는 BigQuery에 기록하며, 거부된 레코드는 오류 정보와 함께 별도의 Cloud Storage 위치에 보관해야 해요. 이 파이프라인의 소스와 싱크를 올바르게 정의한 것은 무엇인가요? | daunlee.com/g/data/18#23 ↗ |
| #24 | Q24 · Transformation versus orchestration | A retailer has already loaded raw sales into BigQuery. It needs version-controlled SQL models and data assertions, and an existing Managed Service for Apache Airflow workflow must notify a downstream service only after transformation succeeds. Which division of responsibilities is most appropriate?한 소매업체는 원본 매출 데이터를 이미 BigQuery에 적재했어요. 버전 관리되는 SQL 모델과 데이터 검증 쿼리가 필요하며, 기존 Managed Service for Apache Airflow 워크플로는 변환이 성공한 뒤에만 후속 서비스에 알림을 보내야 해요. 역할을 어떻게 나누는 것이 가장 적절한가요? | daunlee.com/g/data/18#24 ↗ |
| #25 | Q25 · Private pipeline connectivity | Dataflow workers without external IP addresses must read an on-premises database through an established HA VPN and write to BigQuery. IAM and database credentials are already correct, but workers cannot resolve the private database hostname or reach Google APIs. Which TWO configuration areas must be addressed while retaining private-only workers?외부 IP가 없는 Dataflow 워커가 이미 연결된 HA VPN을 통해 온프레미스 데이터베이스를 읽고 BigQuery에 써야 해요. IAM과 데이터베이스 인증 정보는 올바르지만, 워커가 데이터베이스의 사설 호스트 이름을 해석하지 못하고 Google API에도 접근하지 못해요. 워커를 사설 IP 전용으로 유지하면서 어떤 두 가지 설정 영역을 해결해야 하나요? | daunlee.com/g/data/18#25 ↗ |
| #26 | Q26 · Encryption in transit | A bank plans to ingest database exports over Dedicated Interconnect. Its current design includes private IP addressing and encryption at rest, but security requires encryption in transit from the exporting application to the receiving application. Which addition directly satisfies this requirement?한 은행이 Dedicated Interconnect로 데이터베이스 내보내기 파일을 수집하려고 해요. 현재 설계에는 사설 IP와 저장 데이터 암호화가 포함되어 있지만, 보안팀은 보내는 애플리케이션부터 받는 애플리케이션까지 전송 중 암호화를 요구해요. 어떤 추가 조치가 이 요구를 직접 충족하나요? | daunlee.com/g/data/18#26 ↗ |
| #27 | Q27 · Beam model and Spark engine | A team wants reusable processing logic for daily files and continuously arriving events. One engineer proposes Apache Beam, while another says that choosing Beam makes any future use of Apache Spark impossible. Which TWO statements should guide the design review?한 팀이 일별 파일과 계속 유입되는 이벤트에 재사용할 수 있는 처리 로직을 원해요. 한 엔지니어는 Apache Beam을 제안하고, 다른 엔지니어는 Beam을 선택하면 앞으로 Apache Spark를 전혀 사용할 수 없다고 말해요. 설계 검토에서 기준으로 삼아야 할 올바른 설명 두 가지는 무엇인가요? | daunlee.com/g/data/18#27 ↗ |
| #28 | Q28 · Reusing native Spark pipelines | An insurer has tested PySpark batch jobs with custom Spark libraries. It wants to run those jobs on Google Cloud with minimal code changes and without administering a persistent cluster. Which execution option best matches these requirements?한 보험사에 사용자 정의 Spark 라이브러리를 사용하는 검증된 PySpark 배치 작업이 있어요. 코드를 최소한으로 변경하고 상시 클러스터를 직접 관리하지 않으면서 Google Cloud에서 실행하려고 해요. 어떤 실행 방식이 가장 적합한가요? | daunlee.com/g/data/18#28 ↗ |
| #29 | Q29 · Visual integration with Data Fusion | An integration team must combine supported relational and application sources, preview sample records, and apply reusable cleansing steps before loading BigQuery. The team prefers a visual pipeline designer with connector plugins rather than writing a new distributed-processing application. Which service best fits this authoring requirement?한 통합 팀이 지원되는 관계형 데이터베이스와 애플리케이션 소스를 결합하고, 샘플 레코드를 미리 보며, 재사용 가능한 정제 단계를 적용한 뒤 BigQuery에 적재해야 해요. 새로운 분산 처리 애플리케이션을 작성하기보다 커넥터 플러그인이 있는 시각적 파이프라인 설계 도구를 선호해요. 이 작성 방식에 가장 적합한 서비스는 무엇인가요? | daunlee.com/g/data/18#29 ↗ |
| #30 | Q30 · Pub/Sub direct BigQuery export | A device platform publishes schema-compatible events to Pub/Sub. It needs to store the events in an existing BigQuery table without joins, windowing, or custom transformations, and its downstream analysis tolerates duplicate deliveries. Which option minimizes subscriber infrastructure?한 장치 플랫폼이 스키마가 호환되는 이벤트를 Pub/Sub에 게시해요. 조인, 윈도 처리, 사용자 정의 변환 없이 기존 BigQuery 테이블에 저장하면 되고, 후속 분석에서는 중복 전달을 허용해요. 구독자 인프라를 가장 적게 운영하는 선택은 무엇인가요? | daunlee.com/g/data/18#30 ↗ |
| #31 | Q31 · Pull versus push subscriptions | A processing service runs inside a network that permits authenticated outbound access to Pub/Sub but prohibits public inbound HTTPS endpoints. The service must explicitly control how many messages are outstanding while it performs variable-duration processing. Which subscription approach is the best fit?한 처리 서비스가 인증된 Pub/Sub 아웃바운드 접근은 허용하지만 공개 인바운드 HTTPS 엔드포인트는 금지하는 네트워크에서 실행돼요. 처리 시간이 일정하지 않아서 서비스가 처리 중인 메시지 수를 직접 제어해야 해요. 어떤 구독 방식이 가장 적합한가요? | daunlee.com/g/data/18#31 ↗ |
| #32 | Q32 · Storage Write API offsets | A custom writer needs rows to become queryable immediately in BigQuery. Network failures can make append responses ambiguous, and the writer must safely retry the same rows within its write stream without inserting them twice. Which BigQuery Storage Write API configuration and retry strategy best meet this requirement?사용자 정의 쓰기 프로그램이 BigQuery에 기록한 행을 즉시 쿼리할 수 있어야 해요. 네트워크 장애로 추가 요청의 성공 여부가 불분명해질 수 있으며, 같은 쓰기 스트림 안에서 동일한 행을 재시도해도 두 번 삽입되지 않아야 해요. 어떤 BigQuery Storage Write API 설정과 재시도 전략이 가장 적합한가요? | daunlee.com/g/data/18#32 ↗ |
| #33 | Q33 · Atomic batch visibility | A settlement application uses the BigQuery Storage Write API to prepare a batch in several parallel streams for one destination table. Analysts must see none of the batch until preparation finishes, then see the committed batch together. Which stream lifecycle is appropriate?한 정산 애플리케이션이 BigQuery Storage Write API의 여러 병렬 스트림으로 하나의 목적지 테이블에 넣을 배치를 준비해요. 분석가는 준비가 끝나기 전에는 배치의 어떤 데이터도 볼 수 없어야 하고, 이후에는 커밋된 배치를 함께 볼 수 있어야 해요. 어떤 스트림 생명주기를 사용해야 하나요? | daunlee.com/g/data/18#33 ↗ |
| #34 | Q34 · Direct CDC to BigQuery | A company needs an initial backfill and ongoing replication of supported PostgreSQL tables with primary keys into BigQuery with minimal custom code. It needs source updates and deletes reflected in the destination and does not require custom transformations before ingestion. Which service path is the simplest fit?한 회사가 기본 키가 있는 지원 대상 PostgreSQL 테이블을 BigQuery에 초기 적재한 뒤 계속 복제하려고 해요. 사용자 정의 코드를 최소화하면서 원본의 수정과 삭제를 목적지에도 반영해야 하고, 수집 전에 별도 사용자 정의 변환은 필요하지 않아요. 가장 단순하고 적합한 서비스 경로는 무엇인가요? | daunlee.com/g/data/18#34 ↗ |
| #35 | Q35 · Event time versus processing time | Delivery scanners record package handoffs with reliable UTC timestamps but can upload events after reconnecting from offline periods. A dashboard must report handoffs in the five-minute interval when they actually occurred, not when the cloud received them. How should a Beam pipeline assign windows?배송 스캐너가 신뢰할 수 있는 UTC 시각과 함께 인계 이벤트를 기록하지만, 오프라인 상태가 끝난 뒤에 이벤트를 업로드할 수도 있어요. 대시보드는 클라우드 수신 시각이 아니라 실제 인계가 발생한 5분 구간별로 집계해야 해요. Beam 파이프라인에서 윈도를 어떻게 배정해야 하나요? | daunlee.com/g/data/18#35 ↗ |
| #36 | Q36 · Watermarks and late revisions | A Beam pipeline computes ten-minute event-time totals. The product contract permits revisions while the watermark is no more than twenty minutes beyond a window's end, and the dashboard stores one replaceable total per key and window. Which TWO choices correctly implement this contract?한 Beam 파이프라인이 이벤트 시간 기준 10분 합계를 계산해요. 서비스 계약상 워터마크가 윈도 종료 시점보다 20분 넘게 진행하기 전까지 결과를 수정할 수 있고, 대시보드는 키와 윈도별로 교체 가능한 합계 하나를 저장해요. 이 계약을 올바르게 구현하는 선택 두 가지는 무엇인가요? | daunlee.com/g/data/18#36 ↗ |
| #37 | Q37 · Idempotent external side effects | A Dataflow pipeline in exactly-once mode calls an external loyalty API from a transform to award points. After worker retries, some customers receive the same award twice even though downstream pipeline results are deduplicated. Which design change addresses the actual problem?정확히 한 번 모드의 Dataflow 파이프라인이 변환 단계에서 외부 멤버십 API를 호출해 포인트를 지급해요. 워커 재시도 후 파이프라인 후속 결과는 중복 제거되지만 일부 고객에게는 같은 포인트가 두 번 지급돼요. 실제 문제를 해결하는 설계 변경은 무엇인가요? | daunlee.com/g/data/18#37 ↗ |
| #38 | Q38 · Invalid-record quarantine | A streaming ingestion pipeline receives mostly valid JSON but occasionally encounters permanently malformed records. Valid traffic must continue, and operators must be able to inspect and repair each rejected record later. Which processing design best satisfies both requirements?한 스트리밍 수집 파이프라인이 대부분 정상 JSON을 받지만 가끔 영구적으로 형식이 잘못된 레코드를 받아요. 정상 트래픽 처리는 계속되어야 하고, 운영자는 나중에 각 거부 레코드를 확인하고 수정할 수 있어야 해요. 두 요구를 함께 충족하는 처리 설계는 무엇인가요? | daunlee.com/g/data/18#38 ↗ |
| #39 | Q39 · Deterministic data cleansing | A supplier feed contains padded customer codes, locale-specific date strings, and missing order quantities. Business rules require trimmed codes, dates parsed according to the supplier's declared locale, and rejection of records with missing quantities rather than invented values. Which transformation strategy preserves these rules?한 공급업체 피드에 공백이 붙은 고객 코드, 지역 형식의 날짜 문자열, 주문 수량이 누락된 레코드가 있어요. 업무 규칙은 코드 공백 제거, 공급업체가 선언한 지역 형식에 따른 날짜 해석, 수량이 없을 때 임의 값 대신 레코드 거부를 요구해요. 어떤 변환 전략이 이 규칙을 지키나요? | daunlee.com/g/data/18#39 ↗ |
| #40 | Q40 · Compatible schema evolution | A producer will add an optional campaign_code field to events loaded into an existing BigQuery table. Older producers will continue sending the previous schema during rollout, and no historical value can be reconstructed. Which rollout plan best preserves compatibility and data meaning?한 생산자가 기존 BigQuery 테이블에 적재하는 이벤트에 선택 항목인 campaign_code 필드를 추가하려고 해요. 배포 기간에는 구버전 생산자도 이전 스키마로 계속 보내며, 과거 값은 복원할 수 없어요. 어떤 배포 계획이 호환성과 데이터 의미를 가장 잘 보존하나요? | daunlee.com/g/data/18#40 ↗ |
| #41 | Q41 · Bounded reference enrichment | A streaming Beam job must enrich every order with a product category from a small approved reference snapshot. The snapshot fits comfortably in worker memory, remains unchanged for the job's lifetime, and must be the same version for all orders in that run. Which enrichment pattern is most appropriate?한 스트리밍 Beam 작업이 작은 승인된 참조 스냅샷에서 상품 분류를 찾아 모든 주문에 추가해야 해요. 스냅샷은 워커 메모리에 충분히 들어가고 작업 실행 동안 바뀌지 않으며, 해당 실행의 모든 주문은 같은 버전을 사용해야 해요. 어떤 보강 패턴이 가장 적합한가요? | daunlee.com/g/data/18#41 ↗ |
| #42 | Q42 · Windowed stream joins | Two unbounded streams contain session events and purchase events. The reporting contract counts matches only when both events have the same session identifier and fall in the same fixed ten-minute event-time reporting bucket; bounded late corrections are allowed. Which Beam join design implements this contract without waiting for either stream to end?두 무한 스트림에 각각 세션 이벤트와 구매 이벤트가 들어와요. 보고 규칙은 세션 식별자가 같고 동일한 고정 10분 이벤트 시간 보고 구간에 속하는 이벤트끼리만 매칭하며, 제한된 범위의 지연 수정은 허용해요. 어느 스트림의 종료도 기다리지 않고 이 규칙을 구현하는 Beam 조인 설계는 무엇인가요? | daunlee.com/g/data/18#42 ↗ |
| #43 | Q43 · Kafka ingestion with Dataflow | A company must retain its existing Kafka producers and topics. It wants a Google Cloud streaming pipeline to read those topics, perform event-time aggregations, and write BigQuery results without introducing an unnecessary messaging hop. What is the best integration approach?한 회사가 기존 Kafka 생산자와 주제를 그대로 유지해야 해요. Google Cloud 스트리밍 파이프라인으로 해당 주제를 읽고 이벤트 시간 집계를 수행하여 BigQuery에 결과를 쓰되, 불필요한 메시징 경유 단계는 추가하지 않으려고 해요. 가장 적절한 통합 방식은 무엇인가요? | daunlee.com/g/data/18#43 ↗ |
| #44 | Q44 · Governed AI enrichment | An ingestion pipeline sends support-ticket text to an approved generative model to produce a category field. Policy prohibits sending raw customer identifiers to the model, and only categories from a fixed business vocabulary may enter the curated dataset. Each enrichment must also be traceable to its model and prompt version. Which TWO pipeline controls are necessary?한 수집 파이프라인이 지원 티켓 내용을 승인된 생성형 모델에 보내 분류 필드를 만들어요. 정책상 고객 식별자 원문을 모델에 보내면 안 되며, 정제 데이터셋에는 정해진 업무 용어 목록에 있는 분류만 들어갈 수 있어요. 각 보강 결과에 사용된 모델과 프롬프트 버전도 추적할 수 있어야 해요. 필요한 파이프라인 통제 두 가지는 무엇인가요? | daunlee.com/g/data/18#44 ↗ |
| #45 | Q45 · Parameterized Flex Templates | A platform team has a custom Beam pipeline that must be launched repeatedly by operators who do not have a development environment. The same approved release must run in staging and production with different source subscriptions, destination tables, and service accounts. Which packaging approach best supports repeatable deployment?한 플랫폼 팀의 사용자 정의 Beam 파이프라인을 개발 환경이 없는 운영자가 반복해서 실행해야 해요. 승인된 동일 릴리스를 스테이징과 운영 환경에서 실행하되 소스 구독, 목적지 테이블, 서비스 계정은 달라야 해요. 어떤 패키징 방식이 반복 가능한 배포를 가장 잘 지원하나요? | daunlee.com/g/data/18#45 ↗ |
| #46 | Q46 · Pipeline CI/CD validation | A team is introducing CI/CD for a Beam ingestion pipeline that normalizes records and routes invalid rows to a rejection sink. A release must be tested before production, and the artifact deployed to production must be the one that passed staging. Which TWO practices belong in this release process?한 팀이 레코드를 정규화하고 잘못된 행은 거부 싱크로 보내는 Beam 수집 파이프라인에 CI/CD를 도입해요. 릴리스는 운영 반영 전에 테스트해야 하고, 운영에 배포하는 산출물은 스테이징을 통과한 바로 그 산출물이어야 해요. 릴리스 절차에 포함해야 할 실천 두 가지는 무엇인가요? | daunlee.com/g/data/18#46 ↗ |
| #47 | Q47 · Cross-service job orchestration | A team needs a lightweight serverless workflow that starts a batch ingestion job, waits for successful completion, runs a BigQuery validation query, and then calls a notification API. It has no existing Airflow DAGs or plugins and does not want to manage an Airflow environment. Which implementation best fits?한 팀이 배치 수집 작업을 시작하고 성공 완료를 기다린 뒤 BigQuery 검증 쿼리를 실행하고 알림 API를 호출하는 가벼운 서버리스 워크플로를 원해요. 기존 Airflow DAG나 플러그인은 없고 Airflow 환경을 관리하고 싶지 않아요. 어떤 구현이 가장 적합한가요? | daunlee.com/g/data/18#47 ↗ |
| #48 | Q48 · Analytical warehouse selection | A retailer needs ad hoc SQL analysis over years of sales and joins across large historical tables. It wants managed infrastructure and does not need this store to serve individual checkout transactions. Which primary store best fits?유통사가 여러 해의 매출과 큰 이력 테이블 간 조인을 SQL로 수시 분석하려고 해요. 인프라 관리는 줄이고 싶으며 이 저장소로 개별 결제 트랜잭션을 처리할 필요는 없어요. 가장 적합한 기본 저장소는 무엇인가요? | daunlee.com/g/data/18#48 ↗ |
| #49 | Q49 · High-volume keyed telemetry | A telemetry application writes large volumes of readings and retrieves short time ranges for a known device ID. It does not need joins or transactions spanning multiple devices. Which store is best aligned with the primary access pattern?원격 측정 앱은 많은 측정값을 쓰고, 알려진 장치 ID로 짧은 시간 구간을 읽어요. 조인이나 여러 장치에 걸친 트랜잭션은 필요 없어요. 주요 접근 패턴에 가장 맞는 저장소는 무엇인가요? | daunlee.com/g/data/18#49 ↗ |
| #50 | Q50 · Globally consistent operational transactions | A global reservation system requires relational queries and atomic transactions spanning related records. It expects horizontally scalable writes and strong consistency across its chosen multi-region deployment. Which database should the team evaluate first?글로벌 예약 시스템에 관계형 조회와 관련 레코드 간 원자적 트랜잭션이 필요해요. 선택한 멀티 리전 구성에서 수평 쓰기 확장과 강한 일관성도 원해요. 먼저 검토할 DB는 무엇인가요? | daunlee.com/g/data/18#50 ↗ |
| #51 | Q51 · Compatible relational application migration | A moderate-sized PostgreSQL application uses familiar PostgreSQL features and fits on a managed relational instance. The main goal is reducing database infrastructure administration with minimal application changes, not global write scaling. Which service is the most direct fit?중간 규모 PostgreSQL 앱이 익숙한 PostgreSQL 기능을 쓰고 관리형 관계형 인스턴스 용량 안에 들어와요. 목표는 글로벌 쓰기 확장이 아니라 앱 변경을 최소화하면서 DB 인프라 관리를 줄이는 것이에요. 가장 직접적인 선택은 무엇인가요? | daunlee.com/g/data/18#51 ↗ |
| #52 | Q52 · Storage class cost trade-offs | A seven-year archive is rarely read and can tolerate retrieval charges. The team wants lower storage cost without losing online access. Which TWO statements should guide its Cloud Storage design?7년 보관 아카이브는 거의 읽지 않고 조회 비용도 감수할 수 있어요. 온라인 접근을 유지하면서 보관 비용을 줄이고 싶어요. Cloud Storage 설계를 이끌어야 할 설명 두 가지는 무엇인가요? | daunlee.com/g/data/18#52 ↗ |
| #53 | Q53 · Hierarchical order modeling | BigQuery reports usually read each order together with its modest number of line items. The team wants to preserve this parent-child relationship while reducing repeated joins. Which model is most appropriate?BigQuery 보고서는 주문 하나와 그 주문의 적당한 수의 품목을 보통 함께 읽어요. 부모·자식 관계를 유지하면서 반복 조인을 줄이고 싶어요. 어떤 모델이 가장 적절한가요? | daunlee.com/g/data/18#53 ↗ |
| #54 | Q54 · Avoid automatic over-denormalization | A BigQuery warehouse has a well-performing star schema with a fact table and reusable dimensions. A proposal says every dimension must be nested because joins are always unacceptable. What is the best response?BigQuery 창고에 사실 테이블과 재사용 차원으로 된 성능 좋은 스타 스키마가 있어요. 조인은 언제나 나쁘니 모든 차원을 중첩해야 한다는 제안이 나왔어요. 가장 적절한 대응은 무엇인가요? | daunlee.com/g/data/18#54 ↗ |
| #55 | Q55 · Event-date partitioning | A multi-year BigQuery event table is queried almost exclusively for explicit event-date ranges. The team wants to prune irrelevant dates and manage retention by event date. Which design is most appropriate?여러 해의 BigQuery 이벤트 테이블은 거의 항상 명시한 이벤트 날짜 범위로 조회해요. 무관한 날짜를 건너뛰고 이벤트 날짜로 보관 기간을 관리하고 싶어요. 어떤 설계가 가장 적절한가요? | daunlee.com/g/data/18#55 ↗ |
| #56 | Q56 · Clustering for selective predicates | A large BigQuery table is queried by specific customer IDs with many distinct values. Date ranges vary, and the team wants additional block pruning inside relevant data. Which storage optimization should it evaluate?큰 BigQuery 테이블을 서로 다른 값이 많은 고객 ID로 선택 조회해요. 날짜 범위는 달라지고 관련 데이터 안에서도 블록 읽기를 더 줄이고 싶어요. 어떤 저장 최적화를 검토해야 하나요? | daunlee.com/g/data/18#56 ↗ |
| #57 | Q57 · Partitioning plus clustering | A large events warehouse needs day-based retention and usually queries one week for a few customers. Each daily partition is large. Which TWO design actions best match these requirements?큰 이벤트 창고에서 일 단위 보관 관리가 필요하고, 보통 일부 고객의 일주일 데이터를 조회해요. 하루 파티션도 충분히 커요. 요구에 가장 맞는 설계 두 가지는 무엇인가요? | daunlee.com/g/data/18#57 ↗ |
| #58 | Q58 · External table authorization | A user can query a non-BigLake external table definition but lacks permission to read the underlying Cloud Storage objects. The query fails with an access error. Which explanation is correct?사용자가 비 BigLake 방식의 일반 외부 테이블 정의를 조회할 권한은 있지만 기반 Cloud Storage 객체 읽기 권한은 없어요. 쿼리에 접근 오류가 발생해요. 올바른 설명은 무엇인가요? | daunlee.com/g/data/18#58 ↗ |
| #59 | Q59 · External data consistency trade-off | A critical report queries ordinary external files while another application rewrites those same files. The report requires a stable, validated dataset for each published reporting period. What is the best redesign?중요 보고서가 일반 외부 파일을 읽는 동안 다른 앱이 같은 파일을 다시 써요. 보고서는 공개하는 기간마다 안정적이고 검증된 데이터 세트가 필요해요. 가장 적절한 재설계는 무엇인가요? | daunlee.com/g/data/18#59 ↗ |
| #60 | Q60 · Managed Iceberg table operations | A team selects Apache Iceberg managed tables in BigQuery with data in its own bucket. It wants to preserve table consistency and managed optimization. Which operating practice is most appropriate?팀이 자체 버킷에 데이터를 두는 BigQuery Apache Iceberg 관리형 테이블을 선택했어요. 테이블 일관성과 관리형 최적화를 유지하고 싶어요. 어떤 운영 방식이 가장 적절한가요? | daunlee.com/g/data/18#60 ↗ |
| #61 | Q61 · Federated ownership and common governance | Business domains must retain ownership of their data projects, while the enterprise needs common definitions, discoverability, and enforceable access policies. Which TWO practices fit this federated platform?업무 도메인은 각 데이터 프로젝트의 소유권을 유지해야 하고, 전사는 공통 정의·검색 가능성·강제되는 접근 정책이 필요해요. 분산 소유 플랫폼에 맞는 실천 두 가지는 무엇인가요? | daunlee.com/g/data/18#61 ↗ |
| #62 | Q62 · Object lifecycle versus legal retention | A bucket uses a lifecycle rule to delete aging objects, but legal requirements now demand that records cannot be deleted during a mandatory retention interval. What should the storage design recognize?버킷에 오래된 객체를 지우는 수명 주기 규칙이 있는데, 법적 요구로 의무 보관 기간에는 레코드를 삭제할 수 없어야 해요. 저장 설계에서 무엇을 알아야 하나요? | daunlee.com/g/data/18#62 ↗ |
| #63 | Q63 · Default storage class misconception | A bucket contains old Standard objects. An administrator changes its default storage class to Coldline but finds the old objects are still Standard. What should the administrator do to change eligible existing objects?버킷에 예전 Standard 객체가 있어요. 관리자가 기본 저장 클래스를 Coldline으로 바꿨지만 기존 객체는 여전히 Standard예요. 조건에 맞는 기존 객체를 바꾸려면 어떻게 해야 하나요? | daunlee.com/g/data/18#63 ↗ |
| #64 | Q64 · Bigtable row-key hotspot prevention | A fleet has many devices with reasonably distributed write rates. Queries fetch one device's readings for a time range. A prototype uses timestamp-first row keys and develops write hotspots. Which redesign best balances distribution and queries?많은 장치의 쓰기량이 비교적 고르게 분산된 장치군이에요. 조회는 장치 하나의 시간 범위 측정값을 읽어요. 시제품이 타임스탬프 우선 행 키를 사용하다 쓰기 핫스폿이 생겼어요. 분산과 조회를 함께 고려한 재설계는 무엇인가요? | daunlee.com/g/data/18#64 ↗ |
| #65 | Q65 · Bigtable transactional boundaries | A team proposes storing account balances in separate Bigtable rows and updating two balances atomically during a transfer. It also wants to query by known row keys. Which TWO facts should shape the decision?팀이 계좌 잔액을 서로 다른 Bigtable 행에 저장하고 이체 시 두 잔액을 원자적으로 바꾸려 해요. 알려진 행 키로 조회하고도 싶어요. 결정에 반영할 사실 두 가지는 무엇인가요? | daunlee.com/g/data/18#65 ↗ |
| #66 | Q66 · Metadata access is not data access | A data steward adds descriptions and ownership aspects to a table entry in Knowledge Catalog. An analyst can discover the entry but still receives a BigQuery access-denied error. What should be checked next?데이터 관리자가 Knowledge Catalog(이전 Knowledge Catalog)의 테이블 항목에 설명과 소유권 메타데이터를 추가했어요. 분석가가 항목은 찾지만 BigQuery 접근 거부 오류를 받아요. 다음으로 무엇을 확인해야 하나요? | daunlee.com/g/data/18#66 ↗ |
| #67 | Q67 · Independent compute and durable data | A data platform runs intermittent analytics with different compute engines but must retain datasets between jobs. An engineer proposes deleting data whenever a compute job ends. What principle should the architecture apply instead?데이터 플랫폼은 여러 계산 엔진으로 간헐적 분석을 실행하지만 작업 사이에도 데이터 세트를 보관해야 해요. 한 엔지니어가 계산 작업 종료 때마다 데이터를 지우자고 해요. 대신 어떤 원칙을 적용해야 하나요? | daunlee.com/g/data/18#67 ↗ |
| #68 | Q68 · BI Engine suitability | A retailer's BI dashboard queries a small, frequently accessed set of native BigQuery tables through the BigQuery API. The queries use supported SQL operations, and the team wants in-memory acceleration without changing its BI tool or maintaining another database. Which approach best fits these requirements?한 소매업체의 BI 대시보드는 BigQuery API를 통해 소수의 자주 사용하는 BigQuery 기본 테이블을 조회해요. 쿼리는 지원되는 SQL 연산을 사용하며, 팀은 BI 도구를 바꾸거나 별도 데이터베이스를 운영하지 않고 메모리 기반 가속을 적용하려고 해요. 요구사항에 가장 적합한 방법은 무엇인가요? | daunlee.com/g/data/18#68 ↗ |
| #69 | Q69 · Incremental materialized views | An append-only BigQuery sales table feeds dashboards that repeatedly calculate daily revenue by store. The aggregation is supported by incremental materialized views, dashboards must include newly appended data, and the team wants to avoid maintaining a scheduled aggregation pipeline. Which design best meets these requirements?추가 전용 BigQuery 매출 테이블을 사용하는 대시보드들이 매장별 일 매출을 반복 계산해요. 이 집계는 증분 구체화된 뷰에서 지원되며, 대시보드는 새로 추가된 데이터까지 포함해야 하고 팀은 예약 집계 파이프라인을 별도로 관리하고 싶지 않아요. 가장 적합한 설계는 무엇인가요? | daunlee.com/g/data/18#69 ↗ |
| #70 | Q70 · Precomputed reporting fields | Several dashboards repeatedly parse the same product-description strings with expensive regular expressions and apply identical category rules. New data arrives nightly, and next-morning freshness is sufficient; the transformation is not eligible for the team's incremental materialized-view design. What should the data engineer do to reduce repeated computation and keep category definitions consistent?여러 대시보드가 동일한 상품 설명 문자열을 비용이 큰 정규 표현식으로 반복 분석하고 같은 카테고리 규칙을 적용해요. 새 데이터는 야간에 들어오고 다음 날 아침까지 반영되면 충분하지만, 이 변환은 팀의 증분 구체화된 뷰 설계에 적합하지 않아요. 반복 계산을 줄이고 카테고리 정의를 일관되게 유지하려면 어떻게 해야 하나요? | daunlee.com/g/data/18#70 ↗ |
| #71 | Q71 · Dashboard scan troubleshooting | A dashboard needs only three columns from the last seven days of a BigQuery table partitioned by event_date. Job details show that its generated query scans every column and all historical partitions; the BI tool filters dates only after downloading the result. Which TWO changes directly reduce the unnecessary BigQuery scan work while preserving the required data?대시보드에는 event_date로 파티션된 BigQuery 테이블의 최근 7일 데이터 중 세 열만 필요해요. 작업 세부정보를 보니 생성된 쿼리가 모든 열과 전체 기간의 파티션을 읽고, BI 도구는 결과를 내려받은 뒤에야 날짜를 필터링해요. 필요한 데이터를 유지하면서 불필요한 BigQuery 스캔을 직접 줄이는 변경 두 가지는 무엇인가요? | daunlee.com/g/data/18#71 ↗ |
| #72 | Q72 · Identity-based column masking | Finance and marketing analysts query the same BigQuery table using their own identities. Finance needs original tax identifiers, while marketing must still be able to select the identifier column but receive masked values; neither group should manage access policies. The company uses policy-tag-based column protection and wants to avoid separate table copies. What is the best configuration?재무와 마케팅 분석가가 각자 자신의 ID로 같은 BigQuery 테이블을 조회해요. 재무팀에는 원래 납세자 식별자가 필요하고, 마케팅팀도 식별자 열을 선택할 수 있어야 하지만 마스킹된 값을 받아야 하며 두 팀 모두 접근 정책을 관리해서는 안 돼요. 회사는 정책 태그 기반 열 보호를 사용하고 테이블 복사본을 만들고 싶지 않아요. 가장 적절한 구성은 무엇인가요? | daunlee.com/g/data/18#72 ↗ |
| #73 | Q73 · Sensitive free-text preparation | A support team wants analysts to examine complaint narratives in BigQuery, but email addresses and a company-specific customer code can appear anywhere in the text. Policy requires a persisted sanitized reporting dataset before analyst access, while preserving useful non-sensitive wording. Which preparation approach is most appropriate?고객지원팀은 분석가가 BigQuery에서 불만 서술문을 분석하게 하려 하지만, 이메일 주소와 회사 고유 고객 코드가 텍스트 어디에나 나타날 수 있어요. 정책상 분석가 접근 전에 정제된 보고용 데이터셋을 저장해야 하며 민감하지 않은 유용한 표현은 보존해야 해요. 가장 적절한 데이터 준비 방법은 무엇인가요? | daunlee.com/g/data/18#73 ↗ |
| #74 | Q74 · Point-in-time feature correctness | A lender prepares a BigQuery training table for a decision made when an application is submitted. Its historical feature join currently selects each customer's latest profile, including updates received weeks after the application; the repayment label is observed later. The feature history includes effective timestamps and ingestion timestamps. Which preparation rule best prevents temporal leakage?대출업체가 신청 접수 시점에 내리는 결정을 위한 BigQuery 학습 테이블을 준비해요. 현재 과거 특징 조인은 신청 몇 주 뒤에 받은 변경 내용까지 포함한 고객의 최신 프로필을 선택하며, 상환 레이블은 나중에 관측돼요. 특징 이력에는 유효 시각과 수집 시각이 모두 있어요. 시간적 정보 누출을 가장 잘 막는 데이터 준비 규칙은 무엇인가요? | daunlee.com/g/data/18#74 ↗ |
| #75 | Q75 · BigQuery ML reusable transformations | A team uses a BigQuery ML model that supports manual feature preprocessing. It wants a numerical feature standardized using training-derived statistics, with the identical transformation automatically applied by ML.PREDICT to later raw input rows. Which implementation best avoids separately maintained prediction preprocessing?한 팀이 수동 특징 전처리를 지원하는 BigQuery ML 모델을 사용해요. 학습 데이터에서 계산한 통계로 숫자 특징을 표준화하고, 이후 원시 입력 행에도 ML.PREDICT가 동일한 변환을 자동 적용하게 하려고 해요. 예측 전처리를 별도로 관리하지 않는 가장 적합한 구현은 무엇인가요? | daunlee.com/g/data/18#75 ↗ |
| #76 | Q76 · Missing-value feature consistency | An equipment monitoring team prepares training features in BigQuery and serves predictions in an application. Missing sensor values indicate 'not measured,' while a measured zero is valid; training imputes missing values with a stored training median and sets an is_missing indicator, but the application currently replaces missing values with zero and omits the indicator. What is the best data-preparation correction?설비 모니터링팀이 BigQuery에서 학습 특징을 준비하고 애플리케이션으로 예측을 제공해요. 센서 결측값은 '측정하지 않음'을 뜻하고 실제 측정된 0은 유효한 값인데, 학습에서는 저장한 학습 중앙값으로 결측을 대체하고 is_missing 표시를 추가하는 반면 애플리케이션은 결측을 0으로 바꾸고 표시도 생략해요. 가장 적절한 데이터 준비 수정은 무엇인가요? | daunlee.com/g/data/18#76 ↗ |
| #77 | Q77 · Leakage-safe preprocessing splits | A team prepares one year of dated transactions in BigQuery to assess how its prediction pipeline will behave on future months. Each row already has point-in-time-correct features and an available label, but the proposed preparation computes category vocabulary and scaling statistics across the full year before splitting. Which TWO changes create a more credible evaluation dataset?한 팀이 향후 월별 데이터에서 예측 파이프라인이 어떻게 작동할지 평가하려고 BigQuery에서 날짜가 있는 1년 치 거래를 준비해요. 각 행의 특징은 이미 해당 시점에 맞고 레이블도 확보되어 있지만, 제안된 준비 과정은 데이터를 분할하기 전에 1년 전체에서 범주 목록과 표준화 통계를 계산해요. 더 신뢰할 수 있는 평가 데이터셋을 만드는 변경 두 가지는 무엇인가요? | daunlee.com/g/data/18#77 ↗ |
| #78 | Q78 · Document ingestion and chunk provenance | An engineering company is preparing PDF manuals for a retrieval-augmented generation application. Answers must cite the originating manual version and page, and some manuals require text extraction before their contents can be searched. Which preparation sequence best supports useful retrieval and traceable answers?한 엔지니어링 회사가 검색 증강 생성 애플리케이션용 PDF 매뉴얼을 준비해요. 답변에는 원본 매뉴얼의 버전과 페이지를 인용해야 하며, 일부 매뉴얼은 내용을 검색하기 전에 텍스트 추출이 필요해요. 유용한 검색과 출처 추적이 가능한 답변을 가장 잘 지원하는 준비 순서는 무엇인가요? | daunlee.com/g/data/18#78 ↗ |
| #79 | Q79 · Authorization-aware retrieval | An internal assistant retrieves text chunks with BigQuery VECTOR_SEARCH and sends them to a language model. The base table has department-based row access policies, but every request currently runs as one broadly authorized service account, exposing other departments' chunks to the model. End-user query identities are available, and policy requires unauthorized text never to enter the prompt. What is the best correction?사내 도우미가 BigQuery VECTOR_SEARCH로 텍스트 청크를 검색해 언어 모델에 보내요. 기본 테이블에는 부서별 행 접근 정책이 있지만 모든 요청이 광범위한 권한의 단일 서비스 계정으로 실행되어 다른 부서의 청크까지 모델에 노출돼요. 최종 사용자의 쿼리 ID를 사용할 수 있고 정책상 권한 없는 텍스트는 프롬프트에 절대 들어가면 안 돼요. 가장 적절한 수정은 무엇인가요? | daunlee.com/g/data/18#79 ↗ |
| #80 | Q80 · Sharing through linked datasets | A market-data provider wants approved partners to query a curated BigQuery dataset from their own projects without maintaining a copied dataset for each partner. Partners must not modify the provider's shared objects, and new source data should be available without a partner export-import pipeline. Which sharing pattern best meets these requirements?시장 데이터 제공업체가 승인된 파트너들이 각자 프로젝트에서 정제된 BigQuery 데이터셋을 조회하게 하되 파트너별 복제 데이터셋은 관리하고 싶지 않아요. 파트너는 제공업체의 공유 객체를 수정할 수 없어야 하고, 새 원본 데이터는 파트너별 내보내기·가져오기 파이프라인 없이 이용 가능해야 해요. 가장 적합한 공유 방식은 무엇인가요? | daunlee.com/g/data/18#80 ↗ |
| #81 | Q81 · Authorized aggregate views | A supplier is allowed to query weekly product totals but must not access individual orders or customer identifiers in the retailer's BigQuery source dataset. The retailer wants a centrally maintained SQL definition without another persisted data copy, and the source and reporting datasets are in the same location. Which access design best enforces the boundary?공급업체는 주별 상품 합계만 조회할 수 있고 소매업체의 BigQuery 원본 데이터셋에 있는 개별 주문이나 고객 식별자에는 접근하면 안 돼요. 소매업체는 별도의 저장 복사본 없이 SQL 정의를 중앙에서 관리하려 하며 원본과 보고 데이터셋은 같은 위치에 있어요. 이 경계를 가장 잘 강제하는 접근 설계는 무엇인가요? | daunlee.com/g/data/18#81 ↗ |
| #82 | Q82 · Report sharing and data credentials | A company publishes a Data Studio report backed by BigQuery. Only a named internal group may open the report, and data access must be evaluated using each viewer's existing BigQuery permissions rather than the report owner's privileges. Those users already have the necessary BigQuery query permissions. Which TWO configurations are required?한 회사가 BigQuery를 원본으로 하는 Data Studio(이전 Data Studio) 보고서를 게시해요. 지정한 사내 그룹만 보고서를 열 수 있어야 하며 데이터 접근은 보고서 소유자의 권한이 아니라 각 조회자의 기존 BigQuery 권한으로 평가해야 해요. 해당 사용자들은 필요한 BigQuery 쿼리 권한을 이미 갖고 있어요. 필요한 설정 두 가지는 무엇인가요? | daunlee.com/g/data/18#82 ↗ |
| #83 | Q83 · On-demand query guardrails | Analysts use on-demand BigQuery pricing. Operations wants a per-query rejection threshold for expensive queries and a daily project-level limit on query bytes. Which TWO controls directly meet these requirements?분석가들이 BigQuery 온디맨드 요금제를 사용해요. 운영팀은 비용이 큰 쿼리를 실행 전에 거부할 쿼리별 기준과 프로젝트의 일일 쿼리 처리량 한도를 원해요. 두 요구사항을 직접 충족하는 통제 수단 두 가지는 무엇인가요? | daunlee.com/g/data/18#83 ↗ |
| #84 | Q84 · Idle Spark compute | A compatible PySpark batch runs for 40 minutes each night. Its dedicated cluster is idle for the rest of the day, and no job needs persistent local state or custom cluster services. Which change best reduces idle compute and cluster administration?호환되는 PySpark 배치가 매일 밤 40분 동안 실행돼요. 전용 클러스터는 나머지 시간에 유휴 상태이고, 영구 로컬 상태나 사용자 지정 클러스터 서비스도 필요하지 않아요. 유휴 컴퓨팅 비용과 클러스터 관리 부담을 가장 잘 줄이는 변경은 무엇인가요? | daunlee.com/g/data/18#84 ↗ |
| #85 | Q85 · Workload capacity isolation | Exploratory queries and production transformations share one BigQuery reservation. Production jobs slow down when analysts run large experiments. The organization wants separately managed baseline capacity for the two workloads. What should you configure?탐색 쿼리와 운영 변환 작업이 하나의 BigQuery 예약을 공유해요. 분석가가 대규모 실험을 실행하면 운영 작업이 느려져요. 조직은 두 워크로드의 기본 용량을 각각 관리하고 싶어요. 무엇을 구성해야 하나요? | daunlee.com/g/data/18#85 ↗ |
| #86 | Q86 · Autoscaling reservation bounds | A team uses BigQuery capacity pricing with highly variable demand and wants to avoid a fixed baseline while limiting reservation growth. Some queueing at peak demand is acceptable. Which configuration best matches this goal?팀이 BigQuery 용량 기반 요금제를 사용하며 수요 변동이 커요. 고정 기본 용량은 피하면서 예약의 확장 범위를 제한하고 싶고, 피크 시간의 일부 대기는 허용해요. 어떤 구성이 가장 적합한가요? | daunlee.com/g/data/18#86 ↗ |
| #87 | Q87 · Reproducible backfills | An Airflow DAG must reprocess last month after a transformation bug. Its current tasks use the current date and read whichever input folder is newest, so reruns produce different outputs. Which TWO changes are necessary for reproducible backfills?Airflow DAG(작업 의존성 그래프)가 변환 오류 수정 후 지난달 데이터를 다시 처리해야 해요. 현재 작업은 실행 당일 날짜와 가장 최신 입력 폴더를 사용해서 재실행 결과가 달라져요. 재현 가능한 과거 데이터 재처리에 필요한 변경 두 가지는 무엇인가요? | daunlee.com/g/data/18#87 ↗ |
| #88 | Q88 · Idempotent task output | An Airflow task writes daily order totals to a warehouse and then loses its connection before reporting success. A retry blindly appends the same totals again. Inputs for the day are stable. Which change prevents duplicate business results?Airflow 작업이 일별 주문 합계를 웨어하우스에 쓴 뒤 성공 보고 전에 연결이 끊겨요. 재시도하면 같은 합계를 다시 추가해요. 해당 날짜의 입력은 고정돼 있어요. 업무 결과의 중복을 막는 변경은 무엇인가요? | daunlee.com/g/data/18#88 ↗ |
| #89 | Q89 · Slow DAG parsing | After a DAG update, scheduling becomes slow even before any task starts. The new Python file performs a large API fetch and data transformation at module import time. What should you change first?DAG를 수정한 뒤 작업이 시작하기도 전에 스케줄링이 느려져요. 새 Python 파일은 모듈을 불러오는 시점에 대규모 API 조회와 데이터 변환을 실행해요. 먼저 무엇을 바꿔야 하나요? | daunlee.com/g/data/18#89 ↗ |
| #90 | Q90 · Bounded transient retries | A Workflows step makes an idempotent HTTP request to a service that occasionally returns 429 or 503 during brief overloads. Immediate retries amplify the overload. What retry policy is most appropriate?Workflows 단계가 멱등적인 HTTP 요청을 보내는데, 대상 서비스가 잠깐 과부하일 때 429나 503을 반환해요. 즉시 재시도하면 과부하가 더 심해져요. 가장 적절한 재시도 정책은 무엇인가요? | daunlee.com/g/data/18#90 ↗ |
| #91 | Q91 · Batch query priority | A BigQuery housekeeping query may wait in a queue and does not need interactive responsiveness. The team wants to mark that scheduling intent without rewriting its SQL or assuming the work is free. Which job setting should it use?BigQuery 정리용 쿼리는 대기열에서 기다려도 되고 즉각적인 응답이 필요하지 않아요. SQL을 다시 작성하거나 무료 처리를 가정하지 않고 이런 스케줄링 의도를 표시하려면 어떤 작업 설정을 사용해야 하나요? | daunlee.com/g/data/18#91 ↗ |
| #92 | Q92 · Capacity usage attribution | Two BigQuery jobs scan similar bytes but have very different computational complexity. The team uses capacity-based pricing and wants a job-level indicator of consumed compute after execution, not an exact per-job invoice. Which metric is most useful?BigQuery 작업 두 개가 비슷한 바이트를 스캔하지만 계산 복잡도는 크게 달라요. 팀은 용량 기반 요금제를 사용하며 정확한 작업별 청구 금액이 아니라 실행 후 소비한 계산량을 비교할 지표가 필요해요. 어떤 지표가 가장 유용한가요? | daunlee.com/g/data/18#92 ↗ |
| #93 | Q93 · Streaming freshness alerts | A Dataflow streaming job is still running, but its dashboard is showing progressively older events. Operations needs early warning of processing delay and a signal that pending work is growing. Which TWO measurements best match these needs?Dataflow 스트리밍 작업은 실행 중인데 대시보드에는 점점 오래된 이벤트가 표시돼요. 운영팀은 처리 지연을 조기에 알아야 하고, 미처리 작업이 늘어나는지도 확인해야 해요. 가장 적절한 측정 지표 두 가지는 무엇인가요? | daunlee.com/g/data/18#93 ↗ |
| #94 | Q94 · Sink-bound streaming pipeline | A Dataflow pipeline accumulates backlog after traffic increases. Worker CPU remains low, while sink logs show throttling and the write stage has rising latency. Increasing workers did not improve throughput. What is the best next action?트래픽 증가 후 Dataflow 파이프라인에 백로그가 쌓여요. 작업자 CPU는 낮지만 대상 저장소 로그에 요청 제한이 보이고 쓰기 단계의 지연이 커져요. 작업자를 늘려도 처리량이 개선되지 않았어요. 다음 조치로 가장 적절한 것은 무엇인가요? | daunlee.com/g/data/18#94 ↗ |
| #95 | Q95 · Permanent versus transient failure | An orchestration step succeeds until its service account loses permission on the target resource. Subsequent calls consistently return permission denied, while service health is normal. What should the on-call engineer do first?오케스트레이션 단계가 잘 실행되다가 서비스 계정이 대상 리소스 권한을 잃은 뒤부터 계속 permission denied를 반환해요. 서비스 상태는 정상이에요. 당직 엔지니어가 먼저 해야 할 일은 무엇인가요? | daunlee.com/g/data/18#95 ↗ |
| #96 | Q96 · Replaying acknowledged events | A Pub/Sub subscriber bug acknowledged messages before writing their business results. Acknowledged-message retention was enabled in advance, and the affected interval is still retained. The code is now fixed and output writes are idempotent. How should the team recover the missing results?Pub/Sub 구독자 오류로 업무 결과를 저장하기 전에 메시지를 확인 응답했어요. 확인된 메시지 보존은 사전에 설정돼 있었고 영향받은 구간도 아직 보존 중이에요. 이제 코드는 수정됐고 출력 쓰기는 멱등적이에요. 누락된 결과를 어떻게 복구해야 하나요? | daunlee.com/g/data/18#96 ↗ |
| #97 | Q97 · Logical corruption recovery | A faulty application update corrupts Cloud SQL for PostgreSQL rows, and the bad writes have reached the read replica. Point-in-time recovery was enabled before the incident and the desired time is recoverable. What is the safest recovery approach?잘못된 애플리케이션 업데이트가 Cloud SQL for PostgreSQL 행을 훼손했고 잘못된 쓰기는 읽기 복제본에도 반영됐어요. 사고 전에 시점 복구를 설정했고 원하는 시각도 복구 가능 구간에 있어요. 가장 안전한 복구 접근은 무엇인가요? | daunlee.com/g/data/18#97 ↗ |
| #98 | Q98 · Warm orchestration recovery | A Managed Service for Apache Airflow environment must recover in another region faster than creating a new environment during an incident. The organization accepts ongoing standby costs and plans regular snapshots. Which design fits this requirement?Managed Service for Apache Airflow(이전 Managed Service for Apache Airflow) 환경을 장애 시 새 환경을 만드는 것보다 빨리 다른 리전에서 복구해야 해요. 조직은 상시 대기 비용을 받아들이고 정기 스냅샷도 계획해요. 어떤 설계가 적합한가요? | daunlee.com/g/data/18#98 ↗ |
| #99 | Q99 · Recovery exercise coverage | A team successfully creates Airflow environment snapshots and concludes its pipeline disaster recovery is complete. It has never restored a snapshot or run the DAGs in the failover region. Which TWO checks are most important before accepting the recovery plan?팀은 Airflow 환경 스냅샷 생성에 성공하자 파이프라인 재해 복구가 완성됐다고 판단해요. 스냅샷을 복원하거나 대체 리전에서 DAG를 실행해 본 적은 없어요. 복구 계획을 승인하기 전에 가장 중요한 검증 두 가지는 무엇인가요? | daunlee.com/g/data/18#99 ↗ |
| #100 | Q100 · Passing task outputs safely | An Airflow extraction task saves a large data file on its worker local disk. The downstream task sometimes runs on another worker and cannot find the file. Which design makes the handoff reliable without filling the metadata database with bulk data?Airflow 추출 작업이 큰 데이터 파일을 작업자의 로컬 디스크에 저장해요. 다음 작업이 다른 작업자에서 실행되면 파일을 찾지 못해요. 대량 데이터를 메타데이터 DB에 넣지 않으면서 안정적으로 전달하려면 어떻게 설계해야 하나요? | daunlee.com/g/data/18#100 ↗ |
19 | GCDE Real-world Scenario Questions (10 Questions)GCDE 실전형 연습문제 10문항 | 10 scenario-based questions with deep-dive option analysis, confusion traps, and official documentation links시나리오 기반 실전형 창작 문항 (영어·한국어) · 보기별 해설·혼동 포인트·공식 문서 | daunlee.com/g/data/19 ↗ |
| #1 | Q1 (DE-01) · VPC Service Controls data boundary | A pharmaceutical distributor runs approved transformations between BigQuery and Cloud Storage in separate projects. A review finds that a workload service account could also copy readable source data to a bucket outside the organization. Internal job permissions must remain, but transfers to unapproved external resources through supported Google Cloud APIs must be blocked. The control must cover service-to-service operations, not just traffic from worker VMs. Which design best meets these requirements?의약품 유통 회사가 별도 프로젝트의 BigQuery와 Cloud Storage 사이에서 승인된 변환 작업을 실행해요. 보안 점검에서 작업 서비스 계정이 읽기 권한이 있는 원본을 조직 밖 버킷으로 복사할 수도 있음을 발견했어요. 내부 작업 권한은 유지하되, 지원되는 Google Cloud API를 통한 승인되지 않은 외부 리소스 이동을 차단해야 해요. 작업 VM의 방화벽만으로 통제하지 않고 서비스 간 작업에도 적용해야 해요. 어떤 설계가 가장 적절한가요? | daunlee.com/g/data/19#1 ↗ |
| #2 | Q2 (DE-02) · Immutable retention with Bucket Lock | A quality-assurance team will store inspection evidence in a new Cloud Storage bucket. Its approved policy prohibits deleting or replacing each object for 2,555 days after creation. Bucket administrators will continue operating the bucket but must not be able to shorten or remove the retention policy. The retention duration, costs, and irreversible configuration have been approved. What should you do before production begins?품질보증팀이 새 Cloud Storage 버킷에 검사 증빙을 저장하려고 해요. 승인된 규정은 각 객체를 생성 후 2,555일 동안 삭제하거나 교체하지 못하게 하는 것이에요. 버킷 관리자는 이후에도 운영을 맡지만 보존 기간을 줄이거나 정책을 제거할 수 없어야 해요. 보존 기간과 비용은 검토를 마쳤고, 해제할 수 없는 설정도 승인됐어요. 운영 시작 전에 무엇을 해야 하나요? | daunlee.com/g/data/19#2 ↗ |
| #3 | Q3 (DE-03) · Pub/Sub attribute deduplication in Dataflow | Ticket-scan events flow from Pub/Sub into Dataflow in exactly-once mode. When a publish response is lost, the publisher republishes the event, always within five minutes of the first publication. Pub/Sub message IDs differ, but a globally unique event_id attribute remains identical across retries of that logical event. You must prevent duplicate aggregation in the current run with minimal changes; pipeline restarts and historical replay are out of scope. What should you do?입장권 검표 이벤트를 Pub/Sub에서 Dataflow의 exactly-once 모드로 처리해요. 발행 응답이 유실되면 발행기가 같은 이벤트를 다시 발행하며, 재발행은 최초 발행 후 5분 안에만 발생해요. 이때 Pub/Sub 메시지 ID는 달라지지만, 논리적 이벤트마다 고유한 event_id 속성은 재시도 동안 같아요. 파이프라인 재시작이나 과거 재생 없이 현재 실행의 중복 집계만 최소 변경으로 막아야 해요. 무엇을 해야 하나요? | daunlee.com/g/data/19#3 ↗ |
| #4 | Q4 (DE-04) · Event-time windows and late triggers | A rail operator needs alert counts for non-overlapping ten-minute intervals based on sensor measurement time. Dataflow should emit provisional aggregates every minute and accept late corrections until the watermark passes the interval end plus thirty minutes. Later arrivals use a separate audit path. The result store can replace cumulative aggregates by interval key. Which processing design should you choose?철도 운영팀은 센서 측정 시각 기준으로 겹치지 않는 10분 구간별 경보 건수를 원해요. Dataflow는 1분 주기로 잠정 집계하고, watermark가 해당 구간 종료 시각에 30분을 더한 시점을 넘기기 전까지 지연값을 반영해야 해요. 그 이후의 값은 별도 감사 경로로 처리해요. 결과 저장소는 구간 키별 누적 집계를 교체할 수 있어요. 어떤 처리 방식을 선택해야 하나요? | daunlee.com/g/data/19#4 ↗ |
| #5 | Q5 (DE-05) · Bigtable row-key hotspot prevention | Two hundred thousand rental bicycles publish locations at similar rates, using Bigtable row keys of timestamp#bike_id. Write latency rises while most nodes are idle and only the newest timestamp range is overloaded. Reads retrieve a time range for one known bicycle; fleet-wide time-range reads are not required. Randomly assigned bike_id values are evenly distributed among active bicycles. Which change addresses the cause while preserving efficient reads?대여 자전거 20만 대가 비슷한 속도로 위치를 전송하고, Bigtable은 timestamp#bike_id 키를 사용해요. 쓰기 지연이 늘지만 대부분 노드는 한가하고 최근 시각에 해당하는 키 범위만 과부하예요. 조회는 알려진 자전거 한 대의 특정 시간 범위를 읽는 것이며 전체 차량의 동시각 조회는 없어요. 무작위로 배정된 bike_id는 활성 차량 사이에 고르게 분포해요. 어떤 변경이 원인을 해결하면서 조회 효율도 유지하나요? | daunlee.com/g/data/19#5 ↗ |
| #6 | Q6 (DE-06) · Measurement-date partitioning and clustering | An electricity settlement team's native BigQuery table accumulates 400 GB of meter readings daily and retains two years. Reports always filter at most seven measurement dates and one customer. After connectivity is restored, readings from weeks earlier arrive but must appear under their original measurement dates. The team wants to reduce scanned bytes without maintaining date-sharded tables. Which storage design is most appropriate?전력 정산팀의 BigQuery 기본 테이블에는 하루 400GB의 검침 데이터가 2년간 쌓여요. 보고서는 항상 검침일 기준 최대 7일과 특정 고객 한 곳을 필터링해요. 통신 복구 후 수주 전 검침값이 들어오지만 적재 시각과 무관하게 원래 검침일의 보고서에 포함돼야 해요. 날짜별 테이블 운영 없이 조회 바이트를 줄이고 싶어요. 어떤 저장 설계가 가장 적절한가요? | daunlee.com/g/data/19#6 ↗ |
| #7 | Q7 (DE-07) · Cross-dataset authorized aggregate view | An advertising platform must give an agency current campaign-level aggregates for its own advertisers through BigQuery. The source contains click-level identifiers and other advertisers' data, so the agency must not access source tables directly. The platform also wants no copied aggregate tables or scheduled refresh pipeline. Security has created a filtered, aggregating logical view in a separate dataset in the source region. Which access configuration should it use?광고 플랫폼이 외부 대행사에 자기 광고주들의 최신 캠페인별 집계만 BigQuery로 제공하려고 해요. 원본에는 클릭 단위 식별자와 다른 광고주 데이터가 있어 대행사는 원본 테이블에 직접 접근하면 안 돼요. 집계 결과를 별도 테이블로 복제하거나 주기적으로 갱신하는 작업도 만들지 않으려고 해요. 보안팀이 집계와 광고주 필터가 있는 논리 뷰를 원본과 같은 리전의 별도 데이터셋에 만들었어요. 이제 어떤 권한 구성이 적절한가요? | daunlee.com/g/data/19#7 ↗ |
| #8 | Q8 (DE-08) · Incremental materialized views | A booking platform's dashboards repeatedly compute booking counts and revenue sums by date and region from an append-only native BigQuery table. Result-cache reuse is rare, and recomputing the same aggregates dominates cost. The queries meet the supported single-table aggregation requirements for incremental materialized views, with no updates or deletes. The team needs current available data at query time and less repeated computation without a separate refresh pipeline. Which approach should it choose?예약 플랫폼의 대시보드가 계속 추가되는 BigQuery 기본 테이블에서 날짜·지역별 예약 건수와 금액 합계를 반복 조회해요. 캐시 재사용이 드물고 같은 집계를 다시 계산하는 비용이 대부분이에요. 쿼리는 incremental materialized view가 지원하는 단일 테이블 집계 조건을 충족하며, 원본 업데이트나 삭제는 없어요. 별도 갱신 파이프라인 없이 조회 시점에 사용 가능한 최신 데이터를 반영하면서 반복 계산을 줄여야 해요. 어떤 방식을 선택하나요? | daunlee.com/g/data/19#8 ↗ |
| #9 | Q9 (DE-09) · Dedicated baseline slots and QUERY assignment | Finance and exploration teams use separate execution projects in the same BigQuery region but share one QUERY reservation. Exploration bursts increase finance queueing, and isolated load tests have established sufficient finance capacity. Finance must have that baseline capacity continuously available rather than depend on fair sharing within the exploration reservation. Query clients use default project assignments without runtime reservation overrides. Which two actions should you apply together?재무팀과 탐색 분석팀은 같은 BigQuery 리전에서 서로 다른 실행 프로젝트를 사용하지만 하나의 QUERY 예약을 공유해요. 탐색 쿼리가 몰리면 재무 쿼리 대기가 늘고, 격리 부하 시험에서는 재무용으로 충분한 슬롯 수를 확인했어요. 재무팀은 해당 기본 용량을 상시 확보해야 하며, 탐색팀과 같은 예약의 공정 배분에 의존하면 안 돼요. 쿼리 클라이언트는 실행 시 예약을 별도 지정하지 않고 프로젝트 기본 할당을 사용해요. 어떤 두 조치를 함께 적용해야 하나요? | daunlee.com/g/data/19#9 ↗ |
| #10 | Q10 (DE-10) · Airflow data interval and idempotent writes | A daily DAG in Managed Service for Apache Airflow reads immutable source snapshots and produces date-specific settlement results. Its task currently uses today's wall-clock date and occasionally fails after appending results but before receiving completion confirmation. Retries duplicate rows, and rerunning an older execution the next day reads the wrong input date. Transient-failure retries and historical backfills must remain enabled, and each date's source is immutable. Which two changes are needed together?Managed Service for Apache Airflow의 일별 DAG가 불변 원천 스냅샷을 읽어 날짜별 정산 결과를 만들어요. 현재 태스크는 실행 당시의 오늘 날짜를 사용하고, 결과를 추가한 뒤 완료 응답을 받기 전에 간헐적으로 실패해요. 재시도하면 중복이 생기고, 다음 날 과거 실행을 재처리하면 잘못된 날짜의 입력을 읽어요. 일시 장애 재시도와 과거 날짜 backfill은 유지해야 하며 같은 날짜의 원천은 변경되지 않아요. 어떤 두 변경이 함께 필요한가요? | daunlee.com/g/data/19#10 ↗ |
20 | GCDBE Real-world Scenario Questions (10 Questions)GCDBE 실전형 연습문제 10문항 | 10 scenario-based questions with deep-dive option analysis, confusion traps, and official documentation links시나리오 기반 실전형 창작 문항 (영어·한국어) · 보기별 해설·혼동 포인트·공식 문서 | daunlee.com/g/data/20 ↗ |
| #1 | Q1 (DB-01) · Cloud SQL regional HA failover | A regional hospital runs its appointment service on a single-zone Cloud SQL for PostgreSQL instance. After a single-zone failure, the service must resume writes without an operator promoting a replacement and without losing appointments that were already committed. The application retries broken connections and can tolerate a brief reconnection period. A complete regional outage is outside the current scope, and existing read capacity is sufficient. Which change meets these requirements while adding the fewest unnecessary components?지역 병원의 예약 서비스가 단일 영역 Cloud SQL for PostgreSQL 인스턴스를 사용하고 있어요. 단일 영역 장애가 발생해도 이미 커밋된 예약을 잃지 않고, 운영자의 승격 작업 없이 쓰기 서비스를 재개해야 해요. 애플리케이션에는 끊어진 연결을 재시도하는 기능이 있으며 짧은 재연결 시간은 허용해요. 전체 리전 장애는 이번 요구 범위가 아니고, 현재 읽기 처리량에는 여유가 있어요. 요구사항을 충족하면서 불필요한 구성 요소를 가장 적게 추가하는 변경은 무엇인가요? | daunlee.com/g/data/20#1 ↗ |
| #2 | Q2 (DB-02) · AlloyDB read pool and columnar engine | A retailer processes orders in AlloyDB and runs inventory profitability reports on the same primary instance. The reports scan a few columns from large tables, join them, and aggregate the results; order latency rises while the reports run. A short replication delay is acceptable, but the team cannot operate a separate warehouse and ETL pipeline. The budget allows one small read pool, and the reporting application can use a separate endpoint. Which configuration separates reporting compute from order processing while also addressing this query pattern?유통 회사가 AlloyDB에서 주문을 처리하면서 동일한 primary에 재고 수익성 보고서를 실행해요. 보고서는 큰 테이블에서 몇 개 열만 읽어 조인·집계하며, 실행 시간대에 주문 지연이 증가해요. 짧은 복제 지연은 허용되지만 별도 데이터 웨어하우스와 ETL 파이프라인을 운영할 인력은 없어요. 예산은 소규모 read pool 하나를 추가할 수 있고, 보고서 연결을 별도 엔드포인트로 바꾸는 것은 가능해요. 주문의 연산 자원과 보고서 연산을 분리하면서 해당 쿼리 패턴에도 맞는 구성은 무엇인가요? | daunlee.com/g/data/20#2 ↗ |
| #3 | Q3 (DB-03) · Spanner composite key for tenant locality | A Spanner table stores SaaS audit records with the primary key (EventTime, TenantId, EventId). Concurrent writes are evenly distributed across thousands of tenants, but increasing event timestamps concentrate write latency in the newest key range. The main query reads a time range for one tenant and should use one contiguous key-range scan of the base table. No individual tenant generates enough traffic to create a hotspot, and the team wants to avoid the storage cost of an additional query index. How should you redesign the primary key?SaaS 감사 기록을 저장하는 Spanner 테이블의 기본 키가 (EventTime, TenantId, EventId)예요. 동시 쓰기는 수천 개 테넌트에 고르게 분산되지만, 기록 시각이 증가하면서 최신 키 범위의 쓰기 지연이 급증해요. 주요 조회는 한 테넌트의 특정 시간 범위이며, 기본 테이블의 한 연속 키 범위 스캔으로 처리하고 싶어요. 한 테넌트만으로는 핫스폿을 만들 정도의 부하가 없고, 조회용 보조 인덱스를 추가하는 저장 비용도 피하려고 해요. 기본 키를 어떻게 재설계해야 하나요? | daunlee.com/g/data/20#3 ↗ |
| #4 | Q4 (DB-04) · Selective table repair via Cloud SQL PITR | At 14:03, an incorrect administration script overwrote the tax-rate table in Cloud SQL for PostgreSQL. The team discovered the incident at 14:25, stopped writes to that table, and confirmed from audit records that it has no legitimate post-incident changes to preserve. Other tables have continued to receive valid orders that must not be lost. PITR was enabled before the incident, and the moment immediately before 14:03 is within the available recovery window. What is the most appropriate way to recover the tax rates while preserving the valid new orders?14시 03분에 잘못된 관리 스크립트가 Cloud SQL for PostgreSQL의 세율 테이블을 덮어썼어요. 14시 25분에 발견해 해당 테이블의 쓰기를 중지했으며, 감사 기록상 오류 이후 그 테이블에는 보존해야 할 정상 변경이 없어요. 반면 다른 테이블에는 이후에도 정상 주문이 쌓였고 그 주문을 잃어서는 안 돼요. PITR이 사고 전부터 활성화되어 있으며 14시 03분 직전은 현재 복구 가능한 시간 범위 안에 있어요. 최신 정상 주문을 보존하면서 세율 데이터를 되돌리는 가장 적절한 방법은 무엇인가요? | daunlee.com/g/data/20#4 ↗ |
| #5 | Q5 (DB-05) · Diagnosing lock contention in Query Insights | Order-status UPDATE latency rises sharply after a settlement batch starts on Cloud SQL for PostgreSQL Enterprise Plus. CPU and disk utilization remain low, and the existing execution plan uses a selective index. Query Insights active query analysis and blocked query analysis are enabled, and waiting requests show a Lock wait-event type. You must establish the impact before terminating production sessions or increasing instance capacity. What should you investigate first?정산 배치가 시작된 뒤 Cloud SQL for PostgreSQL Enterprise Plus에서 주문 상태 UPDATE의 지연이 크게 늘었어요. CPU와 디스크 사용량은 낮고, 기존 실행 계획에서도 선택도가 높은 인덱스를 사용해요. Query Insights의 active query analysis와 blocked query analysis는 이미 활성화되어 있으며 대기 중인 요청의 Wait event type은 Lock으로 나타나요. 운영 중인 세션을 무작정 종료하거나 인스턴스를 증설하기 전에 영향 범위를 확인해야 해요. 가장 먼저 수행할 진단은 무엇인가요? | daunlee.com/g/data/20#5 ↗ |
| #6 | Q6 (DB-06) · Cloud SQL IAM login and SQL privileges | A reporting service runs as a service account and is configured to use automatic IAM database authentication through the Cloud SQL Auth Proxy. The network path, Cloud SQL Client role, instance IAM-authentication setting, and IAM database-user registration have all been verified. An administrator confirms that the account has neither cloudsql.instances.login nor effective SQL privileges in the target database. It only needs to read the existing reports.daily_totals table, and long-lived passwords and administrative privileges are prohibited. Which two additional actions are required?보고서 서비스는 서비스 계정으로 실행되며 Cloud SQL Auth Proxy의 automatic IAM database authentication을 사용하도록 구성돼 있어요. 네트워크 경로, Cloud SQL Client 역할, 인스턴스의 IAM 인증 설정과 해당 IAM 데이터베이스 사용자 등록은 모두 확인됐어요. 하지만 관리자 확인 결과 이 계정에는 cloudsql.instances.login 권한도, 대상 데이터베이스의 유효한 SQL 권한도 없어요. 서비스에는 대상 데이터베이스의 reports 스키마에 있는 기존 daily_totals 테이블을 읽는 권한만 필요하며, 장기 비밀번호나 관리자 권한은 허용되지 않아요. 추가로 수행해야 할 두 작업은 무엇인가요? | daunlee.com/g/data/20#6 ↗ |
| #7 | Q7 (DB-07) · Zero-loss DMS PostgreSQL cutover | A logistics company is using Database Migration Service for a continuous migration from on-premises PostgreSQL to Cloud SQL for PostgreSQL. The initial copy and data validation are complete, but replication lag remains about two seconds while the source order API and nightly scripts continue writing. The approved cutover window allows a brief write outage, but no transaction accepted by the source may be omitted. Connection changes and final validation procedures are ready, and no separate bidirectional replication has been configured. What is the safest cutover sequence?물류 회사가 Database Migration Service로 온프레미스 PostgreSQL을 Cloud SQL for PostgreSQL로 연속 이관하고 있어요. 초기 복사는 완료됐고 데이터 검증도 통과했지만, 원본의 주문 API와 야간 스크립트가 계속 쓰는 동안 복제 지연은 약 2초를 유지해요. 승인된 전환 창에서는 짧은 쓰기 중단을 허용하지만, 원본이 수락한 트랜잭션을 하나라도 누락해서는 안 돼요. 연결 설정 변경과 최종 검증 절차는 이미 준비돼 있고 별도 양방향 복제는 구성하지 않았어요. 가장 안전한 전환 순서는 무엇인가요? | daunlee.com/g/data/20#7 ↗ |
| #8 | Q8 (DB-08) · DMS Oracle-to-PostgreSQL conversion validation | An insurer is preparing an Oracle-to-Cloud SQL for PostgreSQL migration with a Database Migration Service conversion workspace. Converted tables and stored procedures can be created on the test destination, but regression tests for refund exception paths produce different results from Oracle. The affected procedure is editable in the workspace, while normal-path tests and table row-count validation have passed. Refund processing and related table updates must complete in one destination transaction, and production dependencies on Oracle must be removed. What should the team do next?보험 회사가 Database Migration Service의 conversion workspace를 사용해 Oracle에서 Cloud SQL for PostgreSQL로 이관을 준비하고 있어요. 변환된 테이블과 저장 프로시저는 테스트 목적지에 생성되지만, 환급 예외 경로를 실행하는 회귀 테스트의 결과가 Oracle과 달라요. 해당 프로시저는 workspace에서 편집 가능한 객체이며, 정상 경로의 테스트와 테이블 행 수 검증은 이미 통과했어요. 환급 처리와 관련 테이블 갱신은 목적지에서 하나의 트랜잭션으로 완료되어야 하고 Oracle에 대한 운영 의존성도 제거해야 해요. 다음으로 무엇을 해야 하나요? | daunlee.com/g/data/20#8 ↗ |
| #9 | Q9 (DB-09) · Bigtable single-cluster conditional mutations | A device-control service stores each device's control-lease state in one row of a Bigtable instance replicated across two clusters. Multiple workers can request the same device, so the service must use CheckAndMutateRow to update the state only when its condition holds. During normal operation, a successful update must be visible to the immediately following state read. All lease-related reads and writes can use one app profile, and failing requests during an outage of the designated cluster is preferable to automatic failover. Which two settings should be applied to the lease app profile and request path?기기 제어 서비스가 두 클러스터로 복제된 Bigtable에 기기별 제어권 상태를 한 행씩 저장해요. 여러 작업자가 같은 기기의 제어권을 요청하므로 현재 상태를 확인하고 조건이 맞을 때만 갱신하는 CheckAndMutateRow를 사용해야 해요. 정상 운영 중에는 성공한 갱신을 바로 이어지는 상태 조회에서 볼 수 있어야 해요. 제어권 관련 모든 읽기·쓰기는 하나의 앱 프로필을 사용하게 할 수 있고, 지정 클러스터 장애 시에는 자동 전환보다 요청 실패를 허용하는 것이 우선이에요. 제어권 앱 프로필과 요청 경로에 적용할 두 설정은 무엇인가요? | daunlee.com/g/data/20#9 ↗ |
| #10 | Q10 (DB-10) · Spanner covering secondary index (STORING) | In a GoogleSQL-dialect Spanner database, a support screen finds cases by AccountId and an OpenedAt range and returns CaseId, Priority, and Summary. The Cases table has primary key CaseId, and an existing secondary index has key (AccountId, OpenedAt). The execution plan shows that the index range scan is fast, but base-table lookups for Priority and Summary account for most latency. These two columns are small and infrequently updated, and modest additional index storage is acceptable while instance scaling and primary-key changes should be avoided. What is the most direct optimization?GoogleSQL 방언을 사용하는 Spanner에서 지원 담당자 화면이 AccountId와 OpenedAt 범위로 사례를 조회하고 CaseId, Priority, Summary를 반환해요. Cases 테이블의 기본 키는 CaseId이고, 기존 보조 인덱스의 키는 (AccountId, OpenedAt)예요. 실행 계획에서 인덱스 범위 스캔은 빠르지만 Priority와 Summary를 가져오기 위한 기본 테이블 조회가 지연의 대부분을 차지해요. 두 열은 작고 변경 빈도가 낮으며, 약간의 인덱스 저장 증가를 허용하되 인스턴스 증설과 기본 키 변경은 피해야 해요. 가장 직접적인 최적화는 무엇인가요? | daunlee.com/g/data/20#10 ↗ |
| 23#1 | PDE Exam Scope ↔ Course & Lab MappingPDE 시험 범위 ↔ 강의·랩 연결 지도 | Mapping official PDE 5 domains to course slides, labs, and hands-on exercises공식 시험 5영역에서 기존 장표·랩과 추가 실습으로 연결 | daunlee.com/g/data/23#1 ↗ |
| 23#2 | Post-Course Diagnosis → Remediation → Re-evaluation수료 후 진단 → 취약 영역 복습 → 재점검 | Diagnose with official sample questions, review weak domains, and re-assess with scenarios공식 샘플로 진단하고, 취약 영역을 복습한 뒤 다른 시나리오로 재점검 | daunlee.com/g/data/23#2 ↗ |
WIP |
Work in ProgressWork in Progress (제작 진행 중 자료) | Work in progress: Mindmaps, Comic Architecture Sketches, and Interactive DB Cost Simulator.마인드맵(vis · mindmap) · 만화풍 스케치(vis · sketch) · 인터랙티브 DB 시뮬레이터(generative-ui) 3종 | daunlee.com/g/data/100~102 ▾ |
| #100 | Mindmap (vis · mindmap)마인드맵 (vis · mindmap) | Interactive branching mindmap expanding key data concepts into left/right tree structures (WIP)중심 주제에서 하위 개념 · 분류 체계를 좌우 가지로 펼치는 마인드맵 (WIP) | daunlee.com/g/data/100 ↗ |
| #101 | Comic Sketch Architecture (vis · sketch)만화풍 스케치 (vis · sketch) | Friendly hand-drawn style architectural sketches of system structures (WIP)시스템 · 도구 구조를 친근한 손그림 느낌 다이어그램으로 그린 스케치 (WIP) | daunlee.com/g/data/101 ↗ |
| #102 | Interactive DB Selector & Cost Simulator (generative-ui)인터랙티브 위젯 (generative-ui) | Interactive calculator comparing Google Cloud DB options and monthly cost estimations (WIP)조건을 조작하며 Google Cloud DB 선택과 월 비용을 비교하는 위젯 (WIP) | daunlee.com/g/data/102 ↗ |
Course material for a 4-day Google Cloud data and database training, built as a website with narrated slides in Korean, English and Portuguese. While it speaks, the narration scrolls the page, steps through the diagrams and moves a cursor to point at things.Google Cloud 데이터·데이터베이스 4일 과정의 교안을 웹사이트로 만들었습니다. 한국어·영어·포르투갈어 해설이 말하는 동안 페이지를 스크롤하고, 그림을 한 단계씩 넘기고, 커서를 움직여 짚어 줍니다.
Words글
Korean text per segment, with scroll and cursor cues구간별 한국어 글과 스크롤·커서 연출 지시
Turns the script into cue JSON, one file per language스크립트를 언어별 cue JSON으로 변환
HTML on Vercel, slides switch by URL hashVercel의 HTML, 장표는 주소 해시로 전환
Voice음성
The same segments, one set per language같은 구간을 언어별로 한 벌씩
One engine and one voice per language언어마다 엔진과 목소리 하나씩
audio.cloudaimarket.com, cached close to the listeneraudio.cloudaimarket.com, 듣는 사람 가까이에 캐시
The player keeps voice, scroll, cursor and diagram steps in sync플레이어가 음성·스크롤·커서·그림 단계를 맞춰 재생합니다
Before every release배포할 때마다
Plain HTML, CSS and JavaScript generated by Python build scripts. Several slides share one file and switch by URL hash, so nothing reloads.순수 HTML·CSS·JavaScript를 Python 빌드 스크립트로 생성합니다. 여러 장표를 한 파일에 담아 주소 해시로 바꾸므로 새로고침이 없습니다.
Reads cue JSON that says when to speak, scroll, press a button or advance a diagram step. It switches between a card, a bar and a phone dock to fit the screen.언제 말하고, 스크롤하고, 버튼을 누르고, 그림을 한 단계 넘길지 적힌 cue JSON을 읽습니다. 화면에 맞춰 카드·가로 막대·휴대폰 하단 도킹으로 바뀝니다.
One text-to-speech engine per language, generated for all 855 segments.언어마다 음성 합성 엔진을 하나씩 써서 855개 구간 전부를 만들었습니다.
Pages on Vercel. The audio sits on Cloudflare R2 because Vercel's free plan caps an upload at 100 MB and the audio is several hundred MB.페이지는 Vercel에 둡니다. 음성은 수백 MB인데 Vercel 무료 플랜 업로드가 100MB까지라서 Cloudflare R2에서 내려줍니다.
A deploy script rebuilds the live state, lets only the intended files differ, publishes, then checks everything again.배포 스크립트가 라이브와 같은 상태를 만들고, 의도한 파일만 다른지 확인한 뒤 올리고, 올린 뒤 전체를 다시 대조합니다.
Author memos such as "needs verification" were mixed into 14 script segments and would have been spoken to students. The converter now cuts them out and keeps them in a separate list."확인 필요" 같은 작성자 메모가 14개 구간에 섞여 학생에게 읽힐 뻔했습니다. 변환기가 잘라 내고 별도 목록으로 남깁니다.
My first overlap test reported 36 collisions, but the test skipped the real click flow. I re-measured with the real flow and fixed only what was real.처음 겹침 측정은 36곳이라고 나왔지만 측정 스크립트가 실제 클릭 흐름을 건너뛴 결과였습니다. 실제 흐름으로 다시 재고 진짜 문제만 고쳤습니다.
Unescaped quotes in 124 places broke one page's slide data, so none of its slides opened. Scanning the live pages is how it was found.따옴표 124곳이 이스케이프되지 않아 한 페이지의 장표 데이터가 깨졌고 장표가 하나도 열리지 않았습니다. 라이브 페이지를 점검하다 찾았습니다.
Built with AI coding agents (Claude Code and Gemini). I set the requirements, then reviewed and verified the results.AI 코딩 에이전트(Claude Code, Gemini)와 함께 만들었습니다. 요구사항을 정하고 결과를 검토·검증한 것은 저입니다.
Like copilot.cloudaimarket.com and daunlee.com/mct, this is my own site, built on my own time. It is not a client deliverable.copilot.cloudaimarket.com, daunlee.com/mct와 마찬가지로 제 개인 사이트이며 고객에게 납품한 결과물이 아닙니다.