연습 문제

문제 1

웹 서비스가 load balancer 뒤의 EC2에서 실행되고 있지만, 많은 클라이언트가 방화벽을 통해 allowlist된 IP만 허용할 수 있습니다. 고정 IP를 통해 서비스에 접근할 수 있도록 해야 합니다. 무엇을 권장해야 합니까?

문제 2

글로벌 컨설팅 회사가 다양한 지역 사무소에 걸쳐 25개의 AWS 계정을 관리하기 위해 AWS Organizations를 사용하고 있습니다. 본사 IT 팀은 민감한 고객 계약 및 규정 준수 문서가 포함된 중앙 Amazon S3 버킷을 마스터 계정에서 유지 관리합니다. 최근 보안 감사로 인해, 이 회사는 AWS Organization 내의 계정에 속한 사용자만 이 중요한 S3 버킷에 액세스할 수 있도록 보장해야 합니다. 지속적인 관리 작업과 유지 관리 노력을 최소화하면서 AWS Organization 내의 계정 사용자에게만 S3 버킷 액세스를 제한하도록 액세스 제어를 구현해야 합니다. 최소한의 운영 오버헤드로 액세스 제어 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 AWS Organizations와 통합되는 IAM 정책 조건 키를 사용하여 Amazon S3 리소스 기반 액세스 제어를 테스트합니다. 목표는 지속적인 관리를 최소화하면서 특정 AWS Organization의 계정에 속한 보안 주체(사용자/역할)만 중앙 S3 버킷에 액세스할 수 있도록 제한하는 것입니다. 정답인 이유: S3 버킷 정책 조건 키인 aws:PrincipalOrgID를 사용하는 것은 '내 Organization의 보안 주체만' 액세스하도록 강제하는 가장 직접적이고 유지 관리가 적은 방법입니다. 버킷 정책에 Organization ID(o-xxxxxxxxxx)를 한 번 지정하면, S3는 요청 시 호출자의 보안 주체를 평가합니다. Organization의 멤버인 모든 계정은 자동으로 일치하며, Organization 외부의 계정은 거부됩니다(명시적 Deny와 결합하거나 Allow 문이 적절히 범위가 지정된 경우). 이를 통해 계정 ID를 나열하거나, 계정별 정책 문을 관리하거나, 계정이 가입/탈퇴할 때 정책을 업데이트할 필요가 없어집니다. 주요 AWS 기능: - S3 버킷 정책(리소스 기반 정책)은 글로벌 조건 키를 사용할 수 있습니다. - aws:PrincipalOrgID 조건 키는 특정 AWS Organization의 일부인 보안 주체로 액세스를 제한합니다. - 중앙 집중식 데이터 레이크, 공유 규정 준수 리포지토리 및 다중 계정 거버넌스 패턴과 잘 작동합니다. - AWS Well-Architected 보안 원칙과 일치: 최소 권한을 구현하고 구성 편차가 발생할 수 있는 수동 프로세스를 줄입니다. 일반적인 오해: - 많은 사람들이 버킷 정책에 모든 계정 ID를 나열해야 한다고 가정합니다. 이는 운영 오버헤드를 증가시키고 계정이 변경될 때 오류가 발생하기 쉽습니다. - 일부는 OU 기반 제어(경로)를 Organization 전체 제어와 혼동합니다. OU 경로는 유용할 수 있지만 더 복잡하며 조직 개편 시 변경될 수 있습니다. - 정책을 모니터링하고 자동 업데이트하는 것(CloudTrail + 자동화)은 강력해 보이지만, 네이티브 조건 키가 이미 동적 멤버십 적용을 제공하는 경우에는 불필요합니다. 시험 팁: '내 AWS Organization의 계정만' 및 '최소한의 운영 오버헤드'라는 문구를 보면 리소스 정책(S3, KMS 등)에서 aws:PrincipalOrgID를 찾으십시오. 요구 사항이 IAM 조건이 제공하는 것 이상의 사용자 지정 로직을 명시적으로 필요로 하지 않는 한, 이벤트 기반 자동화보다 네이티브 정책 조건을 선호하십시오.

문제 3

