AWS DEA-C01 각색 문제 Day 13 — S3 객체 잠금 규정, QuickSight Athena+SPICE, DMS, S3 Lambda, Athena Parquet+Snappy

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

S3 객체 잠금 규정 준수 모드, QuickSight Athena+SPICE(복수), DMS CDCLatencySource 지표, S3 Lambda 무한루프 버킷 분리, Athena Parquet+Snappy — 5문제 핵심 정리.

AWS DEA-C01 Domain 1·2·4 · 거버넌스·BI·모니터링 5문제

📋 목차

• Q61 S3 파일 최소 2년 삭제 방지 — 법적 요건 충족
• Q62 QuickSight 대시보드 — 비용 효율적 클릭스트림 분석 (복수)
• Q63 DMS CDC 지연 시간 원인 — 소스 DB 확인 지표
• Q64 S3→Lambda 인벤토리 무한루프 방지
• Q65 Athena 쿼리 런타임·스토리지 최적화 — 파일 형식·압축

Q61S3 객체 잠금 · 규정 준수 모드 · WORM⭐ 자주 출제

S3 객체 잠금 규정 준수 모드(Compliance Mode)는 루트 사용자를 포함한 누구도 보존 기간 동안 파일을 삭제하거나 잠금을 해제할 수 없습니다. 버킷 정책이나 MFA 삭제는 권한이 있는 사용자가 우회할 수 있어 완벽한 법적 요건 충족이 어렵습니다.

📋 Question

기업이 비즈니스 크리티컬 데이터를 S3 버킷에 저장합니다. 법적 요건에 따라 파일을 최소 2년간 보관해야 하며, 보존 기간 동안 누구도 파일을 삭제할 수 없어야 합니다. 이 요건을 충족하는 구성은 무엇일까요?

• A규정 준수(Compliance) 모드에서 S3 객체 잠금을 구성하고 보존 기간을 2년으로 설정합니다.
  ✅ S3 객체 잠금 규정 준수 모드(Compliance Mode) — WORM(Write Once, Read Many) 방식. AWS 계정 루트 사용자를 포함한 그 누구도 보존 기간 내 파일 삭제·잠금 해제 불가. 가장 엄격한 불변성 보장.
• B모든 IAM 사용자·역할에 대해 삭제 권한을 명시적으로 거부하는 S3 버킷 정책을 구성합니다.
  ❌ 버킷 정책은 권한이 있는 사용자(예: 버킷 정책 관리자)가 정책 자체를 수정하여 삭제 허용으로 변경할 수 있음. 완전한 삭제 방지를 보장하지 못함.
• CS3 Glacier Deep Archive로 전환하는 수명주기 정책을 구성합니다.
  ❌ S3 수명주기 정책은 스토리지 클래스를 전환하거나 객체를 삭제하는 기능. 파일 삭제를 방지하지 않음. Glacier로 이동해도 권한이 있으면 삭제 가능.
• D실수로 파일을 삭제하지 못하도록 MFA 삭제를 구성합니다.
  ❌ MFA 삭제 — 추가 인증 단계를 요구하지만 MFA를 보유한 사용자는 여전히 삭제 가능. 삭제 방지가 아닌 실수 방지만 제공. 법적 요건 완전 충족 불가.

🎯

정답

A — S3 객체 잠금 규정 준수 모드 + 2년 보존 기간

🔑 핵심 개념 — S3 객체 잠금 모드 비교

모드	삭제 방지 대상	루트 포함?	법적 요건 충족?
규정 준수(Compliance)	모든 사용자	✓ 포함	✓ 완벽
거버넌스(Governance)	일반 사용자	루트·관리자 예외 가능	조건부
버킷 정책	IAM 정책 기반	정책 수정으로 우회 가능	✗ 불완전
MFA 삭제	실수만 방지	MFA 소지자 삭제 가능	✗

💡 이것만 기억하자

"법적 요건 + 누구도 삭제 불가"
→ S3 객체 잠금 규정 준수(Compliance) 모드

Compliance = 루트도 삭제 불가, 보존 기간 동안 절대 불변
Governance = 관리자는 해제 가능 (법적 요건에는 부족)

---

Q62QuickSight · Athena · SPICE · 대시보드✌️ 복수 정답

