정답 · 해설

해설

【핵심 용어】 ▸ AWS Shield Advanced — DDoS 공격 방어 및 완화 ▸ DDoS 보호 — 대규모 트래픽 공격 차단 ▸ 자동 완화 — 공격 탐지 시 자동 방어 활성화 【정답 포인트】 ▸ DDoS 공격 위험 감소 → Shield Advanced 지정 ▸ 공용 리소스(ALB) → Shield Advanced 커버리지 ▸ 자동 완화 및 DDoS Response Team(DRT) 지원 ▸ 정책 기반 방어 → 적극적 보안 【오답 체크】 (A) Inspector — 취약점 스캔(DDoS 방어 아님) (B) Macie — 데이터 보안/PII 탐지(DDoS 미지원) (D) GuardDuty — 위협 탐지(예방이 아닌 감시) 【시험 포인트】 ▸ "DDoS 공격" = Shield Advanced 지정 ▸ "공용 애플리케이션" = Shield Advanced 필수 ▸ "위험 감소" = 적극적 방어 서비스 ▸ "ALB + DDoS" = Shield Advanced의 사용 사례 ▸ 최근 웹 공격 = 방어 기능 강화 필수

해설

【핵심 용어】 ▸ AWS WAF 지리적 차단 — 국가/지역 기반 트래픽 필터 ▸ ALB와 WAF 통합 — 로드밸런서 수준 접근 제어 ▸ 정책 기반 제어 — 유연한 국가 추가/변경 【정답 포인트】 ▸ 특정 국가만 허용 → WAF의 지리적 조건 규칙 ▸ ALB 레벨 → 빠른 필터링(EC2 도달 전) ▸ 정책 기반 제어 → 유연한 규칙 변경 ▸ 효율성 → 불필요한 트래픽 조기 차단 【오답 체크】 (A) 보안 그룹 — IP/포트만 제어(지역 정보 없음) (B) ALB 보안 그룹 — IP/포트 제어(국가 매핑 불가) (D) 네트워크 ACL — IP 기반(지역 정보 불가능) 【시험 포인트】 ▸ "특정 국가" = 지리적 조건 필요 ▸ "WAF 지리적 차단" = 국가 수준 제어 ▸ "ALB + WAF" = 레이어 7 필터링 ▸ "정책 제어" = 보안 그룹/네트워크 ACL 불가 ▸ 지역 기반 접근 제어 = WAF의 고급 기능

해설

【핵심 용어】 ▸ API Gateway → Lambda — 완전 서버리스 자동 확장 ▸ 탄력성 — 예측 불가능한 트래픽에 동적 대응 ▸ 연휴 기간 피크 → 탄력적 리소스 필요 【정답 포인트】 ▸ 예측 불가능 트래픽(연휴 집중) → 서버리스 자동 확장(Lambda) ▸ 간단한 계산(세금) → Lambda 적합 ▸ 확장성 최대화 → API Gateway + Lambda 조합 ▸ 관리 오버헤드 최소 → 완전 서버리스 ▸ 응답 시간 개선 → 자동 확장으로 병렬 처리 【오답 체크】 (A) EC2 단일 인스턴스 — 확장성 부족, 고정 용량 (C) ALB + 2개 EC2 — 고정 용량(확장 제한, 연휴 대응 불가) (D) EC2 기반 API — 연휴 트래픽 처리 어려움, 관리 부담 【시험 포인트】 ▸ "연휴 기간만 피크" = 탄력적 리소스 필수 ▸ "확장 가능" = 서버리스(Lambda) ▸ "API + 계산" = API Gateway + Lambda 패턴 ▸ "간단한 요청-응답" = Lambda 최적 사용 사례 ▸ 트래픽 급증 = 자동 확장 필수

해설

