정답 · 해설

해설

【핵심 용어】 ▸ Redshift Audit Logs — 사용자 활동·연결 로그를 S3 또는 CloudWatch Logs로 게시. 【정답 포인트】 ▸ S3 버킷 + Redshift 로깅 활성화 = 감사 로그 저장의 표준 패턴. 【오답 체크】 (B) EFS는 Redshift 로그 대상 아님. (C) Aurora MySQL 적재는 비표준. (D) EBS도 로그 대상 아님.

해설

【핵심 용어】 ▸ AWS SCT — 이종 DW 스키마 변환(Teradata → Redshift). 자동 변환 + 수동 보완 리포트. ▸ AWS DMS — 데이터 이전 (full load + CDC). 【정답 포인트】 ▸ 스키마는 SCT, 데이터는 DMS = 표준 마이그레이션 분담. 【오답 체크】 (A) DMS Schema Conversion은 RDB 위주, Teradata엔 SCT가 표준. (C) DMS 자동 스키마 변환은 Teradata 같은 DW에 한계. (D) 수동 export는 운영 부담.

해설

【핵심 용어】 ▸ Amazon Redshift Serverless — 워크그룹·DB 단위 자동 확장. 사용 시간만 과금. 예측 불가 스파이크에 적합. ▸ RMS — Redshift Managed Storage, 컴퓨팅·스토리지 분리. 【정답 포인트】 ▸ 하루 일부만 사용 + 스파이크 + 최소 운영 = Redshift Serverless. RMS에 데이터 적재. 【오답 체크】 (B) Athena는 매번 스캔 — 지속 빠른 응답 어려움. (C) Provisioned는 24/7 비용. (D) Aurora PostgreSQL은 분석 DW 아님 + DirectQuery 성능 한계.

해설

【핵심 용어】 ▸ AWS Lake Formation — 컬럼·행·태그 기반 권한. JSON 같은 반정형 데이터에 직접 적용. 【정답 포인트】 ▸ 같은 JSON에 직원별 다른 권한 + 최소 운영 = Lake Formation 권한. 파일 분리·DB 분리 부담 없음. 【오답 체크】 (A) Glue로 분리 + 두 버킷 = 데이터 중복·운영 부담. (B) Macie는 탐지 도구 — 권한 관리 아님. (D) RDS 두 개 = 데이터 분산·관리 부담.

해설

【핵심 용어】 ▸ Redshift Cross-Region Snapshot Copy — 대상 리전에 KMS 키 + Snapshot Copy Grant 생성 후 소스 리전에서 복사 활성화. 【정답 포인트】 ▸ B(소스 리전에서 복사 활성화 + 대상 리전 grant 이름 지정) + D(대상 리전에 KMS 키 + grant 생성) = 표준 절차. 【오답 체크】 (A) 소스 리전에 grant 생성은 잘못된 위치. (C) 소스 리전 grant 이름 지정도 잘못됨. (E) Multi-AZ는 단일 리전 HA — DR 시나리오와 다름.

해설

【핵심 용어】 ▸ AWS DMS Full Load + CDC — 초기 데이터 + 변경 데이터 모두 처리. 단일 작업으로 RDS·온프레 SQL Server 모두 지원. 【정답 포인트】 ▸ 기존 + 미래 변경분 + 다중 소스(RDS + 온프레) + 비용 효율 = DMS가 두 단계 모두 처리. Glue 분리 불필요. 【오답 체크】 (A)(B) Glue 잡으로 변경분 처리 = CDC 직접 구현 부담. (D) Kinesis + Glue = 추가 인프라.

해설

【핵심 용어】 ▸ S3 Athena 쿼리 = 파티셔닝(주문 일자) + 컬럼형 변환이 핵심 최적화. 【정답 포인트】 ▸ 주문 일자 기반 파티션 + Athena = 일자 범위 쿼리에서 파티션 프루닝 + 비용 효율. 【오답 체크】 (B) Redshift는 클러스터 비용. (C)(D) load date는 비즈니스 쿼리(주문일)와 매핑 안 됨.

