정답 · 해설

해설

【핵심 용어】 ▸ Cluster Placement Group — 네트워크 지연 최소화를 위해 인스턴스를 물리적으로 가깝게 배치하는 전용 하드웨어 그룹 ▸ Auto Scaling Group — 동적 확장성을 제공하는 논리적 그룹 ▸ Partition Placement Group — 하드웨어 장애 격리 목표 【정답 포인트】 ▸ "최소 지연"→Cluster Placement Group (C) ▸ "탄력적 계층"→Auto Scaling Group (C) ▸ 단일 서브넷 내 배치→네트워크 지연 최소화 ▸ 다중 AZ 배치→Placement Group 정의상 동일 하드웨어 랙에 배치되어야 하므로 불가 【오답 체크】 (A) EFS는 고성능 컴퓨팅과 무관한 파일 시스템 서비스로, 노드 간 지연 시간 감소에 직접적 효과 없음. 분산 스토리지이므로 오히려 지연 증가 가능. (B) Multi-AZ NLB는 가용성 향상이지만 HPC의 지연 시간 요구사항과 무관. 여러 AZ에 분산되면 지연 시간 증가. (E) Partition Placement Group은 하드웨어 장애 격리용으로 노드 간 거리가 더 멈. HPC 최소 지연 요구사항 미충족. 【시험 포인트】 ▸ Placement Group 종류별 특성 구분 필수 — Cluster(저지연), Spread(장애격리), Partition(대규모분산) ▸ "탄력성"과 "최소지연" 동시 만족 ▸ Auto Scaling의 동적 확장 특성 이해

해설

【핵심 용어】 ▸ CloudFront — 엣지 로케이션에서 콘텐츠 캐싱하는 CDN 서비스, S3 버킷 부하 감소 ▸ Cross-Region Replication — 데이터 복제만 수행, 캐싱 기능 없음 ▸ ElastiCache — 인메모리 캐시이지만 정적 웹 콘텐츠 배포용 아님 【정답 포인트】 ▸ "부하 감소"→CloudFront 엣지 캐싱 (C) ▸ "지연 시간 최소화"→전 세계 엣지 로케이션에서 콘텐츠 서빙 ▸ 정적 콘텐츠 배포의 최적 솔루션 ▸ 높은 읽기 작업→원본 S3에 직접 접근 대신 CloudFront 캐시 활용 【오답 체크】 (A) 버킷 마이그레이션은 일부 사용자에게만 이점. 전 세계 사용자 지연 시간 감소 불가. (B) Cross-Region Replication은 데이터 복제일 뿐 캐싱 기능 없어 S3 부하 감소 효과 미미. 읽기 작업은 여전히 S3에서 처리. (D) ElastiCache는 애플리케이션 캐싱용이며, 정적 웹 콘텐츠의 엣지 배포에 적합하지 않음. S3 부하 감소 불가. 【시험 포인트】 ▸ CloudFront 구성의 부하 분산 효과 ▸ 정적 콘텐츠와 동적 콘텐츠 캐싱 전략 구분 ▸ S3 Read Throttling 해결책으로 CDN 필수

해설

【핵심 용어】 ▸ S3 Event Notification — 파일 업로드 직후 즉시 트리거되는 이벤트 기반 아키텍처 ▸ SNS Topic — 다수의 구독자에게 메시지 팬아웃 ▸ Fan-out Pattern — 하나의 이벤트로 여러 작업 트리거 ▸ Operationally Efficient — 자동화 + 저비용 + 관리 최소화 【정답 포인트】 ▸ "운영 효율"→SNS 팬아웃 패턴 (A) ▸ "즉시 처리"→S3 Event Notification (A) ▸ 하나의 SNS 주제→두 구독→이메일, Lambda 동시 처리 ▸ Lambda 재사용 불필요 ▸ CloudWatch의 정기적 폴링 불필요 【오답 체크】 (B) CloudWatch 알람은 메트릭 기반이며 객체 생성 직후 실시간 트리거 불가. 알람 상태 진입 지연 발생. (C) 매분 호출은 비효율적이며 실시간 처리 불가. 파일 업로드와 처리 시간 사이 최대 1분 지연. 불필요한 Lambda 호출 비용 증가. (D) 두 개의 S3 Event Notification은 SNS 팬아웃보다 구성 복잡도 높음. Lambda 중복 실행 가능성. 【시험 포인트】 ▸ Event-driven Architecture 선택의 중요성 ▸ SNS 팬아웃 패턴의 효율성 ▸ Lambda 구독자 재사용으로 코드 중복 회피

