AWS DEA-C01 각색 문제 Day 11 — KMS + Lambda, Glue 카탈로그, Firehose + Lambda → OpenSearch, Secrets Manager, S3 Standard-IA

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

KMS + Lambda 데이터 마스킹, Glue 카탈로그 대칭 CMK 암호화, Firehose + Lambda → OpenSearch, Secrets Manager 다중 리전, S3 Standard-IA 블로그 수명주기 — 5문제 핵심 정리.

AWS DEA-C01 Domain 2·4 · 보안 · 암호화 · 스트리밍 5문제

📋 목차

• Q51 암호화 키 교체 + 데이터 마스킹 + 보안 스토리지
• Q52 Glue 데이터 카탈로그 객체 KMS 암호화
• Q53 Kinesis → 변환 → OpenSearch 수집 (운영 최소)
• Q54 다중 리전 Lambda JDBC 자격증명 안전 저장
• Q55 블로그 30일 후 비용 절감 + 실시간 검색 유지

Q51KMS · Lambda 마스킹 · 데이터 보안 거버넌스⭐ 자주 출제

포괄적 데이터 보안에는 암호화(KMS), 마스킹(Lambda), 안전한 저장소(Redshift)가 모두 필요합니다. 각각의 역할을 명확히 구분하는 것이 DEA-C01 보안 도메인의 핵심입니다.

📋 Question

금융 데이터 플랫폼이 암호화, 마스킹을 포함한 포괄적인 데이터 보안 요건을 충족해야 합니다. 암호화 키는 주기적으로 교체 가능해야 합니다. 이 요건을 모두 충족하는 솔루션은 무엇일까요?

• AAWS Glue로 데이터를 카탈로그화·변환하고 Glue 내부에서 데이터 마스킹을 적용합니다. Amazon S3에 데이터를 저장합니다.
  ❌ Glue는 ETL 도구. 암호화 키 관리 및 교체 기능이 없음. S3 기본 암호화는 있지만 포괄적 암호화·마스킹 요건을 단독으로 충족하기 어려움.
• BAWS KMS로 암호화 키를 생성·관리하고, Lambda 함수로 민감 데이터에 마스킹을 적용합니다. Amazon Redshift에 데이터를 저장합니다.
  ✅ AWS KMS — 암호화 키 생성·관리·자동 교체 기능 제공. Lambda — 서버리스 마스킹 로직 실행. Amazon Redshift — KMS와 통합된 안전한 데이터 웨어하우스. 세 서비스가 암호화 + 마스킹 + 보안 스토리지 + 키 교체 요건을 모두 충족.
• CAWS CloudTrail로 API 호출을 모니터링하고, Lambda로 CloudTrail 로그에 마스킹을 적용합니다. Amazon S3에 데이터를 저장합니다.
  ❌ AWS CloudTrail — 감사 로그 기록 서비스. 실제 데이터 암호화 기능이 없음. CloudTrail 로그 마스킹은 요건의 데이터 마스킹과 다른 개념.
• DAWS Secrets Manager로 API 키·자격증명을 저장하고, Secrets Manager 내에서 마스킹을 구현합니다. Amazon Redshift에 저장합니다.
  ❌ AWS Secrets Manager — 자격증명 저장·교체 서비스. 데이터 마스킹 기능이 내장되어 있지 않음. 실제 데이터 암호화 요건도 충족하지 못함.

🎯

정답

B — KMS(암호화·키 교체) + Lambda(마스킹) + Redshift(저장)

🔑 핵심 개념 — 데이터 보안 서비스 역할 분담

서비스	역할	키 교체?	마스킹?
AWS KMS	암호화 키 생성·관리	✓ 자동	없음
AWS Lambda	마스킹 로직 실행	없음	✓ 커스텀
Secrets Manager	자격증명 저장·교체	자격증명만	✗
CloudTrail	API 호출 감사	없음	✗

💡 이것만 기억하자

"암호화 키 교체 + 데이터 마스킹 + 보안 스토리지"
→ KMS + Lambda + Redshift

Secrets Manager = 자격증명 교체 (데이터 암호화·마스킹 아님)

---

Q52Glue 데이터 카탈로그 · KMS 암호화 · 대칭 CMK⭐ 자주 출제