【핵심 용어】 ▸ 필드 수준 암호화(Field-Level Encryption) — 특정 폼 필드를 공개 키로 암호화 ▸ 엔드-투-엔드 암호화 — CloudFront에서 원본까지 암호화 상태 유지 ▸ 원본 애플리케이션 복호화 — 특정 애플리케이션만 접근 가능 【정답 포인트】 ▸ 민감한 데이터 암호화 → 애플리케이션에서만 복호화 가능 ▸ 전체 스택 보호 → 엣지와 원본 사이 암호화 유지 ▸ 특정 애플리케이션 제한 → 클라이언트 측 암호화 + 원본만 복호화 키 소유 ▸ HTTPS 이상의 보안 → 애플리케이션 내 보호 【오답 체크】 (A) 서명 URL — 콘텐츠 접근 권한만 제어, 데이터 자체 암호화 없음 (B) 서명 쿠키 — URL과 동일하게 인증만 담당, 암호화 미제공 (D) HTTPS 프로토콜 — 전송 계층 보안만 제공, 애플리케이션 내 보호 불가 【시험 포인트】 ▸ "전체 스택 보호" = 필드 수준 암호화 필수 ▸ "민감한 정보" = 엔드-투-엔드 암호화 ▸ "특정 애플리케이션 제한" = 원본만 복호화 키 소유 ▸ "CloudFront 고급 보안" = 필드 수준 암호화는 CloudFront만 지원 ▸ HTTPS 이상의 보호 = 저장 및 처리 중 보호

해설

【핵심 용어】 ▸ CloudFront — 엣지 로케이션 기반 CDN, S3 오리진에서 콘텐츠 캐싱 ▸ 정적 콘텐츠 배포 — 비용 효율적 글로벌 확장 ▸ 원본 부하 감소 — S3 요청 절감으로 비용 최적화 【정답 포인트】 ▸ 정적 미디어 파일 → CDN 캐싱에 최적화 ▸ 글로벌 수백만 사용자 → 엣지 로케이션에서 로컬 배포 ▸ 원본 부하 감소 → 캐시 히트로 S3 요청 절감 ▸ 비용 효율 → S3 요청 요금 감소 【오답 체크】 (A) Global Accelerator — 동적 콘텐츠 최적화, 고비용, 정적 파일에 비효율 (C) (D) ElastiCache — 인메모리 캐시, 웹 서버 응답 가속용, S3 원본 부하 감소 미흡 【시험 포인트】 ▸ "정적 콘텐츠" = CloudFront CDN의 핵심 사용 사례 ▸ "글로벌 규모" = 엣지 캐싱 필수 ▸ "비용 효율" = 원본 부하 감소 ▸ "수백만 조회" = CDN의 가치 증명 ▸ 미디어 파일 배포 = CloudFront의 표준 시나리오

해설

【핵심 용어】 ▸ 고가용성(HA) — 단일 장애점 제거, 리전 내 다중 AZ 배포 ▸ Auto Scaling 그룹 — 인스턴스 분산 설정으로 AZ 레질리언스 확보 ▸ AZ 장애 극복 — 한 AZ의 장애 시 다른 AZ에서 서비스 지속 【정답 포인트】 ▸ 애플리케이션 수정 불필요 → 인프라 변경만 필요 ▸ 비용 효율성 → 리전 확대보다 AZ 추가가 저렴 ▸ AZ 장애 극복 → 각 AZ에 최소 3개 인스턴스 배포 ▸ ALB는 다중 AZ 자동 지원 → 추가 구성 불필요 【오답 체크】 (A) 리전 분산 — 과도한 비용, 고가용성보다 재해 복구 전략 (C) 템플릿만 생성 — 자동 장애 조치 미흡, 수동 개입 필요 (D) 로드 밸런서 설정 변경 — AZ 장애에 대응 불가, 문제 근본 해결 미흡 【시험 포인트】 ▸ "고가용성" = AZ 다중화 필수 ▸ "애플리케이션 수정 불필요" = 인프라 변경 ▸ "비용 효율" = 리전 내 AZ 추가 ▸ "단일 AZ의 한계" = AZ 장애 시 완전 중단 ▸ "최소 2개 AZ" = 고가용성의 기본 원칙

