연습 문제

문제 1

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

문제 분석

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

문제 2

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

문제 분석

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

문제 3

6명으로 구성된 엔지니어링 팀을 가진 한 원격의료(telehealth) 스타트업은 10일 이내에 실시간 데이터 처리 파이프라인의 3가지 버전을 프로토타이핑해야 하며, 장기 인프라에 커밋하지 않고 결과에 따라 방향을 전환(pivot)해야 합니다. 이들이 프로세스와 아키텍처에 민첩성(agility)을 가장 직접적으로 내재화하는 데 도움이 되는 AWS Cloud 기능은 무엇입니까?

문제 분석

핵심 개념 - 이 문제는 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 관련 선택지가 더 유력해집니다.

문제 4

한 핀테크 회사가 us-west-2의 Amazon RDS에서 PostgreSQL 워크로드를 실행하고 있으며, AZ 장애 동안 데이터 손실 없이(RPO 0) RTO를 60초 미만으로 달성해야 합니다. 이를 위해 AWS가 기본(primary) DB 인스턴스와 동일 Region 내 다른 Availability Zone에 있는 대기(standby)를 자동으로 프로비저닝하고, 지속적인 synchronous replication과 automatic failover를 제공해야 합니다. 어떤 RDS 기능을 활성화해야 합니까?

문제 분석

핵심 개념: 이 문제는 단일 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)를 구분하세요.

문제 5

(2개 선택)

월간 활성 사용자 120,000명의 핀테크 스타트업이 Amazon Cognito로 지원되는 고객 포털을 출시하고 있으며, 유료 third-party 도구를 추가하지 않고 AWS 보안을 빠르게 강화해야 합니다. 와일드카드 권한은 피해야 하고 10분 이내에 실행 가능한 점검 결과를 원할 때, 다음 중 보안을 가장 직접적으로 개선하는 두 가지 조치는 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 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를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

한 스타트업은 새 레코드가 도착할 때만 실행되는 데이터 처리 함수에 대한 compute 옵션이 필요합니다. 이 함수는 시간당 0에서 10,000회 invocation까지 자동으로 확장되어야 하고, 각 invocation은 최대 15분까지 실행될 수 있어야 하며, 서버를 관리하지 않고 pay-per-request 요금 모델을 사용해야 합니다. 이러한 serverless compute 기능을 제공하는 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 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가 정석적인 정답입니다.

문제 7

직원 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는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 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는 보통 정답이 아닙니다.

문제 8

미디어 스트리밍 회사가 4개의 AWS 계정 전반에서 관리 이벤트와 데이터 이벤트를 모두 기록하기 위해 AWS Organizations organization trail을 사용하고, 90일 보존 기간을 설정하며, 로그를 단일 SSE-S3로 암호화된 Amazon S3 bucket과 실시간 알림을 위해 Amazon CloudWatch Logs로 전달할 때, 이 구현은 주로 어떤 AWS Cloud 설계 원칙에 해당합니까?

문제 분석

핵심 개념: 이 시나리오는 주로 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를 포함한다는 점을 기억하세요.

문제 9

한 스타트업이 2개의 t3.micro Amazon EC2 인스턴스, 100 GB의 EBS gp3 스토리지, 그리고 월 1 TB의 데이터 전송(아웃)을 사용하여 웹 앱을 출시할 계획이며, 배포 전에 기존 청구서나 과거 사용량에 접근하지 않고도 예상 월별 요금을 예측할 수 있는 도구를 원한다—이 상황에서 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 실제/과거(청구 도구).

문제 10

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 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)을 강하게 시사합니다.

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(22)

다른 모의고사

Practice Test #2

Practice Test #3

Practice Test #4

지금 학습 시작하기