연습 문제

문제 1

글로벌 미디어 구독 서비스가 ap-southeast-2의 세 개 Availability Zone에 걸쳐 Amazon EC2에서 상태 비저장 고객 대시보드를 출시할 계획입니다. 평균 CPU > 60%가 5분 동안 지속될 때 6~120 인스턴스로 Auto Scaling을 수행하며 99.9% 가용성이 필요합니다. 또한 ap-northeast-1에 RTO 10분의 active-passive 재해 복구(DR) 환경을 구현하고 Route 53 health check(30초 간격, 연속 2회 실패 후 장애로 판단)를 사용하되, 정상 운영 중에는 ap-southeast-2에서만 트래픽을 제공해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Application Load Balancer, Auto Scaling, 그리고 health check가 포함된 Amazon Route 53 DNS failover를 사용하여 상태 비저장 EC2 웹 계층에 대한 multi-Region 고가용성과 재해 복구(DR) 설계를 평가합니다. 또한 서비스 범위도 간접적으로 테스트합니다. ALB와 Auto Scaling group은 Regional이며, 일부 선택지에서 제안하는 것처럼 Region/VPC를 가로질러 확장할 수 없습니다. 정답이 맞는 이유: 선택지 C는 active-passive DR 패턴을 구현합니다. 정상 운영 중에는 ap-southeast-2가 모든 트래픽을 제공(Primary)하고, ap-northeast-1은 프로비저닝되어 준비된 상태(Secondary)이지만 장애 시에만 트래픽을 수신합니다. Route 53 failover routing과 health check를 통해 primary 엔드포인트가 비정상 상태가 되면 DNS 응답이 secondary로 전환됩니다. 지정된 health check 설정(30초 간격, 연속 2회 실패 후 장애)은 요구 사항과 일치하며, 60초 TTL은 DNS 캐싱 지연을 줄여 10분 RTO를 충족하는 데 도움이 됩니다. Primary Region은 세 개 AZ에 걸친 ALB와 최소 6/최대 120의 Auto Scaling group, 그리고 평균 CPU > 60%가 5분 지속될 때 스케일링을 사용하여 스케일링 요구 사항과 99.9% 가용성 목표를 충족합니다. 주요 AWS 기능: - ALB는 Regional이며 Region 내 여러 AZ에 걸쳐 구성할 수 있어 복원력을 향상합니다. - 여러 AZ에 걸친 EC2 Auto Scaling은 탄력성과 AZ 장애 허용을 제공합니다. - Route 53 failover routing policy는 health check가 포함된 primary/secondary record를 지원합니다. - health check 간격과 실패 임계값은 감지 시간을 결정하며, TTL은 클라이언트 측 DNS 캐싱에 영향을 주어 실질적인 failover 시간에 영향을 줍니다. 흔한 오해: A와 D는 ALB가 VPC/Region 전반으로 “확장”될 수 있고 단일 Auto Scaling group이 두 Region/VPC에 걸쳐 인스턴스를 시작할 수 있다고 가정합니다. 실제로 ALB와 ASG는 단일 Region 범위이며(또한 ALB는 해당 Region의 subnet과 연결됨), VPC peering도 단일 ALB가 다른 Region의 인스턴스를 대상으로 삼을 수 있게 해주지 않습니다. B는 비슷해 보이지만 active-passive 동작을 강제하지 않습니다. “두 record에 health check를 활성화”는 모호하며 active-active(예: weighted/multivalue) 또는 의도치 않은 트래픽 분산으로 이어질 수 있습니다. 시험 팁: - Regional 경계를 기억하세요: ALB, ASG, subnet은 Regional이며 Route 53은 global입니다. - Route 53로 active-passive DR을 구성할 때는 health check와 함께 명시적인 primary/secondary가 있는 “failover routing policy”를 찾으세요. - RTO는 감지 시간 + DNS TTL + 프로비저닝 준비 상태에 좌우됩니다. secondary 스택을 warm 상태로 유지하고 TTL을 낮게 설정하면 RTO가 개선됩니다.

문제 2

