연습 문제

문제 1

한 금융 기술 스타트업이 모바일 뱅킹 애플리케이션을 구축 중이며 AWS에 프로토타입 인프라를 수동으로 생성했습니다. 인프라는 EC2 인스턴스가 있는 Auto Scaling 그룹, 고성능 트래픽 처리를 위한 Network Load Balancer, 트랜잭션 처리를 위한 Amazon Aurora MySQL 클러스터로 구성됩니다. 보안 규정 준수 검증을 완료한 후, 회사는 4주 후로 예정된 출시를 지원하기 위해 완전히 자동화된 방식으로 스테이징 및 프로덕션 환경 모두에 대해 3개의 가용 영역(Availability Zone)에 걸쳐 동일한 인프라를 신속하게 배포해야 합니다. 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 여러 가용 영역(AZ) 및 여러 환경(스테이징 및 프로덕션)에 걸쳐 반복 가능하고 자동화된 환경 프로비저닝을 위한 코드형 인프라(IaC)를 테스트합니다. 주요 AWS 서비스는 AWS CloudFormation(또는 동급의 IaC)이며, 이는 동일하고 규정을 준수하는 스택을 신속하게 배포하기 위한 표준 시험 정답입니다. 정답인 이유: 보안 규정 준수 검증 후 회사는 동일한 아키텍처를 빠르고 일관되게 재현해야 합니다. CloudFormation 템플릿(잠재적으로 프로토타입을 참조로 생성됨)을 사용하면 스타트업이 Auto Scaling 그룹, Network Load Balancer 및 Aurora MySQL 클러스터를 선언적으로 정의하고 완전히 자동화된 방식으로 배포할 수 있습니다. CloudFormation은 3개의 AZ에 서브넷을 정의하고, NLB를 해당 서브넷과 연결하고, Auto Scaling 그룹이 이를 포괄하도록 구성하고, 해당 AZ에 걸쳐 DB 서브넷 그룹(및 필요에 따라 다중 AZ/복제본)으로 Aurora를 구성하여 다중 AZ 설계를 지원합니다. 스테이징 및 프로덕션을 위해 별도의 스택(또는 파라미터화된 스택)을 배포하여 환경별 파라미터가 있는 동일한 토폴로지를 보장할 수 있습니다. 주요 AWS 기능: CloudFormation은 변경 세트, 드리프트 감지, 스택 정책, 중첩 스택/모듈, 환경 차이(인스턴스 유형, 확장 제한, DB 크기, 태그)에 대한 파라미터화를 제공합니다. 자동화된 배포를 위해 CI/CD(CodePipeline/CodeBuild)와 통합되며 AWS Secrets Manager/SSM Parameter Store에 대한 동적 참조를 통해 보안 암호의 안전한 처리를 지원합니다. 이는 안정성(다중 AZ), 보안(반복 가능한 제어) 및 운영 우수성(자동화)에 대한 Well-Architected 모범 사례와 일치합니다. 일반적인 오해: Systems Manager Automation은 운영 런북을 오케스트레이션할 수 있지만 기존 프로토타입을 "캡처"하고 전체 인프라를 제품화되고 버전 제어되는 배포로 안정적으로 재생성하는 기본 도구는 아닙니다. AWS Config는 규정 준수를 인벤토리화하고 평가합니다. 자동 수정은 전체 다중 계층 환경을 프로비저닝하는 것이 아니라 드리프트/규정 위반을 수정하기 위한 것입니다. Elastic Beanstalk는 애플리케이션 플랫폼 추상화이며 네트워킹, 확장 및 데이터베이스 토폴로지에 대한 명시적 제어가 필요한 사용자 지정 NLB + Aurora 뱅킹 아키텍처에는 자연스럽게 맞지 않습니다. 시험 팁: "동일한 인프라 신속 배포(rapidly deploy identical infrastructure)", "완전 자동화(fully automated)", "다중 AZ(multiple AZs)" 및 "다중 환경(multiple environments)"이 보이면 기본적으로 IaC(CloudFormation/CDK/Terraform)를 선택하십시오. CloudFormation은 표준 AWS 네이티브 정답입니다. "프로토타입이 이미 존재함(prototype already exists)" 및 "반복 가능성과 일관성 필요(need repeatability and consistency)"와 같은 문구를 찾아 스테이징 대 프로덕션을 위한 IaC 및 파라미터화된 스택을 강화하십시오.

