실전 문제

문제 1

미디어 스트리밍 스타트업은 단일 모니터링 마이크로서비스에서 생성되는 재생 오류 알림을 토픽 기반 publish/subscribe 패턴을 사용해 메시지를 팬아웃(fan out)하여, 최소한의 코드 변경으로 두 개의 AWS Regions 전반에 걸쳐 10,000개 이상의 엔드포인트(모바일 푸시, 이메일, SMS, HTTPS 웹훅)로 브로드캐스트해야 합니다. 이 publisher-and-subscriber 모델을 구현하기 위해 팀이 사용해야 하는 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 토픽 기반 publish/subscribe (pub/sub) 팬아웃 패턴을 위한 AWS 관리형 메시징을 테스트합니다. AWS에서 여러 subscriber 프로토콜을 지원하는 pub/sub의 대표 서비스는 Amazon Simple Notification Service (Amazon SNS)입니다. 정답이 맞는 이유: Amazon SNS를 사용하면 단일 publisher(모니터링 마이크로서비스)가 SNS topic에 알림 메시지를 publish할 수 있고, SNS는 해당 메시지의 사본을 잠재적으로 수천(또는 그 이상)의 subscribers에게 전달합니다. SNS는 문제 요구사항과 일치하는 여러 엔드포인트 유형을 기본적으로 지원합니다: 모바일 푸시 알림, 이메일, SMS, HTTPS 웹훅(HTTP/HTTPS subscriptions를 통해). 이를 통해 최소한의 코드 변경으로 10,000개 이상의 엔드포인트로 팬아웃을 달성할 수 있습니다. 마이크로서비스는 topic에 publish만 하면 되고, subscriber 관리와 전달은 SNS가 처리합니다. 주요 AWS 기능: SNS topics는 내구성이 있고 고가용성인 메시지 수집 및 전달을 제공하며 자동 확장을 지원합니다. subscription filter policies(메시지 attributes)를 사용해 관련 알림만 특정 subscriber 그룹으로 라우팅하여 다운스트림 노이즈를 줄일 수 있습니다. cross-Region 요구사항의 경우 SNS는 Regional 서비스이지만, 각 Region에 topic을 생성하고 cross-Region forwarding 패턴(예: 두 topic 모두에 publish하거나, 다른 Region의 HTTPS endpoint/Lambda를 subscribe하여 재게시하도록 구성)을 사용해 multi-Region 전달을 구현할 수 있습니다. 또한 SNS는 다른 AWS 서비스(Lambda, SQS, EventBridge)와 통합되므로, 이후 버퍼링, 재시도, 추가 처리가 필요해질 때 확장할 수 있습니다. 흔한 오해: Lambda는 compute 서비스이지 pub/sub broker가 아닙니다. Lambda만으로 구현하면 커스텀 팬아웃 로직과 엔드포인트 관리가 필요합니다. CloudWatch는 metrics, logs, alarms를 위한 서비스로, 알림을 트리거할 수는 있지만 다중 프로토콜 엔드포인트 팬아웃을 위한 범용 pub/sub 서비스는 아닙니다. CloudFormation은 infrastructure-as-code이며 메시지를 전달하지 않습니다. 시험 팁: “topic-based publish/subscribe”, “fan out”, “multiple protocols (SMS, email, mobile push, HTTP/S)”가 보이면 먼저 SNS를 떠올리세요. 문제가 버퍼링/consumer pull 또는 순서 보장 처리를 강조한다면 SQS/Kinesis를 고려하세요. SNS는 Regional이라는 점을 기억하세요. multi-Region 설계는 일반적으로 topic을 복제하고, 복원력과 로컬리티를 위해 forwarding 또는 dual-publish를 사용합니다.

문제 2

직원 220명의 중견 물류 회사가 6개 제품 팀에 걸쳐 15개월간의 cloud transformation을 시작하며, IT delivery metrics(배포 빈도 주 10회 초과)를 business KPIs(고객 onboarding 48시간 미만)와 정렬하고, 역량 강화(upskilling)와 지속적 학습(continuous learning)을 위한 cross-functional guilds를 구축하려고 합니다. AWS Cloud Adoption Framework (AWS CAF)에서 기술과 비즈니스 사이의 가교 역할을 하여 이러한 지속적 성장과 학습의 문화를 조성하는 관점은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS Cloud Adoption Framework (AWS CAF)의 관점(perspectives) 중 어떤 것이 비즈니스 성과(KPIs)와 기술 delivery를 연결하면서 학습 문화를 구축하는지에 대한 지식을 평가합니다. AWS CAF는 cloud adoption 가이드를 여러 관점으로 구성하며, 여기서 관련된 핵심은 organizational change management, skills, roles, 그리고 협업 모델입니다. 정답이 맞는 이유: People 관점은 조직 구조, 역할과 책임, 인력 구성(staffing), 역량(skills), 인센티브, 문화에 초점을 두기 때문에 기술과 비즈니스 사이의 “가교”입니다. 시나리오에는 IT delivery metrics(배포 빈도)를 business KPIs(고객 onboarding 시간)와 정렬하고, 역량 강화와 지속적 학습을 위한 cross-functional guilds를 구축한다는 내용이 명시되어 있습니다. 이는 전형적인 People 관점의 관심사입니다: 제품 팀을 enable하고, communities of practice(guilds)를 만들며, 새로운 업무 방식(DevOps/product operating model)을 정의하고, 교육과 커리어 개발을 통해 지속적 개선을 추진하는 것입니다. 주요 AWS 기능 / Best Practices: 단일 AWS 서비스라기보다는, People 관점은 일반적으로 다음과 같은 실천과 매핑됩니다: - AWS Training and Certification, AWS Skill Builder, 그리고 구조화된 enablement 계획을 통해 cloud skills를 구축. - cross-functional teams(product + platform + security) 및 communities of practice를 수립하여 패턴을 표준화. - 역할(cloud center of excellence, platform team, SRE/DevOps)을 정의하고 인센티브를 비즈니스 성과에 정렬. - metrics(DORA metrics의 deployment frequency 등)를 학습과 개선을 위한 feedback loop로 활용. 이는 AWS Well-Architected Framework의 Operational Excellence pillar가 강조하는 학습, 실험, 지속적 개선과도 정렬되지만, 문화와 역량에 대한 CAF 관점은 특히 People입니다. 흔한 오해: Governance는 “비즈니스 정렬”처럼 들릴 수 있지만, 더 핵심은 decision rights, portfolio management, risk management, 그리고 policies입니다. Operations는 워크로드 운영 및 지원, incident/problem management, 운영 프로세스에 관한 것입니다. Security는 risk, controls, compliance에 초점을 둡니다. 이들 중 어느 것도 upskilling, guilds, 문화 변화에 1차적으로 초점을 두지는 않습니다. 시험 팁: “skills”, “training”, “organizational change”, “roles”, “culture”, “cross-functional teams”, “communities of practice/guilds” 같은 키워드가 보이면 People 관점을 떠올리세요. “policies, guardrails, compliance reporting, portfolio prioritization”은 Governance입니다. “runbooks, monitoring, incident response”는 Operations에 해당하고, “IAM, encryption, threat detection”은 Security에 해당합니다.

문제 3

(2개 선택)

