정답 · 해설

해설

【핵심 용어】 ▸ Provisioned Concurrency — Lambda 초기화 완료 상태로 사전 준비 ▸ RDS Proxy — 데이터베이스 연결 풀 관리 ▸ 콜드 스타트 — Lambda 초기화 지연 【정답 포인트】 ▸ B) 프로비저닝 동시성 → Lambda 초기화 시간 제거, 즉시 응답 가능 ▸ C) Aurora 글로벌 데이터베이스 → 읽기 복제본으로 지연 시간 감소 ▸ F) RDS Proxy → 연결 풀로 데이터베이스 연결 재사용, 오버헤드 제거 【오답 체크】 (A) 예약 동시성 → 동시 실행 수만 보장, 초기화 시간 단축 아님 (D) 코드 이동 → 함수 핸들러는 매 호출마다 실행, 연결 초기화 반복 (효과 미흡) 【시험 포인트】 ▸ Lambda 성능 최적화 → 프로비저닝 동시성으로 콜드 스타트 제거 ▸ 데이터베이스 연결 최적화 → RDS Proxy로 연결 풀 관리 ▸ 지역 분산 → Aurora 글로벌 데이터베이스로 지연 시간 단축

해설

【핵심 용어】 ▸ RPO(Recovery Point Objective) — 8시간: 최대 8시간의 데이터 손실 허용 ▸ RTO(Recovery Time Objective) — 2시간: 2시간 내 복구 완료 ▸ ECR/Aurora 교차 리전 복제 — 자동 동기화 【정답 포인트】 ▸ Aurora 교차 리전 복제 → 자동으로 RPO 8시간 충족 ▸ ECR 교차 리전 복제 → 이미지가 이미 DR 리전에 복사됨 (빌드 시간 회피) ▸ 2시간 내 구성 요소 준비 완료 → CloudFormation으로 빠른 배포 ▸ 비용 효율 → 자동화된 복제로 수동 관리 최소화 【오답 체크】 (A) Docker 이미지 빌드 필요 → 빌드에 2시간+ 소요 → RTO 미충족 (C) Lambda + EventBridge로 수동 복제 → 자동 복제보다 복잡, 신뢰도 낮음 (D) 글로벌 데이터베이스 + 항시 스택 배포 → 비용 증가, 항상 대기 필요 → 비용 비효율 【시험 포인트】 ▸ 교차 리전 복제 — 자동화된 대기 리전 구성 ▸ RTO/RPO 설계 — 데이터 복제 시간과 배포 시간의 합산 고려 ▸ 비용 효율성 — 필요할 때만 DR 리전 활성화 vs 항시 대기

해설

【핵심 용어】 ▸ CloudWatch Logs Insights — 로그 쿼리 및 분석 엔진 ▸ 집계 함수 — count() 등으로 통계 계산 ▸ 일회성 분석 → 지난 7일 데이터 조회 【정답 포인트】 ▸ Logs Insights 쿼리 → 복잡한 집계 분석에 최적 ▸ 시간 범위 필터링 → last 7 days 조건으로 정확한 기간 설정 ▸ 사용자명 필터 + count() → 특정 사용자의 로그인 횟수 계산 ▸ 즉시 실행 → 근본 원인 분석에 필요한 임시 쿼리 【오답 체크】 (A) 메트릭 필터 → 지속 메트릭 생성에 최적, 과거 데이터 재계산 어려움 (B) 구독 → 실시간 스트리밍 처리, 과거 데이터 분석 부적합 (D) 대시보드 위젯 → 기본 필터링만 가능, 복잡한 집계 함수 미지원 【시험 포인트】 ▸ Logs Insights 활용 → 임시 분석 및 근본 원인 분석 ▸ 메트릭 필터 vs Logs Insights → 지속 모니터링 vs 임시 분석 ▸ 집계 분석 → count, sum, avg 등으로 통계 계산

해설