한 금융 서비스 회사가 다양한 트레이딩 알고리즘 테스트 환경을 위해 여러 AWS 계정을 운영하고 있습니다. 퀀트 리서치 팀은 테스트 계정당 할당된 분기별 예산인 $50,000를 크게 초과하는 값비싼 GPU 지원 Amazon EC2 instance와 고성능 데이터베이스 구성을 자주 배포합니다. 회사는 관리 오버헤드를 최소화하면서 모든 테스트 계정에서 비용이 많이 드는 AWS 리소스 생성을 방지하기 위해 중앙 집중식 거버넌스를 구현해야 합니다. 운영 복잡성이 가장 적은 상태에서 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 다중 계정 환경에서 비용 제어를 위한 중앙 집중식 예방 거버넌스를 테스트합니다. 주요 AWS 개념은 IAM이 허용하는 것과 관계없이 사용 가능한 최대 권한을 정의하는 계정 수준 가드레일을 제공하는 SCP(Service Control Policy)가 포함된 AWS Organizations입니다. 정답인 이유: 옵션 B는 많은 계정에서 비용이 많이 드는 리소스 생성을 방지하는 운영상 가장 덜 복잡한 방법입니다. 모든 테스트 계정을 OU에 배치하고 SCP를 연결함으로써 회사는 특정 API 작업을 중앙에서 거부하거나 특정 리소스 구성의 사용을 거부할 수 있습니다(예: 특정 instance 유형이 요청될 때 ec2:RunInstances를 제한하거나 RDS/DB instance class를 제한). SCP는 IAM 권한 전에 평가되며 모든 멤버 계정에 일관되게 적용되므로, 팀이 계정 내에서 관리자와 유사한 IAM role을 가지고 있더라도 제어를 우회할 수 없습니다. 주요 AWS 기능: - AWS Organizations OU: 환경별로 계정을 그룹화합니다(예: "Trading-Testing"). - SCP: 명시적 거부 가드레일; OU 또는 계정 수준에서 연결할 수 있으며 계층 구조 아래로 상속됩니다. - 세분화된 제한을 위한 조건 키: 예를 들어 EC2는 GPU 제품군(p3, p4, g4, g5 등)을 거부하기 위해 ec2:InstanceType과 같은 조건을 지원합니다. rds:DatabaseClass(지원되는 경우)를 통해 RDS에 유사한 패턴을 적용하거나 승인된 태그/파라미터가 없는 한 특정 생성/수정 작업을 거부할 수 있습니다. - 예방적 대 탐지적 제어: SCP는 비용이 발생하기 전에 지출을 중단하여 비용 최적화 및 거버넌스 모범 사례에 부합합니다. 일반적인 오해: A와 D는 배포를 표준화할 수 있지만, 강력한 권한 경계/SCP를 구현하지 않는 한 사용자가 템플릿 외부에서 리소스를 시작하는 것을 본질적으로 방지하지는 않습니다. C는 사후 대응적(탐지 및 종료)이며 여전히 비용을 발생시키고 중단을 유발할 수 있으며 우회되거나 지연될 수 있습니다. 시험 팁: 요구 사항이 "가장 적은 운영 오버헤드" 및 "생성 방지"와 함께 "여러 계정에 걸친 중앙 집중식 거버넌스"인 경우 AWS Organizations + SCP를 생각하십시오. 탐지적 수정을 위해 EventBridge/Lambda를 사용하고 표준화를 위해 Service Catalog/CloudFormation을 사용하십시오. 단, SCP와 쌍을 이루지 않는 한 기본 하드 가드레일로는 사용하지 마십시오. 이를 AWS Well-Architected 비용 최적화 원칙에 매핑하십시오: 승인되지 않은 지출을 방지하기 위해 가드레일과 제어를 구현합니다.

문제 4

한 금융 서비스 회사가 실시간 주식 거래 플랫폼을 운영하고 있습니다. 이 애플리케이션은 현재 Asia-Pacific의 단일 데이터 센터에 있는 중앙 집중식 데이터베이스를 사용하고 있습니다. 이 회사는 North America와 Europe의 트레이더들에게 서비스를 제공하기 위해 전 세계로 확장할 계획입니다. 회사는 여러 AWS Region에 거래 플랫폼을 배포해야 합니다. 모든 거래 실행은 전 세계적으로 800 밀리초 미만의 지연 시간(latency)을 가져야 합니다. 회사는 거래 인터페이스의 개별적인 Regional 배포를 원하지만, 포트폴리오 잔액 및 거래 기록에 대해 글로벌 일관성(global consistency)을 유지하는 단일 마스터 거래 데이터베이스를 요구합니다. 이러한 요구 사항을 충족하기 위해 solutions architect는 어떤 솔루션을 권장해야 합니까?

문제 분석

