CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
AWS Certified Solutions Architecture - Associate (SAA-C03)
AWS Certified Solutions Architecture - Associate (SAA-C03)

Practice Test #3

65개 문제와 130분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

65문제130분720/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

기출 문제

1
문제 1

금융 서비스 회사가 AWS에서 다중 계층 온라인 뱅킹 애플리케이션을 운영하고 있습니다. 웹 계층은 VPC 내의 퍼블릭 서브넷에서 실행되는 반면, 애플리케이션 로직 및 데이터베이스 계층은 동일한 VPC의 프라이빗 서브넷에서 호스팅됩니다. 규정 준수를 위해 이 회사는 전용 보안 VPC에 AWS Marketplace의 특수 DLP(데이터 손실 방지) 보안 어플라이언스를 배포했습니다. 이 어플라이언스는 민감한 데이터 탐지를 위해 네트워크 패킷을 처리할 수 있는 IP 인터페이스를 갖추고 있습니다. 솔루션 아키텍트는 뱅킹 애플리케이션을 DLP 어플라이언스와 통합하여 모든 고객 트래픽이 웹 서버에 도달하기 전에 민감한 데이터에 대해 검사되도록 해야 합니다. 이 솔루션은 운영 복잡성과 관리 오버헤드를 최소화해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

Network Load Balancer는 TCP/UDP 트래픽을 분산할 수 있지만 VPC 전반에 걸친 투명한 인라인 보안 어플라이언스 삽입을 위해 특별히 구축된 것은 아닙니다. NLB는 어플라이언스로 트래픽을 조향하는 것을 운영상 간단하게 만드는 동일한 라우팅 테이블 기반 서비스 삽입 모델(엔드포인트를 통해)을 제공하지 않습니다. 여전히 추가 라우팅, NAT 또는 프록시 패턴이 필요하며 주요 투명성 요구 사항을 잃을 수 있어 관리 오버헤드가 증가합니다.

Application Load Balancer는 Layer 7(HTTP/HTTPS)에서 작동하며 일반적으로 클라이언트 연결을 종료하므로 일반적인 패킷 검사에는 적합하지 않으며 인증서 및 재암호화를 관리하지 않는 한 종단 간 암호화 기대치를 깨뜨릴 수 있습니다. 네트워크 계층에서 패킷을 검사하는 DLP 어플라이언스는 투명한 방식으로 ALB를 통해 통합되지 않습니다. 이는 복잡성을 추가하며 의도된 AWS 패턴이 아닙니다.

transit gateway는 허브 앤 스포크 연결 및 VPC와 온프레미스 네트워크 간의 중앙 집중식 라우팅에 탁월합니다. 그러나 보안 어플라이언스 플릿을 통해 트래픽을 로드 밸런싱하거나 투명한 서비스 삽입을 수행하는 관리형 메커니즘을 자체적으로 제공하지는 않습니다. 어플라이언스에 대한 사용자 지정 라우팅 및 확장/HA 패턴을 여전히 구축해야 하므로 GWLB에 비해 운영 오버헤드가 증가합니다.

Gateway Load Balancer와 Gateway Load Balancer endpoint는 최소한의 운영 오버헤드로 타사 가상 어플라이언스(방화벽, IDS/IPS, DLP)를 트래픽 경로에 삽입하기 위한 AWS 네이티브 솔루션입니다. GWLB는 DLP 어플라이언스 플릿에 투명한 패킷 전달 및 로드 밸런싱을 제공하는 반면, GWLBe는 트래픽이 웹 계층에 도달하기 전에 검사를 위해 애플리케이션 VPC에서 보안 VPC로의 간단한 라우팅 테이블 스티어링을 가능하게 합니다.

문제 분석

핵심 개념: 이 질문은 최소한의 운영 오버헤드로 타사 인라인 네트워크 보안 어플라이언스(DLP)를 트래픽 경로에 삽입하는 방법을 테스트합니다. 가상 어플라이언스로의 투명한 패킷 스티어링을 위해 특별히 설계된 AWS 네이티브 서비스는 GENEVE 프로토콜을 사용하는 Gateway Load Balancer(GWLB) 및 Gateway Load Balancer endpoint(GWLBe)입니다. 정답인 이유: 전용 보안 VPC에 GWLB를 배포하고 그 뒤에 DLP 어플라이언스를 배치하면 뱅킹 애플리케이션 VPC가 GWLB 엔드포인트를 통해 투명하게 어플라이언스로 트래픽을 보낼 수 있습니다. 그런 다음 라우팅 테이블을 업데이트하여(또는 중앙 집중식 수신/송신 패턴을 사용하여) 고객 트래픽이 웹 계층에 도달하기 전에 검사를 위해 GWLBe로 조향되도록 할 수 있습니다. 이는 복잡한 프록시 구성, 애플리케이션 변경 또는 인스턴스별 어플라이언스 라우팅 없이 관리되고 확장 가능한 삽입 지점을 제공합니다. 또한 GWLB 대상 그룹을 통해 어플라이언스 플릿의 확장 및 상태 확인을 지원합니다. 주요 AWS 기능: - GWLB는 보안 어플라이언스에 대해 투명한 L3/L4 로드 밸런싱을 제공하고 원래의 소스/대상 IP를 보존합니다. - GWLBe는 애플리케이션 VPC의 탄력적 네트워크 인터페이스(ENI)로, VPC 라우팅 테이블의 다음 홉(next hop)이 됩니다. - 다중 VPC 아키텍처(보안 VPC + 애플리케이션 VPC)와 잘 작동하며 중앙 집중식 검사 패턴을 지원합니다. - 사용자 지정 NAT/프록시 체인을 피하고 단일 서비스 엔드포인트 뒤에서 어플라이언스 Auto Scaling을 활성화하여 운영 오버헤드를 줄입니다. 일반적인 오해: NLB/ALB는 종종 "어플라이언스로 트래픽 전송"을 위해 선택되지만 투명한 인라인 패킷 검사를 위해 설계되지 않았습니다. ALB는 HTTP/HTTPS(Layer 7)이며 연결을 종료합니다. NLB는 L4이지만 GWLB가 제공하는 라우팅 테이블 스티어링 및 어플라이언스 체이닝과 동일한 투명한 서비스 삽입 모델을 제공하지 않습니다. 시험 팁: "AWS Marketplace 보안 어플라이언스", "인라인 검사(inline inspection)", "투명한(transparent)", "전용 보안 VPC", "최소한의 운영 오버헤드"를 보면 GWLB + GWLBe를 생각하십시오. Transit Gateway는 VPC 간의 라우팅 연결을 위한 것이지 어플라이언스에 대한 관리되고 확장 가능한 서비스 삽입을 위한 것이 아닙니다. 참조: AWS Gateway Load Balancer 설명서 및 관리형 서비스를 통해 중앙 집중식 검사 및 운영 부담 최소화에 대한 AWS Well-Architected Framework(보안 원칙) 지침.

2
문제 2

개발자들은 private subnet에 있는 Amazon Linux EC2 instance에 대한 안전한 SSH 접근이 필요합니다. 이들은 원격 및 현장에서 근무합니다. Instance는 NAT gateway를 통해 인터넷에 연결됩니다. 회사는 AWS 서비스를 사용하고 비용을 낮게 유지하고자 합니다. Bastion 없이 가장 비용 효율적이고 안전한 접근 방법을 제공해야 합니다. 어떻게 해야 합니까?

EC2 Instance Connect는 SSH key 전달을 단순화하지만, instance에 대한 네트워크 수준의 SSH 도달 가능성 필요성을 제거하지는 않습니다. Private subnet에서는 포트 22에 도달하기 위해 여전히 bastion host, VPN 또는 Direct Connect와 같은 경로가 필요합니다. 또한 이 옵션은 요구 사항에서 금지하는 bastion host를 명시적으로 생성합니다. 운영상 여전히 접근 호스트 및 관련 보안 제어를 관리해야 합니다.

Site-to-Site VPN은 private 접근에 유효하지만, 분산된 개발자 인력에게 가장 비용 효율적이거나 간단한 방법은 아닙니다. 개발자에게 추가 클라이언트 VPN(또는 "두 번째 VPN")을 사용하도록 요구하면 복잡성, 지원 오버헤드 및 잠재적으로 추가 라이선스/비용이 발생합니다. 또한 솔루션을 간단한 AWS 관리형 관리자 접근 패턴에서 멀어지게 하며, Session Manager와 같은 세션 수준 감사를 본질적으로 제공하지 않습니다.

