정답 · 해설

해설

【핵심 용어】 ▸ CloudFormation — AWS 인프라를 코드로 정의하고 자동으로 생성/관리하는 서비스 ▸ PrivateDnsName — 읽기 전용 속성으로, 리소스 생성 후에만 AWS가 자동 할당 (템플릿에서 직접 설정 불가) ▸ Stack Creation — 템플릿으로부터 AWS 리소스를 생성하는 프로세스 【정답 포인트】 ▸ "PrivateDnsName은 출력 속성" → (C) PrivateDnsName을 CloudFormation 템플릿에서 직접 설정하려면 실패 ▸ 템플릿에서 값을 할당하려 했으나, AWS가 자동으로 생성되는 읽기 전용 속성이므로 충돌 발생 【오답 체크】 (A) Outputs 섹션 — 선택 사항, 생략해도 스택 생성 성공. 리소스 생성에는 영향 없음. (B) Parameters 섹션 — 선택 사항, 없어도 기본값으로 스택 생성 가능. (D) VPC 지정 — 선택 사항이 아니면 필수지만, 리소스 유형에 따라 암묵적 또는 기본 VPC 사용 가능. 【시험 포인트】 ▸ 패턴: CloudFormation에서 읽기 전용 속성(예: PublicIpAddress, PrivateDnsName, ResourceId)은 template에서 설정 불가 ▸ 함정: 템플릿이 완전해 보이지만, 특정 리소스의 읽기 전용 속성을 설정하려는 오류 발생 ▸ 해결책: GetAtt()를 사용해 생성 후 속성값을 참조하거나, Outputs 섹션에서 출력

해설

【핵심 용어】 ▸ User-defined Tags — 사용자가 생성한 커스텀 태그 (AWS 관리 태그 vs 구분) ▸ Cost Allocation Tags — Cost Explorer에서 비용 필터링/분석에 사용 가능하도록 활성화된 태그 ▸ Cost Explorer — AWS 비용 및 사용량을 분석하고 시각화하는 서비스 【정답 포인트】 ▸ "사용자 정의 태그 활성화" → (B) 태그를 생성만 해서는 부족, Cost Allocation 활성화 필수 ▸ 태그는 자동으로 Cost Explorer 필터링에 사용되지 않음, 명시적 활성화 필요 【오답 체크】 (A) 30일 대기 — 올바른 답이 아님. 필요한 것은 시간이 아닌 활성화 작업. (C) Cost and Usage Report — 선택 사항, 없어도 Cost Explorer 필터링 가능. (D) AWS Budgets — 별개 서비스, Cost Explorer 필터링과 무관. 【시험 포인트】 ▸ 패턴: 태그 생성 ≠ 비용 분석 적용. Cost Allocation 탭에서 "Activate" 필수 ▸ 함정: 최소 30일 대기라는 잘못된 상식(일부 AWS 기능이 시간 필요하지만, 이 경우 활성화만 필요) ▸ 진행: Billing & Cost Management > Cost Explorer > Cost Allocation Tags 탭에서 활성화

해설

【핵심 용어】 ▸ CloudWatch Agent — EC2의 로그/메트릭을 CloudWatch Logs로 전송하는 소프트웨어 ▸ Configuration File — Agent가 어떤 로그를 수집할지 정의하는 JSON 파일 ▸ append-config — 기존 설정을 유지하면서 새 설정을 추가하는 옵션 ▸ Systems Manager Run Command — 여러 인스턴스에 명령을 원격으로 실행 【정답 포인트】 ▸ "기존 설정 유지 + 새 로그 추가" → (A) append-config로 50개만 효율적으로 업데이트 ▸ 100개 인스턴스 중 50개만 변경하므로, 스케일 가능한 자동화 필수 ▸ Run Command + 태그로 대상 선택 → 운영 효율성 극대화 【오답 체크】 (B) 수동 로그인 — 100개(또는 50개) 인스턴스에 일일이 로그인 → 운영 비효율 (C) 마법사 실행 — 각 인스턴스에서 반복 실행 필요 → 수동, 확장성 부족 (D) 고급 세부 정보 — OS 로그가 자동 캡처되지만, DHCP 로그 지정 불가 【시험 포인트】 ▸ 패턴: CloudWatch Agent 대규모 업데이트 → Run Command + 태그 기반 타게팅 ▸ 함정: 마법사는 개별 인스턴스용, 50개 대상은 비효율적 ▸ 핵심: append-config는 기존 설정 보존 + 새 설정 추가 (replace는 전체 교체로 위험)