한 스타트업이 1.5 TB 온프레미스 PostgreSQL 12 데이터베이스를 AWS로 이전할 계획이며, 서버 유지 관리 없이 완전 관리형 서비스를 요구하면서 표준 PostgreSQL 드라이버 및 확장과의 호환성을 유지하려고 합니다. 어떤 AWS 서비스가 이러한 요구 사항을 충족할 수 있습니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 서버/OS 유지 관리를 제거하면서 PostgreSQL 호환성(표준 드라이버, SQL 동작, 확장 지원)을 제공하는 AWS 완전 관리형 관계형 데이터베이스 서비스를 식별하는지를 평가합니다. 정답이 맞는 이유: PostgreSQL용 Amazon RDS는 PostgreSQL 엔진( PostgresSQL 12 포함)을 지원하는 관리형 데이터베이스 서비스이며, 표준 PostgreSQL 클라이언트, 드라이버(JDBC/ODBC/psql) 및 많은 확장과의 호환성을 목표로 설계되었습니다. 프로비저닝, 패치 적용(엔진 및 OS), 백업, 자동 복구와 같은 차별화되지 않은 운영 작업을 제거해 줍니다. Amazon Aurora PostgreSQL-Compatible Edition 또한 완전 관리형이며 PostgreSQL wire-protocol 및 드라이버 호환성을 제공합니다. 더 높은 성능과 가용성이 필요할 때 흔히 선택되며, 애플리케이션이 표준 PostgreSQL 드라이버를 사용해 연결할 수 있습니다. Aurora는 PostgreSQL 확장의 일부만 지원(버전에 따라 다름)하지만, PostgreSQL 호환성을 위해 명시적으로 구축되었고 “서버 유지 관리 없음” 요구 사항을 충족합니다. 주요 AWS 기능: RDS와 Aurora는 모두 자동 백업, point-in-time recovery, Multi-AZ 고가용성, 저장 시 암호화(KMS) 및 전송 중 암호화(TLS), 모니터링(CloudWatch), 관리형 유지 관리 윈도우를 제공합니다. 1.5 TB 온프레미스 PostgreSQL 데이터베이스 마이그레이션에는 AWS Database Migration Service (DMS) 및/또는 네이티브 pg_dump/pg_restore를 사용할 수 있으며, 최소 다운타임 마이그레이션에는 DMS가 자주 선호됩니다. 스토리지 크기는 일반적인 RDS/Aurora 용량 범위 내에 있으며, 두 서비스 모두 스케일링을 지원합니다(인스턴스 클래스 변경; Aurora는 컴퓨트와 스토리지를 분리). 흔한 오해: 일부는 PostgreSQL을 실행할 수 있고 모든 확장을 지원할 수 있다는 이유로 Amazon EC2를 선택할 수 있지만, EC2는 데이터베이스에 대해 “완전 관리형”이 아닙니다. OS, 패치, 백업, HA를 직접 관리해야 합니다. 또 다른 선택지로 Athena 또는 DynamoDB를 고를 수 있지만, 이들은 PostgreSQL 호환 관계형 엔진이 아닙니다. 시험 팁: “완전 관리형 데이터베이스” + “PostgreSQL 호환성” + “표준 드라이버”를 보면 “RDS for PostgreSQL”과 “Aurora PostgreSQL-Compatible”을 떠올리세요. “서버 유지 관리 없음”이 강조되면 EC2를 제외하세요. S3의 파일에 대해 SQL을 실행해야 한다면 트랜잭션 PostgreSQL 마이그레이션이 아니라 Athena를 가리킵니다.

문제 4

12개의 AWS 계정을 보유한 의료 분석 기업이 향후 90일 동안 20개의 프로덕션 워크로드를 온보딩할 계획이며, AWS Managed Services (AMS)가 환경 전반에서 day-2 운영 지원을 제공하기를 원한다. 멀티 계정 landing zone과 중앙집중식 네트워크 연결을 구축하여 이 범위를 충족하는 AMS 기능은 무엇인가?

문제 분석

핵심 개념: 이 문제는 AWS Managed Services (AMS)의 기본 온보딩 기능—특히 엔터프라이즈 멀티 계정 운영 모델(landing zone)과 중앙집중식 네트워크 연결을 구축하는 것—에 대한 지식을 평가합니다. AWS 관점에서 이는 AWS Organizations 기반의 멀티 계정 거버넌스, 표준화된 계정 베이스라인, 그리고 hub-and-spoke/shared services 네트워킹에 해당합니다. 정답이 맞는 이유: 해당 기업은 12개의 AWS 계정을 보유하고 있으며 단기간에 20개의 프로덕션 워크로드를 온보딩할 계획이고, AMS가 “환경 전반”에서 day-2 운영을 제공하기를 원합니다. AMS는 일반적으로 멀티 계정 landing zone을 생성하거나 통합하고, 워크로드를 가드레일, shared services, 통제된 연결성 하에서 일관되게 운영할 수 있도록 중앙집중식 네트워킹을 구현하는 것으로 시작합니다. “Landing zone 구축 및 네트워크 관리”는 이 범위를 직접적으로 충족합니다. 즉, 멀티 계정의 기반 구조와 AMS가 대규모로 워크로드를 운영 및 거버넌스하기 위해 필요한 중앙집중식 네트워크 패턴을 설정합니다. 주요 AWS 기능: Landing zone에는 일반적으로 AWS Organizations, 계정 발급/프로비저닝, 표준화된 IAM 및 보안 베이스라인, 중앙집중식 로깅 및 모니터링, 그리고 가드레일(종종 AWS Control Tower 개념, SCP, 베이스라인 구성으로 구현)이 포함됩니다. 중앙집중식 네트워크 연결은 보통 shared services VPC, AWS Transit Gateway, 중앙집중식 egress/ingress 제어, 그리고 AWS Direct Connect 또는 VPN을 통한 온프레미스 통합을 갖춘 hub-and-spoke 모델을 사용합니다. 이는 의료와 같은 규제 산업에서 일관된 day-2 운영, 변경 관리, 인시던트 대응, 컴플라이언스를 위해 필수적인 기반입니다. 흔한 오해: 애플리케이션 개발, CI/CD, 또는 심층 로그 문제 해결과 관련된 선택지는 “운영”처럼 들릴 수 있지만, 필요한 멀티 계정 거버넌스 및 네트워크 기반을 구축하지는 않습니다. Landing zone과 중앙집중식 네트워킹이 없으면 AMS는 여러 계정과 워크로드 전반에서 제어, 연결성, 운영 프로세스를 효율적으로 표준화할 수 없습니다. 시험 팁: “멀티 계정”, “다수 워크로드 온보딩”, “중앙집중식 연결성”, “관리형 운영”이 보이면, 선행 조건 기능으로 landing zone + 중앙집중식 네트워킹을 떠올리세요. AMS 문제에서는 기반 플랫폼 설정(계정, 가드레일, 네트워크)과 워크로드 수준 활동(파이프라인, 애플리케이션 변경, 문제 해결)을 구분하세요.

문제 5

한 리테일 분석 팀이 Amazon S3에 저장된 판매 데이터로부터 서버리스의 대화형 대시보드와 차트를 구축하고, 시각화를 60분마다 새로 고침하며, 25명의 비즈니스 사용자와 안전하게 공유해야 합니다— 이러한 인사이트를 제공하기 위해 어떤 AWS 서비스를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon S3의 데이터로부터 직접 대화형 대시보드를 구축하기 위한 AWS의 서버리스 Business Intelligence (BI) 및 데이터 시각화 서비스에 대한 지식을 평가합니다. 정답이 맞는 이유: Amazon QuickSight는 AWS 네이티브 서버리스 BI 서비스로, Amazon S3(종종 AWS Glue Data Catalog/Athena를 통해) 등을 포함한 데이터 소스에서 대화형 대시보드, 차트, 보고서를 생성하도록 설계되었습니다. 예약된 새로 고침(예: 매시간/60분)과 비즈니스 사용자와의 안전한 공유를 지원합니다. “서버리스의 대화형 대시보드와 차트 구축”, “60분마다 시각화 새로 고침”, “25명의 비즈니스 사용자와 안전하게 공유”라는 요구사항은 QuickSight의 대시보딩, SPICE/인메모리 가속, 예약된 ingestion, 사용자/reader 액세스 모델과 정확히 일치합니다. 주요 AWS 기능: QuickSight는 Athena를 사용해 S3 데이터를 쿼리하거나, 빠르고 대화형 성능을 위해 정제된 데이터셋을 SPICE에 로드할 수 있습니다. 데이터셋에 대해 예약된 데이터 새로 고침(매시간)을 구성하여 대시보드가 업데이트된 S3 데이터를 반영하도록 할 수 있습니다. 안전한 공유를 위해 QuickSight는 IAM과 통합되며 사용자 관리(Standard/Enterprise editions), 사용자/그룹별 데이터 제한을 위한 row-level security (RLS), “readers”로 대시보드 공유(비즈니스 소비자에게 적합)를 지원합니다. 또한 embedding과 세분화된 액세스 제어를 지원하여 AWS Well-Architected의 Security 및 Operational Excellence pillar와도 부합합니다. 흔한 오해: 일부는 “analytics”를 데이터베이스(Aurora) 또는 보안 서비스(Macie, CloudTrail)와 혼동할 수 있습니다. 하지만 이 문제는 트랜잭션 데이터 저장, 민감 데이터 탐지, API 호출 감사가 아니라 시각화와 대시보드 제공에 관한 것입니다. Aurora는 데이터를 저장할 수 있고 Macie/CloudTrail은 거버넌스를 지원하지만, 어느 것도 비즈니스 사용자를 위한 BI 대시보드와 예약된 시각화 새로 고침을 제공하지는 않습니다. 시험 팁: “serverless BI”, “interactive dashboards”, “비즈니스 사용자와 공유”, “scheduled refresh”가 보이면 Amazon QuickSight를 떠올리세요. 데이터가 S3에 있다면 Athena/Glue + QuickSight 패턴을 예상하면 됩니다. 또한 라이선싱 단서도 확인하세요: “25명의 비즈니스 사용자”는 비용 효율적인 공유를 위한 QuickSight readers를 의미하는 경우가 많고, 안전한 다중 사용자 액세스를 위해 RLS를 함께 사용하는 경우가 많습니다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

