연습 문제

문제 1

미디어 회사의 솔루션 리드는 다음 1시간 이내에 10,000 requests per second를 목표로 하고 multi-Region disaster recovery(RPO 15 minutes, RTO 1 hour)를 갖춘 multi-tier serverless video-metadata API를 위한 검증된 AWS reference architectures와 design diagrams를 찾아야 한다. AWS Cloud solution designs의 예시를 어디에서 찾아야 하는가?

문제 분석

핵심 개념: 이 문제는 검증된 AWS reference architectures, design patterns, 그리고 diagrams를 어디에서 찾는지 평가한다. 핵심 리소스는 AWS Architecture Center로, AWS Well-Architected Framework, reference architectures, 그리고 architecture diagrams를 포함한 공식 및 파트너 검증 아키텍처 가이던스를 큐레이션한다. 정답이 맞는 이유: 솔루션 리드는 multi-tier serverless API를 고규모(10,000 RPS)로, 그리고 multi-Region disaster recovery 목표(RPO 15 minutes, RTO 1 hour)에 맞춰 빠르게(다음 1시간 이내) 예시가 필요하다. AWS Architecture Center는 이를 위해 특별히 설계되었다. 미디어를 포함한 산업 전반과 serverless, high availability, disaster recovery 같은 요구사항 전반에 걸친 solution patterns와 reference architectures를 제공한다. 소프트웨어를 구매하거나 내부 catalog를 설정할 필요 없이 “AWS reference architectures와 design diagrams”를 찾을 수 있는 가장 직접적인 장소다. 그곳에서 기대할 수 있는 주요 AWS 기능/가이던스: Architecture Center 및 관련 공식 가이던스에서는 일반적으로 API Gateway + Lambda + DynamoDB/Aurora Serverless 같은 serverless API 패턴, CloudFront/ElastiCache를 통한 caching, SQS/SNS/EventBridge를 통한 asynchronous ingestion, 그리고 Route 53 health checks/failover, DynamoDB global tables 또는 Aurora Global Database, cross-Region replication을 활용한 multi-Region DR 접근 방식(active-active 또는 active-passive) 등을 찾을 수 있다. RPO 15 minutes를 위해서는 near-real-time replication 옵션을, RTO 1 hour를 위해서는 automated failover runbooks와 infrastructure-as-code를 확인하게 된다. 흔한 오해: AWS Marketplace에도 listing에 “reference architectures”가 포함될 수 있지만, 주 목적은 third-party software 및 solutions 구매이며, 큐레이션된 AWS design diagrams를 제공하는 곳이 아니다. AWS Service Catalog는 조직 내에서 내부적으로 승인된 products/blueprints를 배포하기 위한 것이지, 공개 AWS reference architectures를 발견하기 위한 것이 아니다. Trusted Advisor는 account별 best-practice checks(cost, security, fault tolerance 등)를 제공하는 것이지 architecture diagrams를 제공하지 않는다. 시험 팁: 문제가 “AWS reference architectures, solution designs, diagrams를 어디에서 찾는가”를 묻는다면 기본적으로 AWS Architecture Center(그리고 종종 Well-Architected Framework)를 떠올려라. third-party solutions 구매라면 Marketplace, 내부 표준화된 deployments라면 Service Catalog, account 최적화 점검이라면 Trusted Advisor를 생각하면 된다.

문제 2

