정답 · 해설

해설

【핵심 용어】 ▸ Region-specific Resources - AMI, 일부 인스턴스 타입, 엔드포인트 등은 리전별로 다릅니다. CloudFormation 템플릿이 특정 리전에서만 유효한 리소스를 참조하면 다른 리전에서 실패합니다. 【정답 포인트】 ▸ us-west-2에서 작동하는 템플릿이 eu-west-1에서 실패하는 경우: (B) AMI ID는 리전별로 다르므로 us-west-2의 AMI ID를 eu-west-1에서 사용할 수 없습니다. (D) 일부 서비스가 모든 리전에서 사용 가능하지 않을 수 있습니다. 이 두 가지가 배포 실패의 일반적인 원인입니다. 【오답 체크】 ▸ (A) IAM 사용자는 전역 리소스이므로 리전에 상관없이 사용 가능합니다. (C) 권한 문제는 템플릿 자체의 문제가 아니라 배포 환경의 문제입니다. (E) CloudFormation은 새 스택 생성 및 기존 스택 업데이트 모두 가능합니다. 【시험 포인트】 ▸ 크로스 리전 CloudFormation 배포 실패 = AMI, 인스턴스 타입, 리전별 서비스를 확인하세요. IAM, 권한, 템플릿 용도는 리전과 무관합니다. 'Choose two' 문제에서 AMI와 Region-specific Service가 답입니다.

해설

【핵심 용어】 ▸ Amazon EFS (Elastic File System) - 여러 가용 영역의 EC2 인스턴스가 동시에 마운트하고 공유할 수 있는 관리형 NFS 파일 시스템. 자동으로 수십 테라바이트까지 확장됩니다. 【정답 포인트】 ▸ 요구 사항: (1) 파일 시스템 인터페이스 (2) 여러 AZ의 인스턴스 공유 (3) 수십 테라바이트까지 확장. EFS는 모든 요구 사항을 완벽하게 충족합니다. Mount Target을 여러 서브넷에 생성하면 각 AZ의 인스턴스가 동일 파일을 공유합니다. 【오답 체크】 ▸ (A) EBS는 단일 AZ에 제한되며 여러 인스턴스 공유가 제한적입니다. (C) EC2 기반 NFS는 단일 인스턴스 장애 시 전체 공유 실패, 확장성 낮음. (D) Storage Gateway는 캐시 메커니즘이며 공유 파일 시스템에 최적화되지 않았습니다. 【시험 포인트】 ▸ 다중 AZ + 파일 시스템 + 확장성 → EFS가 정답입니다. EBS는 단일 인스턴스, S3는 객체 저장소, 자체 NFS는 SPOF(Single Point of Failure) 리스크가 있습니다.

해설

【핵심 용어】 ▸ Geolocation Routing Policy (지리적 위치) - 사용자의 지리적 위치(국가, 대륙)를 기반으로 트래픽을 라우팅합니다. 특정 국가로만 액세스를 제한할 수 있습니다. 【정답 포인트】 ▸ '프랑스 사용자만 액세스' + '향후 다른 국가 추가'는 Geolocation 정책의 정확한 사용 사례입니다. 각 국가마다 별도의 Geolocation 레코드를 설정하면 단순하고 관리하기 용이합니다. 【오답 체크】 ▸ (A) Geoproximity는 지리적 거리 기반이며 특정 국가 제한에 부정확합니다. (C) IP 기반은 프랑스 IP 범위를 개별 등록해야 하므로 관리 복잡도가 높습니다. (D) Geoproximity + IP는 부정확한 조합입니다. 【시험 포인트】 ▸ 특정 국가/지역 제한 → Geolocation Routing. Latency는 성능 최적화, Geolocation은 위치 제한입니다. Geoproximity와 Geolocation을 혼동하지 마세요. Geolocation이 국가별 제한에 더 적합합니다.

해설