해설

【핵심 용어】 ▸ RDS 프록시 — 데이터베이스 연결 풀 관리, 연결 재사용으로 오버헤드 감소 ▸ 연결 타임아웃 — 많은 동시 연결로 인한 DB 자원 소진 ▸ Lambda 호환성 — 프록시가 일시적 Lambda 연결 폭증 완화 【정답 포인트】 ▸ 근본 원인 — 과도한 DB 연결, 프록시로 풀 기반 관리로 전환 ▸ 최소 애플리케이션 변경 — RDS 프록시 엔드포인트만 수정 필요 ▸ Lambda 호환성 — 프록시가 일시적 Lambda 연결 폭증 완화 ▸ 비용 최적화 — 연결 풀 재사용으로 DB 자원 효율화 【오답 체크】 (A) 프로비저닝된 동시성 — Lambda 콜드 스타트만 개선, 연결 풀 문제 미해결 (C) 읽기 복제본 — 읽기 트래픽만 분산, 쓰기(주문)는 여전히 병목 (D) DynamoDB 마이그레이션 — 과도한 변경, 비용 및 구조 변경 【시험 포인트】 ▸ "많은 연결로 인한 오류" = RDS 프록시 필수 ▸ "최소 변경" = 엔드포인트만 수정 ▸ "Lambda + DB 연결 급증" = RDS 프록시의 표준 사용 사례 ▸ "판매 행사 급증" = 탄력적 리소스 필요 ▸ "시간 초과 오류" = 연결 풀 문제

해설

【핵심 용어】 ▸ VPC 엔드포인트 — AWS 서비스로 인터넷 게이트웨이 없이 프라이빗 접근 ▸ 네트워크 격리 — 공개 인터넷 경유 없이 AWS 백본만 사용 ▸ 게이트웨이 엔드포인트 — DynamoDB/S3용 특화 엔드포인트 【정답 포인트】 ▸ AWS 네트워크 내 유지 — 공개 인터넷 경로 제거 ▸ 가장 안전한 방법 — 신원 기반 접근 제어, 암호화된 AWS 백본 ▸ 최소 지연 — 엔드포인트가 VPC 내 가용 영역에 위치 ▸ 비용 절감 — NAT 게이트웨이 비용 제거 【오답 체크】 (B) NAT 게이트웨이 — 공개 인터넷 경로 필요, AWS 네트워크 이탈 (C) NAT 인스턴스 — 운영 오버헤드 증가, 여전히 공개 인터넷 경로 (D) 인터넷 게이트웨이 — 공개 인터넷 노출, 보안 위험 극대화 【시험 포인트】 ▸ "AWS 네트워크 내" = VPC 엔드포인트 필수 ▸ "가장 안전한 방법" = 인터넷 경로 제거 ▸ "프라이빗 서브넷" = VPC 엔드포인트의 이상적 사용 사례 ▸ "DynamoDB 접근" = 게이트웨이 엔드포인트 사용 ▸ "최소 지연" = AWS 백본 사용

해설

【핵심 용어】 ▸ DAX — DynamoDB 전용 인메모리 캐시, 마이크로초 응답 시간 ▸ 네이티브 캐시 — DynamoDB와 직접 통합, 애플리케이션 수정 최소화 【정답 포인트】 ▸ DynamoDB 최적화 — DAX는 DynamoDB 읽기에 특화된 캐시 ▸ 애플리케이션 재구성 불필요 — DAX는 DynamoDB와 투명 통합 ▸ 운영 오버헤드 최소 — AWS 관리형, 자동 확장 【오답 체크】 (A) Redis — 범용 캐시, DynamoDB 통합 필요, 애플리케이션 코드 수정 필수 (C) 전역 테이블 — 다중 리전 복제, 읽기 지연 문제 해결 미흡 (D) Memcached — Redis와 유사, 자동 검색도 DynamoDB와 기본 통합 부족 【시험 포인트】 DAX는 DynamoDB 읽기 지연 문제의 표준 솔루션입니다. DynamoDB의 높은 지연(밀리초 단위)을 마이크로초 단위로 개선하며, DynamoDB API와 호환되므로 애플리케이션 코드 변경 최소화가 가능합니다. ElastiCache는 범용 캐시로 설정과 관리가 복잡합니다.