한 대학 연구실은 3개의 프로젝트에 걸쳐 150명의 IAM user가 있는 단일 AWS account를 사용하며, 분기별 컴플라이언스 점검을 수행하여 각 user에 대해 마지막 password 변경 날짜와 활성 access key 중 90일을 초과한 것이 있는지 여부를 확인해야 합니다. 또한 감사자는 모든 user에 대한 이러한 세부 정보를 나열한 다운로드 가능한 CSV를 요구합니다. 이 요구 사항을 충족하는 AWS service 또는 tool은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 credential 위생 및 컴플라이언스 증빙을 위한 AWS IAM account 수준의 reporting 지식을 평가합니다. 특히 account 내 모든 IAM user에 대해 password 및 access key age 세부 정보를 포함하는 감사 가능하고 내보낼 수 있는 report를 생성하는 데 초점을 둡니다. 정답이 맞는 이유: IAM credential report는 정확히 이 요구 사항을 위해 만들어졌습니다. 모든 IAM user와 주요 credential metadata를 나열하는 다운로드 가능한 CSV를 생성하며, 여기에는 마지막 password 변경 날짜와 access key의 age/status가 포함됩니다. 감사자가 모든 user(150명)에 대한 CSV를 요구하고 연구실이 분기별로 password 및 90일을 초과한 access key를 점검해야 하므로, credential report는 다운로드하여 검토하거나(예: Excel에서) 필터링해 비준수 user 및 key를 식별할 수 있는 단일 표준 산출물을 제공합니다. 주요 AWS 기능: IAM credential report는 account 수준에서 생성되며 password_last_changed, password_enabled, access_key_1_active, access_key_1_last_rotated, access_key_2_active, access_key_2_last_rotated 같은 필드를 포함합니다. 이를 통해 “last_rotated” 날짜를 현재 날짜와 비교하여 활성 access key가 90일을 초과했는지 여부를 쉽게 판단할 수 있습니다. report는 CSV 형식으로 제공되어 감사자의 “다운로드 가능한 CSV” 요구 사항을 충족합니다. IAM console 또는 AWS CLI/API(GenerateCredentialReport 및 GetCredentialReport)로 생성할 수 있어 분기별 자동화에도 유용합니다. 흔한 오해: IAM Access Analyzer와 AWS Audit Manager는 종종 “auditing”과 연관되지만, user별 password 변경 날짜와 access key age를 나열한 CSV를 직접 생성하지는 않습니다. AWS Artifact 역시 컴플라이언스와 관련이 있지만, 이는 AWS(서비스 제공자)의 컴플라이언스 report를 제공하는 것이지, 귀하의 account의 IAM user credential 상태를 제공하는 것이 아닙니다. 시험 팁: “모든 IAM user 나열”, “마지막 password 변경”, “access key age/rotation”, “다운로드 가능한 CSV” 같은 요구 사항이 보이면 즉시 “IAM credential report”를 떠올리십시오. Access Analyzer는 resource access policy 및 외부 access finding을 위한 것이고, Audit Manager는 단순한 IAM credential inventory export가 아니라 framework에 대한 더 광범위한 evidence 수집을 위한 것입니다.

문제 3

