정답 · 해설

해설

【핵심 용어】 ▸ X-Ray Service Map — 마이크로서비스 간 의존 관계와 성능 지표를 시각화 ▸ Trace Filtering — 응답 시간, 오류율로 문제 구간 식별 ▸ Subsegments — 함수/메서드 수준의 세분화된 타이밍 데이터 【정답 포인트】 ▸ (B) 가 효과적: 서비스 맵으로 전체 아키텍처 파악 → 필터링으로 문제 구간 축소 → 개별 추적으로 상세 분석 ▸ X-Ray는 분산 추적(Distributed Tracing)에 최적화 ▸ 응답 시간과 오류율 필터링이 병목 구간 빠른 식별 가능 【오답 체크】 ▸ (A) 커스텀 X-Ray 부분 세그먼트는 추가 개발 작업 필요 (최소 오버헤드 요구사항 위배) ▸ (C) (D) Container Insights는 인프라 메트릭(CPU, 메모리) 중심이지 분산 추적 아님 (요청 흐름 시각화 부족) 【시험 포인트】 ▸ 마이크로서비스 성능 문제 → X-Ray (분산 추적) 선택 ▸ Container Insights는 노드/컨테이너 리소스 모니터링용 ▸ 서비스 맵 + 필터링 = 효율적인 문제 격리 패턴

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — 조직 차원의 권한 경계 설정 ▸ Null Condition — 조건 키 존재 여부를 확인하는 연산자 ▸ lambda:VpcIds — Lambda 함수가 VPC에 연결되었는지 나타내는 조건 키 ▸ ProActive Control — Control Tower의 사전 배포 규칙 (CloudFormation 훅) 【정답 포인트】 ▸ (D) Null 연산자로 VpcIds 키 부재 시 거부 = 완벽한 차단 ▸ SCP는 모든 계정에 조직 차원으로 적용되므로 최소 오버헤드 ▸ VPC 미연결 함수 배포 시도 자체를 차단 (사후 감지 아님) 【오답 체크】 ▸ (A) Control Tower의 CloudFormation 훅은 강제성이 낮음 (SCP보다 약함) ▸ (B) StringEquals로 VPC ID 목록 확인은 복잡하고 VPC ID 관리 필요 ▸ (C) AWS Config는 사후 감지 도구이지 사전 차단이 아님 【시험 포인트】 ▸ 조직 차원 거부 → SCP (가장 강력) ▸ Null 조건 = 특정 키 존재 여부 체크 ▸ Lambda VPC 강제: Null:lambda:VpcIds 거부 패턴

해설

【핵심 용어】 ▸ Tags Class — CDK에서 앱 전체 또는 특정 구성에 태그를 적용하는 클래스 ▸ TagManager Class — 개별 리소스 수준 태그 관리 (세분화되지만 복잡) ▸ Custom CDK Construct — 재사용 가능한 인프라 컴포넌트 정의 ▸ Separate Stacks — 마이크로서비스 간 독립적인 배포 및 라이프사이클 관리 【정답 포인트】 ▸ (B) 의 조합: Tags 클래스 (앱 전체 태그) + 별도 스택 (유연한 배포) ▸ Tags 클래스는 자동으로 모든 하위 리소스에 태그 전파 ▸ 별도 스택으로 각 마이크로서비스를 독립적으로 관리 가능 【오답 체크】 ▸ (A) 단일 스택 = 하나의 마이크로서비스 변경이 전체에 영향 (비추천) ▸ (C) (D) Service Catalog는 IaC 소스 관리보다는 프로비저닝 카탈로그 (CDK와 중복) ▸ TagManager는 개별 리소스마다 설정해야 함 (비효율) 【시험 포인트】 ▸ CDK 태그 전파: Tags 클래스 > TagManager ▸ 마이크로서비스 독립성: 별도 스택 권장 ▸ CDK Construct 라이브러리 = 재사용 가능한 패턴의 기본

해설

