정답 · 해설

해설

【핵심 용어】 ▸ CloudWatch 에이전트: 메트릭 발행을 위해 IAM 권한 필수 ▸ 인스턴스 프로필: EC2가 AWS 서비스에 인증할 수 있게 해주는 메커니즘 ▸ mem_used_percent: 커스텀 메트릭 (기본 모니터링 미포함) 【정답 포인트】 ▸ 정답 B: IAM 인스턴스 프로필 + CloudWatch 권한 ▸ 문제 분석: 1. 에이전트 설치 ✓ 2. 에이전트 실행 ✓ 3. 메트릭 발행 안 됨 ✗ → IAM 권한 부족 ▸ 해결 방법: 1. CloudWatch 권한 포함한 IAM 역할 생성 - cloudwatch:PutMetricData - ec2messages:GetMessages - ssm:GetParameter 2. 역할을 인스턴스 프로필로 연결 3. EC2 인스턴스에 프로필 할당 ▸ 결과: 에이전트가 CloudWatch API 호출 가능 【오답 체크】 (A) 자세한 모니터링: - 기본 메트릭(CPU, 네트워크)의 수집 간격만 변경 - mem_used_percent는 커스텀 메트릭 (에이전트로만 수집) - 도움 안 됨 (C) 프라이빗 서브넷으로 마이그레이션: - 에이전트가 CloudWatch에 메트릭 발행할 수 있으면 위치 무관 - 근본 원인(IAM 권한)과 무관 - 추가 비용만 발생 (D) IAM 사용자 액세스 키: - 보안 안티패턴 (자격증명 노출) - 인스턴스 프로필이 표준 방식 - 코드에 자격증명 하드코딩 위험 【시험 포인트】 ▸ EC2 + AWS 서비스 통합 = 인스턴스 프로필 필수 ▸ CloudWatch 에이전트: - 자세한 모니터링 ≠ 커스텀 메트릭 - 커스텀 메트릭(메모리, 디스크 등)은 에이전트 필수 ▸ INSUFFICIENT_DATA: 데이터 발행 실패 신호 ▸ 실무: CloudWatch 에이전트 배포 시 IAM 권한 먼저 설정

해설

【핵심 용어】 ▸ Content-MD5: 파일 무결성 검증용 MD5 해시값 ▸ 데이터 손상 감지: 전송 중 손상 여부 확인 ▸ 요청 헤더: Content-MD5는 HTTP 헤더로 전송 【정답 포인트】 ▸ 정답 B: Content-MD5 헤더로 무결성 검증 ▸ 작동 원리: 1. 클라이언트: 파일의 MD5 해시 계산 2. 요청: Content-MD5 헤더에 Base64 인코딩 해시 포함 3. S3: 수신한 객체의 MD5 계산 4. 비교: 클라이언트 해시 == S3 해시 5. 불일치 → 400 Bad Request (InvalidDigest) ▸ 효과: 전송 중 손상 탐지 및 거부 【오답 체크】 (A) Content-Disposition: - 파일 다운로드 시 브라우저 동작 지정 (인라인/첨부) - 무결성 검증과 무관 (C) x-amz-object-lock-mode: - Object Lock 정책 설정 - 객체 유지/삭제 보호용 (데이터 손상 감지 아님) (D) x-amz-server-side-encryption-customer-algorithm: - 고객 관리 암호화 키 지정 - 무결성 검증이 아님 【시험 포인트】 ▸ S3 업로드 무결성 검증 메커니즘: - Content-MD5: 기본 방법 (권장) - ETag: S3가 응답에 포함 (다운로드 검증용) ▸ 실무: 대용량 파일 → multipart upload시 각 부분별 MD5 확인 ▸ 보안: HTTPS 사용 권장 (HTTP는 네트워크 감청 위험)

해설