한 리테일 분석 팀이 us-east-1의 7개 Amazon S3 bucket에 걸쳐 약 6TB의 CSV 및 JSON 파일을 저장하고 있으며, 이름과 16자리 신용카드 번호 같은 민감 데이터를 자동으로 탐지하고 분류하며, object별로 finding을 생성하고, 어떤 인프라도 배포하지 않고 예약 스캔을 지원하는 완전 관리형 서비스가 필요합니다. 어떤 AWS 서비스를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon S3를 위한 AWS 관리형 데이터 보안 서비스—특히 object 내 민감 데이터(PII/PCI)의 자동 탐지 및 분류, finding 생성, 예약 스캔—에 대한 지식을 평가합니다. 정답이 맞는 이유: Amazon Macie는 Amazon S3에 저장된 민감 데이터를 탐지, 분류, 보호하도록 설계된 완전 관리형 서비스입니다. 머신 러닝과 패턴 매칭을 사용하여 CSV 및 JSON 같은 일반적인 형식에서 이름과 신용카드 번호(예: 16-digit PAN) 같은 데이터를 식별합니다. Macie는 여러 bucket을 평가하고, object별 finding(예: bucket, object key, 탐지된 데이터 유형 포함)을 생성하며, 어떤 인프라 배포 없이 예약/반복 job을 지원합니다. 이는 “민감 데이터 자동 탐지 및 분류”, “object별 finding 생성”, “여러 S3 bucket에 대한 예약 스캔 지원” 요구사항과 정확히 일치합니다. 주요 AWS 기능: Macie는 S3 inventory 및 자동 민감 데이터 탐지, 관리형 data identifier(일반적인 PII/PCI에 대한 내장), 그리고 조직별 패턴을 위한 custom data identifier(regex/키워드)를 제공합니다. Finding은 Amazon EventBridge로 전송되고 Macie console에서 확인할 수 있으며, 티켓팅/SIEM 워크플로로 라우팅할 수 있습니다. Macie는 AWS Organizations와 통합되어 멀티 계정 활성화를 지원하고, S3 bucket 선택 및 job 정의(일회성 또는 예약)를 통해 범위를 지정할 수 있습니다. 이는 AWS Well-Architected Security Pillar 가이드에 부합하는 최소 운영(least-ops), serverless 보안 태세를 지원합니다. 흔한 오해: GuardDuty도 “finding”을 생성하기 때문에 종종 혼동되지만, object 내부의 민감 데이터를 분류하는 것이 아니라 위협(악성 활동/이상 징후)을 탐지합니다. Inspector는 S3 데이터 분류가 아니라 compute 및 container image에 대한 취약점 관리에 초점을 둡니다. IAM Access Analyzer는 접근 정책과 외부 접근 경로를 분석하는 데 도움을 주며, 콘텐츠 검사 기능은 아닙니다. 시험 팁: “S3”, “PII/PCI”, “discover/classify”, “sensitive data”, “scheduled scans/jobs”가 보이면 정답은 거의 항상 Amazon Macie입니다. 문제가 “threat detection” 또는 “anomalous API calls”를 강조하면 GuardDuty를, “vulnerabilities/CVEs”를 강조하면 Inspector를, “public/cross-account access analysis”를 강조하면 IAM Access Analyzer를 떠올리세요.

문제 4

us-east-1 및 eu-west-1의 Amazon ECS에서 40개의 microservices를 실행하는 미디어 analytics startup이 KMS customer managed key로 암호화된 12개의 third-party API key와 database password를 저장할 수 있는 중앙에서 관리되는 방식이 필요하며, tasks가 런타임에 세분화된 IAM permissions로 이러한 credentials를 programmatically retrieve할 수 있고 30일마다 자동 rotation이 되어야 합니다. 어떤 AWS service 또는 feature를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 애플리케이션을 위한 managed secret storage, AWS KMS customer managed keys (CMKs)를 사용한 암호화, compute(ECS tasks)에서의 세분화된 IAM access, 그리고 내장된 automatic rotation을 테스트합니다. 이를 위해 특별히 설계된 AWS 서비스는 AWS Secrets Manager입니다. 정답인 이유: AWS Secrets Manager는 third-party API keys 및 database passwords와 같은 민감한 값을 위한 중앙 집중식 저장소를 제공하고, AWS KMS(고객 관리형 키 포함)를 사용하여 저장 시 secrets를 암호화하며, 런타임에 AWS SDK/CLI/API를 통한 프로그래밍 방식의 retrieval을 제공합니다. ECS tasks는 최소 권한 permissions를 가진 IAM task role(예: 특정 secret ARN에 대한 secretsmanager:GetSecretValue)을 사용하여 secrets를 안전하게 retrieval할 수 있습니다. 또한 Secrets Manager는 AWS Lambda rotation functions를 사용하여 일정(예: 30일마다)에 따른 automatic rotation을 지원하며, 이는 문제의 직접적인 요구 사항입니다. 주요 AWS 기능: - KMS CMK encryption: 각 secret이 특정 customer managed key를 사용하도록 구성하고, key policies 및 grants를 적용할 수 있습니다. - Fine-grained IAM: IAM policies 및 secrets에 대한 resource-based policies를 사용하여 secret별, environment별, 또는 service별로 access를 제한할 수 있습니다. - Runtime retrieval: ECS는 Secrets Manager와 잘 통합되며, tasks는 시작 시 또는 필요 시 SDK를 사용하여 secrets를 가져올 수 있고, ECS secret options를 통해 secrets를 environment variables로 주입할 수도 있습니다. - Automatic rotation: Lambda를 사용한 기본 rotation scheduling을 지원하며, 일반적인 databases를 위한 AWS 제공 templates도 포함됩니다. 30일마다 rotation하는 것은 표준적인 패턴입니다. - Multi-Region considerations: 워크로드가 us-east-1 및 eu-west-1에서 실행되므로, 일반적으로 각 region에 secrets를 생성하거나(또는 복제를 위해 Secrets Manager multi-Region secrets를 사용) 지연 시간을 줄이고 복원력을 향상시키면서 중앙 집중식 governance를 유지합니다. 일반적인 오해: 일부는 “encryption”이 AWS Encryption SDK를 의미한다고 생각할 수 있지만, 이는 client-side cryptography library이며 중앙 집중식 secret lifecycle management나 rotation을 제공하지 않습니다. 또 다른 경우로 Security Hub를 secret management와 혼동할 수 있는데, 이는 credentials를 저장하는 것이 아니라 security findings를 집계합니다. AWS Artifact는 compliance reports 및 agreements를 위한 것이며, runtime secrets를 위한 서비스가 아닙니다. 시험 팁: “credentials를 중앙에서 저장”, “IAM으로 런타임에 retrieval”, “KMS CMK로 암호화”, 그리고 특히 “automatic rotation”과 같은 요구 사항이 보이면 AWS Secrets Manager를 우선 떠올리세요. rotation이 필요 없고 단순한 parameter storage 요구 사항이라면 AWS Systems Manager Parameter Store도 고려할 수 있지만, 여기서는 rotation이 핵심적인 차별점입니다.

