정답 · 해설

해설

【핵심 용어】 ▸ Apache Parquet — 컬럼 단위 저장. 특정 컬럼만 select할 때 I/O·비용 최소. ▸ Athena 과금 — 스캔한 데이터 양 기준. 컬럼형이 결정적. 【정답 포인트】 ▸ 15컬럼 중 1~2개 컬럼만 자주 쿼리 = Parquet 변환이 가장 비용 효율. Glue ETL로 CSV → Parquet으로 데이터 레이크 적재. 【오답 체크】 (A) CSV 그대로면 매번 전체 행 스캔. (B) JSON은 행 기반 + 파싱 비용 — Parquet 대비 비효율. (C) Avro도 행 기반(레코드 단위) — 컬럼 선택 쿼리에 부적합.

해설

【핵심 용어】 ▸ AWS Lake Formation — S3 데이터 레이크의 카탈로그·세분화 접근 제어. ▸ Data Filter — 행/열 단위 정책. IAM role이나 LF principal에 매핑. 【정답 포인트】 ▸ B(Lake Formation 위치 등록) — Lake Formation이 S3 권한을 위임받아 관리. ▸ D(Fine-grained Access + 리전별 데이터 필터) — 부서별 IAM role에 리전 필터 적용 → 같은 리전 직원만 본인 리전 데이터 조회. 【오답 체크】 (A) 데이터 위치 등록은 LF에 위치를 등록하는 단계로 표현. 단독으론 행 필터 미적용. (C) IAM role에 직접 데이터 필터 추가는 LF 모델이 아님 — LF에서 부여해야 함. (E) 리전별 S3 버킷 분리는 데이터 분산 부담↑, 단일 데이터 레이크 패턴 위배.

해설

【핵심 용어】 ▸ EMR 잡 실패 = 권한(IAM/Glue/Step Functions) 또는 네트워크(SG/VPC) 둘 중 하나가 대부분. ▸ VPC Flow Logs — 트래픽 흐름 로그로 SG/라우팅 문제 진단. 【정답 포인트】 ▸ B(IAM 권한 + S3 액세스 분석) — Step Functions가 EMR 잡 실행/액세스에 필요한 권한 확보 확인. ▸ D(VPC Flow Logs + SG 검증) — EMR 클러스터가 데이터 소스에 도달 가능한지 네트워크 진단. 【오답 체크】 (A) 실패 시 일시정지 + 이메일 승인은 디버깅 워크플로지 원인 식별 액션 아님. (C) EMR on EKS 변경은 원인 분석이 아닌 아키텍처 교체. (E) 재시도/SNS 토픽은 사후 모니터링이지 원인 식별 단계가 아님.

해설

【핵심 용어】 ▸ EC2 Instance Store — 호스트에 직접 붙은 임시 디스크. 인스턴스 종료/재시작 시 데이터 소실. ▸ Amazon EBS — 네트워크 블록 스토리지. 인스턴스 종료해도 별도 분리 가능, 영속. 【정답 포인트】 ▸ Instance Store AMI여도 추가 EBS 볼륨을 붙여 데이터를 거기 저장하면 인스턴스 종료 후에도 보존 가능. 【오답 체크】 (A) Instance Store 단독은 데이터 소실 위험. (B) Root EBS에 모든 데이터 저장은 동작하지만 성능·관리상 권장 패턴 아님. (D) EBS root + Instance Store 데이터 = 데이터를 휘발성 매체에 두는 것이라 요구 위배.

해설

【핵심 용어】 ▸ Athena Spark Workgroup — Athena 안에서 Apache Spark 노트북·잡을 실행하는 워크그룹 타입. 【정답 포인트】 ▸ Athena에서 SQL 대신 Spark를 쓰려면 Spark용 workgroup을 생성. SQL workgroup과 별개. 【오답 체크】 (A) 쿼리 설정만으론 Spark 실행 못 함. (C) data source는 카탈로그 연결이지 엔진 선택 아님. (D) query editor는 SQL 인터페이스.

해설

【핵심 용어】 ▸ Glue create_partition API (Boto3) — 새 파티션을 카탈로그에 즉시 등록. 크롤러/MSCK 없이 가장 빠른 동기화. 【정답 포인트】 ▸ S3에 데이터 쓰는 코드가 같은 시점에 create_partition 호출 = 지연 0. 커밋과 동시에 카탈로그 반영. 【오답 체크】 (A) 일일 크롤러 = 최대 24시간 지연. (B) 수동 호출 2회 = 운영 부담 + 지연. (D) MSCK REPAIR는 일괄 스캔 — 파티션 수 많으면 느리고 주기적 실행 필요.

해설

