정답 · 해설

해설

【핵심 용어】 ▸ Amazon WorkSpaces — 완전관리형 DaaS(가상 데스크톱), 개인 기기로 클라우드 상 관리형 워크스테이션에 원격 접속 ▸ AWS Cloud9 — 클라우드 기반 IDE(코드 편집 환경), 원격 데스크톱 아님 ▸ AWS Outposts — 온프레미스에 AWS 인프라를 설치하는 하드웨어 ▸ Amazon Lightsail — 간편 VPS(가상 서버/웹앱 호스팅), 데스크톱 제공 목적 아님 【정답 포인트】 ▸ "재택 직원이 개인 기기로 관리형 워크스테이션에 접속" → 가상 데스크톱(DaaS)인 Amazon WorkSpaces가 정답 ▸ 관리형 원격 데스크톱 환경 제공이 핵심 요구사항 【오답 체크】 (B) Cloud9는 브라우저 기반 코드 IDE로 데스크톱 환경 제공 목적이 아님. (C) Outposts는 온프레미스용 물리 인프라로 원격 데스크톱과 무관. (D) Lightsail은 간편 서버/앱 호스팅용이지 사용자 데스크톱 제공용이 아님. 【시험 포인트】 "가상 데스크톱 / 원격 워크스테이션 / 개인 기기 접속" → Amazon WorkSpaces (DaaS).

해설

【핵심 용어】 ▸ Amazon Athena — S3 데이터를 표준 SQL로 직접 쿼리하는 서버리스 분석 서비스 ▸ AWS Glue — 서버리스 ETL/데이터 카탈로그 서비스, 직접 SQL 쿼리 도구 아님 ▸ AWS Lambda — 서버리스 컴퓨팅, 쿼리 엔진 아님 ▸ Amazon Kinesis — 실시간 스트리밍 데이터 수집/처리 【정답 포인트】 ▸ "S3 객체를 SQL 구문으로 직접 쿼리" → 서버리스 쿼리 엔진 Amazon Athena가 정확히 부합 ▸ 인프라 프로비저닝 없이 S3에 바로 SQL 실행 【오답 체크】 (A) Glue는 ETL/카탈로그 도구로 대화형 SQL 직접 쿼리 서비스가 아님. (C) Lambda는 코드 실행 컴퓨팅으로 SQL 쿼리 엔진이 아님. (D) Kinesis는 실시간 스트림 처리용이지 S3 정적 데이터 쿼리용이 아님. 【시험 포인트】 "S3 + SQL 직접 쿼리 + 서버리스" → Amazon Athena.

해설

【핵심 용어】 ▸ Multi-AZ deployment — RDS를 여러 AZ에 동기 복제 스탠바이로 배치해 고가용성(HA)과 자동 장애 조치 제공 ▸ Read replicas — 읽기 부하 분산(성능) 목적, 자동 페일오버 아님 ▸ Blue/green deployment — 무중단 배포/업데이트용 ▸ Reserved Instances — 비용 절감용 요금 약정 【정답 포인트】 ▸ "데이터베이스 고가용성 보장" → RDS Multi-AZ가 동기 스탠바이 + 자동 페일오버로 HA 실현 ▸ 가용성 = Multi-AZ (읽기 확장과 구분) 【오답 체크】 (A) Read replicas는 읽기 성능 확장용이며 자동 장애 조치를 보장하지 않음. (B) Blue/green은 안전한 배포 기법이지 상시 고가용성 기능이 아님. (D) Reserved Instances는 비용 최적화 요금제로 가용성과 무관. 【시험 포인트】 "RDS + 고가용성/자동 페일오버" → Multi-AZ. "읽기 성능/부하 분산" → Read replica.

해설

