정답 · 해설

해설

【핵심 용어】 ▸ Service Catalog — 사전 승인된 제품(CloudFormation 템플릿)만 배포 가능 ▸ Launch Constraint — Service Catalog에서 IAM 역할을 지정하여 배포 권한 제어 ▸ AWS Config — 리소스 구성 drift 지속적 모니터링 【정답 포인트】 ▸ (C) Service Catalog + Launch Constraint 조합: - Service Catalog: "승인된 템플릿만" 강제 - Launch Constraint: 배포 IAM 역할 제한 → 승인되지 않은 수정 방지 ▸ AWS Config Rules: drift 감지 및 자동화된 모니터링 ▸ 이 조합이 governance 요구사항 완벽히 충족 【오답 체크】 (A) CloudFormation 서비스 역할 → "승인된 템플릿만" 강제 불가능. 누구나 직접 배포 가능 (B) (A) 와 동일 문제. Service Catalog 제약 없음 (D) 템플릿 제약(Template Constraint)은 템플릿 선택지 제한. 승인 강제와 무관 EventBridge는 drift 모니터링에 부적절. AWS Config가 표준 【시험 포인트】 Governance: Service Catalog (승인된 제품) + Launch Constraint (배포 제어) + AWS Config (모니터링)

해설

【핵심 용어】 ▸ AWS Trusted Advisor — 서비스 제한(Service Limits) 확인 제공 ▸ Trusted Advisor 이벤트 — 검사 결과가 변경될 때 EventBridge 이벤트 발생 ▸ 최소 개발 노력 — AWS 네이티브 기능 활용 【정답 포인트】 ▸ (B) Trusted Advisor의 "Service Limits" 검사 활용 ▸ Lambda로 Trusted Advisor 새로고침 → EventBridge로 결과 감시 ▸ Trusted Advisor는 서비스 제한을 기본으로 모니터링 ▸ 커스텀 로직 필요 없이 AWS 제공 기능만 조합 ▸ EventBridge + Lambda로 제3자 API 호출 가능 【오답 체크】 (A) 커스텀 Lambda 로직으로 모든 서비스 제한 확인 → 개발 오버헤드 높음 (C) AWS Health는 계정/인프라 건강 상태 감시. 서비스 제한은 감시 안 함 (D) AWS Config 커스텀 규칙 → 서비스 제한 검사 지원 부족. Trusted Advisor가 더 나음 【시험 포인트】 서비스 제한 감시: Trusted Advisor (기본 제공) → 최소 개발 노력

해설

【핵심 용어】 ▸ LaunchConfiguration UserData — EC2 인스턴스 시작 시 실행되는 스크립트 ▸ ECS Agent — EC2에서 실행되는 데몬으로 클러스터에 등록 ▸ 클러스터 레지스트레이션 — ECS_CLUSTER 환경변수로 인스턴스가 참여할 클러스터 지정 【정답 포인트】 ▸ ECS가 올바른 클러스터로 인스턴스를 등록하려면 "클러스터 이름" 정보 필요 ▸ (B) LaunchConfiguration의 UserData에서 ECS_CLUSTER 환경변수 설정 ▸ UserData 스크립트가 EC2 시작 시 실행 → ECS Agent가 올바른 클러스터에 등록 ▸ CloudFormation Intrinsic Functions(!Ref)로 클러스터 이름 전달 가능 ▸ 예: ECS_CLUSTER=!Ref MyECSCluster 【오답 체크】 (A) ECS::Cluster와 ECS::Service 관계 설정 — 클러스터 등록 문제와 무관 (C) EC2::Instance는 직접 인스턴스 정의. 여기서는 Auto Scaling 사용 중 (D) CustomResource + Lambda — 과도한 복잡도. UserData로 충분 【시험 포인트】 ECS 클러스터 등록: LaunchConfiguration UserData에 ECS_CLUSTER 환경변수 설정

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — Organizations 수준 권한 경계 ▸ CloudTrail + CloudWatch Logs — API 활동 실시간 모니터링 ▸ Metric Filter — 특정 패턴의 로그 감지 및 경고 【정답 포인트】 ▸ (A) SCP로 비US 지역의 비전역 서비스 액세스 거부 → "제어" 구현 ▸ (B) CloudTrail + CloudWatch Metric Filter → "모니터링" 구현 ▸ 이 두 조합: (1) 사전 예방 (SCP) + (2) 사후 감지 (CloudTrail) ▸ CloudTrail은 모든 지역에 자동 적용 가능 (Organizations 수준) ▸ Metric Filter로 비US 지역 활동 즉시 감지 및 경고 【오답 체크】 (C) Lambda + EventBridge → 시간 기반 폴링. "가능한 한 빨리" 경고 요구사항과 맞지 않음 (D) Amazon Inspector는 보안 취약점 스캔용. 지역 제약 감시 목적 아님 (E) aws:RequestedRegion SCP는 좋지만, "새 지역에 자동 활성화" 불가능. SCP 계층이 정해져야 함 【시험 포인트】 지역 제어 + 감시: SCP (차단) + CloudTrail (감시) = 완벽한 Governance