핵심 개념: 이 문제는 비즈니스가 더 낮은 사용자 지연 시간을 위해 regional application deployments를 요구하면서도, 전 세계적으로 일관된 trade 및 portfolio data를 위한 단일 master database of record를 여전히 원할 때 multi-Region application을 어떻게 설계해야 하는지를 테스트합니다. 핵심적인 구분은 single-writer architecture와 multi-active replicated database 사이의 차이입니다. 정답인 이유: cross-Region read replicas를 사용하는 Amazon Aurora MySQL은 단일 Region에 하나의 primary writer database를 제공하므로, 단일 master trading database 요구 사항을 충족합니다. North America와 Europe의 regional application deployments는 더 낮은 지연 시간의 reads를 위해 로컬 read replicas를 사용할 수 있고, 모든 writes는 portfolio balances와 trade records의 일관성을 유지하기 위해 primary Region으로 전달됩니다. 이것은 전 세계에 배포된 application과 하나의 authoritative transactional database를 위한 AWS-managed 설계 중 가장 가까운 방식입니다. 주요 기능: Aurora는 cross-Region replication, 로컬 reader endpoints, 그리고 source of truth 역할을 하는 primary writer instance를 지원합니다. Aurora는 일반적으로 표준 RDS MySQL replicas보다 더 낮은 replication lag와 더 나은 성능을 제공하므로, 지연 시간에 민감한 글로벌 applications에 더 적합합니다. 또한 financial transactions에서 자주 중요한 relational database semantics도 유지합니다. 일반적인 오해: 흔한 함정은 문제에서 multiple Regions와 low latency를 언급할 때마다 DynamoDB global tables를 선택하는 것입니다. 그러나 global tables는 multi-active이며 Regions 간 eventually consistent하고, conflict resolution 방식도 단일 master financial ledger에는 적절하지 않습니다. 또 다른 오해는 표준 MySQL read replicas가 까다로운 글로벌 transactional workloads에서 Aurora와 동등하다고 생각하는 것입니다. 일반적으로 Aurora가 더 강력한 managed option입니다. 시험 팁: 문제에서 명시적으로 single master database라고 말하면, multi-writer 또는 eventually consistent global database 옵션은 피하세요. 전 세계에 분산된 applications이면서도 여전히 하나의 authoritative transactional writer가 필요한 경우에는 DynamoDB global tables보다 cross-Region replicas가 있는 Aurora를 찾으세요. single master, global consistency, trade records 같은 표현에 특히 주의하세요. 이는 relational single-writer 설계를 강하게 시사합니다.

문제 5

한 금융 서비스 회사가 중요한 규제 준수 문서 및 감사 템플릿을 저장하는 Amazon Elastic File System (Amazon EFS) 파일 시스템을 보유하고 있습니다. 이 회사에는 분석 및 보고 목적으로 이러한 문서에 액세스해야 하는 규정 준수 모니터링 애플리케이션을 실행하는 여러 Amazon EC2 인스턴스가 있습니다. 규정 준수 애플리케이션은 규제 문서에 대한 읽기 액세스 권한이 있어야 하지만 이러한 중요한 파일을 수정, 삭제 또는 손상시킬 수 없어야 합니다. 회사는 운영 효율성을 유지하면서 데이터 무결성을 보장하기 위해 IAM 기반 액세스 제어를 구현해야 합니다. 이 솔루션은 애플리케이션의 모든 쓰기 작업을 방지하는 동시에 규정 준수 보고에 필요한 읽기 작업은 허용해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 OS 수준 제어(마운트 옵션/POSIX)와 비교하여 IAM(EFS 파일 시스템 정책)을 사용하는 Amazon EFS 권한 부여를 테스트합니다. EFS를 사용하면 IAM 권한 부여가 클라이언트 작업(ClientMount, ClientRead, ClientWrite 및 선택적으로 ClientRootAccess)을 통해 EFS API 계층에서 적용되며 IAM identity policies 및/또는 EFS resource-based policy를 사용하여 평가됩니다. 정답인 이유: 옵션 B는 EFS resource-based policy를 사용하여 EC2 인스턴스에서 사용하는 IAM roles에 대해 elasticfilesystem:ClientWrite를 명시적으로 거부합니다. 명시적 거부(Deny)는 AWS 정책 평가 논리에서 가장 강력한 제어이며 다른 곳(identity policies, 권한 경계 또는 기타 연결된 정책)에서 부여될 수 있는 모든 허용(Allow)을 재정의합니다. 이는 읽기 작업을 허용하면서(ClientRead 및 ClientMount가 허용된다고 가정) 문서를 "수정, 삭제 또는 손상시킬 수 없어야 한다"는 요구 사항을 직접적으로 충족합니다. 이는 IAM 기반이고 파일 시스템에서 중앙 집중식으로 관리되며 인스턴스별 구성에 의존하는 대신 EFS 파일 시스템에 한 번 적용할 수 있으므로 운영 효율적입니다. 주요 AWS 기능: - IAM 보안 주체를 사용하여 NFS 클라이언트 액세스를 제어하는 EFS 파일 시스템 정책(resource-based policy). - EFS IAM 권한 부여 작업: elasticfilesystem:ClientMount, elasticfilesystem:ClientRead, elasticfilesystem:ClientWrite. - 정책 평가: 명시적 거부(Deny)는 모든 허용(Allow)을 재정의합니다. - EC2 인스턴스 프로필/역할과 잘 작동하며 많은 인스턴스 및 애플리케이션으로 확장됩니다. 일반적인 오해: - "읽기 전용 마운트"(옵션 A)는 IAM 기반이 아니며 강력한 보안 경계가 아닙니다. 권한이 있는 사용자/프로세스는 읽기-쓰기로 다시 마운트할 수 있습니다. - Identity-based 거부(옵션 C)는 작동할 수 있지만 파일 시스템의 단일 리소스 정책보다 운영 효율성이 떨어지고 대규모로 잘못 관리하기 쉽습니다. - Access points 및 POSIX 권한(옵션 D)은 유용하지만 주로 POSIX/OS 수준 제어입니다. 그 자체로는 IAM 기반 액세스 제어에 대한 요구 사항을 충족하지 않으며 다른 액세스 경로/권한이 존재하는 경우 우회될 수 있습니다. 시험 팁: "절대 쓰지 않아야 함(must never write)" 및 "IAM 기반 제어"가 보이면 EFS ClientWrite를 사용하는 명시적 거부를 찾으십시오. 많은 역할/계정에서 액세스하는 공유 리소스에 대한 중앙 집중식 제어를 원할 때 resource-based policies를 선호하십시오. 기억하십시오: 마운트 옵션과 POSIX 권한은 중요한 심층 방어(defense-in-depth)이지만 질문에서 명시적으로 IAM 기반 액세스 제어를 요구할 때 IAM 적용을 대체할 수는 없습니다.

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

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