해설

【핵심 용어】 ▸ IAM 역할 — EC2 인스턴스에 임시 자격증명 제공, 고정 암호 불필요 ▸ Parameter Store — 민감 문자열 저장(암호화), KMS 기반 접근 제어 ▸ KMS Decrypt 권한 — 암호화된 매개변수 복호화 필수 【정답 포인트】 ▸ 역할 기반 접근 — EC2에 IAM 역할 할당으로 자동 자격증명 관리 ▸ 이중 권한 — Parameter Store 읽기 + KMS 복호화 모두 필요 ▸ 보안 모범 사례 — 고정 암호 제거, 감사 추적 제공 【오답 체크】 (B) IAM 정책 직접 할당 — EC2 사용자 계정에 할당되지 않음, 인스턴스 신원 기반이 아님 (C) (D) 신뢰 관계 생성 — IAM의 신뢰 관계는 역할과 서비스 간의 관계, 리소스 간 직접 신뢰 관계 불필요 【시험 포인트】 EC2 → Parameter Store 접근 시나리오의 정답은 항상 EC2에 할당된 "IAM 역할"입니다. 이 역할은 Parameter Store 읽기와 KMS 복호화 권한을 모두 필요로 합니다. IAM 정책은 역할에 내재되며, 역할이 EC2 인스턴스 신원이 되어 자동 임시 자격증명을 제공합니다.

해설

【핵심 용어】 ▸ AWS WAF — 애플리케이션 계층(L7) 웹 공격 차단 ▸ AWS Shield Advanced — L3/L4 DDoS 대규모 공격 감지 및 완화 ▸ 다층 방어 — 웹 악용과 DDoS 공격 모두 대응 【정답 포인트】 ▸ API Gateway 보호 — WAF로 SQL 인젝션, XSS 등 웹 공격 차단 ▸ NLB 보호 — Shield Advanced로 대규모 정교한 DDoS 방어 ▸ 포괄적 보안 — 동일 리소스에 WAF와 Shield 동시 적용 가능 【오답 체크】 (A) NLB에 WAF — NLB는 L4 장비, WAF는 L7 지원 불가(ALB에만 지원) (D) GuardDuty + Shield Standard — Standard는 기본 DDoS 보호만, 정교한 공격 미흡 (E) Shield Standard만 — 웹 공격(SQL 인젝션) 방어 불가, 표준 DDoS만 대응 【시험 포인트】 "SQL 인젝션 같은 웹 익스플로잇"은 WAF 담당, "대규모의 정교한 DDoS"는 Shield Advanced 담당입니다. API Gateway에는 WAF 적용, NLB에는 Shield Advanced 적용이 최적입니다. WAF는 ALB/API Gateway에만 지원되고 NLB에는 지원되지 않음을 기억해야 합니다.

해설

