연습 문제

문제 1

한 ad-tech 스타트업이 Amazon API Gateway와 AWS Lambda로 메트릭 수집 API를 구축하고 있습니다. Python 3.11로 작성된 12개의 Lambda 함수 전반에서, 팀은 중앙 플랫폼 팀이 유지 관리하는 5개의 내부 라이브러리와 커스텀 클래스(압축 시 약 15 MB)를 재사용해야 합니다. 보안 팀은 프로덕션 배포가 승인된 레지스트리에서만 아티팩트를 가져오도록 요구합니다. Amazon ECR은 승인되었지만, 빌드 작업은 프로덕션 계정에서 S3로 아티팩트를 업로드할 수 없습니다. 솔루션스 아키텍트는 모든 함수에 대한 배포를 단순화하고, 최소한의 패키징 복잡도로 코드 재사용을 극대화해야 합니다. 어떤 접근 방식이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS Lambda 배포 패키징 선택( ZIP vs container images), 코드 재사용 전략(layers vs 공유 base images), 그리고 공급망 제어(예: Amazon ECR과 같은 승인된 아티팩트 레지스트리)를 테스트합니다. 또한 여러 함수에 걸친 Lambda 제한과 운영 단순성도 간접적으로 테스트합니다. 정답인 이유: Option D가 모든 제약을 가장 잘 충족합니다. 보안 팀은 프로덕션 배포가 승인된 레지스트리(ECR 승인)에서만 아티팩트를 가져오도록 요구하며, 빌드 작업은 프로덕션 계정에서 S3로 아티팩트를 업로드할 수 없습니다. Lambda의 container image 지원을 사용하면 각 함수의 배포 패키지가 ECR에 저장된 OCI image가 되어, 프로덕션 계정의 S3에 ZIP 또는 layer 아티팩트를 둘 필요가 없습니다. 코드 재사용은 15 MB(압축) 내부 라이브러리와 공유 클래스를 포함하는 공통 base image로 표준화하여 달성하며, 각 함수 image는 handler 코드만 추가합니다. 이 접근 방식은 공유 의존성을 base image에서 한 번만 관리하고 일관되게 상속하므로 12개 함수에 대한 패키징 복잡도를 최소화합니다. 주요 AWS 기능: - Amazon ECR에 저장된 image로 AWS Lambda container image 지원(최대 10 GB image size). - 재사용을 극대화하고 중복을 줄이기 위한 Docker multi-stage builds 및 공유 base image 패턴. - 거버넌스 및 보안 요구 사항을 충족하기 위한 ECR repository policies, image scanning, immutable tags, lifecycle policies. - CI/CD가 image를 빌드하여 ECR에 push하고, 배포는 Lambda function image URI/digest를 업데이트. 흔한 오해: A와 B는 Lambda layers가 전통적인 재사용 메커니즘이기 때문에 매력적으로 보일 수 있습니다. 그러나 Lambda layers는 설명된 방식처럼 “ECR의 Docker image로부터” 생성되지 않습니다. layers는 ZIP archives로 게시됩니다(일반적으로 Lambda에 업로드되며, 배포 도구에서는 종종 S3를 소스로 사용). 또한 A는 S3를 아티팩트 저장소로 사용하므로 “승인된 레지스트리” 요구 사항을 위반하고, B는 ECR이 layer를 직접 백엔드로 제공할 수 있다고 잘못 가정합니다. C는 Lambda가 실행 중인 ECS/Fargate container를 layer로 참조할 수 없기 때문에 틀립니다. layers는 네트워크로 연결된 런타임 의존성 서비스가 아니라 정적 아티팩트입니다. 시험 팁: “승인된 레지스트리 = ECR” 및 S3 아티팩트 업로드 제한을 보면 Lambda container images를 강하게 고려하십시오. ZIP 기반 함수에는 layers를 사용하지만, 엄격한 레지스트리 기반 공급망 제어와 단순화된 의존성 재사용을 위해서는 ECR의 공유 base image가 종종 가장 깔끔한 패턴입니다. 또한 기억하십시오: Lambda layers는 ZIP 기반이며, Lambda container images는 ECR에서 pull됩니다.

문제 2

(3개 선택)

한 여행 기술 회사는 Amazon API Gateway에서 Regional endpoint와 AWS Lambda 백엔드를 사용하여 파트너 webhook ingestion API를 운영하고 있습니다. 이 Lambda는 AWS Key Management Service (AWS KMS)에서 customer managed key로 암호화된 AWS Secrets Manager에 저장된 API key를 사용해 third-party risk-scoring REST API를 호출하고, Amazon DynamoDB global table에서 레코드를 저장 및 조회하며, 현재 us-east-1에만 배포되어 있습니다. 회사는 운영 오버헤드를 최소화하면서 워크로드가 us-east-1, eu-west-1, ap-southeast-2 전반에서 active-active로 실행되도록 API 구성 요소를 변경해야 합니다. 다음 변경 조합 중 어떤 것이 이러한 요구 사항을 충족합니까? (세 개 선택)