문제 6

AWS Organizations에서 관리하는 수백 개의 AWS 계정을 보유한 글로벌 기술 회사 'GlobalTech'는 감사자에게 NIST 및 PCI DSS와 같은 여러 보안 표준에 대한 규정 준수를 증명해야 합니다. 이 회사는 모든 계정의 보안 상태를 모니터링할 수 있는 중앙 집중식의 자동화된 방법을 원합니다. 솔루션은 보안 팀이 각 개별 계정에서 규정 준수 표준을 수동으로 활성화하고 관리할 필요 없이 모든 멤버 계정의 보안 제어 현재 상태를 모니터링할 단일 계정을 지정할 수 있도록 해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

Core Concept: 이 질문은 AWS Organizations의 여러 AWS 계정 전반에 걸친 중앙 집중식의 자동화된 규정 준수 상태 관리를 테스트합니다. 보안 결과를 집계하고 이를 규정 준수 프레임워크(예: PCI DSS, NIST)에 매핑하는 주요 서비스는 위임 관리자 및 조직 전체 자동 활성화를 사용하는 AWS Security Hub입니다. Why the Answer is Correct: 옵션 A는 AWS Organizations와 함께 AWS Security Hub를 올바르게 사용합니다. Security Hub 위임 관리자 계정을 지정함으로써 GlobalTech는 모든 멤버 계정에 대해 Security Hub를 중앙에서 관리하고 관리자 계정에서 한 번 보안 표준을 활성화할 수 있습니다. 그런 다음 Security Hub는 (AWS 서비스 및 파트너의) 결과를 지속적으로 평가 및 집계하고 조직 전체의 활성화된 표준에 대한 규정 준수 상태를 표시하여 각 계정에서 표준을 수동으로 활성화하고 관리하지 않도록 하는 요구 사항을 충족합니다. Key AWS Features: Security Hub는 다음을 지원합니다. - Organizations를 위한 위임 관리자. 관리 계정이 아닌 계정이 조직 전체의 Security Hub를 관리할 수 있도록 합니다. - 신규 및 기존 계정에 대한 자동 활성화. 계정이 추가될 때 운영 오버헤드를 줄입니다. - 제어 상태 대시보드 및 통합된 결과가 포함된 보안 표준(예: 리전/가용성에 따른 PCI DSS, CIS, NIST 패키지). - 교차 계정 집계 및 중앙 집중식 가시성. AWS Well-Architected Security Pillar 원칙(지속적인 모니터링, 중앙 집중식 거버넌스 및 자동화된 제어)과 일치합니다. Common Misconceptions: GuardDuty는 규정 준수 표준 대시보드가 아니라 위협 탐지(악의적인 활동/이상 징후)를 위한 것입니다. Inspector는 광범위한 다중 제어 규정 준수 프레임워크가 아니라 취약성 관리(EC2/ECR/Lambda)에 중점을 둡니다. CloudTrail은 감사 로그 서비스입니다. 조사 및 거버넌스에 필수적이지만 계정 전반에 걸쳐 내장된 "NIST/PCI 표준 활성화" 규정 준수 점수를 제공하지는 않습니다. Exam Tips: "prove compliance", "standards like PCI/NIST", "central dashboard" 및 "across all accounts"를 보면 Security Hub를 생각하십시오. "threat detection"을 보면 GuardDuty를 생각하십시오. "vulnerability scanning"을 보면 Inspector를 생각하십시오. "API logging"을 보면 CloudTrail을 생각하십시오. 또한 중앙 집중식 다중 계정 관리를 나타내는 핵심 문구로 "delegated administrator" 및 "Organizations integration"을 주의 깊게 살펴보십시오.