해설

【핵심 용어】 ▸ DQDL ReferentialIntegrity 룰 — 한 데이터셋의 컬럼 값이 다른 참조 데이터셋에 모두 있는지 검증. 1.0 = 100%. 【정답 포인트】 ▸ city/state가 reference에 모두 일치 = ReferentialIntegrity 'city,state' 'reference.{ref_city,ref_state}' = 1.0. 【오답 체크】 (A)(C) DatasetMatch는 다른 룰 형식. (D) = 100은 잘못된 비교 표기.

해설

【핵심 용어】 ▸ DMS Full Load + CDC — 초기 적재 후 트랜잭션 로그에서 변경분 지속 캡처. PostgreSQL → Redshift 표준 경로. 【정답 포인트】 ▸ 지속 갱신 + 가능한 빨리 = DMS Full + CDC. 【오답 체크】 (A) pg_dump + SCT 경로는 일회성. (C) pg_dump + COPY도 일회성. (D) 매일 full load = 지연 + 부하.

해설

【핵심 용어】 ▸ S3 + Glue Crawler + Athena Workgroup + 사용량 한도 — 비용 제어 가능한 서버리스 분석. 【정답 포인트】 ▸ CSV/JSON + SQL 분석 + 비용 효율 = S3 + 크롤러 + Athena 워크그룹(한도 설정). 【오답 체크】 (A) RDS MySQL은 분석용 비용 부담. (B) DataBrew는 SQL 쿼리가 아님. (D) SPICE는 캐시 — 데이터 양 많으면 비용↑.

해설

【핵심 용어】 ▸ Aurora zero-ETL Integration with Redshift — 트랜잭션 영향 없이 Redshift로 자동 복제. 별도 ETL 코드 0. 【정답 포인트】 ▸ Aurora → Redshift + 운영 영향 0 + 최소 노력 = zero-ETL. 마케팅 팀이 Redshift에서 join. 【오답 체크】 (A) DMS는 가능하지만 zero-ETL이 더 가벼움. (C) Glue는 ETL 코드 필요. (D) Federated query는 Aurora에 부하 발생.

해설

【핵심 용어】 ▸ S3 → SQS → Lambda — Lambda가 SQS에서 메시지 폴링·재시도. EventBridge 직접 호출 대비 신뢰성·재시도 우수. 【정답 포인트】 ▸ S3 이벤트 → SQS → Lambda 폴링 = 실패 시 재시도·DLQ 등 더 견고. CSV → Redshift COPY 안정. 【오답 체크】 (A) EventBridge → Lambda 직접도 가능하나 재시도 제어가 SQS만큼 세밀하지 않음. (C) DMS는 S3 객체 스트리밍 도구가 아님. (D) EventBridge → SQS → Lambda는 옵션이지만 직접 S3 → SQS가 더 단순.

해설

【핵심 용어】 ▸ Redshift Dynamic Data Masking (DDM) — 컬럼에 마스킹 정책 부착 + role별 다른 결과(전체/마스킹/숨김). 【정답 포인트】 ▸ 같은 데이터 + role별 마스킹 다름 + 데이터 중복 X = DDM 정책. customer support는 끝 4자리, audit는 전체. 【오답 체크】 (B) 메타데이터 보안은 메타 한정. (C) RLS는 행 단위 — 동일 행의 컬럼 마스킹과 다름. (D) Glue redact + 새 테이블 = 데이터 중복.

해설

