AWS DEA-C01 각색 문제 Day 12 — Lake Formation, Athena Parquet, Lambda KMS, SageMaker, Step Functions + Glue ETL

AWS DEA-C01 문제로 공부하기 — Day 12

Lake Formation 셀수준 접근 제어, Athena Parquet+캠페인 파티션(복수), Lambda KMS 키 정책 오류, SageMaker Data Wrangler, Step Functions + Glue ETL — 5문제 핵심 정리.

AWS DEA-C01 Domain 2·4 · 보안·성능·ML·오케스트레이션 5문제

📋 목차

• Q56 대학 데이터 — 열·행 수준 접근 제어 구현
• Q57 Athena 비용 최적화 — 파일 형식 + 파티션 (복수 정답)
• Q58 Lambda S3→DynamoDB 액세스 오류 원인
• Q59 SageMaker Studio에서 Glue 카탈로그 테이블 분석
• Q60 주간 2TB 처리 워크플로 — 가장 비용 효율적 오케스트레이션

Q56Lake Formation · 셀수준 보안 · 데이터 필터⭐ 자주 출제

AWS Lake Formation 데이터 필터는 열(Column) 수준, 행(Row) 수준, 셀(Cell) 수준의 세밀한 접근 제어를 제공합니다. IAM 정책이나 S3 버킷 정책으로는 열·행 수준 제어가 불가능하며, Glue 크롤러로 메타데이터를 등록한 뒤 Lake Formation 권한을 설정합니다.

📋 Question

대학이 교수·학생 데이터를 Amazon S3에 저장하고 여러 사용자가 Amazon Athena로 필요한 데이터 서브셋을 즉시 조회합니다. 데이터는 민감하여 열 수준 및 행 수준 권한으로 사용자와 애플리케이션의 접근을 제어해야 합니다. 올바른 솔루션은 무엇일까요?

• AAWS Lake Formation으로 S3 데이터에 대한 Glue 크롤러를 실행합니다. 데이터 필터를 사용하여 검색된 테이블에 열·행·셀 수준 권한을 설정합니다.
  ✅ AWS Lake Formation 데이터 필터 — 열·행·셀 단위 세밀한 접근 제어. Glue 크롤러로 S3 데이터 스키마를 카탈로그에 등록한 뒤, Lake Formation에서 사용자·역할별 접근 가능 열과 행 조건을 데이터 필터로 정의. Athena 쿼리 시 자동 필터 적용.
• BS3 버킷 정책을 사용하여 객체 수준에서 세밀한 권한을 설정하고 사용자·애플리케이션에 매핑합니다.
  ❌ S3 버킷 정책은 버킷·객체(파일) 단위 접근 제어. 열·행 수준의 세밀한 제어 불가. 파일 전체를 허용하거나 거부할 수 있을 뿐.
• CIAM 그룹·역할에 세밀한 정책을 연결하여 S3 버킷 데이터 접근을 제어합니다.
  ❌ IAM 정책은 API 호출 수준(S3 GetObject 허용/거부). 테이블 내 특정 열·행 수준 접근 제어 불가. Lake Formation으로만 구현 가능.
• DAWS Batch로 사용자별 접근 가능한 데이터 서브셋을 별도 S3 버킷에 복사하고 S3 버킷 정책으로 보호합니다.
  ❌ 데이터를 사용자별 버킷에 복사하는 방식은 데이터 중복 + 동기화 지연(즉시 접근 불가) + 높은 유지보수 부담. 1시간 지연 문제도 있어 즉시 접근 요건 미충족.

🎯

정답

A — Glue 크롤러 + Lake Formation 데이터 필터 (열·행·셀 수준)

🔑 핵심 개념 — 접근 제어 방법별 세밀도 비교

방법	최소 제어 단위	열·행 수준?
Lake Formation 데이터 필터	셀(Cell) 수준	✓ 모두 가능
IAM 정책	API 호출 수준	✗
S3 버킷 정책	객체(파일) 수준	✗
AWS Batch 복사	버킷 단위	✗ 복잡·지연

💡 이것만 기억하자

"열·행·셀 수준 세밀한 접근 제어"
→ Lake Formation 데이터 필터

IAM / S3 버킷 정책 = 파일·API 단위 (열·행 수준 불가)
Lake Formation = 테이블 내 열·행·셀 단위 제어 가능