해설

【핵심 용어】 ▸ CloudWatch Logs Insights — CloudWatch 로그 데이터의 쿼리 및 시각화 ▸ CloudWatch Dashboard 통합 — 위젯으로 다양한 데이터 소스 시각화 ▸ 운영 효율성 — 가장 적은 설정 단계 【정답 포인트】 ▸ (A) CloudWatch Logs Insights가 CloudWatch Dashboard와 가장 간단한 통합 ▸ 애플리케이션 → CloudWatch Logs (JSON) → Insights 쿼리 → 원형 차트 생성 ▸ 대시보드 내에서 Insights 쿼리 결과를 직접 위젯으로 표시 가능 ▸ 추가 서비스(S3, Lambda, DynamoDB, X-Ray) 불필요 ▸ 가장 간단한 아키텍처 = 최소 운영 오버헤드 【오답 체크】 (B) S3 + Athena 쿼리 → CloudWatch와 비통합. 외부 도구 필요 (C) X-Ray는 분산 추적용. 거래 데이터 분석에 부적절 (D) Lambda + DynamoDB → 불필요한 복잡도. Insights만으로 충분 【시험 포인트】 CloudWatch 대시보드 통합: CloudWatch Logs Insights (네이티브 통합) > 외부 도구

해설

【핵심 용어】 ▸ IAM Access Analyzer — 계정에서 사용 중인 AWS 서비스 식별 ▸ FullAWSAccess SCP — 기본적으로 모든 서비스 허용. 명시적으로 거부해야 함 ▸ SCP 계층 — OU별 정책이 더 세밀한 제어 가능 【정답 포인트】 ▸ (A) 완벽한 솔루션: 1. IAM Access Analyzer로 "현재 활성화된 서비스" 식별 2. 그 서비스들만 Allow하는 SCP 작성 (화이트리스트 방식) 3. 새 OU 생성 → 계정 이동 → SCP 적용 4. 기본 FullAWSAccess SCP 제거 → 명시적 Allow만 남음 ▸ 이 방식이 "현재 활성화된 서비스만" 사용 요구사항을 정확히 충족 【오답 체크】 (B) 거부 방식(Deny) → 새로운 서비스 추가 시 자동으로 허용됨. 보안 위험 (C) 루트에 SCP 적용 → 모든 계정에 영향. OU 구조화 없음 (D) 관리 계정에 SCP 적용 → 잘못된 계층. SCP는 OU에 적용해야 효과적 【시험 포인트】 서비스 제한: FullAWSAccess 제거 + Allow-only SCP = 화이트리스트 기반 제어

해설

【핵심 용어】 ▸ CloudTrail 이벤트 → EventBridge — CloudTrail이 S3가 아닌 EventBridge로 이벤트 발송 ▸ EC2 RunInstances 이벤트 — EC2 인스턴스 생성 시 발생 ▸ 1시간 이내 태그 지정 — 거의 실시간 Lambda 실행 필요 【정답 포인트】 ▸ (D) CloudTrail → EventBridge → Lambda 패턴이 정답: 1. CloudTrail에서 "ec2:RunInstances" 이벤트 감지 2. EventBridge 규칙이 EC2 이벤트 소스 구성 3. CloudTrail에서 제공하는 이벤트 패턴 매칭 4. Lambda 함수가 거의 실시간으로 호출 → 태그 추가 ▸ S3 기반이 아닌 EventBridge 기반이 더 빠른 반응 【오답 체크】 (A) S3 ObjectTagging 이벤트 → CloudTrail 로그가 이미 생성된 후의 이벤트. 너무 늦음 (B) S3 이벤트 알림 → (A) 와 동일 문제. S3에 저장 후의 이벤트 감지 (C) 매시간 폴링 → 1시간 대기 시간. "1시간 이내" 요구사항 미충족 위험 【시험 포인트】 CloudTrail 실시간 감시: EventBridge 규칙 (직접 이벤트 감지) > S3 알림 (지연)

