연습 문제

문제 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

스트리밍 미디어 스타트업이 단일 AWS Region 내 4개의 Availability Zone에 걸쳐 Amazon EC2 인스턴스에서 웹 애플리케이션을 실행하고 있다. 요청의 75%는 정적 이미지, CSS, JavaScript에 대한 것이며, 회사는 북미, 유럽, 아시아의 사용자로부터 분당 30,000건의 요청을 예상한다. 또한 다른 Region에 추가 애플리케이션 서버를 배포하지 않으면서 정적 자산의 전 세계 중앙값(median) 지연 시간을 60ms 미만으로 유지해야 한다. 이러한 요구 사항을 충족하기 위해 회사가 사용해야 하는 AWS 서비스는 무엇인가?

문제 분석

핵심 개념: 이 문제는 여러 Region에 추가 애플리케이션 서버를 배포하지 않고도 정적 자산에 대한 전 세계 콘텐츠 전송과 지연 시간 최적화를 테스트한다. 핵심 서비스는 CDN(Content Delivery Network)으로, 최종 사용자와 가까운 위치에서 콘텐츠를 캐시한다. 정답이 맞는 이유: Amazon CloudFront는 전 세계 엣지 로케이션 네트워크를 사용하여 정적 콘텐츠(이미지, CSS, JavaScript)를 캐시하고 매우 낮은 지연 시간으로 제공하는 AWS의 CDN이다. 요청의 75%가 정적 자산이며 사용자 기반이 북미, 유럽, 아시아에 분산되어 있으므로, 단일 Region에서 가져오는 것보다 CloudFront 엣지 로케이션에서 제공하면 왕복 시간이 크게 줄어든다. 이는 다른 Region에 추가 애플리케이션 서버를 배포하지 않으면서 전 세계 중앙값 지연 시간 60ms 미만 요구 사항을 직접적으로 지원한다. 주요 AWS 기능 / 구성 방법: CloudFront distribution은 기존 Regional origin(예: Application Load Balancer 또는 S3 bucket)을 사용하고 엣지에서 정적 객체를 캐시할 수 있다. 다음을 수행한다: - origin(ALB/EC2 또는 S3)과 정적 경로(예: /static/*)에 대한 behavior를 구성한다. - 적절한 TTL과 cache policy를 설정하고, 업데이트를 위해 버전이 포함된 파일명 또는 cache invalidation을 사용한다. - CSS/JS에 대해 compression(Brotli/Gzip)을 활성화한다. - 높은 요청률(30,000/분)에서 origin 부하를 줄이기 위해 Origin Shield(선택 사항)를 사용한다. - HTTPS를 사용하고, 보호를 위해 엣지에서 AWS WAF를 선택적으로 사용한다. 흔한 오해: Route 53는 사용자를 엔드포인트로 라우팅할 수 있지만 엣지에서 콘텐츠를 캐시하지는 않으므로, 단독으로는 정적 자산에 대한 엄격한 전 세계 지연 시간 요구 사항을 충족하지 못한다. Elastic Load Balancing은 Region 내 분산을 개선하지만 전 세계 엣지 캐싱을 제공하지 않는다. Lambda는 엣지(Lambda@Edge) 또는 Region에서 코드를 실행할 수 있지만, 정적 콘텐츠 전송을 가속하는 1차 솔루션은 아니다. 시험 팁: “정적 콘텐츠”, “전 세계 사용자”, “낮은 지연 시간”, “단일 Region origin”이 보이면 기본적으로 가장 좋은 답은 CloudFront이다. 가능하면 정적 호스팅을 위해 S3와 함께 사용하거나, 자산이 애플리케이션에서 제공되는 경우 origin으로 ALB/EC2와 함께 사용한다. 기억할 점: DNS 라우팅(Route 53)과 로드 밸런싱(ELB)은 CDN이 아니다. CloudFront가 이 요구 사항을 위해 설계된 CDN 서비스이다.

문제 4

한 미디어 스타트업은 사용자가 업로드한 사진 200 TB를 99.999999999% 내구성으로 저장해야 하며, HTTPS를 통해 REST로 객체 형태로 접근 가능해야 하고 객체 수준 메타데이터와 수명 주기 규칙을 통해 30일 후 데이터를 더 저렴한 infrequent-access 티어로 전환해야 합니다. 이러한 요구 사항을 가장 잘 충족하는 AWS 서비스는 무엇입니까?

문제 5

한 차량 공유 startup이 평일에 트래픽 급증을 겪고 있으며, 동시 요청이 10분 내에 800에서 4,500으로 증가했다가 자정 이후에는 다시 600 미만으로 떨어집니다. 또한 인스턴스 전반의 평균 CPU utilization이 5분 동안 70%를 초과하면 cloud가 자동으로 compute capacity를 추가하고, 10분 동안 30% 미만으로 떨어지면 해당 capacity를 제거하여 사용한 만큼만 비용을 지불하고자 합니다. 이 목표를 가장 잘 나타내는 AWS 개념은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS Cloud의 탄력성(elasticity) 개념을 테스트합니다. 탄력성은 수요에 맞춰 리소스를 자동으로 증가 및 감소시키고, 사용한 만큼만 비용을 지불하는 능력입니다. AWS에서는 일반적으로 Amazon EC2 Auto Scaling(대개 Auto Scaling group에서)과 Amazon CloudWatch metrics에 의해 구동되는 scaling policies로 구현됩니다. 정답이 맞는 이유: 이 startup의 workload는 예측 가능한 일일 피크와 저점을 가지며, 평균 CPU > 70%가 5분 지속되면 capacity를 추가하고 CPU < 30%가 10분 지속되면 capacity를 제거하길 명시적으로 원합니다. 이는 탄력성의 교과서적 정의입니다. 즉, 수요 신호에 기반해 빠르고 자동으로 scale out 및 scale in을 수행하여 피크 동안 성능을 유지하면서도 낮은 utilization 구간에서는 비용을 최소화합니다. 주요 AWS 기능: 일반적인 구현은 여러 Availability Zones에 걸친 Auto Scaling group과, ASG의 Average CPUUtilization metric에 대한 CloudWatch alarms를 사용합니다. Target tracking 또는 step scaling policies를 임계값과 평가 기간(예: 70% 초과 5분이면 scale out, 30% 미만 10분이면 scale in)으로 구성할 수 있습니다. Cooldowns/warm-up 설정은 thrashing을 방지하는 데 도움이 됩니다. 탄력성은 더 상위 계층(예: AWS Lambda concurrency, ECS Service Auto Scaling)에서도 지원되지만, 문제의 “instances”와 CPU 임계값은 EC2 Auto Scaling + CloudWatch와 강하게 부합합니다. 흔한 오해: 많은 사람들이 scalability와 elasticity를 혼동합니다. Scalability는 시스템이 성장(대개 장기적)을 처리할 수 있도록 리소스를 추가하거나 더 높은 capacity를 위해 설계하는 능력이지만, 반드시 자동적이고 빠르며 양방향의 scaling을 의미하지는 않습니다. Sustainability와 operational excellence는 Well-Architected pillars로 중요하지만, CPU 기반의 자동 scale-out/scale-in 동작을 설명하는 1차 개념은 아닙니다. 시험 팁: metrics의 시간 구간에 따라 “자동으로 capacity를 추가”하고 “capacity를 제거”한다는 표현이 보이면, 탄력성과 Auto Scaling을 떠올리세요. “pay only for what it uses”, “spikes”, “drops”, “scale out/in”, CloudWatch alarm thresholds 같은 단서를 찾으세요. 문제가 장기 성장 계획이나 더 높은 throughput을 위한 재설계를 강조했다면 scalability가 더 적합할 수 있지만, 자동화를 통한 동적 right-sizing을 강조한다면 탄력성입니다.

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

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

문제 6

SOC 2 Type II 감사를 진행 중인 한 fintech 회사는 3개의 AWS Region에 걸쳐 있는 200개의 Amazon EC2 인스턴스와 60개의 Amazon RDS DB 인스턴스에 대해 리소스 구성 변경 사항을 최소 90일 동안 자동으로 기록하고 보관해야 하며, 외부 감사인이 검토할 수 있도록 정기적인 구성 및 규정 준수 보고서를 내보내야 합니다. 이러한 요구 사항을 충족하기 위해 회사는 어떤 AWS 서비스를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 여러 AWS Region 전반에서 지속적인 configuration 모니터링, change tracking, 그리고 audit-ready reporting을 테스트하며, 이러한 기능은 AWS Config가 제공합니다. SOC 2 Type II는 시간에 걸친 지속적인 통제와 증빙을 강조하므로, resource configuration 변경 사항과 compliance 상태에 대한 자동화되고 내구성 있는 기록이 필요합니다. 정답인 이유: AWS Config는 지원되는 resource(예: Amazon EC2 instances 및 Amazon RDS DB instances)의 configuration 변경 사항을 기록하고, configuration history의 timeline을 유지하며, AWS Config Rules를 사용해 resource를 원하는 configuration과 비교하여 평가할 수 있습니다. 이는 compliance audit를 위해 설계되었습니다. configuration items와 snapshots를 보관하고, 과거 상태를 조회하며, reports/증빙을 external auditors를 위해 Amazon S3로 export할 수 있습니다. 또한 AWS Config Aggregators를 통해 multi-Region 및 multi-account aggregation을 지원하므로, “세 개의 Region”과 상당한 규모의 fleet에 이상적입니다. 주요 AWS 기능: 1) Configuration recording: 각 Region에서 AWS Config recorders를 활성화하여 EC2 및 RDS의 변경 사항을 캡처합니다. 2) Retention: configuration items에 대한 retention period(예: 90일 이상)를 설정하고, 필요 시 더 긴 보관을 위해 lifecycle policies가 적용된 S3 bucket에 전달된 configuration history와 snapshots를 저장합니다. 3) Compliance evaluation: managed 또는 custom Config Rules를 사용하여 compliance를 평가합니다(예: encryption, public access, security group rules). 4) Reporting/export: configuration snapshots와 compliance 결과를 S3로 전달합니다. auditors는 export된 파일을 검토할 수 있고, 또는 S3/Athena/QuickSight의 AWS Config 데이터를 사용해 정기 reports를 생성할 수 있습니다. 5) Central visibility: aggregator를 사용하여 한 곳에서 Region(및 account) 전반의 compliance와 configuration을 확인합니다. 일반적인 오해: 팀은 종종 AWS Config를 Amazon Inspector와 혼동합니다. Inspector는 vulnerability management와 runtime/package exposure에 초점을 맞추며, authoritative한 configuration history와 change timeline을 제공하는 서비스는 아닙니다. 또 어떤 사람들은 “changes”에 대한 답이 CloudTrail이라고 생각할 수 있지만, CloudTrail은 API activity를 기록할 뿐, 그 결과로 나타난 resource configuration state와 compliance evaluation을 기록하지는 않습니다. 시험 팁: “record configuration changes”, “configuration history”, “compliance rules”, “audit evidence”, “multi-Region”, “export reports”와 같은 표현이 보이면 기본적으로 AWS Config를 떠올리세요. 내구성 있는 보관을 위해 S3와 함께 사용하고, 중앙 집중식 reporting을 위해 선택적으로 aggregation을 결합하는 것은 SOC 2, ISO 27001, PCI 증빙 수집에서 흔한 패턴입니다.

문제 7

한 미디어 스트리밍 회사는 Amazon S3에서 매일 밤 배치 로드되는 20 TB의 과거 클릭스트림 데이터에 대해 복잡한 분석용 SQL 쿼리를 실행해야 하며, 컬럼형 스토리지, 대규모 병렬 처리, 최대 30명의 동시 분석가를 위한 BI 도구와의 통합이 필요합니다. 이 사용 사례에 대해 페타바이트 규모의 데이터 웨어하우스를 가장 잘 제공하는 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 복잡한 SQL 분석을 위한 AWS의 목적별(purpose-built) 페타바이트 규모 분석 데이터 웨어하우스 서비스인 Amazon Redshift를 식별하는지를 평가합니다. 주요 단서로는 컬럼형 스토리지, massively parallel processing (MPP), 대규모 과거 데이터셋(20 TB 및 증가), Amazon S3에서의 매일 밤 배치 로드, 그리고 많은 동시 분석가를 위한 BI 도구 연결이 있습니다. 정답이 맞는 이유: Amazon Redshift는 OLAP 워크로드(분석)를 위해 설계되었으며 MPP 아키텍처를 사용해 대규모 데이터셋에 대한 복잡한 분석 SQL 쿼리를 지원합니다. Amazon S3와 네이티브로 통합되어 대량 로드(COPY command)를 지원하며, 클릭스트림 분석 및 리포팅에 흔히 사용됩니다. Redshift의 컬럼형 스토리지와 압축은 I/O를 줄이고 스캔 성능을 향상시키며, 이는 클릭스트림 데이터에 일반적인 대규모 팩트 테이블에서 매우 중요합니다. 또한 표준 JDBC/ODBC 연결을 지원하므로 BI 도구와 쉽게 통합할 수 있고, 약 30명의 동시 분석가를 지원할 수 있습니다(대개 Concurrency Scaling 및/또는 Redshift Serverless를 통해). 주요 AWS 기능: - 효율적인 스캔을 위한 컬럼형 스토리지 + 고급 압축. - 노드 전반에 걸친 MPP 쿼리 실행; RA3 instances는 compute와 storage를 분리하여 확장 가능하고 비용 효율적인 성장을 지원. - 고처리량 배치 수집을 위한 S3에서의 COPY; AWS Glue, Step Functions 또는 managed workflows로 매일 밤 오케스트레이션 가능. - 동시 쿼리 급증 시 자동으로 일시적 용량을 추가하는 Concurrency Scaling. - 동일한 SQL로 S3(데이터 레이크)의 데이터를 직접 쿼리하는 Redshift Spectrum으로, 웨어하우스 스토리지를 보완. - IAM, KMS encryption, VPC 및 JDBC/ODBC를 통한 BI 통합. 흔한 오해: RDS와 Aurora는 OLTP(트랜잭션) 워크로드에 최적화된 관계형 데이터베이스이며, 컬럼형/MPP 실행을 사용하는 대규모 분석에는 적합하지 않습니다. DynamoDB는 NoSQL key-value/document 스토어로, 대규모 데이터셋 전반에 걸친 복잡한 분석 SQL 조인/집계를 동일한 방식으로 지원하지 않습니다. 시험 팁: “data warehouse”, “columnar”, “MPP”, “petabyte-scale analytics”, “S3 bulk loads”, “BI tools”가 보이면 기본적으로 Amazon Redshift를 선택하세요. 로드 없이 S3 데이터를 쿼리하는 것이 강조되면 Redshift Spectrum 또는 Athena를, lakehouse 거버넌스가 강조되면 Glue/Lake Formation을 고려하되, 관리형 웨어하우스라면 Redshift가 정석 답입니다.

문제 8

한 미디어 분석 회사가 온프레미스 모놀리식 리포팅 애플리케이션을 AWS로 마이그레이션하고, 이를 약 12개의 도메인 정렬 마이크로서비스로 분해하며, 워크로드를 컨테이너화하여 2개의 Availability Zone에 걸쳐 Amazon EKS에 배포하려고 합니다. 또한 독립적인 CI/CD 파이프라인과 오토스케일링을 적용하려고 하며, 팀은 이벤트 기반 패턴과 관리형 클라우드 네이티브 기능을 채택하기 위해 코드의 약 30%를 재작성할 의향이 있습니다. 이 목표에 가장 부합하는 마이그레이션 전략은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS 마이그레이션 전략(“6 Rs”)과 원하는 아키텍처 변경 수준에 따라 어떤 전략을 선택해야 하는지를 평가합니다. 또한 마이크로서비스 분해, Amazon EKS의 컨테이너, 이벤트 기반 설계, 관리형 서비스, 독립적인 CI/CD, 오토스케일링과 같은 클라우드 네이티브 현대화 패턴도 다룹니다. 정답이 맞는 이유: Refactor(Refactor는 re-architect라고도 함)가 가장 적합합니다. 회사가 명시적으로 큰 애플리케이션 변경을 계획하고 있기 때문입니다: 모놀리스를 약 12개의 도메인 정렬 마이크로서비스로 분해하고, 이벤트 기반 패턴을 채택하며, 관리형 클라우드 네이티브 기능을 활용하려고 합니다. 코드의 약 30%만 재작성하더라도 아키텍처 전환은 상당합니다. 서비스 경계, 통신 패턴(동기 호출 대비 이벤트), 배포 모델(컨테이너), 운영 모델(독립 파이프라인 및 스케일링)이 바뀌며, 이는 lift-and-shift나 소규모 플랫폼 조정이 아니라 리팩터링의 전형적인 신호입니다. 주요 AWS 기능: 2개의 AZ에 걸친 EKS에서 각 마이크로서비스는 Horizontal Pod Autoscaler (HPA)와 Cluster Autoscaler를 통해 탄력성을 확보하면서 별도의 Kubernetes Deployment로 실행될 수 있습니다. 독립적인 CI/CD 파이프라인은 일반적으로 AWS CodePipeline/CodeBuild 또는 서드파티 도구를 사용하며, Helm/Argo CD로 배포합니다. 이벤트 기반 패턴은 보통 Amazon EventBridge, Amazon SNS/SQS 또는 Amazon MSK를 사용하며, 서비스가 이벤트를 발행/소비하여 결합도를 낮춥니다. 관리형 클라우드 네이티브 기능에는 Amazon RDS/Aurora, DynamoDB, ElastiCache 또는 Step Functions 등이 포함될 수 있으며, 이는 AWS Well-Architected 원칙(신뢰성, 성능 효율성, 운영 우수성)에 부합합니다. 흔한 오해: Replatform은 컨테이너와 EKS가 “플랫폼 변경”이므로 그럴듯해 보일 수 있지만, replatforming은 최소한의 코드 변경과 큰 재설계가 없음을 의미합니다(예: “lift, tinker, and shift”). 여기서는 마이크로서비스로 분해하고 이벤트 기반 아키텍처를 채택하려는 의도가 있으므로 replatforming을 넘어섭니다. Rehost는 모놀리스를 최소 변경으로 유지하므로 명백히 부족합니다. Repurchase는 SaaS/COTS 제품으로 이동하는 것이며, 컨테이너화 및 재설계를 하겠다는 계획과 맞지 않습니다. 시험 팁: “microservices”, “event-driven”, “managed services”, “rewrite code”, “re-architect” 같은 키워드는 Refactor를 강하게 시사합니다. 시나리오가 최소 코드 변경과 주로 인프라/플랫폼 조정에 초점을 둔다면 Replatform을 가리킵니다. “그대로 이동”이면 Rehost입니다. “SaaS로 교체”면 Repurchase입니다.

문제 9

한 전자상거래 스타트업이 4개의 AWS 계정을 운영하고 있으며, 버전 관리되는 YAML 템플릿을 사용해 변경 세트와 자동 롤백을 포함하여 2개 Region에 걸쳐 동일한 VPC, IAM 역할, Amazon RDS 인스턴스를 반복적으로 프로비저닝해야 합니다. Infrastructure as code를 구현하기 위해 어떤 AWS 서비스를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 AWS에서의 Infrastructure as Code (IaC)와, 선언적 템플릿으로 AWS 리소스를 네이티브하게 프로비저닝 및 관리하면서 안전한 배포 메커니즘을 제공하는 서비스를 묻습니다. 정답이 맞는 이유: AWS CloudFormation은 버전 관리되는 YAML/JSON 템플릿을 사용하여 여러 Region과 계정에 걸쳐 동일한 리소스 스택(VPC, IAM 역할, RDS 등)을 반복적으로 프로비저닝하는 AWS 네이티브 IaC 서비스입니다. CloudFormation은 템플릿 업데이트의 영향을 실행 전에 미리 확인할 수 있도록 Change Sets를 지원하며, 실패 시 스택을 마지막으로 정상 동작하던 상태로 되돌리는 자동 롤백을 제공합니다. 이러한 요구 사항(YAML 템플릿, change sets, rollback)은 CloudFormation의 핵심 기능과 직접적으로 일치합니다. 주요 AWS 기능: - Templates (YAML/JSON)는 리소스와 종속성을 선언적으로 정의합니다. - Stacks 및 Stack Updates는 라이프사이클(create/update/delete)을 일관되게 관리합니다. - Change Sets는 변경 적용 전에 추가/수정/삭제될 항목을 보여줍니다. - Automatic rollback 및 drift detection은 안전성과 거버넌스를 향상합니다. - Cross-account 및 multi-Region 배포는 일반적으로 CloudFormation StackSets(종종 AWS Organizations와 함께)를 통해 구현되며, 여러 계정과 Region에 걸쳐 일관된 프로비저닝을 가능하게 합니다. - CI/CD(예: CodePipeline)와의 통합을 통해 버전 관리 기반 배포를 지원합니다. 흔한 오해: 일부는 Elastic Beanstalk가 “리소스를 프로비저닝한다”는 이유로 선택할 수 있지만, 이는 애플리케이션 플랫폼 배포에 초점이 맞춰져 있으며 change sets를 포함해 VPC/IAM/RDS에 대한 범용 IaC 용도가 아닙니다. CodeDeploy 또한 CI/CD의 일부이지만 애플리케이션 코드를 배포하는 서비스이지, 기반 인프라를 프로비저닝하는 서비스가 아닙니다. API Gateway는 인프라 프로비저닝과 관련이 없습니다. 시험 팁: “YAML templates”, “change sets”, “rollback”, “동일한 AWS 리소스 프로비저닝”이 보이면 CloudFormation을 떠올리세요. 질문에 “여러 계정과 Region에 걸쳐”가 추가되면, 해당 거버넌스 및 대규모 시나리오를 위해 설계된 CloudFormation 기능인 StackSets를 기억하세요.

문제 10

월 $8,000의 colocation 비용이 들던 25대 서버의 on-premises 환경을 폐기한 후, 한 미디어 스타트업이 AWS로 이전했다. 첫 달에 장기 약정 없이 Amazon EC2 compute hours 2,400시간을 사용하고 Amazon S3에 15 TB-month를 저장했으며, 재무팀은 청구서가 실제 사용량에 정비례해 변동한다고 확인했다. 이는 클라우드 컴퓨팅의 어떤 이점을 주로 보여주는가?

Practice Test #4

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(22)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

지금 학습 시작하기