한 물류 회사가 2,500대의 자율 창고 로봇 플릿을 배포하고 있으며, 각 로봇은 Wi-Fi를 통해 매초 8 KB의 텔레메트리를 AWS로 전송합니다. 이 회사는 유입 스트림에 대해 준실시간(<=3초) 분석을 제공하고, 내구적이며 순서가 보장되고 고도의 병렬 처리가 가능한 수집을 보장하며, 데이터를 재처리할 수 있어야 하고, 처리된 결과를 BI를 위한 데이터 웨어하우스로 전달하는 데이터 플랫폼이 필요합니다. 이러한 요구 사항을 충족하기 위해 솔루션스 아키텍트는 어떤 전략을 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 올바른 스트리밍 수집 및 준실시간 분석 아키텍처를 선택하는 것을 평가합니다. 핵심 요구 사항인 내구적이고 순서가 보장되는 수집, 높은 병렬성, 재생/재처리 가능, 그리고 데이터 웨어하우스로의 전달은 Amazon Kinesis Data Streams (KDS) + 스트림 처리 계층 + Redshift 싱크에 직접적으로 매핑됩니다. 정답이 맞는 이유: Amazon Kinesis Data Streams는 높은 처리량과 낮은 지연의 스트리밍 수집을 위해 목적에 맞게 설계되었으며, shard별 레코드 순서 보장과 멀티 컨슈머 fan-out을 제공합니다. 2,500대 로봇이 각각 8 KB/s를 전송하므로 유입 볼륨은 약 20 MB/s(약 160 Mb/s)입니다. KDS는 write 처리량과 병렬 처리 요구를 충족하기 위해 shard를 추가하여 수평 확장이 가능합니다. 또한 KDS는 기본적으로 24시간(최대 365일) 데이터 보존을 제공하므로, 컨슈머가 체크포인트에서 다시 읽어 과거 데이터를 재처리할 수 있는데, 이는 문제에서 명시적으로 요구하는 사항입니다. 준실시간 분석(<=3초)은 Kinesis Client Library (KCL) 컨슈머 또는 관리형 처리(일반적으로 Kinesis Data Analytics / Apache Flink)를 사용해 달성할 수 있으며, 이후 정제된 결과를 BI를 위해 Amazon Redshift로 로드할 수 있습니다. 옵션에서 EMR을 언급한 것은 시험에서 흔한 패턴으로, 확장 가능한 컴퓨팅 계층을 사용해 변환한 뒤 Redshift로 적재하는 흐름을 반영합니다. 주요 AWS 기능: KDS는 shard 내에서의 순서 보장 처리, 여러 AZ에 걸친 내구적 복제, shard를 통한 수평 확장을 제공합니다. Enhanced fan-out은 여러 병렬 컨슈머에 전용 처리량을 제공하여 지원합니다. 체크포인팅(KCL/DynamoDB를 통해)은 exactly-once/at-least-once 처리 패턴과 재생을 가능하게 합니다. Redshift의 경우 일반적인 전달 방식은 S3에서의 마이크로 배치 COPY 또는 스트리밍 수집 패턴이며, EMR/Spark는 텔레메트리를 집계/윈도잉하고 S3/Redshift에 효율적으로 기록할 수 있습니다. 흔한 오해: Firehose(옵션 A)는 S3/Redshift/OpenSearch 등으로의 단순 전달에는 훌륭하지만, KDS와 같은 재생/재처리 제어 및 shard별 순서 보장 의미론을 제공하지 않으며, 버퍼링으로 인해 지연이 증가할 수 있습니다. SQS 기반 설계(옵션 C/D)는 대규모에서 엄격한 순서를 보존하지 못하며, 재생 가능한 스트림 분석에 적합하지 않습니다. 시험 팁: “순서가 보장되는 내구적 스트림”, “병렬 수집”, “재처리/재생”을 보면 Kinesis Data Streams(또는 Kafka/MSK)를 떠올리십시오. “BI를 위한 데이터 웨어하우스로 전달”을 보면 싱크로 Redshift를 떠올리며, 종종 중간의 정제 저장소(일반적으로 S3)와 처리 엔진(Flink/Spark/EMR)이 함께 사용됩니다.

문제 3

