정답 · 해설

해설

【핵심 용어】 ▸ RDS Performance Insights — 쿼리·세션·대기 이벤트 시각화. CPU 핫스팟 쿼리 식별. 【정답 포인트】 ▸ A(Performance Insights로 문제 쿼리 식별·튜닝) — 근본 해결. ▸ D(인스턴스 사이즈 업그레이드) — 즉시 CPU 여유 확보. 【오답 체크】 (B) 인덱스/테이블 추가는 일반적 권고지만 CPU 직접 해결 보장 X. (C) 주간 재부팅은 임시방편이지 해결책 아님. (E) 캐싱은 읽기 위주에 효과 — 시나리오는 쓰기 위주라 효과 제한.

해설

【핵심 용어】 ▸ VACUUM REINDEX — 인터리브드 정렬 키의 인덱스를 재구성 + 디스크 회수 + 정렬 효율 회복. 【정답 포인트】 ▸ 인터리브드 정렬 키 + 디스크 회수 + 분석 = VACUUM REINDEX. 인터리브드 키 전용 옵션. 【오답 체크】 (A) FULL은 일반 vacuum — 인터리브드 키엔 REINDEX가 정확. (B) DELETE ONLY는 디스크 회수만 — 정렬 인덱스 재구성 안 함. (D) SORT ONLY는 정렬만 — 디스크 회수 없음.

해설

【핵심 용어】 ▸ Kinesis Data Streams + DynamoDB — 스트리밍 인입 + 단일 자릿수 ms 응답 NoSQL. 중첩 JSON 자연 저장. 【정답 포인트】 ▸ near-real-time 인입 + <10ms 쿼리 + 중첩 JSON + 최소 운영 = KDS → DynamoDB. 둘 다 관리형. 【오답 체크】 (A) Self-hosted Kafka는 운영 부담 큼 + S3 쿼리는 ms 단위 어려움. (B) S3는 ms 쿼리 부적합. (D) SQS + Glue + RDS = 관리·지연 모두 늘어남.

해설

【핵심 용어】 ▸ Athena + Lake Formation Data Filters — 행/열 단위 PII 마스킹·필터를 IAM role에 매핑. 【정답 포인트】 ▸ PII 컬럼별로 그룹별 접근 차등 + 최소 노력 = Lake Formation 데이터 필터. 한 곳에서 정책 관리, Athena 쿼리에 자동 적용. 【오답 체크】 (B) QuickSight 컬럼 보안은 BI 도구 한정 — 다른 분석 경로엔 적용 안 됨. (C) 커스텀 UI는 직접 개발 부담. (D) IAM 컬럼 단위 정책 = 운영 복잡 + 행 단위 어려움.

해설

【핵심 용어】 ▸ Glue Workflow (Crawler → Job) — 파일이 들어오면 크롤러로 스키마 변경 감지 → 잡으로 Redshift 적재. ▸ EventBridge 스케줄 또는 Lambda(S3 이벤트) — 워크플로 트리거. 【정답 포인트】 ▸ B(EventBridge 15분마다 → Glue Workflow) — 시간 기반. ▸ D(Lambda S3 이벤트 → Glue Workflow) — 파일 도착 즉시. 둘 다 스키마 변경 자동 처리(크롤러) + 적재(잡). 【오답 체크】 (A) Glue 잡 단독은 스키마 변경 자동 감지 부족. (C) Lambda → Crawler → 또 Lambda → Job = 체인 복잡, 워크플로가 더 깔끔. (E) Spark → Firehose → Redshift = 흐름 부자연스러움.

해설

【핵심 용어】 ▸ Athena Query Result Reuse — 동일 쿼리 결과를 캐시. 데이터가 변하지 않은 동안 재사용해 비용·시간 절약. 【정답 포인트】 ▸ 일 1회 데이터 갱신 + 1시간 BI 새로고침 = 결과 재사용 캐시 매우 효과적. 인프라 추가 0. 【오답 체크】 (A) Glacier 이동 = 쿼리 자체 불가능. (C) ElastiCache는 추가 인프라 + Athena와 직접 통합 어려움. (D) Parquet 변환은 기존 데이터 다시 처리 — 추가 ETL 비용 + Glue 잡 작업 필요.

해설