해설

【핵심 용어】 ▸ CloudWatch Synthetics Canary — 사용자 브라우저 동작을 시뮬레이션하는 합성 모니터링 도구 ▸ SuccessPercent Metric — Canary 성공률을 자동으로 제공 ▸ User-like Monitoring — 고객과 동일한 경로 및 동작 모방 【정답 포인트】 ▸ "고객과 동일한 경로"→Canary (A) ▸ "SuccessPercent 메트릭"→95% 임계값 정확 매핑 (A) ▸ 자동 알림 기능 포함 ▸ 추가 커스텀 메트릭 개발 불필요 【오답 체크】 (B) Route 53 Health Check는 기본 TCP/HTTP 연결 확인만 수행. 복잡한 고객 경로와 비즈니스 로직 시뮬레이션 불가. HealthCheckPercentageHealthy는 단순 상태 확인. (C) 단일 Lambda로 여러 경로 모니터링하면 복잡도 증가, 개별 경로별 실패 원인 파악 어려움. 커스텀 메트릭 없어 자세한 추적 불가. (D) 경로별 Lambda 함수 생성은 과도한 리소스 사용. Canary에 비해 관리 복잡도 높음. 자동 SuccessPercent 제공 안 함. 【시험 포인트】 ▸ CloudWatch Synthetics의 User-like 모니터링 특성 ▸ Canary의 자동 SuccessPercent 메트릭 생성 ▸ Route 53 Health Check vs Synthetics 구분 필수

해설

【핵심 용어】 ▸ Session Manager — SSH 키 없이 인스턴스 접근 가능한 Systems Manager 서비스 ▸ IAM Role — EC2가 AWS 서비스와 통신하는 권한 기반 ▸ Systems Manager Agent — Session Manager 통신을 위한 필수 요소 【정답 포인트】 ▸ "Agent 설치 완료"→IAM 권한 부족이 원인 (C) ▸ Session Manager는 SSH 키, Security Group 불필요 ▸ EC2 Instance Profile에 IAM 역할 필수 ▸ AmazonSSMManagedInstanceCore 또는 유사 정책 필요 【오답 체크】 (A) Session Manager는 Key Pair 기반 인증 불사용. Session Manager는 IAM 기반 액세스 제어. Key Pair 불필요. (B) Session Manager는 SSH 포트 22 사용 안 함. Agent와 Systems Manager 간 HTTPS 통신. Security Group 제약 없음. (D) EC2 인스턴스 ID는 자동으로 Systems Manager에 등록됨. 수동 구성 불필요. Agent 실행 중이면 자동 검색. 【시험 포인트】 ▸ Session Manager의 IAM 기반 인증 메커니즘 ▸ Instance Profile과 IAM Role의 관계 ▸ SSH/Key Pair와의 구분 필수

해설

【핵심 용어】 ▸ Secondary CIDR Block — 기존 VPC에 추가되는 보조 IPv4 주소 범위 ▸ Subnet — VPC 내 IP 주소 할당 단위 ▸ IPv4 Exhaustion — VPC 또는 서브넷의 사용 가능 IP 고갈 문제 【정답 포인트】 ▸ "사용 가능한 IPv4 주소 없음"→Secondary CIDR Block 추가 필요 (A) ▸ 추가 CIDR Block 후 새 서브넷 생성 (C) ▸ 기존 서브넷의 CIDR 수정 불가 ▸ IPv6는 문제 해결 불가 【오답 체크】 (B) IPv6는 IPv4 부족 해결 불가. 별도의 IPv6 주소 범위이며, 대부분 EC2 인스턴스는 IPv4 기본 요구. (D) VPC CIDR 블록은 생성 후 수정 불가능. AWS API 제약사항. (E) 기존 서브넷 CIDR은 수정 불가. 새 서브넷 생성으로만 추가 IP 범위 확보 가능. 【시험 포인트】 ▸ VPC CIDR 확장 전략 — Secondary Block 추가만 가능 ▸ Subnet 생성 필수 — VPC CIDR만으로 충분하지 않음 ▸ IPv4/IPv6 혼동 회피

해설