【핵심 용어】 ▸ ALB 액세스 로그(ALB Access Logs): ALB를 통과하는 모든 요청에 대한 세부 정보(송수신 바이트, 클라이언트/대상 IP, 포트 등) 기록 ▸ Amazon Athena: S3에 저장된 데이터를 SQL로 쿼리하는 서버리스 분석 서비스 【정답 포인트】 ▸ 정답 AC: ALB의 액세스 로깅을 S3에 저장 (A)하면 상세한 통신 데이터가 기록되고, Athena로 S3 로그를 쿼리 (C)하여 received_bytes와 sent_bytes를 대상 포트(target_port)로 그룹화하면 각 대상별 데이터 전송량을 집계할 수 있습니다. ▸ "대상 포트"는 리스닝 대상의 실제 서비스 포트를 의미하므로 올바른 그룹화 기준입니다. 【오답 체크】 ▸ (B) CloudWatch 에이전트는 EC2 인스턴스 내부 메트릭(CPU, 메모리, 디스크) 수집용이며, ALB의 송수신 바이트 추적에는 부적합합니다. ▸ (D) 클라이언트 포트(client_port)로 그룹화하면 동일한 클라이언트에서 여러 포트 사용 시 데이터가 분산되어 대상 그룹별 통계를 얻을 수 없습니다. ▸ (E) ProcessedBytes는 ALB 수준의 집계 메트릭으로 개별 대상별 상세 데이터를 제공하지 않습니다. 【시험 포인트】 ▸ ALB 로깅 구성 및 S3 저장 ▸ Athena SQL에서 ALB 로그 스키마 이해 ▸ 그룹화 기준(대상 포트 vs 클라이언트 포트) 구분 ▸ CloudWatch 메트릭과 로그 분석의 차이

해설

【핵심 용어】 ▸ AWS Systems Manager Session Manager: 브라우저/CLI를 통한 EC2/온프레미스 접근(SSH/RDP 불필요), 모든 세션 자동 기록 ▸ CloudWatch Logs Metric Filter: 특정 로그 패턴을 감지하여 메트릭 생성 【정답 포인트】 ▸ 정답 C: Session Manager는 IAM 기반 접근 제어, 자동 세션 로깅(CloudWatch Logs), 감사 추적 제공이 모두 통합되어 있습니다. ▸ 개별 EC2에 에이전트 설치 불필요(회사 정책 일관성 유지) ▸ 메트릭 필터로 보안 이벤트(명령어 패턴 감지) 및 경보 설정 가능 ▸ "가장 운영 효율적"이라는 요구사항: 중앙 관리, 자동 로깅, 최소 인프라 【오답 체크】 ▸ (A) 각 인스턴스마다 로깅 구성 필요(관리 복잡도 높음), Athena는 임시 쿼리용(실시간 경보 부족) ▸ (B) 배스천 호스트 구성/관리 오버헤드, 단일 장애점, 스케일링 어려움 ▸ (D) Run Command는 일회성 명령 실행용이지, 대화형 세션 기록용 아님 【시험 포인트】 ▸ Session Manager의 대화형 세션 자동 로깅 기능 ▸ 중앙 관리식 접근 제어(IAM) ▸ 감사 및 규정 준수 ▸ 배스천/Run Command와의 차이

해설

【핵심 용어】 ▸ SAML 2.0(Security Assertion Markup Language): XML 기반 페더레이션 표준, IdP가 사용자 정보를 SP(Service Provider)에 전달 ▸ 메타데이터: 인증서, 엔드포인트, 바인딩 정보 등 SAML 연결 구성 【정답 포인트】 ▸ 정답 AB: ▸ (A) IAM Identity Center SAML 메타데이터: Identity Center가 IdP에 자신을 식별하는 데 필요(SP 역할) ▸ (B) IdP 메타데이터 + 공개 X.509 인증서: Identity Center가 IdP의 SAML 응답을 검증하기 위해 필수(IdP 서명 확인) ▸ URL/DNS 기반 접근이므로 IP 주소 불필요 【오답 체크】 ▸ (C) IdP IP 주소 불필요: SAML은 HTTP(S) 메타데이터 URL 기반, DNS로 해석됨 ▸ (D) 루트 액세스 불필요: IAM Identity Center 설정은 IAM 권한으로 충분 ▸ (E) 멤버 계정 권한 불필요: 페더레이션 설정은 관리 계정에서만 수행(조직 전체 적용) 【시험 포인트】 ▸ SAML 2.0 페더레이션 기본 개념 ▸ IdP와 SP 메타데이터 교환 프로세스 ▸ 인증서 기반 신뢰 검증 ▸ Control Tower 환경에서의 중앙 ID 관리