【핵심 용어】 ▸ Redshift ALL distribution — 작은 차원 테이블을 모든 노드에 복제 → 조인 시 노드 간 셔플 없음. ▸ EVEN — 라운드로빈 분산. 【정답 포인트】 ▸ 작고 자주 안 바뀌는 테이블에 ALL 분산 → 조인 셔플 제거 → 큰 테이블과의 조인 성능 향상. 【오답 체크】 (A) EVEN 유지는 현재 문제 그대로. (B) 큰 테이블에 ALL = 모든 노드 복제 = 디스크 폭증. (D) 파티션 키는 Redshift 표준 분산 메커니즘이 아님.

해설

【핵심 용어】 ▸ Glue DataBrew NEST_TO_MAP — 여러 컬럼을 키-값 맵(JSON 객체)으로 묶는 변환. 코드 없음. 【정답 포인트】 ▸ 4개 컬럼을 단일 JSON-like 컬럼 = NEST_TO_MAP. GUI 변환만으로 끝. 【오답 체크】 (A) NEST_TO_ARRAY는 배열로 묶음 — 키 없는 형태로 요구와 다름. (C) PIVOT은 행 ↔ 열 회전. (D) Lambda + Python = 직접 코드 작성 부담.

해설

【핵심 용어】 ▸ SSE-KMS — KMS 키로 S3 암호화. KMS 키 정책 + IAM 정책으로 사용자 단위 접근 제어. 【정답 포인트】 ▸ AWS 관리형 키 인프라 + 특정 직원만 키 접근 = SSE-KMS + KMS 키 IAM 정책. 가장 적은 노력. 【오답 체크】 (A) CloudHSM은 강력하지만 클러스터 운영 부담. (B) SSE-C는 키 관리·전송을 클라이언트가 직접 — 운영 부담. (D) SSE-S3는 키가 AWS 자동 관리 — 사용자별 키 접근 제어 불가.

해설

【핵심 용어】 ▸ S3 Intelligent-Tiering — 접근 패턴 분석해 자동으로 Frequent/Infrequent/Archive Instant Access 계층 이동. ms 응답 유지. ▸ Default access tier — 별도 활성화 없이 ms 접근 보장. 【정답 포인트】 ▸ 접근 패턴 예측 불가 + ms 검색 + 최소 운영 = Intelligent-Tiering 기본. Lifecycle 정책 직접 관리 불필요. 【오답 체크】 (A) Storage Lens 메트릭 + 수동 라이프사이클 = 운영 부담. (B) Standard-IA + Glacier 정책 직접 관리 = 패턴 모르면 비효율. (C) Deep Archive Access는 ms 검색 요구 위반.

해설

【핵심 용어】 ▸ AWS Secrets Manager — DB 자격 증명 안전 저장 + 자동 회전. ▸ Glue Job IAM Role — Secrets Manager 시크릿 읽기 권한 부여. 【정답 포인트】 ▸ D(Secrets Manager 저장) + E(Glue role에 secret 접근 권한) = 표준 보안 패턴. 【오답 체크】 (A) Job Parameters는 평문 저장 가능 — 보안 위험. (B)(C) S3 설정 파일은 평문/관리 부담 + 키 관리 어려움.

해설

【핵심 용어】 ▸ Amazon Redshift Serverless — 클러스터 프로비저닝/삭제 없이 워크그룹·쿼리 단위 자동 확장. 사용한 만큼만 과금. 【정답 포인트】 ▸ 월 1회 분석 + 인프라 자동 관리 = Serverless. 클러스터 생성/삭제·언로드 자체가 불필요해짐. 【오답 체크】 (A) Step Functions 일시정지/재개 = 클러스터 라이프사이클 직접 관리. (C) AWS CLI = 자동화 스크립트 직접 운영. (D) CloudFormation도 인프라 정의·실행은 직접 — Serverless가 더 간단.

해설

【핵심 용어】 ▸ Glue DataBrew COUNT_DISTINCT — GUI 레시피로 고유값 개수 계산. 코드 0. 【정답 포인트】 ▸ 1회성 distinct count + 최소 노력 = DataBrew 레시피. .xls 직접 가져오기 가능. 【오답 체크】 (A)(C) Spark 잡은 직접 코드 작성. (B) 크롤러 + Athena = 인프라 셋업 + 쿼리 작성.

해설