해설

【핵심 용어】 ▸ S3 Object Lock — 객체 삭제를 일정 기간 방지하는 메커니즘 ▸ Compliance Mode — 법적 요구사항용, 보존 기간 중 어떤 방법으로도 우회 불가 (관리자도 불가) ▸ Governance Mode — 일반 목적, 특정 권한(s3:BypassGovernanceRetention)이 있으면 우회 가능 ▸ Retention Period — 객체가 삭제될 수 없는 시간 기간 【정답 포인트】 ▸ "3개월 삭제 방지" → (B) S3 Object Lock + Compliance 모드 + 3개월 보존 ▸ Compliance는 어떤 사용자도 우회 불가 → 규정 준수 보장 ▸ 새 버킷 필요 (Object Lock은 생성 시 활성화해야 함) 【오답 체크】 (A) IAM 정책 — 정책 제거 후 언제든 삭제 가능 → 강제성 부족, 우회 위험 (C) Versioning — 삭제 방지 메커니즘 아님, Lifecycle과 조합해도 주 목표 달성 불충분 (D) Governance 모드 — s3:BypassGovernanceRetention 권한 있으면 관리자가 우회 가능 → 규정 미충족 【시험 포인트】 ▸ 패턴: "삭제 방지 + 규정 준수" → Compliance 모드 필수 (Governance 아님) ▸ 함정: Governance는 Compliance와 비슷해 보이지만, 우회 가능 → 차이 명확히 ▸ 실무: Compliance는 한 번 설정되면 변경/제거 불가 → 신중하게 계획 필요

해설

【핵심 용어】 ▸ VPC Flow Logs — VPC 내 네트워크 인터페이스의 트래픽 정보를 캡처하는 기능 ▸ CloudWatch Logs — Flow Logs의 대상 중 하나 (S3, Kinesis Data Firehose도 가능) ▸ IAM Role — Flow Logs가 CloudWatch Logs에 접근하기 위한 권한 보유자 ▸ logs:CreateLogGroup — CloudWatch Logs 그룹을 생성하는 권한 (필수) 【정답 포인트】 ▸ "Flow Logs 게시 실패" → (A) logs:CreateLogGroup 권한 부족 ▸ Flow Logs는 로그 그룹을 자동 생성하려고 함 → 이 권한 필수 ▸ 권한 누락 → 로그 그룹 생성 실패 → 로그 게시 불가 【오답 체크】 (B) logs:CreateExportTask — S3로 내보내기용, CloudWatch Logs 게시와 무관 (C) IPv6 구성 — Flow Logs는 IPv4/IPv6 모두 지원, 관계 없음 (D) VPC Peering — 네트워크 구성 요소, Flow Logs 게시 메커니즘에 영향 없음 【시험 포인트】 ▸ 패턴: Flow Logs → CloudWatch Logs 게시 → IAM 권한 검토 ▸ 필수 권한: logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents ▸ 함정: IPv6, VPC Peering 등은 Flow Logs 수집을 방해하지만, 게시 메커니즘은 영향 없음

해설