AWS Organizations에서 blueOrg (orgA)라는 organization 하에 운영되는 독립적인 cybersecurity auditing firm은, 별도의 organization인 greenOrg (orgB)에 속한 고객의 AWS account에 programmatically access하여, 해당 업체의 management account에서 4시간마다 automated compliance scanner를 실행해야 합니다. 이 스캐너는 temporary credentials와 least privilege를 사용하여 EC2 Describe*, IAM Get*, S3 List* metadata만 읽습니다. API/CLI를 통해 orgA가 orgB의 resources에 access할 수 있도록 하는 가장 secure한 방법은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 서로 다른 AWS Organizations 간의 secure cross-account access를 AWS STS AssumeRole, least-privilege IAM roles, 그리고 confused deputy protection 메커니즘(ExternalId)을 사용해 구현하는지를 평가합니다. 또한 best practices(장기 credentials 회피, temporary credentials 사용, trust 및 permissions의 엄격한 범위 지정)를 간접적으로 테스트합니다. 정답이 맞는 이유: Option D는 third-party auditor가 고객 account에 programmatically access하는 가장 secure한 패턴입니다. 고객은 orgB(고객 account)에 필요한 read-only permissions(EC2 Describe*, IAM Get*, S3 List*)만 가진 IAM role을 생성합니다. role의 trust policy는 orgA의 auditor AWS account가 role을 assume할 수 있도록 허용하되, auditor가 고유한 ExternalId를 제공하는 경우에만 허용합니다. auditor는 management account에서 4시간마다 sts:AssumeRole을 호출하여 short-lived credentials를 획득합니다. 이는 temporary credentials, least privilege, 그리고 unauthorized role assumption에 대한 강력한 보호를 모두 충족합니다. 주요 AWS 기능: 1) IAM Role + Trust Policy: trust policy는 principal(auditor account)과 조건(sts:ExternalId)을 지정합니다. 선택적으로 고객은 aws:PrincipalArn을 사용해 auditor account 내의 특정 role로 더 제한할 수 있습니다. 2) AWS STS Temporary Credentials: AssumeRole은 시간 제한이 있는 credentials를 반환하여 blast radius를 줄이고 key rotation 부담을 제거합니다. 3) Confused Deputy 완화: ExternalId는 third party가 고객 account에 access할 때 AWS가 권장하는 control로, auditor가 속아 다른 고객의 role에 access하도록 자신의 permissions를 사용하게 되는 것을 방지합니다. 4) Least Privilege Permissions Policy: actions를 ec2:Describe*, iam:Get*, s3:List*로 제한하고 가능하면 resources 범위를 지정합니다(모든 action이 resource-level constraints를 지원하는 것은 아님). 흔한 오해: Option C(ExternalId 없는 role)는 users/keys보다 낫지만, 핵심 third-party security control이 빠져 있어 독립 업체 시나리오에서 “MOST secure”는 아닙니다. Options A와 B는 long-term credentials에 의존하므로 best practices를 위반하고 leakage 및 misuse 위험을 증가시킵니다. 시험 팁: “third-party access”, “temporary credentials”, “least privilege”가 보이면: 고객이 IAM role을 만들고 auditor가 STS로 assume하는 패턴을 떠올리세요. vendor/independent auditor라면 trust policy에 ExternalId를 추가하세요. access keys 공유는 피해야 합니다. 이는 AWS IAM guidance 및 Well-Architected Security Pillar 원칙(identity foundation, least privilege, credential management)과 일치합니다.

문제 4

한 전국 소매 체인은 2,500개 매장에서 하루 4 TB의 POS(point-of-sale) 이벤트 로그를 수집한다. 로그는 매시간 Parquet 파일로 컴팩션되어 장기 실행 중인 Amazon EMR 클러스터의 Hadoop Distributed File System (HDFS)에 저장되며, 비즈니스 분석가들은 동일한 EMR 클러스터에서 Apache Trino (Presto)를 사용해 대화형 SQL을 실행한다. 각 쿼리는 수백 GB를 스캔하고 12분 이내에 완료되며, 쿼리는 평일 현지 시간 기준 오후 6:00부터 오후 11:00 사이에만 실행되고 동시 사용자는 최대 6명이다. 회사는 항상 켜져 있는 클러스터의 높은 비용을 우려하지만, 운영 오버헤드를 최소화하면서 SQL 쿼리를 계속 실행할 수 있는 가장 비용 효율적인 방법이 필요하다. 어떤 솔루션이 이러한 요구 사항을 충족하는가?

문제 분석