문제 5

한 지방자치단체 기록 보관소는 7년 동안 보관해야 하는 규정 준수 PDF 80 TB를 아카이브하고 있으며, 외부 감사인이 연 2회만 접근합니다. 하지만 감사가 발생하면 파일을 가능한 한 가장 낮은 스토리지 비용으로 밀리초 단위로 검색할 수 있어야 합니다. 어떤 Amazon S3 storage class를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 접근 패턴, 검색 지연 시간, 보관 기간, 비용 최적화를 기반으로 Amazon S3 storage class를 선택하는 능력을 평가합니다. 핵심 요구사항은 “밀리초 단위 검색”을 유지하면서, 거의 접근하지 않는(연 2회) 데이터를 7년 동안 보관하는 데 “가능한 한 가장 낮은 스토리지 비용”을 달성하는 것입니다. 정답이 맞는 이유: Amazon S3 Glacier Instant Retrieval은 장기간 보관되며 거의 접근하지 않는 데이터이지만, 요청 시 즉시(밀리초) 접근이 필요할 때를 위해 설계되었습니다. Glacier 계열의 낮은 스토리지 비용 특성을 제공하면서도, 다른 Glacier 옵션(예: Flexible Retrieval 또는 Deep Archive)에서 발생하는 수분~수시간의 복원 지연을 피할 수 있습니다. 감사 시에만 접근하는 규정 준수 PDF의 경우, 접근은 매우 드물지만 접근이 발생하면 감사인이 거의 실시간에 가까운 검색을 기대하므로 이 패턴에 정확히 부합합니다. 주요 AWS 기능: S3 Glacier Instant Retrieval은 밀리초 단위 검색, 높은 내구성(11 9s)을 제공하며, 표준 S3 APIs(GET/PUT/HEAD, lifecycle policies, IAM, bucket policies)와 통합됩니다. S3 Lifecycle rules를 사용해 수집 후 객체를 Glacier Instant Retrieval로 전환할 수 있고, 선택적으로 규정 준수 보관 제어를 위해 S3 Object Lock(WORM)을 적용할 수 있습니다. 비용 측면에서는 S3 Standard보다 낮은 스토리지 비용을 지불하고, 감사가 발생할 때 검색 요금이 부과되는데—연 2회 접근 패턴에서는 적절합니다. 흔한 오해: 많은 사람들이 S3 Intelligent-Tiering이 항상 알 수 없는 접근 패턴에 최선이라고 가정합니다. 하지만 Intelligent-Tiering은 객체당 모니터링/자동화 요금이 추가되며, 접근 빈도가 예측 불가능할 때 가장 가치가 큽니다. 여기서는 패턴이 명확히 “드문 접근”이므로, 일반적으로 Glacier class가 더 저렴합니다. 또 다른 오해는 성능을 위해 S3 Standard를 선택하는 것입니다. S3 Standard는 밀리초 접근을 제공하지만, 7년 아카이브에 대해 가장 낮은 스토리지 비용은 아닙니다. 시험 팁: “아카이브/수년 보관” + “드문 접근” + “밀리초 단위로 검색해야 함”을 보면 S3 Glacier Instant Retrieval을 떠올리세요. 반대로 “수분/수시간을 기다릴 수 있음”이라고 했다면 Glacier Flexible Retrieval 또는 Deep Archive가 후보가 됩니다. 항상 접근 빈도(드묾), 검색 시간 목표(밀리초), 비용 목표(지연 시간을 충족하는 범위 내 최저 스토리지 비용)를 매핑하세요.

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

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