Public bastion host는 전통적인 패턴이지만 "bastion 없이"라는 요구 사항을 위반하고 운영 부담(패치, 강화, 모니터링, 키 관리 및 사고 대응)을 증가시킵니다. 또한 bastion에 대한 인바운드 SSH를 열고(제한되더라도), security group 규칙을 관리하고, SSH key를 처리해야 합니다. 이는 일반적으로 지속적인 운영을 위한 Session Manager보다 덜 안전하고 비용 최적화가 덜 되어 있습니다.

이것이 가장 적합합니다: EC2 instance role에 AmazonSSMManagedInstanceCore를 연결하고 Systems Manager Session Manager를 사용합니다. 인바운드 포트를 열거나 bastion을 배포하지 않고도 안전한 대화형 접근을 제공하며, 감사를 위해 IAM, CloudTrail 및 CloudWatch/S3로의 선택적 로그 스트리밍과 통합됩니다. 기존 NAT 이그레스를 통해 instance는 SSM endpoint에 도달할 수 있으며, 선택적으로 VPC endpoint를 사용하여 노출 및 NAT 데이터 처리 비용을 추가로 줄일 수 있습니다.

문제 분석

핵심 개념: 이 질문은 SSH(포트 22)를 노출하지 않고 bastion host를 관리하지 않으면서, 비용 최적화된 방식으로 AWS 네이티브 서비스를 사용하여 private EC2 instance에 대한 안전한 관리자 접근을 테스트합니다. 핵심 서비스는 AWS Systems Manager(SSM) Session Manager입니다. 정답인 이유: AmazonSSMManagedInstanceCore 정책을 instance role에 연결하면(그리고 Amazon Linux 2/2023에서 기본적으로 설치/실행되는 SSM Agent가 작동 중인지 확인하면) 인바운드 security group 규칙, public IP 또는 bastion 없이도 private subnet의 instance에 대한 Session Manager 접근이 가능해집니다. Session Manager는 Systems Manager endpoint로의 아웃바운드 연결(NAT gateway를 통한 인터넷 또는 VPC endpoint 경유)을 사용하며, 감사 가능하고 IAM으로 제어되는 대화형 쉘 접근을 제공합니다. 이는 운영 오버헤드와 비용을 낮게 유지하면서 원격 및 현장 개발자 모두를 위한 안전한 SSH 유사 접근 요구 사항을 충족합니다. 주요 AWS 기능 / 모범 사례: - Session Manager는 포트 22를 열지 않고도 브라우저/CLI 기반 쉘 접근을 제공합니다. - IAM 정책은 세션을 시작할 수 있는 사람을 제어합니다. MFA 및 최소 권한을 강제할 수 있습니다. - CloudTrail을 통한 전체 감사 및 CloudWatch Logs/S3로의 선택적 세션 로깅. - Bastion 수명 주기 관리(패치, 강화, 키 교체)가 필요 없습니다. - 더 강력한 보안을 위해 SSM용 VPC interface endpoint(ssm, ssmmessages, ec2messages)를 추가하여 NAT 이그레스를 방지할 수 있지만, 문제에서 이미 NAT가 존재한다고 명시하고 있습니다. 일반적인 오해: 많은 사람들이 SSH에는 bastion이나 VPN이 필요하다고 가정합니다. 작동은 하지만 비용과 운영 부담(bastion) 또는 복잡성(모든 개발자를 위한 VPN)이 추가됩니다. EC2 Instance Connect는 여전히 SSH에 대한 네트워크 도달 가능성을 요구하며 일반적으로 bastion/퍼블릭 경로가 필요합니다. 인바운드 접근 경로의 필요성을 제거하지 않습니다. 시험 팁: "private subnets", "secure admin access", "no bastion", "use AWS services"를 보면 기본적으로 Systems Manager Session Manager를 떠올리십시오. 기존 SSH/VPN 접근 방식과 차별화되는 요소로 IAM role + AmazonSSMManagedInstanceCore, 인바운드 규칙 없음, 감사/로깅을 찾으십시오.

3
문제 3

의료 기관이 임상 시험 데이터 분석을 지원하기 위해 연구 개발 워크로드를 AWS Cloud로 마이그레이션하고 있습니다. 이 기관은 종양학, 심장학 및 신경학을 포함한 여러 연구 부서에 걸쳐 클라우드 인프라에 대한 특정 예산을 할당했습니다. 최고 재무 책임자(CFO)는 각 연구 부서별 클라우드 지출에 대한 명확한 가시성을 요구하며, 총 지출이 할당된 월 예산 $50,000의 75%에 도달하면 자동으로 알림을 받기를 원합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

이 옵션이 정답인 이유는 cost allocation tags가 oncology, cardiology, neurology와 같은 business unit에 resource 비용을 귀속시키기 위한 표준 AWS 메커니즘이기 때문입니다. 해당 tags를 billing settings에서 cost allocation tags로 활성화한 후, 조직은 billing reports와 cost analysis tools를 사용하여 department별 지출을 확인할 수 있습니다. AWS Budgets는 $50,000와 같은 정의된 월간 budget에 대해 실제 또는 예측 지출을 추적하도록 특별히 설계되었습니다. 또한 지출이 75%와 같은 임계값에 도달하면 알림을 보낼 수 있으므로, CFO의 알림 요구 사항을 직접적으로 충족합니다.

이 옵션이 오답인 이유는 AWS Cost Explorer가 resource의 department 소유권을 자동으로 판단하지 않기 때문입니다. Department 수준의 가시성을 확보하려면 cost allocation tags 또는 별도의 AWS accounts와 같은 비용 귀속 방법이 필요합니다. 또한 AWS Cost Anomaly Detection은 $50,000의 75%와 같은 고정 budget 임계값을 모니터링하기 위한 것이 아니라, 과거 패턴과 비교하여 비정상적인 지출 동작을 식별하기 위한 서비스입니다. 따라서 이 옵션은 소유권 귀속 요구 사항과 특정 budget 임계값 알림 요구 사항을 모두 충족하지 못합니다.

이 옵션이 오답인 이유는 cost allocation tags가 department에 비용을 할당하는 데 적절하더라도, AWS Trusted Advisor는 budgeting 또는 spend-threshold notification 서비스가 아니기 때문입니다. Trusted Advisor는 cost optimization, security, performance, service limits, fault tolerance와 관련된 권장 사항을 제공합니다. 이 서비스는 정의된 budget에 대해 월간 지출을 기본적으로 추적하고 75% 사용 시 알림을 보내지 않습니다. Budget 기반 알림에 적합한 올바른 AWS 서비스는 AWS Budgets입니다.

이 옵션이 오답인 이유는 AWS Cost Explorer predictive analytics가 미래 지출 추세를 예측할 수는 있지만, tags 또는 account boundaries 없이 어떤 department가 어떤 resources를 소유하는지 추론할 수 없기 때문입니다. 즉, oncology, cardiology, neurology별 지출에 대한 명확한 가시성 요구 사항을 충족하지 못합니다. AWS Budgets는 월간 budget의 75% 시점에 알림을 보내는 올바른 서비스이지만, 유효한 비용 귀속 메커니즘이 없기 때문에 전체 솔루션은 불완전합니다. 결과적으로 이 옵션은 제시된 요구 사항을 완전히 충족하지 못합니다.

문제 분석

핵심 개념: 이 질문은 비즈니스 단위(연구 부서)에 비용을 할당하고 사전 예산 알림을 적용하는 AWS 비용 거버넌스를 테스트합니다. 주요 서비스는 AWS Cost Allocation Tags(속성 부여용) 및 AWS Budgets(임계값 기반 경고용)입니다. 정답인 이유: CFO는 (1) 종양학/심장학/신경학별 지출에 대한 명확한 가시성과 (2) 총 월 지출이 $50,000 예산의 75%에 도달할 때 자동 알림이 필요합니다. 리소스에 적용되고 결제 콘솔에서 활성화된 비용 할당 태그를 사용하면 Cost Explorer 및 Cost & Usage Report와 같은 도구에서 부서별 비용 보고가 가능합니다. 그런 다음 AWS Budgets를 사용하면 75%($37,500)에서 경고가 발생하고 이메일 및/또는 Amazon SNS를 통해 알림이 전송되는 $50,000의 월간 비용 예산을 생성할 수 있습니다. 이는 속성 부여 및 경고 요구 사항을 모두 직접적으로 충족합니다. 주요 AWS 기능: - 비용 할당 태그: Department=Oncology와 같은 태그를 적용하고 비용 할당 태그로 활성화하여 결제 보고서에 표시되도록 합니다. - AWS Budgets(비용 예산): 총 지출에 대한 월간 예산을 생성합니다. 선택적으로 더 깊은 거버넌스를 위해 부서별로 태그 필터링된 예산을 생성할 수도 있습니다. - 경고: 예산 임계값(실제 지출 및/또는 예측 지출)을 구성하고 자동화를 위해 이메일/SNS로 알림을 보냅니다. - 모범 사례: 일관된 태그 정책(종종 AWS Organizations Tag Policies를 통해)을 사용하여 계정 전체에 태그 지정 표준을 적용합니다. 일반적인 오해: 자주 빠지는 함정은 Cost Explorer "예측 분석"이 소유권을 자동으로 식별할 수 있다고 가정하는 것입니다. Cost Explorer는 지출을 예측할 수 있지만 태그/계정 구조 없이는 부서 소유권을 유추할 수 없습니다. 또 다른 오해는 예산 임계값에 이상 탐지를 사용하는 것입니다. 이상 탐지는 "예산의 75%" 마일스톤이 아니라 비정상적인 지출 패턴을 감지합니다. 시험 팁: "부서/팀/프로젝트별 가시성"이 보이면 비용 할당 태그(또는 별도 계정)와 Cost Explorer/CUR을 생각하십시오. "예산의 X%에서 알림"이 보이면 경고(이메일/SNS)가 있는 AWS Budgets를 생각하십시오. 예기치 않은 급증에는 Anomaly Detection을 사용하고 최적화 검사에는 Trusted Advisor를 사용하십시오. 예산 임계값 알림에는 사용하지 마십시오.

