정답 · 해설

해설

【핵심 용어】 ▸ Glue ETL Evaluate Data Quality 변환 + DQDL 룰 — IsComplete (null 검사), ReferentialIntegrity (참조 무결성). 【정답 포인트】 ▸ null + 참조 무결성 + 최소 운영 = DQDL 표준 룰 두 개. 코드 작성 없음. 【오답 체크】 (A) Data Wrangler는 ML 데이터 준비. (C) SQL 변환 직접 작성 = 코드 부담. (D) Python 커스텀 변환도 코드 부담.

해설

【핵심 용어】 ▸ Glue ETL + Glue Data Quality + RDS MySQL — 모두 관리형. RDS는 처리 결과·품질 점수 통합 저장. 【정답 포인트】 ▸ Glue ETL로 변환 + Data Quality로 룰 검증 + RDS MySQL에 결과·품질 모두 적재 = 비용 효율 + 통합. 【오답 체크】 (B) Studio + DataBrew + RDS + S3 분리 = 단계 분산. (C) 결과를 S3에만 저장하면 향후 SQL 쿼리 부담. (D) DataBrew로 변환은 가능하지만 큰 데이터에 비용 부담.

해설

【핵심 용어】 ▸ Redshift UNLOAD — Redshift 데이터를 S3로 내보냄. 다른 계정 S3 버킷도 권한 부여 시 가능. ▸ Glue 잡 스케줄 — UNLOAD 명령을 주간 실행. 【정답 포인트】 ▸ 주 1회 vendor S3로 데이터 송출 = Glue 잡 + UNLOAD 명령 스케줄. 【오답 체크】 (A) Lambda + COPY는 Redshift로 들이는 명령. UNLOAD가 정확. (C) Data sharing은 Redshift 간 공유 — S3 직접 송출 X. (D) Spectrum은 S3 외부 테이블 쿼리이지 데이터 송출 도구 아님.

해설

【핵심 용어】 ▸ Redshift Schema-level Permissions — 각 부서의 객체를 별도 스키마로 묶고 GRANT USAGE/SELECT를 스키마 단위로 부여. 같은 DB 내 cross-schema 쿼리 자연. 【정답 포인트】 ▸ 부서별 분리 + 같은 DB join + 최소 운영 = 스키마 분리 + 권한. 【오답 체크】 (B) DB 분리는 cross-DB 쿼리 부담 큼. (C) 명명 규칙 기반 권한 = 운영 복잡 + 인적 오류. (D) IAM 그룹별 객체 권한 = 객체별 grant 직접 관리 부담.

해설

【핵심 용어】 ▸ Redshift Streaming Ingestion from MSK — 외부 스키마(MSK 매핑) + Materialized View. 별도 ETL 인프라 0. 【정답 포인트】 ▸ MSK → Redshift + 빠른 접근 + 최소 운영 = External Schema + MV. AUTO REFRESH로 신선도 유지. 【오답 체크】 (B) Glue Streaming + S3 + Spectrum = 추가 단계. (C) MV 없이 단순 외부 테이블만으론 데이터 적재 안 됨. (D) S3 + Lambda 경로는 이중 인프라.

해설

【핵심 용어】 ▸ Glue DynamicFrame 그룹화 옵션 — 작은 파일을 자동 묶어 처리. 44,000 작은 파일에 표준 해결. 【정답 포인트】 ▸ small files 문제 + 최소 비용 = file grouping. 워커 수/타입 늘리지 않고 처리 시간 대폭 감소. 【오답 체크】 (A)(B) 워커 사이즈/수 증가 = 비용 증가. (D) Auto scaling도 비용 증가.

해설

【핵심 용어】 ▸ Amazon AppFlow — Salesforce·Slack·SAP 등 SaaS 데이터 통합 관리형. 스케줄·필터 내장. 【정답 포인트】 ▸ SaaS → S3 + Glue 카탈로그 + QuickSight = AppFlow 흐름이 가장 효율적. 코드 0. 【오답 체크】 (A) Lambda + 직접 API 호출 = 인증·페이지네이션 직접 구현. (B) Federated 커넥터 직접 구현 부담. (D) Excel 수동 export = 자동화 위반.

해설

【핵심 용어】 ▸ CloudWatch Logs Subscription Filter → OpenSearch — 로그 그룹의 데이터를 OpenSearch에 자동 스트리밍. 대시보드로 near real-time 시각화. 【정답 포인트】 ▸ near real-time 쿼리·시각화 = OpenSearch + 구독 필터 + Dashboards. 【오답 체크】 (A) Lambda 주기 export → S3 → Athena = 배치 지연. (C) CloudWatch 이상 탐지는 시각화 대시보드가 아님. (D) 앱 코드를 QuickSight로 직접 송출은 비표준.

해설

【핵심 용어】 ▸ Glue ETL → Apache Parquet — 컬럼형 변환으로 일일 분석 쿼리 비용·시간 절감. 검색·집계 핵심 최적화. 【정답 포인트】 ▸ CSV → Parquet 변환 = 스토리지 용량↓ + 분석 쿼리 스캔량↓. 【오답 체크】 (A) Glacier 이전은 일일 분석에 부적합(검색 지연). (B) Aurora 이전은 컴퓨팅 비용 부담. (D) EMR 도입은 운영 부담 증가.

해설

【핵심 용어】 ▸ Athena/Spark 파티션 필터 — WHERE 절에 파티션 컬럼 사용 시 파티션 프루닝으로 스캔 최소화. 【정답 포인트】 ▸ 파티션된 데이터 + 스캔 최소 = 쿼리에 파티션 필터 명시. 【오답 체크】 (B) 크롤러 빈도 증가 = 메타데이터 갱신만, 스캔량 영향 X. (C) 중첩 디렉토리는 자동 프루닝 안 함. (D) 인메모리 캐시는 반복 쿼리만 도움.