【핵심 용어】 ▸ Service Quotas — AWS 계정의 리소스 생성 상한선, 지역 및 리소스 유형별로 정의 ▸ On-Demand Instances Quota — 기본적으로 새 계정은 낮은 할당량으로 시작 ▸ Quota Request — AWS 서포트를 통해 할당량 증가 신청 【정답 포인트】 ▸ "Your quota allows for 0"→Service Quotas 문제 (C) ▸ 새 계정의 기본 할당량 부족 ▸ Service Quotas 콘솔에서 직접 증가 신청 가능 ▸ Instance Type Family별로 할당량 관리 【오답 체크】 (A) Billing 지출 한도는 할당량과 무관. 비용 제어 메커니즘일 뿐 인스턴스 생성 허용량 관계 없음. (B) EC2 Settings에는 Regional Quota 수정 기능 없음. Service Quotas가 정식 관리 도구. (D) Rebalance 작업은 기존 인스턴스의 가용 영역 분산용. 새 인스턴스 생성 오류 해결 불가. 【시험 포인트】 ▸ Service Quotas 관리 중앙화 ▸ 새 AWS 계정의 기본 할당량 이해 ▸ On-Demand vs Spot vs Reserved Instance Quota 구분

해설

【핵심 용어】 ▸ Export — CloudFormation Output을 다른 스택에서 접근 가능하게 공개 ▸ Fn::ImportValue — Export된 값을 다른 템플릿에서 참조 ▸ Cross-Stack Reference — 템플릿 간 리소스 공유 메커니즘 【정답 포인트】 ▸ "최소 관리 노력"→Export/ImportValue (A) ▸ 자동화된 참조 메커니즘 ▸ 수동 Parameter 입력 불필요 ▸ 스택 간 느슨한 결합 【오답 체크】 (B) Custom Resource는 Lambda 함수 개발 필요. 복잡도 증가, 유지보수 부담 증가. Export만으로 충분한 경우 과도한 솔루션. (C) Mapping은 단일 템플릿 내 데이터 구조. 템플릿 간 공유 불가. (D) Parameter는 스택 생성 시 수동 입력 필요. 자동화 기능 부족. 관리 노력 증가. 【시험 포인트】 ▸ CloudFormation Export/ImportValue 패턴 ▸ Cross-Stack Reference의 효율적 구현 ▸ Nested Stack vs Export 비교

해설

【핵심 용어】 ▸ Target Tracking Scaling Policy — 메트릭(CPU, ALB RequestCount 등) 기반 동적 확장 ▸ Scheduled Scaling Policy — 미리 정해진 시간에 용량 조정 ▸ Auto Scaling Group — 수평 확장(인스턴스 추가)을 자동화 【정답 포인트】 ▸ "랜덤한 트래픽 증가"→예측 불가능한 패턴 (C) ▸ Target Tracking — 실시간 메트릭 반응 (C) ▸ 수평 확장이 비용 효율적 ▸ Scheduled Policy는 예측 가능한 패턴용 【오답 체크】 (A) 인스턴스 크기 증대(Vertical Scaling)는 다운타임 발생. 무중단 확장 불가. 기존 인스턴스가 이미 최적 크기일 수 있음. (B) EventBridge 규칙으로 수동 인스턴스 추가는 자동화 미흡. CloudWatch Events와 EventBridge 결합도 복잡. Manual Scaling 같은 효과. (D) Scheduled Scaling은 예정된 시간의 트래픽 증가용(예: 주중 오전 9시). 랜덤 트래픽 증가에 반응 불가. 【시험 포인트】 ▸ Target Tracking vs Scheduled Scaling 선택 기준 ▸ Auto Scaling의 수평 확장 효율성 ▸ 실시간 메트릭 기반 정책의 유연성

해설

【핵심 용어】 ▸ gp3 — 범용 SSD, IOPS와 처리량 독립적 구성 가능, 비용 효율적 ▸ io1 — 고성능 SSD, IOPS당 비용 높음 ▸ EFS — 공유 NFS 파일 시스템, Windows 워크로드 미지원 ▸ FSx for Windows — Windows 전용 관리형 파일 서버, 고비용 【정답 포인트】 ▸ "10,000 IOPS 필요"→gp3 충분 (B) ▸ gp3는 최대 16,000 IOPS까지 지원 ▸ io1보다 저렴 ▸ 용량과 IOPS 분리 구성으로 최소 비용 달성 【오답 체크】 (A) io1은 IOPS당 비용이 gp3보다 높음. 같은 10,000 IOPS 달성 시 약 50% 더 비쌈. (C) EFS는 NFS 프로토콜로 Windows 지원 불가. Max I/O 모드도 Linux 최적화. (D) FSx for Windows는 관리형 서비스로 높은 기본 비용. EBS 블록 스토리지보다 훨씬 비쌈. 【시험 포인트】 ▸ gp3의 IOPS/처리량 독립 구성 특성 ▸ EBS 볼륨 타입별 가격 비교 ▸ Windows 워크로드와 스토리지 선택 매핑