【핵심 용어】 ▸ SQS — 비동기 메시지 큐, 생산자-소비자 분리, 순서 불필수 처리 ▸ 느슨한 결합 — 컴포넌트 독립 확장 가능 【정답 포인트】 ▸ 순차 처리, 결과 순서 불중요 → SQS 표준 큐 최적화 ▸ 비동기 통신 → 생산자-소비자 간 직접 의존성 제거 ▸ 탄력적 확장 → 소비자 인스턴스 수 동적 조정 【오답 체크】 (B) SNS — Pub/Sub 패턴, 브로드캐스트용, 순차 처리 및 큐잉 목적에 부적절 (C) Lambda — 직접 호출 모델, 동기식, 높은 결합도, 느슨한 결합 미흡 (D) DynamoDB Streams — 데이터 변경 감지용, 메시지 큐 대체 미적절, 운영 복잡도 높음 【시험 포인트】 마이크로서비스 간 비동기 통신 시나리오에서 "순서 불중요"는 SQS 표준 큐의 핵심 특징입니다. SNS는 즉시 알림 전달(Pub/Sub), Lambda는 동기 통신용이므로 부적절합니다. SQS는 대기열 기반 비동기 처리로 마이크로서비스 아키텍처 확장성을 극대화합니다.

해설

【핵심 용어】 ▸ 다중 AZ(Multi-AZ) — 주 인스턴스 + 동기식 대기 인스턴스(다른 AZ) ▸ 동기식 복제 — 트랜잭션 커밋 시 최소 두 노드에 저장 보장 ▸ 자동 장애 조치 — 주 노드 장애 시 대기 인스턴스 자동 승격 【정답 포인트】 ▸ "최소 두 개 노드" 요구사항 → Multi-AZ가 정확히 충족(주 + 대기) ▸ 동기식 복제 보장 → 데이터 손실 최소화, 높은 내구성 ▸ 최소 운영 오버헤드 → AWS 자동 관리, 수동 개입 불필요 【오답 체크】 (A) 3 AZ + 3 노드 — 요구사항 초과, 불필요한 복잡도 및 비용 증가 (C) 읽기 복제본 — 비동기식(RPO 간격 발생), 읽기 전용, 장애 조치 미흡 (D) EC2 + Lambda — 복잡한 관리, 높은 운영 부담, AWS 관리 기능 활용 미흡 【시험 포인트】 "최소 두 개의 노드"와 "동기식 복제"라는 조건은 Multi-AZ의 정확한 정의입니다. Multi-AZ는 주 인스턴스와 같은 AZ 내 또는 다른 AZ의 대기 인스턴스로 구성되며, 동기식 복제로 트랜잭션 안정성을 보장합니다. 중단 경험이 있는 회사의 재해 복구 전략으로 최적화된 솔루션입니다.

해설

【핵심 용어】 ▸ Lambda VPC 구성 — Lambda 함수를 VPC 내 서브넷에 실행 ▸ 보안 그룹 — 온프레미스 프라이빗 서브넷의 DB 접근 규칙 정의 ▸ Direct Connect 경로 — VPC의 기존 하이브리드 네트워크 경로 활용 【정답 포인트】 ▸ Lambda → VPC 배치 → Direct Connect 경로 자동 활용 ▸ 보안 그룹 → DB 접근 제어(온프레미스 서브넷 트래픽 허용) ▸ 기존 인프라 활용 → 추가 VPN/라우팅 변경 불필요 【오답 체크】 (B) VPN 추가 설정 — Direct Connect 이미 존재, 중복 연결 불필요 (C) 라우팅 테이블만 수정 — Lambda가 VPC 내에 없으면 VPC 경로 사용 불가 (D) 탄력적 IP — 네트워크 인터페이스 필요, Lambda ENI 없이는 비실용적 【시험 포인트】 Lambda가 온프레미스 리소스 접근이 필요할 때의 표준 솔루션은 "Lambda를 VPC 내에 배치"입니다. VPC에 배치되면 VPC의 라우팅 테이블을 따르므로 기존 Direct Connect 경로를 자동으로 활용합니다. 보안 그룹으로 온프레미스 DB 접근을 허용하면 추가 설정 없이 통신이 가능합니다.

해설