4
문제 4

금융 서비스 회사가 사용자 지정 저장 프로시저 및 독점 분석 도구가 있는 Microsoft SQL Server 데이터베이스에서 고객 포트폴리오 관리 시스템을 운영합니다. 데이터베이스 유지 관리, 백업 관리 및 데이터 센터 비용으로 인한 운영 오버헤드가 증가함에 따라 회사는 신속하게 AWS로 마이그레이션해야 합니다. 애플리케이션은 특수 타사 금융 계산 라이브러리 및 사용자 지정 보안 확장을 사용하기 위해 관리자 권한이 필요합니다. 회사는 예산이 제한되어 있으며 현재 기능을 유지하면서 가장 비용 효율적인 마이그레이션 솔루션을 원합니다. 회사가 데이터베이스를 AWS로 가장 비용 효율적으로 마이그레이션하는 데 도움이 되는 솔루션은 무엇입니까?

Amazon RDS for SQL Server는 운영 오버헤드를 줄이지만 특수 타사 라이브러리 및 사용자 지정 보안 확장을 설치하고 실행하는 데 일반적으로 필요한 수준의 관리자/호스트 액세스를 제공하지 않습니다. 이러한 구성 요소를 AWS Lambda로 교체하는 것은 중요한 재설계이며 신속하게 실현 가능하지 않거나 동일한 기능을 유지하지 못할 수 있습니다. 이 옵션은 금융 시스템에 대한 리팩터링 노력과 위험을 과소평가합니다.

Amazon RDS Custom for SQL Server는 관리형 데이터베이스 이점이 필요하지만 타사 소프트웨어, 에이전트 또는 사용자 지정 보안 확장을 설치하기 위해 관리자 권한이 필요한 사용 사례를 위해 특별히 구축되었습니다. 유지 관리 오버헤드를 줄이면서 현재 SQL Server 기능을 유지하라는 요구 사항과 가장 잘 일치합니다. EC2와 비교할 때 AWS가 백업 및 유지 관리 오케스트레이션과 같은 주요 작업을 관리하므로 일반적으로 총 운영 비용 측면에서 더 비용 효율적입니다.

SQL Server AMI를 사용하여 Amazon EC2에서 SQL Server를 실행하면 전체 관리 제어 권한이 제공되며 모든 타사 라이브러리를 지원할 수 있습니다. 그러나 백업, 패치, 모니터링 및 고가용성/DR 설계에 대한 책임을 회사로 다시 전환하므로 운영 오버헤드를 줄이려는 목표와 충돌합니다. 인스턴스 요금을 최적화할 수는 있지만 지속적인 인건비와 운영 복잡성으로 인해 일반적으로 전체적으로 비용 효율성이 떨어집니다.

Amazon Aurora PostgreSQL로 마이그레이션하려면 애플리케이션, 저장 프로시저를 다시 작성하고 SQL Server 종속성을 제거하고 타사 라이브러리 통합을 재작업해야 합니다. 이는 신속한 마이그레이션이 아닌 현대화 프로젝트이며 상당한 비용, 시간 및 기능적 위험을 초래합니다. Aurora는 장기적으로 비용 효율적일 수 있지만 촉박한 일정 내에 현재 기능을 유지하는 데 가장 비용 효율적인 옵션은 아닙니다.

문제 분석

핵심 개념: 이 질문은 OS/DB 수준의 관리자 권한이 필요한 SQL Server 기능을 보존하면서 가장 비용 효율적인 AWS 데이터베이스 마이그레이션 대상을 선택하는 것을 테스트합니다. 주요 서비스는 Amazon RDS for SQL Server, Amazon RDS Custom for SQL Server 및 Amazon EC2의 SQL Server입니다. 정답인 이유: Amazon RDS Custom for SQL Server는 백업, 패치 오케스트레이션 및 자동화된 모니터링과 같은 차별화되지 않은 과중한 작업을 오프로드하면서 표준 RDS가 허용하는 것 이상의 액세스(예: 타사 에이전트/라이브러리 설치, 사용자 지정 보안 확장 또는 OS/인스턴스 수준 변경)가 필요한 워크로드를 위해 설계되었습니다. 회사는 특수 타사 금융 계산 라이브러리 및 사용자 지정 보안 확장을 사용하기 위해 관리자 권한이 명시적으로 필요합니다. 표준 RDS for SQL Server는 호스트 수준 액세스 및 많은 권한 있는 작업을 제한하므로 현재 기능이 손상될 가능성이 높습니다. EC2는 전체 제어 권한을 유지하지만 운영 오버헤드(패치, 백업, HA 설계, 모니터링)를 줄이지 못하므로 유지 관리 부담과 데이터 센터 비용을 신속하게 줄이려는 목표와 충돌합니다. 주요 AWS 기능: RDS Custom은 자동화된 백업, 특정 시점 복구 및 관리형 유지 관리 기간과 같은 관리형 데이터베이스 이점을 유지하면서 기본 DB 인스턴스/OS(AWS Systems Manager 사용)에 대한 액세스를 통해 "사용자 지정"을 제공합니다. BYOL(Bring-Your-Own-License) 시나리오를 지원하고 AWS KMS 암호화, CloudWatch 지표/로그 및 IAM 제어와 통합됩니다. 일반적으로 전체 아키텍처 재설계 없이 권한 있는 확장이 필요한 "있는 그대로의" SQL Server 워크로드를 마이그레이션하는 가장 빠른 경로입니다. 일반적인 오해: 옵션 C는 EC2가 유연하기 때문에 언뜻 보기에 "가장 저렴해" 보일 수 있지만 지속적인 관리 노력과 HA/DR, 패치 및 백업 프로세스를 엔지니어링해야 할 필요성으로 인해 총 소유 비용이 상승합니다. 옵션 A는 독점적인 데이터베이스 내/호스트 라이브러리를 Lambda로 신속하게 교체할 수 있다고 가정합니다. 이는 일반적으로 주요 리팩터링이며 엄격한 기능 또는 성능 요구 사항을 충족하지 못할 수 있습니다. 옵션 D는 대규모 재작성이며 "신속한 마이그레이션"이 아닙니다. 시험 팁: "시스템 관리자/OS 관리자 액세스 필요", "타사 에이전트", "사용자 지정 드라이버" 또는 "특수 보안 확장"과 같은 요구 사항이 표시되면 RDS Custom(관리형 이점 + 권한 있는 액세스)을 생각하십시오. 운영을 최소화해야 하고 특별한 호스트 액세스가 필요하지 않은 경우 표준 RDS가 일반적으로 비용 최적화된 선택입니다. 최대 제어가 필요하고 운영 부담을 수용할 수 있는 경우 EC2를 선택하십시오.

5
문제 5

한 게임 회사가 /26 CIDR 블록(192.168.1.0/26)이 있는 VPC에 멀티플레이어 게임 서버를 배포했습니다. 게임의 인기가 높아짐에 따라 피크 시간대에 플레이어 트래픽을 처리하기 위해 더 많은 EC2 인스턴스가 필요합니다. 현재 VPC는 64개의 IP 주소만 수용할 수 있지만, 회사는 확장되는 플레이어 기반을 위해 200개 이상의 게임 서버 인스턴스를 지원하도록 확장해야 합니다. 솔루션은 관리 복잡성과 배포 시간을 최소화해야 합니다. 운영 오버헤드가 가장 적게 IP 주소 부족 문제를 해결하는 솔루션은 무엇입니까?