문제 분석

핵심 개념: 이 문제는 API Gateway + Lambda 기반의 active-active, multi-Region API를 설계하고, 운영 오버헤드를 최소화하면서 multi-Region 종속성(Secrets Manager 및 KMS)을 처리하는지를 평가합니다. 또한 API Gateway와 KMS에서 무엇이 “multi-Region”인지/아닌지에 대한 이해도 간접적으로 확인합니다. 정답이 맞는 이유: us-east-1, eu-west-1, ap-southeast-2에서 active-active로 실행하려면 각 Region에 Regional API Gateway와 Lambda를 배포하고, 클라이언트를 정상 endpoint로 라우팅하는 글로벌 진입점을 제공해야 합니다. 옵션 A는 각 Regional API endpoint에 매핑된 Route 53의 custom domain과 라우팅 정책(multivalue)을 사용하여 여러 정상 endpoint를 반환할 수 있으므로 이를 달성합니다. Lambda function은 customer managed KMS key로 암호화된 Secrets Manager의 API key를 읽으므로, secret이 각 Region에서 사용 가능하고 로컬에서 복호화될 수 있도록 해야 합니다. Secrets Manager는 Region 간 secret replication을 지원하지만, 각 replica는 해당 Region의 KMS key를 사용합니다. 가장 낮은 오버헤드 접근 방식은 KMS multi-Region customer managed key(옵션 B)를 사용해 각 Region에 replica를 만든 다음, secret을 복제하고 replica별로 적절한 KMS key를 선택하는 것(옵션 C)입니다. 이는 수동 secret 복사를 피하고 key 관리의 일관성을 단순화합니다. 주요 AWS 기능: - API Gateway Regional endpoint는 Region 범위로 제한되며, multi-Region을 위해서는 별도 배포가 필요합니다. - Route 53 custom domain + health check + multivalue(또는 latency/failover 같은 다른 정책)는 글로벌 라우팅을 제공합니다. - AWS KMS multi-Region key는 다른 Region으로 복제되는 일관된 key material을 허용합니다(각 Region별로 별도의 key ARN은 유지). - Secrets Manager cross-Region replication은 secret 값을 동기화 상태로 유지하며 Region별 KMS 암호화를 지원합니다. 흔한 오해: - API Gateway에 여러 Lambda 백엔드를 연결하는 “multi-Region 옵션”이 있다고 가정하는 것(없음; 배포는 Region별). - 기존 single-Region CMK를 multi-Region key로 “변환”할 수 있다고 생각하는 것(multi-Region key는 새로 생성해야 함). - secret을 수동으로 복사하는 것이 간단해 보이지만 운영 오버헤드와 드리프트 위험을 증가시킴. 시험 팁: active-active multi-Region에서는 (1) Region별 compute/API 배포, (2) health check를 포함한 글로벌 DNS 라우팅, (3) state/secret/key의 적절한 복제를 찾으세요. KMS multi-Region key는 처음부터 multi-Region으로 생성해야 하며, Secrets Manager replication은 수동 복제 대비 운영 부담이 낮은 관리형 방식임을 기억하세요.

문제 3