해설

【핵심 용어】 ▸ ECR VPC Endpoint — 프라이빗 연결로 ECR 액세스 (인터넷 게이트웨이 불필요) ▸ 교차 계정 ECR 액세스 — 리포지토리 정책으로 다른 계정의 assume role 허용 ▸ S3 Gateway Endpoint — ECR이 레이어 데이터 다운로드 시 필요 【정답 포인트】 ▸ (D) 완벽한 솔루션 조합: 1. ECR VPC Endpoint — 프라이빗 연결 보장 2. S3 Gateway Endpoint — ECR이 이미지 레이어 S3에서 내려받을 때 필요 3. 리포지토리 정책 (주 계정) — 별도 계정의 ECS task role 허용 4. 프로덕션 task execution role — ECR 이미지 다운로드 권한 ▸ 프라이빗 연결 + 교차 계정 액세스 모두 충족 【오답 체크】 (A) 별도 계정에 ECR 생성 → 개발 이미지가 주 계정에 있음. 동기화 복잡도 증가 (B) VPC Endpoint 없음 → 인터넷 게이트웨이 필요. "프라이빗 연결" 요구사항 위반 (C) 이미지 복제 → 별도 계정에 복사본 생성. 저장소 중복, 비용 증가 【시험 포인트】 교차 계정 ECR: VPC Endpoint (프라이빗) + Repository Policy (교차 계정) + S3 Endpoint

해설

【핵심 용어】 ▸ AWS Config — 리소스 구성 상태 지속적 모니터링 및 자동 복구 ▸ Config Rule + Remediation — 규정 위반 자동 교정 ▸ "기존 및 새 VPC" — CloudFormation 스택이 아닌 다른 방식 생성도 포함 【정답 포인트】 ▸ (C) AWS Config가 유일한 완벽한 솔루션: 1. Config 활성화 → VPC 리소스 지속적 모니터링 2. 커스텀 규칙 또는 AWS 관리형 규칙으로 "VPC flow logs enabled" 확인 3. Auto Remediation → 흐름 로그 비활성 VPC 자동 활성화 ▸ CloudFormation이 아닌 다른 방식으로 생성된 VPC도 자동 감시/수정 ▸ "모든 IAM 사용자" 및 "모든 새 VPC" 요구사항 충족 【오답 체크】 (A) CloudFormation 스택 → CloudFormation이 아닌 다른 방식 생성 VPC는 미포함 (B) SCP 거부 정책 → "흐름 로그 비활성화 방지"는 할 수 있지만 "자동 활성화" 불가능 (D) IAM 정책 거부 → "수정 거부"만 가능. 기존 비활성 상태 VPC 해결 안 됨 【시험 포인트】 자동 규정 준수: AWS Config (지속 모니터링 + 자동 복구) = 완벽한 감시

해설

【핵심 용어】 ▸ SAML Assertion — IdP에서 AWS로 전달되는 사용자 정보 (팀명 포함 가능) ▸ 세션 태그 — IAM 역할 세션의 태그 기반 조건 검증 ▸ 리소스 태그 매칭 — Principal Tag와 Resource Tag 비교로 접근 제어 【정답 포인트】 ▸ (A) SAML assertion → access-team 값 전달 → IAM 역할 신뢰 정책에서 세션 태그로 설정 ▸ (D) CodeCommit 리포지토리에 access-team 태그 추가 (팀명 설정) ▸ (E) SCP 또는 IAM 권한 경계(F) 중 하나로 태그 매칭 조건 구현 - Principal Tag와 Resource Tag 비교: ${aws:PrincipalTag/access-team} == ${aws:ResourceTag/access-team} - 일치하는 팀의 리포지토리만 수정 가능 ▸ 이 조합으로 팀별 리포지토리 접근 제어 가능 【오답 체크】 (B) 승인 규칙 템플릿 → 모든 리포지토리에 동일하게 적용. 팀별 제한 불가능 (C) 승인 규칙 + 조건 → (B) 와 유사하게 일괄 적용. 팀 식별 불가능 (F) 권한 경계 대신 (E) SCP 선택이 Organizations 차원 제어로 더 효율적 【시험 포인트】 팀별 접근 제어: SAML (팀 정보) → 세션 태그 → 리소스 태그 매칭 → SCP/권한 경계 (E)