문제 2

한 금융 기술 스타트업이 분당 수천 건의 트랜잭션을 처리하는 실시간 결제 처리 플랫폼을 개발하고 있습니다. 이 플랫폼은 하루 종일 크게 변동하는 트랜잭션 볼륨(피크 시간대에는 비피크 시간대보다 10배 더 많은 트래픽 발생)에 따라 자동으로 확장되어야 하는 여러 마이크로서비스로 구성됩니다. 개발 팀은 빠른 배포와 고가용성을 달성하기 위해 마이크로서비스를 컨테이너화하고자 합니다. 이들은 인프라 관리보다는 애플리케이션 개발 및 결제 로직 최적화에 전적으로 집중해야 합니다. 솔루션은 자동 확장을 제공하고 서버 프로비저닝 및 유지 관리의 필요성을 제거해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 서버리스 컨테이너 오케스트레이션 및 운영 책임 경계를 테스트합니다. 핵심 서비스는 AWS Fargate를 사용하는 Amazon ECS로, EC2 인스턴스를 관리하지 않고 컨테이너를 실행하여 "애플리케이션 개발에 집중"하고 "서버 프로비저닝 및 유지 관리 제거"와 일치합니다. 정답인 이유: AWS Fargate의 ECS는 최소한의 운영 오버헤드를 위해 특별히 구축되었습니다. 작업 정의(CPU/메모리), 서비스 및 조정 정책을 정의하면 AWS가 기본 컴퓨팅을 프로비저닝하고 관리합니다. 트래픽 변동이 심한(10배 피크) 결제 플랫폼의 경우, ECS Service Auto Scaling은 지표(예: CPU, 메모리 또는 분당 트랜잭션과 같은 사용자 지정 CloudWatch 지표)를 기반으로 실행 중인 작업 수를 조정할 수 있습니다. 이는 클러스터 용량 계획 없이 빠른 배포, 여러 AZ에 걸친 고가용성 및 자동 확장을 제공합니다. 주요 AWS 기능: - AWS Fargate: EC2 인스턴스 관리, 패치 적용, AMI 또는 용량 프로비저닝이 없습니다. - ECS Service Auto Scaling: 원하는 작업 수를 조정하기 위한 대상 추적(Target tracking) 및 단계 조정(Step scaling). - Application Load Balancer 통합: 트래픽을 작업으로 분산합니다. 상태 확인 및 블루/그린 패턴(종종 CodeDeploy를 통해)을 지원합니다. - 고가용성: 여러 AZ의 서브넷에서 작업을 실행합니다. 복원력을 위해 원하는 수(desired count)와 배포 회로 차단기(deployment circuit breaker)를 사용합니다. - 보안 및 규정 준수 지원 요소: 작업을 위한 IAM 역할, 작업별 보안 그룹(awsvpc 네트워킹), Secrets Manager/Parameter Store와의 통합—핀테크 컨텍스트에서 중요합니다. 일반적인 오해: 팀은 종종 EC2 시작 유형의 ECS가 "충분히 관리된다"고 가정합니다. ECS가 예약을 관리하지만 여전히 EC2 플릿(패치 적용, 확장, 인스턴스 유형, 용량 버퍼)을 관리해야 합니다. 마찬가지로 Docker가 있는 EC2 Auto Scaling은 인스턴스를 확장할 수 있지만 오케스트레이션 및 배포 메커니즘을 구축하고 운영해야 합니다. 시험 팁: "최소한의 운영 오버헤드", "서버 프로비저닝/유지 관리 없음", "컨테이너"가 보이면 시험은 일반적으로 Fargate(또는 Fargate의 EKS)를 가리킵니다. 질문에 ECS가 명시적으로 지정되어 있고 인프라 관리 제거가 강조되어 있다면 Fargate가 있는 ECS가 정답입니다. 요구 사항을 공동 책임 모델에 매핑하십시오. Fargate는 컨테이너 이식성과 자동 확장을 유지하면서 더 많은 차별화되지 않은 과중한 작업을 AWS로 이전합니다.

문제 3

(3개 선택)