핵심 개념 - 이 문제는 이미 컬럼형 Parquet에 있는 데이터에 대해, 사용 시간이 제한되어 있고 운영을 최소화해야 하는 상황에서 가장 비용 효율적인 대화형 SQL 분석 패턴을 선택하는지를 평가한다. 이는 전형적인 “데이터 레이크에 대한 serverless 쿼리” 시나리오로, Amazon S3에 데이터를 저장하고 AWS Glue Data Catalog를 사용하는 Amazon Athena로 쿼리하는 방식이 적합하다. 정답이 맞는 이유 - 현재의 항상 켜져 있는 EMR 클러스터는, 쿼리가 평일 하루 5시간에만 실행되고 동시성이 제한적(최대 6명)임에도 컴퓨팅이 24/7 실행되기 때문에 비용이 높다. Parquet 데이터를 S3로 옮기고 Athena를 사용하면 클러스터 관리와 유휴 컴퓨팅 비용이 제거된다. Athena는 쿼리당 과금(스캔한 TB 기준)이며, Parquet는 원시 로그 대비 스캔 바이트를 크게 줄인다. 파티셔닝(예: 날짜/시간/매장 기준)과 컬럼 프루닝을 적용하면 각 쿼리가 “수백 GB”보다 훨씬 적은 데이터를 스캔할 수 있어 비용과 성능이 모두 개선되면서 대화형 요구를 충족한다. 주요 AWS 기능 - S3를 내구성 있는 데이터 레이크 스토리지로 사용한다. AWS Glue Data Catalog(또는 Athena의 partition projection)에 테이블/파티션을 등록하여 분석가들이 표준 SQL로 쿼리할 수 있게 한다. 모범 사례를 적용한다: event_date와 hour(그리고 선택적으로 region/store)로 파티션하고 Parquet + 압축(Snappy/ZSTD)을 사용한다. Athena workgroup을 사용해 비용 제어, 쿼리 제한, 중앙화된 결과 위치를 설정한다. 선택적으로 Athena result reuse와 CTAS/UNLOAD를 사용해 최적화된 파생 데이터셋을 생성한다. 흔한 오해 - Redshift Spectrum(옵션 A)은 S3를 쿼리할 수 있지만, 일반적으로 실행 중인 Redshift 클러스터(또는 serverless)가 필요하며, 보통 더 자주 사용되고 높은 동시성의 BI를 위해 데이터 웨어하우스가 이미 필요한 경우에 선택된다. EMR에서 Presto를 유지(옵션 C)하는 것은(일시적이라 하더라도) 여전히 클러스터를 관리해야 하며, 이 사용 사례에서는 Athena보다 운영 부담이 크다. Redshift로 적재(옵션 D)하는 것은 수집/유지보수 오버헤드와 지속적인 컴퓨팅 비용을 추가한다. 시험 팁 - 사용이 간헐적이고 요구 사항이 “운영 오버헤드 최소화”와 “가장 비용 효율적”을 강조한다면, 관리형 클러스터보다 serverless(Athena)를 우선 고려하라. Athena/Spectrum 문제에서는 Parquet/ORC + 파티셔닝이 스캔 비용을 제어하고 대화형 성능을 충족하는 핵심 포인트다. 강한 필요 없이 항상 켜져 있는 클러스터가 필요한 솔루션이라면, 대개 최선의 답이 아니다.

문제 5

(2개 선택)

솔루션 아키텍트가 1,200명의 소매 매장 관리자가 모바일 디바이스에서 주간 고객 피드백 양식을 제출할 수 있는 애플리케이션을 설계하고 있습니다. 분당 최대 6,000건의 피크 제출 중 약 80%가 일요일 오후 5:00~9:00 사이에 발생하며, 데이터는 비즈니스 분석가가 리전 수준의 월간 대시보드를 실행할 수 있는 형식으로 저장되어야 합니다. 또한 인프라는 고가용성을 유지하면서 수집과 분석 모두에 대해 탄력적으로 확장되어야 하고 운영 오버헤드는 최소화되어야 합니다. 어떤 단계 조합이 이러한 요구 사항을 충족합니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 스파이크 형태의 모바일 제출을 위한 고가용성, 탄력적 확장, 저운영(저-ops) 수집 계층과 월간 리전 수준 대시보드를 위한 확장 가능한 분석 계층을 설계하는 것을 평가합니다. 핵심 패턴은 serverless 수집(API Gateway + Lambda)과 data lake 분석(S3 + Athena + QuickSight)입니다. 정답이 맞는 이유: 옵션 C는 완전 관리형, multi-AZ, 자동 확장되는 프런트 엔드 및 API 계층을 제공합니다. Amazon S3 뒤에 CloudFront로 정적 프런트 엔드를 호스팅하면 웹 서빙을 오프로딩하고 전 세계 성능을 개선합니다. Amazon API Gateway를 AWS Lambda proxy integration과 함께 사용하면 서버 관리가 제거되며, 사전 프로비저닝 없이도 일요일 저녁 급증(분당 최대 6,000건 제출)을 처리하도록 빠르게 확장됩니다. 이는 “고가용성”, “탄력적 확장”, “최소 운영 오버헤드”를 충족합니다. 옵션 E는 제출 데이터를 Amazon S3에 저장하는데, 이는 장기 보관에 대해 고내구성이며 비용 효율적입니다. 비즈니스 분석가는 Amazon Athena(S3 위에서 serverless SQL)로 데이터를 직접 쿼리하고 Amazon QuickSight에서 월간 리전 수준 대시보드를 구축할 수 있습니다. 이 조합은 클러스터를 관리하지 않고도 분석을 확장할 수 있으며, data lake 접근 방식과 정렬되고, 월간 대시보드 쿼리를 최적화하기 위해 날짜/리전별 파티셔닝을 지원합니다. 주요 AWS 기능: API Gateway throttling/usage plans, Lambda concurrency scaling, CloudFront caching 및 TLS, S3 lifecycle policies, S3 partitioned prefixes(예: region=.../year=.../month=...), Athena Glue Data Catalog schemas, 그리고 대시보드 성능을 위한 QuickSight SPICE. 이는 Well-Architected(Operational Excellence, Reliability, Performance Efficiency, Cost Optimization)에 부합하는 선택입니다. 흔한 오해: EC2/ECS에서 예약 스케일링(A/B)은 예측 가능한 피크를 처리할 수 있지만, 여전히 용량 계획, 패치, 운영 관리가 필요하며 5~9 PM 구간 내 변동성에 대해 매끄럽게 대응하지 못할 수 있습니다. Redshift(D)는 데이터 웨어하우징에 강력하지만, 신중히 설계하지 않으면 클러스터 관리/비용이 추가되어 간헐적 수집/분석에 대해 “최소 ops”가 아닙니다. 시험 팁: “스파이크 트래픽”, “고가용성”, “최소 운영 오버헤드”가 보이면 serverless(S3/CloudFront, API Gateway, Lambda)를 강하게 고려하십시오. “저장된 데이터로부터 대시보드”를 저-ops로 구현하려면, 복잡한 조인/대규모 저지연 BI가 명시적으로 Redshift를 요구하지 않는 한, 데이터 웨어하우스를 관리하는 것보다 S3 + Athena + QuickSight를 선호하십시오.

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

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