문제 6

SOC 2 Type II 검토를 준비 중인 한 fintech 회사는 15분 이내에, 그리고 support case를 열지 않고, 외부 감사인에게 공유하기 위해 AWS에서 발행한 compliance report(예: ISO/IEC 27001 certificates 및 PCI DSS Attestation of Compliance v4.0)와 third-party attestation을 us-east-1, eu-west-1, ap-southeast-2에서 운영 중인 8개 business unit 전반에 걸쳐 다운로드해야 합니다. 이러한 문서를 필요 시 중앙에서 self-service 방식으로 온디맨드 제공하기 위해 어떤 AWS service를 사용해야 합니까?

문제 7

한 핀테크 스타트업은 결제 API를 배포해야 하며, 모든 compute 및 storage가 U.S. Midwest 내에 유지되고 선택한 위치가 Ohio주 Columbus에서 500마일 이내여야 합니다. 또한 fully managed AWS services를 사용하고 해당 위치에서 최소 두 개의 격리된 fault domain을 제공해야 합니다. 이 요구 사항을 충족하기 위해 특정 지리적 위치(예: Ohio의 us-east-2)를 선택할 수 있도록 해주는 AWS global infrastructure의 기능은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS Global Infrastructure 개념인 Regions, Availability Zones (AZs), 그리고 AWS의 전 세계적 존재(“global footprint”)가 고객이 데이터 상주(data residency), 지연 시간(latency), 규제 요구 사항을 위해 특정 지리적 위치를 선택할 수 있게 해준다는 점을 이해하는지를 평가합니다. 정답이 맞는 이유: 요구 사항은 compute와 storage를 U.S. Midwest 내, 그리고 Ohio주 Columbus에서 500마일 이내에 유지하면서 fully managed services를 사용하고 최소 두 개의 격리된 fault domain을 제공하는 것입니다. us-east-2 (Ohio)와 같은 특정 지리적 위치를 선택할 수 있게 해주는 AWS의 기능은 AWS의 global footprint입니다. AWS는 전 세계에 여러 Regions를 운영하며, 고객은 리소스가 배포될 Region을 명시적으로 선택합니다. us-east-2 Region을 선택함으로써 스타트업은 해당 지리적 영역에서 서비스가 프로비저닝되도록 보장하여 상주/주권(residency/sovereignty) 및 근접성 제약을 충족할 수 있습니다. 주요 AWS 기능: 선택한 Region 내에서 AWS는 여러 Availability Zones를 제공하는데, 이는 전력, 냉각, 네트워킹이 독립적인 물리적으로 분리된 격리 fault domain입니다. us-east-2에서 최소 두 개의 AZ에 걸쳐 배포하면 동일한 지리적 Region 내에 머무르면서 “두 개의 격리된 fault domain” 요구 사항을 충족합니다. 많은 fully managed services(예: Amazon RDS Multi-AZ, Amazon DynamoDB, Amazon S3, AWS Lambda, Amazon API Gateway)는 Region 범위(Region-scoped)이며 Multi-AZ 복원력으로 구성할 수 있거나(또는 본질적으로 multi-AZ) 고가용성 및 fault isolation 모범 사례에 부합합니다. 흔한 오해: “가용성”은 AZ가 fault isolation을 제공하므로 정답처럼 보일 수 있지만, 이 문제는 특정 지리적 위치(Region)를 선택하게 해주는 것이 무엇인지 묻고 있으며, 그 안에서 중복성을 달성하는 방법을 묻는 것이 아닙니다. “성능”과 “확장성”은 AWS 인프라의 이점이지만, 지리적 배포 위치를 선택하는 메커니즘을 설명하지는 않습니다. 시험 팁: us-east-2 같은 위치 선택이 언급되면 “Region”과 AWS global footprint를 떠올리십시오. “두 개의 격리된 fault domain”이 언급되면 Region 내의 “Availability Zones”를 떠올리십시오. 상주/주권 제약의 경우 기본 제어는 Region 선택이며, 해당 Region 내부의 복원력은 Multi-AZ 설계와 AZ 중복을 지원하는 managed services를 사용해 달성합니다. 참고: AWS Global Infrastructure 문서(Regions 및 Availability Zones)와 AWS Well-Architected Reliability pillar(fault isolation 및 multi-AZ 설계).