【핵심 용어】 ▸ AWS Fargate — 서버 관리 없이 컨테이너를 실행하는 서버리스 컴퓨팅 엔진(ECS/EKS와 연동) ▸ Amazon SQS — 메시지 큐 서비스, 컴퓨팅 아님 ▸ AWS Elastic Beanstalk — 앱 배포 관리(내부에 EC2 프로비저닝), 서버리스 아님 ▸ Amazon SageMaker — 머신러닝 플랫폼 【정답 포인트】 ▸ "컨테이너용 서버리스 컴퓨팅" → 인프라 프로비저닝 없이 컨테이너를 구동하는 AWS Fargate가 정답 【오답 체크】 (A) SQS는 메시지 큐잉 서비스로 컴퓨팅 제공 아님. (C) Elastic Beanstalk은 EC2를 프로비저닝하는 배포 서비스로 서버리스가 아님. (D) SageMaker는 ML 모델 구축/학습/배포용. 【시험 포인트】 "컨테이너 + 서버리스" → AWS Fargate.

해설

【핵심 용어】 ▸ AWS Organizations — 다중 계정 통합 관리 + 통합 결제(consolidated billing)로 여러 계정을 하나의 청구서로 ▸ AWS Trusted Advisor — 모범 사례 점검 도구 ▸ Cost Explorer — 비용 시각화/분석 도구 ▸ AWS Budgets — 예산 설정/초과 알림 【정답 포인트】 ▸ "여러 계정을 하나의 청구서로 받기" → Organizations의 통합 결제 기능이 정답 【오답 체크】 (B) Trusted Advisor는 비용/보안 등 권장사항 점검용이지 결제 통합 기능이 아님. (C) Cost Explorer는 비용 분석/시각화 도구이지 청구서 통합 자체가 아님. (D) Budgets는 예산 초과 알림용. 【시험 포인트】 "다중 계정 + 하나의 청구서(통합 결제)" → AWS Organizations.

해설

【핵심 용어】 ▸ Security group — 인스턴스(ENI) 단위의 상태 저장(stateful) 가상 방화벽, 개별 EC2 단위 트래픽 제어 ▸ Network ACL — 서브넷 단위 상태 비저장(stateless) 방화벽 (서브넷 내 모든 인스턴스에 적용) ▸ AWS WAF — 웹 애플리케이션 계층(L7) 공격 방어 ▸ Route table — 트래픽 라우팅 경로 지정, 방화벽 아님 【정답 포인트】 ▸ "단일 EC2 인스턴스만 제어, 같은 서브넷의 다른 인스턴스는 제어 안 함" → 인스턴스 단위인 Security group이 정답 ▸ 서브넷 전체가 아닌 개별 인스턴스 방화벽 = Security group 【오답 체크】 (A) Network ACL은 서브넷 단위라 같은 서브넷 내 모든 인스턴스에 영향. (B) WAF는 웹 트래픽(HTTP/HTTPS) 보호용이지 인스턴스 네트워크 방화벽이 아님. (C) Route table은 라우팅 제어이지 방화벽이 아님. 【시험 포인트】 "인스턴스 단위 방화벽" → Security group / "서브넷 단위 방화벽" → Network ACL.

해설

【핵심 용어】 ▸ Auto Scaling group — 수요에 따라 EC2 인스턴스 수를 자동 증감 → 사용 시간대만 확장, 유휴 시 축소해 비용 최소화 ▸ Multiple Availability Zones — 가용성 향상용 배치 ▸ Placement group — 인스턴스 배치 전략(성능/네트워크) ▸ Private subnet — 인터넷 미노출 서브넷 【정답 포인트】 ▸ "대부분 특정 시간대만 사용" + "최저 운영 비용" → 수요에 맞춰 인스턴스를 자동 확장/축소하는 Auto Scaling group이 정답 【오답 체크】 (A) 다중 AZ 배치는 가용성 목적이며 그 자체로 비용을 낮추지 않음. (C) Placement group은 성능/배치 최적화용으로 비용 절감 목적이 아님. (D) Private subnet은 보안/네트워크 격리용이지 비용 절감 수단이 아님. 【시험 포인트】 "수요 변동 + 최저 비용" → Auto Scaling으로 필요할 때만 인스턴스 확장.

해설