미디어 분석 스타트업이 서드파티 썸네일 렌더링 엔진을 AWS로 마이그레이션해야 합니다. 벤더는 퍼블릭 registry에서 지원되는 Docker image를 제공하며, 이는 원하는 수만큼의 container에서 실행할 수 있습니다. 회사에는 12개의 콘텐츠 카테고리(Kids, Sports, News 등)가 있으며, 각 카테고리가 자체적으로 격리된 container 세트를 작은 커스텀 구성(카테고리별 environment variables 및 S3 prefix filters)과 함께 실행하여 각 container가 해당 카테고리만 처리하도록 하길 원합니다. 피크 로드에서는 카테고리당 최대 50개의 동시 container가 필요하며, 작업은 3–5분 지속되고 persistent storage는 필요하지 않습니다. 재무팀은 실행 중인 단위에 대한 tag를 사용해 카테고리별 비용 할당을 요구하고, 운영팀은 가능한 한 운영 오버헤드를 최소화하면서 실행 중인 container 수에만 기반해 비용 효율적으로 리소스를 스케일할 수 있어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 짧은 수명의 버스트성 워크로드에 대해 가장 낮은 운영 부담의 container orchestration 접근 방식을 선택하면서 격리 및 비용 할당 요구 사항을 충족하는지를 평가합니다. 핵심 서비스는 Amazon ECS with AWS Fargate(serverless containers)와 AWS tagging/Cost Allocation Tags입니다. 정답이 맞는 이유: 옵션 D(ECS on Fargate + run-task + task tags + ECS managed tags)가 모든 제약 조건에 가장 부합합니다. 벤더가 Docker image를 제공하므로 ECS task에 쉽게 적합하고, 작업은 일시적(3–5분)이며 stateless(persistent storage 불필요)이고, 피크 버스트가 큽니다(12개 카테고리 각각 최대 50개의 동시 container). Fargate는 EC2 node를 프로비저닝/스케일할 필요를 제거하고, 운영팀이 더 많은 task를 실행하는 것만으로 순수하게 스케일할 수 있게 합니다. 카테고리별 격리는 카테고리별로 별도의 ECS service 또는 task definition을 실행하거나(또는 run time에 카테고리별 environment variables/command overrides 및 S3 prefix filters를 전달) 달성할 수 있습니다. 재무팀의 카테고리별 비용 할당은 각 task에 카테고리 tag를 부여함으로써 해결되며, ECS는 tag 전파 및 관리(enableECSManagedTags)와 run-task에서 tag 전달을 지원하므로 AWS Cost Explorer 및 상세 청구에서 활성화할 수 있습니다. 주요 AWS 기능: - AWS Fargate: container를 위한 serverless compute, cluster capacity 관리 불필요, task 수로 스케일. - ECS run-task / services: 다수의 짧은 수명 task를 간단히 실행, environment variables에 대한 overrides 지원. - Resource tagging: 비용 할당을 위한 ECS task tags(및 managed tags), AWS Billing Cost Allocation Tags와 정렬. - 격리 패턴: 카테고리별 별도 ECS services, 별도 task definitions, 또는 필요 시 서로 다른 IAM roles/task roles 및 security groups. 흔한 오해: EKS도 Fargate에서 실행할 수 있지만, Kubernetes 운영 오버헤드(cluster add-ons, RBAC, networking, upgrades)를 유발하여 “가능한 한 운영 오버헤드를 최소화” 요구와 충돌합니다. 또한 “pods”에 대한 tagging은 비용 할당에 사용되는 AWS resource tags와 동일하지 않습니다. Kubernetes labels/annotations는 자동으로 AWS cost allocation tags가 되지 않습니다. 시험 팁: “short-lived containers”, “no persistent storage”, “burst scaling”, “least ops”를 보면 강한 Kubernetes 요구가 없는 한 기본적으로 ECS on Fargate를 선택하십시오. 비용 할당의 경우, in-cluster metadata(pod labels)가 아니라 청구 가능한 리소스(tasks/services)에 대한 AWS resource tags를 찾으십시오.

문제 4

한 의료 분석 회사가 AWS eu-central-1에서 HIPAA 준수 내부 웹 애플리케이션을 운영하고 있다. 이 회사는 프랑크푸르트 데이터 센터에서 애플리케이션이 실행되는 VPC로 연결되는 1 Gbps AWS Direct Connect private VIF를 보유하고 있으며, 애플리케이션은 내부 Application Load Balancer (ALB) 뒤에서 세 개의 Availability Zone에 걸친 Amazon EC2 인스턴스에서 실행된다. 직원들은 온프레미스 네트워크에서 HTTPS를 통해 앱에 액세스하며, TLS는 ALB에서 종료되고 ALB는 /api, /images, /admin에 대해 경로 기반 라우팅을 사용하는 여러 target group을 사용한다. 네트워크 팀은 목적지 IP 주소의 allow list로만 아웃바운드 트래픽을 허용하는 온프레미스 차세대 방화벽을 배포하고 있으며, 회사는 애플리케이션을 변경하지 않고 ALB에서 TLS 종료와 라우팅을 유지해야 한다. 정적 IP 주소로 allow list 요구 사항을 충족하면서 온프레미스에서의 지속적인 액세스를 가능하게 하는 솔루션은 무엇인가?

문제 분석

핵심 개념: 이 문제는 클라이언트에 대해 정적(allow list 가능한) IP 주소를 제공하면서 Application Load Balancer (ALB)의 Layer 7 기능(TLS 종료 및 경로 기반 라우팅)을 유지하는 방법을 테스트한다. ALB는 고정 IP를 지원하지 않으며, Network Load Balancer (NLB)는 Elastic IP (EIP)를 통해 정적 IP를 사용할 수 있다. 정답이 맞는 이유: 기존 내부 ALB 앞에 NLB를 배치하면 온프레미스 클라이언트가 방화벽에서 allow list로 등록할 수 있는 안정적인 EIP(각 AZ당 1개)로 연결할 수 있다. NLB는 트래픽을 ALB로 전달( ALB-type target group 사용)하고, ALB는 애플리케이션 변경 없이 /api, /images, /admin에 대한 경로 기반 라우팅을 수행하면서 TLS 종료를 계속 담당한다. 이는 ALB에서 TLS 종료와 라우팅을 유지해야 한다는 요구 사항을 충족하는 동시에 온프레미스 방화벽의 목적지 IP allow list 제약도 만족한다. 주요 AWS 기능: - NLB는 Availability Zone별로 EIP를 연결하여 정적 IP 주소를 지원하므로 엄격한 방화벽 allow list에 이상적이다. - NLB는 ALB-type target group을 사용하여 ALB를 대상으로 지정할 수 있어 L4 패스스루를 L7 로드 밸런서로 전달할 수 있다. - ALB는 HTTPS listener, 인증서 관리(ACM), 여러 target group에 걸친 경로 기반 라우팅을 유지한다. - Direct Connect private VIF와 함께 동작하는데, 트래픽이 VPC 내에서 프라이빗하게 유지되며 클라이언트는 단지 NLB 엔드포인트를 resolve/연결하면 된다. 흔한 오해: A는 “ALB에 EIP를 할당”한다고 제안하기 때문에 그럴듯하지만, ALB는 EIP 또는 정적 IP를 지원하지 않으며 IP가 변경될 수 있다. C는 NLB가 정적 IP를 제공하므로 그럴듯하지만, NLB는 Layer 4이며 경로 기반 라우팅을 할 수 없으므로 target group을 마이그레이션하면 라우팅 요구 사항을 깨뜨린다. D는 Gateway Load Balancer를 잘못 사용한 것으로, GWLB는 GENEVE를 통해 가상 어플라이언스를 삽입하기 위한 것이지 웹 앱 앞단에 두거나 L7 라우팅을 제공하기 위한 것이 아니다. 시험 팁: “정적 IP 필요”와 “ALB 기능 유지”가 함께 보이면 “ALB 앞에 NLB”를 떠올려라. 기억할 점: ALB = L7(호스트/경로 라우팅, TLS 종료), NLB = L4(정적 IP/EIP, 고성능). GWLB는 방화벽/어플라이언스 삽입용이지 클라이언트가 접근하는 웹 액세스용이 아니다.