(2개 선택)

직원 240명의 리테일 분석 회사가 6개월 내에 120개의 온프레미스 워크로드를 AWS로 마이그레이션할 계획이며, CIO는 거버넌스 또는 보안 프로세스를 변경하지 않으면서 3개의 제품 라인 전반에서 리더십 목표를 재정렬하고 15%의 클라우드 역량 격차를 해결하기 위해 팀 구조를 재설계하려면 어떤 AWS Cloud Adoption Framework (AWS CAF) People 관점 역량을 우선순위로 두어야 하는지 질문합니다(두 개 선택).

문제 분석

핵심 개념 - 이 문제는 AWS Cloud Adoption Framework (AWS CAF), 특히 People 관점 역량에 대한 지식을 평가합니다. People 관점은 조직 변화 관리에 초점을 둡니다. 즉, 이해관계자 정렬, 운영 모델의 진화, 그리고 클라우드 마이그레이션을 실행할 수 있도록 팀이 적절한 역량을 갖추도록 하는 것입니다. 정답이 맞는 이유 - 이 시나리오에는 두 가지 명시적 요구가 있습니다: (1) “3개의 제품 라인 전반에서 리더십 목표를 재정렬”하고 (2) “15%의 클라우드 역량 격차를 해결하기 위해 팀 구조를 재설계”하는 것인데, 동시에 거버넌스 또는 보안 프로세스는 변경하지 않는다고 명시되어 있습니다. AWS CAF People 관점에서 Organizational alignment는 비즈니스 유닛/제품 라인 전반에서 리더십 목표, 인센티브, 우선순위를 정렬하여 마이그레이션이 공통된 방향과 일관된 의사결정을 갖도록 하는 것을 다룹니다. Organization design는 팀을 어떻게 구성할지(예: 플랫폼 팀, 제품 팀, 클라우드 지원 팀/CCoE 패턴), 역할/책임을 정의하고, 역량 격차를 해소하기 위한 인력 변화를 계획하는 것을 다룹니다. 주요 AWS 기능 / 모범 사례 - 서비스 자체를 묻는 문제는 아니지만, AWS CAF는 실제 마이그레이션에서 사용되는 모범 사례와 연결됩니다: 표준과 코칭을 주도하기 위해 Cloud Center of Excellence(또는 클라우드 지원 기능)를 수립하고, 목표 운영 모델(제품 정렬 팀, 플랫폼 엔지니어링, SRE/DevOps 책임)을 정의하며, 15% 격차를 해소하기 위해 역할 기반 교육 계획(AWS Skill Builder, AWS Training and Certification)과 실습 기반 지원을 마련합니다. 중요한 점은 거버넌스와 보안 프로세스를 변경하지 않는다고 했으므로, 정책 재설계가 아니라 사람/조직 구조와 리더십 정렬에 초점을 유지해야 한다는 것입니다. 흔한 오해 - Portfolio management는 120개 워크로드와 6개월 일정 때문에 관련 있어 보일 수 있지만, 이는 주로 Business 관점 역량(우선순위, 자금, 가치 추적)이며, 요청된 People 관점의 초점이 아닙니다. Risk management는 Governance 및 Security 관점과 더 맞닿아 있으며 리스크 통제/프로세스 변경을 시사하는데, 문제에서 이를 명시적으로 피하고 있습니다. Modern application development는 Platform 관점 역량으로 엔지니어링 관행과 도구에 관한 것이지, 리더십 정렬이나 조직 재설계가 아닙니다. 시험 팁 - AWS CAF가 언급되면 먼저 어떤 관점을 묻는지(People)를 식별하세요. 그다음 키워드를 매핑합니다: “리더십/목표 정렬” -> Organizational alignment; “팀 구조/역할/역량 격차” -> Organization design. “거버넌스 또는 보안을 변경하지 않음”이라고 하면, 광범위하게 관련 있어 보이더라도 Governance/Security 역량은 피하세요.

문제 7

한 개발 팀이 Python 기반 CI/CD 파이프라인에서 코드로 API를 직접 호출하여 AWS 리소스를 생성하고 업데이트하려고 합니다(예: 2개 Region에 걸쳐 Amazon EC2 인스턴스 15개를 시작하고 Amazon RDS 데이터베이스 3개를 프로비저닝). 물리적 네트워크 링크나 시각적 콘솔을 사용하지 않고 AWS에 연결하여 프로그래밍 방식으로 리소스를 배포하려면 어떤 AWS 서비스 또는 도구를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 CI/CD 파이프라인에서 코드로 AWS 리소스를 프로그래밍 방식으로 프로비저닝하고 관리하는 방법을 평가합니다. 핵심 개념은 AWS Management Console을 사용하거나 전용 네트워크 연결이 필요한 방식이 아니라, 언어별 라이브러리(SDK)를 통해 AWS APIs를 사용하는 것입니다. 정답이 맞는 이유: AWS SDKs(예: Python용 Boto3)는 AWS 서비스 API에 대한 프로그래밍 방식 접근을 제공합니다. Python 기반 파이프라인은 인증(일반적으로 IAM roles, access keys 또는 OIDC federation을 통해)을 수행한 다음 Amazon EC2의 RunInstances 또는 Amazon RDS의 CreateDBInstance 같은 API 작업을 호출할 수 있습니다. SDKs는 Region별로 클라이언트를 구성하여(예: us-east-1 및 eu-west-1에 대해 별도의 EC2/RDS 클라이언트 생성) 여러 Region 배포를 지원하고, 코드로 리소스 생성/업데이트를 오케스트레이션할 수 있습니다. 이는 “코드에서 API를 직접 호출”하고 물리적 네트워크 링크나 시각적 콘솔 없이 리소스를 배포해야 한다는 요구사항과 일치합니다. 주요 AWS 기능: AWS SDKs는 요청 서명(SigV4), 재시도, pagination, 서비스 엔드포인트 처리를 담당합니다. CI/CD에서는 IAM roles를 통한 임시 자격 증명 사용(예: STS로 role을 assume하거나 GitHub Actions OIDC로 role을 assume)과 필요한 작업만 허용하는 최소 권한 IAM policies(ec2:RunInstances, rds:CreateDBInstance 등)를 사용하는 것이 모범 사례입니다. SDKs는 표준 자격 증명 제공자(environment variables, shared config, instance profiles, container task roles)와 통합되며, 견고한 오류 처리 및 idempotency 패턴을 지원합니다. 흔한 오해: 일부는 “AWS에 연결”을 AWS Direct Connect 또는 AWS PrivateLink 같은 네트워크 연결 서비스로 혼동할 수 있습니다. 하지만 이러한 서비스는 프라이빗 네트워킹과 연결성을 다루며, 프로그래밍 방식 프로비저닝을 제공하지 않습니다. 또 다른 오해는 QuickSight 같은 분석/시각화 도구를 떠올리는 것인데, 이는 인프라 배포와 무관합니다. 시험 팁: 문제에서 “from code”, “call APIs”, “programmatically”, “language-based pipeline”을 강조하면 AWS SDKs 또는 AWS CLI를 떠올리십시오. “infrastructure as code templates”를 강조하면 AWS CloudFormation/CDK/Terraform(여기에는 제시되지 않음)을 떠올리십시오. “private connectivity”를 강조하면 Direct Connect/VPN/PrivateLink를 떠올리십시오. 주요 요구사항에 맞는 도구를 선택해야 하며, Python에서의 API 기반 자동화는 AWS SDKs(Boto3)를 의미합니다.

문제 8

