AWS DEA-C01 각색 문제 Day 05 — Secrets Manager, S3 수명주기 정책, Kinesis, Lake Formation PII, Glue 데이터 품질

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

Secrets Manager 자격증명 교체, S3 수명주기 정책, Kinesis 실시간 수집, Lake Formation PII 접근 제어, Glue 데이터 품질 최신성 알림까지 — 5문제 핵심 정리.

AWS DEA-C01 Domain 2·4 · 보안 · 스토리지 · 거버넌스 5문제

📋 목차

• Q21 코드 수정 없이 DB 자격증명 자동 교체
• Q22 S3 수명주기 — 고가용성 유지 + 비용 최적화
• Q23 수백만 이벤트 실시간 수집 — 비용 효율적 방법
• Q24 데이터 레이크 PII 컬럼 수준 접근 제어
• Q25 Glue 간헐적 실패 시 데이터 최신성 알림

Q21Secrets Manager · 자격증명 교체 · 보안⭐ 자주 출제

AWS Secrets Manager는 DB 자격증명을 안전하게 저장하고 자동으로 교체(Rotation)합니다. 애플리케이션은 코드 변경 없이 API 호출로 최신 자격증명을 가져오므로 운영 부담이 최소화됩니다.

📋 Question

의료 기관이 온프레미스 MySQL DB에 환자 기록을 저장하며, 접근 애플리케이션을 운영하고 있습니다. 보안 정책상 30일마다 DB 자격증명을 교체해야 하지만, 교체 때마다 애플리케이션 코드를 수정하는 것은 부담스럽습니다. 운영 오버헤드를 최소화하면서 자동으로 자격증명을 교체하는 방법은 무엇일까요?

• AAWS KMS로 암호화 키를 생성하고 자동 키 교체를 설정한 뒤, 암호화된 자격증명을 DynamoDB 테이블에 저장합니다.
  ❌ AWS KMS(Key Management Service) — 암호화 키를 생성·관리하는 서비스. KMS는 암호화 키를 교체하는 것이지 DB 자격증명(ID/PW)을 교체하는 서비스가 아님. DynamoDB에 저장해도 교체 로직을 별도로 구현해야 함.
• BIAM 역할에 DB 접근 권한을 부여하고, 애플리케이션이 IAM 역할로 임시 자격증명을 받아 DB에 접근하도록 구성합니다.
  ❌ IAM 역할 임시 자격증명은 AWS 서비스 접근용. 온프레미스 MySQL은 AWS 서비스가 아니므로 IAM 인증을 사용할 수 없음.
• C암호화된 S3 버킷에 자격증명을 저장하고, S3 수명주기 정책으로 매월 자격증명 객체를 교체합니다.
  ❌ S3 수명주기 정책은 객체를 다른 스토리지 클래스로 이동하거나 삭제하는 기능. 자격증명을 새 값으로 교체하는 기능이 없음. 교체 로직 전체를 수동으로 구현해야 해 운영 부담이 큼.
• DAWS Secrets Manager에 자격증명을 저장하고 자동 교체 주기를 설정합니다. 애플리케이션은 API 호출로 항상 최신 자격증명을 조회합니다.
  ✅ AWS Secrets Manager — 금고 관리인이 주기적으로 열쇠를 자동 교체하고, 직원은 금고에 열쇠 달라고 요청하면 항상 최신 열쇠를 받는 시스템. 자동 교체 주기 설정(30일) + 애플리케이션은 API 호출로 항상 최신 자격증명 조회 → 코드 수정 불필요.

🎯

정답

D — AWS Secrets Manager 자동 교체 + API 조회

🔑 핵심 개념 — 자격증명 관리 서비스 비교

서비스	주 용도	자동 교체	코드 수정 불필요
Secrets Manager	DB 자격증명·API 키 관리	✓ 내장	✓
KMS	암호화 키 생성·관리	키 교체만	자격증명 관리 아님
Parameter Store	설정값·비밀 저장	수동 교체	교체 로직 별도 구현
S3 버킷	파일 스토리지	✗	✗

💡 이것만 기억하자

"자격증명 자동 교체 + 코드 수정 불필요" → AWS Secrets Manager

KMS = 암호화 키 관리 (자격증명 교체 아님)
온프레미스 DB = IAM 역할 인증 불가

---

Q22S3 수명주기 · 스토리지 클래스 · 비용 최적화⭐ 자주 출제

