정답 · 해설

해설

【핵심 용어】 ▸ IAM 사용자 그룹 — 여러 사용자의 권한을 집중 관리하는 메커니즘입니다. ▸ 고객 관리형 정책 — 조직이 생성, 편집, 버전 관리할 수 있는 독립 정책입니다. ▸ AWS 관리형 정책 — AWS가 소유/유지보수하며 편집 불가능합니다. 【정답 포인트】 ▸ "여러 사용자"→그룹 (B) 사용으로 효율적 관리. ▸ "정책 변경 및 버전 생성"→고객 관리형 정책 (D) 필수(버전 관리 기능 포함). ▸ 그룹+고객관리형 조합이 요구사항 완벽 충족. 【오답 체크】 (A) 서비스 연결 역할은 AWS 서비스 전용; 사용자 직접 추가 불가. (C) AWS 관리형 정책은 버전 관리 불가; 조직이 편집 불가능. (E) 인라인 정책은 버전 관리 기능 없음; 삭제 시 이력 손실. 【시험 포인트】 ▸ 다중 사용자 권한 집중 관리 → IAM 그룹. ▸ 조직 맞춤형 정책으로 버전 관리 필요 → 고객관리형. ▸ AWS 관리형은 "읽기 전용" 정책 패턴.

해설

【핵심 용어】 ▸ Warm Pool — 사전 초기화된 대기 인스턴스 풀로, 스케일 아웃 시 즉시 트래픽 처리 가능합니다. ▸ Warm Pool 인스턴스는 부팅/초기화 스크립트 없이 신속하게 활성화됩니다. 【정답 포인트】 ▸ "긴 부팅 스크립트" + "시간 단축" → Warm Pool 솔루션. ▸ Warm Pool은 미리 초기화된 인스턴스로 스케일 아웃 지연 제거. ▸ "과다 프로비저닝 없음"→Warm Pool은 필요 시에만 활성화(비용 최적). 【오답 체크】 (A) 인스턴스 크기는 부팅 시간과 무관. (B) 최소 인스턴스 증가는 항상 실행으로 비용 낭비; 과다 프로비저닝. (C) 예측 스케일링은 미래 부하 예측이지, 부팅 지연 해결 안 함. 【시험 포인트】 ▸ 부팅 지연 문제 → Warm Pool 즉시 선택. ▸ Warm Pool은 Suspended ASG(중단 상태)에서 대기 중. ▸ Capacity Rebalancing과 함께 사용하여 효율성 극대화.

해설