정답입니다. 기존 VPC에 보조 IPv4 CIDR 블록을 연결하는 것은 단일 VPC를 유지하면서 IP 용량을 확장하는 가장 간단한 방법입니다. /22 범위에서 새 서브넷을 생성하고 거기에 추가 게임 서버를 배포할 수 있습니다. 이는 새로운 연결 구성 요소를 피하고, 라우팅/보안 변경을 최소화하며, 다중 VPC 설계에 비해 운영 오버헤드를 줄입니다.

오답입니다. VPC 피어링은 두 개의 VPC 관리, 피어링 구성, 라우팅 테이블 업데이트, VPC 경계 전반의 보안 규칙 처리 등 운영 복잡성을 추가합니다. 또한 제약 조건(전이적 라우팅 불가, 중복을 피하기 위한 신중한 CIDR 계획)을 도입합니다. 작동은 하지만 기존 VPC에 보조 CIDR을 추가하는 것보다 오버헤드가 더 큽니다.

오답입니다. Transit Gateway는 많은 VPC와 온프레미스 네트워크 전반에 걸쳐 확장 가능한 허브 앤 스포크 연결을 위해 설계되었습니다. 더 많은 IP가 필요한 단일 VPC의 경우 TGW는 불필요하며 비용과 구성 복잡성(연결, TGW 라우팅 테이블, 전파/연결)을 추가합니다. 기존 VPC를 확장하는 것만큼 직접적으로 근본 문제를 해결하지 못합니다.

오답입니다. EC2 기반 VPN 인스턴스와 Site-to-Site VPN/가상 프라이빗 게이트웨이를 사용하는 것은 운영 오버헤드가 높으며(인스턴스 관리, 패치 적용, 확장, HA 설계) 단순한 용량 확장을 위해 두 AWS VPC를 연결하는 데 적합한 도구가 아닙니다. 이 옵션은 기본 VPC CIDR 확장보다 배포 속도가 느리고, 장애가 발생하기 쉬우며, 더 복잡합니다.

문제 분석

개요: 핵심 개념: 이 질문은 VPC IP 주소 지정 확장성과 사용 가능한 프라이빗 IPv4 공간을 확장하는 가장 간단한 방법을 테스트합니다. AWS에서 VPC는 기본 IPv4 CIDR과 (선택적으로) 하나 이상의 보조 IPv4 CIDR 블록을 가질 수 있습니다. 그런 다음 연결된 CIDR 블록에서 추가 서브넷을 생성할 수 있습니다. 정답인 이유: 기존 VPC는 /26(총 64개 IP; AWS가 서브넷당 5개를 예약한 후 사용 가능한 수는 더 적음)입니다. 200개 이상의 EC2 게임 서버를 지원하기 위해 회사는 최소한의 운영 오버헤드로 신속하게 더 많은 프라이빗 IP가 필요합니다. 동일한 VPC에 보조 IPv4 CIDR 블록(예: /22)을 추가하는 것이 가장 직접적인 솔루션입니다. 새 VPC, VPC 간 연결, 추가 라우팅 도메인 복잡성, VPC 내 애플리케이션 통신 패턴의 변경이 없습니다. 단순히 새 CIDR을 연결하고, 해당 범위에 새 서브넷을 생성하고, 거기에 추가 인스턴스를 배포하면 됩니다. 주요 AWS 기능: - VPC 보조 IPv4 CIDR 연결: 네트워크를 재설계하지 않고 주소 공간을 확장합니다. - 보조 CIDR의 새 서브넷: 새 Auto Scaling 그룹이나 플릿을 새 서브넷에 배치할 수 있습니다. - 보안 그룹/NACL, IGW/NAT, VPC 엔드포인트: 동일한 VPC에서 재사용할 수 있습니다(종종 새 서브넷 ID를 포함하기 위한 사소한 업데이트만 필요함). - 운영 단순성: 모니터링할 단일 VPC, 단일 핵심 네트워크 구성 요소 세트, 상호 연결 라우팅 정책 없음. 일반적인 오해: 새롭고 더 큰 VPC를 생성하고 연결(피어링, Transit Gateway, VPN)하는 것이 더 "깔끔해" 보일 수 있습니다. 그러나 이러한 접근 방식은 추가 라우팅, 보안 경계 고려 사항, 잠재적인 중복 CIDR 제약 조건 및 운영 작업(여러 VPC, 여러 서브넷 세트, 교차 VPC 트래픽 계획)을 도입합니다. 또한 기존 VPC의 주소 공간을 확장하는 것만큼 간단하게 핵심 문제를 해결하지 못합니다. 시험 팁: VPC 내부의 IP 고갈에 대해 "최소한의 운영 오버헤드"가 요구 사항인 경우, 추가 VPC 및 연결을 생성하는 것보다 보조 IPv4 CIDR(또는 IPv6)을 추가하는 것을 먼저 고려하십시오. Transit Gateway는 다중 VPC/허브 앤 스포크 설계용으로 예약하고, 관리 부담 때문에 프로덕션용 VPN 인스턴스는 피하십시오. 또한 서브넷의 사용 가능한 IP는 AWS의 서브넷당 5개 예약 주소로 인해 줄어들므로 이에 따라 용량을 계획하십시오.

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

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

6
문제 6

글로벌 미디어 제작 회사가 AWS에 비디오 편집 협업 플랫폼을 배포해야 합니다. 이 플랫폼은 북미, 유럽 및 아시아 태평양 지역에 위치한 스튜디오의 영화 편집자와 콘텐츠 제작자에게 서비스를 제공합니다. 사용자는 2GB에서 50GB 크기의 대용량 비디오 파일을 자주 업로드하고 다운로드합니다. 개발 팀은 파일 전송 지연 시간을 최소화하고 글로벌 사용자를 위한 처리량 성능을 극대화하는 비용 효율적인 아키텍처를 요구합니다. 이를 달성하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

정답입니다. Amazon S3 Transfer Acceleration은 사용자를 가장 가까운 엣지 로케이션으로 보낸 다음 AWS 글로벌 네트워크를 사용하여 S3 버킷의 리전에 도달함으로써 글로벌 업로드 및 다운로드 성능을 향상시킵니다. 이는 더 짧은 지연 시간과 더 높은 처리량으로 매우 큰 비디오 파일(2~50GB)의 빈번한 전송을 직접적으로 해결합니다. 대규모 전송 중 병렬 처리 및 더 나은 복원력을 위해 S3 멀티파트 업로드와 결합하십시오.

오답입니다. Cache-Control 헤더는 클라이언트와 중개자가 콘텐츠를 캐시하는 방식에 영향을 미치지만, 대용량 업로드/다운로드를 위한 글로벌 네트워크 경로 최적화를 제공하지는 않습니다. CDN/브라우저가 객체를 캐시하는 경우 반복적인 다운로드를 줄이는 데 도움이 될 수 있지만, 질문은 글로벌 사용자의 빈번한 대용량 파일 전송과 처리량 극대화를 강조하며, 이는 헤더만으로는 부족하고 Transfer Acceleration이나 CDN 전략으로 더 잘 충족되는 요구 사항입니다.

오답입니다. CloudFront는 엣지 로케이션에서 캐시된 콘텐츠를 제공하여 다운로드를 가속화하고 지연 시간을 줄일 수 있지만, EC2에서 비디오 파일을 호스팅하는 것은 대용량 객체 스토리지의 경우 S3에 비해 비용 효율적이거나 운영상 효율적이지 않습니다. 또한 질문은 빈번한 업로드를 강조합니다. CloudFront는 추가 복잡성 없이 대규모 업로드를 가속화하기 위한 기본 서비스가 아닌 반면, S3 Transfer Acceleration은 이 사용 사례를 위해 설계되었습니다.

오답입니다. ElastiCache는 지연 시간이 짧은 데이터 액세스(Redis/Memcached)를 위한 인메모리 캐시이며 수 GB의 비디오 파일을 저장하거나 전송하는 데 적합하지 않습니다. Auto Scaling이 포함된 EC2는 관리 오버헤드를 도입하며 본질적으로 글로벌 전송 지연 시간을 줄이지 않습니다. 이 옵션은 문제를 오해한 것입니다. 과제는 작고 자주 쓰이는 데이터의 애플리케이션 캐싱이 아니라 대용량 객체에 대한 글로벌 네트워크 전송 성능입니다.

문제 분석