Amazon QuickSight + Athena + SPICE 조합은 S3 클릭스트림 데이터를 비용 효율적으로 대시보드화하는 표준 패턴입니다. SPICE(인메모리 엔진)는 데이터를 캐시해 빠른 대시보드 조회와 Athena 과금 절감을 동시에 달성합니다.

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

마케팅 회사가 Firehose로 수집한 클릭스트림 데이터를 S3에 저장합니다. 수백 명의 사용자가 사용할 대시보드를 QuickSight로 개발하려 합니다. 클릭스트림 활동의 일별 업데이트를 제공하고 확장 가능하면서 비용 효율적인 단계의 조합은 무엇일까요?

• AAmazon Redshift를 사용하여 클릭스트림 데이터를 저장하고 쿼리합니다.
  ❌ 데이터가 이미 S3에 있는데 Redshift 클러스터를 별도로 운영하면 불필요한 비용 발생. 클러스터 유지 비용 + 데이터 수집 작업까지 추가. S3에서 직접 쿼리하는 방법이 더 효율적.
• BAmazon Athena를 사용하여 S3 클릭스트림 데이터를 쿼리합니다.
  ✅ Amazon Athena — 서버리스, S3 데이터를 직접 SQL 쿼리. 쿼리할 때만 과금. QuickSight 데이터셋 소스로 직접 연결 가능. 클러스터 운영 비용 없음.
• CAmazon S3 분석을 사용하여 클릭스트림 데이터를 쿼리합니다.
  ❌ Amazon S3 분석 — 데이터 접근 패턴을 관찰하여 스토리지 클래스 전환 시점을 결정하는 기능. 데이터 쿼리 기능이 없음. 비용 최적화 분석 도구이지 쿼리 도구가 아님.
• DQuickSight 다이렉트 SQL 쿼리로 대시보드 데이터에 접근합니다.
  ❌ 다이렉트 SQL 쿼리는 대시보드 접근 시마다 소스에서 실시간 쿼리 실행 → Athena 과금이 사용자 수·접근 횟수에 비례하여 증가. 수백 명이 자주 접근하면 비용 급증. SPICE 캐시 사용이 더 비용 효율적.
• EQuickSight SPICE(인메모리 엔진)를 사용하여 데이터를 캐시하고 일별 데이터셋 새로 고침을 구성합니다.
  ✅ QuickSight SPICE — 인메모리 캐시 엔진. 데이터를 SPICE에 가져와두면 대시보드 조회 시 Athena를 재실행하지 않음 → Athena 과금 최소화 + 빠른 응답. 일별 새로 고침으로 최신 데이터 유지. 수백 명 동시 접근에도 확장 가능.

🎯

정답

B + E — Athena(쿼리) + QuickSight SPICE(캐시·대시보드)

🔑 핵심 개념 — QuickSight 데이터 접근 방법 비교

방법	조회 시 Athena 과금?	속도	비용 효율
SPICE + 일별 새로고침	새로고침 시만	빠름	✓ 최적
다이렉트 SQL 쿼리	매 조회마다	느림	비용 증가
Redshift 연결	없음 (클러스터 비용)	빠름	클러스터 유지 비용

💡 이것만 기억하자

"S3 클릭스트림 → QuickSight 대시보드 + 비용 효율"
→ Athena(쿼리) + SPICE(일별 캐시)

SPICE = 인메모리 캐시 → 대시보드 조회 시 Athena 재실행 안 함
다이렉트 SQL = 매 조회마다 Athena 과금 → 비용 급증

---

Q63DMS · CDCLatencySource · 모니터링⭐ 자주 출제

CDCLatencySource는 DMS가 소스 DB(PostgreSQL 등)에서 변경 사항을 캡처하는 데 걸리는 지연을 측정합니다. 소스 DB가 CDC 지연의 원인인지 확인할 때 가장 직접적인 지표입니다.

📋 Question

AWS DMS 지속 복제 작업이 온프레미스 PostgreSQL DB의 변경 사항을 Amazon Redshift로 거의 실시간으로 전송합니다. CDC 중 지연 시간 문제가 발견되었고 PostgreSQL 소스 DB가 원인으로 의심됩니다. 소스 DB가 지연의 원인임을 확인하는 방법은 무엇일까요?