금융 서비스 회사가 레거시 데이터 웨어하우스 인프라를 현대화하고 AWS로 마이그레이션하고 있습니다. 이 회사는 대량의 거래 데이터, 고객 트랜잭션 및 시장 분석을 처리합니다. 비즈니스 인텔리전스 및 보고 요구 사항을 지원하기 위한 기본 데이터 웨어하우스 솔루션으로 Amazon Redshift를 평가하고 있습니다. 이 회사는 다양한 애플리케이션 유형 지원, 보안 기능 및 운영 유연성을 포함하여 Amazon Redshift가 금융 데이터 웨어하우스 요구 사항에 적합한 기능을 식별해야 합니다. 이 금융 서비스 시나리오에서 Amazon Redshift에 적합한 사용 사례는 무엇입니까? (3개 선택)

문제 4

글로벌 이러닝 플랫폼 회사가 여러 리전의 교육 기관에 서비스를 제공합니다. 이 회사는 여러 대학과 학교에 일관되게 배포해야 하는 표준화된 학습 관리 시스템(LMS) 모듈과 평가 도구를 개발합니다. 회사는 교육 기관이 학생 포털, 성적 관리 시스템 및 분석 대시보드를 포함한 표준화된 LMS 구성 요소를 독립적으로 배포하고 관리할 수 있도록 해야 합니다. 각 기관은 중앙 집중식 거버넌스 및 버전 제어를 유지하면서 학생 수용 인원(500명에서 50,000명 사이) 및 지역 규정 준수 요구 사항과 같은 배포 파라미터를 사용자 지정할 수 있어야 합니다. 중앙 집중식 관리 및 셀프 서비스 배포에 대한 이러한 요구 사항을 가장 잘 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 표준화된 인프라 및 애플리케이션 구성 요소의 셀프 서비스 프로비저닝을 통한 중앙 집중식 거버넌스에 대한 AWS Service Catalog를 테스트합니다. 또한 기본 IaC(종종 CloudFormation)를 사용하는 파라미터화된 배포 및 버전 제어를 다룹니다. 정답인 이유: AWS Service Catalog는 중앙 팀이 최종 사용자(각 교육 기관)가 독립적으로 배포할 수 있는 승인된 "제품"(예: LMS 모듈 스택: 학생 포털, 성적 시스템, 분석 대시보드)의 카탈로그를 정의하고 관리할 수 있도록 특별히 구축되었습니다. 기관은 셀프 서비스를 통해 제품을 시작할 수 있으며 회사는 중앙 집중식 거버넌스, 일관된 구성 및 제어된 버전을 유지합니다. Service Catalog는 파라미터화(예: 학생 수용 인원 500–50,000, 리전/규정 준수 토글)를 지원하므로 각 기관이 가드레일 내에서 사용자 지정할 수 있습니다. 주요 AWS 기능: Service Catalog 제품은 일반적으로 CloudFormation 템플릿으로 지원되므로 파라미터, 매핑, 조건 및 제약 조건을 사용하여 반복 가능한 배포가 가능합니다. 관리자는 제약 조건(허용된 값, IAM 제약 조건, 시작 제약 조건)을 적용하고, 어떤 포트폴리오/제품을 어떤 계정/OU에서 사용할 수 있는지 제어하고, 기관이 특정 승인된 버전을 배포할 수 있도록 제품 버전을 관리할 수 있습니다. AWS Organizations와의 통합을 통해 다중 계정 배포 및 거버넌스가 가능합니다. 이는 최소 권한, 중앙 집중식 제어, 일관되고 감사 가능한 배포와 같은 Well-Architected 보안 원칙과 일치합니다. 일반적인 오해: CloudFormation 단독(옵션 A)은 템플릿을 제공하지만 많은 독립 소비자를 위한 거버넌스된 셀프 서비스 "스토어프런트", 포트폴리오 배포, 액세스 제어 또는 제품 버전 수명 주기 관리를 제공하지 않습니다. Systems Manager(옵션 C)는 운영 관리(패치, 자동화, 런북)에는 탁월하지만 거버넌스가 있는 카탈로그 기반 프로비저닝에는 적합하지 않습니다. AWS Config(옵션 D)는 배포가 아닌 리소스 규정 준수 감사 및 드리프트 감지를 위한 것입니다. 시험 팁: "중앙 집중식 거버넌스 + 셀프 서비스 프로비저닝 + 표준화된 구성 요소 + 버전 제어"가 보이면 AWS Service Catalog를 생각하십시오. 질문이 "코드형 인프라 템플릿"만 강조하는 경우 CloudFormation이 적합할 수 있습니다. 그러나 가드레일 및 승인된 오퍼링이 있는 다중 테넌트 셀프 서비스를 추가하면 Service Catalog가 정답이 됩니다.