문제 8

온라인 티켓팅 스타트업이 평상시에는 분당 800건의 요청이 들어오다가, 대형 콘서트 티켓 판매가 시작되면 90분 동안 분당 24,000건의 요청으로 트래픽이 급증하는 것을 확인했습니다. 이들은 과도하게 구매하지 않고 필요한 만큼만 프로비저닝할 수 있도록 플랫폼이 실시간으로 자동으로 compute capacity를 추가하고 제거하길 원합니다. 이 요구 사항을 충족하는 cloud computing의 이점은 무엇입니까?

문제 분석

핵심 개념 - 이 문제는 AWS Cloud의 가치 제안 중 elasticity와 capacity를 동적으로 right-size할 수 있는 능력을 테스트합니다. AWS 시험 용어로는 일반적으로 “Stop guessing capacity”로 표현되는 cloud advantage에 해당하며, 이는 예측과 과다 프로비저닝에 의존하는 대신 실제 수요에 따라 리소스를 확장/축소하는 것을 의미합니다. 정답인 이유 - 이 스타트업은 매우 가변적이고 스파이크 형태의 트래픽(분당 800에서 24,000으로, 짧은 90분 구간)을 겪습니다. 이들은 필요한 만큼만 프로비저닝하기 위해 compute capacity가 실시간으로 자동 추가/제거되길 원합니다. 이는 바로 “stop guessing capacity” 이점에 해당합니다. elastic services를 사용해 수요에 맞춰 공급을 조정할 수 있으므로, 성능 리스크(과소 프로비저닝)와 낭비(과다 프로비저닝)를 모두 줄일 수 있습니다. 주요 AWS 기능 - 실제로 이 요구 사항은 보통 Amazon EC2 Auto Scaling(대개 Elastic Load Balancer 뒤에 배치)으로 구현하며, CPU utilization, request count per target (ALB), 또는 custom Amazon CloudWatch metrics 같은 지표 기반 scaling policies를 사용합니다. 또는 AWS Lambda 같은 serverless 옵션이나 Amazon ECS/Fargate 같은 container 플랫폼도 자동으로 확장할 수 있습니다. 아키텍처 원칙은 monitoring과 automation(CloudWatch alarms, target tracking, 알려진 이벤트에 대한 scheduled scaling)과 결합된 elasticity(scale out/in)입니다. 흔한 오해 - “Trade fixed expense for variable expense”는 CapEx에서 OpEx로 전환하고 pay-as-you-go billing을 사용하는 것에 관한 내용입니다. 관련은 있지만, 이 문제는 실시간 자동 scaling과 capacity 과다 구매 방지에 초점을 두므로 더 직접적으로는 “stop guessing capacity”가 맞습니다. “Benefit from massive economies of scale”는 집계된 수요로 인해 AWS가 더 낮은 단가를 제공할 수 있다는 의미이지, 동적 scaling을 의미하지는 않습니다. “Go global in minutes”는 글로벌 인프라를 활용한 빠른 지리적 확장에 관한 것으로, 단기간 수요 스파이크 처리와는 다릅니다. 시험 팁 - “traffic surge”, “automatically add and remove capacity”, “real time”, “only what is needed” 같은 키워드가 보이면 elasticity와 Auto Scaling을 떠올리고, 이를 cloud advantage “Stop guessing capacity”에 매핑하세요. 반대로 예산/CapEx vs OpEx에 초점이 있다면 보통 “Trade fixed expense for variable expense”가 가장 적절한 선택입니다.