실시간 스포츠 하이라이트 플랫폼은 120 MB 이미지와 8분짜리 비디오 클립을 50개국 이상의 시청자에게 시작 지연 시간을 100 ms 미만으로 제공해야 합니다. 사용자와 가까운 위치에 이 콘텐츠를 캐시하기 위해 전 세계 엣지 로케이션 네트워크를 사용하는 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Content Delivery Network (CDN)를 사용한 콘텐츠 전송과 엣지 캐싱을 평가합니다. 전 세계에 분산된 시청자와 매우 낮은 시작 지연 시간이 요구되는 경우, 전 세계 엣지 로케이션 네트워크를 사용해 최종 사용자와 가까운 곳에서 콘텐츠를 캐시하고 제공하는 AWS의 CDN 서비스인 Amazon CloudFront가 정답입니다. 정답이 맞는 이유: 이 플랫폼은 대용량 정적 객체(120 MB 이미지)와 비디오 클립(8분)을 50개국 이상에 시작 지연 시간 100 ms 미만으로 제공해야 합니다. CloudFront는 엣지 로케이션에서 콘텐츠를 캐시하고 가장 가까운 엣지에서 요청을 처리하여 지연 시간을 줄이도록 설계되었습니다. 비디오의 경우 CloudFront는 HTTP 기반 전송(프로그레시브 다운로드)을 지원하며 스트리밍 워크플로(예: MediaPackage 또는 S3 오리진을 통한 HLS/DASH)와 통합됩니다. 자주 조회되는 하이라이트를 엣지에 유지함으로써 CloudFront는 오리진까지의 왕복 시간을 최소화하고 time-to-first-byte 및 시작 성능을 개선합니다. 주요 AWS 기능: CloudFront는 구성 가능한 TTL, 캐시 정책, 오리진 요청 정책을 통한 엣지 캐싱을 제공합니다. 여러 오리진(Amazon S3, ALB/EC2, MediaPackage)을 지원하고, 접근 제어를 위한 signed URL/cookie, geo-restriction, 보호를 위한 AWS Shield/WAF 통합을 제공합니다. 대용량 객체와 비디오의 경우 Origin Shield(추가 캐싱 계층), regional edge caches, (해당되는 경우) 압축과 같은 기능이 성능을 최적화하고 오리진 부하를 줄이는 데 도움이 됩니다. 또한 CloudFront는 HTTPS, HTTP/2/3, 그리고 성능 튜닝을 위한 상세 메트릭/로깅을 지원합니다. 흔한 오해: Route 53는 전역 서비스로 DNS 해석과 라우팅 결정을 개선하지만, 엣지 로케이션에서 실제 이미지/비디오 바이트를 캐시하거나 전달하지는 않습니다. Kinesis는 실시간 데이터 스트리밍 수집/처리를 위한 서비스이지 콘텐츠 배포용이 아닙니다. SQS는 애플리케이션 디커플링을 위한 메시지 큐로, 최종 사용자에게 미디어를 제공하는 용도가 아닙니다. 시험 팁: “전 세계 엣지 로케이션 네트워크”, “사용자 가까이에 콘텐츠 캐시”, “저지연 콘텐츠 전송”, “전 세계 시청자에게 비디오/이미지 제공”을 보면 CloudFront를 떠올리면 됩니다. Route 53는 “전역”이라는 키워드 때문에 오답 선택지로 자주 등장하지만, 이는 DNS/라우팅 서비스이지 CDN이 아닙니다. 정적 자산은 CloudFront와 S3를 함께 사용하고, 필요 시 스트리밍 아키텍처에서는 CloudFront를 MediaPackage/MediaStore와 조합합니다.

문제 9

한 스타트업이 Auto Scaling group의 Amazon EC2 인스턴스에서 리포팅 API를 실행하고 있으며, 지난 30일 동안 Amazon CloudWatch metrics에서 평균 CPU utilization이 5% 미만이고 network throughput이 0.5 MB/s 미만으로 나타났습니다. 재무팀은 성능에 영향을 주지 않으면서 인스턴스 크기와 비용을 줄이기 위한 자동화된 권장 사항을 원합니다. EC2 인스턴스를 rightsize하기 위해 팀이 사용해야 하는 AWS 서비스 또는 기능은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon EC2에 대해 AWS 네이티브 권장 엔진을 사용한 rightsize 및 성능 기반 최적화를 테스트합니다. 핵심 서비스는 AWS Compute Optimizer로, 과거 utilization metrics와 configuration data를 분석하여 더 적절한 instance type/size를 권장합니다. 정답이 맞는 이유: 워크로드는 Auto Scaling group의 EC2 인스턴스에서 실행되고, CloudWatch에서 30일 동안 지속적으로 낮은 CPU(<5%)와 낮은 network throughput을 보여줍니다. 재무팀은 성능에 영향을 주지 않으면서 인스턴스 크기와 비용을 줄이기 위한 자동화된 권장 사항을 원합니다. AWS Compute Optimizer는 이를 위해 설계되었습니다. CloudWatch metrics(CPU, network, disk, 그리고 CloudWatch Agent를 통해 활성화되는 memory)를 수집하고 현재 instance type을 대안들과 비교 평가하여, 예상 성능 리스크와 절감액을 포함한 rightsize 권장 사항(예: 더 작은 인스턴스 크기 또는 다른 family)을 제공합니다. 주요 AWS 기능: Compute Optimizer는 EC2 인스턴스와 Auto Scaling groups를 지원하며, group 수준과 instance 수준에서 권장 사항을 제공합니다. “지난 30일”이라는 단서와 맞물리는 lookback period(14일 및 32일 포함)를 사용합니다. instance family 변경(예: general purpose에서 burstable 또는 최신 generation으로 이동)을 권장할 수 있으며 “Over-provisioned” 같은 finding을 제공합니다. 권장 사항은 console과 API를 통해 접근할 수 있고, export하여 governance 자동화에 활용할 수 있습니다. 이는 AWS Well-Architected Cost Optimization 원칙(측정, rightsize, 관리형 권장 사항 사용)과도 부합합니다. 흔한 오해: 목표가 비용 절감이기 때문에 학습자들이 Budgets/Anomaly Detection 같은 billing 도구를 고르는 경우가 많지만, 이러한 서비스는 성능 metrics를 분석하여 instance type을 제안하지 않습니다. AWS Config도 “최적화” 도구로 혼동되기 쉽지만, 이는 configuration compliance와 drift detection에 초점이 있으며 rightsize를 위한 기능이 아닙니다. 시험 팁: “rightsize”, “underutilized”, “recommendations”, “CloudWatch metrics 기반”이라는 표현이 보이면 AWS Compute Optimizer를 떠올리십시오. 반대로 “예상치 못한 지출 급증”을 강조하면 Cost Anomaly Detection, “지출이 임계값을 초과할 때 알림”을 강조하면 Budgets, “리소스 compliance rules”를 강조하면 Config를 선택하십시오.

문제 10

한 스타트업이 AWS Cost Explorer를 사용해 지난 30일 동안 서비스별 일일 지출을 그래프로 확인하고, 하루 20시간 동안 평균 CPU 사용률이 10% 미만인 EC2 m5.large 인스턴스 15대로 구성된 플릿을 식별했으며, 비용을 절감하기 위해 더 작은 인스턴스 크기로 옮길 계획이다—어떤 클라우드 개념이 적용되고 있는가?

문제 분석

핵심 개념: 이 문제는 관측된 사용률을 기반으로 컴퓨팅 리소스를 “rightsizing”하는 비용 최적화 실무를 테스트한다. AWS Cost Explorer(그리고 일반적으로 CloudWatch metrics)를 사용해 과다 프로비저닝된 인스턴스를 식별하고 더 적절한 인스턴스 타입을 선택하는 것이다. 정답이 맞는 이유: 스타트업은 하루 대부분(20시간) 동안 평균 CPU 사용률이 10% 미만인 EC2 m5.large 인스턴스 15대를 발견했다. 이는 사용하지 않는 용량에 비용을 지불하고 있는 전형적인 과다 프로비저닝의 신호다. 비용을 줄이기 위해 더 작은 인스턴스 크기로 이동하려는 계획은 성능 요구사항을 유지하면서 실제 워크로드 수요에 맞게 인스턴스 타입/크기(때로는 개수까지)를 맞추는 rightsizing의 정의와 정확히 일치한다. 주요 AWS 기능: Cost Explorer는 서비스 및 기간별 지출 추세를 시각화하고 분석하는 데 도움을 주며, 이는 비용 유발 요인을 식별하는 첫 단계인 경우가 많다. Rightsizing 결정은 일반적으로 Amazon CloudWatch의 사용률 지표(CPU, 가능한 경우 memory, network, disk I/O)를 사용하며, 더 작은 인스턴스 타입이나 다른 패밀리를 제안하는 AWS Cost Optimization 권장사항(예: Compute Optimizer)의 도움을 받을 수 있다. Rightsizing은 AWS Well-Architected Framework Cost Optimization pillar의 핵심 요소로, 낭비를 피하기 위해 리소스를 측정하고 분석한 뒤 조정하는 것이다. 흔한 오해: Reliability와 resilience는 서비스 가용성을 유지하고 장애에서 복구하는 것(예: Multi-AZ, failover, backups)과 관련이 있다. 이는 중복성을 추가하는 경우가 많아 비용을 줄이기보다는 증가시키는 경우가 흔하다. Modernization은 아키텍처나 기술 스택을 개선하는 것(예: containers/serverless로 리팩터링, managed services 채택)을 의미한다. Modernization이 비용을 줄일 수는 있지만, 여기서 설명된 구체적 조치—낮은 사용률 때문에 EC2 인스턴스를 다운사이징하는 것—은 modernization이 아니라 rightsizing이다. 시험 팁: “low utilization”과 “move to smaller instance size” 또는 “reduce instance count”가 함께 나오면 rightsizing을 떠올려라. 질문에 “recommendations for instance types” 또는 “optimize based on metrics”가 언급되면 AWS Compute Optimizer도 함께 고려하라. 초점이 지출 분석 도구(Cost Explorer, Budgets)와 비용 절감 조치에 있다면, 해당 도메인은 일반 기술이나 보안보다는 대개 Billing, Pricing, and Support이다.