AWS Glue 데이터 카탈로그 암호화는 카탈로그 객체(테이블·데이터베이스 메타데이터)를 KMS로 암호화하는 기능입니다. 대칭 고객 관리형 키(Symmetric CMK)만 지원하며, S3 버킷 암호화와는 별개입니다.

📋 Question

금융 회사가 민감한 데이터를 S3 버킷에 저장하고 AWS Glue 데이터 카탈로그로 메타데이터를 관리합니다. 규정상 S3 메타데이터에서 생성되는 모든 Glue 데이터 카탈로그 객체를 AWS KMS로 암호화해야 합니다. 올바른 설정 방법은 무엇일까요?

• AGlue 데이터 카탈로그 설정에서 메타데이터 암호화를 위한 대칭 고객 관리형 키(Symmetric CMK)를 선택합니다.
  ✅ Glue 데이터 카탈로그 암호화 설정 — 카탈로그 전체 객체(테이블·데이터베이스)를 KMS로 암호화. 대칭 CMK(Symmetric Customer Managed Key) — AWS Glue가 지원하는 유일한 키 유형. 암호화·복호화에 같은 키를 사용. 카탈로그 설정에서 활성화하면 이후 생성되는 모든 객체에 적용.
• BGlue 데이터 카탈로그 설정에서 메타데이터 암호화를 위한 비대칭 고객 관리형 키(Asymmetric CMK)를 선택합니다.
  ❌ 비대칭 CMK(Asymmetric CMK) — 공개키/개인키 쌍 방식. AWS Glue 데이터 카탈로그는 비대칭 키를 지원하지 않음. 대칭 키만 사용 가능.
• CS3 버킷 서버 측 암호화 설정에서 대칭 고객 관리형 키를 선택합니다.
  ❌ S3 버킷 암호화는 S3에 저장된 데이터 파일(객체)을 암호화하는 것. 요건은 Glue 데이터 카탈로그 객체(메타데이터) 암호화로 별개의 설정. 두 가지는 서로 다른 암호화 범위.
• DS3 버킷 서버 측 암호화 설정에서 비대칭 고객 관리형 키를 선택합니다.
  ❌ Amazon S3는 저장 데이터 암호화에 비대칭 CMK를 지원하지 않음. 또한 S3 설정으로는 Glue 카탈로그 객체를 암호화할 수 없음. 두 가지 모두 오답.

🎯

정답

A — Glue 카탈로그 설정에서 대칭 CMK로 메타데이터 암호화

🔑 핵심 개념 — Glue 카탈로그 vs S3 암호화 범위

암호화 설정	암호화 대상	지원 키 유형
Glue 카탈로그 설정	카탈로그 객체(메타데이터)	대칭 CMK만
S3 서버 측 암호화(SSE)	S3 버킷의 데이터 파일	대칭 키만

💡 이것만 기억하자

"Glue 데이터 카탈로그 객체 KMS 암호화"
→ 카탈로그 설정 + 대칭 CMK

비대칭 CMK = Glue 카탈로그에서 지원 안 함
S3 암호화 = 카탈로그 암호화와 별개

---

Q53Firehose · Lambda 변환 · OpenSearch⭐ 자주 출제

Amazon Data Firehose는 Kinesis Data Streams에서 데이터를 받아 Lambda로 변환한 뒤 OpenSearch Service 등으로 전송하는 완전관리형 스트리밍 파이프라인입니다. 자체 컨슈머 개발 없이 낮은 운영 오버헤드로 구현 가능합니다.

📋 Question

음악 분석 플랫폼이 Kinesis Data Streams를 통해 매일 수백만 건의 스트리밍 이벤트를 수신합니다. 이 데이터를 변환한 후 Amazon OpenSearch Service 도메인으로 수집해야 합니다. 운영 오버헤드가 가장 적은 방법은 무엇일까요?

• AAmazon Data Firehose로 Kinesis Data Streams에서 데이터를 받아 Lambda 함수로 변환하고 OpenSearch Service로 전송합니다.
  ✅ Amazon Data Firehose — Kinesis Data Streams를 소스로, OpenSearch Service를 대상으로 직접 지원. Lambda 변환 — Firehose가 대상 전달 전 Lambda를 자동 호출해 레코드 변환. 자체 컨슈머 코드 없이 완전관리형으로 파이프라인 구성.