【핵심 용어】 ▸ 단일 태그 그룹 — AND 조건 (모든 태그 필요) ▸ 다중 태그 그룹 — OR 조건 (그룹 중 하나 일치) ▸ 배포 대상 식별 로직 【정답 포인트】 ▸ 문제 원인 → Environment=Production + Name=ApplicationA 태그만으로는 Application B 제외 불가 ▸ 해결책 → "Name=ApplicationA" 태그 추가로 정확한 식별 ▸ A) Name=ApplicationA 태그 추가 → ApplicationB (Name 태그 다름) 제외 ▸ 단일 태그 그룹에 Name 조건 추가 → ApplicationA만 배포 대상 【오답 체크】 (B) Department=Marketing 추가 → 제외 조건이 아니라 추가 식별 기준 추가 (C) Department=Marketing 태그 그룹 추가 → 이미 ApplicationA도 이 태그 없음 → 배포 안 됨 (D) 태그 그룹 분리 → OR 조건으로 Environment=Production 모든 인스턴스 포함 【시험 포인트】 ▸ CodeDeploy 태그 필터링 — 단일 태그 그룹은 AND, 다중 태그 그룹은 OR ▸ 정확한 대상 식별 — Name 같은 고유 식별 태그 필수 ▸ 태그 계획 — 배포 대상 명확히 구분할 수 있는 태그 설계

해설

【핵심 용어】 ▸ S3 Object Lambda — 객체 검색 시 동적으로 데이터 변환 ▸ 읽기 시점 변환 — 각 앱의 요청 시점에 맞춤 수정 ▸ 원본 데이터 보존 — 단일 원본 유지 【정답 포인트】 ▸ D) S3 Object Lambda → 각 앱의 요청에 따라 다른 Lambda 함수로 변환 ▸ 읽기 시점 변환 → 데이터 저장 시점이 아닌 액세스 시점에 수정 ▸ 원본 보관 → 원본 S3 버킷은 수정 안 됨 ▸ 비용 효율 → 복제 저장 없이 동적 변환 【오답 체크】 (A) SRR 복제 → 저장소 3배 증가, 수정 데이터 관리 복잡 (B) Kinesis 스트림 → 실시간 처리용, 저장 구조 아님, 데이터 지속성 문제 (C) 액세스 포인트 + Lambda → 데이터를 별도 저장해야 함, 중복 저장 증가 【시험 포인트】 ▸ S3 Object Lambda — 읽기 시점 변환의 표준 패턴 ▸ 맞춤형 액세스 제어 — 앱별 다른 데이터 변환 제공 ▸ 저장소 최적화 — 원본 단일 보관으로 비용 절감

해설

【핵심 용어】 ▸ CloudFormation Hooks — 리소스 생성 시점에 사전 검증 ▸ Proactive Control — 규정 위반 리소스 생성 방지 ▸ Control Tower — AWS 규정 준수 자동화 【정답 포인트】 ▸ CloudFormation Hooks → S3 버킷 생성 전 KMS 암호화 여부 검증 ▸ Proactive Control → 정책 위반 리소스 생성 사전 차단 ▸ Control Tower → 조직 전체 OUs에 자동 적용 ▸ 컴플라이언스 보장 → 규정 위반 리소스 생성 원천 차단 【오답 체크】 (A) SCP + x-amz-server-side-encryption → PutObject 시점 제어, CloudFormation 생성 후 검증 (사후) (C) Detective Control → 규정 위반 감지 후 보고, 생성 차단 불가 (D) AWS Config 규칙 → 사후 감지, CloudFormation Hooks처럼 생성 사전 방지 불가 【시험 포인트】 ▸ CloudFormation Hooks — 리소스 생성 단계에서의 사전 규정 준수 ▸ Proactive vs Detective → 사전 방지 vs 사후 감지의 구분 ▸ Control Tower의 역할 — 조직 차원의 규정 준수 자동화

해설