---

Q57Athena · Parquet · 캠페인 파티션 · 비용 최적화✌️ 복수 정답

Athena 비용 최적화의 두 핵심은 열 형식(Parquet/ORC)과 쿼리 패턴에 맞는 파티셔닝입니다. 열 형식은 필요한 컬럼만 스캔해 비용을 줄이고, 파티셔닝은 관련 데이터만 스캔해 추가로 절감합니다.

📋 Question — 두 가지를 선택하세요

마케팅팀이 캠페인별 반응 데이터를 S3에 .csv 파일로 저장합니다. Amazon Athena로 각 캠페인 데이터를 분석할 예정입니다. 일관된 데이터 소스 세트가 각 캠페인 데이터를 생성합니다. 데이터 저장 및 분석 비용을 최적화하는 단계의 조합은 무엇일까요?

• A.csv 파일을 Apache Parquet 형식으로 변환합니다.
  ✅ Apache Parquet — 열 기반(Columnar) 형식. Athena는 스캔한 데이터 바이트 기준 과금 → 필요한 열만 스캔하는 Parquet 사용 시 스캔량과 비용 대폭 감소. 압축 최적화로 스토리지 비용도 절감.
• B.csv 파일을 Apache Avro 형식으로 변환합니다.
  ❌ Apache Avro — 행 기반(Row-oriented) 형식. 모든 필드에 접근할 때 적합. Athena 분석 쿼리는 일부 열만 접근하는 경우가 많아 열 기반 Parquet이 더 비용 효율적.
• C데이터를 캠페인별로 파티셔닝합니다.
  ✅ 캠페인별 파티셔닝 — 분석가가 특정 캠페인 데이터를 쿼리할 때 해당 캠페인 파티션만 스캔 → 스캔 데이터량 감소 → 비용 절감 + 속도 향상. 분석 패턴(캠페인별)과 파티션 기준이 일치하므로 효과 극대화.
• D데이터를 소스별로 파티셔닝합니다.
  ❌ 분석 쿼리가 캠페인별로 실행됨. 일관된 소스 세트가 모든 캠페인에 데이터를 공급하므로 소스별 파티셔닝은 쿼리 패턴과 맞지 않아 스캔량 절감 효과 없음.
• E.csv 파일을 압축합니다.
  ❌ CSV를 압축해도 여전히 행 기반 형식이라 Athena가 필요한 열만 스캔할 수 없음. Parquet으로 변환하는 것이 더 효과적. CSV 압축은 스토리지 비용은 줄이지만 쿼리 비용 절감 효과는 Parquet보다 낮음.

🎯

정답

A + C — Parquet 변환 + 캠페인별 파티셔닝

🔑 핵심 개념 — Athena 비용 절감 전략

전략	원리	비용 절감 효과
Parquet/ORC 형식	필요한 열만 스캔	✓ 높음
쿼리 패턴별 파티셔닝	관련 파티션만 스캔	✓ 높음
CSV 압축	파일 크기 감소	낮음 (전체 스캔)
Avro 변환	행 기반 유지	낮음

💡 이것만 기억하자

Athena 비용 최적화 2요소:
1. Parquet/ORC = 열 형식 (필요 컬럼만 스캔)
2. 쿼리 패턴 파티셔닝 = 필요 파티션만 스캔

파티셔닝 기준 = 분석 쿼리의 WHERE 조건과 일치해야 효과적

---

Q58Lambda · KMS 키 정책 · 액세스 오류 디버깅⭐ 자주 출제

AWS KMS 키 정책(Key Policy)은 IAM 정책과 별개로 KMS 키에 누가 접근할 수 있는지 제어합니다. IAM 정책에 kms:Decrypt 권한이 있어도 KMS 키 정책에 해당 역할이 명시되지 않으면 접근이 거부됩니다.

📋 Question

Lambda 함수가 KMS 암호화된 S3 버킷에서 객체를 읽어 DynamoDB 테이블에 적재합니다. Lambda 실행 역할에는 DynamoDB Full Access, Lambda Basic Execution Role, 그리고 KMS Decrypt/Encrypt 및 S3 GetObject 권한이 인라인 정책으로 포함되어 있습니다. 함수 실행 시 액세스 오류가 발생합니다. 가장 가능성 높은 원인은 무엇일까요?