문제 5

글로벌 제조 회사가 여러 환경에 걸쳐 컨테이너 기반 생산 모니터링 시스템을 운영하고 있습니다. 이들은 서로 다른 AWS 리전에서 실행되는 8개의 Amazon ECS 클러스터와 전 세계 여러 공장에 12개의 온프레미스 Docker Swarm 클러스터를 보유하고 있습니다. 운영 팀은 최소한의 설정 복잡성으로 단일 대시보드에서 모든 컨테이너화된 워크로드를 모니터링하고, 모든 클러스터의 리소스 사용률을 추적하며, 배포를 관리할 수 있는 통합 관리 솔루션이 필요합니다. 최소한의 운영 오버헤드로 중앙 집중식 가시성과 관리를 제공하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 이기종 container 플랫폼(Amazon ECS in multiple Regions 및 on-prem Docker Swarm) 전반에서 최소한의 운영 오버헤드로 중앙 집중식 observability 및 운영 관리를 테스트합니다. 핵심 AWS 서비스는 통합 모니터링을 위한 Amazon CloudWatch Container Insights(및 CloudWatch cross-account/cross-Region dashboards)입니다. 정답인 이유: Amazon CloudWatch Container Insights는 최소한의 설정으로 여러 orchestrator의 container metrics 및 logs를 수집, 집계, 시각화하도록 특별히 설계되었습니다. Amazon ECS(Fargate 및 EC2 launch types 포함)와 Kubernetes를 지원하며, CloudWatch Agent/Fluent Bit 및 Embedded Metric Format를 통해 on-prem 환경의 metrics/logs도 수집할 수 있습니다. Docker Swarm factories의 경우, 팀은 각 Swarm cluster에 CloudWatch agent/Fluent Bit를 container로 배포하여 metrics/logs를 CloudWatch로 전송할 수 있습니다. 여러 Regions에 걸친 8개의 ECS clusters에 대해서는 Container Insights 활성화가 대부분 configuration 변경만으로 가능합니다. 이후 CloudWatch dashboards는 모든 clusters 전반의 resource utilization 및 health에 대해 단일 “pane of glass”를 제공할 수 있습니다. 주요 AWS 기능: - ECS용 CloudWatch Container Insights: cluster/service/task별 CPU, memory, network, storage 및 performance telemetry. - 중앙 집중식 dashboards: CloudWatch dashboards는 여러 Regions의 widgets를 집계할 수 있으며, 조직에서는 clusters가 여러 accounts에 걸쳐 있는 경우 이를 cross-account observability(CloudWatch cross-account dashboards/monitoring)와 함께 사용하는 경우가 많습니다. - 낮은 운영 오버헤드: ECS에 대해서는 managed collection, on-prem에 대해서는 lightweight agents를 사용하므로 workloads를 다시 플랫폼화할 필요가 없습니다. - Alarms 및 anomaly detection: 환경 전반에서 일관된 alerting. 흔한 오해: ECS Anywhere는 최고의 “통합 관리”처럼 들리지만, ECS agent 실행 및 external instances 등록이 필요하며 기존 Docker Swarm clusters를 있는 그대로 “등록”하지는 않습니다. App2Container는 migration 도구이지 모니터링/통합 관리 솔루션이 아니며, 범위와 복잡성을 증가시킵니다. Systems Manager는 operational data를 수집할 수 있지만 container observability 플랫폼은 아니며 상당한 custom integration이 필요합니다. 시험 팁: 요구 사항이 최소한의 설정으로 혼합 환경 전반의 “통합 모니터링/가시성”인 경우, re-architecting(migration)하거나 단일 orchestrator를 강제하기보다 CloudWatch(Container Insights + dashboards)를 우선 고려하세요. 문제가 on-prem 및 AWS 전반에서 하나의 orchestrator 아래 deployment control을 명시적으로 요구한다면 ECS Anywhere 또는 EKS Anywhere가 후보가 될 수 있습니다. 단, on-prem 환경이 해당 control model 아래로 편입될 수 있는 경우에만 해당합니다.

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

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

