정답 · 해설

해설

【핵심 용어】 ▸ AWS Step Functions — 서버리스 워크플로 오케스트레이션, Glue·Lambda를 상태로 연결 ▸ Workflow Studio — 시각적 워크플로 편집기, 전체 파이프라인 lineage를 단일 인터페이스에서 조회 ▸ 서버리스 오케스트레이션 — Airflow(MWAA) 대비 인프라 관리 불필요 【정답 포인트】 ▸ "Glue 성공 후 Lambda 3개 호출 + 서버리스 + 단일 인터페이스에서 전체 lineage" → (A) Step Functions 워크플로로 Glue·Lambda 오케스트레이션, Workflow Studio에서 lineage 확인 【오답 체크】 (B) Airflow(MWAA)는 서버리스가 아니며 인프라 관리 필요. (C) Glue 잡 내 Lambda 호출 + CloudWatch Logs Insights는 lineage 시각화 단일 인터페이스 아님. (D) Glue 잡 코드에서 Lambda 호출하는 방식은 오케스트레이션·lineage 가시성 부족. 【시험 포인트】 "서버리스 오케스트레이션 + 시각적 lineage" → Step Functions Workflow Studio.

해설

【핵심 용어】 ▸ Iceberg Merge-on-Read (MoR) — 쓰기 시 델타만 기록해 수집(ingest) 속도 빠름, 읽기 시 병합 ▸ Copy-on-Write (CoW) — 쓰기 시 전체 파일 재작성, 수집 지연 유발(스트리밍 부적합) ▸ Glue Data Catalog 압축 최적화기(compaction optimizer) — 자동 압축으로 짧은 쿼리 시간 유지 【정답 포인트】 ▸ "빠른 수집(지연 없이) + 짧은 쿼리 시간 + Spark 스트리밍 → Iceberg" → (C) Kinesis Data Streams 수집 + MoR 모드(쓰기 빠름) + Glue Data Catalog 압축 최적화기(읽기 성능 유지) ▸ MoR로 수집 지연 최소화, 자동 compaction으로 쿼리 성능 보장 【오답 체크】 (A) CoW 모드는 쓰기마다 파일 재작성이라 수집 속도 저하, "수집 방해 없이" 요구 위반. (B) MSK도 가능하나 CoW 모드가 수집 성능 요구와 배치. (D) Firehose+Lambda 중첩 스키마 처리는 지문의 "EMR Spark 스트리밍→Iceberg" 조건과 불일치. 【시험 포인트】 "고속 수집 + 짧은 쿼리 Iceberg 스트리밍" → MoR 모드 + 자동 compaction.

해설

【핵심 용어】 ▸ Kinesis Data Streams 확장 보존(extended retention) — 최대 며칠~1년 데이터 보존, 과거 데이터 재처리(replay) 가능 ▸ 멱등 소비자(idempotent consumer) + DynamoDB 체크포인팅 — 중복 없는 재처리, 처리 상태 추적 ▸ 별도 처리 경로(separate paths) — replay와 실시간을 분리해 실시간 처리 무중단 【정답 포인트】 ▸ "며칠치 과거 데이터 중복 없이 재처리 + 실시간 무중단" → (A) 확장 보존(며칠치 replay 가능) + DynamoDB 체크포인팅 멱등 소비자(중복 방지) + replay/실시간 별도 경로(간섭 방지) 【오답 체크】 (B),(D) 표준 보존은 며칠치 과거 데이터 replay에 부족, RDS 체크포인팅은 확장성·운영 면에서 DynamoDB보다 열등. (C) 공유 처리 경로는 replay가 실시간 처리를 방해, "무중단" 요구 위반. 【시험 포인트】 "과거 replay + 중복 없음 + 실시간 무중단" → 확장 보존 + DynamoDB 멱등 체크포인팅 + 경로 분리.

해설

【핵심 용어】 ▸ EventBridge → Glue 워크플로 — 신규 데이터 도착 감지 후 Glue 워크플로 실행 ▸ AWS Glue DataBrew — 노코드 데이터 준비, 민감정보 마스킹(PII) 변환 제공 ▸ 최소 운영 오버헤드 — 커스텀 코드 없이 관리형 서비스 조합 【정답 포인트】 ▸ "신규 데이터 자동 감지 + 민감정보 마스킹 + 최소 오버헤드" → (D) EventBridge로 신규 데이터 감지·Glue 워크플로 실행 + Glue DataBrew로 마스킹 + S3 저장 【오답 체크】 (A) Macie는 민감정보 탐지·분류용이나 자동 "마스킹" 실행 도구는 아님, 조합이 부적합. (B) MSK+EMR 워크플로는 파일 도착 감지·마스킹에 과도하게 무겁고 스트리밍 지향. (C) Kinesis+Comprehend+DynamoDB는 파일 기반 배치 마스킹 요구와 불일치, 복잡. 【시험 포인트】 "파일 도착 감지 + 노코드 마스킹" → EventBridge + Glue + DataBrew.