【핵심 용어】 ▸ Redshift Streaming Ingestion — Kinesis Data Streams/MSK 스트림을 Redshift에 직접 Materialized View로 인입. Firehose나 S3 stagging 불필요. 【정답 포인트】 ▸ KDS → Redshift Serverless + near real-time + 최소 운영 = Streaming Ingestion. 어제 데이터(이미 적재됨) + 신규 스트림 모두 같은 Redshift에서 분석. 【오답 체크】 (A) Firehose는 버퍼링 지연 발생. (C) S3 → COPY = 배치 지연 큼. (D) Aurora zero-ETL은 Aurora ↔ Redshift 통합이지 Kinesis 스트림과 무관.

해설

【핵심 용어】 ▸ QuickSight 권한 = (1) 데이터 소스 권한(S3, Athena 등) + (2) 암호화 키 복호화 권한. 【정답 포인트】 ▸ C(S3 접근 권한 누락) — Athena 쿼리 결과/원본 데이터 접근 불가. ▸ D(KMS 복호화 권한 누락) — 암호화된 객체 읽기 실패. 【오답 체크】 (A) QuickSight ↔ Athena 연결 부재라면 더 일반적 에러. (B) 카탈로그 누락은 쿼리 단계 에러이지 권한 에러 아님. (E) IAM role 미할당이라면 다른 형태 에러.

해설

【핵심 용어】 ▸ Amazon Athena Federated Query + PartiQL — 다양한 소스 통합 SQL. JSON 등 반정형엔 PartiQL. 【정답 포인트】 ▸ S3(JSON·CSV) + RDS + DynamoDB + Redshift 모두 + 최소 운영 = Glue 카탈로그 + Athena. 정형은 SQL, 반정형 JSON은 PartiQL. 【오답 체크】 (B) Redshift Spectrum은 다양한 소스 페더레이션이 약함. (C) Glue로 JSON → Parquet 변환 = 추가 ETL 부담. (D) Lake Formation 변환은 데이터 복제 부담.

해설

【핵심 용어】 ▸ SageMaker Studio + Glue Interactive Sessions — Studio 노트북에서 Glue 세션 사용. SageMaker가 Glue role을 assume. 【정답 포인트】 ▸ sts:AssumeRole + Glue/SageMaker 서비스 principal에 대한 trust = 두 서비스 사이의 위임 패턴. Access Denied 해결의 정석. 【오답 체크】 (A) AWSGlueServiceRole만으론 SageMaker 통합 부족. (C) SageMakerFullAccess만으론 Glue 세션 위임 부족. (D) sts:AddAssociation은 표준 액션이 아님.

해설

【핵심 용어】 ▸ AWS Glue (managed Spark) — 스키마 자동 감지(Crawler) + ETL(Spark) 관리형. 15분 SLA 충족. 【정답 포인트】 ▸ 다양한 소스(SAP HANA·SQL Server·MongoDB·Kafka·DynamoDB) + 스키마 변경 + 15분 SLA + 최소 운영 = Glue. 다중 커넥터 + 자동 스케일. 【오답 체크】 (A) EMR도 가능하지만 클러스터 운영 부담. (C) Lambda는 1TB·15분 SLA 달성 어려움. (D) Redshift 저장 프로시저는 ETL 엔진이 아님.

해설

【핵심 용어】 ▸ S3 Object Lambda — S3 GET 요청 경로에 Lambda를 끼워 응답을 동적으로 변환. PII 마스킹·요약 등. 【정답 포인트】 ▸ 같은 데이터셋, 앱별 다른 마스킹 = Object Lambda. 데이터 복제 0, 한 곳에서 redaction 로직 관리. 【오답 체크】 (A) 복사본 여러 개 = 저장·동기화 부담. (C) Glue 변환 + 복사본 = 같은 문제. (D) API Gateway 직접 구축 = 운영 부담.

해설

【핵심 용어】 ▸ Glue Python Shell Job — 작은 데이터(<수 GB)에 가벼운 pandas 처리. Spark 클러스터 비용 없이 DPU 1/16개로 실행 가능 → 매우 저렴. 【정답 포인트】 ▸ 100MB 미만 일일 CSV + 비용 효율 = Python shell + pandas. Spark/EMR 오버헤드 불필요. 【오답 체크】 (A) EKS 운영 부담 큼. (B) EMR도 작은 파일엔 과한 비용. (C) Glue PySpark도 Spark 오버헤드 — 작은 파일엔 Python shell이 더 효율.