【핵심 용어】 ▸ AWS Config — 규정 준수 모니터링 ▸ cloudformation-stack-drift-detection-check — 드리프트 상태 규칙 ▸ EventBridge 규칙 — 컴플라이언스 변경 이벤트 감지 【정답 포인트】 ▸ AWS Config 관리 규칙 → CloudFormation 드리프트 자동 확인 ▸ 규정 준수 변경 이벤트 → Config에서 비준수로 변경 감지 시 이벤트 발생 ▸ EventBridge 규칙 → 비준수 이벤트 감지 시 SNS 알림 ▸ 자동화된 감지 및 알림 → Lambda 함수의 드리프트 결과를 별도 조회 불필요 【오답 체크】 (A) SNS 필터 정책 → EventBridge는 드리프트 결과 메시지 발행 안 함, SNS 수신 불가 (B) 두 번째 Lambda → 매시간 API 조회 필요 (매번 호출), 즉각적 알림 아님 (C) GuardDuty → 드리프트 감지용이 아니라 보안 위협 감지 (기능 부적합) 【시험 포인트】 ▸ AWS Config 활용 — 규정 준수 변경을 EventBridge 이벤트로 연동 ▸ 자동화된 이벤트 흐름 — Config 규칙 → 비준수 이벤트 → EventBridge → SNS ▸ 실시간 감지 — 드리프트 발생 → Config 감지 → 즉시 알림

해설

【핵심 용어】 ▸ Amazon Managed Service for Prometheus — Prometheus 기반 모니터링 ▸ Alert Manager — 경보 처리 및 라우팅 ▸ SNS 통합 — 경보 알림 전송 【정답 포인트】 ▸ B) 경보 규칙 생성 → Prometheus에서 모니터링 메트릭 기반 경보 정의 ▸ C) Alert Manager 구성 → SNS 주제로의 경보 라우팅 설정 ▸ D) SNS 정책 수정 → aps.amazonaws.com 서비스 보안 주체에 발행 권한 부여 ▸ 3단계 조합 → 경보 규칙 + Alert Manager + SNS 권한 【오답 체크】 (A) Remote Write URL → Prometheus 메트릭 전송용, 경보 전송 아님 (E) IAM 역할 (AMP) → AMP 자신에 권한 부여 불필요, 서비스 보안 주체로 충분 (F) OIDC + 서비스 계정 → EKS 포드 수준 인증, AMP-SNS 통합에 불필요 【시험 포인트】 ▸ Prometheus Alert Manager — 경보 규칙 정의 및 라우팅 ▸ AWS 서비스 간 통합 — 서비스 보안 주체 기반 권한 부여 ▸ SNS 정책 구성 — 외부 서비스의 메시지 발행 허용

해설

【핵심 용어】 ▸ aws:EC2InstanceSourceVPC — EC2 인스턴스가 속한 VPC ▸ aws:SourceVpc — 요청 출처 VPC ▸ aws:EC2InstanceSourcePrivateIPv4 — EC2 인스턴스의 프라이빗 IP ▸ aws:VpcSourceIp — 요청의 소스 IP 【정답 포인트】 ▸ EC2 인스턴스 자격 증명 제한 → 그 인스턴스에서만 사용 가능하도록 ▸ VPC 검증 → aws:EC2InstanceSourceVPC == aws:SourceVpc (같은 VPC에서만) ▸ IP 검증 → aws:EC2InstanceSourcePrivateIPv4 == aws:VpcSourceIp (같은 인스턴스에서만) ▸ 이중 조건 → VPC + IP 모두 일치할 때만 허용 【오답 체크】 (A) VpcSourceIp와 EC2InstanceSourcePrivateIPv4 비교 → 조건 키 유형 불일치 (C) 허용 목록 방식 → 모든 인스턴스마다 IP 목록 유지 → 관리 복잡 (D) EC2InstanceSourceVPC와 VpcSourceIp 비교 → VPC와 IP 형식 부정합 【시험 포인트】 ▸ EC2 인스턴스 프로필 보안 → 특정 인스턴스로만 자격 증명 제한 ▸ SCP 조건 키 정확성 → 동일 타입의 값끼리만 비교 가능 ▸ 이중 인증 — VPC 위치 + IP 주소로 인스턴스 고유성 보장

해설