문제 6

한 재무 분석 회사가 Performance Insights가 활성화된 Amazon RDS for PostgreSQL DB instance에서 분기별 규정 준수 보고서를 실행합니다. 규정 준수 처리에는 고성능 컴퓨팅이 필요하며 매 분기마다 72시간 동안 실행됩니다. 규정 준수 처리는 이 데이터베이스를 사용하는 유일한 워크로드입니다. 회사는 처리 기간 동안 동일한 컴퓨팅 및 메모리 사양을 유지하면서 비용을 최소화하고자 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 짧은 분기별 batch workload에만 사용되는 Amazon RDS for PostgreSQL 인스턴스의 비용 최적화를 테스트합니다. 핵심 제약 사항은 DB 인스턴스에 대한 Amazon RDS stop/start가 일시적이며, 인스턴스는 Amazon RDS가 자동으로 다시 시작하기 전까지 최대 7일만 중지 상태를 유지할 수 있다는 점입니다. 데이터베이스는 7일보다 훨씬 더 오랫동안 유휴 상태이므로, 회사는 긴 비활성 기간 동안 지속적인 DB 인스턴스 compute 요금 지불을 피할 방법이 필요합니다. 정답인 이유: compliance run 이후 snapshot을 생성하고, DB 인스턴스를 terminate한 다음, 다음 분기 실행 전에 snapshot에서 restore하는 것이 가장 비용 효율적인 접근 방식입니다. 이렇게 하면 snapshot에 데이터베이스 내용을 보존하면서 긴 유휴 기간 동안 지속적인 instance-hour 요금을 제거할 수 있습니다. 인스턴스를 restore할 때 회사는 동일한 DB 인스턴스 class를 선택하여 처리 중 동일한 compute 및 memory 사양을 유지할 수 있습니다. 주요 AWS 기능: - RDS snapshots는 데이터베이스 상태를 저장하며 나중에 DB 인스턴스를 다시 생성하는 데 사용할 수 있습니다. - DB 인스턴스를 terminate하면 더 작은 인스턴스 class로 resize하는 것과 달리 compute 과금이 완전히 중지됩니다. - snapshot에서 restore하면 분기별 workload에 필요에 따라 동일한 인스턴스 class, parameter groups, storage 설정을 선택할 수 있습니다. - RDS stop/start는 중지된 인스턴스가 7일 후 자동으로 다시 시작되므로 수개월의 유휴 기간에는 적합하지 않습니다. 일반적인 오해: - 많은 수험자는 RDS 인스턴스를 중지할 수 있다는 것은 기억하지만, 최대 7일의 중지 기간 제한은 잊습니다. - Auto Scaling은 표준 RDS for PostgreSQL DB 인스턴스를 EC2 Auto Scaling처럼 정책으로 수직 확장 및 축소하지 않습니다. - 인스턴스 크기를 줄여도 지속적인 compute 요금은 계속 발생하므로, 데이터베이스가 대부분의 시간 동안 사용되지 않을 때는 최적이 아닙니다. 시험 팁: 유휴 기간이 매우 긴 RDS workload의 경우, 먼저 stop/start 기간 제한 때문에 해당 옵션이 무효가 되는지 확인하세요. 유휴 기간이 7일을 초과하면 snapshot-and-restore가 비용 절감을 위한 최선의 패턴인 경우가 많습니다. 또한 compute 요금을 완전히 제거하는 것과 더 작은 인스턴스 크기로 단지 줄이는 것의 차이도 구분하세요.

문제 7