• AAmazon CloudWatch에서 DMS 작업의 CDCIncomingChanges 지표를 검사합니다.
  ❌ CDCIncomingChanges — 특정 시점에 대상에 적용 대기 중인 변경 이벤트 수. 소스 DB의 변경 캡처 지연을 측정하지 않음. 대상 적용 병목을 나타내는 지표.
• Bpostgresql.conf 파일에서 소스 DB의 논리적 복제 설정을 확인합니다.
  ❌ 논리적 복제 설정은 DMS 작업 시작 전제 조건. 이미 복제가 실행 중이므로 설정이 되어 있다는 뜻. 현재 발생하는 지연의 원인 분석과 무관.
• C소스 DB DMS 엔드포인트에 대한 CloudWatch Logs를 확인하고 오류 메시지를 검사합니다.
  ❌ CloudWatch Logs는 오류·경고 이벤트 기록. 소스 지연이 얼마나 심한지 정량적으로 측정하지 않음. 지연 원인 확인에 직접적이지 않음.
• DAmazon CloudWatch에서 DMS 작업의 CDCLatencySource 지표를 검사합니다.
  ✅ CDCLatencySource — 소스 엔드포인트에서 캡처한 마지막 이벤트와 DMS 인스턴스 현재 시각의 차이(초 단위). 이 값이 크면 소스 DB에서 변경 사항 캡처 자체가 지연됨을 의미. 소스 DB를 원인으로 특정하는 가장 직접적인 지표.

🎯

정답

D — CDCLatencySource로 소스 DB 지연 확인

🔑 핵심 개념 — DMS CDC 지연 관련 지표 비교

지표	의미	소스 지연 확인?
CDCLatencySource	소스 캡처 지연 (초)	✓ 직접
CDCLatencyTarget	대상 적용 지연 (초)	대상 지연 측정
CDCIncomingChanges	대기 중인 변경 이벤트 수	✗ 간접
CloudWatch Logs	오류·경고 로그	✗ 정량 측정 아님

💡 이것만 기억하자

"DMS 소스 DB 지연 확인" → CDCLatencySource
"DMS 대상 DB 지연 확인" → CDCLatencyTarget

Source = 소스에서 캡처 지연
Target = 대상에 적용 지연

---

Q64S3 이벤트 · Lambda 루프 · 버킷 분리⭐ 자주 출제

Lambda 함수가 결과물을 트리거 소스 버킷에 다시 쓰면 S3 이벤트가 재발생해 무한 루프가 됩니다. 입력 버킷과 출력 버킷을 분리하면 루프가 차단됩니다.

📋 Question

S3 PUT 이벤트가 Lambda 함수를 트리거하여 인벤토리 측정 프로세스를 실행합니다. 이 프로세스의 결과물을 동일한 S3 버킷에 저장하도록 구성되어 있어 프로세스가 무한 반복됩니다. 새 객체 업로드 시 프로세스가 한 번만 실행되도록 하는 방법은 무엇일까요?

• AS3 PUT 이벤트 트리거 대신 AWS CloudTrail 이벤트를 사용하여 Lambda 함수를 호출합니다.
  ❌ CloudTrail 이벤트로 트리거를 변경해도 인벤토리 결과가 같은 버킷에 저장되면 새 PutObject 이벤트가 발생 → 다시 CloudTrail 이벤트 생성 → 루프 계속. 근본 원인(같은 버킷 쓰기)을 해결하지 않음.
• BAmazon SQS FIFO 대기열을 호출하도록 S3 이벤트를 구성하여 한 번만 처리합니다.
  ❌ SQS FIFO — 중복 없는 메시지 처리를 지원하지만 S3 이벤트 알림의 직접 대상으로 FIFO 큐를 사용할 수 없음. S3 이벤트 알림은 SQS 표준 큐, SNS, Lambda만 지원.
• C서비스 제어 정책(SCP)을 사용하여 S3 버킷에 대한 지속적인 일일 쓰기를 방지합니다.
  ❌ SCP(서비스 제어 정책) — AWS Organizations 단위 최대 권한 정책. 지속적 반복 쓰기 패턴을 감지하고 방지하는 기능이 없음. 쓰기 권한 자체를 제거하면 정상 업로드도 차단됨.