• ALambda 실행 역할에 Amazon CloudWatch Logs 접근 권한이 없습니다.
  ❌ CloudWatch Logs 권한 없어도 함수 실행 자체는 됨. 단지 로그 기록만 안 될 뿐. 액세스 오류의 원인이 아님. AWSLambdaBasicExecutionRole이 이미 포함되어 있어 로그 권한도 있음.
• B인라인 정책에 KMS 키 접근에 필요한 작업이 누락되었습니다.
  ❌ 인라인 정책에 kms:Decrypt, kms:Encrypt, kms:CreateGrant, kms:ListAliases가 모두 포함되어 있어 IAM 측 권한은 충분함. 이것이 원인이 아님.
• CKMS 키 정책(Key Policy)에 Lambda 함수 실행 역할이 추가되어 있지 않습니다.
  ✅ KMS 키 정책(Key Policy) — KMS 키 자체에 누가 사용할 수 있는지 명시하는 리소스 기반 정책. IAM 정책과 별개로 키 정책에도 허용이 필요. Lambda 실행 역할이 IAM 정책에서 kms:Decrypt를 가져도, KMS 키 정책에 해당 역할이 없으면 거부됨.
• DS3 버킷 리소스 정책에 Lambda 실행 역할이 추가되어 있지 않습니다.
  ❌ Lambda 실행 역할에 이미 s3:GetObject 권한이 인라인 정책에 포함되어 있어 S3 접근은 문제없음. S3 버킷 정책에 명시적으로 추가하지 않아도 IAM 정책 기반으로 접근 가능.

🎯

정답

C — KMS 키 정책에 Lambda 실행 역할 미추가

🔑 핵심 개념 — IAM 정책 vs KMS 키 정책

정책 유형	제어 대상	모두 필요?
IAM 정책 (kms:Decrypt 등)	IAM 주체의 KMS 사용 권한	✓ 둘 다 필요
KMS 키 정책	키 자체에 누가 접근 가능한지

💡 이것만 기억하자

KMS 암호화 S3 접근 권한 = IAM 정책 AND KMS 키 정책 둘 다 필요

IAM에 kms:Decrypt 있어도 키 정책에 없으면 거부됨
→ KMSAccessDeniedException 발생

---

Q59SageMaker Data Wrangler · Athena · 데이터 준비⭐ 자주 출제

Amazon SageMaker Data Wrangler는 Athena·Redshift 등 다양한 소스에서 데이터를 가져와 코드 없이 300+ 내장 변환으로 정리·시각화할 수 있는 통합 데이터 준비 도구입니다.

📋 Question

SageMaker Studio에서 작업 중인 데이터 엔지니어가 Glue 카탈로그에 등록된 소규모 테이블을 쿼리하고 데이터 정리·시각화를 수행해야 합니다. 운영 오버헤드를 최소화하는 방법은 무엇일까요?

• ASageMaker 파이프라인을 구축하여 데이터를 준비하고 시각화 파라미터를 로깅합니다.
  ❌ SageMaker 파이프라인 — CI/CD 기반 엔드투엔드 ML 워크플로 자동화 도구. 탐색적 분석이 아닌 반복적 프로덕션 워크플로에 적합. 설정·유지보수 오버헤드가 큼.
• BAmazon Athena로 데이터를 가져오기 위해 SageMaker Data Wrangler를 사용하고, Data Wrangler에서 데이터를 정리·시각화합니다.
  ✅ SageMaker Data Wrangler — Athena(Glue 카탈로그 포함) 등 다양한 소스에서 데이터를 직접 연결. 300개 이상 내장 변환으로 코드 없이 데이터 정리·시각화. SageMaker Studio와 완벽 통합으로 별도 설정 없이 즉시 사용 가능.
• CSageMaker 노트북 인스턴스에서 Athena로 테이블을 쿼리하고 데이터 탐색·시각화 함수를 직접 작성합니다.
  ❌ 노트북 인스턴스 + 쿼리 코드 + 시각화 함수까지 모두 직접 작성해야 함. Data Wrangler의 내장 기능(코드 없음)을 활용하는 것이 더 효율적.
• DSageMaker Data Wrangler를 EMR 클러스터에 연결하여 데이터를 쿼리하고 준비합니다.
  ❌ 소규모 테이블에 EMR 클러스터 프로비저닝은 과도한 리소스. EMR 연결 설정 추가 오버헤드도 발생. Athena를 직접 Data Wrangler에 연결하는 것이 훨씬 간단.