【핵심 용어】 ▸ 크로스 계정 S3 액세스: 다른 AWS 계정의 S3 버킷에 접근하기 위한 양쪽 권한 필요 ▸ IAM 정책: Identity 측과 Resource 측의 양쪽 정책 구성 필요 ▸ 최소 권한 원칙: 필요한 최소한의 권한만 부여 【정답 포인트】 ▸ 정답 AB: S3 PutObject 권한은 IAM 사용자 정책 (A)과 S3 버킷 정책 (B) 양쪽에서 명시적으로 허용되어야 함 ▸ 크로스 계정 S3 액세스는 양쪽 계정의 정책이 모두 '허용'이어야만 동작 ▸ IAM 정책만으로는 부족: 버킷 정책도 함께 구성 필요 【오답 체크】 (C) IAM 정책 중복: 이미 선택된 A와 유사하므로 불필요 (D) 루트 사용자 정책: 직접 영향 없음, SysOps 관리자 권한 구성이 먼저 (E) 관리자 계정 루트: SysOps 사용자 권한 문제이지 루트 권한 아님 【시험 포인트】 ▸ 크로스 계정/계정간 리소스 액세스는 항상 양쪽 정책 확인 필수 ▸ S3 버킷 정책의 Principal 지정: 외부 계정의 사용자/역할을 명시적으로 지정 ▸ 실무: 버킷 소유자 확인(BucketOwnerFullControl) 설정도 권장

해설

【핵심 용어】 ▸ AD Connector: 온프레미스 AD와 AWS를 직접 연결하는 경량형 디렉터리 게이트웨이 ▸ IAM Identity Center: 다중 계정/애플리케이션 통합 SSO 관리 ▸ 실시간 동기화: AD Connector는 온프레미스 AD 변경사항을 자동 반영 【정답 포인트】 ▸ 정답 C (AD Connector): Direct Connect 기존 인프라를 활용하는 최적 방식 ▸ AD Connector는 대규모 엔터프라이즈 환경의 표준 솔루션 ▸ 온프레미스 AD의 사용자/그룹이 자동 동기화되어 운영 효율성 극대 ▸ 기존 AD 인프라 재사용으로 비용 최소화 【오답 체크】 (A) Simple AD: 온프레미스 AD와의 트러스트 관계가 제한적, 포리스트 신뢰 구성 복잡 (B) EC2 도메인 컨트롤러: 관리 오버헤드 증가, 고가용성 구성 필요, 운영 비효율 (D) 기본 제공 SSO: 수동 복사/동기화, 변경사항 지속적 관리 필요, 운영 효율 최악 【시험 포인트】 ▸ 온프레미스 AD 통합 → AD Connector가 가장 효율적 ▸ Direct Connect 기존 연결: 네트워크 보안 + 성능 최적 ▸ IAM Identity Center + AD Connector = 엔터프라이즈 SSO의 정답 조합

해설

【핵심 용어】 ▸ 프라이빗 호스팅 영역(Private Hosted Zone): VPC 내 내부 DNS 리소스만 확인 가능 ▸ VPC 연결(Association): 호스팅 영역과 VPC의 관계 설정 필수 ▸ Route 53 Resolver: VPC 내 기본으로 작동하며 추가 설정 불필요 【정답 포인트】 ▸ 정답 A: 프라이빗 호스팅 영역이 새 VPC와 '연결'되어야만 DNS 쿼리 응답 ▸ 호스팅 영역 생성 + 레코드 세트 추가만으로는 부족 ▸ VPC 연결이 없으면 해당 VPC의 인스턴스가 호스팅 영역의 레코드를 조회 불가 ▸ 이것이 마지막 필수 단계(missing piece) 【오답 체크】 (B) 보안 그룹 규칙: Route 53 DNS는 포트 53/UDP로 VPC 내 기본 작동, 추가 설정 불필요 (C) 네트워크 ACL: 프라이빗 호스팅 영역 기능과 무관, 외부 트래픽 제어용 (D) 라우팅 테이블: Route 53 Resolver는 VPC 내 기본 IP(169.254.169.253)로 작동, 명시적 라우팅 불필요 【시험 포인트】 ▸ 프라이빗 호스팅 영역 ≠ 자동 적용 → VPC와의 '명시적 연결' 필수 ▸ DNS 설정에서 가장 놓치기 쉬운 부분: 호스팅 영역 생성 후 VPC 연결 단계 ▸ 실무: 다중 VPC에는 각각 연결 설정 필요