【핵심 용어】 ▸ AWS re:Post / AWS Developer Forums — Support 플랜과 무관하게 항상 무료로 제공되는 커뮤니티 포럼 ▸ AWS Developer Support — 유료 지원 플랜 ▸ Programmatic case management(AWS Support API) — Business 이상 유료 플랜에서만 제공 ▸ Technical Account Manager(TAM) — Enterprise 지원 플랜 전용 【정답 포인트】 ▸ "지원 플랜과 무관하게 항상 무료" → 커뮤니티 기반 AWS Developer Forums가 정답 【오답 체크】 (A) Developer Support는 유료 지원 플랜. (C) Programmatic case management(Support API)는 Business 이상 유료 플랜에서만 가능. (D) TAM은 Enterprise 플랜 전용 유료 혜택. 【시험 포인트】 "모든 사용자에게 항상 무료" → 커뮤니티 포럼/기본 리소스. 유료 플랜 전용(API 케이스, TAM)과 구분.

해설

【핵심 용어】 ▸ Reserved Instances — 1년/3년 약정으로 대폭 할인, 상시 실행 예측 가능 워크로드에 최적 ▸ Spot Instances — 여유 용량 저가 이용, 중단 가능성 있음(상시성 요구엔 부적합) ▸ On-Demand Instances — 약정 없이 정가, 할인 없음 ▸ EC2 Fleet — 여러 구매 옵션/인스턴스 유형 묶음 프로비저닝 【정답 포인트】 ▸ "3년 이상 상시 연속 실행" + "요금 할인" → 장기 약정 할인인 Reserved Instances가 정답 【오답 체크】 (B) Spot은 언제든 회수될 수 있어 연속 상시 실행 요구에 부적합. (C) On-Demand는 할인이 없음. (D) EC2 Fleet은 구매 옵션 관리 방식이지 그 자체가 장기 할인 요금제는 아님. 【시험 포인트】 "장기(1/3년) 상시 실행 + 할인" → Reserved Instances (또는 Savings Plans).

해설

【핵심 용어】 ▸ AWS CloudTrail — 계정 내 API 호출/활동 기록, "누가·언제·무엇을" 했는지 감사(audit) 로그 제공 ▸ AWS Config — 리소스 구성 상태/변경 이력 추적(규정 준수) ▸ Amazon Rekognition — 이미지/영상 분석 ML ▸ Amazon SNS — 알림 발행/구독 【정답 포인트】 ▸ "누가 이벤트를 시작하고 어떤 작업을 했는지 감사" → API 활동을 기록하는 AWS CloudTrail이 정답 【오답 체크】 (A) Config는 리소스 구성/컴플라이언스 추적용으로 사용자 행위 감사가 주목적은 아님. (B) Rekognition은 이미지/영상 인식 ML 서비스. (D) SNS는 메시지 알림 서비스로 감사 로그와 무관. 【시험 포인트】 "누가/언제/무슨 API 호출(활동 감사)" → CloudTrail. "리소스 구성 변경 추적" → Config.

해설

【핵심 용어】 ▸ Well-Architected Framework 신뢰성(Reliability) 기둥 — 장애 자동 복구, 복구 절차 테스트, 수평 확장, 용량 추측 배제, 자동화된 변경 관리 원칙 ▸ "Automatically recover from failure" — 장애 자동 복구 (신뢰성 원칙) ▸ "Stop guessing capacity" — 용량 추측 배제(자동 확장) (신뢰성 원칙) 【정답 포인트】 ▸ 신뢰성 기둥의 대표 설계 원칙 → (A) 장애 자동 복구, (C) 용량 추측 중단 두 가지가 정답 ▸ 둘 다 가용성/자동 확장을 통한 신뢰성 확보 원칙 【오답 체크】 (B) 모두에게 서비스 할당량 증가 권한 부여는 최소 권한 원칙 위배, 설계 원칙 아님. (D) 단일 AZ 실행은 오히려 신뢰성을 낮추므로 반대 원칙. (E) 보조 리전에 먼저 할당량 증설한다는 것은 실제 신뢰성 설계 원칙이 아님. 【시험 포인트】 신뢰성 기둥 키워드: 자동 복구 / 복구 테스트 / 수평 확장 / 용량 추측 배제 / 자동화.

해설