해설

【핵심 용어】 ▸ CloudWatch 에이전트: EC2 인스턴스에서 로그/메트릭을 수집하여 CloudWatch로 전송하는 소프트웨어 ▸ IAM 역할(EC2 Instance Profile): EC2가 AWS 서비스(CloudWatch Logs)에 접근할 때 사용하는 임시 자격증명 【정답 포인트】 ▸ 정답 B: ▸ 수동 설치 필요: CloudWatch는 자동 에이전트 설치 미지원, 관리자가 직접 설치 구성 ▸ IAM 역할 필수: EC2 인스턴스가 CloudWatch Logs에 로그 쓰기(logs:CreateLogGroup, logs:PutLogEvents 등) 수행 시 임시 자격증명 필요 ▸ AWS 모범 사례: EC2 인스턴스에 직접 액세스 키 저장 금지, 역할 사용 권장 【오답 체크】 ▸ (A) AWS 콘솔 구성만으로는 에이전트 자동 설치 안 됨(수동 설치 필수) ▸ (C) IAM 사용자: 개별 자격증명 관리 복잡, 장기 액세스 키 보안 위험(모범 사례 위배) ▸ (D) 보안 그룹: 인바운드/아웃바운드 트래픽 제어용(CloudWatch로의 HTTPS 443 트래픽은 AWS 내부이므로 보안 그룹 불필요) 【시험 포인트】 ▸ CloudWatch 에이전트 수동 설치의 필요성 ▸ EC2 인스턴스 IAM 역할(Instance Profile) 용도 ▸ IAM 역할 vs IAM 사용자 차이 ▸ AWS 보안 모범 사례(장기 자격증명 회피)

해설

【핵심 용어】 ▸ CloudFormation 스택 삭제 정책(DeletionPolicy): 스택 삭제 시 리소스 처리 방식 지정(Delete/Retain/Snapshot) ▸ RetainExceptionOnDelete: 특정 리소스만 보관하고 나머지는 삭제 【정답 포인트】 ▸ 정답 C: Stack 삭제 재시도 시 DeletionPolicy="Retain" 옵션으로 보안 그룹을 보관할 수 있습니다. ▸ 보안 그룹이 다른 보안 그룹에 참조되어 있으므로, CloudFormation 삭제 시 의존성 오류 발생 ▸ Retain으로 지정하면: (1) 보안 그룹은 AWS에 남아있음(다른 SG 참조 유지), (2) CloudFormation 스택만 삭제, (3) 다른 애플리케이션 영향 없음 【오답 체크】 ▸ (A) 모든 참조 SG 수정 필요(운영 오버헤드 매우 높음, 문제 해결이 아닌 우회) ▸ (B) 변경 세트는 스택 상태 정의용(DELETE_FAILED 상태 해결 안 됨) ▸ (D) 드리프트 감지는 CloudFormation 템플릿과 실제 리소스 비교만 수행(삭제 문제 해결 안 됨) 【시험 포인트】 ▸ CloudFormation 스택 삭제 정책(DeletionPolicy) ▸ Retain 옵션으로 리소스 보호 ▸ 종속 리소스로 인한 DELETE_FAILED 문제 해결 ▸ 스택 재시도 옵션

해설