문제 9

단일 AWS Organizations 구성 아래 12개의 AWS 계정을 보유한 한 엔지니어링 회사는 350명의 직원에 대해 로그인과 계정별 permission set을 중앙에서 관리해야 합니다. 사용자가 각 계정에 IAM user를 생성하지 않고도 single sign-on으로 여러 계정에 액세스할 수 있어야 합니다. 이 요구 사항을 충족하기 위해 회사는 어떤 AWS 서비스 또는 기능을 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 AWS Organizations 내 여러 AWS 계정 전반에서 workforce identity 및 access management를 중앙에서 수행하는 것을 테스트하며, 특히 각 계정에 IAM user를 생성하지 않고 single sign-on(SSO)을 활성화하고 계정별 permission set을 관리하는 요구 사항을 다룹니다. 정답이 맞는 이유: AWS IAM Identity Center(이전 AWS SSO)는 여러 AWS 계정과 애플리케이션에 대한 사용자 액세스를 중앙에서 관리하도록 목적에 맞게 설계되었습니다. IAM Identity Center를 AWS Organizations와 통합하면 관리자는 특정 member account에 대해 사용자 및 그룹에 permission set(IAM policy의 모음)을 생성하고 할당할 수 있습니다. 사용자는 IAM Identity Center 포털에 한 번만 로그인한 뒤 role-based access를 통해 여러 계정에 액세스할 수 있으므로, 각 계정에 IAM user를 프로비저닝할 필요가 없습니다. 주요 AWS 기능: IAM Identity Center는 중앙 directory를 제공하거나(SAML 2.0을 통해 Azure AD/Okta 같은 외부 IdP에 연결 가능), SSO를 위한 user portal과 target account에 자동으로 IAM role로 프로비저닝되는 permission set을 제공합니다. 또한 세분화된 할당(user/group + permission set + account), session duration 제어, MFA 통합(identity source에 따라 다름), AWS CloudTrail을 통한 중앙 감사 기능을 지원합니다. 이는 AWS Well-Architected Security Pillar의 모범 사례(연동(federation) 사용, least privilege, 중앙 집중식 identity management)와 일치합니다. 흔한 오해: AWS STS는 “temporary credentials” 및 cross-account access와 자주 연관되지만, STS는 구성 요소(building block)일 뿐 중앙 SSO 및 permission-set 관리 솔루션은 아닙니다. Access Analyzer는 resource access 및 policy 분석을 위한 것이지 사용자 로그인용이 아닙니다. Secrets Manager는 secret을 저장하고 rotation하는 서비스로, workforce SSO를 관리하지 않습니다. 시험 팁: “multiple accounts”, “AWS Organizations”, “central management”, “permission sets”, “single sign-on without IAM users”가 보이면, 시험에서는 거의 항상 IAM Identity Center를 가리킵니다. 용어를 기억하세요: permission set은 IAM Identity Center의 구성 요소이며 각 계정에서 IAM role로 생성됩니다. 문제가 외부 기업 directory를 언급한다면, IAM Identity Center + 외부 IdP 통합을 떠올리면 됩니다.