해설

【핵심 용어】 ▸ CloudWatch Alarm — 메트릭 기반 조건 모니터링 및 자동 작업 트리거 ▸ EC2 Action — CloudWatch 알람에서 인스턴스 중지/종료 직접 수행 ▸ Operational Efficiency — 자동화 + 관리 최소화 + 비용 절감 【정답 포인트】 ▸ "자동화"→CloudWatch 알람 (B) ▸ "운영 효율"→AWS 관리형 서비스 활용 (B) ▸ EC2 기본 메트릭(CPU)으로 충분 ▸ 알람이 직접 EC2 작업 수행 ▸ 인스턴스 내 에이전트 불필요 【오답 체크】 (A) Cron 작업은 인스턴스 자체에서 실행. 종료되어야 할 인스턴스는 Cron 실행 불가능. 자동화 미흡. (C) CloudWatch Agent 설치는 추가 복잡도. 기본 CPU 메트릭으로 충분. 관리 부담 증가. (D) Run Command는 수동 스크립트 실행. 자동화 부족. 인스턴스마다 개별 명령 필요. 확장성 제한. 【시험 포인트】 ▸ CloudWatch 알람의 자동 EC2 작업 트리거 ▸ 기본 메트릭(CPU) vs 커스텀 메트릭 구분 ▸ 에이전트 설치의 불필요성

해설

【핵심 용어】 ▸ Access Key — AWS CLI 인증의 기본 요소 (Access Key ID + Secret Access Key) ▸ AWS CLI Authentication — Access Key 기반 credential 시스템 ▸ IAM User — AWS 서비스 접근 권한 관리 대상 【정답 포인트】 ▸ "AWS CLI 인증 실패"→Access Key 부재 (D) ▸ AWS CLI는 Access Key 필수 ▸ IAM 비밀번호는 Console 로그인용 ▸ SSH, 인증서는 AWS CLI와 무관 【오답 체크】 (A) IAM 비밀번호는 AWS Management Console 로그인용. AWS CLI는 Access Key 사용. (B) 서버 인증서는 SSL/TLS 통신용이 아님. AWS CLI는 기본적으로 암호화 통신 수행. (C) SSH 키 쌍은 EC2 인스턴스 접근용. AWS CLI 인증과 무관. 【시험 포인트】 ▸ AWS CLI 인증 메커니즘 — Access Key 기반 ▸ IAM 비밀번호 vs Access Key 구분 ▸ AWS CLI 구성 필수 요소 이해

해설

【핵심 용어】 ▸ AWS Config Managed Rule — 사전 정의된 규칙으로 자동 준수 모니터링 ▸ Systems Manager Automation Runbook — 자동화된 작업 실행 엔진 ▸ Operational Efficiency — 완전 관리형 서비스 조합 【정답 포인트】 ▸ "자동화"→Config + Systems Manager (D) ▸ Managed Rule — IAM 미사용 계정 기본 제공 규칙 ▸ Automation Runbook — AWS 서비스 통합 실행 ▸ 최소 관리 부담 【오답 체크】 (A) Step Functions + Lambda 조합은 커스텀 로직 필요. Config Managed Rule보다 복잡. 관리 부담 증가. (B) AWS Config Rule + EC2 배치는 EC2 인스턴스 유지 필요. 서버 관리 비용 및 복잡도 증가. (C) Python 스크립트는 수동 개발 및 유지보수. EC2 배치 관리 부담. 삭제는 비활성화보다 위험. 【시험 포인트】 ▸ AWS Config Managed Rule의 사전 정의된 규칙 활용 ▸ Systems Manager Automation의 자동 응답 메커니즘 ▸ Serverless vs EC2 기반 자동화 효율성 비교

해설

