정답 · 해설

해설

【핵심 용어】 ▸ Step Functions Standard Workflow — 최대 1년, 24시간 이상 실행 가능 + Wait for Callback 패턴 지원. 24시간 이내 SLA 충족. ▸ Express는 5분 한도. 【정답 포인트】 ▸ 24시간 워크플로 + Wait for Callback = Standard Workflow. 【오답 체크】 (B) Express는 5분 한도 — 24시간 SLA 불가. (C) Lambda 직접 오케스트레이션 = 직접 구현 부담. (D) MWAA는 클러스터 비용 부담.

해설

【핵심 용어】 ▸ Glue 잡은 ENI를 통해 VPC에 연결. 여러 잡 동시 실행 시 ENI 수만큼 IP 소모. 서브넷 IP 부족하면 잡 실패. 【정답 포인트】 ▸ 'subnet does not have enough free addresses' = 서브넷 IP 부족. 더 큰 서브넷 또는 여러 서브넷 사용. 【오답 체크】 (B) 워커 타입은 서브넷 접근과 무관. (C) IAM은 IP 추가 권한이 아님. (D) VPC 전체는 보통 충분 — 특정 서브넷의 한계.

해설

【핵심 용어】 ▸ EMR Cluster Mode + S3 로그 아카이빙 — 클러스터 종료 후에도 S3에 step 로그(stdout/stderr) 보존. 콘솔에서 직접 접근. 【정답 포인트】 ▸ Spark driver 표준 에러 로그는 EMR step 로그 → S3에 자동 아카이브 → EMR 콘솔에서 보기. 【오답 체크】 (A) ResourceManager 로그는 YARN 단위 — Spark driver 에러 직접은 step 로그. (B) 영구 UI도 가능하지만 콘솔 + S3 로그가 더 직접적. (D) SSH는 라이브 클러스터 한정.

해설

【핵심 용어】 ▸ Glue Workflow — 여러 잡을 병렬·순차 실행, 의존성 정의. 별도 인프라 0. 【정답 포인트】 ▸ 두 잡 병렬 + 세 번째 잡은 둘 끝난 후 = Glue Workflow의 표준 패턴. 최소 운영. 【오답 체크】 (A) MWAA는 클러스터 비용. (B) EMR + SQS + Lambda = 인프라 + 코드 부담. (D) Step Functions + Lambda = 가능하나 Glue 잡 직접 통합엔 Workflow가 더 가벼움.

해설

【핵심 용어】 ▸ KDS Cross-Account Access — 데이터 스트림 측에 리소스 기반 정책으로 다른 계정 IAM principal 허용. 【정답 포인트】 ▸ Account A의 KDS에 Account B Lambda role 허용 = KDS 리소스 기반 정책. 【오답 체크】 (A)(C) SCP는 권한 가드레일이지 권한 부여 도구 아님. (D) Lambda에 리소스 정책 추가는 KDS 호출 권한과 방향이 반대.

해설

【핵심 용어】 ▸ Athena Partition Projection — 파티션 메타데이터를 패턴(year/month/day)으로 자동 계산. 매일 새 파티션 생성 작업 0. 【정답 포인트】 ▸ 일·월·년 파티션 + 매일 자동 + 스키마 변경 적응 = Partition Projection. 별도 잡·Lambda 불필요. 【오답 체크】 (A) DataBrew는 파티션 생성 도구 아님. (B) Lambda 직접 생성은 코드·운영 부담. (D) 크롤러 일일 실행도 가능하지만 Partition Projection이 더 가벼움.

해설

【핵심 용어】 ▸ Kinesis Agent → Firehose → S3 (Versioning) — 관리형 스트림 적재 + 의도치 않은 삭제 방지. 【정답 포인트】 ▸ 온프레 → AWS 자동 인입 + 실수 삭제 방지 + Athena 분석 = Firehose + S3 Versioning. 【오답 체크】 (A) DataSync + EFS는 Athena 분석에 부적합 + AWS Backup 추가 단계. (C) Glue → RDS는 Athena 시나리오와 다름. (D) MSK 자체 관리 부담.