개요: 핵심 개념: 이 질문은 Amazon S3 및 엣지 네트워크 최적화를 사용하여 대용량 객체에 대한 글로벌 고처리량 파일 전송 설계를 테스트합니다. 핵심 개념은 수 GB의 파일을 업로드/다운로드하는 지리적으로 분산된 사용자를 위해 지연 시간을 줄이고 처리량을 향상시키는 것입니다. 정답인 이유: Amazon S3 Transfer Acceleration은 트래픽을 가장 가까운 AWS 엣지 로케이션으로 라우팅한 다음 AWS 글로벌 백본 네트워크를 통해 대상 리전으로 전송함으로써 S3 버킷을 오가는 장거리 전송 속도를 높이도록 특별히 구축되었습니다. 2~50GB의 비디오 파일을 업로드하는 북미, 유럽 및 아시아 태평양 사용자의 경우, Transfer Acceleration은 단일 리전으로 퍼블릭 인터넷을 종단 간 통과하는 것에 비해 업로드 및 다운로드 성능을 크게 향상시킬 수 있습니다. 또한 운영상 비용 효율적입니다. S3에 내구성 있고 확장 가능한 객체 스토리지를 유지하고(플릿 관리 없음), S3 스토리지/요청 비용과 사용 시 가속 요금만 지불하면 됩니다. 주요 AWS 기능: - S3 Transfer Acceleration: 가속 엔드포인트(예: bucketname.s3-accelerate.amazonaws.com)와 AWS 엣지 로케이션을 사용하여 TCP 및 라우팅을 최적화합니다. - S3 멀티파트 업로드(multipart upload): 처리량과 복원력을 극대화하기 위한 대용량 파일의 모범 사례(병렬 파트, 파트당 재시도). - 글로벌 백본: 엣지에서 리전으로의 트래픽이 AWS 네트워크에 유지되어 일반적으로 일관성과 처리량이 향상됩니다. - 중앙 S3 버킷(또는 소규모 리전 버킷 세트)이 기록 시스템인 글로벌 협업 패턴에 잘 작동합니다. 일반적인 오해: - CloudFront는 인기 있는 콘텐츠의 다운로드를 캐싱하고 가속화하는 데 탁월하지만, 대용량의 빈번한 업로드를 위한 기본 업로드 가속 솔루션은 아닙니다(추가 설계를 통해 업로드를 지원할 수는 있음). 질문은 매우 큰 파일의 빈번한 업로드 및 다운로드를 강조하며 Transfer Acceleration을 직접적으로 가리킵니다. - Cache-Control 헤더는 캐싱 동작(일반적으로 브라우저/CDN에 의한)에만 영향을 미치며 본질적으로 글로벌 업로드 처리량을 향상시키지는 않습니다. - EC2 + Auto Scaling은 운영 오버헤드를 추가하며 본질적으로 글로벌 전송 지연 시간을 해결하지 않습니다. 병목 현상은 컴퓨팅 확장이 아니라 네트워크 거리와 라우팅입니다. 시험 팁: "글로벌 사용자", "대용량 파일 업로드", "전송 지연 시간 최소화 / 처리량 극대화"를 보면 S3 Transfer Acceleration(업로드/다운로드) 및 멀티파트 업로드를 생각하십시오. 요구 사항이 주로 "다운로드 가속 및 캐싱"인 경우 CloudFront를 생각하십시오. 또한 질문에서 POSIX 파일 시스템이나 특수 컴퓨팅 처리를 명시적으로 요구하지 않는 한 비용과 확장성을 위해 자체 관리형 EC2 파일 호스팅보다 관리형 스토리지(S3)를 선호하십시오.

7
문제 7

생명공학 연구 회사가 온프레미스 연구소에서 호스팅되는 게놈 시퀀싱 분석을 위한 고성능 컴퓨팅(high-performance computing) 솔루션을 개발하고 있습니다. 연구 팀은 병렬 I/O 작업이 필요한 특수 생물정보학 소프트웨어를 사용하여 대규모 데이터 세트(분석당 5-50TB)를 처리합니다. 회사는 1밀리초 미만(sub-millisecond)의 지연 시간으로 POSIX 호환 병렬 파일 시스템 액세스를 지원하는 공유 스토리지 솔루션이 필요합니다. 이 솔루션은 완전 관리형이어야 하며 피크 처리 기간 동안 100개 이상의 컴퓨팅 노드에서 발생하는 동시 액세스를 처리할 수 있도록 확장 가능해야 합니다. 고성능 병렬 파일 시스템 액세스에 대한 이러한 요구 사항을 충족하는 AWS 솔루션은 무엇입니까?

Storage Gateway Volume Gateway(저장 볼륨)는 온프레미스 호스트에 iSCSI 블록 볼륨을 제공하며 하이브리드 블록 스토리지 및 AWS로의 백업에 유용합니다. 그러나 POSIX 호환 병렬 파일 시스템이 아니며 100개 이상의 노드에 걸쳐 Lustre와 같은 병렬 I/O 의미론을 제공하지 않습니다. iSCSI 공유 블록 액세스는 또한 조정/클러스터 파일 시스템 복잡성을 도입하며 1밀리초 미만의 고동시성 HPC 파일 워크로드를 위해 설계되지 않았습니다.

EBS(RAID된 gp3라도)를 사용하여 EC2 인스턴스에 병렬 파일 시스템을 구축하는 것은 완전 관리형 솔루션이 아니며 단일 인스턴스 병목 현상 및 운영 위험(패치 적용, 확장, HA, 메타데이터 성능)을 생성합니다. EBS는 EC2에 연결된 블록 스토리지입니다. 많은 노드에서 이를 공유하려면 추가 클러스터링이 필요하며 일반적으로 HPC 게놈 워크로드에 예상되는 관리형의 수평 확장 가능한 병렬 I/O 아키텍처를 제공할 수 없습니다.

Amazon EFS는 NFSv4.1을 통해 관리형 POSIX 호환 공유 파일 스토리지를 제공하며 처리량을 확장할 수 있습니다(Max I/O 모드, Provisioned Throughput). 그러나 EFS는 Lustre와 같은 병렬 파일 시스템이 아닙니다. 초저지연, 높은 처리량의 병렬 I/O 패턴보다는 일반적인 공유 파일 액세스에 최적화되어 있습니다. 1밀리초 미만의 지연 시간과 병렬 스트라이핑이 필요한 HPC 스크래치 및 게놈 파이프라인의 경우 EFS는 일반적으로 가장 적합하지 않습니다.

Amazon FSx for Lustre는 높은 처리량, 낮은 지연 시간 및 많은 컴퓨팅 노드의 동시 액세스가 필요한 HPC 워크로드를 위해 설계된 완전 관리형 Lustre 병렬 파일 시스템입니다. POSIX 의미론과 스토리지 서버 전반의 파일 스트라이핑을 통한 병렬 I/O를 지원하여 매우 높은 집계 성능을 가능하게 합니다. SSD 스토리지를 사용하는 것은 1밀리초 미만의 지연 시간 요구 사항과 일치하며 실행당 5-50TB의 집중적인 게놈 시퀀싱 분석을 지원합니다.

문제 분석