문제 5

한 디지털 티켓팅 회사가 현재 정적 웹 프런트엔드, checkout/database APIs, 그리고 결제 오케스트레이션 로직을 제공하는 모놀리식 로드 밸런싱된 Amazon EC2 플릿에서 실행 중인 checkout 애플리케이션을 현대화하고 있습니다. 회사는 평균 시간당 10,000건의 checkout을 처리하고 10분 내 최대 30,000건까지 버스트가 발생할 수 있으며, 실패한 checkout 이벤트를 나중에 재처리(replay)할 수 있도록 최소 7일 동안 보관하고, 각 구성 요소를 독립적으로 확장하며, 서버 관리를 제거하여 운영 비용을 최소화할 수 있는 완전히 분리된(serverless-first) 아키텍처를 원합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 관리형 이벤트 버퍼링(SQS), 서버리스 컴퓨팅(Lambda), 그리고 내구성 있는 보관을 통한 실패 처리(dead-letter queues)를 사용하여 버스트를 흡수하고 재처리를 가능하게 하는 serverless-first 분리형 설계를 테스트합니다. 정답이 맞는 이유: 옵션 C는 완전히 분리된 아키텍처를 제공합니다. S3는 서버 없이 정적 프런트엔드를 호스팅하고, API Gateway는 checkout/database APIs를 위한 관리형으로 확장 가능한 API 계층을 제공합니다. SQS Standard는 checkout 이벤트를 버퍼링하여 요청 수집을 결제 처리로부터 분리하고, 버스트 트래픽(10분 내 30,000건)을 흡수합니다. Lambda는 SQS event source mapping과 함께 자동으로 확장되어 인스턴스/컨테이너를 관리하지 않고도 결제 오케스트레이션 로직을 독립적으로 확장할 수 있습니다. 실패한 메시지는 최대 14일까지 메시지 보관 기간을 구성할 수 있는 SQS dead-letter queue (DLQ)로 라우팅되어 “실패한 checkout 이벤트를 최소 7일 동안 보관” 요구 사항을 충족하며, DLQ에서 소스 큐로 메시지를 redrive하여 나중에 재처리할 수 있습니다. 주요 AWS 기능: - Amazon SQS Standard: 사실상 무제한 처리량, at-least-once 전달, 그리고 버스트를 완화하기 위한 버퍼링. - SQS retention: 1분~14일로 구성 가능; DLQ retention을 >= 7일로 설정. - Lambda + SQS 통합: polling 및 batching을 통한 자동 확장; 성공한 항목에 대한 재시도를 줄이기 위해 partial batch response를 지원. - API Gateway: 관리형 확장, throttling, auth, 그리고 Lambda 또는 기타 백엔드와의 통합. - S3 static website hosting: 저비용의 높은 내구성을 갖춘 정적 콘텐츠 제공(프롬프트에서 요구하지는 않지만 종종 CloudFront와 함께 사용). 흔한 오해: 흔한 함정은 “queue + containers”가 여전히 서버리스라고 가정하는 것입니다. ECS는 일부 운영 부담을 줄이지만, Lambda에 비해 여전히 클러스터/태스크 사이징, 확장 정책, 패치 책임이 필요합니다(Fargate가 더 가깝습니다). 또 다른 오해는 운영 재처리를 위해 아카이브 스토리지(예: Glacier Deep Archive)를 사용하는 것인데, 이는 빠른 redrive 워크플로를 위해 설계되지 않았습니다. 시험 팁: “serverless-first”, “bursty traffic”, “decouple components”, “retain failed events for replay”를 보면 다음을 떠올리세요: 프런트 도어로 API Gateway/S3, 버퍼링을 위한 SQS, 컴퓨팅을 위한 Lambda, 그리고 실패 처리를 위한 retention/redrive가 있는 DLQ. 또한 SQS 최대 retention은 14일이므로 “7일”은 SQS DLQ가 깔끔하게 맞는 선택지임을 강하게 시사합니다.

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

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