【핵심 용어】 ▸ CloudWatch Synthetics 카나리(Canary): 브라우저/HTTP 엔드포인트를 정기적으로 호출하여 가용성/성능 모니터링(실제 사용자 경험 시뮬레이션) ▸ 하트비트 모니터링: 가용성 확인(응답/타임아웃) ▸ SuccessPercent: 성공한 점검의 비율 【정답 포인트】 ▸ 정답 C: ▸ Synthetics 하트비트 카나리는 실제 사용자 경험을 시뮬레이션하며 가용성을 직접 측정합니다. ▸ SuccessPercent < 99%가 정확히 "가동 시간 99% 미만" 조건과 매칭 ▸ CloudWatch 경보로 SNS 알림 자동화 ▸ 가용성 기반 모니터링(로그 기반이 아님) 【오답 체크】 ▸ (A) HTTP 4xx/5xx 오류 기반: 단순 오류 로그 계산으로 실제 가용성 정확도 낮음(일부 4xx는 정상 응답), 사용자 경험 미반영 ▸ (B) 이상 탐지: 기존 메트릭 트렌드에 기반하므로 초기 기준선 없음, 99% 가동 시간 기준 명확하지 않음 ▸ (D) 끊어진 링크 확인자: 정적 링크 검사(하트비트/가용성이 아님) 【시험 포인트】 ▸ CloudWatch Synthetics 카나리 유형(하트비트/API/브라우저/끊어진 링크) ▸ 사용자 경험 기반 가용성 모니터링 ▸ SuccessPercent 메트릭 해석 ▸ SNS 알림 연계

해설

【핵심 용어】 ▸ AWS Budgets: 비용 추적 및 임계값 기반 자동 경보(예산 설정, 경보 트리거) ▸ 비용 경보(실제 vs 예측): 임계값 초과 시 SNS로 실시간 알림 【정답 포인트】 ▸ 정답 D: ▸ AWS Budgets는 실제 비용과 예측 비용 모두에 대한 경보를 기본 제공합니다. ▸ 별도 설정 불필요: 예산 생성 → 경보 추가 → SNS 연계(2~3단계) ▸ "최소한의 운영 오버헤드": 자동화된 임계값 기반 트리거, 커스텀 로직 불필요 【오답 체크】 ▸ (A) 수동 모니터링: Cost Explorer 정기 확인 필요(자동화 없음) ▸ (B) 복잡한 파이프라인(Step Functions → Forecast → Lambda): 초기 설정 오버헤드 매우 높음(예측이 불필요, 임계값만 필요) ▸ (C) 월간 보고서만 전송: 실시간 경보 아님(즉각적 대응 불가) 【시험 포인트】 ▸ AWS Budgets 기능 및 경보 유형 ▸ 실제 비용 vs 예측 비용 경보의 차이 ▸ Cost Explorer와 Budgets의 구분(모니터링 vs 자동화) ▸ 운영 효율성 평가 기준

해설

【핵심 용어】 ▸ ACM(AWS Certificate Manager): AWS에서 SSL/TLS 인증서 관리 서비스(리전별) ▸ DNS 검증: ACM이 도메인 소유권 확인을 위해 Route 53에 CNAME 레코드 생성 요구 ▸ 크로스 계정: 인증서 요청과 DNS 검증 권한 필요 【정답 포인트】 ▸ 정답 C: ▸ ACM 인증서는 요청 계정(개발 계정)에서 생성 ▸ DNS 검증 시 Route 53 호스팅 영역(공유 계정)에 CNAME 레코드 생성 필요 ▸ 크로스 계정 접근: 공유 계정의 Route 53에서 개발 계정 ACM의 검증 요청을 처리하기 위해 신뢰 관계 또는 Route 53 호스팅 영역 권한 설정 【오답 체크】 ▸ (A) KMS는 SSL/TLS 인증서 발급 관련 없음(데이터 암호화 키용) ▸ (B) 공유 계정에서 ACM 생성: 개발 계정의 애플리케이션이 다른 계정 인증서 사용 복잡(크로스 계정 공유 설정 필요) ▸ (D) KMS 키 사용 불필요, 검증 레코드에 ARN 참조도 의미 없음 【시험 포인트】 ▸ 다중 계정 환경에서 ACM 배포 패턴 ▸ DNS 검증 기반 인증서 발급 ▸ Route 53 크로스 계정 접근 권한 ▸ 리소스 소유권 vs 접근 권한 분리

