
65개 문제와 90분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
한 대학교 IT 팀이 4개 부서에 걸쳐 180명의 IAM user가 있는 단일 AWS account를 관리하고 있습니다. 분기별 보안 검토 중, 컴플라이언스 담당자가 모든 IAM user와 root user에 대해 MFA가 활성화되어 있는지(true/false), user 생성 날짜, 마지막 password 변경 날짜, access key가 활성 상태인지 여부를 보여주는 다운로드 가능한 CSV 보고서를 요청합니다. 팀은 스크립트를 작성하지 않고, 추가 서비스를 활성화하지 않으며, 추가 비용을 발생시키지 않고 AWS Management Console에서 직접 이 보고서를 생성해야 합니다. 이 요구 사항을 충족하는 AWS 기능 또는 서비스는 무엇입니까?
AWS Cost and Usage Reports(CUR)는 상세한 청구 및 사용량 라인 아이템을 제공하며 S3로 전달될 수 있습니다(종종 Athena로 쿼리). CUR는 내보내고 분석할 수는 있지만 IAM 보안/컴플라이언스 보고서가 아니며, user별 MFA 상태, password 변경 날짜, access key 활성/비활성 상태를 포함하지 않습니다. 또한 일반적으로 설정/전달 구성 작업이 필요하므로 “console에서 직접”이라는 제약과도 충돌합니다.
IAM credential report는 정확히 이 감사(audit) 사용 사례를 위해 설계되었습니다. IAM console에서 생성해 다운로드할 수 있는 CSV로, 모든 IAM user와 root user의 credential 및 보안 상태 필드를 나열합니다. MFA 활성화 상태, user 생성 시간, password_last_changed 정보, access key 활성/비활성 지표가 포함됩니다. 스크립트가 필요 없고, 추가 서비스도 필요 없으며, 추가 비용도 없어 모든 제약 조건을 충족합니다.
Detailed Billing Reports는 청구 중심 산출물(역사적으로 상세 비용 분해와 연관)이며 identity 또는 credential 컴플라이언스를 위한 것이 아닙니다. MFA 활성화, user 생성 날짜, password_last_changed, access key 상태 같은 IAM user 속성을 포함하지 않습니다. 다운로드가 가능하더라도 재무 보고 목적이지 보안 상태 목적이 아니므로, 컴플라이언스 담당자가 요청한 IAM credential 세부 정보를 충족할 수 없습니다.
AWS Cost Explorer reports는 시간에 따른 비용을 시각화하고 분석하며 비용 데이터를 내보낼 수 있습니다. 그러나 Cost Explorer는 지출 및 사용량 배분에만 초점이 있으며 IAM credential 위생 상태를 다루지 않습니다. IAM user 또는 root user에 대한 MFA 상태, password 변경 날짜, access key 활성화 상태를 보고할 수 없으므로 보안 검토 보고 요구 사항을 충족하지 못합니다.
핵심 개념: 이 문제는 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에 포함된다는 점은 시험에서 자주 나오는 구분 포인트입니다.
한 소매 회사가 하루 약 15,000건의 주문을 처리하는 9년 된 온프레미스 Java 모놀리스를 운영하고 있으며 AWS로 마이그레이션하는 동안 이를 CI/CD와 도메인 주도 경계를 갖춘 컨테이너에서 실행되는 12개의 독립적으로 배포 가능한 마이크로서비스로 분리하려고 합니다. 회사는 어떤 마이그레이션 전략을 선택해야 합니까?
Rehost (lift-and-shift)는 일반적으로 Amazon EC2(그리고 경우에 따라 로드 밸런서 및 관리형 데이터베이스)로 최소한의 코드 변경 또는 코드 변경 없이 애플리케이션을 이동합니다. 이는 속도와 리스크 감소를 위해 선택되며 재설계를 위한 것이 아닙니다. Java 모놀리스를 대부분 그대로 유지하게 되며, 12개의 마이크로서비스로의 분해, 독립적 배포, 도메인 주도 경계를 달성하지 못합니다.
Replatform (lift-tinker-and-shift)은 일부 cloud 이점을 얻기 위한 제한적인 변경(예: 자체 관리 미들웨어에서 관리형 서비스로 이동, 또는 런타임 구성 조정)을 포함합니다. 모놀리스를 컨테이너화하거나 데이터베이스를 RDS로 옮길 수는 있지만, replatforming은 별도의 배포 라이프사이클과 서비스별 CI/CD를 갖춘 여러 마이크로서비스로의 대규모 아키텍처 재작성까지 의미하지는 않습니다.
Repurchase는 애플리케이션을 다른 제품(종종 SaaS)으로 대체하는 것을 의미합니다(예: 커스텀 주문 시스템에서 상용 플랫폼으로 이동). 이는 운영 부담을 줄일 수 있지만 비즈니스 프로세스를 변경하며, 일반적으로 컨테이너에서 12개의 커스텀 마이크로서비스를 만들겠다는 목표와 일치하지 않습니다. 이 문제는 패키지 솔루션 채택이 아니라 명시적인 목표 아키텍처를 제시합니다.
Refactor (re-architect)는 회사가 모놀리스를 12개의 독립적으로 배포 가능한 마이크로서비스로 재설계하고, 이를 컨테이너화하며, 도메인 주도 경계를 갖춘 CI/CD를 구현하려고 하기 때문에 올바른 전략입니다. 이는 독립적 확장, 더 빠른 릴리스, 그리고 cloud-native 패턴(서비스 디스커버리, 분리된 메시징, 서비스별 데이터 소유권, 향상된 관측 가능성)을 가능하게 하기 위한 상당한 코드 및 아키텍처 변경을 요구합니다.
핵심 개념: 이 문제는 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 결과를 위해 선택됩니다.
6명으로 구성된 엔지니어링 팀을 가진 한 원격의료(telehealth) 스타트업은 10일 이내에 실시간 데이터 처리 파이프라인의 3가지 버전을 프로토타이핑해야 하며, 장기 인프라에 커밋하지 않고 결과에 따라 방향을 전환(pivot)해야 합니다. 이들이 프로세스와 아키텍처에 민첩성(agility)을 가장 직접적으로 내재화하는 데 도움이 되는 AWS Cloud 기능은 무엇입니까?
과도한 프로비저닝을 피하는 것은 수요가 불확실할 때 elasticity와 용량 right-sizing에 관한 내용입니다. 이는 트래픽 변동이 있는 워크로드에 유용하지만, 주로 용량 계획/비용 최적화 이점입니다. 이 문제의 핵심 과제는 컴퓨팅 리소스 사이징이 아니라, 최소한의 운영 부담으로 서로 다른 파이프라인 프로토타입 3개를 빠르게 만드는 것입니다. 과도한 프로비저닝을 피하더라도, 빠르게 반복하기 위한 서비스 폭이 부족할 수 있습니다.
추가적인 지리적 Regions로 확장하는 것은 지연 시간 감소, 재해 복구, 규제 요구를 위해 사용하는 글로벌 인프라 이점입니다. 이는 6명 팀이 10일 안에 실시간 처리 파이프라인의 3가지 버전을 프로토타이핑하는 데 직접적인 도움이 되지 않습니다. 오히려 Regional 확장은 복잡성(data residency, replication, multi-Region failover)을 추가하여 초기 단계 프로토타입의 실험 속도를 늦출 수 있습니다.
광범위한 기술과 managed services에 대한 접근이 민첩성을 가장 직접적으로 가능하게 합니다. 팀은 서버나 장기 인프라를 관리하지 않고도 여러 파이프라인 설계(예: Kinesis + Lambda vs. Managed Flink vs. SQS/SNS 패턴)를 빠르게 조합하고 비교할 수 있습니다. 이는 빠른 반복, 신속한 pivot, undifferentiated heavy lifting 감소를 지원하며, 촉박한 일정의 소규모 팀에 정확히 필요한 역량입니다.
리소스가 소비될 때에만 비용을 지불하는 것은 pay-as-you-go 가격 모델입니다. 이는 프로토타이핑 동안 선투자 커밋을 피하고 재무적 리스크를 줄이는 데 도움이 되지만, 아키텍처/프로세스 민첩성을 가장 직접적으로 가능하게 하는 요소라기보다는 주로 과금/가격 측면의 이점입니다. 이 문제는 여러 파이프라인 버전을 빠르게 실험하는 데 초점이 있으며, 이는 managed services의 폭과 빠른 프로비저닝으로 더 잘 해결됩니다.
핵심 개념 - 이 문제는 AWS Cloud의 가치 제안 중, 광범위한 managed services 포트폴리오에 대한 온디맨드 접근을 통해 빠른 실험을 가능하게 함으로써 민첩성을 제공하는 점(흔히 “increase speed and agility”, “stop spending money running and maintaining data centers”로 표현됨)을 평가합니다. 실시간 데이터 처리 파이프라인 프로토타입의 경우, 일반적으로 Amazon Kinesis (Streams/Firehose), AWS Lambda, Amazon Managed Service for Apache Flink, Amazon SQS/SNS, AWS Step Functions, Amazon DynamoDB, Amazon OpenSearch Service, Amazon S3 같은 서비스와 매핑됩니다. 정답이 맞는 이유 - 이 스타트업은 10일 안에 파이프라인 버전 3개를 구축하고, 장기 인프라 커밋 없이 빠르게 방향을 전환해야 합니다. 이를 가장 직접적으로 가능하게 하는 역량은, 많은 managed technologies 중에서 선택하여 여러 아키텍처를 빠르게 조합할 수 있는 능력입니다(serverless, managed streaming, managed databases, managed analytics). 이는 하드웨어 조달, 소프트웨어 설치, 차별화되지 않는 무거운 작업(undifferentiated heavy lifting) 없이도 신속한 프로토타이핑, 아키텍처 A/B 테스트, 결과 기반 반복 개선을 직접 지원합니다. 주요 AWS 기능 - Managed services는 운영 오버헤드(패칭, 스케일링, high availability)를 줄여줍니다. Serverless 및 managed streaming 서비스는 몇 분 내에 프로비저닝할 수 있고, IAM을 통해 통합되며, Amazon CloudWatch로 관측할 수 있습니다. Infrastructure as Code (AWS CloudFormation/CDK)는 재현 가능한 실험을 더 빠르게 수행하도록 돕습니다. AWS Well-Architected Framework의 Performance Efficiency 및 Operational Excellence pillar는 managed services 선택과 빈번한 실험을 통해 아키텍처를 진화시키는 것을 강조합니다. 흔한 오해 - 옵션 D(종량제, pay-as-you-go)와 A(과도한 프로비저닝 회피)는 비용/용량 측면의 이점으로 도움이 될 수 있지만, “3가지 버전을 프로토타이핑하고 빠르게 pivot”이라는 요구를 가장 직접적으로 해결하지는 않습니다. 사용한 만큼만 비용을 내더라도 모든 것을 직접 구축·운영해야 한다면 여전히 느릴 수 있습니다. 옵션 B(글로벌 확장)는 파이프라인의 빠른 프로토타이핑과는 관련이 없습니다. 시험 팁 - 지문이 “빠르게 프로토타입,” “실험,” “혁신,” “pivot,” “소규모 팀”을 강조하면, managed services의 폭과 빠른 프로비저닝(agility)에 관한 답을 찾으세요. “비용 절감,” “사용한 만큼만 지불,” “수요 불확실”을 강조하면 pay-as-you-go 또는 elasticity/right-sizing 관련 선택지가 더 유력해집니다.
한 핀테크 회사가 us-west-2의 Amazon RDS에서 PostgreSQL 워크로드를 실행하고 있으며, AZ 장애 동안 데이터 손실 없이(RPO 0) RTO를 60초 미만으로 달성해야 합니다. 이를 위해 AWS가 기본(primary) DB 인스턴스와 동일 Region 내 다른 Availability Zone에 있는 대기(standby)를 자동으로 프로비저닝하고, 지속적인 synchronous replication과 automatic failover를 제공해야 합니다. 어떤 RDS 기능을 활성화해야 합니까?
Read replica는 주로 read traffic을 오프로드하고 read scalability를 향상시키기 위한 것이며, AZ 장애에 대한 주요 high-availability 메커니즘으로 사용되지는 않습니다. PostgreSQL용 Amazon RDS에서 read replica는 일반적으로 asynchronous replication을 사용하므로 replication lag가 발생할 수 있고 primary에 장애가 발생하면 잠재적인 data loss가 있을 수 있습니다. Read replica의 promotion은 Multi-AZ failover와는 다른 운영 모델이며, 문제에서 설명한 표준 automatic synchronous standby 설계와 일치하지 않습니다. Read replica는 reporting, analytics, 일부 disaster recovery 시나리오에는 유용하지만, 이 정확한 HA 요구 사항에는 적합하지 않습니다. 따라서 synchronous replication과 AZ 간 automatic failover 요구를 가장 잘 충족하지는 못합니다.
Blue/green deployment는 cutover 전에 변경 사항을 테스트할 수 있도록 별도의 staging environment를 생성하는 deployment 및 upgrade 기능입니다. 그 목적은 engine upgrade, schema change 및 기타 계획된 수정 중 위험을 줄이는 것이지, AZ 장애 동안 지속적인 high availability를 제공하는 것이 아닙니다. 계획된 전환 중 downtime을 최소화하는 데 도움이 될 수는 있지만, automatic failover를 위한 synchronously replicated standby를 유지하는 것과는 다릅니다. 문제는 AWS가 관리하는 다른 AZ의 항상 활성 standby를 구체적으로 요구하며, 이는 Multi-AZ 패턴입니다. 따라서 여기서 blue/green deployment는 올바른 기능이 아닙니다.
Multi-AZ deployment는 동일한 AWS Region 내의 다른 Availability Zone에 primary DB instance와 standby를 유지하는 Amazon RDS의 고가용성 기능입니다. PostgreSQL용 Amazon RDS에서는 데이터가 standby로 synchronously replicated되므로 primary instance 또는 해당 AZ에 장애가 발생해도 commit된 transaction이 보존됩니다. Amazon RDS는 infrastructure 또는 AZ 장애 조건을 자동으로 감지하고 manual intervention 없이 standby를 promote합니다. 애플리케이션은 계속 동일한 RDS endpoint를 사용하지만, 기존 연결은 failover 후 다시 연결해야 합니다. 따라서 Multi-AZ는 동일 Region 내 HA, synchronous replication, automatic failover에 대한 올바른 선택입니다.
Reserved Instances는 일반적으로 1년 또는 3년의 usage term을 약정하여 비용을 절감할 수 있게 해주는 pricing 옵션입니다. 이는 standby database를 생성하지도 않고, replication 동작을 변경하지도 않으며, automatic failover를 활성화하지도 않습니다. Reserved Instances를 구매해도 Availability Zone 장애 동안 RTO 또는 RPO와 같은 복구 목표에는 아무런 영향이 없습니다. 이 옵션은 architecture나 resilience가 아니라 billing optimization을 다룹니다. 따라서 문제의 기술적 요구 사항과는 관련이 없습니다.
핵심 개념: 이 문제는 단일 AWS Region 내에서 PostgreSQL용 Amazon RDS의 고가용성을 테스트하며, 특히 Availability Zone(AZ) 장애 동안 엄격한 복구 목표를 충족하는지를 묻습니다. 핵심 RDS 기능은 Multi-AZ deployment이며, 이는 다른 AZ의 standby로 자동 failover를 제공합니다. 정답인 이유: 요구 사항은 명시적으로 다음을 요구합니다: (1) 동일 Region 내 다른 AZ의 standby, (2) 지속적인 synchronous replication, (3) automatic failover, (4) zero data loss (RPO = 0), (5) AZ 장애 동안 60초 미만의 RTO. RDS Multi-AZ는 정확히 이를 위해 설계되었습니다. 이는 primary DB instance와 다른 AZ의 synchronous standby replica를 유지합니다. primary 또는 해당 AZ를 사용할 수 없게 되면, RDS는 자동으로 standby로 failover하며, 일반적으로 조건에 따라 약 60~120초 내에 완료됩니다. 또한 시험에서는 “AZ outage + automatic failover + synchronous + zero data loss”에 대한 RDS의 표준 정답입니다. 주요 AWS 기능 / 모범 사례: PostgreSQL용 RDS Multi-AZ에서는 쓰기가 standby로 synchronously replicated됩니다(그리고 최신 아키텍처에서는 Multi-AZ DB clusters가 더 빠른 failover를 제공할 수 있습니다). Failover는 RDS가 관리하며(new primary로의 DNS endpoint remapping), 애플리케이션은 다시 연결해야 합니다. 모범 사례에는 DB instance endpoint 사용(기본 host가 아님), 애플리케이션 retry logic 활성화, Amazon CloudWatch 및 RDS events를 통한 모니터링이 포함됩니다. Multi-AZ는 read scaling이 아니라 high availability를 위한 것입니다. 흔한 오해: Read replica는 종종 HA로 오해되지만, PostgreSQL에서는 일반적으로 asynchronous이며 read scaling과 disaster recovery를 위한 것이고 replication lag 가능성(non-zero data loss)과 많은 시나리오에서 manual promotion이 필요합니다. Blue/green deployment는 더 안전한 업데이트와 제어된 cutover를 위한 것이지, AZ 장애 HA를 위한 것이 아닙니다. Reserved Instances는 downtime이 아니라 비용을 줄입니다. 시험 팁: “AZ outage”, “automatic failover”, “synchronous replication”, “RPO 0”를 보면 RDS Multi-AZ를 떠올리세요. “read scaling” 또는 “cross-Region DR”를 보면 read replica(대개 async) 또는 cross-Region 전략을 떠올리세요. 또한 HA(Multi-AZ)와 deployment 전략(blue/green), 그리고 pricing 구성 요소(Reserved Instances)를 구분하세요.
월간 활성 사용자 120,000명의 핀테크 스타트업이 Amazon Cognito로 지원되는 고객 포털을 출시하고 있으며, 유료 third-party 도구를 추가하지 않고 AWS 보안을 빠르게 강화해야 합니다. 와일드카드 권한은 피해야 하고 10분 이내에 실행 가능한 점검 결과를 원할 때, 다음 중 보안을 가장 직접적으로 개선하는 두 가지 조치는 무엇입니까? (두 개 선택)
AWS Artifact는 AWS compliance report(예: SOC, ISO)에 대한 on-demand 접근을 제공하고 특정 agreement 수락을 가능하게 합니다. 감사 및 compliance 증빙에는 도움이 되지만, 포털의 보안 상태를 직접 강화하거나 몇 분 내에 빠르고 실행 가능한 기술적 발견 사항을 제공하지는 않습니다. 즉각적인 인증/인가 위험 감소가 아니라 governance에 더 가깝습니다.
모든 IAM role에 가장 광범위한 권한을 부여하는 것은 least privilege 원칙을 위반하며 와일드카드 권한을 피해야 한다는 요구사항과 정면으로 충돌합니다. 과도하게 허용적인 IAM policy는 blast radius를 증가시키며 보안 사고의 흔한 근본 원인입니다. 시험 시나리오에서 광범위한 권한은, 엄격히 범위가 제한된 break-glass access가 명시되지 않는 한, 거의 “보안 개선”이 아닙니다.
“AWS Cloud로 애플리케이션 코드 실행”은 특정 AWS 서비스도 아니고 잘 정의된 보안 조치도 아닙니다. 의도가 AWS CloudShell, AWS Lambda, 또는 AWS Cloud9이라 하더라도, 제시된 제약 조건에서 포털 보안을 강화하는 가장 직접적인 통제는 아닙니다. 이 문제는 즉각적인 보안 개선과 빠른 점검을 요구하는데, 이 선택지는 이를 제공하지 못합니다.
Amazon Cognito에서 MFA를 활성화하면 비밀번호 외 추가 factor를 요구하여 고객 포털의 최종 사용자 account 보안을 직접 개선합니다. Cognito user pool은 MFA(optional 또는 required)를 강제할 수 있으며 TOTP와 SMS를 지원합니다. 핀테크에서는 MFA가 credential stuffing 및 account takeover 위험을 줄이는, third-party 도구 없이도 빠르게 구현 가능한 고효율 통제입니다.
AWS Trusted Advisor security checks는 account 보안을 개선하기 위한 빠르고 우선순위가 있는 권고 사항(예: 노출된 security group, IAM credential hygiene, root account의 MFA)을 제공합니다. 이러한 점검은 실행 가능하며 빠르게 검토할 수 있어 “10분 이내” 요구사항에 부합합니다. 외부 도구를 배포하지 않고도 일반적인 misconfiguration을 식별할 수 있는 AWS-native 메커니즘입니다.
핵심 개념: 이 문제는 AWS 기본 기능을 사용해 실무적으로, 그리고 빠르게 보안을 강화하는 방법을 평가합니다. 핵심 주제는 고객 포털의 identity 보안(Amazon Cognito)과 빠르고 실행 가능한 보안 상태 점검(AWS Trusted Advisor)입니다. 또한 least privilege(와일드카드 권한 회피)와 “유료 third-party 도구 없음”을 강조합니다. 정답이 맞는 이유: D (Amazon Cognito에서 MFA 활성화)는 포털 최종 사용자의 인증을 직접 강화합니다. MFA는 account takeover 위험을 줄이며, 이는 핀테크에서 특히 중요합니다. Cognito는 MFA(SMS 및 TOTP)를 지원하고 user pool policy로 강제할 수 있어, 외부 도구 없이도 빠르게 적용 가능한 고효율 통제입니다. E (AWS Trusted Advisor security checks 사용)는 보통 몇 분 내에 과도하게 허용적인 security group, IAM 사용, 기타 account 수준 위험 등 실행 가능한 보안 발견 사항을 빠르게 제공합니다. 이는 “10분 이내 실행 가능한 점검” 요구사항에 부합하며 third-party 도구를 피할 수 있습니다. 주요 AWS 기능 / Best Practices: - Amazon Cognito MFA: user pool MFA 설정(optional/required) 구성, factor 선택(TOTP는 가능하면 SMS보다 일반적으로 선호), 강력한 password policy 및 해당되는 경우 adaptive authentication 기능과 결합. - Trusted Advisor Security checks: open security group, IAM access key rotation, root account의 MFA 등과 같은 발견 사항을 검토하고 remediation 수행. 일부 점검은 Support plan에 연동되지만, security checks는 빠르고 우선순위가 있는 가이드를 얻는 대표적인 AWS-native 방식입니다. - Least privilege: 문제에서 와일드카드 권한을 명시적으로 배제하며, Trusted Advisor의 remediation 및 Cognito policy 통제는 least-privilege와 강한 identity 경계를 지원합니다. 흔한 오해: AWS Artifact (A)는 compliance report와 agreement에 관한 것으로, 즉각적인 보안 강화가 아닙니다. 광범위한 권한 부여(B)는 least privilege의 반대이며 blast radius를 키웁니다. “AWS Cloud로 애플리케이션 코드 실행”(C)은 구체적인 서비스/조치가 아니며 identity 강화나 빠른 보안 점검을 직접적으로 해결하지 못합니다. 시험 팁: “빠르게 보안 개선”과 “third-party 도구 없음”이 보이면 MFA, IAM least privilege, AWS advisory/보안 상태 서비스(Trusted Advisor, Security Hub, Inspector—문제에 따라) 같은 AWS-native 통제를 찾으세요. 또한 요구사항을 서비스에 매핑하세요: 고객 인증 강화는 Cognito MFA를 강하게 시사하고, “몇 분 내 실행 가능한 점검”은 Trusted Advisor security checks를 시사합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
한 스타트업은 새 레코드가 도착할 때만 실행되는 데이터 처리 함수에 대한 compute 옵션이 필요합니다. 이 함수는 시간당 0에서 10,000회 invocation까지 자동으로 확장되어야 하고, 각 invocation은 최대 15분까지 실행될 수 있어야 하며, 서버를 관리하지 않고 pay-per-request 요금 모델을 사용해야 합니다. 이러한 serverless compute 기능을 제공하는 AWS 서비스는 무엇입니까?
AWS Lambda는 이벤트에 응답하여 코드를 실행하고 수요에 따라 자동으로 확장하는 serverless compute 서비스이며, 유휴 상태일 때 0까지 scale down하는 것도 포함됩니다. pay-per-request 요금( invocation 및 duration 기준)을 지원하고 서버 관리가 필요 없습니다. 시험에서의 핵심 단서는 최대 실행 시간입니다. Lambda functions는 최대 15분까지 실행될 수 있어 요구사항과 정확히 일치합니다.
AWS CloudFormation은 templates를 사용하여 AWS 리소스를 모델링하고 프로비저닝하는 infrastructure-as-code 서비스입니다. event-driven 처리에 대한 compute 실행을 제공하지 않으며 요청당 코드를 실행하지도 않습니다. CloudFormation이 Lambda functions 및 관련 리소스를 배포할 수는 있지만, 데이터 처리 함수를 실행하는 runtime 서비스는 아닙니다.
AWS Elastic Beanstalk는 EC2 instances, Auto Scaling groups, load balancers 같은 리소스를 프로비저닝하여 web applications 배포를 단순화하는 managed application platform입니다. 확장할 수는 있지만 0까지 확장되지 않으며 pay-per-request가 아닙니다. 기본 리소스에 대한 비용을 지불합니다. 또한 순수한 event-driven invocations라기보다 application environments를 관리해야 합니다.
Elastic Load Balancing은 가용성과 fault tolerance를 개선하기 위해 들어오는 network 또는 application 트래픽을 여러 targets(예: EC2 instances, containers, 또는 IPs)로 분산합니다. compute 서비스가 아니며 코드를 실행하지 않습니다. 일부 아키텍처에서 ALB가 Lambda targets로 요청을 라우팅할 수는 있지만, ELB 자체가 여기서 설명된 serverless compute 기능은 아닙니다.
핵심 개념: 이 문제는 AWS serverless compute에 대한 지식을 평가합니다. 특히 event-driven 실행, 자동 확장, 그리고 서버 관리 없이 pay-per-request 요금 모델을 다룹니다. 정답이 맞는 이유: AWS Lambda는 이벤트(예: 스트림, 큐, 또는 데이터베이스에 새 레코드가 도착하는 경우)에 의해 트리거될 때만 코드를 실행하도록 설계된 AWS 서비스입니다. 들어오는 이벤트 수에 따라 자동으로 확장되며, 유휴 상태일 때는 0까지 scale down할 수 있어 새 레코드가 도착할 때만 실행되어야 한다는 요구사항과 일치합니다. Lambda는 pay-per-request 모델(요청 수 + 실행 시간)을 사용하며, 고객은 서버를 프로비저닝하거나 관리하지 않습니다. 또한 각 invocation이 최대 15분까지 실행될 수 있어야 한다는 요구사항은 Lambda의 최대 실행 timeout(15분)과 정확히 일치합니다. 주요 AWS 기능: Lambda는 다양한 event source와 네이티브로 통합됩니다(예: Amazon S3 object events, Amazon SQS messages, Amazon Kinesis 또는 DynamoDB Streams, EventBridge schedules/rules, API Gateway). Concurrency scaling을 통해 대량의 invocation burst를 처리할 수 있으며, 기본적으로 Lambda는 빠르게 확장되고 reserved concurrency로 사용량을 제한하거나 latency에 민감한 워크로드의 cold start를 줄이기 위해 provisioned concurrency로 조정할 수 있습니다. 운영 측면에서 Lambda는 로그를 Amazon CloudWatch Logs로 내보내고, metrics(invocations, errors, duration, throttles)를 CloudWatch로 전송합니다. IAM execution roles는 다른 AWS 서비스에 대한 액세스를 제어하여 least-privilege best practices와 정렬됩니다. 흔한 오해: 일부는 “serverless”를 Elastic Beanstalk 같은 managed platform과 혼동할 수 있지만, Beanstalk는 내부적으로 여전히 EC2 instances를 프로비저닝하고 관리하며 0까지 확장되지 않습니다. CloudFormation은 infrastructure-as-code이지 compute가 아닙니다. Elastic Load Balancing은 트래픽을 분산하지만 코드를 실행하지 않습니다. 시험 팁: event-driven, 0에서 확장, pay-per-request, 관리할 서버 없음, 그리고 최대 runtime 15분을 보면 AWS Lambda를 떠올리세요. runtime이 15분을 초과하거나 장시간 실행되는 workflow가 필요하다면 AWS Step Functions와 ECS/Fargate 또는 EC2 같은 대안을 고려할 수 있지만, 이 제약 조건 세트에서는 Lambda가 정석적인 정답입니다.
직원 1,200명이 있는 한 회사는 외부 SAML 2.0 identity provider(예: Okta)를 사용하며, 7개의 AWS account 전반에서 centralized single sign-on을 사용해 사용자가 기존 corporate credential로 AWS Management Console 및 AWS CLI에 sign in할 수 있어야 하고, 해당 account들에 IAM user 또는 새 password를 생성하지 않아야 합니다. 이 요구 사항을 충족하는 AWS service는 무엇입니까?
AWS Directory Service는 managed directory 기능(AWS Managed Microsoft AD, AD Connector, Simple AD)을 제공하며 AWS resource를 Active Directory와 통합하는 데 도움이 될 수 있습니다. 그러나 Okta와 같은 외부 SAML IdP를 사용해 여러 AWS account의 console 및 CLI에 대한 centralized SSO를 제공하는 주요 service는 아닙니다. Identity ecosystem의 일부가 될 수는 있지만, multi-account AWS access management를 위해 IAM Identity Center를 대체하지는 못합니다.
Amazon Cognito는 application의 end user(customer identity)를 authenticate 및 authorize하기 위해 설계되었으며, app sign-in을 위한 OIDC/SAML federation과 app access를 위한 token 발급을 지원합니다. 여러 AWS account에 걸친 AWS Management Console로의 workforce SSO를 제공하거나 AWS Organizations에서 permission set/role assignment를 관리하도록 의도된 서비스가 아닙니다. 직원의 AWS account access에는 IAM Identity Center가 적합합니다.
AWS IAM Identity Center (formerly AWS SSO)는 여러 AWS account 전반에서 AWS Management Console 및 AWS CLI에 대한 centralized workforce SSO를 위해 설계된 AWS service입니다. AWS Organizations와 통합되며 외부 SAML 2.0 identity provider(예: Okta)를 지원하여 사용자가 corporate credential로 sign in할 수 있게 합니다. 또한 permission set을 사용해 target account에 IAM role을 provision하므로 IAM user와 long-term credential을 피할 수 있습니다.
AWS Resource Access Manager (AWS RAM)는 organization 내 account 간 또는 외부 account와 AWS resource(예: subnet, Transit Gateway, Route 53 Resolver rule)를 공유하는 데 사용됩니다. Authentication, SSO, federation, console/CLI sign-in 기능을 제공하지 않습니다. RAM은 multi-account architecture에 도움이 되지만, 여기서 설명된 centralized identity 및 access sign-on 요구 사항과는 관련이 없습니다.
핵심 개념: 이 문제는 IAM user를 생성하지 않고 여러 AWS account에 걸쳐 federated authentication 및 centralized access management를 수행하는지를 평가합니다. 외부 SAML 2.0 identity provider와 통합되어 AWS Management Console 및 AWS CLI에 대한 workforce single sign-on(SSO)을 제공하는 AWS-native service는 AWS IAM Identity Center입니다. 정답인 이유: AWS IAM Identity Center (formerly AWS SSO)는 AWS Organization 내 여러 AWS account에 대해 centralized SSO를 제공합니다. Okta와 같은 외부 SAML 2.0 IdP에 연결할 수 있어 직원이 기존 corporate credential로 authenticate할 수 있습니다. 이후 사용자는 7개의 AWS account 각각에서 할당된 permission set(역할 기반 access)을 통해 access를 획득합니다. 이를 통해 각 account마다 IAM user를 생성하거나 별도의 password를 관리할 필요가 없으며, console access와 CLI access( IAM Identity Center credential process / SSO token-based session을 통해) 모두를 지원합니다. 주요 AWS 기능: IAM Identity Center는 multi-account 관리를 위해 AWS Organizations와 통합되며, 관리자가 user/group을 account 및 permission set에 중앙에서 할당할 수 있습니다. Permission set은 target account에 자동으로 생성되는 IAM role에 매핑되어 least-privilege access를 가능하게 합니다. 또한 외부 IdP와의 SAML 2.0 federation을 지원하고, account/role 선택을 위한 통합 user portal을 제공합니다. CLI의 경우 short-lived credential과 centralized sign-in flow를 지원하여 보안 모범 사례(최종 사용자에 대한 long-term access key 미사용)에 부합합니다. 흔한 오해: 일부는 SSO에 AWS Directory Service가 필요하다고 생각하지만, 이는 주로 managed Microsoft AD/AD Connector를 제공하며 multi-account AWS console/CLI SSO를 위한 중앙 솔루션은 아닙니다. Amazon Cognito는 workforce의 AWS account access가 아니라 customer identity(app user)를 위한 서비스입니다. AWS RAM은 account 간 resource 공유를 위한 것이지 authentication이 아닙니다. 시험 팁: “external SAML 2.0 IdP”, “AWS Management Console and AWS CLI”, “multiple AWS accounts”, “no IAM users”가 보이면 IAM Identity Center + AWS Organizations + permission set을 떠올리세요. 시나리오가 AWS에 대한 workforce access(앱 sign-in이 아님)라면 Cognito는 보통 정답이 아닙니다.
미디어 스트리밍 회사가 4개의 AWS 계정 전반에서 관리 이벤트와 데이터 이벤트를 모두 기록하기 위해 AWS Organizations organization trail을 사용하고, 90일 보존 기간을 설정하며, 로그를 단일 SSE-S3로 암호화된 Amazon S3 bucket과 실시간 알림을 위해 Amazon CloudWatch Logs로 전달할 때, 이 구현은 주로 어떤 AWS Cloud 설계 원칙에 해당합니까?
정답입니다. AWS Cloud 설계 원칙인 "Enable traceability"는 로그를 수집, 중앙 집중화, 분석하여 팀이 누가 작업을 수행했는지, 언제 발생했는지, 어떤 리소스가 영향을 받았는지 이해할 수 있도록 하는 데 중점을 둡니다. AWS Organizations organization trail은 여러 AWS accounts 전반에서 활동을 일관되게 캡처하도록 특별히 설계되었으며, 이는 multi-account 환경에서 governance와 auditability를 강화합니다. management events와 data events를 모두 기록하면 control-plane 변경과 resource-level access 모두에 대한 가시성이 높아지며, 이는 조사와 compliance에 필수적입니다. 로그를 Amazon S3에 전달하여 내구성 있는 저장을 제공하고 CloudWatch Logs에 전달하여 거의 실시간 alerting을 가능하게 하는 것은 과거 분석과 즉각적인 탐지를 모두 가능하게 함으로써 traceability를 직접적으로 지원합니다.
오답입니다. "Use serverless compute architectures"는 AWS Lambda, AWS Fargate 또는 기타 event-driven managed runtimes와 같은 managed compute services를 사용하여 운영 복잡성을 줄이는 설계 원칙입니다. 이 시나리오는 애플리케이션 compute model이나 서버를 managed execution environments로 대체하는 결정을 설명하지 않습니다. 대신 audit 목적의 logging, retention, encryption, alerting에 초점을 맞추고 있습니다. 이러한 기능은 serverless compute 설계가 아니라 observability와 security traceability에 부합합니다.
오답입니다. "Perform operations as code"는 infrastructure, operational procedures, remediation workflows를 코드로 정의하여 versioning, testing, automation이 가능하도록 하는 것을 의미합니다. organization trail과 관련 리소스는 물론 infrastructure as code를 사용해 배포할 수 있지만, 문제는 구현 자체에 의해 주로 적용되고 있는 원칙이 무엇인지 묻고 있습니다. 이 구현의 주요 결과는 account activity의 중앙 집중식 기록과 모니터링이지, 운영 변경의 자동화가 아닙니다. 따라서 이는 operations as code보다는 traceability로 분류하는 것이 더 적절합니다.
오답입니다. "Go global in minutes"는 AWS의 글로벌 인프라를 활용하여 여러 geographic Regions에 워크로드를 신속하게 배포하고 전 세계 사용자에게 낮은 지연 시간으로 서비스를 제공하는 것에 관한 원칙입니다. 이 시나리오에서 국제적 확장, multi-Region 애플리케이션 제공, 또는 전 세계적으로 분산된 사용자 액세스를 강조하는 내용은 없습니다. 여러 AWS accounts에 대한 언급은 글로벌 배포 전략이 아니라 조직의 governance 경계를 의미합니다. 따라서 이 선택지는 제시된 주요 설계 원칙과 일치하지 않습니다.
핵심 개념: 이 시나리오는 주로 AWS CloudTrail(organization trail)을 사용한 중앙 집중식 로깅, 감사, 모니터링과, 암호화를 적용한 Amazon S3 로그 아카이빙, 그리고 준 실시간 탐지를 위한 Amazon CloudWatch Logs에 관한 것입니다. 이는 거버넌스와 사고 대응을 지원하는 핵심 보안 및 규정 준수 기능입니다. 정답인 이유: AWS Well-Architected Framework의 설계 원칙 “Enable traceability”(Security pillar)는 로그와 지표를 수집·중앙화·분석하여 수행된 작업을 추적하고 조사하며 경고할 수 있도록 하는 것을 강조합니다. AWS Organizations organization trail은 여러 계정에 걸친 API 활동을 기록하며, 관리 이벤트(IAM, EC2, S3 구성 같은 control-plane 작업)와 데이터 이벤트(S3 객체 수준 활동, Lambda invoke 등)를 포함합니다. 정의된 보존 기간과 함께 로그를 중앙 S3 bucket으로 전달하면 감사 가능성과 포렌식 조사를 지원하고, CloudWatch Logs로 스트리밍하면 실시간 경고와 자동화된 대응이 가능합니다. 이러한 선택들은 조직 전반에서 “누가, 무엇을, 언제, 어디서, 어떤 리소스에 대해 수행했는지”를 답할 수 있게 하므로, 추적 가능성을 직접 구현합니다. 주요 AWS 기능: 주요 기능은 다음과 같습니다: (1) 멀티 계정 범위와 중앙 거버넌스를 위한 CloudTrail organization trails; (2) 리소스 접근에 대한 더 깊은 가시성을 위한 management events와 data events; (3) 내구성이 높은 중앙 로그 아카이브로서의 S3; (4) 기본 보안 통제를 충족하기 위한 저장 시 SSE-S3 암호화; (5) 의심스러운 활동에 대해 metric filters/alarms를 생성하고(종종 EventBridge/Lambda를 통해) 작업을 트리거하기 위한 CloudWatch Logs 통합; (6) 규정 준수 요구 사항에 맞추기 위한 보존 설정(참고: CloudTrail 자체가 S3에서 “90일 보존”을 제공하는 것은 아니며, 보존은 일반적으로 S3 lifecycle policies와 CloudWatch Logs retention settings로 강제됩니다). 흔한 오해: Organizations와 trail은 종종 IaC로 배포되므로 “Perform operations as code”를 고를 수 있지만, 질문은 배포 자동화가 아니라 로깅/알림의 결과에 초점을 둡니다. 또한 일부는 CloudWatch를 “serverless”와 연관 지을 수 있으나, CloudWatch는 compute architecture가 아니라 모니터링입니다. “Go global in minutes”는 감사 로깅과 관련이 없습니다. 시험 팁: 계정 전반의 CloudTrail + 중앙 S3 + CloudWatch Logs/alarms 조합을 보면 Security pillar의 traceability로 매핑하세요. 또한 organization trails는 멀티 계정 거버넌스를 위한 표준 패턴이며, 실시간 탐지는 보통 S3 단독 아카이빙이 아니라 CloudWatch Logs/EventBridge를 포함한다는 점을 기억하세요.
한 스타트업이 2개의 t3.micro Amazon EC2 인스턴스, 100 GB의 EBS gp3 스토리지, 그리고 월 1 TB의 데이터 전송(아웃)을 사용하여 웹 앱을 출시할 계획이며, 배포 전에 기존 청구서나 과거 사용량에 접근하지 않고도 예상 월별 요금을 예측할 수 있는 도구를 원한다—이 상황에서 AWS Pricing Calculator는 무엇을 할 수 있는가?
정답. AWS Pricing Calculator는 게시된 AWS 가격을 사용하여 제안된 아키텍처의 월별(또는 연간) 비용을 추정하도록 만들어졌다. 2개의 t3.micro 인스턴스, 100 GB의 gp3 EBS, 1 TB의 데이터 전송 아웃을 입력하고, Region과 구매 옵션을 선택하면, 기존 청구서나 과거 사용량 데이터 없이도 예측된 월별 견적을 받을 수 있다.
오답. 지난 12개월의 과거 비용을 계산하는 것은 AWS Cost Explorer(및 관련 청구 보고서)의 역할이며, 이미 생성된 청구 데이터가 있는 AWS 계정이 필요하다. AWS Pricing Calculator는 과거 사용량을 수집하거나 분석하지 않으며, 미래 워크로드를 위한 계획 및 추정 도구이다.
오답. AWS Pricing Calculator는 AWS 내부 가격 책정 전략(예: AWS가 가격을 설정하는 방식이나 마진 구조)에 대한 분석을 제공하지 않는다. 사용자가 입력한 구성에 공개된 가격을 적용할 뿐이다. “내부 가격 책정 전략”을 언급하는 시험 문제는 보통 오답 유도 선택지이며, AWS는 내부 가격 책정 근거가 아니라 요율과 계산기를 제공한다.
오답. 월별 청구서를 조회하고 다운로드하는 것은 AWS Billing and Cost Management 콘솔(Bills/Invoices)에서 수행하며, Cost and Usage Reports (CUR)로 보완할 수 있다. AWS Pricing Calculator는 계정의 청구 산출물과 연결되어 있지 않으며 실제 인보이스나 청구서를 표시할 수 없다.
핵심 개념: 이 문제는 AWS 비용 추정 도구, 특히 AWS Pricing Calculator에 대한 지식을 평가한다. AWS Pricing Calculator는 AWS 계정, 청구 데이터, 또는 과거 사용량에 접근할 필요 없이 계획된(미래) AWS 사용량에 대한 비용을 추정하도록 설계되었다. 정답이 맞는 이유: 스타트업은 정의된 아키텍처 계획(2개의 t3.micro EC2 인스턴스, 100 GB gp3 EBS, 월 1 TB 데이터 전송 아웃)을 가지고 있으며 배포 전에 예상 월별 요금을 예측하려고 한다. AWS Pricing Calculator는 이러한 입력을 모델링하고, 선택한 Region, 인스턴스 유형, 스토리지 유형/크기, 아웃바운드 데이터 전송에 대한 공개 AWS 가격을 적용하여 추정 월 비용을 산출할 수 있다. 이는 미래 지향적 추정 도구이므로 “기존 청구서나 과거 사용량에 접근하지 않고”라는 요구사항에 부합한다. 주요 AWS 기능: AWS Pricing Calculator는 서비스 전반(예: EC2, EBS, 데이터 전송)에 걸친 견적을 구성하고, Region, 구매 옵션(On-Demand, Savings Plans, Reserved Instances), 그리고 월 사용 시간이나 스토리지 용량 같은 가정을 선택할 수 있도록 지원한다. 공유 가능한 견적을 생성하고 예산 편성을 위해 내보낼 수도 있다. EC2의 경우 OS 라이선싱, tenancy, 활용률 가정을 반영할 수 있으며, EBS gp3의 경우 프로비저닝된 스토리지(및 구성 시 추가 IOPS/throughput 가능)를 고려한다. 데이터 전송의 경우 입력한 GB/TB를 기반으로 인터넷 egress를 추정한다. 흔한 오해: 학습자들은 종종 Pricing Calculator를 AWS Cost Explorer 또는 AWS Bills와 혼동한다. Cost Explorer는 과거 지출과 사용량을 분석하지만, 청구 데이터가 존재하는 AWS 계정이 필요하다. Bills/Invoices는 사용이 발생한 후의 실제 요금을 위한 것이다. 또한 이 계산기는 내부 가격 책정 전략을 공개하지 않으며, 게시된 요율을 사용한다. 시험 팁: 문제에서 “배포 전,” “예측,” 또는 “계획된 리소스 추정”이 나오면 AWS Pricing Calculator를 선택하라. “과거 지출 분석,” “추세,” 또는 “과거 사용량”이 나오면 Cost Explorer(및 필요 시 Budgets)를 선택하라. “인보이스 조회/다운로드”가 나오면 Billing 콘솔 기능을 선택하라. 도구를 시간 범위에 매핑하라: 계획(계산기) vs 실제/과거(청구 도구).
Q3 PCI DSS Level 1 감사를 진행 중인 한 fintech startup은 향후 24시간 이내에, 그리고 support case를 열지 않고, 3개 Region의 5개 production account 전반에서 AWS 보안 통제의 운영 효과성을 검증하는 AWS 제공 PCI 준수 보고서(예: Attestation of Compliance (AOC) 및 Responsibility Summary)를 확보해야 합니다. 회사는 이러한 보고서를 어떻게 확보해야 합니까?
오답입니다. AWS Support는 PCI DSS AOC 및 responsibility summary와 같은 AWS compliance reports를 검색하는 표준 메커니즘이 아닙니다. 문제에서 회사가 support case를 열지 않고 reports를 확보해야 한다고 명시하고 있으므로, 이 선택지는 직접적으로 제외됩니다. 이 제약이 없더라도 AWS는 고객이 필요할 때 즉시 접근할 수 있도록 이러한 문서를 self-service portal을 통해 제공합니다. 시험 관점에서 downloadable compliance reports를 요청하는 경우에는 Support가 아니라 AWS Artifact를 떠올려야 합니다.
정답입니다. AWS Artifact는 AWS 고객이 PCI DSS Attestation of Compliance (AOC) 및 PCI Responsibility Summary와 같은 PCI DSS 문서를 포함한 compliance reports와 agreements에 접근할 수 있는 공식 self-service portal입니다. 이 서비스는 audit 및 compliance use case를 위해 특별히 설계되었으며, support case를 열거나 수동 처리를 기다릴 필요 없이 즉시 다운로드할 수 있습니다. 따라서 여러 AWS accounts와 Regions에 걸친 시간 민감한 PCI DSS audit 요구 사항에 가장 적합합니다. Artifact의 reports는 AWS의 compliance posture와 공유 책임 모델에서 AWS 측 책임을 설명하며, 이는 auditor가 요청하는 바로 그 유형의 AWS 제공 documentation입니다.
오답입니다. AWS Security Hub는 findings를 집계하고 resources를 security standards 및 controls에 대해 평가하는 security posture management 서비스입니다. 고객이 자신의 환경에서 compliance 관련 문제를 모니터링하는 데는 도움이 되지만, PCI DSS AOC 또는 Responsibility Summary와 같은 공식 AWS compliance documents를 배포하지는 않습니다. 이러한 문서는 external audit evidence를 위한 auditor-issued 또는 AWS-published reports이며 AWS Artifact를 통해 접근합니다. 시험에서 흔한 함정은 compliance monitoring 도구와 compliance documentation repository를 혼동하는 것입니다.
오답입니다. technical account manager는 가이드를 제공하고 AWS 리소스와의 조율을 도울 수 있지만, 공식 compliance reports를 전달하는 채널은 아닙니다. 많은 AWS 고객은 TAM이 아예 없으며, 사람에게 의존하는 방식은 즉각적인 self-service retrieval 요구 사항도 충족하지 못합니다. 문제의 제약 조건은 회사가 AWS personnel에게 연락하는 대신 AWS console 기반 서비스를 사용해야 함을 강하게 시사합니다. AWS Artifact는 바로 이 요구를 위해 만들어진 전용 서비스입니다.
핵심 개념: 이 문제는 AWS compliance reporting에 대한 지식과 AWS가 third-party audit artifact를 어디에 게시하는지에 대한 이해를 평가합니다. 핵심 서비스는 AWS Artifact이며, 이는 AWS compliance reports(예: PCI DSS AOC)와 agreements에 on-demand access를 제공하는 AWS의 self-service portal입니다. 정답인 이유: PCI DSS Level 1 audit의 경우, 회사는 AWS-managed controls의 operating effectiveness를 입증하는 AWS 제공 evidence(공유 책임 모델의 “AWS 측”)가 필요합니다. AWS Artifact는 고객이 PCI DSS Attestation of Compliance (AOC) 및 PCI Responsibility Summary와 같은 compliance reports를 즉시 다운로드할 수 있도록 특별히 설계되었습니다. support case를 열지 않고도 사용할 수 있으며 빠르게(수분 내) 접근할 수 있어 “24시간 이내”라는 제약 조건을 충족합니다. 이러한 reports는 service configuration evidence처럼 account 또는 Region별로 특정되지 않으며, 여러 accounts와 Regions 전반에서 고객이 사용할 수 있는 AWS 전체 범위의 audit reports입니다. 주요 AWS 기능: AWS Artifact는 다음을 제공합니다: - Reports: independent auditors가 발행한 downloadable compliance reports(PCI DSS AOC, SOC, ISO 등). - Agreements: 특정 compliance 관련 agreements를 검토/수락할 수 있는 기능. - Centralized access: external audits에 사용할 AWS audit documentation를 검색할 수 있는 단일 위치. 이는 AWS compliance best practices 및 공유 책임 모델과 일치합니다. 즉, AWS는 AWS-managed controls에 대한 evidence를 제공하고, 고객은 자신의 configurations 및 processes에 대한 evidence를 제공합니다. 일반적인 오해: Security Hub는 종종 compliance-reporting portal로 오해되지만, 실제로는 security findings를 집계하고 controls를 standards에 매핑할 수 있는 서비스입니다. auditor가 발행한 AOC를 제공하지는 않습니다. 마찬가지로 “Support에 문의”하거나 TAM에게 요청하는 것이 가장 빠른 방법처럼 보일 수 있지만, 문제에서는 support case를 여는 것을 명시적으로 금지하고 즉각적인 self-service access를 요구합니다. 시험 팁: “AWS compliance reports 다운로드”, “AOC”, “SOC reports”, “ISO reports”, 또는 “responsibility summary”를 보면 정답은 거의 항상 AWS Artifact입니다. 문제가 continuous compliance posture, findings, 또는 control monitoring에 관한 것이라면 대신 Security Hub/AWS Config를 떠올리세요. 또한 “support case 불가”와 같은 제약 조건은 self-service console 기능(Artifact)을 강하게 시사합니다.
학습 기간: 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를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.