【핵심 용어】 ▸ Amazon S3 정적 웹사이트 호스팅 — 서버 관리 없이 정적 콘텐츠 호스팅, 운영 오버헤드 최소 ▸ Amazon EC2 — 서버 직접 운영/패치 필요(오버헤드 큼) ▸ AWS Elastic Beanstalk — 내부에 EC2 등 인프라 프로비저닝(관리 부담 존재) ▸ Amazon Lightsail — 간편 VPS이나 여전히 서버 인스턴스 관리 필요 【정답 포인트】 ▸ "정적 웹사이트" + "최소 운영 오버헤드" → 서버리스로 정적 호스팅하는 Amazon S3가 정답 【오답 체크】 (A) EC2는 인스턴스/OS 패치 등 운영 부담이 가장 큼. (B) Elastic Beanstalk은 기반 인프라를 프로비저닝해 관리 요소가 존재. (C) Lightsail도 서버 인스턴스를 관리해야 하므로 S3보다 오버헤드가 큼. 【시험 포인트】 "정적 웹사이트 + 최소 운영 오버헤드" → S3 호스팅 (필요 시 CloudFront).

해설

【핵심 용어】 ▸ AWS Cost Explorer — 비용/사용량 분석 및 유휴·저활용 리소스에 대한 비용 절감 권장(예: 유휴 인스턴스 종료, RI 추천) ▸ 나머지 보기(DB 엔진/프로그래밍 언어/OS 선택) — 비용 도구가 제시하는 권장이 아님 【정답 포인트】 ▸ "Cost Explorer가 제공하는 비용 절감 권장" → 유휴 인스턴스 종료(Terminate an idle instance)가 정답 【오답 체크】 (A) 특정 DB 엔진 사용은 Cost Explorer의 권장 유형이 아님. (B) 애플리케이션 프로그래밍 언어 변경은 비용 도구가 권고하는 대상이 아님. (C) 특정 OS 배포 권장도 Cost Explorer 기능이 아님. 【시험 포인트】 "Cost Explorer 비용 절감 권장" → 유휴/저활용 리소스 정리(종료·라이트사이징).

해설

【핵심 용어】 ▸ Multiple AZ(단일 리전 내 다중 가용영역) — 물리적으로 분리된 AZ에 분산 배포 → 내결함성·고가용성 확보 ▸ 글로벌 지연 개선 — CloudFront/Global Accelerator/다중 리전 영역 ▸ AZ는 필요 시 종료해 두는 대상이 아님 【정답 포인트】 ▸ "단일 리전 내 여러 AZ 배포" → 한 AZ 장애 시에도 지속되는 복원력 있는 고가용성 아키텍처(B)가 정답 【오답 체크】 (A) 글로벌 사용자 연결 성능 개선은 다중 리전/CDN 영역이지 단일 리전 다중 AZ의 주 이점이 아님. (C) 다중 AZ 배포는 스토리지 비용 절감과 무관. (D) 저수요 시 AZ를 꺼두는 개념은 없음. 【시험 포인트】 "단일 리전 + 다중 AZ" → 고가용성/내결함성. "글로벌 저지연" → 다중 리전/CloudFront.

해설

【핵심 용어】 ▸ AWS Health Dashboard — AWS 서비스 상태/이벤트를 게시하며 RSS 피드 구독으로 서비스 이슈 업데이트 수신 가능 ▸ Amazon SNS — 알림 발행/구독(직접적 AWS 상태 RSS 제공 서비스 아님) ▸ AWS Config — 리소스 구성 추적 ▸ AWS CodeCommit — Git 소스 리포지토리 【정답 포인트】 ▸ "AWS 서비스 이슈 업데이트를 RSS로 구독" → 서비스 상태를 게시하는 AWS Health Dashboard가 정답 【오답 체크】 (A) SNS는 범용 알림 서비스로 AWS 서비스 상태 RSS 자체를 제공하지 않음. (C) Config는 리소스 구성/컴플라이언스 추적용. (D) CodeCommit은 소스 코드 리포지토리. 【시험 포인트】 "AWS 서비스 상태/이슈 알림, RSS" → AWS Health Dashboard(구 Service Health Dashboard).

해설

【핵심 용어】 ▸ Reserved Instances 약정 기간 — 1년 또는 3년만 존재하며, 3년 약정이 최대 할인 ▸ 5년 약정은 존재하지 않음 【정답 포인트】 ▸ "가장 큰 비용 절감의 RI 약정 기간" → 3년(3 year)이 정답 (약정이 길수록 할인 큼) 【오답 체크】 (A) 1년은 할인폭이 3년보다 작음. (B) 2년 약정은 표준 RI 옵션이 아님. (D) 5년 약정은 존재하지 않음. 【시험 포인트】 "RI 최대 할인" → 3년 약정 + 전액 선결제(All Upfront).