【핵심 용어】 ▸ S3 RTC (Replication Time Control) — 15분 SLA로 객체 복제 시간 보장 ▸ Multi-Region Access Point — 단일 DNS명으로 여러 리전 S3 버킷에 접근 ▸ SubmitMultiRegionAccessPointRoutes — MRAP 라우팅 규칙을 변경하여 능동-수동 전환 ▸ Two-way Replication — 양방향 동기화 【정답 포인트】 ▸ (A) S3 RTC = 15분 요구사항 충족의 핵심 (SLA 보장) ▸ (B) MRAP 능동-수동 구성 = 단순한 관리, 자동 장애 조치 지원 ▸ (C) SubmitMultiRegionAccessPointRoutes = 필요시 수동으로 라우팅 변경 가능 ▸ 이 조합만으로 운영 부담 최소화 【오답 체크】 ▸ (D) Transfer Acceleration은 업로드 속도 증가일 뿐 복제 SLA 보장 안 함 ▸ (E) (F) Route 53 Application Recovery Controller는 MRAP보다 복잡하고 별도 구성 필요 【시험 포인트】 ▸ S3 복제 SLA → RTC 필수 ▸ 다중 리전 S3 관리 → MRAP (단순) ▸ 수동 장애 조치 → SubmitMultiRegionAccessPointRoutes API

해설

【핵심 용어】 ▸ AWS Device Farm — 관리형 테스팅 플랫폼 (기기 관리 자동화) ▸ Managed Testing Service — 물리/가상 디바이스 풀 제공 ▸ Auto-scaling — 테스트 부하 자동 처리 【정답 포인트】 ▸ (A) Device Farm = 완전 관리형 → 인프라 운영 비용 최소 ▸ 다양한 디바이스 유형 자동 관리 ▸ 부하 증가 시 자동 확장 내장 ▸ CodePipeline 통합 간단 【오답 체크】 ▸ (B) EC2 플릿 = 디바이스 에뮬레이터 운영, 패치 관리 필요 (오버헤드 높음) ▸ (C) ECS = 컨테이너 라이프사이클 관리 필요 ▸ (D) Lambda 커스텀 런타임 = 에뮬레이터 크기 제한 (Lambda 용량 한계) 【시험 포인트】 ▸ "최소 관리 오버헤드" → 관리형 서비스 선택 ▸ Device Farm = 모바일 테스팅 전문 서비스 ▸ 자동 확장 + 다양한 디바이스 = Device Farm 핵심 특징

해설

【핵심 용어】 ▸ CloudWatch Subscription Filter — CloudWatch 로그를 다른 서비스로 실시간 전송 ▸ Amazon Data Firehose — 버퍼링 + 배치 처리로 비용 효율적 ▸ S3 Glacier Deep Archive — 90일 이후 접근 드문 장기 보관용 (가장 저비용) ▸ Infrequent Access Log Class — CloudWatch 내 저비용 보관 옵션 【정답 포인트】 ▸ (D) 가 총비용 최소: - Firehose > Kinesis (배치 처리로 비용 저렴, 버퍼링 자동) - Deep Archive > Flexible Retrieval (180일 이후 검색 빈도 드뭄) ▸ 30일 CloudWatch + 90일 S3-IA + 이후 Deep Archive = 3단계 가격 최적화 【오답 체크】 ▸ (A) Kinesis는 스트리밍 방식 (배치 처리 아님, 비용 높음) ▸ (B) One Zone-IA는 단일 AZ (가용성 낮음, 데이터 보호 약함) ▸ (C) Glacier Instant Retrieval은 Deep Archive보다 비쌈 【시험 포인트】 ▸ 비용 최적화: 접근 빈도 감소에 따라 계층화된 스토리지 ▸ Firehose vs Kinesis: Firehose = 배치 기반 (저비용) ▸ 90-180일 간격: Flexible > Instant > Deep Archive (가격 순) ▸ 데이터 보호: Multi-AZ 필수 (One Zone-IA 제외)

해설

【핵심 용어】 ▸ CloudWatch Logs Metric Filter — 로그에서 특정 패턴 감지하여 메트릭 생성 ▸ CloudWatch Alarm — 메트릭 기반 경보 발생 ▸ CloudTrail Organization Trail — 조직 전체 이벤트 추적 ▸ Event-Driven — 이벤트 검사 최소 지연 【정답 포인트】 ▸ (C) 가 가장 간단하고 빠름: - CloudWatch Logs Metric Filter로 실패한 로그인 패턴 감지 - CloudWatch Alarm이 메트릭 기반 자동 알림 (거의 실시간) - 두 가지 서비스만 필요 (운영 오버헤드 최소) 【오답 체크】 ▸ (A) EventBridge는 CloudTrail S3 이벤트에 반응 (로그 분석 필요, 지연 생김) ▸ (B) Lambda + Athena 쿼리 = 5분 간격 폴링 (거의 실시간 아님) ▸ (D) Apache Flink = 복잡한 스트림 처리 (오버헤드 높음) 【시험 포인트】 ▸ 거의 실시간 알림: Metric Filter + Alarm (가장 빠름) ▸ CloudWatch Logs는 CloudTrail 로그 기본 지원 ▸ 최소 운영 노력: EventBridge/Lambda/Flink보다 Metric Filter 우선