핵심 개념: 이 질문은 많은 동시 클라이언트가 있는 HPC 워크로드를 위해 매우 낮은 지연 시간과 높은 처리량을 제공하는 완전 관리형 POSIX 호환 병렬 파일 시스템의 선택을 테스트합니다. AWS에서 이를 위해 특별히 구축된 관리형 서비스는 Amazon FSx for Lustre입니다. 정답인 이유: Amazon FSx for Lustre는 많은 컴퓨팅 노드의 병렬 I/O가 필요한 게놈, 시뮬레이션 및 ML과 같은 워크로드를 위해 설계된 고성능 병렬 파일 시스템(Lustre)을 제공합니다. POSIX 의미론을 지원하며 여러 스토리지 서버에 데이터를 스트라이핑하여 1밀리초 미만의 지연 시간과 대규모 집계 처리량에 최적화되어 있습니다. 수백 또는 수천 개의 클라이언트를 지원하도록 확장되어 피크 처리 중 100개 이상의 컴퓨팅 노드에 대한 요구 사항과 일치합니다. 주요 AWS 기능: FSx for Lustre는 완전 관리형입니다(프로비저닝, 패치 적용, 모니터링 및 복구를 AWS에서 처리함). SSD 스토리지를 사용하면 가장 낮은 지연 시간과 가장 높은 IOPS 특성을 제공합니다. 컴퓨팅 노드의 Lustre 클라이언트는 진정한 병렬 읽기/쓰기, 메타데이터 성능 및 파일 스트라이핑을 가능하게 합니다. 이는 기존 NFS 기반 시스템이 동일한 성능 수준에서 제공하지 못하는 기능입니다. FSx for Lustre는 일반적으로 HPC 컴퓨팅 플릿과 짝을 이루며 데이터 리포지토리 기능(대규모 게놈 데이터 세트를 스테이징하는 데 유용함)을 위해 S3와 통합될 수 있지만, 여기서 핵심 요구 사항은 병렬 POSIX 액세스와 낮은 지연 시간입니다. 일반적인 오해: Amazon EFS는 종종 "공유 POSIX 스토리지"로 선택되지만 NFS 파일 시스템이며 HPC 스크래치 워크로드를 위한 Lustre 스타일의 병렬 I/O 또는 일반적인 1밀리초 미만의 지연 시간을 제공하지 않습니다. Storage Gateway Volume Gateway는 하이브리드 사용 사례를 위한 블록 스토리지 통합을 제공하지만 병렬 파일 시스템이 아니며 초저지연, 고동시성 HPC I/O 패턴을 위해 설계되지 않았습니다. 시험 팁: "병렬 파일 시스템", "Lustre", "HPC", "게놈", "1밀리초 미만의 지연 시간" 및 "100개 이상의 노드"가 보이면 기본적으로 FSx for Lustre를 선택하십시오. 일반적인 공유 NFS(웹/콘텐츠, 홈 디렉터리)의 경우 EFS를 선택하고, 처리량이 높고 지연 시간이 짧은 병렬 워크로드의 경우 FSx for Lustre를 선택하십시오. 또한 "완전 관리형"은 시험에서 DIY EC2 기반 파일 서버를 최선의 답변에서 제외시킵니다.

8
문제 8
(2개 선택)

한 금융 서비스 회사가 온프레미스 Red Hat Enterprise Linux 서버에서 Java 기반 거래 애플리케이션을 운영하고 있습니다. 이 애플리케이션은 트랜잭션 데이터와 시장 분석을 저장하기 위해 MySQL Enterprise 데이터베이스를 사용합니다. 증가하는 규제 요구 사항과 비즈니스 성장으로 인해 회사는 AWS로 마이그레이션해야 합니다. 회사는 마이그레이션 중 코드 변경을 최소화하는 동시에 AWS 환경이 내결함성을 제공하고 피크 시장 시간(오전 9시~오후 4시 EST) 동안 거래량을 처리할 수 있도록 보장하고자 합니다. 이러한 요구 사항을 충족하기 위해 회사는 어떤 조치 조합을 취해야 합니까? (2개 선택)

여러 AZ에 걸쳐 ALB가 있는 AWS Fargate는 고가용성 및 확장이 가능하지만 레거시 Java 앱을 컨테이너화하려면 일반적으로 컨테이너 이미지를 생성하고 구성, 로깅 및 CI/CD 프로세스를 조정해야 합니다. 이는 간단한 EC2 리호스트보다 더 많은 변경입니다. 복원력 목표를 충족할 수 있지만 기존 RHEL 기반 배포에 대한 EC2 Auto Scaling에 비해 "코드 변경 최소화"에 가장 적합하지는 않습니다.

ALB 뒤의 여러 AZ에 걸친 Auto Scaling group에서 EC2의 애플리케이션을 실행하면 최소한의 리팩터링으로 내결함성과 탄력성을 모두 제공합니다. 이는 고전적인 리호스트 접근 방식입니다. Java 앱을 크게 변경하지 않고 유지하고, 복원력 있는 라우팅을 위해 ALB 상태 검사를 사용하며, 수요에 따라 scale out/in합니다. 예약된 조정은 예측 가능한 피크 거래 시간과 잘 일치하며, Multi-AZ 배치는 AZ 중단으로부터 보호합니다.

API Gateway와 함께 AWS Lambda의 마이크로서비스로 애플리케이션을 다시 작성하는 것은 주요 리팩터링입니다. 애플리케이션 아키텍처, 배포 모델 및 종종 데이터 액세스 패턴을 변경하므로 코드 변경을 최소화하라는 요구 사항과 충돌합니다. 서버리스는 확장이 잘 되고 운영을 줄일 수 있지만 상당한 재설계 노력과 위험을 도입합니다. 일반적으로 거래 플랫폼의 시간에 민감한 마이그레이션에는 적절하지 않습니다.

Multi-AZ에서 MySQL을 Aurora MySQL로 마이그레이션하는 AWS DMS는 최소한의 코드 변경 및 고가용성과 잘 일치합니다. Aurora MySQL은 MySQL과 호환되므로 애플리케이션 변경을 줄이는 동시에 관리형 백업, 복제 및 빠른 장애 조치를 제공합니다. DMS는 전체 로드 및 변경 데이터 캡처(CDC)를 지원하여 가동 중지 시간이 거의 없는 마이그레이션을 가능하게 합니다. 이는 제어된 컷오버와 지속적인 데이터 무결성이 필요한 규제 대상 금융 시스템에 중요합니다.

MySQL에서 Amazon DocumentDB(MongoDB 호환)로 마이그레이션하는 것은 데이터베이스 모델 변경(관계형에서 문서형으로)입니다. 이를 위해서는 상당한 스키마 재설계, 쿼리 재작성 및 애플리케이션 코드 변경이 필요하므로 "코드 변경 최소화" 요구 사항을 위반합니다. DocumentDB는 AZ 전반에 배포할 수 있지만 MySQL을 직접 대체할 수 없으며 거래 시스템의 일반적인 트랜잭션 관계형 워크로드에 가장 적합한 선택이 아닙니다.

문제 분석

핵심 개념: 이 질문은 상태 저장(stateful), 규제 대상 워크로드에 대한 "복원력이 있는 리프트 앤 시프트(lift-and-shift)"를 테스트합니다. 즉, 내결함성을 달성하고 예측 가능한 피크 수요를 처리하면서 코드 변경을 최소화하여 Java 앱을 실행하는 것입니다. 핵심 서비스는 애플리케이션 계층을 위한 EC2 Auto Scaling + Application Load Balancer(ALB)와 데이터베이스 계층을 위한 Aurora MySQL Multi-AZ이며, AWS DMS로 마이그레이션됩니다. 정답인 이유: 옵션 B는 기존 Java 애플리케이션을 Amazon EC2에 배포하는 것이 현재 RHEL 서버와 가장 유사하기 때문에 "코드 변경 최소화"와 가장 잘 일치합니다. ALB 뒤에 여러 Availability Zone에 걸쳐 Auto Scaling group을 사용하면 고가용성(AZ 장애 허용)과 피크 거래 시간(오전 9시-오후 4시 EST) 동안 scale out하고 이후에 scale in할 수 있는 탄력성을 제공합니다. 옵션 D는 가용성과 운영 복원력을 향상시키면서 관계형 MySQL 엔진 의미 체계를 보존합니다. AWS DMS를 사용하여 Amazon Aurora MySQL(MySQL과 호환됨)로 마이그레이션하면 데이터베이스 패러다임 전환에 비해 애플리케이션 변경이 최소화됩니다. Aurora Multi-AZ(작성자 및 AZ 전반에 복제된 스토리지, 장애 조치 포함)는 금융 워크로드에 적합한 강력한 내결함성을 제공합니다. 주요 AWS 기능: - 정상적인 instance로만 트래픽을 라우팅하기 위한 ALB 상태 검사 + 교차 AZ 로드 밸런싱. - 피크 처리를 위한 예약된 조정(예측 가능한 시장 시간) 및/또는 대상 추적(CPU/RequestCount)이 있는 EC2 Auto Scaling. - 리팩터링을 줄이기 위한 Aurora MySQL 호환성; Multi-AZ 장애 조치 및 관리형 백업. - 컷오버 중 가동 중지 시간을 줄이기 위한 지속적인 복제(CDC)를 위한 AWS DMS. 일반적인 오해: Fargate(A)도 운영을 줄일 수 있지만 "컨테이너화"는 종종 패키징 변경, 새로운 빌드 파이프라인 및 잠재적인 런타임 차이를 의미하며, 이는 간단한 EC2 리호스팅보다 더 많은 변경입니다. Lambda(C)로 다시 작성하는 것은 "코드 변경 최소화"의 반대입니다. DocumentDB(E)는 MySQL과 호환되지 않습니다. MongoDB와 호환되며 상당한 스키마/쿼리 리팩터링이 필요합니다. 시험 팁: "코드 변경 최소화"가 보이면 리팩터링(Lambda/마이크로서비스) 또는 데이터베이스 모델 변경(NoSQL)보다 리호스트/리플랫폼 패턴(EC2, 관리형 관계형 DB)을 기본으로 사용하십시오. "내결함성"의 경우 컴퓨팅(AZ 전반의 ASG) 및 데이터(Aurora Multi-AZ) 모두에서 Multi-AZ 설계를 찾고 가동 중지 시간이 짧은 마이그레이션을 위해 DMS를 고려하십시오.