【핵심 용어】 ▸ CreationPolicy — 리소스 생성 완료를 대기하는 CloudFormation 정책, Timeout 설정 가능 ▸ Signal — 리소스가 완료됨을 CloudFormation에 알리는 메커니즘 ▸ Timeout Rollback — 지정된 시간 내 완료 신호 없으면 스택 롤백 【정답 포인트】 ▸ "프로세스 중단"→CreationPolicy with Timeout (B) ▸ OpsWorks의 cfn-signal으로 완료 신호 전송 ▸ 4시간 타임아웃 설정 ▸ 신호 없으면 스택 실패 및 롤백 【오답 체크】 (A) Conditions는 논리적 조건문. Timeout 기능 없음. 프로세스 중단 감지 불가. (C) DependsOn은 리소스 의존성 정의. Timeout 개념 없음. 순서 제어만 수행. (D) Metadata는 구성 데이터 저장소. CreationPolicy와 달리 자동 모니터링 불가. 【시험 포인트】 ▸ CreationPolicy의 Signal/Timeout 메커니즘 ▸ cfn-signal 통합 ▸ 스택 롤백 조건 이해

해설

【핵심 용어】 ▸ Compute Savings Plan — 리전, 인스턴스 타입 유연한 할인 플랜 ▸ Instance Savings Plan — 리전 내 특정 인스턴스 타입 할인 ▸ Standard Reserved Instances — 리전 + 인스턴스 타입 고정 ▸ Convertible Reserved Instances — 유연한 교환 가능 【정답 포인트】 ▸ "리전 마이그레이션"→리전 유연성 필요 (D) ▸ "1년 약정"→장기 할인 (D) ▸ Compute Savings Plan만 리전 간 마이그레이션 지원 ▸ 90개 인스턴스→인스턴스 수 증감은 할인 계속 적용 【오답 체크】 (A) Standard Reserved Instances는 특정 리전 고정. eu-west-1에서 eu-west-3로 마이그레이션하면 할인 손실. (B) Instance Savings Plan은 리전별로 구분. eu-west-1 plan은 eu-west-3 사용 시 할인 제외. (C) Convertible Reserved Instances는 속성 변경 가능하지만 리전 간 전환 불가. 여전히 특정 리전 기반. 【시험 포인트】 ▸ Savings Plan 종류별 유연성 차이 ▸ 리전 마이그레이션 시나리오에서 할인 지속 ▸ Compute Savings Plan의 광범위한 적용 범위

해설

【핵심 용어】 ▸ NAT Gateway — 공개 서브넷 배치, 개인 인스턴스의 인터넷 접근 중계 ▸ Route Table — 각 서브넷의 트래픽 라우팅 규칙 ▸ Public IP — NAT Gateway를 위한 필수 요소 【정답 포인트】 ▸ "개인 서브넷 인스턴스→인터넷"→NAT Gateway 필수 (A) ▸ NAT Gateway는 공개 서브넷 배치 (A) ▸ 개인 서브넷 라우팅→NAT Gateway (A) ▸ NAT Gateway의 기본 아키텍처 이해 【오답 체크】 (B) 공개 서브넷→NAT Gateway 경로는 불필요. 공개 서브넷은 이미 Internet Gateway 통해 인터넷 접근 가능. (C) 개인 서브넷에 NAT Gateway 배치 불가 — Public IP 할당 불가. NAT Gateway는 Public IP 필수. (D) NAT Gateway를 개인 서브넷에 배치하면 Public IP 획득 불가 — 기술적으로 불가능. 【시험 포인트】 ▸ NAT Gateway 배치 위치 — 공개 서브넷만 가능 ▸ 라우팅 방향 — Private→NAT (개인 서브넷 라우팅 테이블) ▸ NAT Instance vs NAT Gateway 차이

해설

【핵심 용어】 ▸ Application Load Balancer — HTTP/HTTPS 리다이렉트 규칙 지원 ▸ Network Load Balancer — TCP/UDP 계층, 리다이렉트 규칙 미지원 ▸ Listener — 포트 기반 트래픽 처리 규칙 【정답 포인트】 ▸ "HTTP→HTTPS 리다이렉트"→ALB의 규칙 기반 리다이렉트 (B) ▸ 포트 80(HTTP) + 포트 443(HTTPS) 각각 Listener (B) ▸ ACM 인증서는 443 포트에만 연결 (B) ▸ ALB의 리다이렉트 액션으로 구현 【오답 체크】 (A) 포트 80에 HTTPS Listener는 불가능. HTTPS는 포트 443이 표준. 포트 기반 프로토콜 매핑 오류. (C) ALB에서 TCP Listener는 기본 프로토콜. HTTP/HTTPS 계층 리다이렉트 규칙 적용 불가. (D) NLB는 TCP/UDP 계층만 지원. 애플리케이션 계층 리다이렉트 기능 없음. ALB만 지원. 【시험 포인트】 ▸ ALB vs NLB의 기능 차이 — 계층 7 vs 4 ▸ HTTP 리다이렉트 규칙은 ALB 전용 ▸ Listener 구성의 정확한 포트/프로토콜 매핑