해설

【핵심 용어】 ▸ VPC 흐름 로그(VPC Flow Logs): ENI 수준에서 네트워크 트래픽 수락/거부 기록 ▸ 타임아웃: 일반적으로 네트워크 계층(L3/L4)의 연결 실패 신호 ▸ 계층별 진단: VPN → 보안그룹 → 네트워크ACL → ENI 순서로 확인 【정답 포인트】 ▸ 정답 C: VPC 흐름 로그로 ENI 수준의 REJECT/ACCEPT 상태 직관적 확인 ▸ RDP(포트 3389) 연결 실패의 가장 효율적 진단 방법 ▸ "거부된 트래픽(rejected traffic)" 명시: 패킷이 VPC 경계 내에서 드롭됨을 의미 ▸ 보안 그룹이 '허용'하더라도 네트워크ACL이 거부할 수 있음 → VPC 흐름로그로 확인 【오답 체크】 (A) CloudWatch 로그: 애플리케이션/OS 레벨 로그, VPN 연결 상태와 무관 (B) VPN CloudWatch 로그: VPN 터널 상태만 기록, 목대지 네트워크 도달성 미확인 (D) EC2 Instance Connect: 대증 요법, 근본 원인 규명 불가 【시험 포인트】 ▸ 하이브리드 네트워크 트러블슈팅 → VPC 흐름 로그 필수 ▸ "타임아웃 오류" = 패킷이 목대지에 도달하지 못함 ▸ ENI 수준 추적: 보안그룹/네트워크ACL/라우팅 모든 계층 확인 가능 ▸ 실무: VPC 흐름 로그는 CloudWatch Logs 또는 S3에 저장하여 분석

해설

【핵심 용어】 ▸ 인바운드 경로(Inbound Path): 클라이언트 → 인스턴스 (포트 80/443) ▸ 아웃바운드 경로(Outbound Path): 인스턴스 → 클라이언트 응답 (임시포트 1024-65535) ▸ 계층별 필터링: 보안그룹(stateful) → 네트워크ACL(stateless) → OS방화벽 【정답 포인트】 ▸ 정답 A: 인바운드 80/443 허용 필수 (클라이언트 요청) ▸ 정답 D: 아웃바운드 임시포트(ephemeral) 허용 필수 (응답 전송) - Stateless ACL: 반환 트래픽도 명시적 규칙 필요 - Stateful 보안그룹은 자동으로 응답 트래픽 허용 ▸ 정답 E: OS 레벨 방화벽(iptables, Windows Firewall 등) 설정 확인 ▸ 아웃바운드 OS 방화벽 규칙이 HTTP/HTTPS 응답 차단 가능 【오답 체크】 (B) 보안그룹 아웃바운드: Stateful이므로 자동으로 응답 트래픽 허용 - 역방향 트래픽을 위해 명시적 규칙 불필요 (C) ACL 인바운드 임시포트: 클라이언트 수신 측에서만 필요 - 서버 입장에서는 80/443 인바운드만 필요 (F) AWS WAF: 웹 서버가 아닌 CloudFront/ALB/API Gateway 앞에 배치 - EC2 직접 액세스에는 WAF 미적용 【시험 포인트】 ▸ Stateless vs Stateful 이해 필수 ▸ 아웃바운드 응답 경로: 임시포트 범위(1024-65535) 허용 필수 ▸ 인터넷 접근성 트러블슈팅 순서: 보안그룹 → 네트워크ACL → OS방화벽 ▸ 실무: 공개 IP/탄력적 IP 할당, 인터넷 게이트웨이 라우팅도 확인

해설