9
문제 9

한 금융 서비스 회사가 AWS에서 실시간 거래 플랫폼을 운영하고 있습니다. 모든 거래 주문은 단일 Availability Zone의 Amazon EC2 인스턴스에서 실행되는 RabbitMQ 대기열에 메시지로 게시됩니다. 이 메시지들은 별도의 EC2 인스턴스에서 실행되는 위험 평가 애플리케이션에 의해 처리됩니다. 이 애플리케이션은 거래 데이터를 또 다른 EC2 인스턴스의 MySQL 데이터베이스에 저장합니다. 모든 EC2 인스턴스는 동일한 Availability Zone에 있습니다. 이 회사는 99.9%의 가동 시간을 요구하는 규정 준수 요구 사항으로 인해 최소한의 운영 오버헤드로 최고의 가용성을 제공하도록 아키텍처를 재설계해야 합니다. 솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

Amazon MQ for RabbitMQ는 브로커 운영을 줄이고 HA를 개선하기 위한 좋은 단계입니다. 그러나 Multi-AZ Auto Scaling 그룹의 EC2에 MySQL을 배치하는 것은 그 자체로 유효한 HA 데이터베이스 전략이 아닙니다. Auto Scaling은 인스턴스를 교체할 수 있지만 동기식 복제, 일관된 스토리지 또는 자동 데이터베이스 장애 조치를 제공하지 않습니다. 이 옵션은 데이터베이스 계층에 상당한 운영 오버헤드와 위험을 남깁니다.

정답입니다. Amazon MQ는 AZ 전반에 걸쳐 active/standby 중복성을 갖춘 관리형 RabbitMQ를 제공하여 운영 부담을 줄이고 가용성을 향상시킵니다. Multi-AZ Auto Scaling 그룹의 위험 애플리케이션은 자가 복구 및 AZ 복원력을 갖추게 됩니다(일반적으로 ALB 뒤에 위치). MySQL을 Amazon RDS for MySQL Multi-AZ로 마이그레이션하면 관리형 백업, 패치, 동기식 복제 및 자동 장애 조치가 제공되어 최소한의 운영 노력으로 99.9%의 가동 시간을 충족합니다.

Multi-AZ Auto Scaling을 사용하여 EC2에서 RabbitMQ를 실행하는 것은 운영상 무겁고 본질적으로 HA가 아닙니다. RabbitMQ는 클러스터링/쿼럼 구성, 내구성 있는 스토리지 설계, 신중한 노드 교체 및 클라이언트 재연결 처리가 필요합니다. Auto Scaling만으로는 파괴적인 교체를 유발할 수도 있습니다. RDS Multi-AZ가 데이터베이스를 위한 올바른 선택이긴 하지만, 브로커 계층은 여전히 Amazon MQ를 사용하는 것보다 높은 운영 오버헤드를 가집니다.

이 옵션은 상태 저장 시스템인 RabbitMQ와 MySQL 모두에 대해 전적으로 EC2 Auto Scaling에 의존합니다. Auto Scaling은 브로커/데이터베이스에 대한 데이터 복제, 내구성 있는 공유 스토리지 또는 조정된 장애 조치를 자동으로 제공하지 않습니다. 클러스터링/복제, 백업 및 장애 조치 메커니즘을 직접 구축하고 운영해야 하므로 '최소한의 운영 오버헤드' 요구 사항과 충돌하고 가동 중지 시간의 위험이 증가합니다.

문제 분석

핵심 개념: 이 질문은 관리형 서비스(Amazon MQ, Amazon RDS Multi-AZ)와 상태 비저장 스케일링 패턴(Auto Scaling)을 사용하여 최소한의 운영 오버헤드로 Availability Zone 전반에 걸친 고가용성(HA)을 설계하는 능력을 테스트합니다. 정답인 이유: 현재 설계는 단일 AZ의 EC2 관리형 스택(RabbitMQ, 앱, MySQL)으로, 여러 단일 장애점과 높은 운영 부담(패치, 백업, 장애 조치, 모니터링, 복구)을 발생시킵니다. 최소한의 운영 오버헤드로 99.9%의 가동 시간을 충족하기 위한 최선의 접근 방식은 (1) 브로커를 관리형 HA 서비스로 이동하고, (2) 데이터베이스를 관리형 Multi-AZ 서비스로 이동하며, (3) 애플리케이션 계층을 Multi-AZ 및 자가 복구 가능하게 만드는 것입니다. 옵션 B가 정확히 이를 수행합니다. Amazon MQ for RabbitMQ는 AZ 전반에 걸쳐 내장된 active/standby 브로커 중복성을 제공하며, Amazon RDS for MySQL Multi-AZ는 동기식 복제 및 자동 장애 조치를 제공합니다. 위험 평가 애플리케이션은 인스턴스/AZ 장애를 견딜 수 있도록 로드 밸런서(암시됨) 뒤의 Multi-AZ Auto Scaling 그룹에 배포될 수 있습니다. 주요 AWS 기능: - Amazon MQ for RabbitMQ: 관리형 브로커, 자동화된 프로비저닝/패치, HA를 위한 active/standby 배포, 간소화된 모니터링/통합. - Amazon RDS for MySQL Multi-AZ: 다른 AZ의 대기 인스턴스로의 동기식 복제, 자동 장애 조치, 관리형 백업, 패치 및 유지 관리. - 여러 AZ의 서브넷에 걸친 EC2 Auto Scaling: 실패한 인스턴스를 자동으로 교체하고 스케일링을 지원합니다. 탄력적인 트래픽 분산을 위해 Application Load Balancer와 함께 사용합니다. 일반적인 오해: A와 D는 EC2의 데이터베이스에 Auto Scaling을 사용할 것을 제안합니다. 데이터베이스는 상태 저장(stateful)입니다. Auto Scaling 자체는 데이터베이스 복제, 일관된 스토리지 또는 자동 장애 조치를 제공하지 않습니다. 여전히 복제, 백업 및 장애 조치를 직접 엔지니어링해야 합니다(높은 운영 오버헤드). C와 D는 또한 Auto Scaling을 사용하여 EC2에서 RabbitMQ를 실행할 것을 제안합니다. 메시지 브로커는 상태 저장이며 클러스터링/쿼럼, 내구성 있는 스토리지 및 신중한 장애 조치 처리가 필요하므로 Amazon MQ에 비해 운영 복잡성이 다시 증가합니다. 시험 팁: 요구 사항이 '최고의 가용성'과 '최소한의 운영 오버헤드'를 강조할 때, 내장된 Multi-AZ 및 자동 장애 조치 기능이 있는 관리형 서비스(RDS Multi-AZ, Amazon MQ 등)를 선호하십시오. 상태 비저장 계층에는 Auto Scaling을 사용하고, Auto Scaling만으로 상태 저장 구성 요소(데이터베이스/브로커)를 고가용성으로 만든다고 가정하지 마십시오.

10
문제 10
(3개 선택)

한 의료 네트워크가 .csv 형식으로 진단 보고서를 생성하는 on-premises 의료 영상 기기를 갖춘 여러 클리닉을 운영하고 있습니다. 이 네트워크는 더 나은 확장성과 비용 효율성을 위해 데이터 분석을 AWS Cloud로 마이그레이션하고자 합니다. 영상 기기는 SMB file share에 데이터를 쓸 수 있으며, 의료 연구 팀은 환자 진단 추세에 대해 SQL 기반 분석을 수행해야 합니다. 연구 팀은 업무 시간 동안 매일 3~4회 분석 쿼리를 실행합니다. 솔루션은 비용 효율적이어야 하며 의료 기기에서 생성된 .csv 파일에 대한 표준 SQL 쿼리 기능을 지원해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 단계의 조합은 무엇입니까? (3개 선택)

정답입니다. S3 File Gateway 모드의 AWS Storage Gateway는 on-prem 기기에 SMB file share를 노출하고 파일을 Amazon S3의 객체로 저장합니다. 이는 클라우드 기반 분석을 활성화하면서 영상 기기가 SMB share에 쓸 수 있어야 한다는 요구 사항과 일치합니다. 사용자 지정 수집 파이프라인을 피하고 on-premises에서 선택적 캐싱과 함께 S3의 저비용 스토리지를 활용하므로 비용 효율적입니다.