문제 7

한 금융 서비스 회사가 Application Load Balancer 뒤에 있는 Amazon EC2 인스턴스에서 호스팅되는 온라인 뱅킹 플랫폼을 운영하고 있습니다. 규정 준수 요구 사항으로 인해 이 플랫폼은 미국 내에 위치한 고객만 액세스할 수 있어야 합니다. 이 회사는 높은 성능과 보안을 유지하면서 지리적 위치를 기반으로 뱅킹 플랫폼에 대한 액세스를 제한하는 솔루션을 구현해야 합니다. 이러한 지리적 액세스 제한 요구 사항을 충족하는 구성은 무엇입니까?

문제 분석

Core Concept: 이 질문은 클라이언트의 지리적 위치를 기반으로 한 엣지/애플리케이션 계층(edge/application-layer) 액세스 제어를 테스트합니다. AWS에서 Layer 7(HTTP/S)의 지리적 기반 허용/차단을 위해 특별히 구축된 서비스는 geo match statement를 사용하는 AWS WAF이며, 일반적으로 Application Load Balancer(ALB) 또는 CloudFront와 연결됩니다. Why the Answer is Correct: 지리적 일치 조건(geographic match conditions)을 사용하여 ALB에 AWS WAF를 구성하면 회사는 미국에서 시작된 요청을 명시적으로 허용하고 다른 모든 국가를 차단할 수 있습니다. 트래픽이 EC2 인스턴스에 도달하기 전에 필터링이 발생하므로 성능과 보안을 유지하면서 규정 준수 요구 사항을 충족합니다. WAF는 ALB와 기본적으로 통합되고, 관리형 가시성(지표/로깅)을 지원하며, 애플리케이션 진입점에서 결정론적 정책 적용을 제공합니다. Key AWS Features: - ALB와 연결된 AWS WAF Web ACL: ALB 뒤에 있는 모든 대상에 대한 중앙 집중식 정책 적용. - Geo match statement: 요청의 출발지 국가(클라이언트 IP에서 파생됨)를 일치시키며 allow-list 또는 block-list 규칙에 사용할 수 있습니다. - Default action + rule priority: 일반적인 패턴은 기본적으로 "Block"을 설정한 다음 "Allow US"를 설정하여(또는 설계에 따라 그 반대로) 미국 외 지역이 거부되도록 보장하는 것입니다. - Observability and audit: Amazon S3/CloudWatch Logs/Kinesis Data Firehose로의 WAF 로깅 및 CloudWatch 지표는 규정 준수 증거를 지원합니다. - Security best practice: 지리적 제한을 rate-based rules, bot control 및 OWASP 보호를 위한 managed rule groups와 결합합니다. Common Misconceptions: 많은 사람들이 security groups나 network ACLs가 국가별로 필터링할 수 있다고 가정합니다. 하지만 불가능합니다. 이들은 IP/CIDR 및 포트/프로토콜만 평가합니다. IP 소유권과 지리적 위치가 자주 변경되고 SG/NACL 규모에서 안정적으로 적용할 수 있는 권위 있는 "미국 전용" CIDR 목록이 없기 때문에 "미국 IP 범위"를 수동으로 유지 관리하는 것은 비실용적이고 오류가 발생하기 쉽습니다. Exam Tips: ALB 뒤의 HTTP/S 워크로드에 대해 "지리적 위치로 제한(restrict by geographic location)"이라는 문구를 보면 AWS WAF geo match(또는 설계에 CloudFront가 있는 경우 CloudFront geo restriction)를 생각하십시오. L3/L4 IP 기반 제한의 경우 SG/NACL을 사용하지만, 국가 기반 제어 및 규정 준수 친화적인 로깅의 경우 WAF가 표준 정답입니다. 또한 ALB security groups는 지리적 조건을 지원하지 않으며 IP/CIDR 기반 규칙만 지원한다는 점에 유의하십시오.