S3 수명주기 정책으로 접근 빈도에 따라 스토리지 클래스를 자동 전환해 비용을 최적화합니다. 고가용성 조건에서는 단일 AZ인 One Zone-IA를 제외해야 하며, 장기 보관엔 Glacier Deep Archive가 가장 저렴합니다.

📋 Question

분석팀이 S3 Standard 클래스에 모든 데이터를 보관하고 있습니다. 분석 결과 데이터 접근 패턴은 다음과 같습니다: 생성 후 6개월은 매일 여러 번 조회되고, 6개월~2년은 월 1~2회, 2년 이후는 연 1~2회만 접근됩니다. 고가용성을 유지하면서 S3 수명주기 정책으로 비용을 최적화하는 방법은 무엇일까요?

• A6개월 후 S3 One Zone-IA로 전환하고, 2년 후 S3 Glacier Deep Archive로 이동합니다.
  ❌ S3 One Zone-IA — 단일 가용 영역(AZ)에만 데이터 저장. 고가용성 요건 위반. AZ 장애 시 데이터 손실 가능.
• B6개월 후 S3 One Zone-IA로 전환하고, 2년 후 S3 Glacier Flexible Retrieval로 이동합니다.
  ❌ One Zone-IA로 인한 고가용성 요건 위반. 추가로 Glacier Flexible Retrieval은 Deep Archive보다 비쌈.
• C6개월 후 S3 Standard-IA로 전환하고, 2년 후 S3 Glacier Flexible Retrieval로 이동합니다.
  ❌ S3 Standard-IA — 다중 AZ 저장으로 고가용성 충족. 하지만 2년 후 단계에서 Glacier Flexible Retrieval보다 Glacier Deep Archive가 약 4배 더 저렴. 연 1~2회 접근 패턴엔 Deep Archive가 최적.
• D6개월 후 S3 Standard-IA로 전환하고, 2년 후 S3 Glacier Deep Archive로 이동합니다.
  ✅ S3 Standard-IA — 다중 AZ 저장, 고가용성 유지, 월 1~2회 접근에 Standard보다 저렴. S3 Glacier Deep Archive — AWS에서 가장 저렴한 스토리지, 연 1~2회 접근 패턴에 최적. 두 조건 모두 충족.

🎯

정답

D — Standard-IA (고가용성) → Glacier Deep Archive (최저 비용)

🔑 핵심 개념 — S3 스토리지 클래스 비교

클래스	가용성	AZ 수	적합 접근 패턴	비용
S3 Standard	99.99%	3+	매일 여러 번	높음
S3 Standard-IA	99.9%	3+	월 1~2회	중간
S3 One Zone-IA	99.5%	1 (위험)	월 1~2회	중간(저)
Glacier Flexible	99.99%	3+	분기 1회	낮음
Glacier Deep Archive	99.99%	3+	연 1~2회	최저

💡 이것만 기억하자

고가용성 요건 → One Zone-IA 제외 (단일 AZ = 위험)

월 1~2회 → Standard-IA (다중 AZ, 고가용성)
연 1~2회 → Glacier Deep Archive (AWS 최저 비용)

---

Q23Kinesis · 실시간 수집 · 이벤트 처리⭐ 자주 출제

Amazon Kinesis Data Streams는 수백만 이벤트를 밀리초 단위로 실시간 수집하는 완전 관리형 스트리밍 서비스입니다. MSK보다 운영 부담이 낮고 배치보다 지연이 낮아 DEA-C01 실시간 수집 + 비용 효율 조합의 정답 패턴입니다.

📋 Question

미디어 플랫폼이 웹·앱 전반에서 발생하는 사용자 활동 이벤트를 실시간으로 수집하는 파이프라인을 구축하려 합니다. 매우 낮은 지연 시간으로 초당 수백만 건의 이벤트를 처리해야 하며, 데이터 손실 없이 확장 가능하고 내구성 있는 솔루션이 필요합니다. 비용 효율적인 방법은 무엇일까요?

• AAmazon Kinesis Data Streams로 이벤트를 수집하고, Lambda로 처리한 뒤 분석 결과를 Redshift에 저장합니다.
  ✅ Amazon Kinesis Data Streams — 실시간 컨베이어 벨트. 수백만 이벤트를 밀리초 단위로 수집, 자동 샤드 확장, 24시간~365일 데이터 보존으로 내구성 보장. 완전 관리형이라 운영 부담 낮고 Lambda와 직접 연동 가능. 비용 효율적.