오답입니다. FSx는 관리형 파일 시스템 서비스(예: FSx for Windows File Server)이지만, "FSx File Gateway 모드"는 파일 기반 분석을 위해 데이터를 S3에 저장하기 위한 적절한 Storage Gateway 옵션이 아닙니다. 요구 사항은 SQL을 사용하여 비용 효율적으로 .csv 파일을 쿼리하는 것입니다. 이 패턴은 FSx 기반 파일 시스템을 유지 관리하는 것이 아니라 데이터 레이크 스토리지로서 S3를 사용하는 것이 가장 좋습니다.

정답입니다. AWS Glue crawler는 S3의 .csv 데이터를 스캔하고, 스키마를 추론하며, AWS Glue Data Catalog에서 테이블을 생성/업데이트할 수 있습니다. Athena는 테이블 정의를 위해 Data Catalog에 의존하므로 수동 DDL 관리 없이 표준 SQL 쿼리를 활성화합니다. 이는 여러 클리닉에서 새 파일이 정기적으로 도착하고 시간이 지남에 따라 스키마가 발전할 수 있을 때 특히 유용합니다.

오답입니다. EMRFS가 있는 Amazon EMR은 Spark/Hive/Presto를 사용하여 S3의 데이터를 쿼리할 수 있지만 cluster 프로비저닝 및 지속적인 관리가 필요합니다. 하루에 3~4회의 분석 쿼리만 실행하는 경우, 임시 cluster를 구축하고 오케스트레이션하여 복잡성을 추가하지 않는 한 EC2 인스턴스(및 종종 유휴 시간)에 대한 비용을 지불해야 하므로 EMR은 일반적으로 Athena보다 비용 효율성이 떨어집니다.

오답입니다. Amazon Redshift는 COPY 또는 Redshift Spectrum을 사용하여 S3를 쿼리할 수 있지만 Redshift cluster는 더 높은 고정 비용과 운영 고려 사항을 도입합니다. 매일 몇 번 원시 CSV 파일에 대한 ad hoc SQL 쿼리를 수행하는 경우 Athena가 일반적으로 가장 비용 효율적인 serverless 선택입니다. Redshift는 지속적으로 높은 동시성, 복잡한 웨어하우징 또는 큐레이팅된 데이터 세트에 대한 빈번한 쿼리가 필요할 때 더 좋습니다.

정답입니다. Amazon Athena는 S3의 .csv 파일에서 직접 serverless 표준 SQL 쿼리를 제공하고 스캔한 데이터당 요금을 청구하므로 업무 시간 동안의 간헐적인 분석에 이상적입니다. 스키마를 위해 AWS Glue Data Catalog와 통합되며, 서버를 관리하지 않고도 비용을 줄이고 성능을 향상시키기 위해 파티셔닝 및 열 형식(나중에 최적화되는 경우)을 지원합니다.

문제 분석

핵심 개념: 이 질문은 on-premises에서 생성된 파일에 대한 비용 최적화된 serverless 분석 패턴을 테스트합니다. .csv 데이터를 Amazon S3에 저장하고 Amazon Athena를 사용하여 표준 SQL로 쿼리하며, AWS Glue Data Catalog가 스키마 메타데이터를 제공합니다. 정답인 이유: 의료 기기는 SMB share에만 쓸 수 있으므로, 사용자 지정 전송 소프트웨어를 구축하지 않고 AWS로 수집하는 가장 비용 효율적인 방법은 S3 File Gateway 모드의 AWS Storage Gateway(A)입니다. 이는 로컬에 SMB file share를 제공하고 객체를 Amazon S3에 내구성 있게 저장하므로 .csv 보고서 파일에 이상적입니다. 데이터가 S3에 저장되면 연구 팀은 하루에 몇 번 SQL 쿼리를 실행해야 합니다. Amazon Athena(F)는 serverless이며 스캔한 TB당 요금을 청구하므로 항상 켜져 있는 cluster에 비해 간헐적인 분석에 매우 비용 효율적입니다. 적절한 스키마, 파티션 및 테이블 정의를 사용하여 SQL 쿼리를 활성화하려면 AWS Glue crawler(C)가 S3 데이터에서 스키마를 추론하고 Athena가 사용하는 Glue Data Catalog에서 테이블을 생성/유지 관리할 수 있습니다. 주요 AWS 기능: S3 File Gateway는 S3에 데이터를 영구 저장하면서 지연 시간이 짧은 액세스를 위한 로컬 캐싱과 함께 SMB/NFS 액세스를 지원합니다. S3는 보존을 위한 저비용의 내구성 있는 스토리지 및 수명 주기 정책을 제공합니다. Glue crawler는 스키마 검색을 자동화하고 Data Catalog를 업데이트합니다. Athena는 Presto/Trino 기반 SQL을 사용하고, Glue Data Catalog와 통합되며, 스캔되는 데이터를 줄이기 위해 파티셔닝(날짜/클리닉별)을 지원하고, 미사용 데이터(S3 SSE-KMS) 및 전송 중 데이터를 암호화할 수 있습니다. 일반적인 오해: EMR(D)은 S3를 쿼리할 수 있지만 cluster를 프로비저닝하고 비용을 지불해야 하므로(또는 일시적인 cluster를 관리해야 하므로) 매일 3~4회의 쿼리를 실행하기에는 일반적으로 더 비싸고 운영 부담이 큽니다. Redshift(E)는 COPY/Spectrum을 통해 S3를 쿼리할 수 있지만, 원시 CSV에 대한 가볍고 주기적인 ad hoc 쿼리의 경우 cluster(또는 serverless)가 가장 비용 효율적인 방법은 아닙니다. FSx File Gateway 모드(B)는 여기에 적합하지 않습니다. 요구 사항은 AWS에서 Windows 파일 시스템을 유지 관리하는 것이 아니라 S3 객체에 대한 분석과 함께 SMB 수집을 수행하는 것입니다. 시험 팁: 간헐적으로 사용하는 "S3의 파일에 대한 SQL"의 경우 기본적으로 Athena + Glue Data Catalog를 선택하십시오. 사용자 지정 코드 없이 "on-prem SMB/NFS에서 S3로"의 경우 기본적으로 Storage Gateway S3 File Gateway를 선택하십시오. "매일 몇 번" 및 "비용 효율적"과 같은 비용 단서를 찾으십시오. 이는 일반적으로 항상 켜져 있는 cluster를 배제합니다.

합격 후기(30)

C
C*********Mar 23, 2026

학습 기간: 1 week

요구사항 정확히 인지하기(이거 젤중요 이 훈련이 제일 중요한듯), 오답노트 갈겨서 200문제만 확실히 해서 갔어요 실제 시험 지문은 훨씬 간단한데 난이도는 앱이랑 비슷하거나 더 낮았던것같아요 느낌상 탈락이었는데 통과해서 기쁘네요 큰 도움 되었습니다 감사해요!

소
소**Feb 22, 2026

학습 기간: 1 week

그냥 문제 풀면서 개념들 GPT에 물어보면서 학습했어요 768점 턱걸이 합격,,

조
조**Jan 12, 2026

학습 기간: 3 months

그냥 꾸준히 공부하고 문제 풀고 합격했어요 saa 준비생분들 화이팅!!

김
김**Dec 9, 2025

학습 기간: 1 month

앱으로는 4일만에 몇 문제를 풀었는지 모르겠지만 1딜동안 aws 기본 개념부터 덤프로 시나리오 그려보고 하니까 합격했습니다. 시험은 생각보다 헷갈리게 나와서 당황했는데 30분 추가 테크로 flag한 지문들 다시 확인하니까 문제 없었습니다.

L
L*************Nov 26, 2025

학습 기간: 3 months

I passed the AWS SAA with a score of 850/1000. Honestly, the exam wasn’t easy, but solving the actual exam–style questions in Cloud Pass helped me understand the reasoning behind each service. The explanations were super helpful and made the concepts stick. I don’t think I could’ve scored this high without the practice here.

다른 모의고사

Practice Test #1

65 문제·130분·합격 720/1000

Practice Test #2

65 문제·130분·합격 720/1000

Practice Test #4

65 문제·130분·합격 720/1000

Practice Test #5

65 문제·130분·합격 720/1000

Practice Test #6

65 문제·130분·합격 720/1000

Practice Test #7

65 문제·130분·합격 720/1000

Practice Test #8

65 문제·130분·합격 720/1000

Practice Test #9

65 문제·130분·합격 720/1000

Practice Test #10

65 문제·130분·합격 720/1000
← 모든 AWS Certified Solutions Architecture - Associate (SAA-C03) 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 AWS Certified Solutions Architecture - Associate (SAA-C03) 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

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

앱 받기

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