정답 · 해설

해설

【핵심 용어】 ▸ Amazon Managed Service for Apache Flink — KDS 스트림에 복잡 처리(조인·윈도·이상 탐지)를 관리형으로 수행. 결과를 S3에 적재. 【정답 포인트】 ▸ 복잡 처리 + 저지연 + S3 적재 = KDS + Flink. Firehose 단순 변환으론 한계. 【오답 체크】 (A) Lambda 변환은 단순 케이스에 한정. (B) Firehose 내장 변환은 단순 변환만. (D) Firehose + Lambda는 가능하지만 복잡 처리는 Flink가 표준.

해설

【핵심 용어】 ▸ Glue DataBrew Profile Job + Ruleset — GUI로 데이터 품질 룰 정의 후 프로파일 잡으로 검증. 【정답 포인트】 ▸ ML 학습 데이터 품질 검사 + 최소 운영 = DataBrew 룰셋 + 프로파일 잡 + EventBridge 트리거. 【오답 체크】 (A) Lambda 직접 검증 + CloudWatch는 코드 부담. (C) EMR + Python 라이브러리는 클러스터 운영 부담. (D) Step Functions + Lambda도 직접 구현 부담.

해설

【핵심 용어】 ▸ Glue Data Catalog 파티션 갱신 = MSCK REPAIR/크롤러/Boto3 호출. 신규 파티션이 등록 안 되면 Athena 쿼리에서 누락. 【정답 포인트】 ▸ 누락/오래된 데이터 = Glue Catalog가 최신 S3 파티션 미반영. 【오답 체크】 (B) IAM은 권한 — 데이터 누락 원인 아님. (C) Versioning은 객체 버전. (D) 잡 스케줄 겹침은 데이터 충돌 — 누락이라기보단 정합성 문제.

해설

【핵심 용어】 ▸ Redshift Federated Queries — RDS for MySQL 데이터를 Redshift에서 직접 SQL로 조회 + Redshift 테이블과 join. 【정답 포인트】 ▸ 당일 트랜잭션(MySQL) + 과거(Redshift) join + 데이터 이동 최소 = Federated Query. 【오답 체크】 (A) DMS 지속 복제는 인프라 + 데이터 이중화. (C) 시간당 ETL은 지연·운영 부담. (D) S3 export + COPY = 단계 분산 + 지연.

해설

【핵심 용어】 ▸ Glue Studio Data Preparation Recipes — DataBrew 레시피 통합. 데이터 분석가가 코드 없이 변환 정의. 【정답 포인트】 ▸ 코드 없이 + 분석가 친화 + 후속 엔지니어 변환 추가 = Glue Studio 레시피. 【오답 체크】 (A) Python/Pandas는 코딩. (B) SageMaker Canvas + Wrangler는 ML 데이터 준비 — 일반 ETL 도구가 아님. (D) 문서로 정의는 자동 실행 X.

해설

【핵심 용어】 ▸ DMS → KDS (테이블 단위 스트리밍) + DMS → S3 (전체 적재) — 단일 소스에서 두 가지 적재. ▸ Lambda — KDS 데이터 처리 + REST API 호출. 【정답 포인트】 ▸ customer_complaints 실시간 + REST API + 다른 테이블은 향후 분석용 S3 = DMS 두 작업 + Lambda. 【오답 체크】 (A) PostgreSQL 우회는 비용 부담. (B) Redshift 경유 + Lambda 폴링은 지연 큼. (D) Read replica + Lambda는 near real-time 모호.

해설

【핵심 용어】 ▸ Redshift Materialized View — 자주 쓰는 복잡 쿼리 결과를 미리 계산·저장. AUTO REFRESH로 신선도 유지. 【정답 포인트】 ▸ 시간당 복잡 변환 시간 단축 = MV. 매번 재계산 회피. 【오답 체크】 (A) Concurrency Scaling은 동시성 문제 해결 — 단일 쿼리 시간 직접 단축 아님. (B) Athena 우회는 클러스터 활용 안 함. (C) Spectrum 외부 테이블은 추가 지연.