해설

【핵심 용어】 ▸ Spot Instances — AWS 여유 용량을 최대 90% 저가로 사용, 언제든 중단될 수 있어 중단 허용 워크로드(빅데이터/병렬 연산/개발·테스트)에 최적 ▸ On-Demand — 정가, 할인 없음 ▸ Reserved Instances / Savings Plans — 장기 약정 상시 워크로드용 【정답 포인트】 ▸ "빅데이터/대규모 병렬 연산 + 가끔 중단 허용" + "가장 비용 효율적" → 저가·중단 허용형 Spot Instances가 정답 【오답 체크】 (A) On-Demand는 할인이 없어 가장 비싼 축. (C) Reserved는 상시 실행 예측형 워크로드 약정용으로 이 상황에 최적 아님. (D) Savings Plans도 상시 사용량 약정 기반으로 중단 허용 배치 작업엔 Spot이 더 저렴. 【시험 포인트】 "중단 허용(fault-tolerant) + 최저 비용" → Spot Instances.

해설

【핵심 용어】 ▸ On-Demand Instances — 약정 없이 사용한 만큼만 과금, 간헐적·단시간 실행(주 3시간)에 최적 ▸ Spot Instances — 저가지만 중단 가능(중단 불가 요구엔 부적합) ▸ Savings Plans / Convertible RI — 상시 사용량 장기 약정용(주 3시간 저사용엔 비효율) 【정답 포인트】 ▸ "주당 3시간만 실행 + 중단 불가" → 약정 없이 실행분만 과금하는 On-Demand가 정답 ▸ 사용량이 극히 적어 장기 약정 할인의 이점이 없고, 중단 불가라 Spot도 배제 【오답 체크】 (A) Compute Savings Plan은 상시 사용량 약정이라 주 3시간엔 낭비. (C) Convertible RI도 지속 사용 약정 기반으로 저사용에 비효율. (D) Spot은 중단될 수 있어 "중단 불가" 요구에 부적합. 【시험 포인트】 "저사용/간헐 실행 + 중단 불가" → On-Demand. "중단 허용 + 저가" → Spot.

해설

【핵심 용어】 ▸ AWS Support API(프로그래매틱 케이스 관리) — Business 지원 플랜부터 제공 ▸ AWS Business Support — API 접근 지원되는 가장 저렴한 플랜 ▸ Basic/Developer — Support API 미제공 ▸ Enterprise — API 제공하나 더 고가 【정답 포인트】 ▸ "API 호출로 AWS Support와 상호작용" + "가장 비용 효율적" → Support API를 제공하는 최저가 플랜인 AWS Business Support가 정답 【오답 체크】 (A) Basic은 기술 지원/Support API 미제공. (B) Developer는 Support API(케이스 관리 API)를 제공하지 않음. (D) Enterprise도 API를 제공하나 Business보다 훨씬 비쌈(가장 비용 효율적 아님). 【시험 포인트】 "AWS Support API 접근"의 최저 플랜 → Business Support.

해설

【핵심 용어】 ▸ Trade fixed expense for variable expense — 선투자(고정비) 대신 사용한 만큼만 지불(변동비)하는 클라우드 이점 ▸ 나머지 보기는 각기 다른 클라우드 이점(데이터센터 유지 중단, 민첩성, 글로벌 확장) 【정답 포인트】 ▸ "필요할 때(as-needed) 사용분만큼 지불" → 고정비를 변동비로 전환(Trade fixed expense for variable expense)이 정답 【오답 체크】 (A) 데이터센터 운영 비용 중단은 별개 이점(직접 청구 방식과 다른 관점). (B) 속도/민첩성 향상은 결제 방식 이점이 아님. (C) 몇 분 내 글로벌 확장은 지리적 확장 이점. 【시험 포인트】 "사용한 만큼 지불(pay-as-you-go)" → 고정비 → 변동비 전환.