정답 · 해설

해설

【핵심 용어】 ▸ Glue Studio Detect PII — PII 자동 감지/마스킹/제거 변환. 시각적 ETL. ▸ Step Functions — 멀티 단계 ETL 오케스트레이션. 【정답 포인트】 ▸ Glue Studio Detect PII로 식별 + 변환에서 직접 난독화 + Step Functions로 파이프라인 = 가장 적은 노력. 【오답 체크】 (A) Lambda 변환은 직접 코드 작성 + SDK 호출 → 노력 큼. (C) Data Quality는 데이터 품질 룰 검증이지 PII 난독화 변환 도구가 아님. (D) DynamoDB 적재 → Lambda 변환은 데이터 흐름과 어긋남.

해설

【핵심 용어】 ▸ Step Functions — 다양한 AWS 서비스를 상태 머신으로 묶는 표준 오케스트레이션. 시각적 흐름·재시도·에러 처리 내장. 【정답 포인트】 ▸ Glue + EMR 등 이종 서비스 조합 자동화 + 최소 운영 = Step Functions. 코드 거의 없이 시각적 흐름 정의. 【오답 체크】 (A) Glue Workflows는 Glue 잡/크롤러 한정. EMR과 결합 어려움. (C) Lambda 함수로 직접 오케스트레이션 = 코드·에러 처리 직접 구현. (D) MWAA는 강력하지만 클러스터 비용·운영 부담 큼.

해설

【핵심 용어】 ▸ S3 Standard-IA — 다중 AZ 고가용성 + 접근 빈도 낮을 때 비용 절감. 1회 검색 비용 발생. ▸ S3 One Zone-IA — 단일 AZ로 비용 더 낮지만 가용성 떨어짐. ▸ Glacier Deep Archive — 가장 저렴(연 1~2회 접근), 검색에 시간 걸림. 【정답 포인트】 ▸ '고가용성 유지' 조건 → One Zone-IA 제외 → Standard-IA. 2년 후 거의 안 봄 → Deep Archive(가장 저렴). 【오답 체크】 (A)(D) One Zone-IA는 가용성 요구를 못 맞춤. (B) Glacier Flexible Retrieval은 Deep Archive보다 비쌈. 거의 안 보는 데이터엔 Deep Archive가 더 비용 효율.

해설

【핵심 용어】 ▸ Redshift Data Sharing — 클러스터 간 라이브 데이터 공유. 소비자 쿼리 시 생산자 컴퓨팅 자원 소비 없음(별도 컴퓨팅 분리). 【정답 포인트】 ▸ ETL 클러스터에 부하 주지 않고 BI 클러스터가 데이터 조회 = Redshift Data Sharing이 정확한 매핑. 【오답 체크】 (B)(C) 직접 접근/Materialized View는 ETL 클러스터 컴퓨팅 사용 → 운영 영향. (D) S3 Unload + Spectrum은 데이터 복제·신선도·관리 부담 발생. 라이브 공유 아님.

해설

【핵심 용어】 ▸ Athena Federated Query — DynamoDB·RDS·Redshift 등 여러 소스에 직접 SQL 쿼리. 데이터 이동 불필요. ▸ 일회성 분석에 가장 비용 효율. 【정답 포인트】 ▸ 일회성 + 다중 소스 + 비용 최소 = Federated Query. 인프라/복제 없이 즉시 실행. 【오답 체크】 (A) EMR 클러스터는 일회성에 과한 비용. (B) S3로 사전 복사는 데이터 파이프라인 구축 비용 발생. (D) Redshift Spectrum은 S3 외부 테이블만 쿼리 가능. DynamoDB·RDS는 직접 안 됨.

해설

【핵심 용어】 ▸ EMR + S3 (EMRFS) — HDFS 대신 S3를 영속 스토리지로. 클러스터 종료/재시작에도 데이터 유지. ▸ Graviton(ARM) 인스턴스 — x86 대비 비용·전력 효율 우수, EMR 지원. 【정답 포인트】 ▸ B(S3 영속 스토리지) — 신뢰성·비용 모두 향상. ▸ D(Graviton 노드) — 같은 성능에 비용↓. 【오답 체크】 (A) HDFS는 클러스터 종료 시 데이터 소실 위험. (C) x86 대비 Graviton이 더 저렴. (E) Primary 노드를 Spot으로 운영하면 클러스터 안정성 손상.

해설

【핵심 용어】 ▸ Redshift 외부 스키마 + Streaming Ingestion — Kinesis Data Streams 데이터를 Materialized View로 자동 적재. ▸ Auto Refresh — 새 레코드를 즉시 반영해 BI 도구가 거의 실시간으로 조회 가능. 【정답 포인트】 ▸ 외부 스키마 매핑 + auto-refresh MV = 가장 적은 단계로 GB/s 수준 스트림을 Redshift에 노출. 기존 BI 도구가 그대로 쿼리. 【오답 체크】 (A) S3 스테이징 + COPY = 배치 지연 발생. (B) 'Kinesis에 SQL 직접 쿼리'는 Redshift 기능이 아님. (D) Firehose 경유 + COPY = 추가 지연·운영 부담.