문제 6

(3개 선택)

AWS Organizations의 18개 AWS 계정을 보유한 한 엔터프라이즈는 AWS Transit Gateway를 통해 멤버 VPC에 연결된 공유 네트워킹 계정 내 중앙 집중식 보안 VPC에서 수동으로 구성된 고가용성 Amazon EC2 인스턴스로 두 개의 타사 inline inspection appliance를 실행하고 있습니다. 각 appliance는 멤버 VPC에서 0.0.0.0/0의 다음 홉으로 정적 프라이빗 IP를 사용합니다. 최근 잘못 구성된 자동화 실행으로 두 인스턴스가 모두 종료되었고, 재구축하는 동안 팀은 첫 부팅 시 appliance를 구성하기 위한 bootstrap script를 만들었습니다. 이제 회사는 비용을 최소화하도록 현대화하고, 두 Availability Zone에 걸쳐 총 12 Gbps의 집계 트래픽을 처리하기 위해 2대에서 최소 10대의 appliance로 수평 확장하며, 60초 미만의 failover를 제공하면서 동일한 vendor code를 계속 사용하고자 합니다(vendor는 완전한 AWS 호환성을 확인함). 이러한 요구 사항을 가장 비용 효율적으로 충족하기 위해 솔루션 아키텍트가 권장해야 하는 단계 조합은 무엇입니까? (세 개 선택)

문제 분석

핵심 개념: 이 문제는 AWS에서 중앙 집중식 cross-account inline traffic inspection을 현대화하는 방법에 관한 것입니다. 즉, 취약한 정적 next-hop EC2 appliance를 Gateway Load Balancer (GWLB), Gateway Load Balancer endpoints (GWLBe), 그리고 Auto Scaling을 중심으로 구축된 확장 가능하고 복원력 있는 아키텍처로 대체하는 것입니다. GWLB는 third-party virtual appliance의 투명한 삽입을 위해 특별히 설계되었으며, AWS PrivateLink와 통합되어 private한 cross-account service consumption을 지원합니다. 정답인 이유: A가 정답인 이유는 GWLB가 inline inspection appliance에 적합한 load balancer이며, 이를 endpoint service를 통해 노출하면 다른 account의 member VPC가 inspection service를 private하게 사용할 수 있기 때문입니다. C가 정답인 이유는 launch template과 bootstrap user data를 사용하는 Auto Scaling group이 반복 가능한 appliance 배포, 자동 교체, 그리고 두 개의 Availability Zone에 걸친 horizontal scaling을 제공하기 때문입니다. E가 정답인 이유는 각 member VPC가 로컬 GWLBe 리소스를 생성하고 route table을 업데이트하여 정적 appliance IP에 의존하지 않고 traffic이 inspection service로 전달되도록 해야 하기 때문입니다. 주요 기능: GWLB는 GENEVE encapsulation을 사용하여 traffic을 appliance fleet으로 전달하면서도 security appliance에 필요한 flow context를 유지합니다. GWLBe 리소스는 consumer VPC에 배포되며 투명한 service insertion을 위한 route target 역할을 합니다. launch template과 user data를 사용하는 Auto Scaling은 수동 appliance 관리 대신 elastic하고 health 기반의 scaling을 통해 운영 위험과 비용을 줄여줍니다. 흔한 오해: PrivateLink와 함께 사용하는 Network Load Balancer는 투명한 inline inspection에 적합한 패턴이 아닙니다. 이는 route 기반 service insertion이 아니라 L4 service exposure를 위해 설계되었기 때문입니다. 또 다른 흔한 실수는 endpoint를 중앙 집중식 security VPC에 생성해야 한다고 생각하는 것이지만, 실제로는 consuming member VPC가 GWLB endpoint를 생성합니다. 또한 Auto Scaling group의 EC2 appliance에 대한 GWLB target group은 일반적으로 IP target이 아니라 instance target을 사용합니다. 시험 팁: 문제에서 third-party firewall, inline inspection, 중앙 집중식 security VPC, multi-account access, 그리고 route-table steering이 언급되면 GWLB + GWLBe + PrivateLink endpoint service를 떠올리세요. 시나리오에 수동 EC2 appliance와 빠른 복구 또는 horizontal scale 필요성도 언급된다면, launch template과 bootstrap automation을 사용하는 Auto Scaling도 함께 고려하세요. GWLB와 NLB를 혼동하지 않도록 주의하고, endpoint는 provider VPC가 아니라 consumer VPC에 배치해야 합니다.