문제 6

한 비디오 주석(annotaion) 회사가 Docker 기반 태깅 서비스를 AWS로 리플랫폼하고 있습니다. 이 서비스는 두 개의 Availability Zone에 걸쳐 최대 200개의 task가 동시에 접근할 수 있는, /data에 마운트되는 공유 POSIX 준수 NFSv4 마운트가 필요합니다. 또한 온디맨드로 확장되어야 하고, 저장 데이터(at rest) 암호화를 지원해야 하며, IAM으로 접근을 제어해야 하고, 어떤 서버나 클러스터 인프라를 프로비저닝하거나 관리할 필요가 없어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 여러 Availability Zone에 걸쳐 많은 동시 task가 사용하는 공유 POSIX 파일 스토리지를, 서버리스 컨테이너 컴퓨팅과 함께 올바르게 선택하는지를 테스트합니다. 핵심 서비스는 AWS Fargate의 Amazon ECS(서버/클러스터 관리 불필요)와 Amazon EFS(관리형 NFSv4, multi-AZ, 탄력적)입니다. 정답이 맞는 이유: 이 워크로드는 /data에 마운트되는 공유 POSIX 준수 NFSv4 마운트가 필요하며, 두 AZ에 걸쳐 최대 200개의 task가 동시에 접근할 수 있어야 하고, 온디맨드로 확장되며, at rest 암호화를 제공하고, IAM으로 접근을 제어해야 하며, 서버를 프로비저닝하거나 관리하지 않아야 합니다. Amazon EFS는 완전 관리형 탄력적 NFS 파일 시스템으로 NFSv4.1을 지원하고 POSIX 시맨틱을 제공하며, 여러 AZ에 걸쳐 많은 클라이언트의 동시 접근을 위해 설계되었습니다. ECS Fargate는 EC2 instance나 ECS cluster의 기반 용량을 관리할 필요를 제거합니다. EFS는 task definition의 volume 구성으로 Fargate task에서 직접 마운트할 수 있어 “서버 불필요” 요구 사항을 충족합니다. 주요 AWS 기능: - EFS multi-AZ 가용성: EFS는 Region 내 여러 AZ에 걸쳐 데이터를 중복 저장하여, 서로 다른 AZ의 task에서 동시 접근이 가능합니다. - 탄력적 확장: EFS는 수요에 따라 throughput/스토리지를 자동으로 확장합니다(필요 시 throughput mode 사용 가능). - 암호화: EFS는 at rest(KMS) 및 in transit(TLS) 암호화를 지원합니다. - IAM 접근 제어: EFS는 NFS client에 대한 IAM authorization(EFS mount helper/IAM 통합 사용 시)과, 특정 POSIX identity 및 root directory를 강제하는 EFS Access Point를 지원하므로, 일관된 권한으로 /data에 마운트하는 데 이상적입니다. - Fargate 통합: ECS task definition에서 instance를 관리하지 않고도 EFS volume과 mount point를 지정할 수 있습니다. 흔한 오해: FSx for Lustre도 공유 POSIX 파일 시스템이지만, HPC에 최적화되어 있고 일반적으로 S3와 통합되어 사용됩니다. 컨테이너용 NFSv4 공유 스토리지의 표준 선택지는 아니며, 시험에서 자주 다루는 IAM/EFS access point 패턴과도 깔끔하게 맞지 않습니다. EC2 launch type 옵션은 EFS가 잘 동작하므로 가능해 보일 수 있지만, 서버를 프로비저닝/관리하지 말라는 요구 사항을 위반합니다. EBS Multi-Attach는 block storage이며 제약이 많고 NFS 공유 파일 시스템이 아닙니다. 시험 팁: “shared POSIX, NFSv4, multi-AZ, 많은 동시 컨테이너, serverless/인프라 관리 불필요”를 보면 “ECS Fargate + EFS (Access Points + encryption + IAM/TLS)”로 매핑하세요. FSx for Lustre는 HPC/고성능 scratch에, EBS는 단일 instance(또는 제한적인 multi-attach) block storage에 해당하며, 공유 NFS 마운트에는 해당하지 않습니다.

문제 7

(3개 선택)

한 연구실이 Amazon EFS file system에 수백만 개의 shared file을 기록하는 AWS HPC cluster에서 MPI 기반의 tightly coupled seismic inversion workload를 실행하고 있습니다. 이 job은 120개의 EC2 compute node로는 성능 목표를 충족했지만, cluster를 1,200개 node로 확장하자 I/O 및 inter-node communication bottleneck으로 인해 전체 throughput과 time-to-solution이 크게 저하되었습니다. HPC cluster의 성능을 최대화하기 위해 solutions architect가 구현해야 할 설계 선택의 조합은 무엇입니까? (세 개를 선택하세요.)