해설

【핵심 용어】 ▸ S3 파티셔닝 — 연/월/일 디렉토리 구조로 Glue 잡이 처리 범위를 좁힘. 스캔량·비용·시간 모두 절감. ▸ Glue Worker Type — G.1X·G.2X 등으로 메모리·CPU 늘려 처리 속도 향상. 【정답 포인트】 ▸ A(파티셔닝) — 신규 데이터만 처리하면 잡 시간 급감. ▸ B(워커 스케일업) — 파티셔닝과 함께 쓰면 처리 속도 추가 향상. 【오답 체크】 (C) DynamicFrame ↔ DataFrame 전환은 성능 향상 보장 X. (D) 실행 빈도 줄이면 한 번에 더 많은 데이터를 처리 → 더 느려짐. (E) S3FullAccess 권한 확장은 성능과 무관.

해설

【핵심 용어】 ▸ Step Functions Map state — 컬렉션의 각 항목에 대해 동일한 처리를 병렬로 수행. ▸ Parallel state — 정해진 N개 분기를 병렬 실행(컬렉션 반복 아님). 【정답 포인트】 ▸ '대량 파일 컬렉션을 동일 변환' = Map state. Distributed Map으로 수만~수십만 항목까지 확장 가능. 【오답 체크】 (A) Parallel은 분기 수가 정적. 동적 컬렉션엔 Map이 적합. (B) Choice는 조건 분기. (D) Wait는 시간 대기.

해설

【핵심 용어】 ▸ AWS Glue FindMatches — ML 기반 fuzzy 중복 식별 변환. 같은 사람·제품의 표기 차이까지 매칭. 【정답 포인트】 ▸ 레거시 데이터의 중복(유사 표기 포함) 제거 + 최소 노력 = FindMatches. Glue Studio에서 변환 추가 + 학습 데이터 약간으로 끝. 【오답 체크】 (A) Pandas drop_duplicates는 정확 일치만 제거. 노이즈 있는 중복엔 한계. (C) dedupe 라이브러리 직접 도입 + 코드 작성 = 운영 부담↑. (D) Glue 잡에서 dedupe import도 가능하지만 ML 학습/관리 직접 부담.

해설

【핵심 용어】 ▸ Columnar 포맷(Parquet/ORC) — 컬럼 단위 읽기 + 압축 → Spectrum 스캔량 대폭 감소. ▸ 파티셔닝 — 자주 쓰는 WHERE 컬럼 기준 디렉토리 분리 → 파티션 프루닝. 【정답 포인트】 ▸ B(컬럼형) + C(쿼리 술어 기반 파티션) = Spectrum 가장 빠른 조합. 【오답 체크】 (A) 1~5GB gzip은 압축 가능하지만 파일이 너무 크면 병렬도 떨어짐. 컬럼형이 더 효과적. (D) 10KB 미만 작은 파일 = 메타데이터/오버헤드 폭증, 오히려 느림. (E) splittable 하지 않은 포맷은 병렬 처리 불가 → 느림.

해설

【핵심 용어】 ▸ Lambda VPC 구성 — 같은 서브넷·SG에 두면 RDS와 프라이빗 통신 가능. ▸ 자기 참조 SG 규칙 — 같은 SG가 붙은 리소스끼리만 트래픽 허용. 【정답 포인트】 ▸ C(같은 서브넷) + D(같은 SG + 자기 참조 규칙) = 인터넷 노출 없이 Lambda↔RDS 프라이빗 연결 + 최소 운영. 【오답 체크】 (A) DB의 퍼블릭 액세스 ON = 보안 정책 위반. (B) Lambda 호출만 허용은 SG 소스가 'Lambda'라는 직접 식별자가 아니라 어색. (E) NACL 자기 참조 = NACL은 stateless · self-reference 개념 부적합. SG 자기 참조가 정석.

해설

【핵심 용어】 ▸ Lambda + API Gateway — REST API 백엔드의 표준 서버리스 조합. ▸ Provisioned Concurrency — 콜드 스타트 제거를 위한 초기화 워밍. 【정답 포인트】 ▸ '간헐적 호출 + API Gateway 통합 + 최소 운영' = Lambda. Provisioned Concurrency로 콜드 스타트 영향 줄임. 【오답 체크】 (A)(C) ECS·EKS는 클러스터 운영 부담. (D) 5분마다 mock 이벤트로 워밍 = 비용·관리 모두 비효율(Provisioned Concurrency가 정석).

해설