해설

【핵심 용어】 ▸ Apache Parquet / Apache ORC — 컬럼형, 압축, predicate pushdown 지원. Athena 분석 쿼리 최적. ▸ Glue Data Catalog — 스키마 변경 추적의 표준. 【정답 포인트】 ▸ B(ORC + Glue Catalog) + D(Parquet + Glue Catalog) = 두 컬럼형 모두 짧은 쿼리 시간 보장. 【오답 체크】 (A) Avro는 행 기반. (C) DynamoDB로 스키마 추적은 비표준. (E) S3 별도 스키마 파일은 운영 복잡.

해설

【핵심 용어】 ▸ S3 prefix 파티셔닝 + Glue Catalog — 일별 파티션으로 Athena가 시간 범위 쿼리 시 해당 파티션만 스캔. 【정답 포인트】 ▸ 시간 범위 쿼리 + 비용 효율 = SALE_DATE 파티션. 변환 없이 즉시 비용 절감. 【오답 체크】 (A) JSON 변환은 컬럼형이 아님 + 추가 ETL. (C) EMR은 인프라 부담. (D) RDS는 Athena 시나리오와 다른 분석 모델.

해설

【핵심 용어】 ▸ Glue Crawler + JDBC 드라이버 — Redshift 테이블 메타데이터(컬럼·타입·통계) 카탈로그에 일일 갱신. 【정답 포인트】 ▸ Redshift 스키마 변화 추적 + 카탈로그 = JDBC 크롤러 일일 실행. 【오답 체크】 (B) DataSync는 데이터 동기화 — 메타데이터 카탈로그 도구 아님. (C) SCT는 마이그레이션용. (D) Hive 메타스토어는 Redshift와 직접 통합 어색.

해설

【핵심 용어】 ▸ Glue Detect PII (Specific Patterns) — 회사 정의 PII 패턴(독자 형식)을 정규식·컨텍스트로 탐지. 변환 단계에서 즉시 마스킹. 【정답 포인트】 ▸ 독자 PII 형식 + 최소 운영 = Glue Detect PII '특정 패턴' 모드. 【오답 체크】 (B) Macie 관리형 식별자는 표준 PII만. (C) Lambda 정규식 직접 = 코드 부담. (D) Athena SQL 매칭은 직접 쿼리 작성·유지 부담.

해설

【핵심 용어】 ▸ DynamoDB TTL — 항목별 만료 타임스탬프 자동 삭제. 추가 인프라 0. 【정답 포인트】 ▸ 일일 자동 삭제 + 최소 설정 = TTL 활성화 + 코드에서 만료 시간 부여. 【오답 체크】 (B) EventBridge cron + Lambda 삭제는 RCU/WCU 소비 + 운영. (C) DynamoDB 라이프사이클 같은 옵션은 없음. (D) Streams는 변경 트리거 — 만료 자동 삭제 도구 아님.

해설

【핵심 용어】 ▸ DynamoDB GSI (Global Secondary Index) — 테이블의 다른 키로 인덱스 생성. DriverID PK + RideStatus SK로 드라이버별 상태 쿼리. 【정답 포인트】 ▸ 드라이버별 라이드 + 상태 필터 + 스캔 X = GSI(DriverID, RideStatus). 【오답 체크】 (A) LSI는 같은 PK + 다른 SK — DriverID가 PK인 인덱스 필요. (B) RiderID 인덱스는 시나리오와 다름. (D) Filter 표현은 스캔 후 필터 — 비효율.

해설