문제 7

한 미디어-테크 회사가 전 세계 학습 포털을 운영하고 있으며, 웹 및 모바일 클라이언트는 ap-south-1의 Amazon S3 bucket(약 55 TB, 최대 12,000 requests/second)에 있는 정적 UI asset(CSS, JS, thumbnail)을 직접 HTTPS object URL로 가져옵니다. 회사는 이미 eu-west-1에 두 번째 S3 bucket을 생성했으며, 새 object에 대해 near-zero RPO의 multi-Region resiliency, 자동 read failover, application code 변경 없음, 가능한 한 최소의 운영 오버헤드를 요구합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 application 변경을 피하고 운영 오버헤드를 최소화하면서, Amazon S3의 static content에 대해 near-zero RPO와 automatic read failover를 갖춘 multi-Region 복원력을 테스트합니다. 핵심 서비스는 Region 간 데이터 내구성/가용성을 위한 Amazon S3 Cross-Region Replication (CRR)와 투명한 read failover를 위한 Amazon CloudFront origin failover (origin groups)입니다. 정답인 이유: Option C는 모든 요구 사항을 충족합니다. (1) 새 객체에 대한 near-zero RPO는 ap-south-1에서 eu-west-1로 S3 CRR을 활성화하여 달성되며, 새로 기록된 객체는 낮은 지연으로 비동기 복제됩니다(엄격한 zero는 아니지만 near-zero). (2) application code 변경 없이 automatic read failover는 S3 앞에 CloudFront를 두고 asset URL에 단일 CloudFront distribution domain name을 사용하여 달성됩니다. CloudFront origin groups는 primary S3 origin에서 secondary로 fail over할 수 있으며, primary가 구성된 failure status code를 반환하거나 도달할 수 없을 때 동작합니다. (3) 최소 운영 오버헤드는 CRR이 S3에서 관리되고(custom code 없음), CloudFront failover가 구성 기반이기 때문에 충족됩니다. 주요 AWS 기능: - 두 bucket 모두에서 versioning이 활성화된 S3 CRR. replication rule은 범위 지정(prefix/tags)할 수 있으며, 필요 시 delete marker도 복제할 수 있습니다. - origin group이 있는 CloudFront distribution: primary origin = ap-south-1 S3 bucket, secondary origin = eu-west-1 S3 bucket. failover criteria(예: 500/502/503/504)를 구성합니다. - HTTPS와 bucket 비공개 유지(best practice)를 위해 CloudFront와 함께 S3 REST endpoint를 사용합니다(S3 static website endpoint 아님). 이를 위해 Origin Access Control (OAC)을 사용합니다. 흔한 오해: - “Weighted Route 53”(Option A)은 automatic failover가 아니며, health check와 failover routing을 사용하지 않으면 비정상 Region으로도 트래픽을 보낼 수 있습니다. 또한 client가 새 DNS name을 사용하도록 변경해야 하므로(code/config 변경) 요구 사항에 맞지 않습니다. - “Lambda copy”(Option B)는 유연해 보일 수 있지만, 12,000 rps에서 운영 부담, scaling 문제, error handling, retry, 잠재적 replication gap을 추가합니다. 관리형 CRR보다 RPO도 더 나쁩니다. 시험 팁: multi-Region S3 복원력, near-zero RPO, minimal ops 같은 요구 사항이 보이면 기본적으로 S3 CRR/SRR(해당하는 경우)을 떠올리세요. “automatic read failover”와 “no app changes”가 보이면 단일의 안정적인 hostname과 함께 CloudFront origin groups(또는 Route 53 failover)를 찾으세요. 명시적으로 요구되지 않는 한 custom replication code는 피하세요.

문제 8

한 미디어 대기업은 단일 AWS Organizations 조직 내에서 3개의 OU에 걸쳐 12개의 AWS 계정을 운영하며, 모든 인프라는 오직 AWS CloudFormation으로만 프로비저닝합니다. 컴플라이언스 부서는 차지백(Chargeback) 모델을 구현해야 하며, 모든 신규 리소스에 키 cost-center 태그를 반드시 지정하되 허용된 값 CC-101, CC-202, CC-303 또는 CC-404 중 하나만 사용하도록 의무화했습니다. 그러나 AWS Cost Explorer에서 AWS Cost and Usage Report를 cost-center로 필터링했을 때, 지난 30일 동안 생성된 스택에서 누락되었거나 규정을 준수하지 않는 값이 다수 발견되었습니다. 운영 노력을 최소화하면서, 회사는 모든 OU 전반에서 CloudFormation으로 생성되는 신규 리소스에 cost-center 태그가 반드시 존재하도록 강제하고, 동시에 태그 값이 승인된 집합으로만 제한되도록 어떻게 적용해야 합니까?