• B사전 구성된 필터가 있는 Logstash 파이프라인으로 데이터를 변환하고 OpenSearch Service로 전송합니다.
  ❌ Logstash — 오픈소스 데이터 수집·처리 도구. 자체 호스팅 및 관리가 필요. 서버 운영 비용과 유지보수 부담 발생. 완전관리형 대비 운영 오버헤드 높음.
• CLambda 함수로 Kinesis Agent를 호출하여 데이터를 변환하고 OpenSearch로 전송합니다.
  ❌ Kinesis Agent — 데이터를 Kinesis Data Streams에 쓰는(Write) 도구. 스트림에서 읽어서 처리하는 기능이 없음. 데이터 흐름 방향이 반대.
• DKinesis Client Library(KCL)로 데이터를 읽어 변환하고 OpenSearch로 전송합니다.
  ❌ KCL(Kinesis Client Library) — Kinesis 스트림 읽기 애플리케이션 개발 라이브러리. 직접 애플리케이션을 개발·배포·관리해야 해 Firehose보다 훨씬 높은 운영 오버헤드 발생.

🎯

정답

A — Firehose + Lambda 변환 → OpenSearch (완전관리형)

🔑 핵심 개념 — Kinesis → OpenSearch 파이프라인 방법 비교

방법	운영 부담	OpenSearch 네이티브?	변환 지원?
Firehose + Lambda	최소	✓	✓ 내장
KCL 직접 개발	높음	개발 필요	직접 구현
Logstash 자체 호스팅	높음	✓	✓
Kinesis Agent	중간	쓰기 전용	제한적

💡 이것만 기억하자

"Kinesis → 변환 → OpenSearch + 운영 최소"
→ Firehose + Lambda 변환

Firehose = Kinesis 소스 + Lambda 변환 + OpenSearch 대상 모두 지원
KCL = 직접 개발 필요 → 오버헤드 높음

---

Q54Secrets Manager · 다중 리전 · JDBC 자격증명⭐ 자주 출제

AWS Secrets Manager는 자격증명을 안전하게 저장하고 다중 리전 복제를 지원합니다. Lambda 환경 변수나 Lambda 계층에 자격증명을 저장하는 것은 보안 모범 사례에 어긋납니다.

📋 Question

Lambda 함수가 JDBC를 사용하여 여러 AWS 리전의 Amazon Redshift 클러스터에 ETL 작업을 수행합니다. JDBC 자격증명을 안전하게 저장하고 모든 리전에서 접근 가능하도록 해야 합니다. 가장 안전한 방법은 무엇일까요?

• ALambda 환경 변수에 자격증명을 저장하고 필요한 리전에 구성을 복제합니다.
  ❌ Lambda 환경 변수 — 함수별 설정값 저장 용도. 암호 같은 민감 정보를 저장하면 안 됨. 환경 변수는 콘솔에서 평문으로 보일 수 있어 보안 위험.
• BKMS로 암호화된 S3 버킷에 자격증명 파일을 저장하고 S3 교차 리전 복제로 배포합니다.
  ❌ S3 파일에 자격증명을 저장하는 것은 모범 사례가 아님. S3/KMS 읽기 권한이 있는 사람은 자격증명에 접근 가능. 잘못된 퍼블릭 접근 설정 위험도 있음.
• CAWS Secrets Manager에 자격증명을 저장하고 필요한 리전에 보안 암호를 복제합니다. Lambda 함수에서 Secrets Manager API로 자격증명을 조회합니다.
  ✅ AWS Secrets Manager — 자격증명 저장·암호화·자동 교체를 위한 전용 서비스. 다중 리전 복제 — 보안 암호를 다른 리전으로 자동 동기화. Lambda에서 API 호출로 최신 자격증명 조회. 가장 안전하고 관리하기 쉬운 방법.
• D자격증명을 Lambda 계층(Layer)에 저장하고 각 리전에 Lambda 계층을 복사합니다.
  ❌ Lambda 계층 — 재사용 가능한 코드·라이브러리 패키지. 자격증명 저장 용도가 아님. 계층은 코드 패키지라 자격증명이 노출될 위험이 있음.