문제 8

한 의료 기관이 제3자 규정 준수 감사 회사에 자사의 AWS account에 대한 액세스를 제공해야 합니다. 감사 회사는 자체 AWS 환경에서 실행되는 특수 자동화 스캐닝 도구를 사용하여 여러 클라이언트 account에 걸쳐 보안 구성 및 규정 준수 상태를 평가합니다. 감사 회사는 AWS account ID 123456789012에서 운영되며 30일의 평가 기간 동안 보안 관련 서비스에 대한 read-only 액세스가 필요합니다. 의료 기관은 액세스 권한에 대한 완전한 제어를 유지해야 하며 감사가 완료되면 즉시 액세스를 취소할 수 있어야 합니다. solutions architect는 감사 회사에 의료 기관의 AWS account에 대한 액세스를 어떻게 안전하게 부여해야 합니까?

문제 분석

핵심 개념: 이 문제는 IAM role(STS AssumeRole) 및 최소 권한 위임을 사용한 안전한 cross-account 액세스를 테스트합니다. 자체 AWS account에서 운영되는 제3자의 경우, 장기 자격 증명을 공유하는 대신 제3자가 assume할 수 있는 고객 account의 role을 통해 액세스를 부여하는 것이 AWS 모범 사례입니다. 정답인 이유: 옵션 A는 의료 기관의 account에 IAM role을 생성하고 AWS account 123456789012(감사자)가 이를 assume할 수 있도록 허용하는 trust policy를 설정합니다. 권한이 자사 account의 role에 연결되어 있으므로 의료 기관은 완전한 제어를 유지하며, role이나 trust policy를 수정/삭제하여 즉시 액세스를 취소할 수 있습니다. role 세션은 일시적(STS 자격 증명)이며 최대 세션 기간 및 모니터링을 통해 추가로 제한할 수 있으므로 30일 요구 사항이 자연스럽게 지원됩니다. 주요 AWS 기능: - IAM Role + Trust Policy: trust policy는 누가 role을 assume할 수 있는지 지정합니다(전체 account보다는 특정 감사자 role ARN으로 제한하는 것이 이상적임). - STS Temporary Credentials: AssumeRole은 수명이 짧은 자격 증명을 반환하여 장기 키에 비해 위험을 줄입니다. - External ID: 제3자가 여러 고객에게 서비스를 제공할 때 발생하는 "confused deputy" 문제를 방지합니다. 감사자는 role을 assume하기 위해 합의된 external ID를 제시해야 합니다. - 최소 권한: read-only, 보안 중심 policy(예: SecurityAudit 관리형 policy 및/또는 필요한 서비스로 범위가 지정된 사용자 지정 policy)를 연결합니다. 민감한 데이터 서비스에 대해서는 permission boundary나 명시적 거부를 고려하십시오. - 거버넌스: CloudTrail을 사용하여 AssumeRole 이벤트를 로깅하고, 가능한 경우 선택적으로 MFA 또는 소스 조건을 요구합니다. 일반적인 오해: access key(IAM user)를 공유하는 것이 더 간단해 보일 수 있지만, 통제 범위를 벗어난 장기 자격 증명을 생성하며 복사될 경우 안전하게 취소하기가 더 어렵습니다. IAM에는 "cross-account group membership"이 존재하지 않습니다. "External AWS Account"는 IAM identity provider 유형이 아닙니다. 페더레이션은 다른 account의 root 자격 증명이 아닌 SAML/OIDC를 사용합니다. 시험 팁: 제3자가 자체 AWS account에서 액세스해야 하는 경우 "account에 role을 생성하고 이를 assume하도록 허용"을 찾으십시오. 제3자 액세스를 위해 ExternalId를 추가하고, 임시 자격 증명을 선호하며, trust policy를 변경하거나 role을 삭제하여 즉각적인 취소를 보장하십시오. 이는 최소 권한, 강력한 자격 증명 기반 및 추적성이라는 AWS Well-Architected Security Pillar와 일치합니다.