해설

【핵심 용어】 ▸ Amazon SageMaker(Data/ML Assets) 자산 카탈로그 — 크로스 계정 데이터셋 게시·검색·접근 요청, 승인 워크플로 + 접근 추적 ▸ 데이터 거버넌스 — 접근 제어 유지 + 컴플라이언스용 데이터 접근 추적 ▸ 최소 운영 오버헤드 — 관리형 카탈로그로 검색·승인·감사 일원화 【정답 포인트】 ▸ "크로스 계정 데이터셋 검색 + 접근 제어 유지 + 접근 추적" → (A) SageMaker Assets(자산 카탈로그)로 게시·검색·접근 요청, 승인 워크플로가 접근 추적 【오답 체크】 (B) Feature Store 크로스 계정 자동 공유는 승인 워크플로·접근 제어 요구와 배치. (C) 모든 계정 전 데이터셋 접근 IAM 역할은 최소 권한·거버넌스 위반, 운영 부담. (D) 도메인 격리·공유 불가는 "데이터셋 검색·공유" 요구 정면 위반. 【시험 포인트】 "크로스 계정 데이터셋 검색+거버넌스+감사" → SageMaker 자산 카탈로그(승인 워크플로).

해설

【핵심 용어】 ▸ CloudTrail 데이터 이벤트(data events) — Publish/PublishBatch 같은 리소스 데이터 평면 API를 기록(관리 이벤트는 제어 평면만) ▸ CloudTrail Lake — 이벤트 데이터 스토어에 수집된 로그를 SQL로 직접 쿼리 ▸ SNS Publish 감사 — 데이터 이벤트로만 캡처 가능 【정답 포인트】 ▸ "SNS Publish/PublishBatch 감사 + 쿼리 + 최소 오버헤드" → (C) SNS 토픽에 데이터 이벤트 활성화 + 이미 구성된 CloudTrail Lake에서 쿼리 ▸ Publish류는 데이터 이벤트, Lake에서 바로 SQL 쿼리라 별도 Glue/Athena 불필요 【오답 체크】 (A),(B) 관리 이벤트는 Publish/PublishBatch(데이터 평면)를 캡처하지 못함. (D) 데이터 이벤트는 맞으나 Glue Catalog+Athena 추가는 이미 있는 Lake를 두고 불필요한 오버헤드. 【시험 포인트】 "데이터 평면 API(Publish 등) 감사" → CloudTrail 데이터 이벤트 + Lake 쿼리.

해설

【핵심 용어】 ▸ AWS Glue DataBrew 프로파일링 잡 — null·형식 불일치·이상치 등 데이터 품질 메트릭을 노코드로 산출 ▸ 재사용 레시피 액션(recipe) — 규칙 기반 프로파일링을 여러 데이터셋에 반복 적용 ▸ 스케일·최소 코드 — 커스텀 PySpark 없이 반복 가능한 품질 모니터링 【정답 포인트】 ▸ "규칙 기반 프로파일링 재사용 + 여러 데이터셋 확장 + 최소 코드" → (C) DataBrew 프로파일링 잡 + 재사용 레시피 액션을 각 S3 데이터셋에 스케줄 실행 【오답 체크】 (A) Glue Studio PySpark 파이프라인은 커스텀 코드 필요, "최소 코드" 요구 위반. (B) dynamic frames/ResolveChoice는 스키마 정렬용이지 품질 프로파일링(널·이상치)의 반복 규칙 솔루션 아님. (D) DataBrew 대시보드 + 수동 검토는 "최소 수작업·반복 가능" 요구 위반. 【시험 포인트】 "규칙 기반 데이터 품질 프로파일링 노코드" → Glue DataBrew 프로파일링 잡 + 레시피.

해설