【핵심 용어】 ▸ Weighted Random — 모든 인스턴스에 동등한 가중치로 무작위 분배 ▸ Session Affinity (Stickiness) — 같은 클라이언트가 계속 같은 인스턴스로 라우팅 ▸ Least Outstanding Requests — 미처리 요청이 적은 인스턴스로 우선 라우팅 ▸ Health Check — 타겟 인스턴스 상태 모니터링 【정답 포인트】 ▸ "Weighted Random + Session Affinity 필요" → 충돌 발생 ▸ Weighted Random은 세션을 고려하지 않음 → 매 요청마다 랜덤 인스턴스로 전송 ▸ 같은 사용자 세션이 여러 인스턴스에 분산 → 애플리케이션 오류 (상태 불일치) ▸ (A) Least Outstanding Requests로 변경 → 더 일관적인 인스턴스 선택 가능 【오답 체크】 (B) 이상 탐지 — 연결 패턴 분석 기능, 세션 유지 메커니즘 아님 (C) 교차 영역 로드 밸런싱 — AZ 간 분산 제어, 세션 문제와 무관 (D) 등록 해제 지연 — 연결 정리 시간, 세션 라우팅과 무관 【시험 포인트】 ▸ 패턴: "로드 밸런싱 알고리즘 + 세션 요구" → 알고리즘이 세션 인식 여부 확인 ▸ Sticky Sessions/Affinity 기능은 ALB에도 있지만, Weighted Random 자체로는 보장 불가 ▸ 함정: Health Check가 정상이므로 인프라 문제 아님 → 로직/라우팅 문제

해설

【핵심 용어】 ▸ Backtracking — Aurora DB 클러스터를 과거 시점으로 빠르게 되감는 기능 (같은 클러스터 내) ▸ Point-in-Time Recovery — 백업으로부터 새 DB 클러스터 생성 (별도 클러스터) ▸ 72-Hour Window — Backtracking 기본 보존 기간 【정답 포인트】 ▸ "같은 프로덕션 DB 클러스터 내에서 복구" → (C) Backtracking ▸ Backtracking은 현재 클러스터를 과거로 되감음 (빠르고 비용 효율적) ▸ 72시간 요구사항 → Aurora는 기본 72시간 보존 【오답 체크】 (A) Aurora Replica 승격 — 다른 클러스터 생성 → "같은 클러스터" 요구 미충족 (B) Lambda로 자동 백업 복구 — 복구 시간 길고, 별도 클러스터 생성 (D) Point-in-Time 복구 — 새 클러스터 생성 → "같은 클러스터" 요구 미충족 【시험 포인트】 ▸ 패턴: "같은 클러스터 + 과거 지점으로 복구" → Backtracking 핵심 ▸ 차이: Backtracking은 Aurora 전용, Point-in-Time은 모든 RDS ▸ 72시간: Backtracking 기본 윈도우, 필요시 BacktrackWindow 설정으로 확장 가능 (최대 35일)

해설

【핵심 용어】 ▸ Stack Creation Failure — 템플릿의 일부 리소스 생성이 실패 ▸ Rollback — 실패 시 생성된 모든 리소스 자동 삭제 (기본 동작) ▸ OnFailure Parameter — 스택 생성 실패 시의 동작 지정 (CLI/API 사용) ▸ DO_NOTHING — 생성된 리소스 유지, 스택만 실패 상태로 유지 【정답 포인트】 ▸ "생성된 리소스 보존" → (B) OnFailure=DO_NOTHING ▸ 기본값은 ROLLBACK (모든 리소스 삭제) → DO_NOTHING으로 변경 ▸ 스택 생성 실패 후 성공한 리소스는 유지, 분석/troubleshooting 가능 【오답 체크】 (A) DisableRollback=False — 기본값이며, 롤백 수행 → 리소스 삭제 (C) Rollback Configuration — 롤백 조건 설정, 리소스 보존 불가 (D) OnFailure=ROLLBACK — 기본값, 리소스 삭제 【시험 포인트】 ▸ 패턴: "스택 실패 + 리소스 보존" → OnFailure 파라미터 ▸ 옵션: DO_NOTHING (보존), ROLLBACK (삭제), CONTINUE (부분 계속) ▸ 실무: DO_NOTHING으로 리소스 검토 후, 수동으로 스택/리소스 정리

해설