문제 9

한 핀테크 스타트업이 시장 운영 시간 동안 변동하는 거래량을 처리할 실시간 주식 거래 플랫폼을 개발하고 있습니다. 이 플랫폼은 시장 개장/폐장 시간에 최대 50,000명의 동시 접속자가 발생하는 피크 로드를 겪지만, 비피크 시간대에는 2,000명으로 감소합니다. 이 회사는 인프라 관리 오버헤드가 없어야 하며, 30초 이내에 거래 활동의 갑작스러운 급증을 처리할 수 있는 자동 스케일링을 요구합니다. 플랫폼은 시장 운영 시간 동안 99.99%의 가용성을 유지해야 하며, 실시간 시장 데이터 쿼리와 고빈도 거래 실행을 모두 지원해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 높은 가용성과 짧은 지연 시간 요구 사항을 충족하면서 운영 오버헤드를 최소화하고 빠르고 자동화된 스케일링을 제공하는 완전 관리형 서버리스 서비스를 선택하는 능력을 테스트합니다. 주요 서비스는 컴퓨팅을 위한 API Gateway + AWS Lambda, 스파이크가 발생하는 트랜잭션 워크로드를 위한 DynamoDB 온디맨드, 고가용성 정적 전송을 위한 S3/CloudFront입니다. 정답인 이유: 옵션 A는 유일한 엔드투엔드 서버리스 설계입니다. API Gateway와 Lambda는 인프라 관리를 제거하고 갑작스러운 트래픽 변화에 자동으로 스케일링할 수 있습니다. Lambda는 동시 실행을 늘려 스케일링하며, API Gateway는 사전 프로비저닝 없이 수평으로 스케일링됩니다. DynamoDB 온디맨드 용량은 예측할 수 없고 버스트가 심한 트래픽을 위해 특별히 설계되었으며, 용량 계획 없이도 큰 스파이크를 수용할 수 있어 "30초 이내"의 응답성 및 시장 개장/폐장 시의 급증과 일치합니다. S3와 CloudFront는 전 세계적으로 정적 대시보드에 대해 고가용성 및 짧은 지연 시간의 전송을 제공하여 API의 부하를 줄입니다. 주요 AWS 기능: - API Gateway: 관리형 프런트 도어, 스로틀링/사용량 계획, 시장 데이터 쿼리를 위한 캐싱(선택 사항), 다중 AZ 복원력. - AWS Lambda: 자동 스케일링, 서버 없음, 빠른 스케일 아웃 지원; 중요한 거래 실행 경로를 보호하려면 예약된 동시성(reserved concurrency)을 사용하고, 초저지연 콜드 스타트가 필요한 경우 프로비저닝된 동시성(provisioned concurrency)을 사용합니다. - DynamoDB 온디맨드: 읽기/쓰기 처리량에 대한 즉각적인 탄력성, 기본적으로 다중 AZ 지원; 읽기 작업이 많은 시장 데이터의 경우 DynamoDB Accelerator (DAX)를, 이벤트 기반 워크플로의 경우 DynamoDB Streams를 고려합니다. - CloudFront + S3: 정적 UI 및 캐싱 가능한 시장 데이터에 대한 고가용성 및 글로벌 엣지 캐싱. 일반적인 오해: Aurora "Auto Scaling"(옵션 B/D)은 관계형 거래 데이터에 매력적일 수 있지만, Aurora 용량 변경(특히 Serverless v2 스케일링)은 극단적인 스파이크 상황에서의 즉각적이고 제약 없는 스케일링과 동일하지 않으며, 더 많은 튜닝/연결 관리 고려 사항을 도입합니다. EC2 Auto Scaling(옵션 C/D)은 스케일링할 수 있지만 "인프라 관리 오버헤드 제로"를 위반하며, 인스턴스 시작/웜업 시간으로 인해 일반적으로 30초 이내에 대규모 스파이크에 대한 스케일링을 보장할 수 없습니다. 시험 팁: 요구 사항에서 "인프라 관리 없음", "갑작스러운 스파이크", "매우 빠른 스케일링"을 강조하는 경우, 예측할 수 없는 처리량에 대해 기본적으로 서버리스(API Gateway/Lambda) 및 DynamoDB 온디맨드를 선택하십시오. OS 수준의 제어나 장기 실행 연결이 필요한 경우 EC2/ALB를 사용하고, 강력한 관계형 제약 조건이 명시적으로 필요한 경우 Aurora를 사용하십시오. 또한 99.99%+ 설계를 위해 가용성 목표를 관리형 다중 AZ 서비스(S3, CloudFront, API Gateway, Lambda, DynamoDB)에 매핑하십시오.