【핵심 용어】 ▸ CloudWatch Agent — 메트릭/로그 수집 ▸ Safety Control — Automation 작업 사전 검증 【정답 포인트】 ▸ A (CloudWatch 에이전트): 디스크 공간 메트릭을 수집하여 실시간 모니터링 가능 ▸ D (CloudWatch 경보): Automation 작업의 안전 제어로 역할하여 임계값 이하 시 실행 방지 【오답 체크】 (B) cron 작업은 임시 파일 삭제만 가능하지만 충분한 공간 보장 불가 (C) 로그 스트림 기록은 모니터링용이지 자동 제어 메커니즘 아님 (E) Lambda 함수는 로그 스트림 평가 불가능 (Lambda는 CloudWatch 메트릭 직접 쿼리해야 함) 【시험 포인트】 ▸ Automation 실행 전 조건 확인 → Safety Control ▸ 메트릭 수집 → CloudWatch Agent (설치 필수) ▸ 실시간 임계값 기반 제어 → CloudWatch Alarm ▸ 자동화 오류 방지의 핵심: 사전 예방적 모니터링

해설

【핵심 용어】 ▸ RDS Proxy — 연결 풀링, 연결 재사용으로 DB 부하 감소 ▸ Connection Pooling — 연결 수 제한으로 DB 스트레스 완화 ▸ Lambda Context Reuse — 핸들러 외부 초기화로 성능 향상 【정답 포인트】 ▸ A (RDS Proxy): 리더 엔드포인트로 읽기 부하 분산, 연결 풀 관리 ▸ C (Initialization): 핸들러 외부에서 연결 생성으로 재사용 가능 ▸ E (Proxy 접속): Lambda에서 직접 DB 대신 프록시 사용 【오답 체크】 (B) Lambda 내 풀링은 동시성 인스턴스마다 독립적 풀 생성 → 비효율적 (D) 핸들러 내 열고 닫기는 매 호출마다 연결 오버헤드 발생 (F) 직접 DB 접속은 연결 수 폭증, 프록시 미사용으로 성능 악화 【시험 포인트】 ▸ 고트래픽 Lambda-DB 연동 → RDS Proxy 필수 ▸ 연결 재사용 패턴 → Initialization 외부화 ▸ 읽기 전용 워크로드 → 리더 엔드포인트 + 프록시 조합 ▸ AWS Lambda 성능 최적화의 핵심

해설

【핵심 용어】 ▸ EventBridge — AWS 서비스 이벤트 매칭 및 라우팅 ▸ CloudFormation Events — 스택 상태 변경 알림 ▸ Lambda Trigger — 이벤트 기반 함수 실행 【정답 포인트】 ▸ EventBridge는 CloudFormation 스택 상태 변경(UPDATE_COMPLETE)을 직접 감지 ▸ 이벤트 패턴 매칭으로 특정 상태만 선택적 처리 ▸ EventBridge → Lambda 직접 호출이 가장 간결한 구조 【오답 체크】 (A) Systems Manager Automation은 CloudFormation 업데이트 실행용이지 모니터링용 아님 (B) AWS Config는 규정 준수 상태 검증용, CloudFormation 이벤트 감지 아님 (D) SNS 구독은 EventBridge 없이도 가능하나, Lambda에서 SNS 메시지 파싱 필요 → 복잡 【시험 포인트】 ▸ 이벤트 기반 자동화 → EventBridge 우선 고려 ▸ CloudFormation 상태 감시 → EventBridge의 native integration ▸ 직접 Lambda 호출 → SNS 래퍼 없이 간단한 구조 ▸ UPDATE_COMPLETE 후 액션 → 이벤트 패턴 매칭 활용

해설

【핵심 용어】 ▸ S3 Batch Operations — 대규모 객체 작업 자동화 ▸ Replication Retry — 실패한 복제 재시도 ▸ Event Notifications — S3 상태 변경 알림 【정답 포인트】 ▸ S3 Batch Operations는 복제 재시도를 위해 설계된 기능 ▸ 실패한 객체를 식별하고 일괄 처리로 효율적 재시도 ▸ Lambda는 이벤트 감지 및 배치 작업 트리거 역할 【오답 체크】 (A) EventBridge-Lambda는 개별 객체 처리로 대규모 재시도 비효율 (B) SQS 폴링도 개별 처리, 배치 작업의 효율성 미달 (C) Lambda 직접 처리는 동시성 제한으로 많은 재시도 건 처리 불가 【시험 포인트】 ▸ 대규모 객체 작업 → S3 Batch Operations ▸ 실패한 복제 처리 → Replication Metrics + Lambda + Batch Ops ▸ 비용 효율적 재시도 → 배치 작업의 병렬 처리 ▸ AWS가 제공하는 전문화된 도구 활용의 중요성