문제 10

(2개 선택)

한 소매 회사는 본사 대역 198.51.100.0/24 및 파트너 VPN 대역 203.0.113.16/28에서의 웹 액세스를 허용해야 하며, 액세스 규칙을 구성할 때 CIDR 표기법을 사용하여 이러한 대역을 직접 지정하려고 합니다. IP 주소 범위를 CIDR block 형식으로 입력할 수 있도록 지원하는 AWS 네트워크 서비스 또는 기능은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 CIDR 표기법의 IP 범위를 사용하여 허용/거부 트래픽 소스를 정의할 수 있는 AWS 네트워킹 제어가 무엇인지 평가합니다. AWS에서 VPC 수준의 IP 기반 필터링을 위한 주요 구성 요소는 security groups(상태 저장, instance/ENI 수준)와 network ACLs(비상태 저장, subnet 수준)입니다. 둘 다 198.51.100.0/24 및 203.0.113.16/28과 같은 CIDR blocks를 허용합니다. 정답이 맞는 이유: Security groups는 IPv4 CIDR blocks 및 IPv6 CIDR blocks를 사용하여 소스(inbound rules)와 대상(outbound rules)을 지정할 수 있습니다. 예를 들어, 규칙의 source 필드에 198.51.100.0/24 및 203.0.113.16/28에서의 TCP/443을 직접 허용할 수 있습니다. Network ACLs도 CIDR 기반 규칙을 지원합니다. rule number, protocol/port range, source/destination CIDR로 allow/deny 항목을 생성할 수 있습니다. 이는 security groups가 지원하지 않는 명시적 deny를 포함하여 subnet 전체 제어에 흔히 사용됩니다. 주요 AWS 기능 / 모범 사례: - Security groups는 stateful입니다. 반환 트래픽이 자동으로 허용되므로 일반적인 웹 액세스 패턴에서 규칙 복잡도가 줄어듭니다. - Network ACLs는 stateless입니다. 필요 시 inbound와 outbound 모두(반환 트래픽을 위한 ephemeral ports 포함)를 허용해야 합니다. - 대부분의 워크로드 액세스 제어에는 security groups를 선호하고, 광범위한 subnet 가드레일, 명시적 deny, 또는 규정 준수 기반 subnet 경계에는 NACLs를 사용합니다. - 둘 다(해당되는 경우) 다른 security groups(SG만) 및 prefix lists 참조를 지원하지만, 이 문제는 CIDR 표기법 입력을 구체적으로 묻고 있습니다. 흔한 오해: 일부 응시자는 IAM policies 또는 WAF를 CIDR 입력과 혼동합니다. AWS WAF도 CIDR이 포함된 IP sets를 지원하지만, 여기서는 선택지에 없습니다. 또한 AMI나 EBS에 “access rules”가 있다고 생각할 수 있으나, 이들은 네트워크 계층의 CIDR 필터링을 제공하지 않습니다. 시험 팁: “configure access rules”와 “CIDR block format”이 보이면 VPC 트래픽 필터링을 떠올리세요: Security Groups(instance/ENI)와 Network ACLs(subnet). 핵심 차이: SG = stateful allow rules, NACL = stateless allow/deny 및 순서가 있는 rule numbers. 이를 통해 객관식에서 네트워킹이 아닌 서비스를 빠르게 제거할 수 있습니다.

Practice Test #3

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(22)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #4

지금 학습 시작하기