【핵심 용어】 ▸ Amazon AppFlow — Salesforce·Slack·SAP 등 SaaS와 AWS 간 양방향 데이터 통합 관리형. 코드 없이 S3 적재 가능. 【정답 포인트】 ▸ SaaS 도구 데이터 → S3 + 최소 운영 = AppFlow가 정확한 매핑. 【오답 체크】 (A) MSK는 Kafka 운영용 — SaaS 통합 도구 아님. (C) Glue Data Catalog는 메타데이터 카탈로그 — 데이터 이동 자체 안 함. (D) Kinesis는 스트림 인입 — SaaS 커넥터 직접 미제공.

해설

【핵심 용어】 ▸ WHERE year = 2023 — 'year'가 실제 컬럼명일 때만 작동. 날짜 컬럼에서 연도를 추출해야 한다면 함수 필요. 【정답 포인트】 ▸ 일부 제품만 누락 = year 컬럼 자체가 없거나 잘못 매칭. 날짜 컬럼에서 extract(year FROM ...)으로 추출해 비교해야 정상 결과. 【오답 체크】 (A) sum → count는 의미가 다름. (C) HAVING > 0은 결과 제외만 추가, 누락 원인 해결과 무관. (D) GROUP BY 제거 = 집계 자체 깨짐.

해설

【핵심 용어】 ▸ S3 Select — 단일 객체에 SQL 쿼리 + 필요한 컬럼만 반환. 인프라 0, 일회성에 최적. 【정답 포인트】 ▸ Parquet + 단일 컬럼 + 일회성 = S3 Select가 가장 가벼움. Glue/Athena/Lambda 셋업 불필요. 【오답 체크】 (A) Lambda + pandas = 메모리 한계 + 코드 작성. (C) DataBrew는 GUI 데이터 정리 — 일회성 쿼리에 과도. (D) Glue 크롤러 + Athena = 인프라 셋업 필요.

해설

【핵심 용어】 ▸ Redshift Query Editor v2 — 콘솔 SQL 편집기. Materialized View 자동 새로고침 스케줄을 GUI에서 직접 설정. 【정답 포인트】 ▸ 별도 Airflow/Lambda/Glue 없이 Query Editor v2로 새로고침 스케줄 등록 = 최소 노력. 【오답 체크】 (A) Airflow 인프라 운영 부담. (B) Lambda UDF는 Redshift 함수 영역 — MV 새로고침 스케줄러가 아님. (D) Glue 워크플로 = 추가 서비스 운영.

해설

【핵심 용어】 ▸ AWS Step Functions — Lambda·Glue·EMR·SageMaker 등 AWS 서비스를 시각적 상태머신으로 묶는 관리형 오케스트레이션. 【정답 포인트】 ▸ Lambda + Glue 두 단계 = Step Functions 표준 사용 사례. 코드 거의 없이 정의·재시도·에러 처리 내장. 【오답 체크】 (B) EC2에 Airflow 직접 운영 = 서버 관리 부담. (C) Glue Workflow는 Glue 잡/크롤러 한정 — Lambda 통합 어색. (D) EKS Airflow는 가장 무거운 옵션.

해설

【핵심 용어】 ▸ AWS Glue Data Catalog — 모든 AWS 분석 서비스의 중앙 메타데이터 저장소. ▸ Glue Crawler — RDS·Redshift·S3 등 다중 소스에서 스키마 자동 감지·갱신, 변경 감지. 【정답 포인트】 ▸ 정형(RDS·Redshift) + 반정형(S3 JSON·XML) 모두 + 변경 자동 감지 + 정기 갱신 = Glue Data Catalog + 크롤러. 【오답 체크】 (A) Aurora를 카탈로그로 쓰는 건 비표준 + 직접 구현 부담. (C) DynamoDB도 비표준 — 메타데이터 카탈로그 표준 도구 아님. (D) 일부만 자동(S3) + RDS/Redshift는 수동 추출 = 운영 부담.

해설

【핵심 용어】 ▸ DynamoDB Application Auto Scaling — Scheduled Scaling으로 정기 시간대에 용량 조정. 예측 가능한 패턴에 비용 효율. 【정답 포인트】 ▸ 월요일 아침 급증 + 주말 저조 = 예측 가능 → 스케줄드 오토스케일링이 가장 비용 효율. 피크 시간만 용량↑. 【오답 체크】 (A) 항상 피크 용량 유지 = 비용 큰 낭비. (B) 테이블 분리는 의미 없는 복잡성. (D) On-Demand는 트래픽 매우 가변적일 때 유리하지만 예측 가능한 워크로드엔 Provisioned + 스케줄링이 더 저렴.

해설