해설

【핵심 용어】 ▸ VPC Flow Logs: VPC의 네트워크 인터페이스로 송수신되는 IP 트래픽 기록 ▸ CloudWatch Logs 대상: Flow Logs 데이터를 CloudWatch Logs 로그 그룹에 쓰기 ▸ IAM Role: Flow Logs가 CloudWatch Logs에 데이터 쓰기 시 필요한 권한 【정답 포인트】 ▸ 정답 A: ▸ VPC Flow Logs가 CloudWatch Logs에 처음 쓸 때 로그 그룹(log group) 자동 생성 필요 ▸ CreateLogGroup 권한 필수: logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents ▸ 이 중 CreateLogGroup 권한 부재 시 로그 그룹 생성 실패 → 전체 로깅 중단 【오답 체크】 ▸ (B) CreateExportTask: S3로의 로그 내보내기용 권한(Flow Logs → CloudWatch Logs 쓰기와 무관) ▸ (C) IPv6 주소: Flow Logs가 IPv6 지원(IPv4/IPv6 모두 기록 가능) ▸ (D) VPC 피어링: 네트워크 통신과 로깅 메커니즘 독립적(피어링 여부 무관) 【시험 포인트】 ▸ VPC Flow Logs 활성화 시 필요한 IAM 권한 ▸ CloudWatch Logs 대상 설정 ▸ CreateLogGroup vs CreateLogStream 권한 차이 ▸ Flow Logs 트러블슈팅 체크리스트

해설

【핵심 용어】 ▸ 보안 그룹 참조(Security Group Reference): 보안 그룹 규칙에서 특정 보안 그룹의 멤버로부터의 트래픽만 허용 ▸ 동적 멤버십: 보안 그룹 변경 시 자동 반영(IP 목록 관리 불필요) 【정답 포인트】 ▸ 정답 A: ▸ EC2 인스턴스 보안 그룹의 인바운드 규칙: "소스 보안 그룹 = NLB 보안 그룹" ▸ 이렇게 설정하면 NLB의 ENI(탄력적 네트워크 인터페이스)를 통한 모든 트래픽만 허용됩니다. ▸ "최소한의 운영 오버헤드": 보안 그룹 ID만 참조(IP/CIDR 관리 불필요, 자동 동기화) 【오답 체크】 ▸ (B) ENI 직접 참조: 보안 그룹 규칙에서 ENI ID 목록 지정 불가(지원 안 됨), 관리 복잡 ▸ (C) 네트워크 ACL: NLB의 정확한 CIDR 범위 파악 필요(IPv6 지원 복잡), 서브넷 전체에 적용(과도한 범위) ▸ (D) 타사 방화벽: 추가 EC2 인스턴스 관리 오버헤드(비용, 유지보수) 【시험 포인트】 ▸ 보안 그룹의 보안 그룹 참조 기능 ▸ NLB와 EC2 인스턴스 간 보안 그룹 설정 ▸ 인바운드 규칙의 소스 지정 방식(IP/CIDR vs 보안 그룹) ▸ 운영 오버헤드 최소화 전략

해설

【핵심 용어】 ▸ AWS CloudTrail: AWS API 호출 기록(보안 그룹 변경 포함) ▸ Amazon EventBridge: CloudTrail 이벤트 감지 및 트리거 ▸ AWS Systems Manager Automation: 사전 정의된 런북(Runbook) 실행(AWS-CreateServiceNowIncident 제공) 【정답 포인트】 ▸ 정답 C: ▸ 보안 그룹 변경은 AWS API 호출(예: AuthorizeSecurityGroupIngress, RevokeSecurityGroupEgress)로 기록됨 ▸ EventBridge 규칙: CloudTrail 이벤트 패턴 매칭("eventName": ["AuthorizeSecurityGroupIngress", ...]) ▸ AWS-CreateServiceNowIncident 런북: AWS에서 제공하는 기본 통합(커스텀 Lambda 불필요) ▸ "최소한의 운영 노력": 서버리스, 사전 정의된 런북 사용 【오답 체크】 ▸ (A) CloudWatch 경보는 메트릭 기반(CloudTrail 이벤트 직접 감지 불가) ▸ (B) Security Hub는 보안 검결과 분석용(CloudTrail 이벤트 직접 감지 아님) ▸ (D) EC2 인스턴스 지속 운영: 관리 오버헤드 높음, 배치 처리(30분 지연), 고가용성 부족 【시험 포인트】 ▸ CloudTrail 기반 API 호출 이벤트 감지 ▸ EventBridge의 CloudTrail 통합 ▸ Systems Manager Automation 런북(AWS-CreateServiceNowIncident) ▸ 실시간 이벤트 기반 자동화