• BGlue 작업을 10분 주기로 예약하여 S3의 사용자 로그를 가져와 Redshift에 적재합니다.
  ❌ 10분 배치 주기는 실시간이 아님. 최소 지연 시간 요건과 정반대. 로그가 S3에 쌓이는 동안 지연 발생.
• CAmazon MSK 클러스터를 배포하고, 자체 관리형 컨슈머로 이벤트를 실시간 처리한 뒤 Redshift와 연동합니다.
  ❌ Amazon MSK(Managed Streaming for Kafka) — 완전 관리형 Kafka. 기술적으로 가능하지만 자체 관리형 컨슈머를 별도 구현해야 하고 Kinesis보다 운영 복잡도와 비용이 높음. 신규 구축엔 Kinesis가 더 효율적.
• DS3 이벤트 알림으로 새 로그 파일이 생성될 때마다 Lambda를 트리거하고, 분석 결과를 Redshift에 저장합니다.
  ❌ S3 이벤트 알림은 파일 단위 처리. 수백만 건의 개별 이벤트를 실시간으로 수집하는 구조가 아님. 파일이 생성된 후에야 처리 시작 → 준실시간.

🎯

정답

A — Kinesis Data Streams + Lambda + Redshift

🔑 핵심 개념 — 실시간 이벤트 수집 서비스 비교

서비스	지연 시간	운영 부담	비용 효율	실시간?
Kinesis Data Streams	밀리초	낮음	✓ 높음	✓
MSK (Kafka)	밀리초	높음	중간	✓
Glue 배치	분 단위	낮음	높음	✗
S3 이벤트	초 단위	낮음	높음	준실시간

💡 이것만 기억하자

"수백만 이벤트 실시간 + 비용 효율" → Kinesis Data Streams

MSK = 기존 Kafka 마이그레이션 시 선택, 운영 복잡
Kinesis = 신규 실시간 파이프라인, 완전 관리형, 비용 효율

---

Q24Lake Formation · PII · 열 수준 보안⭐ 자주 출제

AWS Lake Formation 데이터 필터(Data Filter)는 열(Column)·행(Row) 단위로 접근을 제어합니다. PII가 포함된 데이터 레이크에서 그룹별로 필요한 컬럼만 접근하게 하는 가장 간단한 방법으로 DEA-C01에서 자주 출제됩니다.

📋 Question

기업의 S3 데이터 레이크에 일부 개인식별정보(PII)가 포함되어 있습니다. 여러 팀이 원시 데이터에 접근하며, 각 팀은 자신이 처리해야 하는 PII 컬럼에만 접근할 수 있어야 합니다. 최소한의 구현 노력으로 이 요건을 충족하는 방법은 무엇일까요?

• AAthena 쿼리를 백그라운드에서 실행하는 커스텀 쿼리 빌더 UI를 개발하고, Amazon Cognito 사용자 그룹으로 접근 수준을 관리합니다.
  ❌ 사용자 지정 쿼리 빌더 UI를 개발하는 것은 개발 비용이 매우 높고 유지보수 부담도 큼. "최소한의 노력" 요건과 정반대.
• BAmazon QuickSight의 열 수준 보안 기능으로 팀별 PII 접근을 제한하고, QuickSight 대시보드로 데이터에 접근하게 합니다.
  ❌ Amazon QuickSight — BI 시각화 도구. 원시 데이터에 직접 접근하는 게 아니라 시각화 레이어에서만 제어. QuickSight 밖에서 Athena를 직접 쿼리하는 경우는 제어 불가.
• C세분화된 접근 권한을 가진 IAM 역할을 팀별로 만들고, ID 기반 정책에서 열 수준으로 접근을 제한합니다.
  ❌ IAM 정책으로 S3 객체 레벨 접근은 제어 가능하지만 열(Column) 수준 접근 제어는 IAM 정책으로 불가능. 열 수준 보안은 Lake Formation의 기능.
• DAWS Lake Formation을 설정하고 데이터 필터를 생성하여 IAM 역할별 접근 가능한 컬럼을 정의합니다. 각 팀에 해당 역할을 할당하고 Athena로 데이터를 쿼리합니다.
  ✅ Lake Formation 데이터 필터(Data Filter) — 도서관 사서가 특정 회원에게 특정 챕터만 열람 가능하게 설정하는 것. 열(PII 컬럼)·행 단위로 접근 제어. Athena 쿼리 시 자동으로 필터 적용 → 코드 없이 최소 노력으로 구현.

🎯

정답