해설

【핵심 용어】 ▸ Origin Group — CloudFront의 오리진 장애 조치 ▸ HTTP 5xx Detection — 기본 오리진 장애 감지 ▸ Zero-second RTO — DNS 재쿼리 없는 즉시 장애 조치 【정답 포인트】 ▸ Origin Group이 CloudFront 레이어에서 직접 장애 조치 수행 ▸ HTTP 5xx로 기본 오리진 장애 감지 시 자동 보조 오리진 사용 ▸ CloudFront 캐시가 유지되어 클라이언트 지연 최소화 (0초 RTO) 【오답 체크】 (A) 두 개 배포는 Route 53 TTL 기반 전환 → DNS 재쿼리 지연 발생 (C) Route 53 레코드 TTL 기반이므로 즉시 장애 조치 불가 (DNS 전파 시간) (D) CloudFront Function은 요청 리다이렉트만 가능, 실제 오리진 장애 조치 아님 【시험 포인트】 ▸ 0초 RTO → DNS 우회, CloudFront 레이어 장애 조치 필수 ▸ Origin Group + HTTP 5xx → CloudFront 내장 기능 ▸ 웜 대기 + 자동 장애 조치 → 최소 지연 솔루션 ▸ GET 요청만 처리 → 상태 비저장 이상적

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — 조직 차원 권한 제한 ▸ Permission Set — IAM Identity Center의 권한 템플릿 ▸ Deny Override — Deny가 Allow보다 우선 【정답 포인트】 ▸ AdministratorAccess는 모든 권한 허용 (iam:CreateUser 포함) ▸ Permission Set 내 정책만으로는 Override 불가능 ▸ SCP를 계정 레벨에 적용하면 모든 권한 세트를 제어 가능 【오답 체크】 (A) Permission Set에 Deny 추가 → AdministratorAccess의 Allow가 우선순위 높음 (실패) (B) Permissions Boundary는 Permission Set 아닌 IAM Role/User용 (D) 이미 생성된 사용자만 삭제 → 생성 방지 아님 (사후 대응) 【시험 포인트】 ▸ Permission Set 우회 → SCP 적용 필수 ▸ 조직 관리 → SCP는 가장 강력한 제어 ▸ IAM Identity Center + Organizations → SCP 정책이 최상위 ▸ Deny 기반 정책의 효과적 활용

해설

【핵심 용어】 ▸ ReportBatchItemFailures — 부분 실패 배치 처리 ▸ Dead-Letter Queue — 유효하지 않은 메시지 격리 ▸ Valid Data Priority — 유효한 메시지만 재시도 【정답 포인트】 ▸ D에서 ReportBatchItemFailures 활성화 → 유효한 메시지만 처리 ▸ 배송 못 함 큐로 유효하지 않은 메시지 격리 ▸ 배치 크기 유지 → 처리 효율성과 타임라인 균형 【오답 체크】 (A) 배치 크기 증가 + FIFO 변경 → 지연 악화 (FIFO는 순서 보장으로 느림) (B) 배치 크기 감소는 오버헤드 증가, 처리량 할당량 증가 불가능 (AWS 한정) (C) Transfer Acceleration은 S3 업로드 최적화만, 큐 처리 효율 미달 【시험 포인트】 ▸ 큐의 혼합된 메시지 처리 → DLQ + ReportBatchItemFailures ▸ 유효한 메시지 우선 처리 → 부분 배치 실패 처리 ▸ 타임라인 요구사항 → 유효하지 않은 메시지 早期 분리 ▸ Lambda-SQS 통합의 고급 기능 활용

해설