【핵심 용어】 ▸ Procstat: CloudWatch 에이전트의 프로세스 상태(실행/중지) 모니터링 플러그인 ▸ StatsD: 커스텀 메트릭 수집용(프로세스 상태 감지 아님) ▸ EventBridge: CloudWatch 로그/메트릭 이벤트를 실시간 캡처 및 트리거 【정답 포인트】 ▸ 정답 A: Procstat + EventBridge 조합 ▸ Procstat: "프로세스 실행 중"을 metric으로 발행 → 상태 변화(0→1 또는 1→0) 감지 ▸ EventBridge: CloudWatch Logs의 프로세스 중지 이벤트를 실시간 포착 ▸ EventBridge가 CloudWatch 알람보다 빠른 반응 시간 제공 【오답 체크】 (B) StatsD: 사용자 정의 메트릭 수집용(ex. 응답시간, 요청 수) - 프로세스 "존재 여부" 모니터링에는 부적합 (C) StatsD + EventBridge: (B)와 동일한 이유로 부적합 (D) Procstat + CloudWatch 알람: 조합은 가능하나 EventBridge가 더 효율적 - 알람은 상태 전환이 필요하지만 EventBridge는 실시간 이벤트 캡처 【시험 포인트】 ▸ CloudWatch 에이전트 플러그인 선택: - Procstat: 프로세스 상태/실행 여부 - StatsD: 애플리케이션 커스텀 메트릭 ▸ 이벤트 기반 자동화: EventBridge가 CloudWatch 알람보다 실시간 반응 ▸ 실무: Procstat 발행 메트릭은 'Alive'(0/1) 형태로 떨어짐

해설

【핵심 용어】 ▸ RDS Proxy: 애플리케이션과 데이터베이스 간 연결 풀링 및 자동 페일오버 관리 ▸ 연결 재사용: 새 TCP/SSL 연결 설정 오버헤드 제거 ▸ 투명한 페일오버(Transparent Failover): 페일오버 중 기존 연결 유지 【정답 포인트】 ▸ 정답 D: RDS Proxy가 페일오버 다운타임 최소화의 가장 효과적 솔루션 ▸ Proxy의 역할: 1. 기존 애플리케이션 연결(미사용)을 풀에 유지 2. 페일오버 발생 시 같은 연결로 새 기본 노드에 라우팅 3. 애플리케이션은 "연결 끊김" 경험 최소화 ▸ 다운타임 단축: 초 → 밀리초 수준으로 감소 【오답 체크】 (A) Multi-Writer 클러스터: MariaDB에서 지원하지 않음 (Aurora만 지원) - 기술적으로 불가능한 솔루션 (B) 유지보수 윈도우 풀링: 페일오버 자체는 방지 불가 - 연결 유지만 해주므로 불완전 (C) ElastiCache 캐시: 캐시 활용은 좋으나 페일오버 다운타임과 무관 - RDS 페일오버 중 캐시도 함께 수용할 수 없음 【시험 포인트】 ▸ 페일오버 다운타임 ≠ RDS 재부팅 또는 유지보수 기간 ▸ RDS Proxy: IAM 인증, SSL/TLS 오프로딩도 추가 이점 ▸ 실무: RDS Proxy는 기존 애플리케이션 코드 변경 최소화 ▸ 소규모에서 대규모까지 효과적: 연결 풀 크기 자동 조정

해설

【핵심 용어】 ▸ CloudTrail 데이터 이벤트: API 호출(GetObject, ListObject 등) 상세 기록 ▸ S3 액세스 로깅: S3 버킷 자체 액세스 로그 (IP, 시간, 작업 기록) ▸ 요청 출처 추적: 클라이언트 IP, IAM 사용자, 권한 정보 필요 【정답 포인트】 ▸ 정답 A (CloudTrail 데이터 이벤트): - LIST API 호출 상세 기록: 호출자 IAM 사용자/역할/IP - eventSource 필터링으로 s3.amazonaws.com 선택 - requestParameters로 버킷명/프리픽스 확인 ▸ 정답 D (S3 서버 액세스 로깅): - 버킷 활성화 후 타겟 버킷에 로그 저장 - RemoteIP/Requester/Operation/Key 기록 - 로그 분석으로 LIST 요청 패턴 파악 【오답 체크】 (B) EventBridge: S3 이벤트 필터링/라우팅용 (후속 조치) - 요청 출처 "조사"하는 로그 제공 불가 (C) AWS Health Dashboard: 계정 레벨 AWS 인프라 상태 - S3 요청 추적과 무관 (E) Trusted Advisor: 보안/성능/비용 모범 사례 권장 - 특정 LIST 요청 추적 기능 없음 【시험 포인트】 ▸ S3 액세스 추적 우선순위: CloudTrail(상세) > S3 로깅(기본) ▸ "어디에서 오는지" = 호출자 IP/IAM 신원 파악 필수 ▸ 실무: CloudTrail은 90일 보관, 장기는 S3에 저장 설정 ▸ 비용 절감: S3 로깅은 무료, CloudTrail 데이터 이벤트는 추가 비용