【핵심 용어】 ▸ CloudWatch Logs Subscription Filter — 로그 그룹 → 다른 계정 Kinesis Data Streams로 실시간 전달. ▸ Trust Policy — 다른 계정의 CloudWatch Logs가 이 계정 KDS에 put할 수 있게 허용. 【정답 포인트】 ▸ D — 보안 계정에 KDS 생성 + KDS에 put 권한을 CloudWatch Logs에 trust policy로 부여 + 프로덕션 계정에 subscription filter 생성. 정석 패턴. 【오답 체크】 (A) 프로덕션에 KDS를 두면 보안 격리 의미가 떨어짐. (B) Subscription filter는 로그가 발생하는 계정(프로덕션)에 만들어야 함. (C) IAM role 방향이 반대.

해설

【핵심 용어】 ▸ 오픈 테이블 포맷(Apache Iceberg / Hudi / Delta) — S3 기반 데이터 레이크에서 ACID·UPSERT·MERGE 지원. 일일 스냅샷과 기존 데이터를 효율적으로 병합. 【정답 포인트】 ▸ JSON 일일 스냅샷 + S3 데이터 레이크에 변경분만 반영 = 오픈 테이블 포맷의 MERGE INTO가 가장 비용 효율. 【오답 체크】 (A) Lambda로 직접 비교 = 큰 파일 처리 한계, 일관성 보장 어려움. (B)(D) RDS/Aurora 경유 + DMS는 트랜잭션 DB가 굳이 필요 없는 시나리오에 과한 인프라.

해설

【핵심 용어】 ▸ Glue Partition Index — 카탈로그에 파티션 인덱스를 만들어 GetPartitions 응답 속도 향상. ▸ Athena Partition Projection — 파티션을 GetPartitions 호출 없이 패턴으로 계산 → 메타데이터 호출 자체 제거. 【정답 포인트】 ▸ A(파티션 인덱스 + 파티션 필터링) + C(Athena Partition Projection) = 파티션이 많을 때 쿼리 플래닝 시간 단축의 정석 두 가지. 【오답 체크】 (B) 버킷팅은 데이터 분포 최적화이지 파티션 플래닝 시간 단축은 아님. (D) Parquet 변환은 스캔 시간 단축이지 플래닝 단계 개선은 제한적. (E) 작은 파일 합치기는 스캔 효율, 플래닝 시간과 직결되지 않음.

해설

【핵심 용어】 ▸ Amazon Managed Service for Apache Flink — 윈도/이벤트 시간/체크포인트 기반 fault-tolerant 스트림 처리. 30분 윈도 집계의 표준. 【정답 포인트】 ▸ '30분 윈도 + 다양한 집계 + 고내결함성 + 최소 운영' = Managed Flink. 자동 체크포인트·재시작·확장. 【오답 체크】 (A) Lambda는 상태 유지·체크포인트 없음 — 30분 윈도 부적합. (C) Lambda + 텀블링 윈도도 직접 구현은 부담 + 내결함성 약함. (B) 표현이 부정확하지만 D가 더 정확한 매핑.

해설

【핵심 용어】 ▸ EBS Elastic Volumes — 볼륨 타입/크기/IOPS/처리량 변경을 무중단으로 수행. gp2 → gp3도 ModifyVolume 한 번. 【정답 포인트】 ▸ 다운타임·데이터 손실 없이 gp2 → gp3 = 직접 ModifyVolume. 새 볼륨·스냅샷 불필요. 【오답 체크】 (A) 스냅샷 → 새 볼륨 = 다운타임 발생. (B) 데이터 점진 전송 = 직접 작업 부담. (D) DataSync는 파일 전송용. EBS 타입 변경의 표준 도구가 아님.

해설

【핵심 용어】 ▸ AWS Glue + JDBC + 뷰 — SQL Server에 대해 Glue가 직접 JDBC 연결로 뷰를 읽어 Parquet으로 S3에 쓰는 정석. 【정답 포인트】 ▸ 뷰가 조인 결과를 캡슐화 → Glue 잡이 select * + Parquet 변환 + S3 출력 + 일일 스케줄 = 가장 효율적. 추가 변환·중간 파일 없음. 【오답 체크】 (B) CSV → Lambda Parquet 변환은 단계 많고 큰 데이터에 한계. (C) 크롤러로 SQL Server 뷰 카탈로깅은 직접 쿼리하는 Glue 잡 대비 단계 추가. (D) Lambda JDBC + 직접 Parquet 작성 = 메모리·시간 한계.

해설

【핵심 용어】 ▸ STL_ALERT_EVENT_LOG — Redshift 쿼리 옵티마이저가 잠재적 성능 이슈(누락 통계·과도한 ghost rows·중첩 루프 등)를 감지하면 기록하는 시스템 테이블. 【정답 포인트】 ▸ '옵티마이저가 성능 이상을 감지' = STL_ALERT_EVENT_LOG. 운영 보고서 튜닝의 첫 출발점. 【오답 체크】 (A) STL_USAGE_CONTROL은 동시성 제어 통계. (C) STL_QUERY_METRICS는 쿼리별 리소스 사용량 메트릭. (D) STL_PLAN_INFO는 실행 계획 단계 정보 — 알림이 아님.