【핵심 용어】 ▸ Enhanced Fan-Out — 소비자 전용 처리로 지연 감소 ▸ ParallelizationFactor — 단일 샤드의 병렬 배치 처리 ▸ Shard Scaling — 처리량 증가로 지연 완화 【정답 포인트】 ▸ A (Enhanced Fan-Out): 소비자 전용 스트림으로 폴링 지연 제거 ▸ B (ParallelizationFactor): 동일 샤드의 병렬 배치로 처리 가속 ▸ F (Shard 증가): 전체 처리량 확대로 쌓인 메시지 빠르게 처리 【오답 체크】 (C) Reserved Concurrency는 처리량 제한, 지연 증가 가능 (D) 배치 크기 증가 → 처리 지연 시간 증가 (큰 배치는 느림) (E) ReportBatchItemFailures OFF는 실패 배치 전체 재시도 → 지연 악화 【시험 포인트】 ▸ 단일 소비자 + 높은 처리량 → 3가지 레이어 최적화 ▸ 폴링 지연 → Enhanced Fan-Out ▸ 배치 병렬화 → ParallelizationFactor ▸ 처리량 제약 → 샤드 스케일링 ▸ Kinesis 성능 최적화의 완전한 이해

해설

【핵심 용어】 ▸ SCP with aws:SourceIp — IP 기반 API 호출 제어 ▸ Deny Principle — 외부 IP 차단 ▸ Organization Root — 모든 계정에 적용 【정답 포인트】 ▸ SCP의 aws:SourceIp 조건으로 IP 범위 기반 제어 ▸ Deny 문으로 범위 외 IP 자동 차단 ▸ 루트 레벨 적용으로 모든 계정에 동일 정책 강제 【오답 체크】 (A) Network Firewall은 VPC 트래픽 제어, AWS API 호출 제어 불가 (C) GuardDuty는 위협 탐지, IP 기반 API 호출 제어 불가 (D) Allow 기반 SCP는 나중에 추가된 액션 허용 안 함 (유지보수 비효율) 【시험 포인트】 ▸ AWS API 호출 제어 → SCP의 aws:SourceIp 조건 ▸ 조직 차원 정책 → 루트 레벨 적용 ▸ Deny 정책의 우월성 → Allow보다 우선 ▸ IP 기반 액세스 제어의 구현 방식

해설

【핵심 용어】 ▸ CRR (Cross-Region Replication) — 지속적 복제 ▸ S3 Batch Operations — 기존 객체 일괄 처리 ▸ Two-Way Replication — 양방향 동기화 【정답 포인트】 ▸ A: S3 및 배치 작업 서비스 주체 권한 설정 ▸ D: 기존/신규 객체 지속 복제 (CRR 규칙) ▸ F: 기존 객체 일괄 복제 (배치 작업) 조합: 기존 데이터는 배치, 신규는 CRR로 관리 【오답 체크】 (B) AWS Batch는 대규모 컴퓨팅용, S3 복제 오버헤드 (C) 단방향 CRR만으로 양방향 동기화 불가 (E) Bash + CLI는 배치 작업의 효율성 미달, 복제 최적화 아님 【시험 포인트】 ▸ 기존 객체 + 신규 객체 → 서로 다른 메커니즘 필요 ▸ 최소 운영 오버헤드 → CRR + 배치 작업 조합 ▸ 양방향 장애 조치 → 일괄 초기 동기화 필수 ▸ S3 복제 전략의 완전한 이해

해설

【핵심 용어】 ▸ StackSets — 여러 계정에 스택 배포 ▸ Isolation Security Group — 인바운드/아웃바운드 차단 ▸ EventBridge + Lambda — 태그 기반 자동 격리 【정답 포인트】 ▸ A: StackSets로 모든 계정에 격리 리소스 배포 ▸ E: 보안 그룹 교체로 모든 트래픽 차단 (더 완벽한 격리) 【오답 체크】 (B) SCP는 권한 제한용, 격리 메커니즘이 아님 (C) SCP만으로는 ec2:* 전체 차단, 비즈니스 영향 큼 (D) 네트워크 ACL 추가는 불완전, 아웃바운드 차단 미흡 【시험 포인트】 ▸ 다중 계정 격리 → StackSets + EventBridge ▸ 완벽한 격리 → 보안 그룹 교체 (모든 방향 차단) ▸ 자동 응답 → 태그 감지 시 람다 실행 ▸ 운영 효율성 → CloudFormation 템플릿화로 재사용