문제 11

한 대학교 IT 팀이 4개 부서에 걸쳐 180명의 IAM user가 있는 단일 AWS account를 관리하고 있습니다. 분기별 보안 검토 중, 컴플라이언스 담당자가 모든 IAM user와 root user에 대해 MFA가 활성화되어 있는지(true/false), user 생성 날짜, 마지막 password 변경 날짜, access key가 활성 상태인지 여부를 보여주는 다운로드 가능한 CSV 보고서를 요청합니다. 팀은 스크립트를 작성하지 않고, 추가 서비스를 활성화하지 않으며, 추가 비용을 발생시키지 않고 AWS Management Console에서 직접 이 보고서를 생성해야 합니다. 이 요구 사항을 충족하는 AWS 기능 또는 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 IAM account 수준의 보고 기능, 특히 모든 IAM user와 root user에 대한 credential 관련 보안 상태를 CSV로 다운로드할 수 있는 IAM credential report에 대한 지식을 테스트합니다. 정답인 이유: IAM credential report는 AWS Management Console(IAM console)에서 직접 생성하여 추가 비용 없이 CSV로 다운로드할 수 있습니다. 이 보고서에는 컴플라이언스 담당자가 요청한 필드가 정확히 포함됩니다. 각 user(및 root account 포함)에 대해 MFA 활성화 여부, user 생성 시간, password 마지막 사용/변경 관련 지표( password_last_changed 포함), access key의 상태/마지막 rotation 정보(활성/비활성)가 제공됩니다. 따라서 스크립트 불필요, 추가 서비스 활성화 불필요, 추가 비용 없음이라는 제약을 모두 충족합니다. 주요 AWS 기능: - IAM Credential Report: 모든 IAM user와 root user를 나열하는 account 전체 보고서. - 감사에 흔히 사용되는 보안 관련 컬럼: mfa_active, user_creation_time, password_last_changed, access_key_1_active/access_key_2_active(및 관련 last rotated/last used 필드). - console에서 온디맨드로 생성(IAM > Credential report)하고 CSV로 다운로드 가능하여 “다운로드 가능한 CSV 보고서” 요구 사항과 일치. - 정기적인 컴플라이언스 점검을 지원하며 AWS Well-Architected Security Pillar 관행(강력한 identity 기반, MFA, credential lifecycle 관리)과 정렬됨. 흔한 오해: 비용 및 청구 도구(Cost Explorer, Cost and Usage Reports, Detailed Billing Reports)는 CSV를 생성할 수 있지만, 지출/사용량에 초점이 있으며 IAM credential 위생 상태를 다루지 않습니다. 이들은 IAM user별 MFA 상태, password 변경 날짜, access key 활성화 상태를 보고하지 않습니다. 또 다른 흔한 혼동은 IAM Access Analyzer 또는 AWS Config인데, 이들은 보안 상태에 도움을 줄 수는 있지만 console 내에서 이와 같은 정확한 통합 CSV를 제공하지 않거나 추가 서비스를 활성화해야 하므로(제약 위반) 요구 사항을 충족하지 못합니다. 시험 팁: “모든 IAM user + root에 대한 CSV”, “MFA enabled true/false”, “password/access key 상태”, “스크립트 없음” 같은 요구 사항이 보이면 즉시 “IAM credential report”를 떠올리면 됩니다. 또한 root user가 credential report에 포함된다는 점은 시험에서 자주 나오는 구분 포인트입니다.

문제 12

미디어 회사의 솔루션 리드는 다음 1시간 이내에 10,000 requests per second를 목표로 하고 multi-Region disaster recovery(RPO 15 minutes, RTO 1 hour)를 갖춘 multi-tier serverless video-metadata API를 위한 검증된 AWS reference architectures와 design diagrams를 찾아야 한다. AWS Cloud solution designs의 예시를 어디에서 찾아야 하는가?

문제 분석

핵심 개념: 이 문제는 검증된 AWS reference architectures, design patterns, 그리고 diagrams를 어디에서 찾는지 평가한다. 핵심 리소스는 AWS Architecture Center로, AWS Well-Architected Framework, reference architectures, 그리고 architecture diagrams를 포함한 공식 및 파트너 검증 아키텍처 가이던스를 큐레이션한다. 정답이 맞는 이유: 솔루션 리드는 multi-tier serverless API를 고규모(10,000 RPS)로, 그리고 multi-Region disaster recovery 목표(RPO 15 minutes, RTO 1 hour)에 맞춰 빠르게(다음 1시간 이내) 예시가 필요하다. AWS Architecture Center는 이를 위해 특별히 설계되었다. 미디어를 포함한 산업 전반과 serverless, high availability, disaster recovery 같은 요구사항 전반에 걸친 solution patterns와 reference architectures를 제공한다. 소프트웨어를 구매하거나 내부 catalog를 설정할 필요 없이 “AWS reference architectures와 design diagrams”를 찾을 수 있는 가장 직접적인 장소다. 그곳에서 기대할 수 있는 주요 AWS 기능/가이던스: Architecture Center 및 관련 공식 가이던스에서는 일반적으로 API Gateway + Lambda + DynamoDB/Aurora Serverless 같은 serverless API 패턴, CloudFront/ElastiCache를 통한 caching, SQS/SNS/EventBridge를 통한 asynchronous ingestion, 그리고 Route 53 health checks/failover, DynamoDB global tables 또는 Aurora Global Database, cross-Region replication을 활용한 multi-Region DR 접근 방식(active-active 또는 active-passive) 등을 찾을 수 있다. RPO 15 minutes를 위해서는 near-real-time replication 옵션을, RTO 1 hour를 위해서는 automated failover runbooks와 infrastructure-as-code를 확인하게 된다. 흔한 오해: AWS Marketplace에도 listing에 “reference architectures”가 포함될 수 있지만, 주 목적은 third-party software 및 solutions 구매이며, 큐레이션된 AWS design diagrams를 제공하는 곳이 아니다. AWS Service Catalog는 조직 내에서 내부적으로 승인된 products/blueprints를 배포하기 위한 것이지, 공개 AWS reference architectures를 발견하기 위한 것이 아니다. Trusted Advisor는 account별 best-practice checks(cost, security, fault tolerance 등)를 제공하는 것이지 architecture diagrams를 제공하지 않는다. 시험 팁: 문제가 “AWS reference architectures, solution designs, diagrams를 어디에서 찾는가”를 묻는다면 기본적으로 AWS Architecture Center(그리고 종종 Well-Architected Framework)를 떠올려라. third-party solutions 구매라면 Marketplace, 내부 표준화된 deployments라면 Service Catalog, account 최적화 점검이라면 Trusted Advisor를 생각하면 된다.

문제 13

3개의 데이터 센터에 걸쳐 240대의 온프레미스 Windows 및 Linux 서버를 운영하는 한 물류 회사가 AWS로의 마이그레이션을 계획하기 위해 2~4주간의 사용률 데이터를 수집하고 데이터 기반의 3년 TCO 비즈니스 케이스를 생성할 수 있는 무료 AWS 오퍼링을 원한다. 회사는 어떤 서비스 또는 도구를 사용해야 하는가?

문제 분석