한 회사가 Amazon Aurora 데이터베이스에 연결되는 Amazon EC2 인스턴스 그룹을 실행할 계획입니다. 이 회사는 EC2 인스턴스와 Aurora DB 클러스터를 배포하기 위해 AWS CloudFormation 템플릿을 구축했습니다. 회사는 인스턴스가 안전한 방식으로 데이터베이스에 인증할 수 있도록 허용하고자 합니다. 회사는 정적 데이터베이스 자격 증명을 유지 관리하고 싶지 않습니다. 최소한의 운영 노력으로 이러한 요구 사항을 충족하고 가장 안전한 인증 방법을 제공하는 솔루션은 무엇입니까? 최소한의 운영 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 수명이 긴(정적) 데이터베이스 암호를 관리하지 않고 Amazon EC2에서 Amazon Aurora로의 안전하고 운영 부담이 적은 인증을 테스트합니다. 핵심 기능은 임시 AWS 자격 증명을 얻기 위한 EC2 인스턴스 프로파일(IAM 역할)과 결합된 Amazon Aurora(RDS) IAM 데이터베이스 인증입니다. 정답인 이유: 옵션 A는 Aurora 클러스터에서 IAM 데이터베이스 인증을 사용하고 EC2 인스턴스에 연결된 IAM 역할을 사용합니다. EC2의 애플리케이션은 인스턴스 역할의 임시 자격 증명(인스턴스 메타데이터 서비스에서 제공)을 사용하여 RDS IAM 인증 토큰을 요청한 다음, 해당 토큰을 사용하여 Aurora에 연결합니다. 이는 정적 DB 암호를 제거하고, 보안 암호 교체 부담을 줄이며, 수명이 짧은 토큰 및 IAM 정책 제어를 통해 강력한 보안을 제공합니다. 또한 CloudFormation과도 잘 맞습니다. 클러스터에서 IAM 인증을 활성화하고, IAM 인증을 위해 매핑된 DB 사용자를 생성하고, 인스턴스 프로파일을 연결하는 것은 모두 Infrastructure-as-Code에 친화적입니다. 주요 AWS 기능: - Aurora용 IAM DB 인증: (저장된 암호 대신) 수명이 짧은 인증 토큰을 생성하고 IAM 정책을 통해 권한을 부여합니다. - EC2 인스턴스 프로파일(IAM 역할): STS를 통해 자동으로 교체되는 임시 자격 증명을 제공하여 자격 증명 배포를 방지합니다. - 세분화된 액세스 제어: IAM 정책은 액세스할 수 있는 DB 리소스/사용자를 제한할 수 있습니다. DB 측 권한은 여전히 적용됩니다. - 운영 단순성: 보안 암호 저장소, 교체 워크플로 또는 인스턴스에 대한 파라미터 주입이 필요하지 않습니다. 일반적인 오해: - CloudFormation 파라미터에 자격 증명을 저장하는 것(옵션 B)은 기본적으로 안전하지 않으며 여전히 정적 암호를 사용합니다. 또한 로그, 변경 세트 또는 사용자 데이터에 노출될 위험이 있습니다. - Parameter Store(옵션 C)는 안전할 수 있지만(특히 SecureString + KMS 사용 시), 여전히 교체 및 관리해야 하는 정적 자격 증명에 의존합니다. - EC2에서 IAM 사용자를 사용하는 것(옵션 D)은 안티 패턴입니다. IAM 사용자는 사람을 위한 것이며 수명이 긴 액세스 키는 자격 증명 관리 및 유출 위험을 초래합니다. 시험 팁: 'EC2에서 Aurora/RDS로', '정적 DB 자격 증명 없음', '최소한의 운영 노력/가장 안전함'을 볼 때 IAM 데이터베이스 인증(또는 다른 시나리오에서는 교체 기능이 있는 Secrets Manager)을 생각하십시오. EC2의 워크로드에는 IAM 사용자/액세스 키보다 IAM 역할을 선호하십시오. 또한 IAM DB 인증을 사용하려면 IAM 인증용으로 구성된 DB 사용자를 생성하고 역할에 rds-db:connect 권한을 부여해야 합니다.

문제 8

미디어 제작 회사가 비디오 편집 워크플로를 위한 스토리지 솔루션을 필요로 합니다. 이 솔루션은 여러 편집 팀의 다양한 워크로드를 처리할 수 있도록 고가용성과 확장성을 갖춰야 합니다. 솔루션은 공유 파일 시스템으로 작동해야 하며, AWS에 있는 15대의 Linux 기반 편집 워크스테이션과 온프레미스에 있는 8대의 워크스테이션에서 표준 프로토콜을 통해 마운트할 수 있어야 하고, 스토리지 용량을 사전 프로비저닝(pre-provisioning)하지 않고도 동적 확장을 지원해야 합니다. 이 회사는 온프레미스 스튜디오와 AWS 인프라 간의 하이브리드 액세스를 위해 Direct Connect 연결을 설정했습니다. 이러한 요구 사항을 충족하는 스토리지 솔루션은 무엇입니까?