문제 분석

핵심 개념: 이 문제는 대규모 tightly coupled MPI workload에 대한 AWS HPC 설계를 평가하며, low-latency networking과 high-concurrency shared file system 성능에 초점을 둡니다. 핵심 서비스/개념은 placement/latency(단일 AZ), MPI를 위한 Elastic Fabric Adapter(EFA), 그리고 극단적인 metadata 및 small-file I/O에 대해 Amazon EFS 대신 parallel file system(Amazon FSx for Lustre)을 사용하는 것입니다. 정답이 맞는 이유: 1,200개 node에서는 inter-node communication과 shared storage가 모두 지배적인 bottleneck이 됩니다. (A)는 모든 node를 하나의 Availability Zone에 유지하여 cross-AZ latency, jitter, bandwidth 제약을 피하는데, 이는 tightly coupled MPI collective에 특히 치명적입니다. (C)는 지원되는 instance type에서 EFA를 활성화하여 (libfabric를 통한) OS-bypass와 매우 낮은 latency/높은 message rate networking을 제공하므로, 표준 ENA networking보다 MPI 성능 확장성이 훨씬 좋습니다. (F)는 EFS를 FSx for Lustre(scratch)로 교체하는데, 이는 HPC를 위해 설계된 고성능 parallel file system으로 높은 aggregate throughput과 metadata 성능을 제공하며, “수백만 개의 shared file”과 높은 concurrent access에 적합합니다. 주요 AWS 기능: Single-AZ cluster placement는 network variability를 줄이고 cluster placement group(일반적으로 HPC와 함께 사용됨)을 최적으로 활용할 수 있게 합니다. EFA는 MPI stack과 통합되어 tightly coupled job의 latency와 throughput을 개선합니다. FSx for Lustre는 확장 가능한 throughput/IOPS를 제공하고 Amazon S3와의 통합(import/export)을 지원하여, Lustre file system을 빠른 scratch/work space로 사용하면서 durable data repository를 구성할 수 있습니다. 흔한 오해: AZ에 걸쳐 분산(D)하면 resiliency는 좋아지지만, tightly coupled HPC 성능은 보통 latency 증가와 determinism 저하로 악화됩니다. ENI 추가(B)는 MPI latency를 의미 있게 개선하지 못하며 HPC interconnect 성능을 확장하는 표준 방법이 아닙니다. EFA가 목적에 맞게 설계된 솔루션입니다. 단일 instance에 RAID0 EBS를 “shared storage”로 사용하는(E) 방식은 심각한 single-node bottleneck과 single point of failure를 만들며, 1,200개 node의 높은 metadata concurrency를 감당할 수 없습니다. 시험 팁: Tightly coupled MPI의 경우 low latency, low jitter, high message rate를 우선시하세요(single AZ + EFA). 대규모 shared-file concurrency에는 범용 NFS(EFS)보다 parallel file system(FSx for Lustre)을 선택하세요. Multi-AZ는 workload가 loosely coupled이거나 명시적으로 HA가 요구되지 않는 한, tightly coupled HPC 성능 문제에서는 보통 경고 신호입니다.

문제 8

한 제약 연구 회사는 태그된 각 빌드마다 수명이 짧은 검증 샌드박스를 신속히 생성해야 합니다. 각 샌드박스는 Auto Scaling group에서 관리되는 단일 Amazon EC2 instance이며, 결과를 보고하기 위해 TCP 8443으로 온프레미스 라이선스 서버에 연결되어야 합니다. 이 회사는 영업일 기준 하루 최대 30개의 샌드박스를 생성 및 삭제해야 하며, 각 샌드박스는 3시간 미만으로 유지됩니다. 수동 개입 없이, 온프레미스 네트워크(172.16.0.0/16)로의 일관된 연결성이 필요합니다. 회사는 이미 데이터 센터로의 Site-to-Site VPN이 연결된 AWS Transit Gateway(tgw-0abc123def4567890)를 운영 중이며, 운영 오버헤드가 가장 적은 솔루션을 원합니다. 어떤 접근 방식이 이러한 요구 사항을 가장 잘 충족합니까?

문제 분석