【핵심 용어】 ▸ 서브넷 CIDR — IP 주소 범위 정의; /28은 16개, /27은 32개, /26은 64개 주소. ▸ Availability Zone — 각 AZ는 독립 물리 인프라; 서브넷은 단일 AZ에 속함. ▸ Elastic IP — 퍼블릭 IP(VPC의 IP 풀과 별도)로 서브넷 IP 부족과 무관. 【정답 포인트】 ▸ 서브넷은 생성 후 CIDR 변경 불가(AWS 제한). ▸ 프라이빗 서브넷은 단일 AZ에 속하므로 "확장" 불가. ▸ 새로운 서브넷 생성이 유일한 IPv4 주소 확보 방법. ▸ Elastic IP는 프라이빗 IP와 분리된 풀. 【오답 체크】 (A) 기존 서브넷 CIDR 변경 불가능(AWS 아키텍처 제약). (B) 서브넷은 한 AZ에만 속함; AZ 확장 불가. (C) Elastic IP는 대역폭 풀이 아니라 퍼블릭 IP; EC2 인스턴스 증가와 무관. 【시험 포인트】 ▸ 서브넷 IP 부족 → 새 서브넷 생성 유일 해법. ▸ CIDR 변경, AZ 확장은 AWS 기술 제약으로 불가. ▸ VPC 계획 시 충분한 CIDR(/'24 이상) 미리 할당 권장.

해설

【핵심 용어】 ▸ EventBridge Archive — 이벤트를 저장하여 나중에 재생 가능하게 하는 기능입니다. ▸ 사용자 정의 이벤트 버스 — 조직 특정 이벤트 스트림용 독립 이벤트 버스입니다. ▸ Pipe — 이벤트 소스에서 대상으로 라우팅하는 추가 변환 메커니즘입니다. 【정답 포인트】 ▸ "사용자 정의 애플리케이션 이벤트"→사용자 정의 이벤트 버스(기본 버스 대신). ▸ Archive는 이벤트 버스에 생성되며 필터/패턴으로 자동 기록. ▸ 규칙을 통해 Lambda로 동시 라우팅. 【오답 체크】 (B) 기본 버스는 AWS 시스템 이벤트용; 사용자 정의 이벤트는 분산될 가능성. (C) Pipe는 추가 변환 필요 시 사용; 단순 기록/재생에는 과잉. (D) CloudWatch Logs는 구조화된 재생/필터링 기능 부족; EventBridge Archive보다 조회 기능 제한. 【시험 포인트】 ▸ "사용자 정의 이벤트" + "재생" → Archive 기능 필수. ▸ 사용자 정의 이벤트 버스는 격리된 이벤트 네임스페이스. ▸ Archive는 자동 필터링, 타임스탬프 기반 재생 지원.

해설

【핵심 용어】 ▸ AMI — 특정 리전 한정 리소스(ID는 리전별로 고유). ▸ IAM — 전역 서비스(리전 무관)로 모든 리전에서 동일합니다. ▸ 리전별 서비스 가용성 — 일부 AWS 서비스는 특정 리전에만 제공됩니다. 【정답 포인트】 ▸ AMI는 리전 한정(us-west-2 AMI ID는 eu-west-1에 없음). ▸ 새 리전 배포 시 리전별 AMI ID 조정 필수. ▸ 일부 신규 서비스는 특정 리전에만 출시. 【오답 체크】 (A) IAM 사용자는 전역 리소스(모든 리전에서 동일 접근 가능). (C) 권한 부족은 "부분 배포 + 롤백"이 아닌 "배포 거부" 오류 발생. (E) CloudFormation은 신규 스택 생성도 가능; 잘못된 설명. 【시험 포인트】 ▸ 리전 간 템플릿 이동 → AMI 리전별 ID 조정 필수. ▸ IAM은 전역; 리전 간 이동 시 신경 쓸 필요 없음. ▸ 신규 서비스는 리전 가용성 확인 권장.

해설

【핵심 용어】 ▸ Origin Access Control(OAC) — CloudFront만 S3 접근을 허용하는 보안 메커니즘(구형 OAI 대체). ▸ Bucket Policy — 버킷 수준 접근 제어로 특정 CloudFront 배포만 허용. ▸ 자동화 — 직원 수동 개입 최소화가 목표. 【정답 포인트】 ▸ CloudFront + OAC = 자동화된 CDN 배포(CDN 캐싱 이점). ▸ "최소 행정 노력"→직원 수동 다운로드/배포 제거. ▸ Bucket Policy는 CloudFront 배포 ID 기반으로 접근 제어(공용 차단 유지). 【오답 체크】 (A) 직원이 수동으로 파일 다운로드 후 배포(행정 작업 과다). (C) 공용 접근 허용은 보안 정책 위반(요구사항: "계정 수준 공용 차단"). (D) Signed URL은 수동 생성; 자동화 미흡(직원 개입 필요). 【시험 포인트】 ▸ 공용 접근 차단 + 웹 배포 → CloudFront + OAC 패턴. ▸ OAC는 최신 보안(OAI는 구형). ▸ 자동화된 솔루션은 CloudFront 배포 URL로 직접 제공.

해설

【핵심 용어】 ▸ CRR(Cross-Region Replication) — 새로운 객체의 자동 복제 설정입니다. ▸ S3 Batch Replication — 기존 객체를 일괄 복제하며 실패 항목 재시도 가능합니다. ▸ Lifecycle Rules — 객체 이동/삭제 정책(복제 아님). 【정답 포인트】 ▸ "기존 객체"→CRR만으로는 과거 객체 복제 불가. ▸ S3 Batch Replication은 기존 객체 대량 복제 + 재시도 기능. ▸ "재시도"→Batch 기능만 명시적 재시도 지원. 【오답 체크】 (A) 라이브 복제는 신규 객체만; 기존 객체 미포함. (C) S3 RTC는 복제 완료 시간 보장(15분 이내); 기존 객체 복제용 아님. (D) Lifecycle은 리전 간 이동 불가(같은 리전 내 스토리지 클래스 변경만). 【시험 포인트】 ▸ 기존 데이터 + 규제 복제 요구 → S3 Batch Replication. ▸ CRR은 자동화(신규); Batch는 수동 트리거(기존). ▸ 실패 재시도는 Batch 기능.

해설

【핵심 용어】 ▸ CloudWatch Agent — EC2 인스턴스 내부 메트릭(메모리, 디스크) 수집용 소프트웨어입니다. ▸ mem_used_percent — 에이전트가 제공하는 메모리 사용률 메트릭입니다(기본 모니터링은 미제공). ▸ 기본 vs 상세 모니터링 — 기본은 CPU만, 상세는 추가 메트릭(5분 단위). 【정답 포인트】 ▸ "RAM 사용률" → CloudWatch Agent 필수(기본 모니터링은 CPU만). ▸ "5분 간격" → 기본 모니터링도 5분 단위 제공(상세 불필요). ▸ mem_used_percent는 에이전트 전용 메트릭(기본 모니터링은 미제공). 【오답 체크】 (A) mem_active는 표준 메트릭 아님(에이전트로도 미제공). (B) mem_used_percent는 상세 모니터링 표준 메트릭이 아님(에이전트용만). (D) mem_used_percent는 기본 모니터링 제공 안 함(에이전트 필수). 【시험 포인트】 ▸ EC2 메모리 메트릭 = CloudWatch Agent + mem_used_percent. ▸ 기본 모니터링(5분)은 충분; 상세(1분) 불필요. ▸ 에이전트는 IAM 역할로 CloudWatch에 데이터 업로드 권한 필요.

해설

【핵심 용어】 ▸ AWS Control Tower — 계정 거버넌스, 규제 준수용 관리 서비스입니다. ▸ Region Deny Controls — 특정 리전 접근 차단(200+ 계정에 자동 적용). ▸ Service Control Policy(SCP) — 조직 수준 권한 거부(루트 포함 모든 사용자 영향). 【정답 포인트】 ▸ "200개 이상 계정" + "중앙 집중식" → Control Tower 자동 적용. ▸ "리전 거부"→Control Tower의 Region Deny 컨트롤. ▸ "루트 사용자 차단" + "CloudTrail 삭제 방지"→SCP로 구현(루트 사용자도 범위). ▸ 자동 적용은 Control Tower 거버넌스 정책. 【오답 체크】 (A) AWS Config는 감지 전용; 선제적 차단 불가. 개별 계정 설정(중앙화 미흡). (B) Security Hub는 탐지/규제 준수; CloudTrail 삭제 방지 불가. (D) Firewall Manager는 네트워크 보안; 루트 사용자 접근/CloudTrail 삭제 방지 불가. 【시험 포인트】 ▸ 다중 계정 거버넌스(200+) → AWS Control Tower 필수. ▸ Region Deny는 Control Tower의 관리형 컨트롤. ▸ SCP는 권한 거부(모든 사용자); 권한 부여 불가.

해설

【핵심 용어】 ▸ Systems Manager Inventory — EC2 인스턴스 메타데이터 및 패치 정보를 자동 수집합니다. ▸ Run Command — 명령 실행(수집 자동화 안 됨, 수동 선택 필요). ▸ AWS Config — 구성 변경 추적(패치 메타데이터 자동 수집 아님). 【정답 포인트】 ▸ "패치 버전" 자동 수집 → Systems Manager Inventory(기본 기능). ▸ "모든 인스턴스 보고"→Inventory의 쿼리/보고서 기능으로 자동화. ▸ 운영상 효율 = 자동 수집 + 쉬운 보고서 생성. 【오답 체크】 (B) Run Command는 명령 실행; Inventory처럼 자동 메타데이터 수집 아님. (C/D) AWS Config는 구성 변경 감지용; 패치 정보 자동 수집 기능 없음(커스텀 규칙 필요로 복잡). 【시험 포인트】 ▸ 인스턴스 메타데이터 수집 = Systems Manager Inventory. ▸ 자동 보고서 생성은 Inventory 쿼리. ▸ Run Command는 개별 실행 명령(배치 자동화 미흡).

해설

【핵심 용어】 ▸ AWS Compute Optimizer — 인스턴스 크기 조정 권장사항을 제공합니다. ▸ 인스턴스 유형 지원 — 일부 신규/특수 인스턴스 유형은 미지원(e.g., 극한 성능 인스턴스). 【정답 포인트】 ▸ "새로 출시된 인스턴스 유형" 언급→일부 신규 유형은 Compute Optimizer 미지원. ▸ 미지원 유형은 분석 대상에서 제외(대시보드 미표시). ▸ 기술적 원인은 지원 범위, 메트릭 부족 아님. 【오답 체크】 (A) CloudWatch 메트릭 부족 시 권장사항 미생성이지만, 인스턴스는 대시보드에 표시(권장사항 없음으로). (C) 최적화된 상태는 "권장사항 없음"으로 표시; 누락 아님. (D) Windows 인스턴스도 지원; OS는 무관. 【시험 포인트】 ▸ 새 인스턴스 유형 언급 + 대시보드 누락 → 지원 불가 패턴. ▸ Compute Optimizer는 실시간 지원 범위 명시(AWS 공식 문서).

해설

【핵심 용어】 ▸ Amazon GuardDuty — 머신 러닝 기반 위협 탐지(API 활동, 비정상 로그인, 의심 동작 감지). ▸ CloudWatch Logs — 애플리케이션 로그 저장(GuardDuty가 분석 가능). ▸ CloudTrail Insights — "비정상" API 활동(높은 호출 빈도 등)만 탐지. 【정답 포인트】 ▸ "비정상적인 API 활동" + "보안 이벤트" → GuardDuty(보안 위협 전문). ▸ GuardDuty는 CloudWatch Logs, VPC Flow Logs, CloudTrail 자동 분석. ▸ 머신 러닝 기반 탐지로 자동화. ▸ "모니터링"이 핵심(원점). 【오답 체크】 (A) Amazon Inspector는 애플리케이션 취약점 스캔; API 활동 탐지 아님. (C) CloudTrail Insights는 비정상 활동(높은 빈도)만; 보안 이벤트 해석 제한적. (D) AWS Config는 구성 변경 감지; 보안 위협 탐지 아님. 【시험 포인트】 ▸ "위협" + "자동 탐지" → GuardDuty 필수. ▸ GuardDuty는 CloudWatch Logs 분석 가능(설정 필요). ▸ Amazon Inspector는 취약점 스캔(동적 분석).

해설

【핵심 용어】 ▸ AWS Lambda — 서버리스 함수 실행(초당 단위 비용, 미사용 시 비용 없음). ▸ S3 Event Notifications — S3 객체 변경 시 이벤트 트리거(자동화). ▸ 30~120초 처리 시간 — Lambda 제한(15분) 내 충분(비용 최적). 【정답 포인트】 ▸ "가장 비용 효율적"→Lambda(서버리스, 초 단위 과금). ▸ S3 직접 이벤트로 Lambda 호출. ▸ "항상 켜져" EC2 실행 비용 제거. ▸ 처리 시간(30~120초)은 Lambda 범위(최대 900초). 【오답 체크】 (A) 항상 켜진 EC2 인스턴스 유지 비용(비효율). (B) AWS Glue는 ETL용(데이터 변환); 단순 이미지 처리엔 과잉. (D) ECS는 컨테이너 오버헤드(시작 시간 증가); Lambda보다 느림. 【시험 포인트】 ▸ 이벤트 기반 + 단시간 처리 → Lambda 최우선. ▸ 항상 켜진 리소스 대체 = 비용 절감. ▸ S3 Event + Lambda 패턴은 표준 구성.

해설

【핵심 용어】 ▸ EventBridge 리소스 기반 정책 — 이벤트 버스의 접근 제어(PutEvents 권한 포함). ▸ IAM 역할 + Bucket Policy — 양쪽 모두 필요(IAM은 발신자, 리소스 정책은 대상). ▸ Cross-Account 이벤트 라우팅 — 정책 조합으로 구성. 【정답 포인트】 ▸ IAM 역할만으로는 부족(발신자 권한만 확인). ▸ 대상 이벤트 버스의 리소스 기반 정책도 필요(발신자 계정 ID 명시). ▸ "PutEvents 허용"은 IAM + 리소스 정책 양쪽 필수. ▸ 리소스 정책이 누락되어 "Access Denied". 【오답 체크】 (A) VPC 엔드포인트는 네트워크 격리(선택사항); 기본 요구사항 아님. (B) Lambda는 다른 리전과 상호작용 가능(VPC 없음). (D) 계정 매개변수는 선택사항(이벤트 필터링용); 필수 아님. 【시험 포인트】 ▸ Cross-Account 이벤트 = IAM 역할 + 리소스 기반 정책. ▸ 리소스 정책이 발신자 계정 명시(Principal 필드). ▸ "Access Denied" 오류 시 정책 조합 검토.

해설

【핵심 용어】 ▸ S3 버전 관리 활성화 — 리전 전체 일관성 지연이 발생합니다(15분 정도). ▸ 404 NoSuchKey — 객체 메타데이터 지연으로 인한 임시 오류입니다. 【정답 포인트】 ▸ "버전 관리 활성화 직후" + "404 오류" → 활성화 지연 패턴(S3 내부 일관성). ▸ 15분 대기는 AWS 권장 절차(메타데이터 동기화). ▸ 재시도로 해결(정책 변경 필요 없음). 【오답 체크】 (A) 버전 관리 비활성화는 원인 제거 아님(요구사항 위반). (B) Bucket Policy는 권한 문제가 아님(S3 내부 지연). (D) Transfer Acceleration은 네트워크 최적화(지연 해결 안 함). 【시험 포인트】 ▸ S3 버전 관리 활성화 시 임시 404 오류 발생 가능. ▸ AWS 내부 메타데이터 동기화 시간 필요. ▸ 시간 경과 후 정상 작동으로 복구.

해설

【핵심 용어】 ▸ ObjectOwnerOverrideToBucketOwner — Cross-Account 복제 시 객체 소유권을 대상 버킷 소유자로 변경합니다. ▸ Cross-Account CRR — 소유권 문제로 복제 실패 가능. 【정답 포인트】 ▸ 소스 계정 IAM 역할 + 대상 계정 정책만으로는 부족. ▸ ObjectOwnerOverrideToBucketOwner 설정으로 대상 버킷 소유자 권한 명시. ▸ SSE-S3(소스) → SSE-S3(대상)는 호환(암호화 방식 동일). ▸ 이 권한이 누락되면 복제 거부. 【오답 체크】 (B) 다중 리전 키는 필요 없음(SSE-S3 호환). (C) VPC 엔드포인트는 선택사항(공개 엔드포인트 가능). (D) SSE-S3 → SSE-KMS도 가능하지만, SSE-S3 대상 가능. 【시험 포인트】 ▸ Cross-Account CRR = IAM 역할 + 버킷 정책 + ObjectOwnerOverrideToBucketOwner. ▸ 객체 소유권 변경 설정 필수. ▸ SSE-S3은 동일 암호화 방식으로 간단.

해설

【핵심 용어】 ▸ EC2 Instance Connect Endpoint — SSH 터널을 통해 프라이빗 EC2 인스턴스에 직접 연결할 수 있는 AWS 관리형 엔드포인트, 인터넷 게이트웨이나 NAT Gateway 없이 작동. Systems Manager Session Manager와 다른 서비스로, 인바운드 SSH 트래픽을 Security Group에서 열어야 함. 【정답 포인트】 ▸ "EC2 Instance Connect endpoint를 프라이빗 서브넷에" — 엔드포인트 자체가 프라이빗 EC2와 통신하기 위해 같은 VPC 내에 있어야 함. ▸ "인바운드 SSH 트래픽 허용" — 엔드포인트에서 오는 연결을 받기 위한 필수 설정. 【오답 체크】 (B) Systems Manager endpoint는 Session Manager용이며 SSH 프로토콜을 직접 지원하지 않음. (C) Instance Connect endpoint가 공개 서브넷에 있으면 프라이빗 인스턴스와 직접 통신할 수 없음. (D) Systems Manager endpoint는 공개 서브넷에 위치하며, PowerUserAccess 대신 SSM 권한이 필요함. 【시험 포인트】 ▸ Instance Connect Endpoint vs Session Manager 구분 — Instance Connect는 SSH 접근용, Session Manager는 브라우저 기반 셸 접근용. ▸ Endpoint 위치가 중요 — 같은 VPC 내 올바른 서브넷에 위치해야 기능함.

해설

【핵심 용어】 ▸ AWS Global Accelerator — AWS의 고정 IP 주소를 사용하여 전 세계 사용자의 트래픽을 최적의 AWS 리전 엔드포인트로 라우팅하는 서비스, 낮은 지연 시간과 높은 가용성 보장. 【정답 포인트】 ▸ "글로벌 사용자의 지연 시간 개선" — Global Accelerator의 Anycast IP와 AWS 글로벌 네트워크가 최단 경로로 라우팅. ▸ "ALB 앞에" — 기존 ALB 구조를 유지하며 성능 계층을 추가. 【오답 체크】 (B) NLB를 ALB 앞에 배포하면 계층이 증가하지만 지역적 지연 개선에는 효과 없음. (C) NLB로 교체해도 단일 리전(us-east-1) 구조이므로 글로벌 지연 시간 개선 불가. (D) Route 53 상태 확인은 리전 간 장애 조치를 지원하지만, 다른 리전의 리소스가 없으면 작동 불가능. 【시험 포인트】 ▸ Global Accelerator — HTTP/HTTPS 외 모든 트래픽(TCP/UDP) 최적화. ▸ CloudFront와의 차이 — CloudFront는 콘텐츠 캐싱, Global Accelerator는 트래픽 라우팅.

해설

【핵심 용어】 ▸ Organizations tag policies — AWS Organizations에서 조직의 모든 계정과 리소스에 태깅 규칙을 강제할 수 있는 정책 유형, SCPs와 함께 작동. ▸ Cost allocation tags — AWS Billing 콘솔에서 활성화하면 비용 추적과 분석에 사용되는 태그. 【정답 포인트】 ▸ "tag policies로 필수 태그 강제" — 중앙 집중식으로 모든 계정의 리소스 태깅을 제어. ▸ "비용 할당 태그 활성화" — Billing 콘솔에서 활성화하면 자동으로 비용 추적에 반영, 추가 구성 불필요. 【오답 체크】 (B) Lambda 기반 자동화는 태그 지정을 자동화하지만 중앙 집중식 정책 강제가 아니며 운영 오버헤드 증가. (C) AWS Config는 태깅 규정 준수를 평가만 하고, AWS Budgets는 비용 할당 태그를 적용하지 않음. (D) Service Catalog는 프로비저닝 시에만 적용되고, Trusted Advisor는 태깅을 강제하지 않으며 권장사항만 제시. 【시험 포인트】 ▸ Tag Policies — Organizations 기능으로 조직 계정 전체에 적용. ▸ 비용 할당 태그 — Billing 콘솔에서 별도로 활성화 필요.

해설

【핵심 용어】 ▸ Systems Manager Patch Manager — AWS 기반 패치 관리 서비스로, SSM Agent가 설치된 EC2 인스턴스에 자동으로 OS 및 애플리케이션 패치를 적용. Patch Group과 Schedule을 정의하여 자동화. 【정답 포인트】 ▸ "SSM Agent 설치" — Patch Manager의 필수 전제 조건, 새로운 인스턴스에도 포함되어야 함. ▸ "운영 효율성" — 중앙 집중식 패치 관리로 대규모 인스턴스 자동화, 추가 스크립트 없음. 【오답 체크】 (A) Lambda의 SSH 연결은 보안 위험, 인스턴스별 SSH 키 관리 필요, 확장성 낮음. (C) Systems Manager Inventory는 인스턴스 정보 수집만 하며, 패치 설치 자동화 기능 없음. (D) EventBridge + 직접 OS 명령은 대상 지정이 복잡하고, 새 인스턴스 추가 시 규칙 수정 필요. 【시험 포인트】 ▸ Patch Manager — Systems Manager의 일부로 완전 자동화된 패치 관리 솔루션. ▸ Patch Group — 패치 적용 대상 인스턴스 그룹, 태그 기반으로 자동 관리.