🎯

정답

C — Secrets Manager 다중 리전 복제 + API 조회

🔑 핵심 개념 — 자격증명 저장 방법 보안성 비교

방법	보안성	다중 리전?	적합성
Secrets Manager	✓ 최고	✓ 복제 지원	✓ 모범 사례
Lambda 환경 변수	낮음	수동 복제	비권장
S3 파일(KMS 암호화)	중간	복제 가능	비권장
Lambda 계층	낮음	복사 필요	비권장

💡 이것만 기억하자

"JDBC 자격증명 안전 저장 + 다중 리전"
→ AWS Secrets Manager + 다중 리전 복제

Lambda 환경 변수 = 민감 정보 저장 금지
Lambda 계층 = 코드 패키지 (자격증명 저장 금지)

---

Q55S3 Standard-IA · 수명주기 · 고가용성 + 실시간⭐ 자주 출제

S3 Standard-IA(Infrequent Access)는 접근 빈도가 낮지만 즉시(실시간) 검색이 필요한 데이터에 적합합니다. Glacier는 검색 시간이 분~시간 단위로 실시간 검색 불가, One Zone-IA는 단일 AZ라 고가용성 미보장입니다.

📋 Question

개인 블로그 플랫폼이 S3에 콘텐츠를 저장하며 고가용성이 필요합니다. 분석 결과 게시 후 30일 동안은 자주 조회되고, 이후에는 드물게 접근됩니다. 30일이 지난 게시물도 사용자 요청 시 즉시 제공되어야 합니다. 가장 비용 효율적인 방법은 무엇일까요?

• A30일 후 S3 Glacier Flexible Retrieval로 전환하는 수명주기 정책을 설정합니다.
  ❌ S3 Glacier Flexible Retrieval — 신속 검색 수 분, 표준 검색 수 시간 소요. 즉시(실시간) 검색 요건 미충족. 사용자가 오래된 게시물을 요청해도 수 분~수 시간 후에나 제공됨.
• BS3 Intelligent-Tiering을 사용하여 30일 지난 게시물을 자동으로 더 저렴한 계층으로 전환합니다.
  ❌ S3 Intelligent-Tiering은 접근 패턴이 불규칙하거나 예측 불가할 때 유용. 이 케이스는 30일이라는 명확한 패턴이 이미 파악됨 → 수명주기 정책이 더 비용 효율적. Intelligent-Tiering은 객체별 월별 모니터링 비용이 추가됨.
• C30일 후 S3 Standard-IA로 전환하는 수명주기 정책을 설정합니다.
  ✅ S3 Standard-IA — 다중 AZ 저장(고가용성 ✓) + 즉시 검색(실시간 ✓) + Standard보다 저렴한 스토리지 비용. 접근 패턴이 명확하므로 수명주기 정책으로 정확히 전환. 세 요건(비용 절감·고가용성·실시간) 모두 충족.
• D30일 후 S3 One Zone-IA로 전환하는 수명주기 정책을 설정합니다.
  ❌ S3 One Zone-IA — 단일 AZ 저장으로 Standard-IA보다 저렴하지만 고가용성 요건 미충족. AZ 장애 시 데이터 손실 가능.

🎯

정답

C — 30일 후 S3 Standard-IA 전환 (고가용성 + 실시간 검색)

🔑 핵심 개념 — 요건별 적합 스토리지 클래스

클래스	즉시 검색?	고가용성(다중 AZ)?	비용
S3 Standard-IA	✓	✓	중간
S3 One Zone-IA	✓	✗ 단일 AZ	낮음
Glacier Flexible	✗ 수 분~시간	✓	매우 낮음
S3 Intelligent-Tiering	✓	✓	모니터링 비용 추가

💡 이것만 기억하자

"드문 접근 + 즉시 검색 + 고가용성" → S3 Standard-IA

Glacier = 즉시 검색 불가 (수 분~시간 소요)
One Zone-IA = 단일 AZ → 고가용성 미보장
접근 패턴 명확 = Intelligent-Tiering보다 수명주기 정책이 비용 효율적

AWS DEA-C01KMS 키 교체Glue 카탈로그 암호화Firehose OpenSearchSecrets Manager 다중 리전S3 Standard-IAAWS 자격증