해설

【핵심 용어】 ▸ CloudWatch Logs — 실시간 로그 저장 및 모니터링 ▸ Metric Filter — 로그 패턴 감지 및 메트릭 생성 【정답 포인트】 ▸ 직접 통합 → CloudWatch Logs는 AWS WAF 로그를 기본 지원 ▸ 최소 오버헤드 → 별도 서비스 배포 없이 기본 기능 활용 ▸ 메트릭 필터 → 로그 패턴 매칭으로 경보 자동 생성 【오답 체크】 (B) OpenSearch는 추가 클러스터 생성, Firehose 스트림 구성 필요 → 높은 오버헤드 (C) Lambda 함수, S3, SNS 등 여러 서비스 조합 → 복잡한 아키텍처 (D) Athena 설정 필요하며 수동 SQL 쿼리 작성 → 자동화 부족 【시험 포인트】 ▸ AWS 로깅 통합 이해 — WAF의 네이티브 CloudWatch 지원 ▸ 최소 오버헤드 선택 — 기존 서비스로 충분한 경우 우선 ▸ Metric Filter 활용 — 패턴 기반 자동 경보 구성

해설

【핵심 용어】 ▸ CodeBuild — 소스 코드 빌드 및 테스트 ▸ CodeDeploy — 배포 자동화 서비스 ▸ runOrder — 스테이지 내 작업 실행 순서 정의 【정답 포인트】 ▸ 단위 테스트는 빌드 후 실행 → Build 스테이지에 포함 ▸ CodeBuild는 단위 테스트 지원 → CodeDeploy와 달리 빌드 및 테스트 수행 ▸ runOrder 2 → 기존 빌드(runOrder 1) 후 테스트 실행, 테스트 실패 시 자동 중단 【오답 체크】 (A) CodeDeploy는 배포 도구 → 단위 테스트 적합하지 않음 (C) 테스트를 Deploy 스테이지에 배치 → 이미 배포된 후 테스트 → 요구사항 미충족 (D) Deploy 스테이지 테스트 → 배포 후 검증 → 불필요한 배포 발생 【시험 포인트】 ▸ CI/CD 도구 역할 이해 — CodeBuild는 빌드 테스트, CodeDeploy는 배포 ▸ 파이프라인 흐름 — 테스트 통과 후 배포 순서 중요 ▸ runOrder 활용 — 같은 스테이지 내 순차 실행 제어

해설

【핵심 용어】 ▸ aws:SecureTransport — HTTPS/SSL 전송 여부 조건 ▸ Conformance Pack — AWS Config 규정 준수 자동 검사 ▸ Systems Manager Automation — 자동 수정 작업 【정답 포인트】 ▸ S3 전송 암호화 조건 → aws:SecureTransport 확인 ▸ SecureTransport false → HTTP 비암호화 연결 거부 ▸ Conformance Pack + Automation → 감지 + 자동 정책 적용 ▸ 조직 전체 적용 → AWS Config 조직 단위 배포 【오답 체크】 (A/B) Network Firewall은 포트 기반 필터링 → 특정 S3 요청 식별 어려움, 과도한 구성 (D) KMS 암호화 여부 확인 → 전송 암호화와 별도, SecureTransport와 무관 【시험 포인트】 ▸ 전송 중 암호화 정책 → aws:SecureTransport 조건 키 ▸ AWS Config 조직 관리 → Conformance Pack으로 규정 준수 자동화 ▸ Systems Manager Automation → 감지된 비준수 자동 수정

해설