핵심 개념: 이 문제는 AWS의 무료 마이그레이션 계획 및 비용/TCO 평가 도구에 대한 지식을 테스트한다. 특히, 짧은 관찰 기간(일반적으로 2~4주) 동안 온프레미스 사용률 데이터를 수집하고 AWS로 마이그레이션하기 위한 데이터 기반 Total Cost of Ownership (TCO) 및 비즈니스 케이스를 생성하도록 설계된 서비스를 묻는다. 정답이 맞는 이유: AWS Migration Evaluator(이전 명칭 TSO Logic)는 기존 환경에서 측정된 사용률을 사용해 3년 TCO 모델과 마이그레이션 비즈니스 케이스를 구축하도록 목적에 맞게 설계되었다. 온프레미스 서버(Windows 및 Linux)의 인벤토리와 성능 데이터를 가져오는 것을 지원하며, 서버 right-sizing, 라이선싱 고려사항, 가격 구성 요소 등을 반영해 온프레미스 비용과 AWS 비용을 비교할 수 있다. 문제에서 명시한 “무료 AWS 오퍼링”, “2~4주간의 사용률 데이터 수집”, “데이터 기반 3년 TCO 비즈니스 케이스 생성”은 Migration Evaluator의 표준 수행 모델과 정확히 일치한다. 주요 AWS 기능: Migration Evaluator는 데이터 수집(에이전트/컬렉터 및/또는 import), CPU/메모리/스토리지/네트워크 사용률 분석, right-sizing 및 비용 최적화를 위한 모델링을 제공한다. 또한 경영진이 바로 활용할 수 있는 산출물(비즈니스 케이스, TCO 보고서)을 생성하며, 가격 옵션(On-Demand, Savings Plans/Reserved Instances 가정)과 운영 비용 요소를 반영할 수 있다. 일반적으로 상세한 애플리케이션 리팩터링 결정 이전, 마이그레이션 라이프사이클 초기에 마이그레이션 웨이브를 정당화하고 우선순위를 정하기 위해 사용된다. 흔한 오해: Billing 도구(Billing Console, Billing Conductor)는 종종 “비용 계획” 솔루션으로 오해되지만, 이는 기존 AWS 사용량과 계정을 기반으로 동작하며 온프레미스 사용률 수집 및 마이그레이션 TCO 모델링을 수행하지 않는다. Amazon Forecast는 “예측”을 한다는 점에서 관련 있어 보일 수 있으나, 이는 시계열 수요를 예측하는 서비스이지 인프라 마이그레이션 경제성 분석을 위한 것이 아니다. 시험 팁: “2~4주간의 사용률 데이터”와 “3년 TCO 비즈니스 케이스”가 함께 나오면 Migration Evaluator를 떠올려라. TCO 비즈니스 케이스보다는 디스커버리/인벤토리에 초점이 있는 경우, 수험자는 종종 AWS Application Discovery Service와 혼동하지만, 이 문제는 특히 TCO 및 비즈니스 케이스 생성에 초점을 두고 있다. 또한 “무료(complimentary)”라는 표현은 강력한 단서인데, Migration Evaluator는 일반적으로 계량 과금 기능이 아니라 AWS 지원 평가 형태로 제공된다.

문제 14

한 의료 분석 회사는 us-east-1의 두 Availability Zone에 걸쳐 75개의 Amazon EC2 인스턴스를 실행하고 있으며, 에이전트를 배포하거나 커스텀 모델을 구축하지 않고도 machine learning을 사용해 Amazon VPC Flow Logs와 AWS CloudTrail 이벤트를 자동으로 상관관계 분석하여 분석가가 IP, 사용자, 인스턴스 ID 전반에서 빠르게 피벗할 수 있는 완전 관리형 서비스가 필요합니다. 이 요구 사항을 가장 잘 충족하는 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 여러 로그 소스(특히 VPC Flow Logs와 AWS CloudTrail)에서 신호를 상관관계 분석하여 incident triage와 피벗을 가속화하는, machine learning 및 graph 기반 분석을 사용하는 AWS 관리형 보안 조사 서비스에 대한 지식을 평가합니다. 정답이 맞는 이유: Amazon Detective는 AWS CloudTrail management events, Amazon VPC Flow Logs, Amazon GuardDuty findings를 포함한 AWS 소스의 보안 관련 데이터를 자동으로 수집, 정규화, 상관관계 분석하도록 목적에 맞게 설계되었으며, 이후 ML/통계 분석을 사용해 엔터티(사용자, 역할, IP 주소, EC2 인스턴스, API 호출)의 상호 연결된 대화형 뷰를 생성합니다. 에이전트를 배포하거나 커스텀 모델을 구축하지 않고 “IP, 사용자, 인스턴스 ID 전반에서 빠르게 피벗”해야 한다는 요구 사항은 Detective의 조사 워크플로와 엔터티 관계 그래프에 정확히 부합합니다. 이는 완전 관리형이며 분석가 주도의 조사를 위해 설계되었습니다. 주요 AWS 기능: Detective는 시간이 지남에 따라 행동 프로필과 관계 컨텍스트를 구축하여 분석가가 “무슨 일이 있었고 어떻게 연결되어 있는가?”에 답할 수 있도록 돕습니다. 엔터티 간 시각화 및 피벗을 제공합니다(예: VPC Flow Logs에서 관찰된 IP에서 CloudTrail의 IAM principal 및 영향을 받은 EC2 인스턴스로 피벗). GuardDuty와 긴밀하게 통합되며(종종 GuardDuty finding에서 시작해 Detective로 조사), Detective의 가치는 탐지 자체보다는 상관관계 분석 및 조사 레이어에 있습니다. 흔한 오해: GuardDuty도 ML을 사용하고 CloudTrail 및 VPC Flow Logs를 분석하므로 정답처럼 보일 수 있습니다. 그러나 GuardDuty의 주요 기능은 위협 탐지 및 findings 생성이지, 엔터티 전반에 걸친 조사를 위한 심층적이고 대화형 상관관계 그래프를 제공하는 것이 아닙니다. Inspector는 취약점 관리에 초점이 있고, QuickSight는 BI/시각화로서 보안 로그 상관관계 분석을 위한 내장 ML 조사 기능이 아닙니다. 시험 팁: “CloudTrail + VPC Flow Logs 상관관계 분석”, “엔터티 전반 피벗”, “조사”, “커스텀 모델/에이전트 없음”을 보면 Amazon Detective를 떠올리세요. “위협 탐지 및 findings 생성”을 보면 GuardDuty를 떠올리세요. “취약점/CVEs”를 보면 Inspector를 떠올리세요. 동사를 매칭하세요: detect(GuardDuty) vs investigate/correlate(Detective).

문제 15

한 리테일 분석 스타트업은 3개의 제품 라인(Alpha, Beta, Gamma)에 걸친 워크로드로 2개의 AWS account를 운영하고 있으며, 월 약 $12,000를 지출합니다. 재무팀은 월간 비용의 최소 95%를 각 제품 라인과 팀 오너에 귀속시켜야 하며, 그 내역을 AWS Cost Explorer와 인보이스에서 확인해야 합니다. 이러한 요구 사항을 충족하기 위해 어떤 AWS service 또는 feature를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 여러 account 전반에서 product line 및 team owner와 같은 비즈니스 차원에 AWS 비용을 할당하는 것에 관한 것입니다. 이를 위해 설계된 AWS 기능은 cost allocation tags이며, 이를 통해 리소스에 라벨을 지정한 다음 AWS billing 및 cost management 도구에서 해당 태그를 사용할 수 있습니다. 정답인 이유: Cost allocation tags를 사용하면 startup이 ProductLine=Alpha 및 TeamOwner=AnalyticsTeam과 같은 값으로 리소스에 태그를 지정한 다음, Billing and Cost Management console에서 해당 태그를 활성화할 수 있습니다. 활성화 후 이러한 태그는 AWS Cost Explorer 및 AWS Cost and Usage Report와 같은 상세 billing 데이터셋에서 사용할 수 있게 되어, finance 팀이 태그가 지정된 대부분의 지출을 올바른 product line 및 owner에 귀속시킬 수 있습니다. 95% 귀속률 달성은 강력한 tagging governance와 taggable 리소스 전반에 걸친 광범위한 태그 적용 범위에 달려 있습니다. 주요 AWS 기능: 1) User-defined cost allocation tags는 product line, owner 또는 cost center와 같은 비즈니스 소유 차원을 나타낼 수 있습니다. 2) 활성화된 태그는 Cost Explorer에 표시되어 지출을 그룹화하고 필터링할 수 있습니다. 3) 동일한 활성화된 태그는 더 심층적인 분석을 위해 CUR와 같은 상세 billing export에 포함됩니다. 4) AWS Organizations는 tag policies를 통해 일관된 tagging을 강제하는 데 도움이 될 수 있지만, 기본적인 allocation 기능은 아닙니다. 일반적인 오해: AWS Organizations는 consolidated billing 및 governance를 제공하지만, 그 자체로 비즈니스 차원별 비용을 할당하지는 않습니다. CUR는 상세한 원시 billing 데이터를 제공하지만, allocation 차원을 정의하는 핵심 기능이라기보다는 reporting export입니다. 또한 표준 AWS invoice는 일반적으로 사용자 지정 tag 기반 세부 내역으로 제공되지 않으므로, 실질적인 billing 가시성은 Cost Explorer 및 상세 billing report에서 나옵니다. 시험 팁: 시험에서 team, project, application 또는 product별로 비용을 할당하고 이를 Cost Explorer에서 보는 방법을 묻는다면 cost allocation tags를 떠올리세요. consolidated multi-account billing을 묻는다면 AWS Organizations를 떠올리세요. 사용자 지정 분석을 위한 가장 상세한 export를 묻는다면 AWS Cost and Usage Report를 떠올리세요.

