
65개 문제와 90분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
미디어 스트리밍 스타트업은 단일 모니터링 마이크로서비스에서 생성되는 재생 오류 알림을 토픽 기반 publish/subscribe 패턴을 사용해 메시지를 팬아웃(fan out)하여, 최소한의 코드 변경으로 두 개의 AWS Regions 전반에 걸쳐 10,000개 이상의 엔드포인트(모바일 푸시, 이메일, SMS, HTTPS 웹훅)로 브로드캐스트해야 합니다. 이 publisher-and-subscriber 모델을 구현하기 위해 팀이 사용해야 하는 AWS 서비스는 무엇입니까?
AWS Lambda는 서버리스 compute 서비스이지 관리형 pub/sub 메시징 패브릭이 아닙니다. Lambda가 SNS의 subscriber가 될 수는 있지만(또는 외부 엔드포인트를 호출할 수도 있지만), Lambda를 주 메커니즘으로 사용해 10,000개 이상의 엔드포인트로 브로드캐스트하려면 subscriptions, 재시도, throttling, 프로토콜별 전달(SMS/이메일/푸시/웹훅)을 관리하는 커스텀 코드가 필요합니다. 이는 “최소한의 코드 변경” 및 “토픽 기반 pub/sub” 의도에 어긋납니다.
Amazon SNS는 토픽 기반 publish/subscribe 팬아웃을 위해 설계되었습니다. 단일 publisher가 SNS topic에 메시지를 보내면, SNS가 SMS, 이메일, 모바일 푸시 알림, HTTP/HTTPS 웹훅을 포함한 지원 프로토콜 전반에 걸쳐 많은 subscribers에게 전달합니다. SNS는 대규모 엔드포인트 수로 확장 가능하며, 애플리케이션 코드를 단순한 publish 호출로 줄여줍니다. cross-Region 요구사항은 Region별로 topic을 배포하고 필요에 따라 forwarding/dual-publishing을 구성하여 처리합니다.
Amazon CloudWatch는 관측 가능성(observability)에 초점을 둡니다: metrics, logs, alarms, events. CloudWatch alarms는 SNS를 통해 알림을 보낼 수 있지만, CloudWatch 자체는 토픽 subscriptions와 다중 프로토콜 엔드포인트 전달을 관리하는 pub/sub 서비스가 아닙니다. 이 시나리오에서는 마이크로서비스가 알림을 생성하고 publisher/subscriber 모델이 필요하므로, SNS가 올바른 메시징 계층이며 CloudWatch는 알림이 metrics/logs에서 파생되는 경우에만 선택적으로 사용됩니다.
AWS CloudFormation은 템플릿을 통해 AWS 리소스(예: SNS topics 및 subscriptions 포함)를 프로비저닝하고 관리하는 infrastructure-as-code 서비스입니다. 런타임 메시지 브로드캐스팅 또는 pub/sub 전달 메커니즘을 구현하지는 않습니다. CloudFormation은 두 개의 Regions에 걸쳐 SNS 기반 솔루션을 일관되게 배포하는 데는 도움이 될 수 있지만, publisher-and-subscriber 메시징 모델을 제공하는 서비스는 아닙니다.
핵심 개념: 이 문제는 토픽 기반 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를 사용합니다.
직원 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)에서 기술과 비즈니스 사이의 가교 역할을 하여 이러한 지속적 성장과 학습의 문화를 조성하는 관점은 무엇입니까?
People이 정답인 이유는 organizational change management(역할, 역량, 인력 구성, 인센티브, 문화)을 다루기 때문입니다. 시나리오의 핵심인 cross-functional guilds, upskilling, 지속적 학습은 People 관점에 직접적으로 포함됩니다. 또한 팀의 협업 방식과 개선 방식을 형성함으로써 기술 delivery 관행(예: deployment frequency 같은 DevOps metrics)을 비즈니스 성과와 연결하는 데 도움을 줍니다.
Governance는 의사결정 메커니즘, policies, risk management, compliance oversight, 그리고 guardrails와 controls를 통해 cloud 투자를 비즈니스 전략과 정렬하는 것에 초점을 둡니다. portfolio 수준에서 KPI 정렬에 영향을 줄 수는 있지만, 학습 문화 구축이나 upskilling을 위한 guilds 생성이 주된 목적은 아닙니다. 이러한 문화 및 역량 요소는 People 관점의 관심사에 더 가깝습니다.
Operations는 cloud 워크로드를 운영하고 지원하는 것(모니터링, incident 및 problem management, change management 프로세스, 신뢰성(reliability) 실천, operational readiness)에 관한 것입니다. Operations가 운영 피드백을 통해 지속적 개선을 지원할 수는 있지만, 인력 upskilling, 조직 구조, cross-functional guilds 구축을 위한 1차 CAF 관점은 아닙니다. 이 문제는 런타임 운영보다는 문화와 학습을 강조합니다.
Security는 보안 전략, identity and access management, 데이터 보호, 위협 탐지, compliance controls를 다룹니다. Security 팀이 cross-functional 모델(예: DevSecOps)에 참여할 수는 있지만, 이 문제의 핵심은 지속적 성장과 학습을 촉진하고 사람과 문화를 통해 비즈니스와 기술을 연결하는 것입니다. 이는 Security 관점의 주된 초점이 아닙니다.
핵심 개념: 이 문제는 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에 해당합니다.
스트리밍 미디어 스타트업이 단일 AWS Region 내 4개의 Availability Zone에 걸쳐 Amazon EC2 인스턴스에서 웹 애플리케이션을 실행하고 있다. 요청의 75%는 정적 이미지, CSS, JavaScript에 대한 것이며, 회사는 북미, 유럽, 아시아의 사용자로부터 분당 30,000건의 요청을 예상한다. 또한 다른 Region에 추가 애플리케이션 서버를 배포하지 않으면서 정적 자산의 전 세계 중앙값(median) 지연 시간을 60ms 미만으로 유지해야 한다. 이러한 요구 사항을 충족하기 위해 회사가 사용해야 하는 AWS 서비스는 무엇인가?
Amazon Route 53는 latency-based routing 또는 geolocation 같은 정책을 사용하여 사용자를 엔드포인트로 라우팅할 수 있는 고가용성 DNS 서비스이다. 그러나 Route 53는 엣지 로케이션에서 정적 파일을 캐시하고 제공하지 않는다. Route 53가 사용자를 “가장 가까운” Region으로 보낸다 하더라도, 회사는 multi-Region origin을 배포하지 않고 있으며, DNS 라우팅만으로는 정적 자산에 대해 전 세계 중앙값 60ms 미만을 달성할 수 없다.
Amazon CloudFront가 정답인 이유는 전 세계 엣지 로케이션 네트워크에서 정적 자산을 캐시하여 북미, 유럽, 아시아 사용자에 대한 지연 시간을 최소화하면서 origin을 단일 Region에 유지할 수 있기 때문이다. CloudFront는 origin 부하를 줄이고 높은 요청량에서 성능을 개선한다. cache policy, TTL, compression, Origin Shield 같은 기능은 엄격한 지연 시간 및 확장성 요구 사항을 충족하는 데 도움이 된다.
Elastic Load Balancing은 트래픽을 대상(EC2, 컨테이너, IP) 전반에 분산하며 여러 Availability Zone에 걸쳐 확장할 수 있어 Region 내 가용성과 확장성을 개선한다. 하지만 ELB는 전 세계 엣지 캐싱을 제공하거나 먼 지역으로의 전송을 가속하지 않는다. 유럽과 아시아의 사용자는 여전히 단일 Region에서 정적 자산을 가져와야 하므로, 중앙값 지연 시간 60ms 요구 사항을 초과할 가능성이 높다.
AWS Lambda는 서버리스 컴퓨팅 서비스이며 Lambda@Edge와 함께 CloudFront 엣지 로케이션에서 요청/응답을 사용자 지정하는 데 사용할 수 있다. 그러나 Lambda만으로는 콘텐츠 전송 솔루션이 아니며 정적 자산에 대한 캐싱이나 전 세계 가속을 본질적으로 제공하지 않는다. 여기서 필요한 1차 서비스는 CloudFront이며, Lambda@Edge는 고급 로직(헤더, 인증, 리라이트)을 위한 선택 사항이다.
핵심 개념: 이 문제는 여러 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 서비스이다.
한 미디어 스타트업은 사용자가 업로드한 사진 200 TB를 99.999999999% 내구성으로 저장해야 하며, HTTPS를 통해 REST로 객체 형태로 접근 가능해야 하고 객체 수준 메타데이터와 수명 주기 규칙을 통해 30일 후 데이터를 더 저렴한 infrequent-access 티어로 전환해야 합니다. 이러한 요구 사항을 가장 잘 충족하는 AWS 서비스는 무엇입니까?
Amazon S3는 네이티브 REST/HTTPS 접근, 객체 수준 메타데이터, 그리고 30일 후 더 저렴한 storage classes(예: S3 Standard-IA)로 데이터를 전환하는 lifecycle policies를 제공하는 객체 스토리지이므로 정답입니다. S3는 대규모(200 TB+)를 위해 설계되었고 여러 AZ에 걸쳐 데이터를 중복 저장하여 99.999999999% 내구성을 제공합니다. 문제의 모든 요구 사항과 직접적으로 일치합니다.
Amazon EFS는 여러 인스턴스에서 공유 POSIX 파일 접근이 필요한 Linux 워크로드를 위한 관리형 NFS 파일 시스템입니다. EFS는 큰 용량으로 확장할 수 있지만 객체 스토어가 아니며 S3 스타일의 REST 객체 접근, 객체 수준 메타데이터 시맨틱스, 또는 infrequent-access 객체 티어로의 S3 Lifecycle 전환을 제공하지 않습니다. EFS에는 자체 storage classes(Standard/IA)가 있지만 접근 모델은 객체 기반이 아니라 파일 기반입니다.
Amazon EBS는 단일 EC2 인스턴스(또는 제한적인 multi-attach 시나리오)에 연결되어 디스크 볼륨처럼 사용되도록 설계된 블록 스토리지입니다. 직접적인 HTTPS/REST 접근, 객체 수준 메타데이터, 또는 객체를 infrequent-access 티어로 전환하는 lifecycle rules를 제공하지 않습니다. EBS의 내구성/가용성 특성은 S3와 다르며, 대규모 인터넷 접근형 객체 저장소를 위한 용도가 아닙니다.
Amazon FSx는 특수한 파일 워크로드를 위한 관리형 파일 시스템(예: SMB를 통한 Windows File Server, Lustre, NetApp ONTAP, OpenZFS)을 제공합니다. EFS와 마찬가지로 객체 스토리지가 아니라 파일 스토리지이므로 REST/HTTPS 객체 접근, S3 object metadata, 또는 S3 Lifecycle 전환 요구 사항을 네이티브로 충족하지 않습니다. FSx는 객체 스토리지 내구성과 수명 주기 티어링이 아니라 파일 프로토콜 호환성과 성능 기능을 위해 선택됩니다.
핵심 개념: 이 문제는 객체 스토리지 요구 사항(매우 높은 내구성, REST/HTTPS 접근, 객체 수준 메타데이터, 더 낮은 비용의 infrequent access로의 수명 주기 티어링)에 기반해 올바른 AWS 스토리지 서비스를 선택하는지를 평가합니다. 정답이 맞는 이유: Amazon S3는 AWS의 목적에 맞게 설계된 객체 스토리지 서비스입니다. 버킷에 객체로서(200 TB 및 그 이상 포함) 어떤 양의 데이터든 저장하고 검색하도록 설계되었으며, HTTPS를 통한 REST APIs로 네이티브 접근이 가능합니다. S3는 Region 내 여러 디바이스와 여러 Availability Zones에 걸쳐 데이터를 중복 저장함으로써 객체에 대해 99.999999999%(11 9s) 내구성을 제공합니다. “객체 수준 메타데이터를 가진 객체” 요구 사항은 S3 object metadata(시스템 정의 및 사용자 정의)와 tagging에 정확히 대응됩니다. 주요 AWS 기능: S3 Lifecycle rules는 객체의 경과 시간(예: 30일 후)에 따라 storage class 간 자동 전환을 수행할 수 있습니다. 일반적인 패턴은 최근 업로드는 S3 Standard에 두고, 이후 복원력 요구에 따라 S3 Standard-IA(infrequent access) 또는 S3 One Zone-IA로 전환하며, 선택적으로 이후 S3 Glacier Instant Retrieval/Flexible Retrieval/Deep Archive로 아카이빙하는 것입니다. Lifecycle은 또한 객체 만료, (versioning이 활성화된 경우) noncurrent versions 관리, object tags를 사용한 서로 다른 정책 적용을 지원합니다. S3는 encryption(SSE-S3, SSE-KMS), bucket policies, IAM, access logging도 지원하며, 이는 안전한 HTTPS 접근 패턴에 중요합니다. 흔한 오해: EFS와 FSx는 객체 스토어가 아니라 파일 시스템(POSIX/SMB/NFS 시맨틱스)이며, S3 스타일의 object metadata, REST object APIs, 또는 IA 티어로의 S3 Lifecycle 전환을 제공하지 않습니다. EBS는 EC2에 연결되는 블록 스토리지로, 직접적인 HTTPS/REST 객체 접근이나 대규모 공유 객체 저장소에 적합하지 않습니다. 시험 팁: “REST/HTTPS objects”, “object metadata”, “lifecycle transition”, “11 9s durability”를 보면 즉시 Amazon S3를 떠올리세요. 파일 스토리지 키워드(NFS/SMB/POSIX)는 EFS/FSx를, 블록 스토리지 키워드(volumes, EC2에 attached, low-latency)는 EBS를 가리킵니다.
한 차량 공유 startup이 평일에 트래픽 급증을 겪고 있으며, 동시 요청이 10분 내에 800에서 4,500으로 증가했다가 자정 이후에는 다시 600 미만으로 떨어집니다. 또한 인스턴스 전반의 평균 CPU utilization이 5분 동안 70%를 초과하면 cloud가 자동으로 compute capacity를 추가하고, 10분 동안 30% 미만으로 떨어지면 해당 capacity를 제거하여 사용한 만큼만 비용을 지불하고자 합니다. 이 목표를 가장 잘 나타내는 AWS 개념은 무엇입니까?
확장성(Scalability)은 리소스를 추가(수직 또는 수평)하여 애플리케이션이 증가한 부하를 처리할 수 있는 능력이며, 종종 장기적 성장이나 더 높은 throughput을 지원하도록 시스템을 설계하는 맥락에서 논의됩니다. 이 시나리오도 스파이크를 처리하지만, 핵심 요구사항은 CPU 임계값과 시간 구간에 기반한 자동 scale out 및 scale in입니다. 이러한 동적이고 양방향의 동작은 scalability보다 elasticity가 더 정확합니다.
지속 가능성(Sustainability)은 AWS Well-Architected Framework pillar로, 환경 영향을 최소화하고 에너지 효율을 개선하며 시간에 따라 리소스 utilization을 최적화하는 데 초점을 둡니다. 사용하지 않는 capacity를 줄이는 것이 간접적으로 sustainability 목표에 도움이 될 수는 있지만, 이 문제의 본질은 수요와 비용에 맞춰 compute capacity를 자동으로 조정하는 것입니다. 따라서 테스트하는 1차 개념은 sustainability가 아니라 elasticity입니다.
탄력성(Elasticity)은 현재 수요에 맞춰 리소스를 자동으로 provisioning 및 deprovisioning하는 능력으로, 급증 시에는 scale out하고 사용량이 낮을 때는 scale in하여 비용을 최적화합니다. 이 문제는 정의된 기간 동안의 CPU 기반 임계값(예: 5분 동안 >70%, 10분 동안 <30%)과 사용한 만큼만 비용을 지불하려는 요구를 명시적으로 설명합니다. 이는 CloudWatch metrics에 의해 구동되는 EC2 Auto Scaling policies와 직접적으로 일치합니다.
운영 우수성(Operational excellence)은 운영 프로세스, 자동화, 모니터링, 지속적 개선을 강조하는 Well-Architected pillar입니다. Auto Scaling은 operational excellence의 일부가 될 수 있지만, 이 시나리오의 핵심 목표는 운영 프로세스나 거버넌스가 아니라 수요에 맞춰 capacity를 동적으로 맞추고 비용 효율을 달성하는 것입니다. 따라서 operational excellence는 관련은 있으나 가장 적절한 표현은 아닙니다.
핵심 개념: 이 문제는 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를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
SOC 2 Type II 감사를 진행 중인 한 fintech 회사는 3개의 AWS Region에 걸쳐 있는 200개의 Amazon EC2 인스턴스와 60개의 Amazon RDS DB 인스턴스에 대해 리소스 구성 변경 사항을 최소 90일 동안 자동으로 기록하고 보관해야 하며, 외부 감사인이 검토할 수 있도록 정기적인 구성 및 규정 준수 보고서를 내보내야 합니다. 이러한 요구 사항을 충족하기 위해 회사는 어떤 AWS 서비스를 사용해야 합니까?
Amazon Cognito는 인증, 인가, 사용자 관리(user pools, identity pools, federation)를 위한 identity 서비스입니다. AWS 리소스 구성 변경을 기록하거나, 구성 이력을 유지하거나, EC2/RDS에 대한 규정 준수 보고서를 생성하지 않습니다. Cognito는 애플리케이션의 보안 아키텍처 일부가 될 수는 있지만, 인프라 구성 드리프트 또는 규정 준수 모니터링을 위한 감사 증적 시스템은 아닙니다.
Amazon FSx는 관리형 파일 시스템(예: FSx for Windows File Server, Lustre, NetApp ONTAP, OpenZFS)을 제공합니다. 파일을 저장할 수는 있지만, AWS 리소스 구성 변경을 기본적으로 추적하거나 규정 준수를 평가하지는 않습니다. FSx를 저장 대상으로 사용하더라도 구성 이력과 규정 준수 데이터를 생성하려면 다른 서비스가 필요하며, 그 증적을 생성하는 서비스는 AWS Config입니다.
AWS Config는 AWS resource configuration 변경 사항을 기록하고, configuration history를 유지하며, AWS Config Rules를 통해 compliance를 평가하도록 특별히 설계되었습니다. 문제에 나온 resource types, 즉 Amazon EC2 instances와 Amazon RDS DB instances를 지원하며, 여러 Region에서 동작하고 aggregators를 통해 중앙 집중식 visibility를 제공합니다. 90일 audit 요구 사항에 대해 AWS Config는 configuration history, snapshots, 그리고 compliance 데이터를 Amazon S3로 전달할 수 있으며, 회사는 해당 기록을 필요한 기간 동안 보관하고 external auditors가 사용할 수 있도록 제공할 수 있습니다. 따라서 SOC 2 Type II audit 동안 자동화된 증빙 수집과 정기적인 compliance reporting에 가장 적합한 선택입니다.
Amazon Inspector는 워크로드(예: EC2, container images, Lambda)를 스캔하여 소프트웨어 취약점과 의도치 않은 네트워크 노출을 찾는 vulnerability management 서비스입니다. 보안 상태 측면에서 유용하지만, Region 전반의 리소스 구성 드리프트에 대한 권위 있는 구성 타임라인, 구성 스냅샷, 또는 규정 준수 보고를 제공하지는 않습니다. 구성 변경과 규정 준수 상태에 대한 SOC 2 증적에는 AWS Config가 올바른 서비스입니다.
핵심 개념: 이 문제는 여러 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 증빙 수집에서 흔한 패턴입니다.
한 미디어 스트리밍 회사는 Amazon S3에서 매일 밤 배치 로드되는 20 TB의 과거 클릭스트림 데이터에 대해 복잡한 분석용 SQL 쿼리를 실행해야 하며, 컬럼형 스토리지, 대규모 병렬 처리, 최대 30명의 동시 분석가를 위한 BI 도구와의 통합이 필요합니다. 이 사용 사례에 대해 페타바이트 규모의 데이터 웨어하우스를 가장 잘 제공하는 AWS 서비스는 무엇입니까?
Amazon RDS는 MySQL, PostgreSQL, SQL Server 같은 엔진을 사용해 주로 OLTP 워크로드(예: 애플리케이션 백엔드)를 대상으로 하는 관리형 관계형 데이터베이스 서비스입니다. SQL 쿼리를 실행할 수는 있지만, 페타바이트 규모 분석, 컬럼형 스토리지 또는 MPP 실행에 최적화되어 있지 않습니다. 많은 동시 분석가와 BI 리포팅이 필요한 20 TB 클릭스트림 분석에서는 목적별 웨어하우스에 비해 RDS가 비용 효율이 떨어지고 성능 한계에 부딪히는 경우가 많습니다.
Amazon DynamoDB는 대규모에서 저지연 key-value 및 document 접근 패턴에 최적화된 완전 관리형 NoSQL 데이터베이스입니다. 복잡한 조인, 대규모 집계, 컬럼형 스토리지를 갖춘 전통적인 분석 SQL 데이터 웨어하우스 경험을 제공하지 않습니다. DynamoDB에는 PartiQL이 있고 일부 쿼리 패턴을 지원할 수는 있지만, 20 TB의 과거 클릭스트림 데이터에 대한 MPP 분석이나 표준 BI 웨어하우스 워크로드를 위해 설계된 것은 아닙니다.
Amazon Redshift는 복잡한 분석 SQL을 위해 구축된 AWS의 관리형, 페타바이트 규모 클라우드 데이터 웨어하우스입니다. 컬럼형 스토리지와 MPP를 사용해 노드 전반에 걸쳐 쿼리를 병렬화하고, 효율적인 압축을 지원하며, 배치 로드(COPY) 및 데이터 레이크 쿼리(Redshift Spectrum)를 위해 Amazon S3와 긴밀하게 통합됩니다. 또한 JDBC/ODBC를 통해 BI 도구를 지원하고, Concurrency Scaling 또는 Redshift Serverless 같은 기능으로 많은 동시 분석가를 처리할 수 있습니다.
Amazon Aurora는 MySQL/PostgreSQL 호환의 고성능 관리형 관계형 데이터베이스로, OLTP 및 고가용성에 최적화되어 있습니다. Aurora는 읽기 확장과 일부 리포팅을 지원할 수 있지만, 컬럼형 MPP 데이터 웨어하우스가 아니며 매일 밤 S3 배치 로드와 무거운 집계 쿼리가 있는 대규모 클릭스트림 분석에 가장 적합한 선택은 아닙니다. 이 규모의 웨어하우스형 BI 분석에는 Redshift가 의도된 서비스입니다.
핵심 개념: 이 문제는 복잡한 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가 정석 답입니다.
한 미디어 분석 회사가 온프레미스 모놀리식 리포팅 애플리케이션을 AWS로 마이그레이션하고, 이를 약 12개의 도메인 정렬 마이크로서비스로 분해하며, 워크로드를 컨테이너화하여 2개의 Availability Zone에 걸쳐 Amazon EKS에 배포하려고 합니다. 또한 독립적인 CI/CD 파이프라인과 오토스케일링을 적용하려고 하며, 팀은 이벤트 기반 패턴과 관리형 클라우드 네이티브 기능을 채택하기 위해 코드의 약 30%를 재작성할 의향이 있습니다. 이 목표에 가장 부합하는 마이그레이션 전략은 무엇입니까?
Rehost(“lift and shift”)는 애플리케이션을 거의 그대로 AWS(예: EC2)로 옮기며 코드 변경이 최소 또는 전혀 없습니다. 이는 속도와 낮은 위험을 위해 선택되며, 대규모 아키텍처 현대화를 위한 것이 아닙니다. 모놀리스를 마이크로서비스로 분해하고, 이벤트 기반 패턴을 구현하며, 독립적인 CI/CD 파이프라인을 구축하는 것은 rehosting을 훨씬 넘어서는 범위이므로 이 옵션은 제시된 목표와 부합하지 않습니다.
Repurchase는 기존 애플리케이션을 다른 제품(일반적으로 SaaS 솔루션)으로 교체하는 것을 의미합니다(예: 커스텀 CRM에서 Salesforce로 이동). 이 전략은 운영 부담을 줄이지만, 새로운 제품의 기능과 제약을 수용해야 합니다. 문제는 기존 애플리케이션을 EKS에서 마이크로서비스로 컨테이너화하고 분해하는 것을 설명하고 있으며, 상용 off-the-shelf 또는 SaaS 리포팅 플랫폼으로 교체하는 것이 아닙니다.
Replatform(“lift, tinker, and shift”)는 핵심 아키텍처를 변경하지 않으면서 클라우드 서비스를 활용하기 위해 몇 가지 최적화를 수행하는 것입니다. 예를 들어 모놀리스를 컨테이너로 옮기거나 최소한의 코드 변경으로 데이터베이스를 관리형 서비스로 전환하는 경우입니다. EKS와 오토스케일링은 replatforming에 해당할 수 있지만, 명시적인 마이크로서비스 분해와 이벤트 기반 재설계는 일반적으로 replatforming이 의미하는 수준보다 더 깊은 re-architecture를 나타냅니다.
Refactor (re-architect)는 조직이 cloud-native 패턴과 managed services를 활용하기 위해 애플리케이션 아키텍처를 의도적으로 변경할 때 가장 적합한 마이그레이션 전략입니다. 이 시나리오에서 회사는 monolith를 단순히 containers로 옮기려는 것이 아니라, 애플리케이션을 도메인에 정렬된 약 12개의 microservices로 분해할 계획이며, 이는 서비스 경계, deployment units, 운영 소유권에 대한 상당한 재설계를 의미합니다. event-driven 패턴을 지원하기 위해 코드의 약 30%를 다시 작성할 의향이 있다는 점도 Refactor의 강력한 지표입니다. 왜냐하면 그 정도 수준의 코드 및 communication model 변경은 단순한 플랫폼 최적화를 넘어가기 때문입니다. 또한 두 개의 Availability Zones에 걸쳐 Amazon EKS에서 서비스를 실행하고, 독립적인 CI/CD pipelines와 autoscaling을 사용하는 점은 최소한의 변경만 가한 마이그레이션이 아니라 현대화된 microservices 아키텍처를 더욱 뒷받침합니다. AWS 시험에서는 microservices, event-driven, managed cloud-native capabilities, 그리고 의미 있는 코드 변경과 같은 키워드가 나오면 Refactor를 강하게 시사합니다.
핵심 개념: 이 문제는 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입니다.
한 전자상거래 스타트업이 4개의 AWS 계정을 운영하고 있으며, 버전 관리되는 YAML 템플릿을 사용해 변경 세트와 자동 롤백을 포함하여 2개 Region에 걸쳐 동일한 VPC, IAM 역할, Amazon RDS 인스턴스를 반복적으로 프로비저닝해야 합니다. Infrastructure as code를 구현하기 위해 어떤 AWS 서비스를 사용해야 합니까?
AWS CodeDeploy는 애플리케이션 배포(예: EC2, on-premises, Lambda, ECS)를 자동화하며 롤링 업데이트, 트래픽 시프팅, 배포 훅에 초점을 둡니다. YAML 템플릿으로 VPC, IAM 역할, RDS 같은 기반 인프라를 정의하거나 프로비저닝하지 않으며, 인프라 업데이트를 위한 CloudFormation 스타일의 change sets도 제공하지 않습니다. CodeDeploy는 코드용 CI/CD이지, AWS 리소스를 위한 주요 IaC 서비스가 아닙니다.
AWS Elastic Beanstalk는 웹 앱을 배포하고 환경 구성에 따라 지원 리소스(예: EC2, ALB, Auto Scaling)를 생성하는 관리형 애플리케이션 플랫폼입니다. 인프라를 생성할 수는 있지만 애플리케이션 환경 중심으로 의견이 반영된(opinionated) 서비스이며, CloudFormation처럼 명시적인 change sets와 rollback 의미 체계를 갖추고 커스텀 VPC 아키텍처, IAM 역할, RDS 같은 임의의 리소스를 반복 가능하고 버전 관리 방식으로 프로비저닝하는 용도로 설계되지 않았습니다.
Amazon API Gateway는 API(REST, HTTP, WebSocket)를 생성, 게시, 보안 설정하기 위한 서비스입니다. 인프라 프로비저닝 도구가 아니며 YAML 템플릿, change sets, rollback을 통해 다중 리소스 배포를 관리하지 않습니다. API Gateway는 (CloudFormation을 포함한) IaC 도구로 정의될 수는 있지만, API Gateway 자체가 계정과 Region 전반에서 infrastructure as code를 구현하는 데 사용하는 서비스는 아닙니다.
AWS CloudFormation은 AWS의 네이티브 Infrastructure as Code 서비스입니다. 버전 관리에 저장된 YAML/JSON 템플릿을 사용하여 AWS 리소스를 일관되게 프로비저닝하고 업데이트합니다. CloudFormation은 실행 전에 업데이트를 미리 확인할 수 있도록 Change Sets를 지원하며, 실패 시 자동 롤백을 제공합니다. 여러 AWS 계정과 Region에 걸친 반복 배포의 경우, CloudFormation StackSets(종종 AWS Organizations와 통합됨)를 통해 중앙에서 일관된 프로비저닝을 대규모로 수행할 수 있습니다.
핵심 개념: 이 문제는 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를 기억하세요.
월 $8,000의 colocation 비용이 들던 25대 서버의 on-premises 환경을 폐기한 후, 한 미디어 스타트업이 AWS로 이전했다. 첫 달에 장기 약정 없이 Amazon EC2 compute hours 2,400시간을 사용하고 Amazon S3에 15 TB-month를 저장했으며, 재무팀은 청구서가 실제 사용량에 정비례해 변동한다고 확인했다. 이는 클라우드 컴퓨팅의 어떤 이점을 주로 보여주는가?
“데이터 센터를 운영하고 유지보수하는 데 돈을 쓰는 것을 중단”은 시설(전력, 냉각, 물리적 보안, 하드웨어 교체, 랙 설치/배치)을 소유/운영하는 운영 부담과 비용을 제거하는 것을 의미한다. 회사가 colocation 구성을 폐기하긴 했지만, 이 문제의 주된 강조점은 EC2 hours와 S3 TB-month에 따라 요금이 실제 사용량에 정비례해 변동했다는 점이다. 이는 단순히 데이터 센터 운영을 피하는 것보다, 사용량 기반 변동 비용에 더 구체적으로 해당한다.
“속도와 민첩성을 높인다”는 리소스를 신속히 프로비저닝(수주가 아닌 수분), 빠르게 실험하고, EC2, Auto Scaling, 관리형 서비스 등을 통해 출시 시간을 단축하는 것을 말한다. 이 시나리오는 더 빠른 프로비저닝, 배포 속도, 반복적 실험을 언급하지 않는다. 대신 소비량을 추적하는 과금을 강조하므로, 민첩성 이점이 아니라 비용 모델 이점이다.
“몇 분 만에 글로벌로 확장”은 여러 AWS Regions 및 edge locations에 워크로드를 빠르게 배포해 전 세계 사용자에게 낮은 지연과 복원력을 제공하는 것을 의미한다. 프롬프트에는 Regions, 글로벌 확장, 국제 사용자 도달에 대한 언급이 없다. 제시된 지표(compute hours 및 S3 TB-month)와 재무팀의 관찰은 글로벌 인프라 범위가 아니라 계량 과금에 관한 것이다.
“고정 비용을 변동 비용으로 전환”이 직접적으로 드러난다. 이전의 월 $8,000 colocation 비용은 대체로 고정적인 월 비용인 반면, AWS 요금은 계량 과금(EC2 compute hours 및 S3 TB-month)이며 실제 사용량에 따라 규모가 변한다. 문제는 청구서가 사용량에 정비례해 변동했고 장기 약정이 없었다고 명시하는데, 이는 pay-as-you-go 변동 지출을 가장 명확히 나타내는 지표다.
핵심 개념: 이 문제는 AWS Cloud Concepts의 기본적인 클라우드 경제성 원리, 즉 고정적 선투자 비용에서 사용량 기반 요금제(pay-as-you-go)로 전환하는 것을 평가한다. 시나리오는 계량 과금(EC2 compute hours 및 S3 TB-month)을 언급하고, 청구서가 실제 사용량에 정비례해 변동한다고 명시한다. 정답인 이유: 이전에는 25대 서버 환경에 대해 월 $8,000의 colocation 비용을 지불했는데, 이는 사용률과 무관하게 지불해야 하는 대체로 고정 비용이다. AWS로 이전한 뒤 “장기 약정 없음” 상태에서 EC2 2,400시간과 S3 15 TB-month를 소비했고, 재무팀은 비용이 실제 사용량을 따라간다고 관찰했다. 이는 “고정 비용을 변동 비용으로 전환”의 전형적인 특징으로, 수요에 따라 비용이 증가/감소하며 일정한 월 시설/서버 비용에 묶이지 않는다. 주요 AWS 기능: Amazon EC2는 인스턴스 사용량(구매 모델과 OS에 따라 초/분 단위)에 기반해 과금되며, 약정 없이 On-Demand로 실행할 수 있다. Amazon S3 스토리지는 GB-month(요청 및 데이터 전송 추가) 기준으로 과금되므로, 한 달 동안 15 TB를 저장하는 것은 측정 가능한 단위에 직접 대응한다. AWS는 Savings Plans/Reserved Instances 같은 약정 기반 할인도 제공하지만, 문제에서 약정이 없다고 명시해 순수한 변동 지출임을 강화한다. 흔한 오해: 선택지 A(데이터 센터 운영 및 유지보수 비용 지출 중단)도 실제 클라우드 이점이며, on-prem 환경을 폐기했다는 언급 때문에 그쪽으로 유도될 수 있다. 그러나 핵심 단서는 재무팀이 청구서가 사용량에 정비례한다고 관찰했다는 점으로, 이는 운영 책임이 아니라 비용 구조(고정 vs 변동)에 관한 것이다. 선택지 B와 C는 과금 방식과 관련이 없다. 시험 팁: “사용한 만큼만 지불,” “시간당 과금,” “GB-month,” “선결제 없음,” “장기 약정 없음,” “사용량에 따라 비용이 확장” 같은 표현이 보이면, 대개 변동 비용이 정답이다. 시설, 전력, 냉각, 랙 설치, 하드웨어 수명주기 제거가 초점이면 “데이터 센터를 운영하고 유지보수하는 데 돈을 쓰는 것을 중단”에 해당한다.
학습 기간: 2 months
기초만 따로 공부하고 무한으로 문제 돌렸습니다. 믿을만한 앱임
학습 기간: 2 months
I have very similar questions on my exam, and some of them were nearly identical to the original questions.
학습 기간: 2 months
다음에 또 이용할게요
학습 기간: 2 months
Would vouch for this practice questions!!!
학습 기간: 1 month
도메인별 문제들이 잘 구성되어 있어서 좋았고, 강의만 듣고 시험보기엔 불안했는데 잘 이용했네요
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.