【핵심 용어】 ▸ 최소 권한 원칙 — 필요한 최소 권한만 부여 ▸ Resource 제한 — 특정 리소스만 대상으로 제한 ▸ Action 제한 — 필요한 작업만 허용 【정답 포인트】 ▸ Resource "*" → 모든 리소스 대상 → 과도하게 허용적 ▸ arn:aws:ec2:*:*:instance/* → EC2 인스턴스만 제한 ▸ ec2:StopInstances → 중지 작업만 허용 ▸ 태그 기반 조건 → ec2:ResourceTag 조건으로 NonProduction만 대상 【오답 체크】 문제에서 조건부 표현식 옵션(A, C, D, F)의 구체적 내용이 누락되어 명확한 검증 불가능. 다만 정책 최소화를 위해서는: - Resource 범위 축소 (B 필수) - Action 범위 축소 (E 필수) - TagBased 조건 추가 (미제시 옵션 필요) 【시험 포인트】 ▸ IAM 권한 최소화 — Resource와 Action 모두 제한 ▸ 와일드카드 제거 — "*" 대신 명확한 ARN 지정 ▸ 태그 기반 접근 제어 — 특정 태그 값으로만 허용

해설

【핵심 용어】 ▸ Batch Write — 여러 레코드를 한 번에 작성 ▸ Multi-Measure Record — 한 레코드에 여러 메트릭 저장 ▸ Memory Store — 최근 데이터 저장 (고속) ▸ Magnetic Store — 장기 데이터 저장 (저가) 【정답 포인트】 ▸ A) 배치 쓰기 → 0.1초마다 5개 메트릭의 높은 빈도 처리 효율화 ▸ D) 다중 측정값 레코드 → 5개 메트릭을 단일 레코드로 통합, 저장 최적화 ▸ F) Memory Store < Magnetic Store → 일일 쿼리 데이터는 최근 데이터 → Memory Store에서 빠르게 조회 【오답 체크】 (B) 개별 쓰기 → API 호출 오버헤드 증가 → 성능 저하 (C) 단일 측정값 → 5개 메트릭 = 5개 레코드 → 저장 비효율, 쿼리 느림 (E) Memory Store > Magnetic Store → 최근 데이터도 느린 저장소로 이동 → 쿼리 지연 【시험 포인트】 ▸ Timestream 최적화 — 배치 쓰기와 다중 측정값 활용 ▸ 저장소 계층 선택 — 쿼리 패턴에 맞춘 보존 기간 설정 ▸ 대용량 시계열 데이터 처리 → 기록 빈도와 저장소 설계의 균형

해설

【핵심 용어】 ▸ cfn-init/cfn-hup — CloudFormation 메타데이터 변경 모니터링 및 적용 ▸ State Manager — Systems Manager 정책 자동 적용 및 유지 ▸ 스택 업데이트 반영 → 실행 중 인스턴스 자동 갱신 【정답 포인트】 ▸ B) cfn-hup 모니터링 → 메타데이터 변경 감지 시 자동 적용 (지속적 모니터링) ▸ E) State Manager → SSM 문서로 정의된 설정을 인스턴스에 지속 적용 ▸ 두 방식 모두 이미 실행 중인 인스턴스에 변경 반영 가능 【오답 체크】 (A) MIME 형식 + scripts-user → CloudFormation 메타데이터 변경 감지 없음 (C) Auto Scaling 그룹 → 새 인스턴스만 배포, 기존 실행 중 인스턴스 미반영 (D) Run Command 일회성 → 지속적 모니터링 부족, 한 번의 실행만 수행 【시험 포인트】 ▸ CloudFormation 메타데이터 적용 → cfn-init/cfn-hup 조합 ▸ 지속적 구성 관리 → State Manager로 정책 자동 유지 ▸ 실행 중 인스턴스 갱신 — 새 배포가 아닌 기존 인스턴스 변경 관리

해설

【핵심 용어】 ▸ OIDC IdP — OpenID Connect 기반 외부 인증 제공자 ▸ AssumeRoleWithWebIdentity — OIDC 토큰으로 임시 자격 증명 획득 ▸ 신뢰 정책 — OIDC 제공자로부터의 역할 전환 허용 【정답 포인트】 ▸ B) IAM IdP 생성 → OIDC 제공자 등록 (URL, 대상, 서명 정보) ▸ D) 신뢰 정책 구성 → auth.company.com:aud로 조건 지정 (정확한 IdP 출처 검증) ▸ E) AssumeRoleWithWebIdentity → OIDC 토큰으로 AWS 역할 전환, S3 API 호출 【오답 체크】 (A) IAM Identity Center → AWS 관리형 SSO, 기존 외부 OIDC와 다른 패턴 (C) sts.amazon.com:aud → AWS 서비스 조건 키, OIDC IdP 조건 아님 (F) GetFederationToken → 동일 계정 리소스 공유용, OIDC 외부 제공자 적합하지 않음 【시험 포인트】 ▸ OIDC 연동 흐름 — 외부 IdP 등록 → IAM 역할 신뢰 정책 → AssumeRoleWithWebIdentity ▸ 조건 키 정확성 — IdP 도메인 기반 조건 (auth.company.com:aud) ▸ Federated 인증 패턴 — 웹 애플리케이션에서 OIDC 토큰 획득 후 AWS 역할 전환

해설

【핵심 용어】 ▸ Control Tower Detective Control — 규정 준수 상태 자동 감지 ▸ EventBridge — AWS 이벤트 기반 자동화 ▸ 운영 효율성 — 자동화된 감지 및 알림 【정답 포인트】 ▸ AWS Control Tower 탐지 제어 → RDS 암호화 상태 자동 모니터링 ▸ EventBridge 규칙 → 비준수 이벤트 감지 시 자동 SNS 알림 ▸ 최소 운영 오버헤드 → 기존 Control Tower 기능 활용 ▸ 조직 전체 적용 → 모든 계정에 자동 적용 【오답 체크】 (B) Lambda + CloudFormation → 수동 배포 및 관리 필요, Control Tower 기능 미활용 (C) 사용자 정의 Config 규칙 → 모든 계정 개별 구성 필요, 운영 복잡도 높음 (D) EC2 인스턴스 기반 → 자체 인프라 유지 비용, 자동화 부족, 지속 모니터링 어려움 【시험 포인트】 ▸ AWS Control Tower 활용 — 내장 규정 준수 제어 우선 ▸ EventBridge 통합 — 이벤트 기반 자동 응답 ▸ 조직 차원의 거버넌스 — Control Tower로 일관된 규정 준수 적용

해설

【핵심 용어】 ▸ IAM Roles Anywhere — 온프레미스에서 AWS IAM 역할 사용 ▸ External Connection — CodeArtifact의 외부 퍼블릭 리포지토리 연결 ▸ Upstream Repository — 의존성 패키지 소스 【정답 포인트】 ▸ B) IAM Roles Anywhere → 온프레미스 CI/CD에서 AWS 자격 증명 직접 사용 (최소 오버헤드) ▸ D) External Connection + Upstream → CodeArtifact가 퍼블릭 리포지토리 자동 캐싱 및 제공 ▸ 온프레미스 파이프라인에서 AWS 서비스 직접 통합 【오답 체크】 (A) AMI 생성 및 Import/Export → 추가 변환 단계, 복잡한 프로세스 (C) S3 + Lambda 중개 → 불필요한 추가 서비스, 운영 오버헤드 증가 (E) Downstream 연결 → 외부 리포지토리가 CodeArtifact를 향함 (역방향), 적합하지 않음 【시험 포인트】 ▸ IAM Roles Anywhere — 온프레미스에서 AWS 서비스 직접 액세스 ▸ CodeArtifact External Connection — 퍼블릭 저장소 의존성 자동 관리 ▸ 최소 운영 오버헤드 — 기존 파이프라인 최소 변경으로 마이그레이션

해설

【핵심 용어】 ▸ Canary 배포 — 10% 트래픽에서 10분 실행 후 확대 ▸ 자동 롤백 — CloudWatch 경보 기반 자동 복구 ▸ 최소 고객 영향 → Canary 전략 필수 【정답 포인트】 ▸ LambdaCanary10Percent10Minutes → 처음 10%만 배포, 10분 모니터링 ▸ 자동 롤백 → 경보 임계값 도달 시 자동으로 이전 버전 복구 ▸ 운영 효율성 → 수동 개입 없이 자동 대응 【오답 체크】 (A) LambdaAllAtOnce → 모든 Lambda 동시 배포 → 오류 발생 시 전체 고객 영향 (C) 수동 롤백 → 운영자 개입 필요 → 대응 시간 지연 → 고객 영향 증가 (D) LambdaCanary + 수동 롤백 → Canary는 있지만 수동 대응 → 효율성 저하 【시험 포인트】 ▸ Lambda 배포 전략 — Canary는 위험 최소화, AllAtOnce는 빠른 배포 ▸ 자동 롤백 → CloudWatch 경보 + CodeDeploy 자동 복구 ▸ 점진적 배포 → 오류 영향을 제한하면서 신속하게 복구