문제 10

한 금융 서비스 회사가 대출 신청 문서를 처리하기 위해 Amazon API Gateway와 AWS Lambda를 사용하여 RESTful API를 배포했습니다. 이 시스템은 고객의 재무 제표, 세금 신고서 및 은행 기록이 포함된 PDF 및 PNG 형식의 문서 업로드를 처리합니다. 회사는 규정 준수를 보장하기 위해 업로드된 문서에서 사회 보장 번호, 은행 계좌 번호 및 신용 카드 정보와 같은 개인 식별 정보(PII)를 자동으로 감지하고 식별하도록 Lambda 코드를 수정해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 문서에서 텍스트를 추출(OCR)한 다음 최소한의 운영 오버헤드로 PII를 감지하기 위해 완전 관리형 AWS AI 서비스를 선택하는 능력을 테스트합니다. 주요 서비스는 PDF/PNG에서 문서 텍스트를 추출하는 Amazon Textract와 SSN, 은행 계좌 번호, 신용 카드 번호와 같은 민감한 엔터티를 식별하는 Amazon Comprehend(특히 Comprehend PII)입니다. 정답인 이유: 옵션 C는 운영 부담이 가장 적고 목적에 맞게 구축된 접근 방식입니다. Textract는 스캔/구조화된 재무 문서(양식 및 테이블 포함)에서 텍스트를 안정적으로 추출하며, Comprehend는 모델을 구축, 훈련 또는 호스팅하지 않고도 관리형 PII 엔터티 감지 기능을 제공합니다. 이는 운영 부담을 낮게 유지하면서 "Lambda 코드를 수정"(즉, Lambda에서 관리형 API 호출)하라는 요구 사항과 일치합니다. 워크플로는 간단합니다. Lambda가 업로드된 문서(주로 S3에 있음)를 수신/찾고, Textract를 호출(작은 문서의 경우 동기식, 다중 페이지 PDF의 경우 비동기식 작업)하여 추출된 텍스트를 수집한 다음, Comprehend DetectPiiEntities를 호출하여 교정, 알림 또는 규정 준수 로깅을 위한 PII 유형 및 오프셋을 반환합니다. 주요 AWS 기능: Textract는 PDF 및 이미지를 지원하며 대출 패키지에서 흔히 볼 수 있는 텍스트와 구조(양식/테이블)를 추출할 수 있습니다. Comprehend PII는 일반적인 PII(예: CREDIT_DEBIT_NUMBER, BANK_ACCOUNT_NUMBER, SSN)에 대해 사전 훈련된 감지 기능을 제공하고 신뢰도 점수와 문자 오프셋을 반환합니다. 두 서비스 모두 서버리스/관리형이며 Lambda와 잘 통합되고 패치 적용, 확장 및 모델 수명 주기 관리를 줄여줍니다. 프로덕션 환경의 경우 문서를 S3에 저장하고, 대용량 PDF에는 비동기식 Textract를 사용하며, 금융 규정 준수 기대치를 충족하기 위해 최소 권한 IAM 권한 및 암호화(SSE-KMS)를 적용합니다. 일반적인 오해: Rekognition은 OCR(DetectText)을 수행할 수 있지만 이미지/비디오에 최적화되어 있으며 Textract에 비해 다중 페이지 PDF 및 복잡한 문서 레이아웃에는 적합하지 않습니다. SageMaker는 확실히 PII 분류기를 구축할 수 있지만, 이는 훈련, 엔드포인트 호스팅, 모니터링 및 재훈련을 도입하여 Comprehend의 관리형 PII 감지에 비해 높은 운영 오버헤드를 발생시킵니다. DIY Python 라이브러리는 간단해 보일 수 있지만 정확성, 유지 관리, 확장 및 규정 준수 검증은 회사의 책임이 됩니다. 시험 팁: "최소한의 운영 오버헤드"를 위해서는 사용자 지정 ML보다 관리형 AI 서비스를 선호하십시오. PDF/양식/테이블의 문서 OCR의 경우 Textract를 생각하십시오. PII 감지와 같은 관리형 NLP 작업의 경우 Comprehend(PII)를 생각하십시오. Rekognition OCR은 일반적으로 문서 처리 파이프라인이 아니라 이미지의 장면 텍스트를 위한 것입니다.

Practice Test #10

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(29)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #6

Practice Test #7

Practice Test #8

Practice Test #9

지금 학습 시작하기