【핵심 용어】 ▸ Amazon EMR on EKS — 기존 EKS 인프라에서 관리형 Spark 실행, 운영 부담 낮음 ▸ KEDA(Kubernetes Event-Driven Autoscaling) — 이벤트 기반 스케일링으로 자원 최적화 ▸ 이벤트 기반 스케일링 — 스트리밍 부하에 따라 파드/Spark 앱 확장 【정답 포인트】 ▸ "EKS에서 Spark 스트리밍 + 이벤트 기반 스케일링 + 자원 최적화 + 최소 오버헤드" → (B) EMR on EKS + KEDA로 이벤트 기반 Spark 확장 ▸ 관리형 EMR on EKS가 자체 관리 대비 오버헤드↓, KEDA가 이벤트 기반 스케일 담당 【오답 체크】 (A) 자체 관리 Spark on EKS는 운영 오버헤드 큼(관리형 아님). (C) Cluster Autoscaler + Metrics Server는 노드 스케일 중심이라 "이벤트 기반" 요구에 KEDA보다 부적합. (D) 자체 Spark + Auto Scaling 그룹 커스텀 정책은 운영 부담 크고 이벤트 기반 아님. 【시험 포인트】 "EKS 관리형 Spark + 이벤트 기반 스케일" → EMR on EKS + KEDA.

해설

【핵심 용어】 ▸ Step Functions + Glue 트리거(시간/이벤트 기반) — 일일 배치와 5분 이내 캘린더 갱신을 오케스트레이션 ▸ Amazon OpenSearch Service — 복잡한 전문(full-text) 검색 제공 ▸ S3 저장 — 처리 데이터 저장, OpenSearch가 검색 담당 【정답 포인트】 ▸ "복잡한 전문 검색 + 5분 이내 최신성 + AWS Glue ETL + 최소 오버헤드" → (B) Step Functions로 Glue 잡 오케스트레이션(시간·이벤트 트리거) + S3 저장 + OpenSearch로 full-text 검색 【오답 체크】 (A) RDS는 복잡한 전문 검색에 부적합(OpenSearch가 적합). (C) DynamoDB + Lambda 커스텀 검색은 전문 검색 구현 부담 큼. (D) Kendra는 자연어 검색 지향으로 과하고, RDS 저장·전체 구성이 요구와 덜 맞음. 【시험 포인트】 "복잡한 full-text 검색" → OpenSearch Service.

해설

【핵심 용어】 ▸ AWS SAM — 서버리스 앱 정의·패키징·배포 프레임워크, S3 이벤트 소스를 템플릿에 선언 ▸ sam build → sam deploy --guided — 빌드 후 대화형 가이드 배포(리소스·이벤트 트리거 자동 프로비저닝) ▸ S3 event source in template — 버킷·이벤트 트리거를 IaC로 정의 【정답 포인트】 ▸ "SAM으로 파이프라인 패키징·배포" → (A) 첫 S3 버킷과 Lambda의 S3 이벤트 소스를 SAM 템플릿에 추가, sam build 후 sam deploy --guided 실행 【오답 체크】 (B) sam deploy 직접 + 콘솔 수동 트리거 구성은 IaC 원칙·자동화에 어긋나고 SAM 표준 흐름 아님. (C) sam package + CloudFormation 스택 + 수동 이벤트 알림은 불필요하게 복잡, SAM 표준 흐름 아님. (D) sam build 후 aws cloudformation deploy 혼용은 SAM 표준 배포(sam deploy)와 어긋남. 【시험 포인트】 "SAM 표준 배포 흐름" → sam build → sam deploy (--guided), 이벤트 소스는 템플릿에 선언.

해설

【핵심 용어】 ▸ ALTER TABLE DROP PARTITION — Glue Data Catalog에서 특정 파티션 메타데이터 제거 ▸ 빈 파티션 정리 — 데이터 이동 후 남은 status=01 파티션 메타데이터 삭제 ▸ MSCK REPAIR TABLE — 신규 파티션 추가 감지용(제거엔 부적합) 【정답 포인트】 ▸ "status=01 위치는 비었으나 카탈로그에 파티션 메타데이터 잔존" → (B) ALTER TABLE DROP PARTITION으로 해당 파티션 정의 제거 【오답 체크】 (A) MSCK REPAIR TABLE은 새 파티션 추가를 스캔·등록하는 명령, 빈 파티션 제거 목적엔 부적합. (C) SET TBLPROPERTIES는 테이블 속성 변경용, 파티션 제거와 무관. (D) CHANGE COLUMN은 컬럼 정의 변경용, 파티션 메타데이터와 무관. 【시험 포인트】 "빈 파티션 메타데이터 제거" → ALTER TABLE DROP PARTITION.