🎯

정답

B — SageMaker Data Wrangler + Athena 연동

🔑 핵심 개념 — SageMaker 데이터 준비 도구 비교

도구	코딩 필요	내장 변환	적합 용도
Data Wrangler	없음	300+ 내장	탐색·정리·시각화
노트북 인스턴스	많음	직접 구현	유연한 커스텀 분석
SageMaker 파이프라인	많음	일부	프로덕션 ML 워크플로
EMR + Data Wrangler	중간	300+ 내장	대규모 분산 처리

💡 이것만 기억하자

"SageMaker Studio에서 소규모 테이블 정리·시각화 + 최소 오버헤드"
→ SageMaker Data Wrangler + Athena 연결

코드 없이 300+ 내장 변환 사용 가능
EMR = 대규모 처리용 (소규모엔 과도)

---

Q60Step Functions · Glue ETL · 서버리스 오케스트레이션⭐ 자주 출제

AWS Step Functions + AWS Glue는 서버리스 오케스트레이션 + 서버리스 ETL 조합으로 인프라 관리 없이 복잡한 ETL 워크플로를 비용 효율적으로 실행합니다. 두 서비스 모두 서버리스이므로 사용한 만큼만 과금됩니다.

📋 Question

의료 연구 기관이 매주 여러 S3 버킷에 2TB의 환자 데이터를 수신합니다. 주 1회 처리 워크플로를 오케스트레이션해야 합니다. 가장 비용 효율적인 솔루션은 무엇일까요?

• AAWS Step Functions로 워크플로를 오케스트레이션하고, Amazon EC2 인스턴스에서 ETL 작업을 수행합니다.
  ❌ Step Functions는 서버리스로 좋지만 EC2 인스턴스는 주 1회 사용에도 시간당 비용 발생. 인스턴스 관리·확장 오버헤드도 추가. 서버리스 Glue보다 비용이 높음.
• BAWS Step Functions로 처리 워크플로를 오케스트레이션하고, AWS Glue로 ETL 작업을 수행합니다.
  ✅ AWS Step Functions — 서버리스 워크플로 오케스트레이션. 상태 머신으로 여러 Glue 작업을 순서대로/병렬로 조정. AWS Glue — 서버리스 ETL. 실행 시간만큼만 과금. 두 서비스 모두 서버리스 → 주 1회 실행에 가장 비용 효율적.
• CAWS Lambda 함수로 처리 워크플로를 오케스트레이션하고, AWS Glue로 ETL 작업을 수행합니다.
  ❌ Lambda는 서버리스 컴퓨팅 서비스이지 오케스트레이션 서비스가 아님. 복잡한 다단계 워크플로 조정에는 Step Functions가 적합. Lambda 단독으로 오케스트레이션하면 복잡한 상태 관리 코드를 직접 작성해야 함.
• DAmazon SQS로 처리 워크플로를 오케스트레이션하고, AWS Glue로 ETL 작업을 수행합니다.
  ❌ Amazon SQS — 메시지 큐 서비스. 분산 시스템 메시지 전달에는 유용하지만 다단계 ETL 워크플로 오케스트레이션 기능이 없음. 순서 제어·상태 추적·오류 처리를 별도로 구현해야 함.

🎯

정답

B — Step Functions(오케스트레이션) + Glue(ETL) 서버리스 조합

🔑 핵심 개념 — 오케스트레이션 서비스 비교

서비스	오케스트레이션?	서버리스?	ETL 워크플로 적합?
Step Functions	✓ 전용	✓	✓
Lambda	✗ 컴퓨팅만	✓	상태 관리 직접 구현
Amazon SQS	✗ 메시지 큐	✓	워크플로 제어 없음
EC2	구현 필요	✗	비용 과다

💡 이것만 기억하자

"ETL 워크플로 오케스트레이션 + 비용 효율"
→ Step Functions(오케스트레이션) + AWS Glue(ETL)

두 서비스 모두 서버리스 → 사용한 만큼만 과금
Lambda / SQS = 오케스트레이션 서비스 아님

AWS DEA-C01Lake Formation 데이터 필터Athena Parquet 파티션KMS 키 정책SageMaker Data WranglerStep Functions GlueAWS 자격증