해설

【핵심 용어】 ▸ Glue Flex Job + Redshift Serverless — 둘 다 서버리스 + 사용 시간만 과금. 야간 ETL + 업무 시간 쿼리 패턴에 비용 효율. 【정답 포인트】 ▸ 야간 처리(Flex 잡) + 업무 시간 쿼리(Serverless) = 비용 최저. 【오답 체크】 (A) EMR은 클러스터 비용. (C) Lambda는 큰 데이터 한계. (D) Provisioned Redshift는 24/7 비용.

해설

【핵심 용어】 ▸ Step Functions — 단계 분리·재시도·실패 가시성 내장. Lambda·Glue 통합. 【정답 포인트】 ▸ 인입(Lambda) + 변환(Glue) + 저장(S3) + 재시도 + 가시성 + 최소 운영 = Step Functions. 【오답 체크】 (A) Glue 잡 트리거 체인은 단계별 가시성·재시도 설정 부족. (C) EventBridge 체인은 실패 처리 직접 구현. (D) MWAA는 클러스터 비용.

해설

【핵심 용어】 ▸ AWS Lake Formation Cross-Domain — 도메인 간 테이블 공유 + 행/열 fine-grained 권한 + CloudTrail 감사 통합. 1,000+ 테이블 확장. 【정답 포인트】 ▸ 데이터 메시 + cross-domain + PII 접근 제한 + 감사 = Lake Formation. Athena/Redshift 모두 통합. 【오답 체크】 (A) Athena 뷰 + LF는 가능하지만 단편적. (B) Glue Data Catalog 뷰는 표준 패턴 아님. (D) Redshift 데이터셰어만으론 도메인 간 1,000+ 테이블 거버넌스 부족.

해설

【핵심 용어】 ▸ AWS Backup + Vault Lock (Compliance Mode) — S3·RDS 통합 백업 + 보존 기간 동안 누구도 삭제·수정 불가. 우발적·악의적 삭제 방어. 【정답 포인트】 ▸ S3 + RDS + 보존·불변성 + 최소 운영 = AWS Backup + Vault Lock 컴플라이언스. 【오답 체크】 (A) MFA Delete는 S3만, 우발적 삭제 방지는 가능하나 통합 운영 X. (B)(D) 복제는 백업 보존 정책과 다름.

해설

【핵심 용어】 ▸ S3 SHA-256 체크섬 — 업로드 시 클라이언트가 계산한 해시를 PUT에 포함하면 S3가 검증·기록. 향후 무결성 검증 기준. 【정답 포인트】 ▸ 전송 손상 검증 = 사전 SHA-256 + SDK 전달. S3가 자동 비교. 【오답 체크】 (A) 부분 다운로드 수동 검증 = 운영 부담. (B) SSE-C는 암호화 — 무결성 검증 도구 아님. (D) 전체 다운로드 검증 = 비용·시간 부담.

해설

【핵심 용어】 ▸ S3 Object Lock + Glacier Flexible Retrieval — 7년 불변 보존 + 1년 후 5시간 내 검색 가능 + WORM 모델. 【정답 포인트】 ▸ 7년 WORM(Object Lock) + 1년 후 5시간 검색(Glacier Flexible Retrieval) = 정확한 매핑. 【오답 체크】 (A) Versioning만으론 WORM 아님. (B) Deep Archive는 검색 12시간 — 5시간 요건 위반. (D) Versioning + Deep Archive 동일 문제.

해설

【핵심 용어】 ▸ Amazon MWAA — 관리형 Airflow. 스크립트 단계 실행 + 서버리스(완전 관리). 복잡 파이프라인 표준. 【정답 포인트】 ▸ 복잡 파이프라인 + 스크립트 실행 + 관리형 = MWAA. 【오답 체크】 (A) Glue 잡은 ETL 한정. (C) EC2는 서버 관리. (D) DataBrew는 데이터 정리 GUI — 복잡 파이프라인 아님.

