
65개 문제와 90분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
직원 240명의 리테일 분석 회사가 6개월 내에 120개의 온프레미스 워크로드를 AWS로 마이그레이션할 계획이며, CIO는 거버넌스 또는 보안 프로세스를 변경하지 않으면서 3개의 제품 라인 전반에서 리더십 목표를 재정렬하고 15%의 클라우드 역량 격차를 해결하기 위해 팀 구조를 재설계하려면 어떤 AWS Cloud Adoption Framework (AWS CAF) People 관점 역량을 우선순위로 두어야 하는지 질문합니다(두 개 선택).
Organizational alignment는 People 관점 역량으로, 비즈니스 유닛 또는 제품 라인 전반에서 리더십 목표, 인센티브, 우선순위를 정렬하는 데 초점을 둡니다. 문제는 “3개의 제품 라인 전반에서 리더십 목표를 재정렬”해야 한다고 명시하고 있어 직접적으로 일치합니다. 이 역량은 거버넌스 또는 보안 프로세스를 변경하지 않고도 마이그레이션에 대해 일관된 후원, 의사결정, 공동의 성과를 보장하는 데 도움이 됩니다.
Portfolio management는 AWS CAF에서 주로 Business 관점과 연관되며, 이니셔티브 우선순위 지정, 투자 관리, 애플리케이션 포트폴리오 전반의 가치 추적을 다룹니다. 6개월 내 120개 워크로드는 포트폴리오 계획을 떠올리게 하지만, 문제는 People 관점 역량을 구체적으로 묻고 있으며 자금/가치 관리보다는 리더십 정렬과 팀 재설계를 강조합니다.
Organization design는 People 관점 역량으로, 팀 구조, 역할과 책임, 운영 모델 변화, 인력 계획을 다룹니다. “팀 구조를 재설계”하고 “15%의 클라우드 역량 격차”를 해결해야 한다는 요구사항이 여기에 직접 매핑됩니다. 이는 거버넌스/보안 프로세스를 변경하지 않으면서도 클라우드 지원 팀/CCoE 같은 기능을 만들거나 발전시키고 새로운 클라우드 역할을 정의하는 것을 지원합니다.
Risk management는 통제와 프로세스를 통해 리스크를 식별, 평가, 완화하는 Governance(그리고 종종 Security) 영역과 더 밀접합니다. 문제는 거버넌스 또는 보안 프로세스를 변경하지 말라고 명시하므로 적합하지 않습니다. 마이그레이션 리스크는 존재하지만, 이 문제는 리스크 통제 프레임워크가 아니라 사람 역량(정렬과 조직 구조)에 관한 것입니다.
Modern application development는 일반적으로 Platform 관점 역량으로, 엔지니어링 관행과 도구(예: CI/CD, 마이크로서비스, 컨테이너, 서버리스 패턴)에 초점을 둡니다. 장기적인 클라우드 성공에는 도움이 될 수 있지만, 리더십 목표 정렬이나 역량 격차를 해소하기 위한 조직 재구성에는 직접적으로 해당하지 않습니다. 문제는 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 역량은 피하세요.
실시간 스포츠 하이라이트 플랫폼은 120 MB 이미지와 8분짜리 비디오 클립을 50개국 이상의 시청자에게 시작 지연 시간을 100 ms 미만으로 제공해야 합니다. 사용자와 가까운 위치에 이 콘텐츠를 캐시하기 위해 전 세계 엣지 로케이션 네트워크를 사용하는 AWS 서비스는 무엇입니까?
Amazon Kinesis는 실시간 스트리밍 데이터 수집 및 처리(예: 클릭스트림, 텔레메트리, 라이브 이벤트 데이터 파이프라인)에 사용됩니다. 실시간 분석과 이벤트 기반 아키텍처를 구축하는 데 도움이 되지만, CDN이 아니며 엣지 로케이션에서 대용량 미디어 파일을 캐시하거나 시청자에게 제공하지 않습니다. Kinesis는 100 ms 미만 시작 지연 시간으로 이미지와 비디오를 전달하는 것이 아니라 스포츠 이벤트 메타데이터를 처리하는 데 더 관련이 있습니다.
Amazon SQS는 프로듀서와 컨슈머를 디커플링하고, 워크로드를 버퍼링하며, 분산 시스템의 신뢰성을 높이는 완전관리형 메시지 큐입니다. 최종 사용자에게 콘텐츠를 전달하도록 설계되지 않았고, 엣지 캐싱이나 전 세계 미디어 배포 기능을 제공하지 않습니다. SQS는 백엔드에서 비디오 처리 작업 조정이나 알림에 사용될 수는 있지만, 전 세계 시청자 가까이에서 미디어를 캐시하고 제공해야 하는 요구 사항을 충족할 수 없습니다.
Amazon CloudFront는 전 세계 엣지 로케이션 네트워크를 사용해 콘텐츠를 캐시하고 저지연으로 전달하는 AWS의 CDN입니다. 여러 국가의 사용자에게 대용량 이미지와 비디오를 포함한 정적/동적 콘텐츠를 배포하도록 목적에 맞게 설계되었습니다. CloudFront는 가장 가까운 엣지에서 콘텐츠를 제공하여 시작 지연 시간을 줄이고, S3/ALB/MediaPackage 오리진을 지원하며, 전 세계 미디어 전송을 위한 캐시 제어, 보안 기능, 성능 최적화를 제공합니다.
Amazon Route 53는 지연 시간 기반 라우팅, 지리 위치, 헬스 체크와 같은 정책을 사용해 사용자를 엔드포인트로 라우팅할 수 있는 고가용성 DNS 서비스입니다. 최적의 엔드포인트로 사용자를 안내하고 DNS 조회 시간을 줄이는 데는 도움이 되지만, 엣지 로케이션에서 실제 미디어 콘텐츠를 캐시하거나 전달하지는 않습니다. Route 53는 CloudFront와 함께 자주 사용되지만, 전 세계 캐싱과 저지연 전송을 위한 CDN을 대체할 수는 없습니다.
핵심 개념: 이 문제는 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와 조합합니다.
12개월의 runway를 가진 한 fintech startup이 5년에 걸쳐 감가상각되는 $180,000의 on-premises hardware를 구매하는 것과, 하루에 20~120 vCPUs로 예상 수요가 변동하고 storage가 매달 2 TB씩 증가하는 AWS를 사용하는 것 사이에서 선택하고 있습니다. 이 시나리오에서 AWS 사용의 cost-effectiveness를 가장 잘 설명하는 두 가지 진술은 무엇입니까? (두 개 선택)
정답. AWS는 큰 upfront capital expenditures(servers 및 storage 구매)를 pay-as-you-go operational expenses로 대체합니다. 이 시나리오에서는 compute 수요가 크게 변동(하루 20–120 vCPUs)하므로, 사용한 만큼만 지불하면 overprovisioning과 stranded capacity를 피할 수 있습니다. 12개월 runway만 있는 상황에서 upfront cash outlay를 줄이고 지출을 실제 usage에 맞추는 것은 cost-effectiveness의 주요 이점입니다.
cost-effectiveness 관점에서는 오답. 여러 Regions에서 빠르게 launch할 수 있는 능력은 agility 및 resiliency 기능이지, 주로 cost 이점은 아닙니다. multi-Region architectures는 리소스 중복, data transfer, operational complexity로 인해 오히려 cost가 증가할 수 있습니다. 배포 속도는 가치가 있지만, 질문은 on-prem hardware economics 대비 cost-effectiveness를 구체적으로 묻고 있습니다.
cost-effectiveness 관점에서는 오답. 더 빠른 실험과 agility는 핵심 cloud 이점이지만, 여기서 가장 cost 중심의 진술은 아닙니다. 이 시나리오의 가장 강한 cost drivers는 variable compute demand와 제한된 runway이며, 이는 variable pricing(OpEx)과 overprovisioning 회피에 더 직접적으로 대응합니다. agility는 간접적으로 cost를 줄일 수 있지만, 이 문제에서의 주요 경제적 비교는 아닙니다.
cost-effectiveness 관점에서는 오답. AWS가 모든 infrastructure에 대해 보편적으로 “patching을 처리”하는 것은 아닙니다. patching 책임은 서비스에 따라 달라집니다(예: managed services의 underlying hosts는 AWS가 patching하지만, EC2 guest OS는 고객이 patching). 이는 직접적인 cost-effectiveness보다는 operational responsibility와 security posture에 관한 내용입니다. 또한 CapEx vs pay-as-you-go라는 핵심 재무 비교를 다루지 않습니다.
정답. AWS의 economies of scale은 일반적으로 작은 startup이 자체 hardware(컴퓨팅, storage, networking, facilities, procurement)를 구매하고 운영하는 것보다 더 낮은 per-unit costs를 제공합니다. 이는 storage가 매달 2 TB씩 증가하고 compute가 scale up/down하는 상황에서 중요합니다. right-sizing 및 pricing options(Savings Plans/Spot)과 결합하면 AWS는 unit costs와 total cost of ownership를 줄일 수 있습니다.
핵심 개념: 이 문제는 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” 이점을 구분하십시오.
분기별 감사를 진행 중인 의료 분석 회사는 지원 케이스를 열거나 어떤 에이전트도 배포하지 않고, 다음 10분 이내에 기본 클라우드 인프라에 대한 공식 AWS SOC 2 Type II 및 ISO 27001 컴플라이언스 보고서를 다운로드해야 합니다. 이러한 보안 및 컴플라이언스 문서에 대해 온디맨드(Self-service) 방식의 셀프서비스 액세스를 제공하는 AWS 서비스는 무엇입니까?
Amazon GuardDuty는 로그(예: VPC Flow Logs, DNS logs, CloudTrail)를 분석하여 의심스러운 활동과 잠재적 침해를 식별하는 관리형 위협 탐지 서비스입니다. 이는 보안 운영 및 인시던트 대응에 도움이 되지만, SOC 2 Type II 또는 ISO 27001과 같은 공식 AWS 컴플라이언스 감사 보고서를 조회/다운로드하는 용도가 아닙니다. GuardDuty findings는 보안 상태를 뒷받침할 수는 있지만, 감사자가 발행한 컴플라이언스 문서는 아닙니다.
AWS Security Hub는 AWS 서비스 및 파트너 도구의 보안 findings를 집계, 정규화, 우선순위화하며, 보안 표준 점검(예: CIS AWS Foundations Benchmark, PCI DSS)을 실행할 수 있습니다. 지속적 컴플라이언스 모니터링을 지원하긴 하지만, AWS 인프라에 대한 다운로드 가능한 공식 AWS SOC/ISO 컴플라이언스 보고서를 제공하지는 않습니다. 이는 AWS의 제3자 감사 산출물이 아니라 계정의 보안 상태에 관한 것입니다.
AWS Artifact는 SOC 2 Type II 보고서와 ISO 27001 인증을 포함한 AWS 보안 및 컴플라이언스 문서에 대해 온디맨드, 셀프서비스 액세스를 제공하므로 정답입니다. 이는 감사 및 컴플라이언스 요구를 위해 설계되었으며, 고객이 지원 케이스를 열거나 에이전트를 배포하지 않고도 공식 보고서를 신속하게 다운로드할 수 있게 합니다. 이는 시간에 민감한 분기별 감사 요구사항과 정확히 일치합니다.
AWS Shield는 관리형 DDoS 보호 서비스(Standard 및 Advanced)로, AWS에서 실행되는 애플리케이션을 분산 서비스 거부 공격으로부터 보호합니다. 가용성과 공격 완화에 초점을 두며 컴플라이언스 보고에는 초점을 두지 않습니다. Shield는 SOC 2 Type II 또는 ISO 27001 문서를 제공하지 않으며, 이러한 문서는 AWS Artifact를 통해 획득합니다.
핵심 개념: 이 문제는 고객이 AWS의 기본 cloud infrastructure에 대한 SOC 보고서 및 ISO 인증서와 같은 공식 AWS compliance 문서를 어디에서 얻는지에 대한 지식을 평가합니다. 정답 서비스는 AWS Artifact이며, 이는 보안 및 compliance 보고서와 특정 계약을 위한 AWS의 self-service portal입니다. 정답인 이유: AWS Artifact를 사용하면 고객은 support case를 열지 않고도 SOC 2 Type II 보고서 및 ISO 27001 인증서와 같은 AWS 발행 audit artifact를 즉시 다운로드할 수 있습니다. 시나리오는 10분 이내의 긴급한 접근과 agent 배포가 없음을 강조하며, 이는 on-demand document repository로서의 Artifact의 목적과 정확히 일치합니다. 주요 기능: 1. Artifact Reports: SOC, ISO, PCI 및 기타 audit 문서를 포함한 다운로드 가능한 compliance 보고서와 인증서를 제공합니다. 2. Artifact Agreements: 해당되는 경우 Business Associate Addendum와 같은 특정 compliance 관련 계약을 고객이 검토, 수락 및 관리할 수 있게 합니다. 3. Self-service access: IAM 기반 access control과 함께 AWS Management Console을 통해 직접 사용할 수 있어 audit 및 governance workflow에 적합합니다. 4. 공식 AWS 문서: AWS infrastructure control을 검증할 때 auditor가 기대하는 공식 보고서를 제공합니다. 일반적인 오해: GuardDuty와 Security Hub는 보안 서비스이지만, AWS의 third-party audit 보고서를 제공하는 것이 아니라 고객 환경 내에서 findings, threat detection 및 posture management에 중점을 둡니다. AWS Shield는 DDoS 공격으로부터 보호하며 compliance 문서를 다운로드하는 것과는 관련이 없습니다. 시험에서 흔한 함정은 compliance monitoring tool과 compliance report repository를 혼동하는 것입니다. 시험 팁: 문제에서 SOC 보고서, ISO 인증서, audit artifact 또는 AWS의 self-service compliance 문서를 묻는다면 즉시 AWS Artifact를 떠올리세요. 반대로 문제에서 threat detection을 묻는다면 GuardDuty를 선택하고, 중앙 집중식 보안 findings 및 posture check를 묻는다면 Security Hub를, DDoS protection을 묻는다면 Shield를 선택하세요. 'official reports', 'auditor', 'download', 'no support case'와 같은 키워드는 AWS Artifact를 강하게 나타냅니다.
IAM 사용자 비밀번호가 90일마다 교체되는 3개의 프로덕션 계정으로 구성된 멀티 계정 AWS 환경에 대한 감사 중이며, 2개의 AWS Regions 간에 50 TB의 데이터를 마이그레이션하고 있습니다. 팀은 AWS shared responsibility model에서 'security of the cloud'가 무엇을 의미하는지—특히 모든 AWS services를 운영하는 글로벌 인프라(데이터 센터, 하드웨어, 네트워킹)의 보호를 가리키는지—질문합니다.
이 옵션이 틀린 이유는 'security of the cloud'가 구체적으로 data centers, hardware, 그리고 foundational networking과 같이 AWS services를 실행하는 기반이 되는 global infrastructure를 AWS가 보호하는 것을 의미하기 때문입니다. AWS는 EC2 service 자체의 가용성과 운영에 대한 책임이 있지만, 이 옵션의 문구는 infrastructure security보다는 service uptime을 설명하고 있습니다. 고객은 여전히 resilient workloads를 설계하고, instance health를 모니터링하며, Auto Scaling 및 Multi-AZ deployments와 같은 기능을 구성할 책임이 있으므로, 이는 문제에서 테스트하는 정의와 일치하지 않습니다.
정답입니다. shared responsibility model에서 “security of the cloud”는 AWS가 모든 AWS services를 실행하는 기반 인프라(물리적 데이터 센터, 하드웨어, 그리고 기초 네트워킹/가상화)를 보호한다는 의미입니다. 고객은 이러한 물리 구성 요소를 관리하거나 보안 처리하지 않으며, AWS는 글로벌 인프라 보안 및 컴플라이언스 체계의 일부로 이러한 통제를 설계, 운영, 감사합니다.
IAM 비밀번호 정책(90일 교체 포함)을 강제하는 것은 고객 책임이며 “security in the cloud”에 해당합니다. IAM 구성, 자격 증명 관리, MFA, least privilege, 계정 거버넌스는 고객이 통제합니다. AWS는 IAM 서비스를 제공하고 그 가용성을 보장하지만, 고객은 자신의 identity에 대한 정책과 운영 프로세스를 결정하고 구현합니다.
서드파티 AWS Network Firewall 파트너(또는 AWS Network Firewall 자체)를 사용하는 것은 고객 워크로드와 VPC 트래픽 흐름을 보호하는 것으로, 고객 책임(“in the cloud”)입니다. 이는 글로벌 인프라(데이터 센터, 물리 하드웨어, 핵심 네트워킹)를 보호하는 AWS의 책임을 설명하는 것이 아닙니다. 네트워크 방화벽은 고객이 자신의 환경을 보호하기 위해 선택하는 구성 옵션입니다.
핵심 개념: 이 문제는 AWS Shared Responsibility Model을 평가하며, 특히 “security of the cloud”(AWS의 책임)와 “security in the cloud”(고객의 책임)의 구분을 다룹니다. “security of the cloud”는 AWS services를 실행하는 기반 글로벌 인프라—시설, 물리적 하드웨어, 그리고 기초 네트워킹—를 보호하는 것을 의미합니다. 정답이 맞는 이유: 선택지 B는 AWS의 정의와 직접적으로 일치합니다. AWS는 모든 AWS services를 실행하는 인프라를 보호할 책임이 있습니다. 여기에는 데이터 센터의 물리적 보안, 환경 제어, 물리적 접근 제어, 미디어의 안전한 폐기, 그리고 서비스 기반을 제공하는 글로벌 네트워크 및 가상화 계층의 설계/운영이 포함됩니다. 고객은 물리 계층을 관리하지 않고 이러한 서비스를 사용합니다. 알아야 할 주요 AWS 기능 / 실무: AWS는 컴플라이언스 프로그램(예: SOC reports, ISO certifications) 하에서 이러한 통제를 구현하고 감사하며, AWS Artifact를 통해 아티팩트를 제공합니다. 고객은 서비스(IAM, security groups, encryption, logging)를 안전하게 구성해야 하지만, AWS는 기반 인프라가 보호되고 복원력을 갖추도록 보장합니다. 멀티 계정 환경과 cross-Region 마이그레이션에서도 고객은 identity governance, 데이터 보호 구성, 워크로드 하드닝을 여전히 소유하지만, AWS는 물리 및 기반 계층을 소유합니다. 흔한 오해: EC2를 계속 실행 상태로 유지하거나 IAM 비밀번호 교체를 구성하는 선택지는 “보안 관련”처럼 보일 수 있지만, 이는 고객 측 운영/보안 통제(“in the cloud”)입니다. 마찬가지로 네트워크 방화벽(AWS Network Firewall 또는 파트너 솔루션)을 사용하는 것은 고객 VPC 트래픽과 워크로드를 보호하는 것으로, 역시 고객 책임이며, 글로벌 인프라에 대한 AWS의 책임과는 다릅니다. 시험 팁: “global infrastructure,” “data centers,” “hardware,” “networking that operates all AWS services” 같은 표현을 보면 AWS 책임(“security of the cloud”)으로 매핑하세요. IAM policies, password rotation, security groups, encryption settings, guest OS 패치, firewall rules 같은 항목을 보면 고객 책임(“security in the cloud”)으로 매핑하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
220명의 직원을 보유한 리테일 분석 회사가 단일 Region 내 3개의 Availability Zone에 걸쳐 AWS에서 microservices 앱을 배포하고 있으며, 48시간 이내에 OS instances를 패치하고 최소 권한 security groups를 구성해야 하고, client devices에서 민감한 데이터를 AES-256으로 암호화하여 사용한다. AWS shared responsibility model에 따라, 기본적으로 AWS가 책임지는 작업은 무엇인가?
오답. AWS는 VPC 구성요소와 network ACLs 및 security groups를 사용할 수 있는 기능을 제공하지만, least privilege에 따라 이를 구성하는 책임은 고객에게 있습니다. AWS는 애플리케이션에 필요한 ports, sources 또는 segmentation 요구사항을 알 수 없습니다. 이는 “security in the cloud”에 해당하며, 고객의 구성 및 지속적인 governance 영역입니다.
오답. mobile 또는 desktop apps에서의 client-side encryption은 고객이 관리하는 endpoints 및 고객 애플리케이션 코드 내에서 발생합니다. AWS는 encryption libraries, KMS 및 best-practice guidance를 제공할 수 있지만, 고객의 client applications에서 암호화를 구현할 책임은 AWS에 있지 않습니다. 이는 전적으로 고객의 통제 및 책임 범위입니다.
오답. IAM users, groups, roles, policies 및 MFA enforcement를 생성하고 관리하는 것은 고객 책임입니다. AWS는 IAM service를 운영하고 availability 및 durability를 보장하지만, 고객이 identities, permissions 및 authentication requirements를 정의해야 합니다. 여기서의 misconfigurations는 보안 사고의 흔한 원인이며 명확히 “security in the cloud”에 해당합니다.
정답. AWS는 AWS services를 실행하는 physical facilities, hardware, power, cooling 및 global network를 유지보수할 책임이 있습니다. 이는 “security of the cloud”이며 모든 고객에 대해 기본적으로 AWS가 처리합니다. 고객은 이러한 구성요소를 패치하거나 구성할 수 없고, AWS가 이를 안전하고 신뢰성 있게 운영하는 것에 의존합니다.
핵심 개념: 이 문제는 AWS Shared Responsibility Model을 평가합니다. AWS는 “security of the cloud”(기반 인프라)에 대한 책임이 있고, 고객은 “security in the cloud”(AWS services를 어떻게 구성하고 사용하는지, 그리고 endpoints에서의 모든 것)에 대한 책임이 있습니다. 정답인 이유: 옵션 D는 AWS의 기본 책임을 설명합니다. 즉, physical data centers, hardware, power, cooling, 그리고 AWS services를 지원하는 global network를 유지보수 및 운영하는 것입니다. 이는 고객이 직접 접근하거나 관리할 수 없는 기반 통제입니다. workload가 3개의 Availability Zones에 걸친 microservices이든, 회사가 엄격한 patching 및 least-privilege 요구사항을 갖고 있든 상관없이, AWS는 여전히 physical 및 environmental security와 backbone network operations를 소유합니다. 주요 AWS 기능 / 책임: AWS는 data center physical security(통제된 접근, surveillance, environmental safeguards), hardware lifecycle, 그리고 Regions/AZs 간 networking fabric을 처리합니다. 또한 AWS는 많은 services에 대해 virtualization layer를 관리하고 AWS Artifact를 통해 compliance reports(예: SOC, ISO)를 제공하지만, 핵심 요점은 기반 facilities 및 infrastructure가 AWS 소유라는 것입니다. 흔한 오해: 많은 응시자가 “network security”를 AWS 책임으로 혼동합니다. AWS는 tools(security groups, NACLs, IAM)를 제공하지만, 이를 구성하는 것은 고객 책임입니다. 마찬가지로 mobile/desktop devices에서의 client-side encryption은 AWS 외부에서 발생하므로 전적으로 고객이 통제합니다. OS patching은 service model에 따라 달라집니다. EC2의 경우 고객이 guest OS를 패치합니다. managed services(예: RDS)의 경우 AWS가 기반 인프라를 패치하고, 구성에 따라 engine도 종종 패치하지만, 이 문제는 명시적으로 OS instances를 언급하므로 EC2 스타일의 책임을 시사합니다. 시험 팁: “기본적으로 AWS가 책임지는 것”을 묻는 경우, physical infrastructure 및 기반 cloud platform에 관한 답을 찾으십시오. IAM, security groups, NACLs 같은 customer configuration, data classification, encryption 선택, endpoint security, 또는 guest OS patching을 포함하는 항목은 일반적으로 고객 책임이며—특히 Amazon EC2 같은 IaaS에서는 더욱 그렇습니다.
한 피트니스 스타트업이 웨어러블 동반 애플리케이션을 출시할 계획이며, 코로케이션된 온프레미스 랙에 배포할지 AWS Cloud에 배포할지 결정하고 있습니다. 첫 3개월 내에 활성 사용자 50,000명을 목표로 하며, 주말 챌린지 동안 트래픽 급증이 예상됩니다. 이 경우 AWS Cloud를 사용하는 이점으로 해당되는 것은 무엇입니까? (두 개 선택)
오답입니다. 대규모 upfront 하드웨어 구매는 전통적인 온프레미스 또는 코로케이션 배포(CapEx)의 특징입니다. AWS Cloud의 주요 이점 중 하나는 변동형 pay-as-you-go 요금(OpEx)으로 전환하고 피크 수요를 대비한 과도한 프로비저닝을 피하는 것입니다. 성장 불확실성과 주말 급증이 있는 스타트업에게 upfront 구매는 위험을 높이고 유연성을 낮춥니다.
정답입니다. AWS는 리소스(컴퓨팅, 데이터베이스, 네트워킹)를 몇 분 내로 프로비저닝할 수 있어, 조달 및 설치에 수주가 걸리는 것을 기다리지 않고 더 빠른 실험을 가능하게 합니다. 이는 새로운 웨어러블 동반 앱의 빠른 기능 반복 개선을 지원합니다. 관리형 서비스와 Infrastructure as Code를 사용하면 개발 사이클이 더 빨라지고 출시까지의 시간이 단축됩니다.
오답입니다. 출입 배지 접근 및 CCTV 감시에 대한 완전하고 직접적인 제어는 온프레미스/코로케이션의 이점입니다. AWS에서는 데이터 센터의 물리적 보안이 shared responsibility model의 일부로 AWS에 의해 처리됩니다. 고객은 논리적 보안(IAM, security groups, encryption)은 제어하지만, 시설 접근 시스템에 대한 직접 제어는 하지 않습니다.
정답입니다. 탄력성은 AWS의 핵심 장점입니다. 수요에 맞춰 몇 분 내로 용량을 확장하거나 축소할 수 있습니다. 이는 주말 챌린지 급증에 이상적이며, Auto Scaling, 로드 밸런싱, serverless 확장을 통해 피크를 처리하면서도 비피크 기간에는 피크 규모의 인프라를 상시 실행(및 비용 지불)하지 않아도 됩니다.
오답입니다. 고객은 지연 시간, 규정 준수, 복원력을 위해 Regions 및 Availability Zones를 선택하지만, 서버를 호스팅하는 정확한 물리적 건물은 선택하지 않습니다. 이 선택지는 코로케이션/온프레미스 시나리오를 설명합니다. AWS는 기반 시설을 추상화하면서도 아키텍처 설계를 위한 고가용성 구성 요소(multi-AZ, multi-Region)를 제공합니다.
핵심 개념: 이 문제는 AWS Cloud의 기본 가치 제안인 민첩성(온디맨드 리소스)과 탄력성(신속한 확장)을 평가합니다. 이는 AWS Cloud Practitioner 스타일 도메인에서 강조되는 핵심 Cloud Concepts이며, AWS Well-Architected Framework의 Performance Efficiency 및 Cost Optimization 기둥과도 일치합니다. 정답이 맞는 이유: 이 스타트업은 활성 사용자 50,000명까지의 빠른 성장과 주말 급증처럼 예측 가능하지만 급격한 트래픽 스파이크를 예상합니다. AWS는 하드웨어 조달, 랙 설치, 용량 계획 사이클을 기다리지 않고도 팀이 인프라를 온디맨드로 프로비저닝하고 빠르게 반복 개선할 수 있게 해줍니다. 이는 더 빠른 실험과 기능 반복 개선(B)을 직접적으로 지원합니다. 또한 AWS는 탄력성을 제공합니다. 수요 급증에 맞춰 몇 분 내로 용량을 확장/축소할 수 있어(D), 트래픽 급증이 시간적으로 제한된 주말 챌린지에 이상적입니다. 주요 AWS 기능: 온디맨드 프로비저닝은 Amazon EC2, Amazon ECS/EKS, AWS Lambda, 관리형 데이터베이스(Amazon RDS/Aurora, DynamoDB) 같은 서비스를 통해 가능합니다. Infrastructure as Code(AWS CloudFormation, AWS CDK, Terraform)는 dev/test/prod를 위한 반복 가능한 환경을 가속합니다. 몇 분 내 확장을 위해서는 AWS Auto Scaling(EC2 Auto Scaling, ECS Service Auto Scaling), Application Load Balancer, 그리고 serverless 동시성 확장(Lambda) 등이 일반적인 패턴입니다. 관리형 서비스를 사용하면 운영 오버헤드가 줄고 출시까지의 시간이 단축됩니다. 흔한 오해: 일부는 하드웨어를 upfront로 구매하는 것(A)이 장기적으로 단가를 낮출 수 있어 유리하다고 생각할 수 있지만, 이는 대규모 자본 지출을 피하고 사용한 만큼 지불하는 cloud 이점과 상충합니다. 물리적 제어(C, E)에 관한 선택지는 온프레미스의 장점을 반영합니다. AWS에서는 shared responsibility model을 사용하며, AWS가 물리적 시설을 관리하고 고객은 구성 및 데이터 보안을 관리합니다. 시험 팁: “traffic surges”, “spiky demand”, “rapid growth”, “launching soon”을 보면 탄력성과 민첩성 키워드인 “scale within minutes”, “on-demand”, “pay-as-you-go”, “faster experimentation”을 찾으세요. 반대로 직접적인 물리적 접근, 정확한 건물 선택, 대규모 upfront 구매에 대한 문구는 보통 cloud 이점이 아니라 온프레미스 특성을 나타냅니다.
90일마다 비밀번호를 변경해야 하는 회사 정책으로 인해, 지원 엔지니어는 원격으로 근무하면서 웹 브라우저와 IAM 자격 증명으로 구성된 AWS CLI v2가 있는 터미널만 사용할 수 있는 상태에서 향후 24시간 내에 자신의 IAM user 비밀번호를 변경해야 합니다. 엔지니어가 비밀번호를 변경하는 데 사용할 수 있는 AWS 서비스 또는 인터페이스는 무엇입니까? (두 개 선택)
정답입니다. AWS CLI는 IAM ChangePassword API를 사용하여 현재 IAM user의 console password를 변경할 수 있습니다(예: "aws iam change-password"). 이를 위해서는 CLI가 해당 사용자의 access keys로 구성되어 있어야 하며, 사용자에게 iam:ChangePassword 권한이 있어야 합니다. 이는 셀프 서비스 작업이며 AWS Management Console 접근이 필요하지 않습니다.
오답입니다. AWS KMS는 encryption key를 생성 및 관리하고 암호화 작업을 제어하는 데 사용됩니다. console password 같은 IAM user authentication 자격 증명을 관리하지 않습니다. KMS는 secret을 보호하거나 데이터를 암호화할 수는 있지만, IAM user의 비밀번호를 변경하거나 비밀번호 회전 정책을 적용하는 데 사용할 수는 없습니다.
정답입니다. AWS Management Console은 로그인한 IAM user가 자신의 비밀번호를 변경할 수 있는 기본 인터페이스를 제공합니다. 이는 일반적인 비밀번호 회전 워크플로 및 IAM account password policy와 일치합니다. 브라우저 기반으로 가장 직접적인 방법이며, IAM과 console UI 외에 추가 서비스가 필요하지 않습니다.
오답입니다. AWS Resource Access Manager (RAM)는 AWS 리소스(예: subnet, Transit Gateway, license configuration)를 AWS 계정 간 또는 조직 내에서 공유하기 위한 서비스입니다. IAM user 자격 증명 관리 기능이 없으며 IAM user 비밀번호를 변경하거나 회전하는 데 사용할 수 없습니다.
오답입니다. AWS Secrets Manager는 데이터베이스 비밀번호, API key 및 기타 애플리케이션 자격 증명 같은 secret을 저장하고(종종 Lambda 기반 회전을 통해) 회전합니다. IAM과 통합되어 IAM user의 console password를 변경하지는 않습니다. IAM user 비밀번호 회전은 IAM policy, password policy, 그리고 IAM 인터페이스(console/CLI/API)를 통해 처리됩니다.
핵심 개념: 이 문제는 IAM user의 자격 증명 관리, 특히 사용자가 자신의 console password를 변경하는 방법을 평가합니다. AWS에서 IAM user password는 AWS Management Console에 로그인하는 데 사용되는 자격 증명입니다. 비밀번호 변경(회전)은 일반적으로 IAM account password policy 및 운영 프로세스를 통해 강제됩니다. 정답인 이유: C (AWS Management Console)가 정답인 이유는 IAM user가 console UI를 통해(예: 사용자 메뉴 또는 IAM user security credentials 페이지) 자신의 비밀번호를 변경할 수 있기 때문입니다. 단, 해당 IAM user로 로그인되어 있고 셀프 서비스 작업을 수행할 권한이 있어야 합니다. 웹 브라우저만 사용할 수 있을 때 가장 일반적이고 간단한 방법입니다. A (AWS CLI)도 정답인 이유는 IAM이 현재 사용자의 비밀번호를 변경하는 API 작업(ChangePassword)을 제공하기 때문입니다. 엔지니어의 IAM user access keys로 구성된 AWS CLI v2를 사용하면 "aws iam change-password --old-password ... --new-password ..." 같은 명령을 실행할 수 있습니다. 이는 다른 사용자를 관리하기 위한 관리자 권한 없이도 사용자가 자신의 비밀번호를 변경하도록 특별히 설계된 기능입니다. 주요 AWS 기능: - IAM ChangePassword API: 사용자가 자신의 비밀번호를 변경할 수 있도록 하며, 다른 사용자의 비밀번호 변경은 허용하지 않습니다. - IAM permissions: 사용자는 iam:ChangePassword를 호출할 수 있어야 합니다(대개 self-management policy에서 기본적으로 부여됨). 거부되는 경우 admin이 권한을 업데이트해야 합니다. - Account password policy: 회전, 복잡성, 재사용 방지, 만료를 강제하며, 사용자는 새 비밀번호 설정 시 이를 준수해야 합니다. 흔한 오해: - AWS Secrets Manager (E)는 애플리케이션 secret을 관리하고 데이터베이스/API 자격 증명을 회전할 수 있지만, IAM user의 console password를 변경하지는 않습니다. - AWS KMS (B)는 데이터를 암호화하고 key를 관리하는 서비스로, IAM user 비밀번호 변경과는 관련이 없습니다. - AWS RAM (D)은 계정 간 리소스를 공유하는 서비스로, IAM authentication 자격 증명과는 무관합니다. 시험 팁: IAM user 비밀번호 관련 작업은 “IAM + Console/CLI/API”를 떠올리세요. 자신의 비밀번호를 변경하는 문제라면 Management Console과 CLI/SDK를 통한 IAM ChangePassword 기능을 찾으면 됩니다. access keys를 회전하는 것은 다른 IAM 작업(create/update/delete access keys)입니다. 애플리케이션 자격 증명 회전이라면 보통 Secrets Manager가 관련됩니다.
마이그레이션을 계획하기 위해, 재무 팀은 두 개의 Application Load Balancers 뒤에서 20개의 m5.large Amazon EC2 인스턴스를 사용하고 인터넷으로 월 약 8 TB의 데이터 전송(아웃바운드)이 발생할 예정인 분석 스택의 월간 AWS 비용을 추정해야 합니다. 어떤 AWS 서비스 또는 기능을 사용해야 합니까?
Amazon Detective는 AWS 로그(예: VPC Flow Logs, CloudTrail)를 분석하고 엔터티 행동 그래프를 구축하여 잠재적인 보안 문제를 조사하는 보안 분석 서비스입니다. 이는 사고 조사 및 위협 탐지에 사용되며, AWS 비용을 추정하는 용도가 아닙니다. 제안된 마이그레이션에 대한 EC2, ALB, 또는 인터넷 egress 요금을 재무 팀이 모델링하는 데 도움이 되지 않습니다.
AWS Budgets는 비용 및 사용량 예산을 설정하고 실제 또는 예측 지출이 임계값을 초과할 때 알림을 받는 데 사용됩니다. 워크로드가 실행된 이후(또는 Cost Explorer에 데이터가 쌓인 이후) 지출을 통제하는 데 유용하지만, 새로운 아키텍처에 대한 사전 배포 항목별 추정치를 만드는 데 가장 적합한 도구는 아닙니다. 마이그레이션 계획을 위한 추정에는 Pricing Calculator가 올바른 선택입니다.
AWS Resource Explorer는 리전과 계정 전반에서 AWS 리소스를 검색하고 발견하는 데 도움이 됩니다(인벤토리 및 거버넌스 사용 사례). 가격 또는 비용 추정 기능을 제공하지 않습니다. 이 문제는 제안된 스택의 월간 비용을 예측하는 것이므로, 리소스 탐색 도구는 관련이 없습니다.
AWS Pricing Calculator는 계획된 아키텍처에 대한 월간 AWS 비용을 추정하는 올바른 도구입니다. 20개의 m5.large EC2 인스턴스, 두 개의 Application Load Balancers(load balancer-hours 및 LCU 가정 포함), 그리고 리전별 요금을 반영한 인터넷으로의 월 ~8 TB data transfer out을 모델링할 수 있습니다. 재무 팀이 마이그레이션 계획 및 승인에 사용할 수 있는 항목별 추정치를 제공합니다.
핵심 개념: 이 문제는 (아직 배포되지 않은) 계획된 워크로드에 대한 AWS 비용 추정을 테스트합니다. 선택한 AWS 서비스, 인스턴스 유형, 로드 밸런서, 데이터 전송을 기반으로 월간 비용을 예측하는 주요 서비스는 AWS Pricing Calculator입니다. 정답이 맞는 이유: 재무 팀은 제안된 분석 스택의 월간 AWS 비용을 추정해야 합니다: 20개의 m5.large EC2 인스턴스, 두 개의 Application Load Balancers(ALBs), 그리고 인터넷으로 월 ~8 TB의 데이터 전송(아웃바운드). AWS Pricing Calculator는 마이그레이션 전에 이러한 입력값을 정확히 모델링하도록 설계되었습니다. EC2 인스턴스 유형과 개수, 예상 사용 시간, EBS 가정, ALB 시간/LCU 사용량, 아웃바운드 데이터 전송을 선택할 수 있으며, 이후 항목별 월간 추정치를 산출합니다. 이는 마이그레이션 계획 및 비즈니스 케이스에서 사용하는 표준 사전 배포 도구입니다. 주요 AWS 기능: Pricing Calculator는 다음을 지원합니다: - 서비스별 추정치(EC2, ELB/ALB, data transfer, storage 등) - 리전별 요금(요금은 리전에 따라 달라지므로 중요) - 사용량 가정(on-demand vs Savings Plans/Reserved Instances, hours/month) - 이해관계자 공유/내보내기(재무 승인에 유용) ALB의 경우 비용에는 load balancer-hours와 LCUs가 포함되며, data transfer의 경우 계층형 인터넷 egress 요금을 반영합니다. 이는 시험에서 자주 나오는 디테일로, compute + load balancing + egress는 각각 별도의 항목으로 청구됩니다. 흔한 오해: AWS Budgets는 종종 추정과 혼동되지만, 예산을 설정한 후 AWS 계정에서 실제 또는 예측 지출을 모니터링하고 알림을 제공하는 기능입니다. 처음부터 상세한 사전 마이그레이션 견적을 만드는 주요 도구는 아닙니다. Detective와 Resource Explorer는 요금과 관련이 없습니다. 시험 팁: 문제에서 “estimate(추정)” 또는 “plan a migration(마이그레이션 계획)”이라고 하면서 인스턴스 수와 데이터 전송이 포함된 가상의 아키텍처를 제시하면 AWS Pricing Calculator를 선택하십시오. “set alerts/thresholds(알림/임계값 설정)” 또는 “track spend over time(시간에 따른 지출 추적)”이라면 AWS Budgets를 선택하십시오. 또한 인터넷으로의 data transfer out은 주요 비용 요인이며 Pricing Calculator에서 명시적으로 모델링된다는 점을 기억하십시오.
한 스타트업이 Amazon S3에 고객 기록 5 TB를 저장하고, EC2 인스턴스에 Amazon EBS 볼륨 20개를 연결하며, 프로덕션 Amazon RDS 데이터베이스를 실행할 계획이다. 또한 이들 모두에서 저장 데이터 암호화를 위해 키를 중앙에서 생성하고 관리할 수 있도록, 이러한 서비스들과 통합되는 단일 AWS 관리형 서비스가 필요하다. 어떤 서비스를 사용해야 하는가?
AWS Key Management Service (AWS KMS)는 AWS 서비스 전반에서 저장 데이터 암호화에 사용되는 암호화 키를 생성하고 관리하는 AWS 관리형 서비스이므로 정답이다. Amazon S3 (SSE-KMS), Amazon EBS (볼륨 및 스냅샷 암호화), Amazon RDS (DB 인스턴스 및 백업 암호화)와 직접 통합된다. 또한 key policies, IAM 통합, CloudTrail 감사, 선택적 키 로테이션을 제공한다.
AWS Certificate Manager (ACM)는 로드 밸런서, CloudFront, API 엔드포인트의 HTTPS와 같이 네트워크 통신을 보호하기 위한 SSL/TLS 인증서(전송 중 암호화)를 관리한다. 인증서에는 공개/개인 키가 포함되지만, ACM은 S3 객체, EBS 볼륨, RDS 스토리지에 대한 저장 데이터 암호화 키를 중앙에서 관리하는 데 사용되지 않는다. 따라서 이러한 서비스 전반에서 저장 데이터를 암호화한다는 요구 사항을 충족하지 못한다.
AWS Identity and Access Management (IAM)은 사용자, 역할, 권한을 관리하는 데 사용되며, KMS 키를 누가 사용할 수 있는지 또는 암호화된 리소스에 누가 접근할 수 있는지를 제어하는 것도 포함한다. 그러나 IAM은 저장 데이터용 암호화 키를 생성, 저장, 로테이션하거나 키로 암호화 작업을 수행하지 않는다. IAM은 접근 제어 서비스이지 중앙 집중식 키 관리 서비스가 아니므로, 단독으로는 제시된 요구 사항을 충족할 수 없다.
AWS Security Hub는 AWS 서비스(예: GuardDuty, Inspector) 및 파트너 도구에서 나온 보안 탐지 결과를 집계, 정규화, 우선순위화하며, 표준에 대한 보안 상태 관리를 돕는다. 하지만 저장 데이터 암호화를 위한 키 생성이나 키 라이프사이클 관리를 제공하지 않는다. 암호화 관련 통제를 보고할 수는 있지만, 암호화 키를 생성하고 관리하는 단일 서비스로 사용할 수는 없다.
핵심 개념: 이 문제는 여러 AWS 스토리지 및 데이터베이스 서비스 전반에서 저장 데이터 암호화를 위한 중앙 집중식 키 관리를 테스트합니다. 다른 AWS 서비스에서 사용하는 암호화 키를 생성, 저장 및 제어하도록 특별히 설계된 AWS 관리형 서비스는 AWS Key Management Service (AWS KMS)입니다. 정답인 이유: 이 스타트업은 Amazon S3, Amazon EBS, Amazon RDS와 통합되어 암호화 키를 중앙에서 생성하고 관리할 수 있는 단일 AWS 관리형 서비스가 필요합니다. AWS KMS는 이러한 서비스에서 서버 측 암호화에 직접 사용할 수 있는 customer managed keys와 AWS managed keys를 제공합니다. KMS를 사용하면 S3는 SSE-KMS를 사용할 수 있고, EBS는 KMS keys로 볼륨과 스냅샷을 암호화할 수 있으며, RDS는 KMS를 사용하여 DB 인스턴스, 스토리지, 스냅샷 및 자동 백업을 암호화할 수 있습니다. 이는 세 가지 모두에 걸쳐 하나의 중앙 집중식 AWS 관리형 키 서비스가 필요하다는 요구 사항을 충족합니다. 주요 AWS 기능: KMS는 권한 부여를 위해 IAM과 통합되며, key policies와 IAM policies를 통해 세분화된 제어를 가능하게 합니다. 또한 key usage에 대한 AWS CloudTrail logs를 통해 감사 가능성을 제공하고, customer managed keys에 대한 자동 key rotation을 지원하며, 서비스가 KMS key로 data keys를 보호하는 envelope encryption 패턴을 사용합니다. 규정 준수에 민감한 워크로드의 경우, KMS는 AWS가 관리하는 HSM 기반 key material을 사용할 수 있으며, 일부 고급 시나리오에서는 AWS CloudHSM과 통합할 수 있습니다. 모범 사례는 key policies에 least privilege를 적용하고 환경 또는 데이터 분류별로 키를 분리하는 것입니다. 일반적인 오해: ACM은 둘 다 암호화 자료를 다루기 때문에 종종 KMS와 혼동되지만, ACM은 저장 데이터 암호화를 위한 S3, EBS 또는 RDS의 키가 아니라 전송 중 데이터에 대한 TLS/SSL certificates를 관리합니다. IAM은 자격 증명과 권한을 제어하지만, 이러한 서비스에 대한 암호화 키를 생성하거나 중앙에서 관리하지는 않습니다. Security Hub는 보안 findings와 보안 상태 관리를 중앙화하지만, 암호화 키 생성이나 lifecycle management를 제공하지는 않습니다. 시험 팁: AWS 서비스 전반에서 '키를 중앙에서 생성 및 관리'하고 '저장 데이터를 암호화'한다는 표현이 보이면 AWS KMS를 떠올리세요. 서비스를 해당 KMS 통합에 매핑하세요: S3 (SSE-KMS), EBS (볼륨 및 스냅샷 암호화), RDS (DB 암호화). 문제에서 certificates 또는 HTTPS가 언급되면 ACM을, permissions, users 또는 roles가 언급되면 IAM을, 보안 경고 집계를 언급하면 Security Hub를 떠올리세요.
학습 기간: 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를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.