【핵심 용어】 ▸ AWS Glue Data Catalog as External Hive Metastore — EMR/Athena/Redshift Spectrum 모두 공유 사용. 서버리스·관리 부담 0. 【정답 포인트】 ▸ 온프레 Hive metastore → EMR + Glue Data Catalog 외부 메타스토어 = 서버리스 + 비용 효율. 관리 인프라 없음. 【오답 체크】 (A) DMS는 트랜잭션 DB 마이그레이션 — Hive 메타스토어 이전 도구 아님. (C) Aurora MySQL 메타스토어는 서버리스 아님 + 관리 부담. (D) EMR 새 메타스토어는 EMR 클러스터 의존 — 서버리스가 아님.

해설

【핵심 용어】 ▸ Redshift Distribution Key — 데이터를 노드에 분산하는 기준. KEY 분산은 같은 키 값을 같은 노드에 묶음. ▸ 핫 노드 — 분산 키가 한쪽에 치우쳐 발생. 차원이 큰(카디널리티 높은) 컬럼으로 키 변경. 【정답 포인트】 ▸ 노드 1개에만 부하 집중 = 분포 불균형. 카디널리티 높은(가장 큰 차원) 컬럼으로 분산 키 변경하면 균등 분포. 【오답 체크】 (A) 정렬 키는 쿼리 성능이지 노드 분산과 무관. (C) 노드 업그레이드 = 노드 수 유지 요건 위반 + 비용. (D) Primary key는 Redshift에서 강제되지 않음 — 분산과 무관.

해설

【핵심 용어】 ▸ Glue Schema Registry — 스트리밍/IoT 데이터의 스키마 진화(추가·변경) 추적·검증. ▸ Glue Data Catalog — 메타데이터 저장. 【정답 포인트】 ▸ IoT 펌웨어 업그레이드로 스키마 변경 가능 + 비용 효율 = Glue Catalog + Schema Registry. Redshift Serverless로 분석 인입. 【오답 체크】 (B) Redshift Provisioned는 비용 부담. (C) Athena Spark는 가능하지만 스키마 진화 관리·인덱싱은 Schema Registry가 더 적합. (D) Lambda UDF + Step Functions = 직접 구현 부담.

해설

【핵심 용어】 ▸ CloudTrail Data Events — S3 객체 단위 PUT/GET 등 데이터 플레인 이벤트 기록. 다른 S3 버킷으로 직접 저장 가능. ▸ Management Events — 버킷 생성/삭제 같은 콘트롤 플레인. 객체 쓰기 추적엔 부적합. 【정답 포인트】 ▸ S3 객체 쓰기를 다른 버킷에 로그 = CloudTrail Data Events의 정확한 사용. write-only + 빈 prefix로 모든 객체. 【오답 체크】 (A) Lambda + Firehose = 추가 서비스, 운영 부담. (B) Management Events는 객체 단위 안 잡힘. (C) Lambda 직접 작성 = 코드 작성·유지 부담.

해설

【핵심 용어】 ▸ AWS Glue Data Catalog — Athena·EMR·Redshift Spectrum 공통 메타데이터 저장소. Hive 호환. 【정답 포인트】 ▸ EMR + Athena 공통 메타데이터 + Hive에서 import = Glue Data Catalog. 두 엔진이 동일한 카탈로그 즉시 공유. 【오답 체크】 (A) Apache Ranger는 권한 관리이지 메타데이터 저장소 아님. (B) EMR 자체 Hive metastore는 EMR 한정 — Athena와 직접 공유 안 됨. (D) RDS MySQL metastore는 직접 운영 부담 + Athena 통합 어색.

해설

【핵심 용어】 ▸ AWS Lake Formation — S3 데이터 레이크에 대한 행/열 단위 권한 + Athena·Spectrum·EMR 통합. 【정답 포인트】 ▸ 행/열 권한 + 다중 엔진(Athena·Spectrum·Hive on EMR) + 최소 운영 = Lake Formation의 정확한 사용 사례. 【오답 체크】 (A) S3 정책은 객체 단위 — 행/열 단위 불가. (B) Apache Ranger는 EMR 한정 + 직접 운영. (C) Redshift를 데이터 레이크 스토리지로 쓰는 건 데이터 레이크 모델이 아님.

해설

【핵심 용어】 ▸ Athena 성능 최적화 = 같은 리전 + 컬럼형(Parquet/ORC) 조합이 핵심. 【정답 포인트】 ▸ C(같은 리전 S3) — 데이터 전송 비용·지연 최소. ▸ E(Parquet 변환) — 컬럼 푸시다운 + 압축으로 스캔량 대폭 감소. 【오답 체크】 (A) 무작위 prefix는 처리량 분산 — 단일 쿼리 성능과 무관. (B) 같은 계정은 권한 단순화일 뿐 성능과 직접 무관. (D) JSON은 Parquet 대비 비효율.