【핵심 용어】 ▸ Lake Formation Data Lake Location 등록 — S3 경로를 LF에 등록해야 LF가 권한을 위임받아 관리. 미등록 위치는 크롤러도 접근 못 함. 【정답 포인트】 ▸ 'S3 location is not registered' 에러 = LF에 등록 필요. 표준 첫 단계. 【오답 체크】 (A) IAM 권한만으론 LF가 등록되지 않은 위치를 허용 X. (C) DB는 메타데이터 — 위치 등록과 별개. (D) 크로스 계정 정책은 시나리오와 다름.

해설

【핵심 용어】 ▸ Amazon DataZone — 데이터 거버넌스·비즈니스 카탈로그 + 비즈니스 용어집·메타데이터 폼 + 포털 UI 내장. 【정답 포인트】 ▸ 비즈니스 메타데이터·용어집 + 포털 + 최소 운영 = DataZone. Glue 카탈로그·OpenSearch 직접 구축 불필요. 【오답 체크】 (A) Glue Catalog에 직접 비즈니스 메타 추가는 직접 구현·UI 부담. (B) Hive metastore도 직접 운영. (D) OpenSearch 인덱스 직접 구축 부담.

해설

【핵심 용어】 ▸ MERGE WHEN MATCHED THEN DELETE — 두 테이블 매칭되는 행을 대상 테이블에서 삭제. 표준 SQL UPSERT 패턴 변형. 【정답 포인트】 ▸ accounts와 monthly_accounts_update에 모두 있는 customer = accounts에서 삭제. 결과: 매칭된 행 모두 삭제. 【오답 체크】 (B) 보존이 아닌 삭제. (C) 소스 테이블은 영향 없음. (D) Glue Spark SQL은 MERGE 지원.

해설

【핵심 용어】 ▸ Lambda + EventBridge S3 트리거 + Redshift COPY — 100KB~300KB 작은 파일 인입에 가장 가벼움. 【정답 포인트】 ▸ 잦지만 작은 파일 + 최소 운영 = Lambda(COPY) + S3 이벤트 트리거. 인프라 0. 【오답 체크】 (B) Firehose Lambda 소스로 S3 풀링은 비표준. (C) Spectrum은 외부 테이블 — COPY가 아닌 직접 쿼리. (D) DMS는 DB 마이그레이션 — S3 파일 인입 도구 아님.

해설

【핵심 용어】 ▸ Apache Hudi on EMR — 1TB 베이스 테이블에 일일 10K 변경분 upsert. Hudi의 incremental upsert는 Spark 직접 update보다 빠름. 【정답 포인트】 ▸ 큰 베이스 + 작은 변경 + 최저 런타임 = Hudi. 변경분만 인덱스로 처리 — 전체 스캔 회피. 【오답 체크】 (A)(C) Spark update method는 1TB 베이스 전체 스캔. (B) Pandas는 1TB 처리 부적합 (메모리).

해설

【핵심 용어】 ▸ Glue Spark 'No space left on device' — 데이터 스큐로 셔플 디스크 부족. 해결: shuffle을 S3에 쓰기 + salting. ▸ Spark UI / Glue 메트릭 — 스큐 모니터링. 【정답 포인트】 ▸ B(Spark UI/메트릭으로 스큐 모니터) + D(write-shuffle-files-to-S3 + salting) = 비용 효율 해결. 【오답 체크】 (A) 워커 수직 스케일은 스큐 자체 해결 안 함. (C) 수평 스케일도 스큐 그대로면 효과 약함. (E) CloudWatch 에러 로그는 스큐 진단 한계.

해설

【핵심 용어】 ▸ 자기 참조 SG 규칙 — 같은 SG가 붙은 리소스끼리 모든 트래픽 허용. Glue → RDS(같은 SG)에 표준. 【정답 포인트】 ▸ '모든 TCP 포트 허용 + source = 같은 SG' = self-referencing rule. SSH 외에 추가 인바운드. 【오답 체크】 (B) UDP 포트는 잘못됨(RDS는 TCP). (C) DNS name source는 SG 규칙에 사용 X. (D) IP 주소로 source 지정은 동적 IP에서 깨짐.