문제 16

(2개 선택)

한 핀테크 스타트업이 4개의 microservices를 호스팅하기 위해 2개의 Availability Zones에 걸쳐 CIDR 블록 10.1.0.0/16을 사용하는 새로운 Amazon VPC를 프로비저닝하고 있습니다. 공개 웹 트래픽을 허용하면서 데이터베이스는 private 범위에 유지하기 위해, 솔루션스 아키텍트는 VPC의 일부로 생성되거나 VPC에 직접 연결되어야 하는 리소스를 나열합니다. 다음 중 이 요구 사항을 충족하는 native VPC 구성 요소는 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 Amazon VPC의 기본 구성 요소와, VPC와 통합되기만 하는 AWS managed service가 아니라 native VPC 구성 요소로 간주되는 것이 무엇인지 테스트합니다. 공개 웹 계층을 호스팅하면서 데이터베이스를 private로 유지하려면, subnet(공용/사설)을 설계하고 제어된 인터넷 연결을 제공해야 합니다. 정답이 맞는 이유: Subnet(E)은 VPC CIDR 내에서 IP 범위를 정의하는 핵심 VPC 구성 요소이며, EC2 instances, load balancers, RDS(DB subnet group 내) 같은 리소스를 배치하는 단위입니다. 웹 계층을 인터넷에 노출하려면 VPC에 Internet gateway(D)를 연결해야 합니다. Internet gateway는 적절한 route table 항목(0.0.0.0/0 -> IGW)과 public IPv4 addressing(public IP/EIP), 그리고 보안 제어와 결합될 때 public subnets의 리소스와 public internet 간 통신을 가능하게 합니다. 주요 AWS 기능 / 모범 사례: 일반적인 2-AZ 설계에서는 인터넷에 노출되는 구성 요소(예: ALB, web instances)를 위해 최소 두 개의 public subnets(AZ당 1개)와 데이터베이스를 위한 두 개의 private subnets를 생성합니다. Internet gateway를 VPC에 연결하고, public subnets를 0.0.0.0/0을 IGW로 라우팅하는 route table과 연결하며, private subnets는 IGW로의 직접 라우트를 두지 않습니다. private 리소스에 outbound internet(패치, 패키지 저장소)이 필요하다면 public subnets에 NAT gateways를 추가합니다(이 문제에서는 묻지 않음). AWS Well-Architected의 Security 및 Reliability pillar에 맞춰 layered security를 위해 security groups와 NACLs를 사용합니다. 흔한 오해: 많은 응시자가 “VPC 안에 있음”과 “VPC와 통합됨”을 혼동합니다. API Gateway, S3, Storage Gateway는 VPC 자체의 일부로 생성/연결하는 VPC 구성 요소가 아닙니다. 이들은 VPC endpoints(S3/API Gateway private integrations)로 private하게 액세스하거나 네트워킹을 통해 연결될 수는 있지만, native VPC 구성 요소는 아닙니다. 시험 팁: 핵심 VPC 구성 요소를 암기하세요: VPC, subnets, route tables, IGW, NAT gateway, NACLs, security groups, DHCP options sets, endpoints, peering/TGW attachments. 문제가 “VPC의 일부로 생성되거나 VPC에 직접 연결됨”이라고 하면, 관리형 상위 서비스가 아니라 VPC 내부에 실제로 존재하는 구성 요소(subnets) 또는 VPC에 attach되는 구성 요소(IGW)를 고르세요.

문제 17

(2개 선택)

12개월의 runway를 가진 한 fintech startup이 5년에 걸쳐 감가상각되는 $180,000의 on-premises hardware를 구매하는 것과, 하루에 20~120 vCPUs로 예상 수요가 변동하고 storage가 매달 2 TB씩 증가하는 AWS를 사용하는 것 사이에서 선택하고 있습니다. 이 시나리오에서 AWS 사용의 cost-effectiveness를 가장 잘 설명하는 두 가지 진술은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 on-premises CapEx 대비 AWS cloud economics 및 pricing models—특히 variable OpEx(pay-as-you-go)로의 전환과 economies of scale(더 낮은 unit costs)의 이점을 평가합니다. 이는 AWS Cloud Value Proposition 및 AWS Well-Architected Framework의 Cost Optimization pillar와 연관됩니다. 정답인 이유: 이 startup은 12개월 runway를 가지고 있으며 compute 수요가 크게 변동(하루 20–120 vCPUs)하고 storage는 꾸준히 증가(매달 2 TB)합니다. On-prem hardware는 큰 upfront 구매($180,000)가 필요하고 5년에 걸쳐 감가상각되지만, 비즈니스는 12개월 runway만 보유하고 있어 cash-flow risk가 발생하고 수요가 예상보다 낮을 경우 stranded capacity가 생길 수 있습니다. AWS는 실제 일일 수요에 맞춰 capacity를 조정하고 필요 없을 때 scale down할 수 있어 fixed costs를 variable costs로 전환합니다(A). 또한 AWS는 많은 고객의 수요를 집계하고 대규모로 infrastructure를 조달하므로, 일반적으로 작은 startup이 자체적으로 달성할 수 있는 것보다 더 낮은 per-unit pricing을 제공합니다(E). 이는 storage 증가와 compute에 특히 중요하며, right-sized instances, 예측 가능한 baseline에 대한 Savings Plans/Reserved Instances, 그리고 spikes에 대한 On-Demand/Spot을 활용할 수 있습니다. 주요 AWS 기능: compute 변동성에 대해 Auto Scaling과 EC2, ECS, 또는 EKS를 사용하면 20~120 vCPUs 사이로 scale할 수 있으며, 혼합 구매 옵션(On-Demand는 bursts, Spot은 유연한 workloads, Savings Plans는 baseline)을 통해 cost를 최적화할 수 있습니다. storage 증가에 대해서는 Amazon S3의 lifecycle policies(예: S3 Standard에서 IA/Glacier로)와 EBS volume right-sizing 같은 서비스가 월별 TB 증가를 관리하는 데 도움이 됩니다. cost 가시성 도구(AWS Cost Explorer, Budgets)는 runway 관리를 지원합니다. 흔한 오해: multi-Region 속도(B), agility(C), managed patching(D) 같은 선택지는 실제 AWS의 이점이지만, 이 시나리오에서 cost-effectiveness를 가장 잘 설명하지는 않습니다. 이는 직접적인 cost 구조 및 unit economics보다는 operational agility와 shared responsibility에 더 가깝습니다. 시험 팁: 문제가 upfront hardware 구매, depreciation, runway, variable demand를 강조하면 CapEx-to-OpEx 전환과 economies of scale에 관한 답을 찾으십시오. usage 변동이 언급되면 pay-as-you-go와 elasticity가 보통 핵심입니다. “cost-effectiveness”와 patching 또는 빠른 글로벌 배포 같은 “operational convenience” 이점을 구분하십시오.

문제 18

한 소매 회사가 하루 약 15,000건의 주문을 처리하는 9년 된 온프레미스 Java 모놀리스를 운영하고 있으며 AWS로 마이그레이션하는 동안 이를 CI/CD와 도메인 주도 경계를 갖춘 컨테이너에서 실행되는 12개의 독립적으로 배포 가능한 마이크로서비스로 분리하려고 합니다. 회사는 어떤 마이그레이션 전략을 선택해야 합니까?

문제 분석