해설

【핵심 용어】 ▸ AWS X-Ray — 분산 시스템의 요청 추적 및 성능 분석 ▸ X-Ray Service Map — 마이크로서비스 간 호출 흐름 시각화 ▸ X-Ray SDK — 애플리케이션 코드 계측으로 세부 타이밍 수집 ▸ DaemonSet — 모든 EKS 노드에서 X-Ray 데몬 실행 【정답 포인트】 ▸ (A) 가 분산 추적의 표준 솔루션: - CPU/메모리는 정상이므로 애플리케이션 로직/서비스 간 호출 지연이 원인 - X-Ray Service Map으로 지연점을 정확히 파악 가능 - DaemonSet 배포로 모든 마이크로서비스 자동 계측 【오답 체크】 ▸ (B) Container Insights = 노드/컨테이너 리소스 모니터링 (이미 확인됨) ▸ (C) 경보만으로는 지연 원인 파악 불가 ▸ (D) 타임아웃 증가는 문제 해결이 아님 (근본 원인 분석 필요) 【시험 포인트】 ▸ 마이크로서비스 성능 이슈 → X-Ray (분산 추적) ▸ 리소스 메트릭 정상 → 애플리케이션 로직 문제 ▸ EKS + 분산 시스템 → X-Ray DaemonSet 표준 패턴

해설

【핵심 용어】 ▸ CloudFormation Git Sync — Git 저장소의 변경사항을 CloudFormation 스택과 자동 동기화 ▸ Pull Request Workflow — Git 기반 코드 리뷰 프로세스 ▸ CodeConnections — AWS와 Git 저장소의 연결 관리 ▸ Git Native Review — 템플릿 변경사항이 자동으로 버전 관리됨 【정답 포인트】 ▸ (A) 가 가장 효율적: - CloudFormation Git Sync = 템플릿 변경과 스택 배포 자동 연계 - Git Pull Request = 표준 코드 리뷰 프로세스 (추가 구성 최소) - 롤백은 Git 커밋 히스토리로 관리 (자동화) 【오답 체크】 ▸ (B) 수동 검토만 추가 = 여전히 수동 프로세스 ▸ (C) Lambda는 자동화이지만 검토 기능 부족 ▸ (D) 수동 검토 + 파이프라인 = (B) 와 동일하게 오버헤드 【시험 포인트】 ▸ "최소 운영 오버헤드" → 자동화된 워크플로우 선택 ▸ CloudFormation Git Sync = 템플릿 버전 관리의 표준 ▸ Pull Request = 자동 리뷰 + 승인 게이트웨이

해설

【핵심 용어】 ▸ PARALLEL Mode — 여러 실행을 동시에 처리 ▸ QUEUED Mode — 이전 실행이 완료되지 않으면 대기열에 보관 ▸ SUPERSEDED Mode — 새 실행이 이전 실행을 취소 【정답 포인트】 ▸ (A) 의 조합: - pull_request: PARALLEL = 개발자는 빠른 테스트 피드백 원함 (대기 불필요) - main_branch: QUEUED = 각 배포 완료 후 다음 실행 (안정성) - 이 조합이 두 요구사항 모두 충족 【오답 체크】 ▸ (B) pull_request SUPERSEDED = 새 PR마다 이전 테스트 취소 (빠른 피드백 방해) ▸ (C) main_branch SUPERSEDED = 배포 도중 취소 가능성 (위험) ▸ (D) pull_request QUEUED = 모든 PR이 순차 처리 (개발자 피드백 지연) 【시험 포인트】 ▸ PARALLEL = 빠른 처리 필요한 경우 (PR 테스트) ▸ QUEUED = 순차 처리 필요한 경우 (프로덕션 배포) ▸ SUPERSEDED = 최신 실행만 필요한 경우 (취소 가능)

해설