【핵심 용어】 ▸ Lambda Memory ↑ — CPU·네트워크도 비례 증가. 128MB → 512MB 시 CPU 약 4배. 【정답 포인트】 ▸ CPU 100% + 메모리 부족 → 메모리 증가가 CPU·전체 성능 향상. 【오답 체크】 (B) 재시도는 실패 처리. (C) VPC 설정은 네트워크 — 컴퓨팅 영향 X. (D) 타임아웃 늘리기는 시간만 늘림 — 처리 속도 향상 없음.

해설

【핵심 용어】 ▸ Glue Auto Scaling — 워크로드에 따라 워커 수 자동 조정. 트래픽 급증 시 디스크 스페이스 부족 완화. 【정답 포인트】 ▸ 트래픽 급증 + 디스크 부족 + 최소 운영 = Auto Scaling 활성화. 【오답 체크】 (A) DPU 고정 증가는 비용 늘리지만 가변 트래픽엔 비효율. (B) EMR로 교체는 큰 변경. (C) Step Functions는 오케스트레이션 — 셔플/디스크 문제 직접 해결 X.

해설

【핵심 용어】 ▸ Redshift KEY 분산 + 고카디널리티 조인 컬럼 = 노드 간 셔플 최소. ▸ Redshift Advisor — 자동 권고(분산·정렬·인코딩) 제공. 【정답 포인트】 ▸ B(고카디널리티 KEY 분산) + E(Advisor 권고) = 큰 두 테이블 조인 성능 향상의 표준 + 자동화 도움. 【오답 체크】 (A) 저카디널리티 KEY는 데이터 스큐. (C) 큰 테이블에 ALL은 디스크 폭증. (D) 옵티마이저가 제안 X — Advisor가 정답.

해설

【핵심 용어】 ▸ Glue Catalog Iceberg 자동 최적화 — 컬럼 통계(스타티스틱스) 자동 생성 + 자동 컴팩션. 쿼리 옵티마이저 더 좋은 계획 + 작은 파일 병합으로 스캔 감소. 【정답 포인트】 ▸ A(컬럼 통계 자동 생성) + B(자동 컴팩션) = Iceberg 쿼리 성능 향상의 표준. 【오답 체크】 (C) 인덱스 자동 최적화는 Glue Catalog 기능 아님. (D) Copy-on-write는 쓰기 패턴이지 쿼리 성능 옵션 아님. (E) 뷰 생성은 쿼리 단순화일 뿐.

해설

【핵심 용어】 ▸ Glue + Glue Workflows — 모두 서버리스. Spark 잡 + 오케스트레이션 통합. 【정답 포인트】 ▸ 서버리스 + Spark + 오케스트레이션 + 최소 수동 = Glue + Workflows. EMR/MWAA 운영 부담 제거. 【오답 체크】 (B) Step Functions + EMR은 EMR 클러스터 운영. (C) Lambda S3 트리거는 Spark 처리에 한계. (D) MWAA는 클러스터 비용.

해설

【핵심 용어】 ▸ AWS STS Session Policy — AssumeRole 시점에 추가 적용되는 임시 정책. 같은 IAM role을 여러 리전에 재사용 + 리전 제한. 【정답 포인트】 ▸ 리전마다 별도 role 안 만들고 + 세션 정책으로 리전 한정 = 운영 최소. 【오답 체크】 (B) 리전마다 role 분리는 관리 복잡. (C) 리전마다 IAM 그룹은 사용자 분류 부담. (D) 사용자별 정책 분리는 확장성 부족.

해설

【핵심 용어】 ▸ Redshift Dynamic Data Masking (DDM) — 컬럼에 마스킹 정책 부착. 사용자 role에 따라 평문/마스킹 자동 분기. 【정답 포인트】 ▸ 적재 후 Redshift에서 동적 마스킹 = role별 평문/마스킹 자동 분기. 별도 ETL 단계 없음. 【오답 체크】 (A) Macie는 탐지지만 마스킹 변환 아님. (B) Macie + Glue 변환 = 추가 ETL 단계. (C) Glue 변환 직접 = 코드 부담.