해설

【핵심 용어】 ▸ AWS Config: 리소스 규정 준수 모니터링 및 자동 수정(규칙 기반) ▸ required-tags 관리형 규칙: 특정 태그 존재 여부 평가 ▸ 자동 수정(Auto Remediation): 비규정 준수 리소스 자동 수정(Systems Manager Automation 연계) 【정답 포인트】 ▸ 정답 C: ▸ required-tags는 AWS Config 기본 제공 관리형 규칙(DynamoDB 포함 지원) ▸ 자동 수정: Systems Manager Automation 런북 연계로 태그 자동 추가 ▸ "최소한의 운영 오버헤드": (1) 사전 정의된 규칙 사용(커스텀 로직 불필요), (2) AWS Config가 지속적 모니터링, (3) 자동 수정으로 수동 개입 최소화 【오답 체크】 ▸ (A) Lambda 함수 + EventBridge: 커스텀 로직 작성 필요, 일정 기반 실행(지연 가능), Config 통합 부족 ▸ (B) AWS Config 커스텀 규칙: required-tags 관리형 규칙이 있는데 왜 커스텀?→ 불필요한 개발 오버헤드 ▸ (D) EventBridge 관리형 규칙: 이벤트 기반 감지(모든 변경 감지 가능하나 Config의 지속적 평가보다 복잡) 【시험 포인트】 ▸ AWS Config 관리형 규칙(required-tags) ▸ 자동 수정(Auto Remediation) 메커니즘 ▸ Systems Manager Automation 런북과의 통합 ▸ Config의 지속적 규정 준수 모니터링

해설

【핵심 용어】 ▸ Aurora Auto Scaling: Aurora 복제본(읽기 전용 인스턴스) 수를 동적으로 조정하는 기능 ▸ 읽기 스케일링: 복제본 추가로 읽기 쿼리 분산(95% 읽기 워크로드에 최적) ▸ Aurora Replica: 읽기 전용 인스턴스(쓰기는 주 인스턴스에서만) 【정답 포인트】 ▸ 정답 A: ▸ 읽기 워크로드가 95%이므로 읽기 확장에 집중 ▸ Aurora Auto Scaling: Aurora 복제본의 CPU 사용률 모니터링 → 임계값 초과 시 복제본 추가, 미만 시 제거 ▸ 읽기 트래픽 증가 → 복제본 추가로 자동 분산 → CPU 부하 균형 【오답 체크】 ▸ (B) "크기 증가": 인스턴스 타입 업그레이드(스케일 업)는 다운타임 발생, 읽기 부하 분산 아님 ▸ (C) AWS Auto Scaling + 주 인스턴스 모니터링: 주 인스턴스는 쓰기만 처리(5%), CPU 낮음→ 복제본 추가 신호 부족 ▸ (D) AWS Auto Scaling은 서비스별 개별 스케일링(Aurora Auto Scaling 전용 기능 아님) 【시험 포인트】 ▸ Aurora Auto Scaling의 복제본 수 조정 메커니즘 ▸ 읽기 워크로드 기반 스케일링 전략 ▸ 주 인스턴스 vs 복제본의 역할 구분 ▸ 스케일 아웃(수평) vs 스케일 업(수직) 차이