【핵심 용어】 ▸ CodePipeline V2 — 새로운 파이프라인 유형 (트리거 필터, 향상된 모드 지원) ▸ QUEUED Mode — 이전 실행 완료 후 다음 실행 (이미지 푸시 순서 보장) ▸ Git Tags — 분기 대신 태그로 트리거 필터링 ▸ EventBridge Integration — ECR 푸시 이벤트 감지 후 배포 파이프라인 시작 【정답 포인트】 ▸ (A) 의 조합: - V2 + QUEUED = 태그 푸시 순서대로 처리 ("이전 실행 대기" 충족) - Tag Trigger = 분기가 아닌 태그 필터링 (Git 태그 푸시 감지) - EventBridge = ECR 푸시 이벤트로 배포 파이프라인 자동 시작 【오답 체크】 ▸ (B) SUPERSEDED = 새 태그마다 이전 실행 취소 (요구사항 위배) ▸ (C) (D) V1 = 트리거 필터 불가 (태그 필터링 미지원), 파이프라인 간 호출은 느림 【시험 포인트】 ▸ CodePipeline V2 = 새로운 트리거 필터 기능 ▸ Git Tags = 분기가 아닌 릴리스 태그 트리거 ▸ EventBridge = 크로스 파이프라인 이벤트 기반 트리거 (권장) ▸ QUEUED = 순차 처리 필요 시 (이미지 버전 순서 보장)

해설

【핵심 용어】 ▸ EKS Control Plane Logging — CloudWatch Logs로 자동 지원 ▸ Container Insights — CloudWatch 기반 EKS 노드/컨테이너 모니터링 ▸ CloudWatch Logs Insights — 로그 쿼리 및 분석 ▸ Managed Logging — 추가 인프라 설치 불필요 【정답 포인트】 ▸ (B) 가 가장 간단하고 통합됨: - EKS 컨트롤 플레인 로깅을 CloudWatch로 설정 (네이티브) - Container Insights로 노드/컨테이너 자동 수집 - 모든 로그가 CloudWatch에 중앙화 - CloudWatch Logs Insights로 통합 분석 가능 【오답 체크】 ▸ (A) Logstash + OpenSearch = 별도 인프라 운영 (오버헤드 높음) ▸ (C) S3 + Athena + QuickSight = 복잡한 파이프라인 (관리 부담) ▸ (D) ADOT + Firehose + Redshift = 분석 인프라 복잡 【시험 포인트】 ▸ EKS 통합 로깅 → CloudWatch (기본) ▸ 노드 모니터링 → Container Insights ▸ "최소 운영 오버헤드" → 관리형 서비스 선택 ▸ API 서버 로그 = EKS 제어 플레인 로깅 범위

해설

【핵심 용어】 ▸ PrincipalTag — IAM 사용자/역할에 적용된 태그 ▸ ResourceTag — AWS 리소스에 적용된 태그 ▸ StringEquals ResourceTag — 리소스 태그가 특정 값과 일치할 때만 허용 ▸ AssumeRole with Condition — 태그 조건으로 역할 가정 제한 【정답 포인트】 ▸ (A) 각 프로젝트별 역할 생성 (프로젝트 + 직무 분리) ▸ (B) 기존 정책에 ResourceTag:project 조건 추가 (PrincipalTag 매칭) ▸ (C) 사용자에게 역할 가정 권한 정책 부여 (태그 기반 조건) ▸ 이 조합으로 최소 권한 + 자동 프로젝트 격리 【오답 체크】 ▸ (D) 역할에 정책을 연결하면 역할 가정 조건 부족 (신뢰 정책 불명확) ▸ (E) IAM 정책에 태그 불가 (정책은 태깅 대상 아님) ▸ (F) IAM 그룹은 권한 위임용 (역할 가정은 별도 처리 필요) 【시험 포인트】 ▸ 태그 기반 접근 제어: PrincipalTag ↔ ResourceTag 매칭 ▸ 역할 생성 + 정책 조건 + 가정 권한 = 3단계 구성 ▸ "최소 권한" = 프로젝트별 격리 + 직무별 권한 (ABC 조합 필수)

해설