【핵심 용어】 ▸ taskRoleArn — ECS 작업(컨테이너)에 부여되는 IAM 역할 ▸ 작업 정의 — 컨테이너 실행 메타데이터, 역할 지정 위치 ▸ 임시 자격증명 — ECS 에이전트가 자동 제공 【정답 포인트】 ▸ 작업 레벨 권한 → taskRoleArn으로 특정 작업에만 S3 접근 부여 ▸ 보안 격리 → 다른 작업/애플리케이션과 권한 분리 ▸ 작업 정의 기반 → 컨테이너 배포 시마다 일관되게 적용 【오답 체크】 (A) ECS 서비스 역할 수정 → ECS 관리 권한 부여, 개별 작업 권한 설정 미흡 (C) 보안 그룹 → 네트워크 수준 제어, IAM 기반 S3 접근 불가능 (D) IAM 사용자 + 인스턴스 로그인 — 자동 임시 자격증명 없음, 보안 취약 【시험 포인트】 ECS 작업에 AWS 서비스 접근 권한을 부여할 때 최우선은 "taskRoleArn"입니다. taskRoleArn은 작업 정의에서 지정되며, 실행 중인 컨테이너에 IAM 역할 기반의 임시 자격증명을 제공합니다. 보안 그룹은 네트워크 수준, IAM은 권한 수준이므로 둘 다 필요하지만 S3 API 호출 인증은 IAM 역할로만 가능합니다.

해설

【핵심 용어】 ▸ Amazon FSx for Windows File Server — Windows 네이티브 SMB 프로토콜, NTFS 지원 ▸ 다중 AZ 공유 접근 — 여러 인스턴스 동시 마운트, 클러스터 파일 시스템 ▸ Windows 호환성 — Active Directory 통합, 권한 관리 【정답 포인트】 ▸ Windows 애플리케이션 → Windows 파일 시스템 필수(SMB, NTFS) ▸ 다중 AZ 공유 → FSx가 다중 AZ 접근 기본 제공 ▸ 마이그레이션 용이 → 기존 Windows 파일 시스템과 호환 【오답 체크】 (A) Storage Gateway — 온프레미스 데이터센터 연동, AWS로 마이그레이션 후 불필요 (C) EFS — Linux 전용, Windows 지원 불가 (D) EBS — 단일 인스턴스 연결만 가능(멀티마운트 미지원), 공유 접근 불가 【시험 포인트】 Windows 기반 다중 AZ 공유 파일 시스템 시나리오는 FSx for Windows File Server의 정의적 사용 사례입니다. EFS는 Linux 전용, EBS는 단일 인스턴스 전용, Storage Gateway는 하이브리드 용이므로 모두 부적절합니다. FSx는 Windows SMB 프로토콜과 NTFS를 지원하여 Windows 애플리케이션 마이그레이션의 최선책입니다.

해설

【핵심 용어】 ▸ AWS Transfer Family — 관리형 SFTP/FTPS/FTP 서비스, S3 직접 통합 ▸ 고가용성 — 여러 가용 영역, 자동 확장 ▸ 운영 오버헤드 제거 — 서버 관리 불필요 【정답 포인트】 ▸ 고가용성 SFTP → Transfer Family 표준 솔루션(관리형) ▸ S3 레이크 통합 → SFTP 업로드가 S3로 직접 전달 ▸ 최소 운영 → AWS 자동 관리, 패치/스케일링 불필요 【오답 체크】 (B) S3 파일 게이트웨이 — SFTP 프로토콜 지원 안 함, NFS/SMB만 지원 (C) (D) EC2 기반 — 인스턴스 관리, OS 패치, cron 스크립트 유지 필요, 운영 부담 높음 (D) NLB + EC2 — EC2 장애 시 수동 대응, 자동 고가용성 미제공 【시험 포인트】 SFTP → S3 시나리오에서 "고가용성"과 "최소 운영 오버헤드"를 동시 요구하면 Transfer Family입니다. S3 파일 게이트웨이는 SFTP를 지원하지 않으므로 오답이고, EC2 기반은 서버 관리 필요로 오버헤드가 최소화되지 않습니다. Transfer Family는 SFTP 프로토콜을 지원하고 S3로 직접 저장하는 관리형 서비스입니다.