해설

【핵심 용어】 ▸ VPC 흐름 로그: VPC 경계(ENI) 내의 네트워크 트래픽만 캡처 ▸ 캡처 범위: VPC 내부 ↔ VPC 내부, VPC ↔ 인터넷 ▸ 캡처 불가: VPN/Direct Connect 터널 내 트래픽 【정답 포인트】 ▸ 정답 D: VPC 흐름 로그의 설계상 한계 ▸ 온프레미스 → VPC 트래픽의 경로: 1. VPN/Direct Connect 터널 진입 (암호화) 2. 터널 내에서는 로깅 불가 3. VPC 경계 도착 후 복호화 4. 이 지점부터 VPC 흐름 로그 캡처 ▸ "예상보다 적은 트래픽" = 온프레미스 ↔ VPC 간의 터널 내 트래픽이 누락 【오답 체크】 (A) CloudWatch Logs 제한: 로그 발행 간격 지연 가능하나 - "완전히 누락"되는 것은 아님, 처리 시간 차이 (B) IAM 역할 신뢰 관계 부재: 로그 발행 자체 실패 - 로그가 존재하되 "부분적" 수신은 이유가 아님 (C) VPC 흐름 로그 생성 중: 초기 5~10분 지연 - 검토 시점에 이미 생성 완료 상태 (충분한 시간 경과) 【시험 포인트】 ▸ VPC 흐름 로그 vs CloudTrail: - 흐름 로그: 네트워크 패킷 수준 (OSI L3/L4) - CloudTrail: AWS API 호출 기록 ▸ 하이브리드 네트워크 추적: - VPN 터널 상태 → VPN CloudWatch 로그 - VPC 내 패킷 → VPC 흐름 로그 ▸ 온프레미스 기록과 AWS 로그의 차이 = 암호화 터널 구간

해설

【핵심 용어】 ▸ Domain Users: 기본 제공 AD 그룹 (모든 사용자 포함) ▸ IAM Identity Center 권한 세트: Domain Users와 직접 연계 불가 ▸ 사용자 그룹 관계: 1:N 매핑 필요 (각 그룹 → 계정+역할) 【정답 포인트】 ▸ 정답 A: "새 그룹 생성" 후 할당 ▸ IAM Identity Center의 설계 원칙: 1. AD 전체 Domain Users는 과도하게 광범위 2. 특정 기능/팀별 그룹 생성 필수 3. 각 그룹 → AWS 계정 + 권한 세트 매핑 4. 이를 통해 권한 분리(principle of least privilege) 실현 ▸ 액세스 거부 이유: 권한 세트가 Domain Users와 연결되지 않음 【오답 체크】 (B) AD 시간 동기화: Kerberos 인증 문제일 때만 해당 - "액세스 거부" 에러는 시간 불일치 증상 아님 (C) 계정 제거/재추가: 계정 설정 문제 아님 - IAM Identity Center 권한 배정 문제 (계정 자체는 정상) (D) AD 그룹 권한 수정: IAM Identity Center와 직접 무관 - AD 권한과 AWS 권한은 분리된 개념 【시험 포인트】 ▸ IAM Identity Center 권한 설정 순서: 1. AD에서 권한 세트 배정 그룹 생성 (ex. "AWS-Admins") 2. 그룹에 사용자 추가 3. IAM Identity Center에서 그룹 → 권한 세트 매핑 ▸ Domain Users 직접 사용 불가: 너무 광범위한 권한 ▸ 실무: 팀별/역할별 AD 그룹 설계가 운영 효율성 핵심