문제 9

(3개 선택)

글로벌 보험 회사가 네트워크 및 보안 가드레일을 최종 확정한 후 워크로드 마이그레이션을 AWS로 가속화할 계획이며, 이미 공유 network-landing account에서 종단되는 전용 10 Gbps AWS Direct Connect를 프로비저닝했습니다. 12개월 내에 조직은 3개 Region에 걸쳐 약 300개의 AWS account와 약 900개의 VPC를 예상합니다. 기업 MPLS WAN은 모든 AWS 리소스에 대해 원활한 도달성을 가져야 하며, 모든 VPC는 중앙 허브를 통해 다른 VPC와 통신해야 합니다. 컴플라이언스를 위해 AWS 워크로드의 모든 아웃바운드 인터넷 트래픽은 온프레미스 데이터 센터의 차세대 방화벽을 통해 이그레스되어야 하며, AWS에서의 직접 인터넷 이그레스는 허용되지 않습니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 대규모로 충족하기 위한 단계 조합은 무엇입니까? (세 개 선택)

문제 분석

핵심 개념: 이 문제는 AWS Transit Gateway (TGW)를 허브로 사용하는 대규모 멀티 account, 멀티 VPC 연결, 프라이빗 WAN 연결을 위한 AWS Direct Connect (DX), 그리고 온프레미스 보안 appliance로의 중앙집중식 이그레스 제어(강제 터널링)를 테스트합니다. 정답이 맞는 이유: 제시된 규모(300 accounts, ~900 VPCs, 3 Regions)에서는 VPC-to-VPC 및 온프레미스 연결이 메시 설계를 피해야 합니다. TGW는 모든 VPC에 대해 확장 가능한 허브-앤-스포크 라우팅 도메인을 제공하며, transit virtual interface (transit VIF)를 사용해 DX를 통해 온프레미스와도 연결할 수 있습니다. 옵션 B는 올바른 기반을 구축합니다. 공유 네트워크 account에서 TGW를 생성하고, DX gateway를 생성하고, transit VIF를 생성한 다음, TGW를 DX gateway에 연결하여 기업 MPLS WAN이 프라이빗 라우팅으로 AWS 네트워크에 도달할 수 있게 합니다. 옵션 D는 조직 복잡성을 해결합니다. AWS RAM으로 TGW를 공유하면 멤버 account가 중앙 네트워킹 구성요소를 중복 생성하지 않고도 VPC attachment를 생성할 수 있어, 중앙 통제를 유지하면서 운영 오버헤드를 최소화합니다. 옵션 F는 컴플라이언스 요구 사항( AWS에서의 직접 인터넷 이그레스 금지)을 강제합니다. private subnet만 사용하고 TGW에서 온프레미스로 향하는 기본 라우트(0.0.0.0/0)를 DX를 통해 광고/전파하면, 모든 아웃바운드 인터넷 트래픽이 온프레미스 차세대 방화벽/NAT/egress appliance를 통해 강제로 통과합니다. 주요 AWS 기능: TGW route table(세그멘테이션, 전파, 연결), cross-account attachment를 위한 RAM 공유, 프라이빗 연결을 위한 DX transit VIF + DX gateway, 그리고 기본 트래픽을 온프레미스로 유도하는 중앙 라우팅입니다. 이는 검사(inspection)를 중앙화하고 네트워크 운영을 단순화함으로써 AWS Well-Architected(보안 및 신뢰성 원칙)와도 부합합니다. 흔한 오해: 많은 사람이 DX gateway를 각 VPC의 VGW에 연결해야 한다고 가정합니다(옵션 A). 이 패턴은 VPC당 VGW 연결을 제공할 수는 있지만, VPC-to-VPC 통신을 위한 중앙 허브를 제공하지 않으며 900 VPC 규모에서는 운영 부담이 큽니다. 또 다른 선택으로 단순함 때문에 IGW(옵션 C)를 고르기도 하지만, 이는 명시된 컴플라이언스 요구 사항을 위반합니다. VPC peering(옵션 E)은 직관적으로 보이지만 확장되지 않습니다(메시 증가, 라우트 관리, 전이 라우팅 부재). 시험 팁: “수백 개의 accounts/VPCs”와 “central hub”가 보이면 TGW + RAM을 떠올리십시오. “AWS에서 인터넷 이그레스 금지”가 보이면 private subnet + 강제 터널링(0.0.0.0/0)을 DX/VPN을 통해 온프레미스로 보내고 중앙 검사(inspection)를 적용하는 패턴을 떠올리십시오.