【핵심 용어】 ▸ Application Load Balancer(ALB) — 레이어 7 (애플리케이션) 로드 밸런싱, HTTP/HTTPS 리디렉트 지원 ▸ Network Load Balancer(NLB) — 레이어 4 (전송), HTTP 리디렉트 미지원 ▸ HTTPS Listener — 포트 443, SSL/TLS 인증서 필수 ▸ HTTP to HTTPS Redirect — ALB 규칙으로 자동 리디렉트 【정답 포인트】 ▸ "HTTP → HTTPS 자동 리디렉트" → (B) ALB + HTTP 리스너 + HTTPS 리스너 + 리디렉트 규칙 ▸ ALB는 레이어 7이므로 HTTP 리디렉트 규칙 지원 ▸ 포트 80 (HTTP) → 포트 443 (HTTPS) 리디렉트 【오답 체크】 (A) 포트 80에 HTTPS — HTTP 프로토콜이 HTTPS 포트로 올 수 없음 (프로토콜 불일치) (C) TCP 리스너 — 레이어 4, HTTP 애플리케이션 리디렉트 불가 (D) Network Load Balancer — 레이어 4, HTTP 리디렉트 규칙 지원 안 함 【시험 포인트】 ▸ 패턴: "HTTP → HTTPS 리디렉트" → ALB (레이어 7) ▸ ALB vs NLB: ALB는 애플리케이션 수준 기능 (리디렉트), NLB는 연결 수준 ▸ 구성: HTTP 리스너 (포트 80) + HTTPS 리스너 (포트 443) → 리디렉트 규칙

해설

【핵심 용어】 ▸ Service Control Policy(SCP) — AWS Organizations에서 조직/OU/계정 단위로 권한 제어 ▸ Organizational Unit(OU) — 조직 내 계정 그룹 ▸ ec2:RunInstances — EC2 인스턴스 시작 작업 ▸ Tag Condition — 정책에서 특정 태그 존재 여부로 권한 제어 【정답 포인트】 ▸ "애플리케이션 OU 계정만 제한" → (B) SCP를 애플리케이션 OU에 연결 ▸ SCP는 조직 단위에서 작동, 계정 내 모든 IAM 사용자/역할에 적용 ▸ 태그 없으면 거부 → 강제성 있음 (IAM 정책보다 상위) 【오답 체크】 (A) IAM 그룹 — 계정 단위 제어, OU 단위 제어 불가 + 사용자 추가 수동 필요 (C) IAM 역할 — 계정 내 일부 사용자만 제어, OU 전체 계정 제어 불가 (D) 루트 OU에 SCP 연결 — 모든 계정에 적용 → "애플리케이션 OU만" 요구 미충족 【시험 포인트】 ▸ 패턴: "특정 OU의 모든 계정 제어" → SCP를 해당 OU에 연결 ▸ SCP vs IAM: SCP는 조직/OU 수준, IAM은 계정 수준 → SCP가 상위 권한 ▸ 함정: (D) 루트 OU는 전체 조직에 적용 → 요구 범위 초과

해설

【핵심 용어】 ▸ Systems Manager Run Command — 여러 EC2 인스턴스에 명령 원격 실행 ▸ Rate Control — 동시 실행 인스턴스 수 제한 (Concurrency) ▸ Target Tagging — 태그로 명령 대상 인스턴스 지정 ▸ Reserved Concurrency (Lambda) — Lambda 동시 호출 제한 【정답 포인트】 ▸ "300+ 인스턴스 + 동시성 30 제한" → (C) Run Command + Rate Control ▸ Rate Control의 Concurrency 파라미터로 동시 실행 30 제한 ▸ 사용자 정의 태그로 모든 대상 지정 → 자동 확장 가능 ▸ 가장 운영 효율적: 배치 수동 분할 불필요 【오답 체크】 (A) 보조 태그로 10개 배치 생성 — 수동 분할 + 10번 실행 필요 → 운영 비효율 (B) Lambda 예약 동시성 — Lambda 호출 제한이지, EC2 명령 동시성 제어 아님 (D) Step Functions 병렬 상태 — 30개 병렬 + 10번 실행 → 복잡하고, Lambda와 유사한 비효율 【시험 포인트】 ▸ 패턴: "대규모 인스턴스 + 동시성 제한" → Run Command의 Rate Control ▸ Rate Control: Concurrency (최대 동시 실행), Percentage (전체 대비 %) ▸ 태그 기반 타게팅으로 자동 확장 지원 → 미래 인스턴스 증가에 대응

해설