D — Lake Formation 데이터 필터 + IAM 역할 매핑

🔑 핵심 개념 — 열 수준 접근 제어 방법 비교

방법	열 수준 제어?	구현 노력	원시 데이터 보호
Lake Formation 데이터 필터	✓	최소	✓
IAM 정책	✗ (파일 단위)	중간	파일 단위만
QuickSight 열 보안	BI 레이어만	중간	✗
커스텀 쿼리 빌더	개발 필요	매우 높음	조건부

💡 이것만 기억하자

"PII 열 수준 접근 제어 + 최소 노력" → Lake Formation 데이터 필터

IAM 정책 = 파일/버킷 단위만 제어 (열 수준 불가)
Lake Formation = 열·행 단위 세밀한 접근 제어

---

Q25Glue 데이터 품질 · EventBridge · SNS · 알림⭐ 자주 출제

Glue 데이터 품질 + EventBridge + SNS 조합은 데이터 최신성 등 품질 규칙 실패 시 자동 알림을 보내는 표준 패턴입니다. 작업 실패(Job Fail)와 데이터 최신성 미달(Freshness)은 서로 다른 레이어의 문제임을 구분하는 것이 핵심입니다.

📋 Question

S3의 시계열 데이터를 Redshift 서버리스 테이블에 적재하는 일별 Glue 워크플로가 있습니다. 일부 작업이 간헐적으로 실패하는 것이 확인되었으며, 엔지니어는 Redshift 테이블에 최신 데이터가 없을 경우 즉시 알림을 받아야 합니다. 운영 효율을 최대화하는 방법은 무엇일까요?

• AGlue 작업 로그를 S3에 저장하고, 로그에 Job.State=FAILED가 포함될 때 알림을 보내도록 CloudWatch 알람을 구성합니다.
  ❌ 작업 실패(Job Failed)를 감지하는 것과 데이터 최신성(Freshness) 부재는 다름. 작업이 성공해도 데이터가 최신이 아닐 수 있음. 요건을 정확히 충족하지 못함.
• BGlue 데이터 품질 작업으로 Redshift 테이블의 데이터 최신성을 주기적으로 검사하고, 규칙 실패 시 EventBridge 규칙이 SNS 토픽으로 알림을 전송하도록 구성합니다.
  ✅ Glue 데이터 품질로 최신성(Freshness) 규칙을 정의 (예: 최근 24시간 내 데이터 존재). 규칙 실패 시 EventBridge — 이벤트 자동 반응 시스템 — 가 감지해 SNS — 방송 스피커 — 로 알림 전송. 데이터 최신성을 직접 검사하는 유일한 방법.
• CEventBridge 스케줄러로 Amazon Macie 작업을 실행하여 Redshift 테이블의 최신성을 검사하고, Glue 실패 시 Macie가 SNS로 알림을 보내도록 설정합니다.
  ❌ Amazon Macie — S3의 PII(개인정보) 자동 탐지 및 데이터 보안 서비스. 데이터 최신성 검사 기능이 없음. Macie로 Redshift 검사도 불가. 완전히 용도가 다른 서비스.
• DCloudWatch 대시보드에 일별 Glue 작업 실패 횟수 메트릭을 추가하고, 값이 0을 초과하면 알림을 보내도록 CloudWatch 알람을 설정합니다.
  ❌ A와 같은 이유. 작업 실패 횟수 = 작업 레벨 모니터링. Redshift 테이블의 데이터 최신성을 직접 검사하는 것이 아님.

🎯

정답

B — Glue 데이터 품질 최신성 규칙 + EventBridge → SNS 알림

🔑 핵심 개념 — "작업 실패"와 "데이터 최신성"의 차이

감지 방법	감지 대상	데이터 최신성 직접 검사?
Glue 데이터 품질 최신성 규칙	테이블 내 데이터 최신성	✓ 직접
CloudWatch Glue 실패 알람	작업 실패 여부	✗ 간접
Amazon Macie	S3 PII 탐지	✗ 무관

💡 이것만 기억하자

"Redshift 데이터 최신성 알림"
→ Glue 데이터 품질(Freshness 규칙) + EventBridge + SNS

작업 실패 ≠ 데이터 최신성 미달 → 다른 레이어!
Macie = PII 탐지 도구 (최신성과 무관)

AWS DEA-C01 Secrets Manager S3 수명주기 Glacier Deep Archive Kinesis Data Streams Lake Formation PII Glue 데이터 품질 데이터 엔지니어 자격증 AWS 자격증