【핵심 용어】 ▸ StatusCheckFailed_System — AWS가 호스트 하드웨어 문제 감지 시 발생하는 상태 확인 실패 ▸ StatusCheckFailed_Instance — EC2 인스턴스 운영 체제 문제 (별도) ▸ EC2 Recover Action — 인스턴스를 같은 호스트에서 재시작 (데이터 유지) ▸ CloudWatch Alarm → EC2 Action — 자동 복구 트리거 【정답 포인트】 ▸ (C) 가 정확한 솔루션: - StatusCheckFailed_System = 네트워크 손실 포함 하드웨어 문제 감지 - CloudWatch Alarm으로 자동 모니터링 - EC2 Recover Action = 인스턴스 데이터 보존 (중요) 【오답 체크】 ▸ (A) Auto Scaling 1:1 = 복구가 아닌 교체 (EBS 데이터 손실) ▸ (B) 라이프사이클 훅 = 종료 시만 작동 (자동 복구 아님) ▸ (D) NetworkOut 메트릭은 트래픽 측정 (네트워크 손실 감지 불가) 【시험 포인트】 ▸ 호스트 하드웨어 문제 감지 → StatusCheckFailed_System ▸ 자동 복구 → EC2 Recover Action (Reboot 아님) ▸ 데이터 유지 필요 → Auto Scaling 교체 불가

해설

【핵심 용어】 ▸ AWS Systems Manager Patch Manager — 패치 배포 자동화 및 관리 ▸ Patch Baseline — 승인된 패치 목록 정의 ▸ AWS Config — 규정 준수 모니터링 ▸ Systems Manager Automation — 패치 적용 워크플로우 자동화 【정답 포인트】 ▸ (A) 가 엔드투엔드 자동화 솔루션: - Patch Manager = 패치 배포 관리 - Patch Baseline = 적용할 패치 규정 - AWS Config = 준수 상태 모니터링 - Systems Manager Automation = 정책 위반 시 자동 교정 【오답 체크】 ▸ (B) SSH 수동 접근 = 자동화 아님 (운영 부담) ▸ (C) Auto Scaling으로 인스턴스 교체 = 다운타임 발생 ▸ (D) CloudFormation + CloudTrail = 모니터링만 가능 (자동 교정 아님) 【시험 포인트】 ▸ 자동화된 패치 관리 → Patch Manager + Config ▸ 준수 강제 → Systems Manager Automation (교정) ▸ "자동화" 키워드 → Patch Manager 우선 선택

해설

【핵심 용어】 ▸ CloudWatch Synthetics Canaries — 실제 사용자 경험을 시뮬레이션하는 자동 테스트 ▸ Canary Test — 배포 전 검증 (카나리 배포 패턴) ▸ CloudWatch Alarm Integration with ECS — 경보가 ECS 롤백 직접 트리거 ▸ Pre-deployment Validation — 트래픽 라우팅 전 검증 【정답 포인트】 ▸ (D) 가 가장 간단하고 효과적: - CloudWatch Synthetics = 중요 사용자 여정 + API 엔드포인트 검증 - 새 배포에서 카나리 실행 (프로덕션 트래픽 전) - 카나리 실패 → CloudWatch Alarm → ECS 자동 롤백 - 관리형 서비스만 사용 (최소 오버헤드) 【오답 체크】 ▸ (A) Lambda 커스텀 로직 = 개발 및 관리 필요 (오버헤드) ▸ (B) Step Functions + 워크플로우 = 복잡한 오케스트레이션 ▸ (C) X-Ray + Lambda 커스텀 분석 = 추가 개발 필요 【시험 포인트】 ▸ "최소 운영 오버헤드" → 관리형 서비스 조합 ▸ Canary 배포 패턴 = CloudWatch Synthetics 최적 활용 ▸ 배포 검증 → 자동 롤백 (ECS 기본 제공 통합)

해설

【핵심 용어】 ▸ CloudWatch Central Monitoring — 여러 계정의 로그를 중앙 계정으로 수집 ▸ CloudFormation StackSet — 조직 전체에 자동 배포 ▸ CloudWatch Logs Organization Policy — 조직 수준 로그 수집 활성화 ▸ Managed Service — 인프라 운영 최소화 【정답 포인트】 ▸ (A) 가 가장 간단하고 확장 가능: - 중앙 로그 계정에서 CloudWatch 데이터 소스 활성화 - 조직 ID 지정 → 자동으로 모든 계정 포함 - StackSet으로 필요한 설정을 조직의 모든 계정에 자동 배포 - AWS 완전 관리형 (KMS 암호화 지원) 【오답 체크】 ▸ (B) Firehose는 각 계정에서 중앙으로 설정 (복잡한 배포) ▸ (C) OpenSearch + SQS + Lambda = 최대 운영 부담 ▸ (D) 각 계정에 Firehose 스트림 개별 생성 (관리 부담) 【시험 포인트】 ▸ 조직 수준 로그 수집 → CloudWatch 중앙 모니터링 (표준) ▸ 자동 배포 → CloudFormation StackSet ▸ "최소 운영 오버헤드" → 관리형 중앙화 서비스 ▸ KMS 암호화 = CloudWatch 기본 지원