핵심 개념: 이 문제는 운영 오버헤드를 최소화하면서 일관된 하이브리드 연결성을 갖춘 임시(ephemeral) 환경을 설계하는지를 평가합니다. 주요 서비스/개념은 AWS Transit Gateway(TGW) attachments 및 라우팅, VPC 공유/재사용, 그리고 반복 가능한 샌드박스 프로비저닝을 위한 infrastructure as code(CloudFormation)입니다. 정답이 맞는 이유: Option B는 기존 TGW + Site-to-Site VPN을 통해 온프레미스 네트워크(172.16.0.0/16)로의 신뢰할 수 있는 연결성을 보장하면서도 운영 부담이 가장 적은 설계입니다. 단일 공유 VPC에 하나의 TGW VPC attachment와 안정적인 route tables를 사용하면 네트워크 구성 요소는 한 번만 생성하고 재사용할 수 있습니다. 각 샌드박스는 사전 구성된 subnets 및 security groups에 Auto Scaling group/EC2 instance만 실행하면 되므로, 하루 최대 30회까지 빠르게 생성/삭제할 수 있고, 반복적인 TGW attachment 라이프사이클 작업(복잡성, 시간, 잠재적 장애 지점 증가)을 피할 수 있습니다. 주요 AWS 기능 / 구성: - 공유 샌드박스 VPC에서 tgw-0abc123def4567890으로의 TGW VPC attachment. - VPC route tables: 172.16.0.0/16에 대한 라우트를 TGW attachment로 향하도록 추가하고, TGW route tables에 해당 attachment를 통해 10.20.0.0/16(또는 선택한 VPC CIDR)로의 반환 라우트가 있도록 보장. - Security groups/NACLs: 172.16.0.0/16으로의 outbound TCP 8443을 허용하고 반환 트래픽을 허용(상태 저장(stateful) SGs가 이를 단순화). 온프레미스 firewall은 VPC CIDR이 8443에서 라이선스 서버에 도달하도록 허용해야 함. - CloudFormation으로 태그된 빌드별로 ASG/Launch Template/Instance Profile을 생성/삭제하고, tags를 라이프사이클 자동화에 사용. 흔한 오해: 샌드박스마다 완전히 새로운 VPC와 TGW attachment를 생성하는 것(Option A)이 더 “깔끔”해 보일 수 있지만, 이는 네트워킹 리소스를 증폭시키고 수명이 짧은 워크로드에 대해 운영 리스크를 증가시킵니다. 샌드박스마다 새 account를 생성하는 것(Option C)은 3시간 미만 환경에 비해 지나치게 무겁습니다. EKS(Option D)는 불필요하게 현대화하며 운영 부담을 증가시킵니다. 시험 팁: 짧은 수명의 환경이 자주 생성되고 하이브리드 연결성이 필요할 때는, 안정적인 네트워크 구성 요소(VPC/TGW attachment/routes)를 재사용하고 compute만 순환시키는 방식을 선호하십시오. TGW attachments는 임시 샌드박스를 위해 하루에도 수십 번 생성/삭제하도록 의도된 것이 아닙니다. 네트워크는 안정적으로 유지하고 CloudFormation과 Auto Scaling으로 워크로드 계층을 자동화하십시오.

문제 9

한 디지털 티켓팅 회사가 eu-west-1에서 Fargate profiles를 사용해 Amazon EKS에서 microservices를 실행하고, 초당 약 600건의 write transactions를 Amazon Aurora PostgreSQL cluster에 영속화합니다. 또한 지속적인 운영 오버헤드를 최소화하면서 RPO ≤ 1 second 및 RTO ≤ 15 minutes로 다른 AWS Region으로 fail over해야 합니다. 다음 중 이러한 요구 사항을 가장 잘 충족하는 접근 방식은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon Aurora PostgreSQL에 대해 매우 낮은 RPO(≤ 1 second)와 중간 수준의 RTO(≤ 15 minutes)를 요구하는 multi-Region disaster recovery를, 지속적인 운영 오버헤드를 최소화하면서 설계하는지를 평가합니다. 핵심 서비스는 Amazon Aurora Global Database로, managed 방식의 저지연 cross-Region replication과 이를 위해 설계된 failover 메커니즘을 제공합니다. 정답이 맞는 이유: Aurora Global Database는 cross-Region DR을 위해 목적에 맞게 설계되었으며, primary Region에서 secondary Regions로 dedicated storage-level replication을 사용해 near-real-time replication(일반적으로 sub-second)을 제공합니다. 이는 초당 ~600 writes/sec 환경에서 RPO ≤ 1 second 요구 사항과 직접적으로 부합합니다. RTO 측면에서도 Aurora Global Database는 managed cross-Region failover/promote 작업을 지원하며, 이를 빠르게(종종 수 분) 수행할 수 있어 15-minute 목표에 부합합니다. 또한 replication, monitoring, cross-Region topology를 Aurora가 관리하므로, custom replication pipeline을 요구하지 않아 지속적인 운영 오버헤드를 최소화합니다. 주요 AWS 기능: Aurora Global Database는 storage layer에서 secondary Region의 secondary clusters로 asynchronous replication을 수행하여 replication lag를 낮게 유지하고 primary에 대한 영향을 줄입니다. 다른 Region에 secondary Aurora cluster를 생성하고 지속적으로 업데이트된 상태로 유지할 수 있습니다. 재해 발생 시 secondary를 read/write로 promote하고 애플리케이션을 리디렉션합니다(일반적으로 Route 53 failover records 같은 DNS 또는 application-level configuration 사용). 이는 AWS Well-Architected Reliability pillar의 표준 DR 패턴으로, failure를 전제로 설계하고, recovery를 자동화하며, managed services를 활용합니다. 흔한 오해: AWS DMS도 cross-Region data replication을 수행할 수 있지만, 지속적인 write load에서 sub-second RPO를 보장하도록 설계된 것은 아니며 운영 복잡성(task, instance sizing, monitoring lag, schema changes, failover runbooks)을 증가시킵니다. DataSync 및 snapshot 기반 접근은 backup/restore 메커니즘이지 continuous DR이 아니므로 1-second RPO를 충족할 수 없고, restore 시간과 replay를 고려하면 15-minute RTO도 일반적으로 충족하기 어렵습니다. 시험 팁: Aurora + cross-Region DR + 매우 낮은 RPO를 보면 “Aurora Global Database”를 떠올리십시오. snapshot copy와 file-based copy는 backup/archival 용도이지 near-zero RPO 용도가 아닙니다. DMS는 migration 및 일부 replication use case에 적합하지만, 엄격한 DR 목표와 최소 운영을 요구한다면 native managed database DR 기능을 우선 고려하십시오.