해설

【핵심 용어】 ▸ QuickSight VPC 연결 — 같은 계정/다른 계정 모두 SG 인바운드로 Redshift 포트 허용 필요. SG 소스에 QuickSight SG ID 지정. 【정답 포인트】 ▸ Redshift SG 인바운드에 QuickSight SG ID 허용 = 표준 패턴. 크로스 계정 SG 참조 가능. 【오답 체크】 (B) QuickSight에 EIP 할당은 표준 기능 아님. (C) CIDR 일치는 피어링 요건이지만 시나리오상 불필요. (D) QuickSight Gateway Endpoint 같은 서비스는 없음.

해설

【핵심 용어】 ▸ Glue Event-Based Trigger via EventBridge — S3 객체 도착 이벤트 → CloudTrail/EventBridge → Glue Workflow 즉시 시작. 【정답 포인트】 ▸ 도착 즉시 처리 = 이벤트 기반 트리거. 폴링 지연 없음. 【오답 체크】 (A) 15분 폴링은 즉시성 부족. (C) 15분 cron 동일. (D) DMS는 S3 객체 트리거 도구 아님.

해설

【핵심 용어】 ▸ Lambda + S3 Event + SNS — 1분 내 변환 + 이메일 알림. 모든 단계 서버리스. 【정답 포인트】 ▸ 시간당 1개 + 1분 미만 작업 + 이메일 = Lambda + SNS. 가장 가벼움. 【오답 체크】 (A)(B) EC2/ECS 폴링은 인프라 운영 부담. (D) EMR은 작은 워크로드에 과한 비용.

해설

【핵심 용어】 ▸ PySpark DynamicFrame Schema 정의 — 우편번호 같은 형식 강제 컬럼에 명시적 타입·포맷 지정. 잘못된 값은 ChoiceType으로 처리·교정. 【정답 포인트】 ▸ 형식 강제 + 잘못된 값 처리 = 스키마 정의 후 DynamicFrame에 전달. 【오답 체크】 (B) 잡 상태 공유는 데이터 형식 교정과 무관. (C) push_down_predicate는 파티션 필터링 — 형식 교정 아님. (D) useS3ListImplementation은 S3 리스팅 옵션.

해설

【핵심 용어】 ▸ EventBridge Rule on Glue Job State = FAILED → SNS → Email — 이메일 구독은 Standard 토픽만(FIFO 미지원). 【정답 포인트】 ▸ Glue 실패 시 자동 이메일 = SNS Standard + EventBridge 규칙(Glue 잡 상태 FAILED). 【오답 체크】 (A) FIFO 토픽은 이메일 구독 미지원. (C)(D) SQS는 이메일 직접 구독 안 됨.

해설

【핵심 용어】 ▸ EventBridge Rule(Glue 실패) → CloudWatch Metric → CloudWatch Alarm → SNS — Lambda 없이 알림 자동화. 【정답 포인트】 ▸ EventBridge 매칭 + 메트릭 + Alarm + SNS = Lambda 추가 운영 0. 【오답 체크】 (A) Lambda 추가는 운영 부담. (B) 로그 파싱·Lambda는 무거움. (D) EventBridge → SNS 직접도 가능하지만 알람 임계 제어가 필요할 때 (C)가 더 정교.

해설

【핵심 용어】 ▸ Glue Spark 잡 + Spark UI (영구 로그) — 단계(Stage)·태스크별 실행 시간·셔플·메모리 메트릭 시각화. 【정답 포인트】 ▸ 단계 메트릭 = Spark UI. CloudWatch는 잡 단위 메트릭 한정. 【오답 체크】 (B) CloudWatch는 단계 단위 부족. (C) CloudTrail은 API 감사. (D) Run insights는 잡 수준 인사이트지 단계별 깊이 부족.

해설

【핵심 용어】 ▸ Athena Partition Projection — 파티션 메타데이터를 카탈로그에 등록하지 않고도 패턴(날짜 범위)으로 자동 계산. 파티션 관리 자동화 + 쿼리 플래닝 빠름. 【정답 포인트】 ▸ 5년치 일별 파티션 + 쿼리 성능 + 자동 관리 = Partition Projection. 【오답 체크】 (A) Lambda 일일 파티션 추가는 직접 구현. (C) 일별 → 월별로 줄이면 쿼리 정확도/세분성 영향. (D) Athena 컴퓨팅 늘리기는 비용 부담.

해설

【핵심 용어】 ▸ Glue + Iceberg — Glue 잡 파라미터에 --datalake-formats=iceberg + --extra-jars로 특정 Iceberg 버전 지정. 【정답 포인트】 ▸ B(--extra-jars + --datalake-formats=iceberg) + C(--datalake-formats=iceberg) = 두 단계 모두 Iceberg 활성화. 【오답 체크】 (A) --conf 파라미터 자체는 Iceberg 활성화에 직접 사용 X. (D) auto-scaling은 성능 옵션. (E) 책갈피는 증분 처리 — Iceberg 활성화와 무관.

해설

【핵심 용어】 ▸ Glue Spark Shuffle Manager — 셔플 파일을 S3로 외부 저장. 노드 디스크 한계 회피. 【정답 포인트】 ▸ 'No space left on device' (셔플 디스크 부족) = Glue Spark Shuffle Manager 활성화. EBS 추가 없이 해결. 【오답 체크】 (B) EBS 추가는 비용 + 워커 단위 한계 여전. (C) Broadcast join은 한 쪽 큰 테이블이면 메모리 부족 위험. (D) DynamicFrame join도 셔플 발생 — 디스크 문제 그대로.