문제 10

글로벌 미디어 회사가 AWS Control Tower로 거버넌스되는 14개 계정의 AWS Organizations 환경을 운영하고 있으며, AWS Transit Gateway를 사용해 계정 전반의 VPC를 연결하고 있습니다. us-east-1 Region에서 분석 계정(Account ID: 222222222222)은 AWS Lambda와 Amazon Aurora MySQL DB cluster를 사용하는 마이크로서비스를 호스팅하고, 데이터 거버넌스 팀은 조직 전반의 데이터베이스를 관리하기 위해 별도의 보안 계정(Account ID: 111111111111)에서 private subnet의 단일 Amazon EC2 instance로 작업합니다. 분석 팀은 Aurora 자격 증명을 분석 계정의 AWS Secrets Manager에 secret으로 저장하며, 해당 secret은 us-east-1에서 Secrets Manager의 기본 AWS managed key(alias aws/secretsmanager)로 암호화되어 있습니다. 현재 분석 팀은 문제 해결을 위해 데이터 거버넌스 팀과 자격 증명을 수동으로 공유하고 있습니다. 솔루션스 아키텍트는 수동 공유 없이 EC2 instance의 보안 계정 관리자에게 Aurora 자격 증명에 대한 온디맨드 액세스를 제공해야 하며, 기존 secret을 재암호화하거나 암호화 키를 변경해서는 안 됩니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS Organizations/Control Tower 환경에서 AWS Secrets Manager secret에 대한 cross-account 액세스와, secret이 AWS managed key(alias aws/secretsmanager)로 암호화되어 있을 때 Secrets Manager와 AWS KMS 간의 상호작용을 테스트합니다. 또한 온디맨드 관리 액세스를 위한 IAM role assumption의 올바른 사용도 테스트합니다. 정답인 이유: Option B가 정답인 이유는 기본 AWS managed KMS key로 암호화된 secret에 대해 다른 계정에 액세스를 부여하는 유일하게 지원되는 방법이 secret을 소유한 계정(분석)에서 cross-account IAM role을 사용하고, 다른 계정(보안)의 principal이 이를 assume하도록 허용하는 것이기 때문입니다. AWS managed key는 key policy를 수정하여 cross-account principal을 추가할 수 없으며, AWS RAM을 통해 Secrets Manager secret을 cross-account로 “공유”할 수도 없습니다. B에서는 EC2 instance가 연결된 role(Sec-DBA)을 사용해 분석 계정의 role(Analytics-SecretAccess)로 sts:AssumeRole을 호출합니다. 그런 다음 assume된 role이 secret과 동일한 계정에서 secretsmanager:GetSecretValue(및 필요 시 DescribeSecret)를 호출하므로, KMS decrypt가 분석 계정 컨텍스트에서 수행되어 AWS managed key로도 동작하며 재암호화나 키 변경이 필요 없습니다. 주요 AWS 기능: - STS AssumeRole을 사용한 계정 간 IAM role chaining. - 최소 권한: Analytics-SecretAccess를 특정 secret ARN과 필요한 action으로 범위 제한. - Secrets Manager resource policy를 사용해 어떤 principal(분석 role)이 secret에 액세스할 수 있는지 추가로 제한 가능. - 운영 모범 사례: session tagging/MFA/CloudTrail을 사용해 누가 언제 role을 assume했는지 감사. 일반적인 오해: A는 AWS RAM이 리소스를 공유하므로 그럴듯하지만, Secrets Manager secret은 RAM으로 공유 가능한 리소스가 아닙니다. C는 KMS 권한을 언급하므로 그럴듯하지만, AWS managed KMS key는 key policy 편집을 허용하지 않으며 해당 방식으로 cross-account decrypt grant를 줄 수 없습니다. D는 SCP를 오용합니다. SCP는 가드레일(최대 권한)만 설정할 뿐 권한을 부여하지 않으며, cross-account secret retrieval을 활성화할 수 없습니다. 시험 팁: “default AWS managed KMS key”와 “키 변경/재암호화 금지”가 보이면 key policy를 조정할 수 없다는 뜻이므로, 소유 계정의 보안 경계 내에서 secret에 액세스해야 합니다(해당 계정의 role을 assume). 또한 SCP는 제한만 하고, RAM은 지원되는 리소스 유형만 공유하며, cross-account 액세스에는 일반적으로 IAM trust policy(role assumption)와 대상 서비스에 대한 권한(KMS 고려 포함)이 모두 필요하다는 점을 기억하십시오.

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(9)

다른 모의고사

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

지금 학습 시작하기