• D판매 데이터 입력 버킷과 인벤토리 프로세스 결과 출력 버킷을 분리합니다.
  ✅ 핵심 해결책. 입력 S3 버킷(판매 데이터 업로드) → Lambda 트리거 → 인벤토리 처리 → 결과를 별도 출력 S3 버킷에 저장. 출력 버킷에는 S3 이벤트 트리거가 없으므로 Lambda가 다시 호출되지 않음. 루프 차단.

🎯

정답

D — 입력·출력 S3 버킷 분리로 무한루프 차단

🔑 핵심 개념 — S3 이벤트 Lambda 루프 방지 아키텍처

구성	루프 발생?
입력 버킷 = 출력 버킷 (현재 문제)	✓ 무한루프
입력 버킷 ≠ 출력 버킷 (해결책)	✗ 루프 없음
이벤트 소스 변경(CloudTrail)	✓ 여전히 루프

💡 이것만 기억하자

"S3 → Lambda → 같은 S3 쓰기" = 무한루프!

해결책: 입력 버킷(트리거)과 출력 버킷(결과)을 분리
→ 출력 버킷에 S3 이벤트 트리거 없음 → 루프 차단

---

Q65Athena · Parquet · Snappy 압축 · 쿼리 최적화⭐ 자주 출제

Apache Parquet + Snappy 압축은 Athena 쿼리 런타임과 스토리지 비용을 동시에 최적화하는 최선의 조합입니다. Parquet은 열 기반 스캔을, Snappy는 빠른 압축·해제를 제공합니다. Athena는 ZIP 압축을 지원하지 않습니다.

📋 Question

Amazon Athena를 사용하여 10~15TB의 비압축 .csv 파일을 분석하려 합니다. 쿼리 런타임과 스토리지 비용 모두를 최적화하기 위해 데이터를 변환해야 합니다. 가장 적합한 파일 형식과 압축 방식의 조합은 무엇일까요?

• A.csv 형식 + ZIP 압축
  ❌ ZIP 압축 — Athena에서 지원하지 않음. Athena는 Snappy, Gzip, Zlib, LZO, Zstd 등 오픈소스 형식만 지원. 또한 CSV 형식 자체가 열 기반이 아니어서 쿼리 성능 개선 제한적.
• BJSON 형식 + bzip2 압축
  ❌ bzip2는 Athena 지원 형식이지만 JSON은 행 기반 형식. 필요한 열만 읽는 열 기반 최적화 불가. 쿼리 런타임 최적화 요건 미충족.
• CApache Parquet 형식 + Snappy 압축
  ✅ Apache Parquet — 열 기반 형식. 필요한 열만 스캔 → Athena 스캔량·비용 대폭 감소. Snappy 압축 — 빠른 압축·해제 속도로 쿼리 런타임 최적화. 파일 크기 감소로 스토리지 비용 절감. Athena에서 Parquet+Snappy가 쿼리 런타임과 비용 모두 최적화하는 표준 조합.
• DApache Avro 형식 + LZO 압축
  ❌ Apache Avro — 행 기반 형식. 실시간 처리·전체 필드 접근에 적합하지 열 기반 분석 쿼리 최적화에 부적합. LZO는 압축률이 낮아 비용 절감 효과 낮음.

🎯

정답

C — Apache Parquet + Snappy 압축 (표준 최적화 조합)

🔑 핵심 개념 — Athena 지원 형식·압축 조합 비교

조합	열 기반?	Athena 지원?	쿼리 성능	스토리지 비용
Parquet + Snappy	✓	✓	최고	최저
ORC + Snappy/Zlib	✓	✓	높음	낮음
JSON + bzip2	✗ 행 기반	✓	낮음	중간
CSV + ZIP	✗	✗ ZIP 미지원	최저	높음

💡 이것만 기억하자

"Athena 쿼리 런타임 + 스토리지 비용 최적화"
→ Apache Parquet + Snappy 압축

ZIP = Athena 미지원 (오답 함정!)
Avro / JSON = 행 기반 → 열 스캔 최적화 불가

AWS DEA-C01S3 객체 잠금QuickSight SPICEDMS CDCLatencySourceS3 Lambda 루프Parquet SnappyAWS 자격증