해설

【핵심 용어】 ▸ S3 Block Public Access: 기본 설정으로 활성화(모든 공개 액세스 차단) ▸ 버킷 정책(Bucket Policy): 버킷 수준의 IAM 정책(PutObject/GetObject 권한 제어) ▸ 정적 웹사이트 호스팅: S3가 HTTP 엔드포인트로 콘텐츠 제공 【정답 포인트】 ▸ 정답 B: ▸ 403 Forbidden 원인: Block Public Access 활성화로 모든 공개 액세스 차단(인증 없는 요청 거부) ▸ 해결: (1) Block Public Access "비활성화" (2) 버킷 정책으로 Principal "*"(모든 사용자)에게 "s3:GetObject" 권한 부여 ▸ "공개" 정적 웹사이트 요구사항 충족 【오답 체크】 ▸ (A) Route 53 DNS 별칭: 정적 웹사이트 접근 경로(URL 리다이렉션)만 제공, 403 액세스 권한 문제 해결 안 됨 ▸ (C) 개체 ACL 권한: 버킷 정책이 GetObject 거부하면 개체 ACL 권한도 효과 없음(버킷 정책 우선) ▸ (D) PutObject: 업로드 권한(콘텐츠 읽기와 무관) 【시험 포인트】 ▸ S3 Block Public Access 설정 이해 ▸ 버킷 정책 vs 개체 ACL 차이 ▸ 정적 웹사이트 호스팅 권한 설정 ▸ GetObject vs PutObject 권한

해설

【핵심 용어】 ▸ CloudWatch Alarm → SNS: 경보 상태 변화(OK, ALARM, INSUFFICIENT_DATA) 시 SNS 메시지 발행 ▸ SNS 구독: 이메일, SMS, HTTP(S), Lambda, SQS 등으로 알림 수신 ▸ 티켓팅 도구 웹훅(Webhook): HTTP POST로 요청 수신 【정답 포인트】 ▸ 정답 A: ▸ CloudWatch 경보가 VPN 터널 상태(TunnelState 메트릭) 모니터링(이미 구성됨) ▸ 경보가 ALARM 상태(터널 다운) → SNS 주제로 메시지 발행 ▸ 티켓팅 도구 웹훅을 SNS 구독(HTTPS 엔드포인트) → 자동으로 티켓 생성 API 호출 ▸ "가장 간단한 연계": 중간 Lambda/SQS 불필요 【오답 체크】 ▸ (B) SQS는 메시지 큐(비동기 처리)용이며, "메시지 변환 + 티켓팅" 로직은 별도 처리 필요(복잡) ▸ (C) CloudWatch는 Lambda 직접 호출 미지원(SNS/SQS 경유 필요) ▸ (D) EventBridge는 CloudTrail/VPC Flow 등의 구조화된 이벤트 기반(CloudWatch 경보 상태 이벤트는 CloudWatch 경보 자체로 충분) 【시험 포인트】 ▸ CloudWatch 경보 → SNS 알림 경로 ▸ SNS 구독 타입(웹훅/HTTPS) ▸ VPN 모니터링 메트릭(TunnelState) ▸ 기존 CloudWatch 경보 활용(새로운 이벤트 감지 불필요)

해설