해설

【핵심 용어】 ▸ Advanced Tier Parameter — 더 큰 파라미터 크기 지원 (민감 데이터에 권장) ▸ Customer Managed KMS Key — 회사가 직접 제어하는 암호화 키 ▸ AWS RAM Resource Share — AWS 계정 간 리소스 공유 ▸ Cross-account Access — 별도 계정의 파라미터 접근 【정답 포인트】 ▸ (A) Advanced Tier = 큰 자격증명 데이터 지원 (권장) ▸ (E) Customer Managed KMS = 회사가 암호화 제어 ("회사가 관리하는 키" 요구사항) ▸ (F) AWS RAM = 중앙 계정에서 CI/CD 계정으로 파라미터 공유 권한 설정 ▸ 이 조합으로 보안 + 크로스 계정 접근 달성 【오답 체크】 ▸ (B) Parameter ARN만 추가 = 여전히 암호화 키 문제 (복호화 권한 필요) ▸ (C) Standard Tier = 작은 크기만 지원 (데이터베이스 자격증명 부족) ▸ (D) AWS Managed KMS = "회사가 관리" 요구사항 위배 【시험 포인트】 ▸ 크로스 계정 Parameter 접근: RAM + Custom KMS 필수 ▸ 민감한 자격증명 → Advanced Tier + Customer Managed KMS ▸ "회사가 관리하는 키" → Customer Managed KMS (AWS Managed 아님)

해설

【핵심 용어】 ▸ Level 3(L3) 컨스트럭트 — L2에서 생성된 고수준 추상화로 특정 비즈니스 패턴 구현 ▸ 단일 스택 세트 — 환경별 커스터마이제이션을 매개변수로 처리 【정답 포인트】 ▸ L3 컨스트럭트 사용 → 비즈니스 로직 중심의 재사용 가능 컴포넌트 생성 ▸ 단일 배포 스택 + 환경 매개변수 → 코드 중복 최소화, 관리 오버헤드 감소 ▸ 일관성 + 유연성 → L3의 추상화 수준이 최적 【오답 체크】 (A) L1 컨스트럭트는 저수준(CloudFormation 기본), 비즈니스 패턴 구현에 부적합 (B) 별도 스택 생성 → 관리 복잡도 증가, 코드 중복 위험 (D) L3+별도 스택 → 오버헤드 증가, 요구사항("최소 개발 오버헤드")과 불일치 【시험 포인트】 CDK construct levels: L1(원시적)-L2(일반적)-L3(패턴) 이해 필수. 반복 패턴 + 환경 관리 = L3+단일 스택 조합이 표준 아키텍처 패턴입니다.

해설

【핵심 용어】 ▸ Application Auto Scaling — ECS 서비스의 동적 확장 ▸ Target Tracking — SQS 큐 메트릭 기반 자동 조정 ▸ Fargate — 서버리스 컨테이너, 자동 스케일링 지원 【정답 포인트】 ▸ Application Auto Scaling 등록 → ECS 서비스 인스턴스 수 자동 조정 ▸ Target Tracking 정책 → ApproximateNumberOfMessagesVisible 등 SQS 메트릭 사용 ▸ 버스트 트래픽 시 자동 scale-out → 처리 시간 단축 ▸ Fargate 유지 → 서버 관리 오버헤드 없음, 비용 최적화 【오답 체크】 (B) 배치 수/폴링 개선 → 처리 시간 영향 미미, 버스트 대응 불가 (C) EventBridge 전환 → 아키텍처 변경 필요, 추가 복잡도 (D) EC2 Auto Scaling Group → Fargate 대체 필요, 서버 관리 오버헤드 증가 【시험 포인트】 SQS+Fargate 버스트 처리 = Application Auto Scaling의 target tracking. ApproximateNumberOfMessagesVisible 메트릭이 핵심입니다.