핵심 개념: 이 문제는 AWS migration strategies(일반적으로 “7 Rs”로 설명됨)와 원하는 target architecture를 기준으로 적절한 전략을 선택하는 방법을 평가합니다. 이 시나리오는 legacy on-premises Java monolith를 containerized되고 independently deployable한 microservices로, 그리고 CI/CD 및 domain-driven boundaries를 갖춘 구조로 의도적으로 modernize하는 상황을 설명합니다. 정답인 이유: 이 회사는 9년 된 monolith를 12개의 independently deployable microservices로 분리하고, 이를 containers에서 실행하며, CI/CD와 domain-driven boundaries를 구현하기를 명확히 원합니다. 이는 lift-and-shift나 소규모 platform 조정이 아니라, service decomposition, API design, data ownership separation, deployment automation, observability, resilience patterns와 같은 상당한 code 및 architecture 변경이 필요합니다. AWS migration terminology에서 이는 Refactor/Re-architect에 해당하며, 조직이 agility, independent scaling, faster releases와 같은 cloud-native 이점을 원할 때 사용됩니다. 주요 AWS 기능: 일반적인 AWS 구현에서는 containers를 위해 Amazon ECS 또는 Amazon EKS, container images를 위해 Amazon ECR, 그리고 CI/CD를 위해 AWS CodePipeline, CodeBuild, CodeDeploy 또는 이에 상응하는 third-party tooling을 사용할 수 있습니다. Microservices는 routing을 위해 Application Load Balancer 또는 Amazon API Gateway를 사용할 수 있고, decoupled communication을 위해 Amazon SQS, SNS 또는 EventBridge를, monitoring 및 tracing을 위해 CloudWatch와 AWS X-Ray를 사용할 수 있습니다. 또한 팀은 Amazon Aurora 또는 DynamoDB와 같은 서비스를 사용하여 service별로 별도의 data store를 채택할 수 있습니다. 흔한 오해: Replatform는 일부 optimization을 허용하므로 그럴듯하게 들릴 수 있지만, 일반적으로 monolith를 여러 개의 independently deployable microservices로 분해하는 작업까지 포함하지는 않습니다. Rehost는 주로 application을 최소한의 변경으로 있는 그대로 이동하는 방식입니다. Repurchase는 custom application을 다른 product 또는 SaaS offering으로 대체하는 것을 의미하므로, custom microservices architecture를 구축하려는 명시된 목표와는 맞지 않습니다. 시험 팁: 문제에서 microservices, independently deployable services, containers, CI/CD 또는 domain-driven design이 언급되면, 보통 Refactor/Re-architect가 가장 적절한 정답입니다. Rehost와 Replatform는 더 적은 code 변경으로 더 빠른 migration에 초점을 맞추는 반면, Refactor는 깊이 있는 architectural modernization와 cloud-native 결과를 위해 선택됩니다.

문제 19

한 핀테크 스타트업이 dev, test, 그리고 4개의 프로덕션 팀을 위해 서로 분리된 6개의 AWS 계정을 운영하고 있으며, 하나의 관리(지불자) 계정을 지정해 단일 월간 청구서를 수령하고, 연결된 모든 계정을 대신해 결제하며, 사용량을 자동으로 집계해 볼륨 기반 요금 할인 자격을 얻고자 합니다. 어떤 AWS 서비스 또는 도구를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 consolidated billing 및 비용 집계를 위한 AWS Organizations를 테스트합니다. AWS Organizations를 사용하면 여러 AWS 계정을 중앙에서 관리하고, 모든 멤버 계정에 대한 단일 청구서를 수령하는 관리(지불자) 계정을 지정할 수 있습니다. 정답이 맞는 이유: 이 스타트업은 (1) 하나의 관리/지불자 계정, (2) 단일 월간 청구서, (3) 연결된 계정을 대신한 결제, (4) 볼륨 기반 요금 할인 자격을 위한 사용량 자동 집계를 원합니다. 이는 AWS Organizations의 consolidated billing이 제공하는 대표적인 결과입니다. 계정이 organization에 포함되면 멤버 계정의 요금이 관리 계정으로 롤업되어 청구 및 결제가 이루어집니다. 또한 많은 서비스에서 organization 전체에 걸쳐 계층형/볼륨 요금제가 적용되므로, 집계된 사용량으로 더 낮은 단가의 요금 구간으로 이동할 수 있습니다. 주요 AWS 기능: - Consolidated billing: 관리 계정에서 단일 청구서 및 중앙 결제. - 대규모 계정 연결: organization에 계정을 생성/초대하고 Organizational Units (OUs)로 구성. - 비용 가시성: 관리 계정에서 Cost Explorer 및 Cost and Usage Report (CUR)를 사용해 계정 전반의 지출 분석. - 할인 공유: 계층형 요금제를 위한 사용량 집계; 또한 특정 할인 공유를 활성화(시험에서 consolidated billing과 함께 자주 언급). - 거버넌스(부가 이점): Service Control Policies (SCPs)로 가드레일을 강제할 수 있으나, 청구에는 필수 아님. 흔한 오해: AWS Budgets는 종종 청구 통합 도구로 오해되지만, 이는 알림/임계값 설정만 제공하며 단일 청구서를 생성하거나 요금 구간을 위한 사용량 집계를 수행하지 않습니다. Trusted Advisor는 모범 사례 점검과 비용 최적화 권장 사항을 제공하지만 계정 또는 청구를 통합하지 않습니다. Service Catalog는 승인된 리소스 프로비저닝을 표준화하는 서비스이지, 청구를 위한 서비스가 아닙니다. 시험 팁: “단일 월간 청구서,” “payer/management account,” “pay on behalf of,” “linked accounts,” “volume pricing/aggregated usage” 같은 키워드가 보이면 정답은 AWS Organizations (consolidated billing)입니다. 또한 AWS Organizations는 상위(umbrella) 서비스이고, “consolidated billing”은 여기서 테스트되는 구체적 기능임을 기억하세요.

문제 20

한 대학 연구실은 3개의 프로젝트에 걸쳐 150명의 IAM user가 있는 단일 AWS account를 사용하며, 분기별 컴플라이언스 점검을 수행하여 각 user에 대해 마지막 password 변경 날짜와 활성 access key 중 90일을 초과한 것이 있는지 여부를 확인해야 합니다. 또한 감사자는 모든 user에 대한 이러한 세부 정보를 나열한 다운로드 가능한 CSV를 요구합니다. 이 요구 사항을 충족하는 AWS service 또는 tool은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 credential 위생 및 컴플라이언스 증빙을 위한 AWS IAM account 수준의 reporting 지식을 평가합니다. 특히 account 내 모든 IAM user에 대해 password 및 access key age 세부 정보를 포함하는 감사 가능하고 내보낼 수 있는 report를 생성하는 데 초점을 둡니다. 정답이 맞는 이유: IAM credential report는 정확히 이 요구 사항을 위해 만들어졌습니다. 모든 IAM user와 주요 credential metadata를 나열하는 다운로드 가능한 CSV를 생성하며, 여기에는 마지막 password 변경 날짜와 access key의 age/status가 포함됩니다. 감사자가 모든 user(150명)에 대한 CSV를 요구하고 연구실이 분기별로 password 및 90일을 초과한 access key를 점검해야 하므로, credential report는 다운로드하여 검토하거나(예: Excel에서) 필터링해 비준수 user 및 key를 식별할 수 있는 단일 표준 산출물을 제공합니다. 주요 AWS 기능: IAM credential report는 account 수준에서 생성되며 password_last_changed, password_enabled, access_key_1_active, access_key_1_last_rotated, access_key_2_active, access_key_2_last_rotated 같은 필드를 포함합니다. 이를 통해 “last_rotated” 날짜를 현재 날짜와 비교하여 활성 access key가 90일을 초과했는지 여부를 쉽게 판단할 수 있습니다. report는 CSV 형식으로 제공되어 감사자의 “다운로드 가능한 CSV” 요구 사항을 충족합니다. IAM console 또는 AWS CLI/API(GenerateCredentialReport 및 GetCredentialReport)로 생성할 수 있어 분기별 자동화에도 유용합니다. 흔한 오해: IAM Access Analyzer와 AWS Audit Manager는 종종 “auditing”과 연관되지만, user별 password 변경 날짜와 access key age를 나열한 CSV를 직접 생성하지는 않습니다. AWS Artifact 역시 컴플라이언스와 관련이 있지만, 이는 AWS(서비스 제공자)의 컴플라이언스 report를 제공하는 것이지, 귀하의 account의 IAM user credential 상태를 제공하는 것이 아닙니다. 시험 팁: “모든 IAM user 나열”, “마지막 password 변경”, “access key age/rotation”, “다운로드 가능한 CSV” 같은 요구 사항이 보이면 즉시 “IAM credential report”를 떠올리십시오. Access Analyzer는 resource access policy 및 외부 access finding을 위한 것이고, Audit Manager는 단순한 IAM credential inventory export가 아니라 framework에 대한 더 광범위한 evidence 수집을 위한 것입니다.