해설

【핵심 용어】 ▸ Cognito 사용자 풀 권한부여자 — API Gateway 네이티브 통합, 토큰 검증 자동화 ▸ 관리형 서비스 — Lambda 커스텀 로직 불필요, AWS 제공 기능 활용 【정답 포인트】 ▸ Cognito 사용자 풀 권한부여자 활성화 → 사용자 로그인시 토큰 발급 → API Gateway 자동 검증 ▸ "AWS 관리형" + "최소 오버헤드" → Lambda 커스텀 로직 제거 ▸ 개발자가 API 호출시 Cognito 토큰 전송 → 권한부여자가 토큰 검증 → 접근 제어 【오답 체크】 (A) Lambda 커스텀 권한부여자 → 관리형 아님, 추가 코드·로직 필요 ("개발 노력 감소" 위배) (B) API 키 → 정적 키, 사용자별 권한 제어 불가, 보안 약함 (C) 헤더 이메일 + Lambda 검증 → 이메일 위변조 가능, Lambda 추가 로직 필요 【시험 포인트】 ▸ Cognito 통합 → "관리형", "최소 오버헤드" 키워드 → 권한부여자 선택 필수 ▸ API Gateway + Cognito 아키텍처 → 표준 패턴, 커스텀 로직 제거

해설

【핵심 용어】 ▸ Amazon Pinpoint — 마케팅 커뮤니케이션 플랫폼, SMS/푸시/이메일 통합 ▸ Pinpoint 여정 — 사용자 상호작용 자동화, 응답 추적 ▸ Kinesis 데이터 스트림 — 실시간 이벤트 스트림, 분석·보관 파이프라인 【정답 포인트】 ▸ Pinpoint(SMS 송수신) → 마케팅용 전용 서비스, 양방향 응답 지원 ▸ Kinesis 스트림 → 이벤트 캡처 → 분석·보관 자동화 ▸ 조합: SMS 사용자 상호작용 → 실시간 분석 → 1년 저장 【오답 체크】 (A) Amazon Connect → 음성 통화 센터용, SMS 회신 추적 복잡 (C) SQS → 메시지 큐, SMS 양방향 통신 미지원, 응답 수집 어려움 (D) SNS FIFO → 메시지 브로드캐스트만, Kinesis와 통합 불자연스러움 【시험 포인트】 ▸ 마케팅 SMS 여정 → Pinpoint 우선 선택지 ▸ 이벤트·응답 분석 → Kinesis 데이터 스트림으로 수집·보관

해설

【핵심 용어】 ▸ SSE-S3 — AWS 관리형 암호화, 90일 내부 자동 순환(사용자 제어 불가) ▸ KMS CMK — 고객 관리형 키, 명시적 자동 순환 설정 가능(권장 1년) ▸ 자동 키 순환 — 매년 새 키 생성, 이전 키는 복호화용 보존 【정답 포인트】 ▸ KMS 고객 관리형 키 생성 → 추가 제어권(정책, CloudTrail 감사) ▸ 자동 순환 활성화 → 연 1회 자동화, 수동 개입 제거 ▸ "최소 오버헤드" + "매년 순환" → KMS 자동 순환이 표준 솔루션 【오답 체크】 (A) SSE-S3 — AWS 내부 90일 순환, "매년" 요구사항 미충족, 사용자 제어 불가 (C) 수동 교체 → "최소 오버헤드" 위배, 연간 수동 작업 필수, 자동화 불가 (D) BYOK(고객 키 자료) — 가져온 키는 자동 순환 미지원, 구조적 제약 【시험 포인트】 ▸ 자동 키 순환 → "최소 오버헤드" = KMS 자동 순환 기능 ▸ SSE-S3 vs KMS → 사용자 제어/감사 필요시 KMS 선택