【핵심 용어】 ▸ Latency-Based Routing — 가장 낮은 네트워크 지연시간 Region으로 라우팅 ▸ Weighted Records — 가중치로 트래픽 분배 비율 제어 (같은 Region 내 AZ 간) ▸ Health Check — 엔드포인트 상태 모니터링 (정상/비정상 판별) ▸ Failover — 비정상 엔드포인트 감지 시 트래픽 우회 【정답 포인트】 ▸ "비정상 엔드포인트로 트래픽 계속 라우팅" → Health Check 부재 ▸ 가중치 레코드는 Health Check 없으면 상태 무시 → (A) Health Check 추가 ▸ Health Check 활성화 → 비정상 엔드포인트 자동 제외 【오답 체크】 (B) 가중치 증가 — 정적 구성, 동적 상태 변경 감지 불가 (C) 라우팅 방식 변경 — Health Check 문제 미해결 (D) TTL 감소 — DNS 재조회 빈도만 증가, 상태 감지 메커니즘 없음 【시험 포인트】 ▸ 패턴: "다중 Region/AZ + 비정상 엔드포인트 감지" → Health Check 필수 ▸ Latency + Weight 조합 사용 시, Weight 레코드에 Health Check 첨부 ▸ Health Check는 CloudWatch, SNS 알림과 통합 가능

해설

【핵심 용어】 ▸ Systems Manager Distributor — 패키지를 생성하고 배포하는 서비스 ▸ State Manager — 정기적인 구성 변경/업데이트를 자동화 ▸ AWS-ConfigureAWSPackage — Distributor 패키지를 설치/업데이트하는 문서 ▸ AWS-RunRemoteScript — 임의의 스크립트 실행 (Distributor 통합 X) 【정답 포인트】 ▸ (A) Distributor 패키지 — 타사 에이전트를 패키지화하여 중앙 배포 ▸ (E) State Manager + AWS-ConfigureAWSPackage — 정기적 자동 설치/업데이트 + 태그 기반 타게팅 ▸ A + E 조합: 패키지 배포 + 정기 자동 적용 → 운영 자동화 극대화 【오답 체크】 (B) OpsItem — 문제 추적용, 에이전트 배포와 무관 (C) Lambda — 수동 로그인 및 스크립트 → 확장성 부족, 자동화 불충분 (D) AWS-RunRemoteScript — 임의 스크립트용, Distributor와 통합 안 됨 → 정기 업데이트 추적 어려움 【시험 포인트】 ▸ 패턴: "타사 에이전트 + 정기 배포" → Distributor + State Manager ▸ AWS-ConfigureAWSPackage는 Distributor 패키지만 지원 ▸ State Manager로 주기 설정 (cron) → 자동 최신 유지

해설

【핵심 용어】 ▸ Patch Baseline — 적용할 패치 정의 (보안, 중요도 등) ▸ Patch Manager Scan — 인스턴스를 스캔하여 필요한 패치 식별 ▸ Patch Now — 스캔 후 패치 즉시 적용 ▸ Zero-Day Exploit — 미알려진 취약점 【정답 포인트】 ▸ "Zero-Day 패치 신속 배포" → (A) Patch Manager의 Scan + Patch Now ▸ Patch Baseline으로 패치 정책 정의 → 자동 적용 ▸ 영향받는 인스턴스 자동 식별 → 매우 빠름 【오답 체크】 (B) AWS Config — 시간 지연, Patch Manager만으로 충분 (C) EventBridge — 이벤트 기반 자동화이지만, 주기적 검사 필요 → Scan보다 느림 (D) AMI 업데이트 + 수동 인스턴스 배치 — 운영 오버헤드 큼, 가동 중단 발생 【시험 포인트】 ▸ 패턴: "긴급 패치 배포" → Patch Manager의 Scan + Patch Now (가장 빠름) ▸ Patch Baseline에서 즉시 적용할 패치 정의 가능 ▸ 각 Region에서 Patch Now → 병렬 적용 가능

해설