해설

【핵심 용어】 ▸ OAI(Origin Access Identity): CloudFront만 S3 버킷 접근 가능하도록 제한 ▸ 직접 접근 차단: S3 버킷 정책으로 OAI가 아닌 요청 거부 ▸ CloudFront 캐싱 효율: 직접 접근 제거로 대역폭/비용 절감 【정답 포인트】 ▸ 정답 D: OAI 설정이 유일한 해결책 ▸ OAI의 작동: 1. CloudFront 배포에서 OAI 생성 2. S3 버킷 정책: OAI만 GetObject 허용 3. 다른 모든 출처의 직접 접근은 "Access Denied" 4. 사용자는 반드시 CloudFront URL을 통해서만 접근 ▸ 보안 + 성능 이점: 콘텐츠 캐싱 강제화 【오답 체크】 (A) S3 버킷 ACL: 공개 vs 비공개 설정만 가능 - CloudFront 선택적 허용 불가능 (B) AWS Firewall Manager: 다중 계정 방화벽 정책 관리 - S3 직접 접근 차단 기능 없음 (C) Route 53 프라이빗 호스팅 영역: VPC 내부 DNS만 지원 - 인터넷 사용자의 S3 직접 접근 차단 불가 【시험 포인트】 ▸ OAI = CloudFront + S3 보안의 필수 조합 ▸ 최신 권장: OAI 대신 OAC(Origin Access Control) 사용 - OAC는 서명 요청(sigv4) 지원으로 더 안전 ▸ 실무: S3 정적 호스팅 + CloudFront의 표준 구성 ▸ 비용: CloudFront 캐싱으로 S3 요청 수 급감

해설