해설

【핵심 용어】 ▸ Billing Alert — 관리 계정에서 활성화되어야 모든 멤버 계정에서 사용 가능 ▸ Consolidated Billing — AWS Organizations의 청구 통합 기능 ▸ Cost Anomaly Detection — AWS Cost Explorer의 비용 이상 탐지 기능 【정답 포인트】 ▸ "멤버 계정에서 Alarm 설정 불가"→관리 계정 설정 부족 (A) ▸ Billing Alert 활성화는 관리 계정에서만 가능 (A) ▸ 멤버 계정은 관리 계정 활성화 후 자동 이용 가능 【오답 체크】 (B) AWS RAM은 리소스 공유용. Billing Alert와 무관. 청구는 콘솔 권한으로 제어. (C) GuardDuty는 보안 위협 탐지 서비스. 청구 알람과 완전 무관. (D) AWS Config는 리소스 준수 모니터링. 청구 알람 기능 아님. 【시험 포인트】 ▸ AWS Organizations의 Consolidated Billing 관리 계정 역할 ▸ Billing Alert 활성화 위치 — Management Account의 Billing Preferences ▸ 멤버 계정의 권한 vs 관리 계정 설정 구분

해설

【핵심 용어】 ▸ awsvpc Network Mode — 각 작업이 ENI를 가지는 네트워크 모드, VPC Flow Logs 추적 가능 ▸ VPC Flow Logs — ENI 트래픽 캡처 및 모니터링 ▸ Bridge/Host Mode — 공유 ENI, VPC Flow Logs 추적 어려움 ▸ Task Network Interface — awsvpc 모드에서만 개별 ENI 할당 【정답 포인트】 ▸ "Task 간 트래픽 흐름"→VPC Flow Logs (B) ▸ 개별 Task ENI — awsvpc Mode 필수 (C) ▸ VPC Flow Logs는 ENI 단위 캡처 ▸ Bridge/Host 모드는 ENI 공유로 Task 간 구분 불가 【오답 체크】 (A) CloudWatch Logs는 애플리케이션 로그 저장. 트래픽 흐름 모니터링 불가. (D) Bridge Mode는 호스트 EC2의 ENI 공유. Task별 트래픽 분리 추적 불가. (E) Host Mode는 호스트 네트워크 직접 사용. Task별 트래픽 흐름 분석 불가. 【시험 포인트】 ▸ ECS Network Mode별 ENI 할당 방식 ▸ awsvpc의 VPC Flow Logs 호환성 ▸ Task 간 트래픽 모니터링을 위한 네트워크 구성 필수 요소

해설

【핵심 용어】 ▸ AWS CloudFormation StackSets: 여러 AWS 계정과 리전에 걸쳐 스택을 배포하고 관리할 수 있는 서비스입니다. AWS Organizations 통합을 통해 모든 계정에 자동으로 배포할 수 있습니다. IAM Role 관리를 중앙에서 수행할 수 있습니다. 【정답 포인트】 ▸ StackSets + Organizations 조합이 가장 운영 효율적입니다. 중앙 집중식 관리로 모든 계정에 동일한 IAM Role을 자동 배포합니다. 템플릿 변경 시 모든 계정에 동시에 반영되어 유지보수 비용이 최소화됩니다. 규모 확장 시에도 새 계정이 자동으로 포함되도록 설정 가능합니다. 【오답 체크】 ▸ (A) 단순 CloudFormation: 각 계정마다 수동으로 배포해야 하므로 자동화 불완전. (B) Directory Service: IAM Role 자동 생성이 아니라 Active Directory 사용자 연결만 가능. (C) Resource Access Manager: 공유 리소스 관리용이며 IAM Role 배포 전담이 아님. 60~90자 【시험 포인트】 ▸ SysOps 시험에서 자주 출제되는 Multi-Account 관리 문제입니다. StackSets의 핵심은 '한 번 정의, 여러 계정에 자동 배포'입니다. Organizations과의 조합으로 계정 기반 자동 배포 가능성을 높이는 것이 핵심입니다. 'Operational efficiency' 키워드가 있으면 자동화와 중앙 관리를 생각해야 합니다.