【핵심 용어】 ▸ AWS Security Hub — 보안 결과를 중앙에서 집계하고 관리 ▸ EventBridge — Security Hub 결과를 실시간으로 이벤트로 수신 ▸ Event-Driven Remediation — 보안 결과 이벤트 감지 → Lambda 자동 실행 ▸ Security Group Rule — 포트/프로토콜 수준의 접근 제어 【정답 포인트】 ▸ "보안 Hub 결과 자동 remediate" → (D) EventBridge + Lambda ▸ EventBridge는 Security Hub 결과를 실시간 이벤트로 수신 ▸ Lambda는 공개 포트를 제거 → 근본 원인 해결 ▸ 이벤트 기반 → 자동, 지속적 【오답 체크】 (A) 인스턴스 중지 — 근본 원인 해결 X, 가동 중단 발생 (B/C) Cron Job — 정기 실행, 실시간 응답 불가 → "이벤트 기반" 요구 미충족 (B) 보안 그룹 수정 + 인스턴스 제거 — 오류, 인스턴스 제거는 비용 낭비 (C) FTP → SFTP 변경 — 서버 재구성, 복잡, 근본 해결 X 【시험 포인트】 ▸ 패턴: "Security Hub 결과 + 자동 remediate" → EventBridge + Lambda ▸ EventBridge: 보안 허브 → 이벤트 규칙 생성 → Lambda 트리거 ▸ Lambda: 보안 그룹 규칙 삭제 (ec2:RevokeSecurityGroupIngress) ▸ 함정: Cron은 정기적이지만 "실시간 이벤트 기반" 아님

해설

【핵심 용어】 ▸ Cluster Placement Group — 낮은 지연시간, 높은 처리량 → HPC용 (같은 AZ 내) ▸ Partition Placement Group — 분산 워크로드, 대규모 병렬 처리 → 여러 AZ 지원 ▸ Spread Placement Group — 장애 격리, 개별 인스턴스 → HPC 부적합 ▸ Network Latency & Throughput — HPC의 핵심 요구사항 【정답 포인트】 ▸ "최소 지연시간 + 최대 처리량" → (A) Cluster Placement Group ▸ Cluster: 같은 AZ 내 인스턴스 물리적 근접 → 극도로 낮은 지연 ▸ 고대역폭 연결 (10 Gbps+) → HPC 병렬 처리 최적화 【오답 체크】 (B) Partition + 두 AZ — 여러 AZ는 지연시간 증가 (C) Partition + 한 AZ — Partition은 장애 격리 목적, HPC 처리량 최적화 X (D) Spread + 두 AZ — 개별 장애 격리, 높은 지연시간 → HPC 부적합 【시험 포인트】 ▸ 패턴: "HPC + 처리량/지연시간" → Cluster Placement Group ▸ Cluster는 단일 AZ만 지원 → 높은 처리량 보장 ▸ Partition/Spread는 여러 AZ 가능하지만, 지연시간/처리량 트레이드오프

해설

【핵심 용어】 ▸ AWS Security Hub — 보안 표준 및 컴플라이언스 통합 관리 ▸ CIS AWS Foundations Benchmark — AWS 보안 모범 사례 표준 ▸ Organization Auto-Enable — 새 계정 자동 등록 ▸ GuardDuty — 위협 탐지, CIS Benchmark 스캔 미지원 【정답 포인트】 ▸ "모든 계정 자동 스캔" → (D) Security Hub + 자동 활성화 ▸ (D)는 수동 초대 절차 불필요 → 자동 등록 ▸ 새 계정 자동 포함 → 운영 오버헤드 제거 ▸ Security Hub는 CIS Benchmark 표준 지원 【오답 체크】 (A) 수동 초대 스크립트 — 매번 수동 실행 필요 → 운영 비효율 (B) Amazon Inspector — CIS Benchmark 아님, EC2 취약점 스캔 → 용도 다름 (C) GuardDuty — 위협 탐지, CIS 스캔 미지원 + 수동 초대 필요 【시험 포인트】 ▸ 패턴: "조직 전체 자동 컴플라이언스" → Security Hub + Organization Auto-Enable ▸ Security Hub: CIS, PCI-DSS, HIPAA 등 다양한 표준 지원 ▸ AWS Organizations 통합 → 신규 계정 자동 포함 기능

해설