【핵심 용어】 ▸ CloudFormation 스택 생성 실패 시 롤백(Rollback): 생성된 리소스 자동 삭제(기본 동작) ▸ OnFailure 파라미터: 스택 생성 실패 시 동작 지정(ROLLBACK/DO_NOTHING/ROLLBACK_COMPLETE_ON_FAILURE) ▸ DisableRollback: 스택 생성 중 롤백 비활성화(스택 검사 가능, 손상된 상태 유지) 【정답 포인트】 ▸ 정답 B: ▸ OnFailure="DO_NOTHING": 스택 생성 실패 시 이미 생성된 리소스는 유지(롤백 안 함) ▸ "향후 배포"를 위해 리소스 보존 필요 → 스택 생성 실패 후 리소스 조사 가능 ▸ AWS CLI 예: aws cloudformation create-stack --on-failure DO_NOTHING 【오답 체크】 ▸ (A) DisableRollback=False: 롤백 활성화(기본값)→ 리소스 삭제됨(요구사항 충돌) ▸ (C) 롤백 구성의 "DO_NOTHING"은 롤백 트리거와 함께 사용하는 다른 개념(스택 생성 실패 시 리소스 보존 효과 없음) ▸ (D) OnFailure=ROLLBACK: 명시적 롤백(리소스 삭제) 【시험 포인트】 ▸ CloudFormation 스택 생성 실패 시 옵션 ▸ OnFailure 파라미터의 3가지 값 ▸ DisableRollback vs OnFailure 차이 ▸ 스택 생성 후 문제 진단을 위한 리소스 보존

해설

【핵심 용어】 ▸ AWS Systems Manager State Manager: EC2/온프레미스 인스턴스에서 구성 관리(문서 기반) ▸ 연관(Association): 예약된 시간이나 특정 이벤트(예: InstanceStart)에 문서 실행 ▸ EC2 User Data: 스크립트를 AMI에 포함하거나 State Manager로 런타임 실행 【정답 포인트】 ▸ 정답 A: ▸ State Manager는 EC2 시작(또는 정기적)을 트리거로 AWS Systems Manager 문서 실행 ▸ 문서: 소프트웨어 설치 명령어 정의(예: "aws:runShellScript") ▸ "인스턴스 시작 시 설치": State Manager 연관으로 자동화 ▸ AMI 수정 불필요(유연한 소프트웨어 업데이트) 【오답 체크】 ▸ (B) CloudWatch는 모니터링 에이전트(이벤트 감지가 아님), StartTask는 ECS 태스크 시작용(EC2 소프트웨어 설치와 무관) ▸ (C) Amazon Inspector: 보안 취약점 스캔(소프트웨어 설치 아님) ▸ (D) Security Hub: 보안 검결과 관리(소프트웨어 설치 기능 없음) 【시험 포인트】 ▸ AWS Systems Manager State Manager의 연관(Association) 기능 ▸ EC2 라이프사이클 이벤트(시작 시 자동 실행) ▸ State Manager 문서 타입(RunShellScript, RunCommand, CloudFormation 등) ▸ 서버리스 구성 관리(인스턴스별 부트스트랩 스크립트보다 유연)

해설

【핵심 용어】 ▸ CloudWatch Container Insights: EKS/ECS 클러스터의 컨테이너 성능 메트릭 수집(CPU, 메모리, 네트워크) ▸ Amazon DevOps Guru: ML 기반 이상 탐지 및 근본 원인 분석/권장 사항 제공 ▸ Anomaly Detection: CloudWatch의 통계 기반 임계값(권장 사항 생성 기능 없음) 【정답 포인트】 ▸ 정답 B: ▸ Container Insights는 EKS 워크로드 메트릭 수집 ▸ DevOps Guru는 Container Insights 메트릭 분석 → 이상 패턴 감지(ML) → 근본 원인(예: 메모리 누수, Pod 재시작 빈번) 파악 → 구체적 권장 사항 생성 ▸ "임계값 정의 대신 ML 기반 자동 분석" → 운영 효율성 향상 【오답 체크】 ▸ (A) 이상 탐지: 통계 기반(평균/표준편차), 근본 원인 분석 없음(권장 사항 부족) ▸ (C) Container Insights만: 메트릭 수집만 제공(이상 탐지/권장 사항 기능 없음) ▸ (D) 이상 탐지 + Container Insights: Insights 메트릭은 DevOps Guru 분석에 적합(이상 탐지 통계 기반은 컨테이너 환경에 부적합) 【시험 포인트】 ▸ CloudWatch Container Insights의 EKS 통합 ▸ Amazon DevOps Guru의 ML 기반 이상 탐지 및 권장 사항 ▸ 기존 임계값 기반 경보의 한계 ▸ 컨테이너 워크로드 운영 최적화