문제 10

한 텔레매틱스 스타트업이 두 개의 대도시 권역에 걸쳐 2,500대의 배송 드론을 운영하고 있습니다. 각 드론은 100ms마다 평균 레코드 크기 1.5KB의 JSON 텔레메트리(GPS, temperature, vibration)를 게시합니다. 회사는 이 연속 스트림을 수집하고, 속성이 마이그레이션 없이 진화할 수 있도록 고정 스키마가 필요 없는 데이터베이스로 이벤트를 준실시간(엔드 투 엔드 3초 미만)으로 전달하는 AWS 솔루션이 필요합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 올바른 스트리밍 수집 서비스와, 유연한(스키마리스) 속성을 지원하면서 준실시간 전달을 만족하는 대상 데이터베이스를 선택하는지를 평가합니다. 또한 Kinesis의 전달 특성(Streams vs Firehose), 지연 시간, 그리고 DynamoDB의 문서 스타일 아이템 모델에 대한 이해도 간접적으로 테스트합니다. 정답이 맞는 이유: 2,500대의 드론이 100ms마다 게시하므로 시스템은 초당 약 25,000개의 레코드를 수집합니다. 레코드당 1.5KB라면 페이로드는 약 37.5MB/s입니다. Amazon Kinesis Data Streams는 고처리량, 저지연 스트리밍 수집(밀리초~1초 미만)에 맞게 설계되었습니다. Lambda 컨슈머(Enhanced fan-out 또는 표준 폴링)는 레코드를 지속적으로 처리하여 Amazon DynamoDB에 기록할 수 있으며, DynamoDB는 고정 스키마가 필요 없습니다. 각 아이템은 서로 다른 속성을 가질 수 있고, JSON과 유사한 중첩 속성(Map/List)은 마이그레이션 없이 진화할 수 있습니다. 이 아키텍처는 충분한 shard/처리량, 적절한 배치 설정, 그리고 DynamoDB 용량(온디맨드 또는 Auto Scaling이 있는 프로비저닝)을 구성하면 엔드 투 엔드 3초 미만 목표를 충족할 수 있습니다. 주요 AWS 기능: Kinesis Data Streams는 순서가 보장되는 내구성 있는 스트림 스토리지를 제공하며, shard를 통해 보존 기간 설정 및 스케일링이 가능합니다. Lambda event source mapping은 batch size와 maximum batching window 튜닝을 지원하며, enhanced fan-out은 컨슈머 지연 시간을 줄이고 컨슈머별 처리량을 분리할 수 있습니다. DynamoDB는 유연한 속성, TTL(오래된 텔레메트리 만료에 유용), 그리고 쓰기 분산을 위한 partition key 설계를 지원합니다(예: droneId로 파티셔닝하고 sort key로 timestamp 사용). 흔한 오해: Firehose는 “데이터베이스로 스트리밍”에 자주 선택되지만, Firehose는 S3/Redshift/OpenSearch/Splunk로의 전달을 위해 버퍼링(크기/시간)을 사용하도록 최적화되어 있어 지연이 수 초에서 수 분까지 늘어날 수 있으며, DynamoDB 또는 Keyspaces로 네이티브 전달을 지원하지 않습니다. Aurora MySQL과 Redshift는 스키마 지향의 관계형/웨어하우스 대상이므로 “고정 스키마 불필요” 요구 사항과 충돌합니다. 시험 팁: 엄격한 수 초 미만~수 초 수준의 지연 시간으로 “준실시간”이 요구되면 Firehose보다 Kinesis Data Streams(또는 Kafka)를 우선 고려하십시오. “마이그레이션 없이 스키마가 진화”를 보면 DynamoDB(또는 문서 데이터베이스)를 떠올리십시오. 항상 처리량(초당 레코드 수 및 MB/s)을 대략 계산하고, 선택한 서비스가 대상 및 지연 시간 요구 사항을 지원하는지 확인하십시오.

Practice Test #2

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(9)

다른 모의고사

Practice Test #1

Practice Test #3

Practice Test #4

Practice Test #5

지금 학습 시작하기