【핵심 용어】 ▸ AWS Compute Optimizer — 머신러닝으로 비용 최적화 추천 ▸ EBS Volumes — 프로비저닝된 IOPS/처리량 vs 실제 사용량 ▸ Metric Collection — 일반적으로 2주 필요 (충분한 데이터) ▸ Cost Optimization — IOPS 용량 과다 프로비저닝 식별 【정답 포인트】 ▸ "EBS IOPS/처리량 최적화" → (C) AWS Compute Optimizer ▸ Compute Optimizer는 EBS 볼륨 최적화 권장 제공 ▸ 자동 분석 → 수동 모니터링보다 효율적 ▸ 메트릭 수집 후 권장사항 도출 (일반적으로 2주) 【오답 체크】 (A) 수동 모니터링 — 사용된 공간 확인, IOPS/처리량 사용량 미분석 (B) EBS-optimized 변경 — 인스턴스 유형 변경, EBS 볼륨 최적화 X (D) fio 벤치마크 — 수동 테스트, 운영 비효율, 프로덕션 워크로드 대표 어려움 【시험 포인트】 ▸ 패턴: "대규모 비용 최적화 + 자동 권장" → Compute Optimizer ▸ Compute Optimizer는 EC2, EBS, Lambda 등 지원 ▸ 2주 대기 필수 (충분한 워크로드 데이터 수집)

해설

【핵심 용어】 ▸ AWS Config Managed Rule (s3-bucket-logging-enabled) — S3 로깅 활성화 여부 확인 ▸ Remediation Action — 비규정 리소스를 자동 수정 ▸ AWS Systems Manager Automation Runbook — AWS Systems Manager에서 제공하는 자동화 작업 ▸ AWS-ConfigureS3BucketLogging — S3 로깅 구성을 위한 공식 Runbook 【정답 포인트】 ▸ "현재 + 미래 버킷 로깅 강제" → (D) AWS Config + Automation Runbook ▸ AWS Config Managed Rule: 현재 버킷 자동 감지 ▸ Remediation + Automation Runbook: 자동 로깅 활성화 ▸ 미래 버킷: Config 규칙 지속 적용 → 자동 규정 준수 【오답 체크】 (A) Trusted Advisor — 일회성 검사, 자동 remediation 미지원 (B) Bucket Policy — 이미 생성된 버킷에 미적용, 강제 메커니즘 약함 (C) Lambda 함수 — 가능하지만, AWS Systems Manager Automation Runbook이 더 안정적이고 공식 【시험 포인트】 ▸ 패턴: "현재 + 미래 규정 준수 자동화" → AWS Config + Remediation ▸ AWS-ConfigureS3BucketLogging — AWS 공식 Runbook으로 최적화됨 ▸ Remediation은 자동/수동 선택 가능 ▸ 함정: (C) Lambda도 가능하지만, (D)가 권장 (운영 유지보수 용이)

해설

【핵심 용어】 ▸ Amazon EventBridge — 이벤트 기반 워크플로우를 자동화하는 서버리스 이벤트 버스 ▸ Cron expression — 반복 일정을 정의하는 방식("0 0 * * SAT") ▸ AWS Lambda vs EC2 — 서버리스(유지보수 최소)와 서버 기반 운영의 차이 【정답 포인트】 ▸ "EventBridge" → 이벤트 기반 자동 스케줄링(주기적 작업 최적) ▸ "운영 효율적" → 서버 관리 불필요한 서버리스 솔루션 ▸ "매주 토요일" → cron expression으로 자동 트리거 ▸ SNS와의 통합 → 기존 알림 메커니즘 활용 【오답 체크】 (A) EC2 인스턴스는 항상 실행되어야 하고 cron job 관리에 운영 부담 발생 (C) SNS fanout은 메시지를 분배하는 기능이며 스케줄링 기능 없음 (D) Step Functions는 EventBridge보다 복잡하고 오버헤드가 큼 【시험 포인트】 ▸ 스케줄 기반 자동화 → EventBridge(cron 또는 rate expression) ▸ 서버리스 원칙 → 관리형 서비스가 "가장 운영 효율적" ▸ 기존 서비스 활용 → SNS는 이미 배포됨