문제 분석

Core Concept: 이 질문은 고가용성을 갖추고 탄력적으로 확장 가능하며 표준 파일 프로토콜을 통해 AWS와 온프레미스 모두에서 액세스할 수 있는 관리형 공유 파일 시스템을 선택하는 능력을 테스트합니다. AWS에서 기본 서버리스 NFS 파일 시스템은 Amazon EFS입니다. Why the Answer is Correct: Amazon EFS는 NFSv4.1/4.2를 사용하여 여러 Linux 클라이언트가 동시에 마운트할 수 있는 공유 POSIX 호환 파일 시스템을 제공합니다. 파일이 추가/제거됨에 따라 스토리지 용량이 자동으로 투명하게 확장되므로 용량을 사전 프로비저닝할 필요가 없습니다. 고가용성과 복원력을 위해 EFS는 Multi-AZ 내구성과 가용성을 갖도록 설계되었으며, 클라이언트가 사용하는 각 Availability Zone에 마운트 타겟을 생성하는 것이 모범 사례입니다. AWS Direct Connect가 이미 구축되어 있으므로 온프레미스 Linux 워크스테이션은 프라이빗 VIF를 통해(적절한 라우팅/DNS 및 보안 그룹 규칙과 함께) EFS를 마운트할 수 있어 하이브리드 요구 사항을 충족합니다. Key AWS Features: - 탄력적인 서버리스 용량 확장 (볼륨 크기 조정 없음) - Linux 공유 액세스를 위한 NFS 표준 프로토콜 - AZ별 마운트 타겟을 통한 Multi-AZ 액세스; 클라이언트는 짧은 지연 시간과 AZ 내결함성을 위해 AZ 로컬 마운트 타겟을 사용 - 마운트 타겟의 보안 그룹, IAM 권한 부여(선택 사항), 저장 및 전송 중 암호화 - 다양한 워크로드를 처리하기 위한 성능 모드(General Purpose/Max I/O) 및 처리량 모드(Bursting/Provisioned/Elastic Throughput) Common Misconceptions: FSx for Lustre는 높은 처리량으로 인해 미디어 워크로드에 인기가 있지만, "Multi-AZ 배포"는 Lustre 배포 모델이 아닙니다(Multi-AZ는 FSx for Windows/ONTAP과 관련이 있습니다). EBS Multi-Attach는 공유 스토리지처럼 보일 수 있지만 블록 스토리지이며 관리형 공유 파일 시스템을 제공하지 않습니다. 또한 엄격한 제한 사항이 있으며 클러스터 인식 파일 시스템이 필요합니다. 단일 EFS 마운트 타겟은 단일 장애점(single point of failure)이 되며 고가용성 요구 사항을 충족하지 못합니다. Exam Tips: "공유 파일 시스템(shared file system)", "Linux", "표준 프로토콜(standard protocol)", "사전 프로비저닝 없는 자동 확장(automatic scaling without pre-provisioning)"이라는 키워드를 보면 EFS를 떠올리십시오. "AZ 전반의 고가용성(high availability across AZs)"을 위해서는 설계에 여러 마운트 타겟(AZ당 하나)이 포함되어 있는지 확인하십시오. 하이브리드 액세스의 경우 연결(DX/VPN), 라우팅, DNS 및 NFS 보안 그룹 규칙(TCP/2049)을 확인하십시오.

문제 9