【핵심 용어】 ▸ MFA 조건부 접근: IAM 정책의 조건(Condition) 사용 ▸ aws:MultiFactorAuthPresent: true 조건으로 MFA 필수화 ▸ ec2:StopInstances/ec2:TerminateInstances: 정책에서 제한할 액션 【정답 포인트】 ▸ IAM 정책 구조: { "Effect": "Allow", "Action": [ "ec2:StopInstances", "ec2:TerminateInstances" ], "Resource": "*", "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } } } ▸ 조건: MFA 인증 후에만 위 액션 허용 ▸ 대안: 명시적 거부도 가능 (MFA 없을 때 Deny) 【오답 체크】 - 정책 본문이 비어있어 선택지 판단 불가 - 일반적 오답: (B) Deny 구조: "MFA 없을 때 거부" (보안 강화) (C) 조건 역순: "aws:MultiFactorAuthPresent": "false" (D) 잘못된 액션: ec2:AuthorizeSecurityGroup 등 【시험 포인트】 ▸ 조건부 IAM 정책 핵심: - "Effect": "Allow" + Condition 조합 - 조건 만족 시에만 액션 허용 ▸ 위험 작업 보호: StopInstances, TerminateInstances ▸ 실무: 조직 표준으로 민감한 작업에 MFA 조건 설정

해설

【핵심 용어】 ▸ S3 Transfer Acceleration: CloudFront 엣지 로케이션을 통한 고속 업로드 ▸ 지역별 최적화: 사용자 근처의 엣지에서 AWS 백본 네트워크로 전환 ▸ PutObject 성능: 거리 최소화로 지연 시간 단축 【정답 포인트】 ▸ 정답 A: S3 Transfer Acceleration 활성화 + 엔드포인트 변경 ▸ 작동 원리: 1. 사용자 → 가장 가까운 CloudFront 엣지 (빠른 인터넷) 2. 엣지 → AWS 백본 네트워크 (최적화된 경로) 3. 백본 → us-east-1 S3 버킷 (AWS 내부 고속망) ▸ 효과: 일반 업로드 대비 최대 400% 빠른 성능 ▸ 기존 모바일 앱 변경 최소: 엔드포인트 URL만 변경 【오답 체크】 (B) S3 액세스 포인트: 같은 리전의 S3 접근 간소화 - "다중 리전 액세스 포인트"도 리전 간 복제 필요 - 업로드 성능 개선은 기대하기 어려움 (C) S3 Select: 서버 측 데이터 필터링 - 업로드(PutObject) 성능과 무관 (D) NLB + 리전별 배치: 아키텍처상 불가능 - S3 버킷은 특정 리전에만 존재 - NLB가 s3.us-east-1.amazonaws.com으로 라우팅할 수 없음 【시험 포인트】 ▸ 지역별 업로드 성능 = Transfer Acceleration의 표준 솔루션 ▸ 다운로드의 경우: CloudFront 배포 사용 ▸ 실무: 비용은 GB당 약간의 추가 요금 ▸ 요구사항: S3 버킷은 us-east-1 고정, 만으로도 최적화 가능

해설

【핵심 용어】 ▸ EventBridge ACM 이벤트: ACM에서 자동 발행하는 인증서 상태 변화 이벤트 ▸ 자동화된 모니터링: 커스텀 메트릭 수집 불필요 ▸ 최소 운영 오버헤드: 설정 후 자동 동작 【정답 포인트】 ▸ 정답 B: AWS 서비스 통합 + 자동 이벤트 기반 트리거 ▸ 구성: 1. EventBridge 규칙: 이벤트 소스 = aws.acm 2. 패턴: 인증서 만료 임박(DaysToExpiry < 14) 3. 대상: SNS 주제 4. SNS: 이메일 구독자에게 즉시 알림 ▸ 장점: - ACM이 자동으로 이벤트 발행 (CloudWatch 메트릭 필요 없음) - 실시간 알림 (지연 최소) - 관리 코드 없음 (마이크로서비스 아니어도 됨) 【오답 체크】 (A) CloudWatch 커스텀 메트릭: - Lambda/에이전트로 메트릭 수집 필수 - 추가 구성/관리 오버헤드 증가 (C) CloudWatch 대시보드 + 수동 CLI: - 대시보드는 시각화만 (알림 기능 아님) - "CLI 명령 실행"은 수동 작업 필요 - 자동화 불가능 (D) SMS 신원: - EventBridge는 SNS/SQS 대상 지원 - "SMS 신원" + 이메일 템플릿 조합은 지원 불됨 【시험 포인트】 ▸ 인증서 만료 알림: EventBridge ACM 이벤트가 표준 ▸ "가장 운영 오버헤드가 적은" = 자동화 + 설정 최소화 ▸ ACM → EventBridge → SNS 조합 암기 필수 ▸ 실무: 갱신 자동화(자동 갱신 활성화)도 권장

해설

【핵심 용어】 ▸ EventBridge → Lambda 호출: events.amazonaws.com의 서비스 주체(Principal) 권한 필요 ▸ Lambda 실행 역할(Execution Role): CloudWatch 쓰기 권한 ▸ Lambda 리소스 기반 정책(Resource-based Policy): 호출자 권한 【정답 포인트】 ▸ 정답 C: AWS::Lambda::Permission으로 EventBridge 호출 권한 부여 ▸ 권한 흐름: 1. Lambda 실행 역할(이미 있음): CloudWatch 로그 쓰기 ✓ 2. EventBridge → Lambda 호출 권한(없음) ✗ 3. AWS::Lambda::Permission 추가: events.amazonaws.com → Lambda 호출 허용 ▸ 리소스 기반 정책: { "Effect": "Allow", "Principal": { "Service": "events.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:...function...", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:events:...:rule/..." } } } 【오답 체크】 (A) EventBridge 역할 생성: - EventBridge는 service-linked role 자체로 동작 - EventBridge → Lambda 호출은 Lambda 리소스 정책으로 통제 - EventBridge 역할 추가는 방향 틀림 (B) Lambda 실행 역할: - 이미 CloudWatch 권한 있음 (문제 설명) - 부족한 것은 "EventBridge가 Lambda를 호출할 권한" (D) lambda.amazonaws.com Principal: - Lambda 서비스 자신을 허용하는 것 - EventBridge(events.amazonaws.com)가 아님 【시험 포인트】 ▸ 2가지 권한 분리: - 실행 역할(Execution Role): 함수가 "뭘 할 수 있는가" - 리소스 정책(Lambda::Permission): "누가 함수를 호출할 수 있는가" ▸ EventBridge → Lambda 통합은 리소스 정책 필수 ▸ 실무: CloudFormation으로 자동화 시 두 권한 모두 명시 필요

해설

【핵심 용어】 ▸ 인스턴스 유형 변경: 탄력성 있는 성능 조정 ▸ EBS 지원 인스턴스: 중지/시작 후 유형 변경 가능 ▸ 인스턴스 저장소: 인스턴스 중지 불가능 (마이그레이션 필요) 【정답 포인트】 ▸ 정답 C: Stop → Change Type → Start 순서 ▸ 요구사항 충족: 1. EC2 인스턴스 중지 (메모리 유지) 2. 인스턴스 유형 변경 가능 (EBS 지원 인스턴스) 3. 인스턴스 시작 (기존 데이터/설정 유지) ▸ 가동 중지 시간: 수 분 (유일한 단점) ▸ 장점: 간단하고 비용 효율적 【오답 체크】 (A) VM Import/Export: - 온프레미스 VM을 AWS로 마이그레이션할 때 사용 - 같은 AWS 내 인스턴스 유형 변경에는 오버헤드 과다 - 불필요한 복잡성 추가 (B) 최대 절전 모드 활성화/비활성화: - 최대 절전 모드는 인스턴스 유형 변경 시 도움 안 됨 - 추가 단계가 불필요 - 일부 인스턴스 유형은 최대 절전 지원 안 함 (D) 실행 중 유형 변경: - 기술적으로 불가능 - EBS 지원 인스턴스는 중지 상태에서만 유형 변경 【시험 포인트】 ▸ EBS 지원 vs 인스턴스 저장소: - EBS: 중지 후 유형 변경 가능 - 인스턴스 저장소: 임시 스토리지, 중지 시 데이터 손실 ▸ t3.large → c5.large (컴퓨팅 최적화): - 둘 다 EBS 지원 (변경 가능) ▸ 실무: 변경 전 호환성 확인 필수 (아키텍처/라이선스)

해설

【핵심 용어】 ▸ Lambda 실행 역할: CloudWatch Logs 쓰기 권한(logs:CreateLogGroup/Stream/PutLogEvents) ▸ 기본 동작: print() 또는 console.log()로 CloudWatch에 자동 저장 ▸ 권한 부재: 로그 쓰기 실패 (오류 무시) 【정답 포인트】 ▸ 정답 B: Lambda 함수 역할의 CloudWatch 권한 부족 ▸ Lambda CloudWatch 로깅 flow: 1. 함수 실행 (성공) 2. print/console.log 호출 3. CloudWatch Logs API 호출 (logs:PutLogEvents) 4. 권한 부족 → 로그 쓰기 실패 (조용히 실패) ▸ 증상: 함수는 정상 실행, 로그만 보이지 않음 ▸ 해결: Lambda 실행 역할에 AWSLambdaBasicExecutionRole 연결 【오답 체크】 (A) "로그 메시지 활성화": - Lambda는 기본으로 CloudWatch 로깅 활성화 - 비활성화 옵션은 없음 (C) 예외 발생: - 함수가 예외로 종료되면 에러 메시지는 CloudWatch에 나타남 - 로그 메시지가 "전혀 없는 것"과 다름 (D) 로컬 로그 파일: - Lambda의 /tmp 임시 파일은 CloudWatch와 무관 - stdout/stderr는 자동으로 CloudWatch로 전송 【시험 포인트】 ▸ Lambda 권한 체크 순서: 1. 함수 실행 역할 존재? → 아니면 실행 자체 실패 2. 역할에 필요한 권한? → CloudWatch, 기타 AWS 리소스 ▸ AWSLambdaBasicExecutionRole: 기본 필수 정책 ▸ 실무: Lambda 생성 시 자동으로 역할 생성되지만, 수동 생성 시 권한 추가 필수