해설

【핵심 용어】 ▸ S3 Lifecycle 정책 — Standard → Standard-IA(60일) → Glacier Flexible Retrieval(180일) → Expire(365일). ▸ Glacier Flexible Retrieval — 시간 단위 검색 가능(요건 충족). 【정답 포인트】 ▸ 0~60 즉시 + 61~180 가끔 + 181~365 시간 단위 + 365 후 삭제 = 표준 라이프사이클 4단계. 【오답 체크】 (A) Intelligent-Tiering Archive Access는 분 단위 검색 X. (C)(D) Inventory + Batch는 운영 부담 — 라이프사이클이 가장 단순.

해설

【핵심 용어】 ▸ DynamoDB Query (Key Condition with Partition Key) — 파티션 키 명시 = 해당 파티션만 조회. 최소 RCU. ▸ Scan = 전체 테이블, 매우 비효율. 【정답 포인트】 ▸ 파티션 키 알고 있음 + 최소 RCU = Query API + Key Condition + DynamicFrame. 【오답 체크】 (A) 필터 옵션은 사후 필터 — 스캔 발생. (B) Sort key만으론 Query 불가. (C) Scan은 전체 테이블 RCU 소비.

해설

【핵심 용어】 ▸ EMR Runtime Roles for Steps — EMR 스텝마다 다른 IAM role 부착. 같은 클러스터에서도 팀별 스텝이 별도 권한으로 실행. 【정답 포인트】 ▸ 한 클러스터·여러 팀 + 특정 팀만 DynamoDB 접근 = Runtime Role for Step. 스텝 단위 권한 격리. 【오답 체크】 (B) Lake Formation은 S3 데이터 레이크 권한 — DynamoDB는 대상이 아님. (C) EMRFS IAM role은 S3 한정. (D) DynamoDB resource policy로 EMR 클러스터의 특정 팀만 식별하기 어려움.

해설

【핵심 용어】 ▸ Iceberg Auto Compaction — 테이블 속성으로 파일 크기·개수 임계값 설정 → Glue Catalog가 자동 컴팩션. 작은 파일 누적 방지. 【정답 포인트】 ▸ 시간이 갈수록 작은 파일 누적 + 자동 처리 = Iceberg auto compaction(테이블 속성). 【오답 체크】 (A) 일일 Glue 컴팩션은 가능하지만 자동 임계 기반이 더 효율. (B) '매분 컴팩션'은 비현실적·고비용. (D) 파티션만으론 작은 파일 문제 해결 X.

해설

【핵심 용어】 ▸ CloudWatch Alarms + KDS/Firehose 메트릭 — IncomingBytes, OutgoingBytes, DeliveryToS3.Success 등 핵심 지표 임계 알람. 【정답 포인트】 ▸ 파이프라인 헬스 + 최소 운영 = CloudWatch Alarms. 코드 0. 【오답 체크】 (A) 수동 로그 검토는 운영 부담. (C) Lambda 일일 체크는 코드 + 지연. (D) Flink 이상 탐지는 비용·복잡 — 헬스 모니터링엔 과한 옵션.

해설

【핵심 용어】 ▸ DynamoDB On-Demand + GSI — 단일 자릿수 ms 응답, 트래픽 스파이크 자동 처리. GSI로 보조 속성(Category·Brand) 쿼리 지원. 【정답 포인트】 ▸ ms 응답 + 스파이크 + 가변 속성 + 보조 키 쿼리 = DynamoDB On-Demand + GSI. 【오답 체크】 (B) Aurora Multi-AZ는 ms 보장과 스파이크 자동 대응 약함. (C) OpenSearch Serverless는 검색용이지 OLTP 패턴 아님. (D) ElastiCache + S3 + Athena는 ms 일관 응답 어려움.