금융 거래 플랫폼 회사가 고빈도 거래(high-frequency trading) 작업을 위해 초저지연(ultra-low latency)이 요구되는 실시간 거래 시스템 아키텍처를 구축하고 있습니다. 이 거래 애플리케이션은 특화된 Linux 배포판에서 실행되는 사용자 지정 C++ 엔진을 사용하며, 최대 속도를 위해 오직 UDP 프로토콜을 통해서만 통신합니다. 프런트엔드 인프라는 밀리초 수준의 지연 시간을 제공하고, 전 세계에서 가장 가까운 시장 데이터 센터로 거래 요청을 자동으로 라우팅하며, 브로커 연결을 위한 일관된 정적 IP 주소를 제공하고, 최소 99.9%의 가동 시간으로 여러 리전(region)에 걸쳐 고가용성을 유지해야 합니다. 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 글로벌 초저지연 인그레스(ingress), 정적 애니캐스트(anycast) IP, UDP 지원 및 다중 리전 고가용성을 테스트합니다. 핵심 서비스는 글로벌 애니캐스트 진입 및 AWS 백본을 통한 라우팅을 위한 AWS Global Accelerator(GA), UDP를 포함한 고성능 L4 로드 밸런싱을 위한 Network Load Balancer(NLB), 사용자 지정 Linux에서 특화된 C++ 엔진을 실행하기 위한 Amazon EC2입니다. 정답인 이유: AWS Global Accelerator는 브로커가 허용 목록(allowlist)에 추가하고 일관되게 연결할 수 있는 두 개의 정적 애니캐스트 IP 주소를 제공합니다. GA는 각 클라이언트를 가장 가까운 정상 AWS 엣지 로케이션으로 라우팅한 다음, AWS 글로벌 네트워크를 통해 최적의(가장 지연 시간이 짧은) 정상 엔드포인트로 트래픽을 전달하여 밀리초 수준의 지연 시간 및 자동 글로벌 라우팅 요구 사항을 충족합니다. 애플리케이션이 오직 UDP를 통해서만 통신하므로 프런트 도어는 엔드투엔드로 UDP를 지원해야 합니다. GA는 UDP를 지원하고 NLB 엔드포인트로 전달할 수 있으며, NLB는 Layer 4에서 UDP를 지원합니다. EC2 전용 인스턴스(dedicated instances)는 고빈도 거래에 필요한 특화된 Linux 배포판 및 성능 특성을 허용하며, 서버리스/컨테이너 옵션은 OS/커널 제약으로 인해 이를 지원하지 못할 수 있습니다. 주요 AWS 기능: - Global Accelerator: 정적 애니캐스트 IP, 상태 검사(health checks), 트래픽 다이얼(traffic dials), 리전별 엔드포인트 그룹, 리전 간 빠른 장애 조치(failover). - Network Load Balancer: 초저지연, 높은 처리량, UDP/TCP 지원, AZ별 정적 IP(GA 뒤에서 유용함), 교차 영역 로드 밸런싱(필요시). - 리전당 여러 AZ에 걸친 EC2 Auto Scaling; 99.9% 이상의 가용성을 달성하기 위한 GA 엔드포인트 그룹을 사용한 다중 리전 배포. 일반적인 오해: Route 53 지리적 위치 라우팅은 지리적으로 라우팅할 수 있지만 정적 애니캐스트 IP를 제공하지 않으며 장애 조치가 DNS 기반(캐시/TTL)이므로 1초 미만의 거래 장애 조치에는 이상적이지 않습니다. CloudFront는 주로 HTTP(S)용이며 원시 UDP 거래 흐름에는 적합하지 않습니다. API Gateway 및 ALB는 L7 HTTP 중심이며 UDP를 지원하지 않습니다. 시험 팁: "전 세계적인 정적 IP", "가장 가까운 진입점", "빠른 장애 조치" 및 "TCP/UDP"와 같은 요구 사항이 보이면 Global Accelerator + NLB를 생각하십시오. "UDP" 및 "초저지연"이 보이면 NLB를 생각하십시오(ALB/API Gateway 아님). "사용자 지정 OS/특화된 엔진"이 보이면 Lambda/Fargate보다는 EC2(종종 전용/배치/ENA 튜닝)를 기본으로 선택하십시오.

문제 10

한 금융 분석 회사가 Linux 컨테이너에서 실행되는 Python을 사용하여 데이터 처리 애플리케이션을 개발했습니다. 이 애플리케이션은 실시간 시장 분석을 수행하고 거래 보고서를 생성합니다. 회사는 이 컨테이너화된 작업을 AWS Cloud에서 실행해야 합니다. 시장 데이터를 처리하려면 이 작업이 15분마다 실행되어야 합니다. 각 실행은 시장 변동성에 따라 2분에서 5분 정도 소요됩니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

Practice Test #6

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(29)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #7

Practice Test #8

Practice Test #9

Practice Test #10

지금 학습 시작하기