AWS
AWS Certified Solutions Architecture - Associate (SAA-C03)
1,007+ 기출 문제 (AI 검증 답안 포함)
실제 시험
기출 문제
상세
해설
실제 시험과
가장 유사AI 기반
3중 AI 검증 답안 및 해설
모든 AWS Certified Solutions Architecture - Associate (SAA-C03) 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
시험 도메인
실전 문제
웹 서비스가 load balancer 뒤의 EC2에서 실행되고 있지만, 많은 클라이언트가 방화벽을 통해 allowlist된 IP만 허용할 수 있습니다. 고정 IP를 통해 서비스에 접근할 수 있도록 해야 합니다. 무엇을 권장해야 합니까?
정답입니다. Network Load Balancer는 subnet mapping을 통해 Availability Zone당 Elastic IP(또는 AWS 소유 static IP)를 사용하여 static IP 주소를 지원합니다. 이는 다중 AZ 고가용성 및 관리형 load balancing을 유지하면서 클라이언트 방화벽 allowlisting 요구 사항을 직접적으로 해결합니다. 클라이언트는 장애 조치 중 복원력을 보장하기 위해 모든 NLB EIP(활성화된 AZ당 하나)를 allowlist해야 합니다.
오답입니다. Application Load Balancer에는 Elastic IP 주소를 할당할 수 없습니다. ALB는 DNS 이름을 통해 접근되며 기본 IP는 확장 및 유지 관리로 인해 시간이 지남에 따라 변경될 수 있습니다. IP allowlisting 요구 사항의 경우, 다른 서비스(예: Global Accelerator)와 결합하지 않는 한 ALB 단독으로는 적합하지 않으며, 이는 옵션에 제공되지 않았습니다.
오답입니다. Route 53 A record는 Elastic IP를 가리킬 수 있지만, 이는 트래픽을 단일 public 엔드포인트로 라우팅하며 load balancing이나 내재적인 다중 AZ 복원력을 제공하지 않습니다. load balancer를 단일 IP target으로 대체하게 되어 단일 장애점(single point of failure)을 생성하고 관리형 load balancing 동작을 잃게 됩니다.
오답입니다. load balancer 앞에 public EC2 proxy를 배치하면 고정 IP를 제공할 수 있지만, 이는 복원력 및 운영 측면에서 안티 패턴입니다. 단일 장애점을 도입하고(여러 proxy를 구축하고 관리하지 않는 한), 패치/유지 관리 부담을 가중시키며, 병목 현상이 될 수 있습니다. 가용성과 보안을 위해 AWS 관리형 솔루션(EIP가 있는 NLB)이 선호됩니다.
문제 분석
Core Concept: 이 질문은 AWS에서 load-balanced 서비스에 대해 고정되고 allowlist 가능한 public IP 주소를 제공하는 방법을 테스트합니다. 핵심적인 차이점은 대부분의 AWS load balancer(특히 ALB)가 static IP를 제공하지 않으며, 대신 일반적으로 DNS를 사용한다는 것입니다. 고객이 IP 기반 방화벽 allowlisting을 요구할 때, 안정적인 IP를 제공할 수 있는 아키텍처가 필요합니다. Why the Answer is Correct: Network Load Balancer(NLB)는 NLB 노드가 있는 각 subnet/AZ에 대해 Elastic IP 주소(EIP)와 연결될 수 있습니다. 이를 통해 클라이언트가 allowlist할 수 있는 안정적이고 고정된 public IP를 제공하는 동시에, 관리형 load balancing 및 고가용성을 제공합니다. NLB는 Layer 4(TCP/UDP/TLS)에서 작동하며, 이는 많은 웹 서비스에 충분하고 특히 "load balancer를 위한 static IP" 요구 사항에 일반적으로 사용됩니다. Key AWS Features: - NLB + Elastic IPs: EIP를 할당하고 이를 NLB의 subnet mapping에 지정하여 AZ당 하나의 static IP를 얻을 수 있습니다. - High availability: 여러 AZ에 걸쳐 NLB를 배포합니다. 클라이언트는 모든 EIP를 allowlist에 추가합니다. - Preserves client IP: NLB는 source IP를 target으로 전달할 수 있습니다(로깅 및 보안 제어에 유용함). - Works with TLS: NLB는 필요한 경우 TLS listener를 지원하거나 target에서 TLS를 종료할 수 있습니다. Common Misconceptions: 많은 사람들이 Application Load Balancer가 EIP를 사용할 수 있다고 가정하지만, 그렇지 않습니다. ALB는 DNS 이름을 통해 접근되며 기본 IP는 변경될 수 있습니다. 또 다른 오해는 "단순히 Route 53을 사용하여 EIP를 가리키는 것"이지만, EIP는 단일 엔드포인트이며 그 자체로는 load balancing이나 다중 AZ 복원력을 제공하지 않습니다. Exam Tips: "클라이언트가 고정 IP/allowlisting을 요구함" + "load balancer"를 볼 때, EIP가 있는 NLB를 생각하십시오(다른 시나리오에서는 AWS Global Accelerator일 수 있지만 여기서는 옵션이 아님). 또한 기억하십시오: ALB/NLB는 일반적으로 DNS로 주소가 지정되지만, NLB만이 EIP를 통한 static IP를 지원합니다. 활성화된 AZ당 하나의 EIP를 고려하고 클라이언트에게 모든 EIP를 allowlist하도록 안내해야 합니다.
글로벌 컨설팅 회사가 다양한 지역 사무소에 걸쳐 25개의 AWS 계정을 관리하기 위해 AWS Organizations를 사용하고 있습니다. 본사 IT 팀은 민감한 고객 계약 및 규정 준수 문서가 포함된 중앙 Amazon S3 버킷을 마스터 계정에서 유지 관리합니다. 최근 보안 감사로 인해, 이 회사는 AWS Organization 내의 계정에 속한 사용자만 이 중요한 S3 버킷에 액세스할 수 있도록 보장해야 합니다. 지속적인 관리 작업과 유지 관리 노력을 최소화하면서 AWS Organization 내의 계정 사용자에게만 S3 버킷 액세스를 제한하도록 액세스 제어를 구현해야 합니다. 최소한의 운영 오버헤드로 액세스 제어 요구 사항을 충족하는 솔루션은 무엇입니까?
정답입니다. S3 버킷 정책의 aws:PrincipalOrgID는 지정된 AWS Organization ID에 속하는 보안 주체로 액세스를 제한합니다. 계정이 Organization에 추가되거나 제거될 때 자동으로 조정되므로 지속적인 정책 편집이 필요하지 않습니다. 이는 중앙 S3 버킷과 같은 공유 리소스에 대한 Organization 범위의 액세스를 위한 표준적이고 유지 관리가 가장 적은 접근 방식입니다.
최소 오버헤드를 위한 최선의 선택이 아닙니다. aws:PrincipalOrgPaths는 OU 멤버십을 기반으로 액세스를 제한할 수 있지만, 계정이 OU 간에 이동하거나 OU 구조가 변경될 경우 추가적인 복잡성과 잠재적인 유지 관리가 발생합니다. 요구 사항은 단순히 'Organization 내'이므로 Organization ID를 사용하는 것이 OU 경로 기반 제어보다 더 간단하고 안정적입니다.
운영 오버헤드가 높습니다. 조직 멤버십 변경을 감지한 다음 버킷 정책을 다시 작성하는 CloudTrail 기반 자동화는 복잡하고 불안정하며 불필요합니다. 이는 움직이는 요소(규칙, 함수, 권한, 오류 처리)를 추가하고 정책 편차 또는 지연된 적용의 위험을 초래합니다. 네이티브 IAM 조건 키는 사용자 지정 자동화 없이도 이미 실시간 평가를 제공합니다.
요구 사항과 일치하지 않으며 관리 작업이 증가합니다. 각 사용자(또는 역할)에 태그를 지정하고 aws:PrincipalTag를 강제하려면 25개 계정 전체에서 일관된 태그 거버넌스와 자격 증명 변경에 따른 지속적인 수명 주기 관리가 필요합니다. 또한 보안 주체가 Organization에 속해 있다는 것을 본질적으로 보장하지 않고 태그가 있다는 것만 보장하므로, Organization 멤버십에 대해 가장 신뢰할 수 있거나 유지 관리가 최소화된 제어 방법이 아닙니다.
문제 분석
핵심 개념: 이 질문은 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 조건이 제공하는 것 이상의 사용자 지정 로직을 명시적으로 필요로 하지 않는 한, 이벤트 기반 자동화보다 네이티브 정책 조건을 선호하십시오.
글로벌 스트리밍 미디어 회사가 여러 리전에서 250개 이상의 비디오 스트리밍 플랫폼을 운영하고 있습니다. 이 회사는 콘텐츠 추천 및 사용자 경험을 최적화하기 위해 매일 약 25TB의 사용자 시청 행동 및 상호 작용 데이터를 처리해야 합니다. 솔루션은 대용량 실시간 데이터 수집(ingestion)을 처리하고, 안정적인 데이터 전송을 제공하며, 대규모 스트리밍 데이터에 대한 효율적인 분석 처리를 가능하게 해야 합니다. 솔루션 아키텍트는 스트리밍 행동 데이터를 수집하고 처리하기 위해 무엇을 권장해야 합니까?
AWS Data Pipeline은 주로 예약된/배치 데이터 이동 및 오케스트레이션을 위한 것이며 대용량 실시간 스트리밍 수집을 위한 것이 아닙니다. S3 + EMR이 대규모 데이터 세트를 분석할 수 있지만, 여기서 수집 계층이 약점입니다. Data Pipeline은 Kinesis와 동일한 실시간 버퍼링, 확장 및 재생 의미 체계를 제공하지 않습니다. 이 옵션은 또한 거의 실시간 요구 사항에 대한 운영 복잡성을 증가시킵니다.
스트리밍 이벤트를 캡처하고 전달하기 위한 EC2 인스턴스의 Auto Scaling 그룹은 안정적으로 확장하고 운영하기(용량 계획, 백프레셔 처리, 재시도, 순서 지정 및 장애 복구) 더 어려운 DIY 수집 접근 방식입니다. 작동할 수는 있지만 하루 25TB의 실시간 원격 측정에 가장 적합한 관리형 패턴은 아닙니다. Kinesis는 더 적은 운영 오버헤드로 이러한 기능을 기본적으로 제공합니다.
Amazon CloudFront는 짧은 지연 시간으로 콘텐츠를 캐시하고 전송하도록 설계되었습니다. 기본 데이터 수집 메커니즘으로 사용자 상호 작용 원격 측정을 저장하거나 수집하기 위한 것이 아닙니다. S3 객체 생성에서 Lambda를 트리거하는 것은 연속 스트리밍이 아닌 배치/객체 기반 수집을 의미하며, 매우 높은 볼륨에서는 확장 및 지연 시간 문제를 일으킬 수 있습니다. 이는 실시간 행동 분석을 위한 아키텍처 불일치입니다.
Kinesis Data Streams는 많은 소스에서 발생하는 대용량 이벤트 데이터에 대해 확장 가능하고 내구성 있는 실시간 수집을 제공합니다. 그런 다음 Kinesis Data Firehose는 자동 확장, 버퍼링, 재시도 및 선택적 변환을 통해 스트림을 S3 데이터 레이크로 안정적으로 전송합니다. S3에서 Amazon Redshift로 로드하면 효율적인 대규모 분석을 지원합니다. 이는 실시간 수집, 안정적인 전송 및 확장 가능한 분석에 대한 요구 사항과 직접적으로 일치합니다.
문제 분석
핵심 개념: 이 질문은 처리량이 높고 안정적인 스트리밍 수집 및 분석 파이프라인 설계에 대해 테스트합니다. 주요 AWS 서비스는 Amazon Kinesis Data Streams(실시간 수집 및 버퍼링), Amazon Kinesis Data Firehose(스토리지/분석 대상으로의 관리형 전송), Amazon S3(내구성 있는 데이터 레이크), Amazon Redshift(분석/데이터 웨어하우스)입니다. 정답인 이유: 250개 이상의 플랫폼에서 매일 약 25TB의 데이터를 처리해야 하므로, 회사는 내구성 있는 버퍼링과 안정적인 전송을 갖춘 확장 가능한 거의 실시간 수집이 필요합니다. Kinesis Data Streams는 샤드당 정렬된 레코드, 재생을 위한 보존, 샤드(또는 온디맨드 모드)를 통한 수평 확장을 제공하여 대용량 이벤트 수집을 위해 특별히 구축되었습니다. 그런 다음 Kinesis Data Firehose는 배치 처리, 재시도 및 선택적 변환을 통해 데이터를 S3 데이터 레이크에 저장하는 완전 관리형의 안정적인 전송 계층을 제공하여 운영 오버헤드를 최소화합니다. S3에서 대규모 행동 분석 및 추천 기능 생성을 위해 데이터를 Redshift로 로드(예: S3에서 COPY)할 수 있습니다. 주요 AWS 기능: - Kinesis Data Streams: 샤드 기반 확장(또는 온디맨드), 다중 소비자, 향상된 팬아웃(enhanced fan-out), 재처리를 위한 보존, IAM/KMS와의 통합. - Kinesis Data Firehose: 자동 배치/압축/암호화, 재시도 로직, S3 전송, 선택적 Lambda 기반 변환. - S3 데이터 레이크: 높은 내구성, 수명 주기 정책, 효율적인 다운스트림 쿼리를 위한 파티셔닝된 스토리지. - Redshift: 빠른 집계를 위한 열 기반 스토리지 및 MPP; 처리량이 높은 로드를 위한 S3에서 COPY. 일반적인 오해: Data Pipeline 및 DIY EC2 수집은 실행 가능해 보일 수 있지만, 이 규모의 실시간 스트리밍에 최적화되어 있지 않으며 상당한 운영 부담을 추가합니다. CloudFront는 콘텐츠 전송/캐시 서비스이지 이벤트 수집 시스템이 아닙니다. 행동 원격 측정에 이를 사용하는 것은 아키텍처상 맞지 않습니다. 시험 팁: "대용량 실시간 수집(high-volume real-time ingestion)"과 "안정적인 전송(reliable transmission)" 및 "분석(analytics)"이 보이면 Kinesis(수집/버퍼링을 위한 Streams, 관리형 전송을 위한 Firehose) + 랜딩 존으로서의 S3를 생각하십시오. 분석 요구 사항에 따라 Redshift/EMR/Athena와 페어링하십시오. Redshift는 대규모 구조화된 행동 분석을 위한 일반적인 선택입니다.
다국적 의료 기관이 15개의 의학 연구 애플리케이션을 여러 AWS 계정에 걸쳐 AWS로 이전하여 IT 인프라를 통합하고 있습니다. 이 기관은 임상 시험, 환자 데이터 분석 및 규정 준수 시스템을 위한 별도의 환경이 포함된 이러한 계정을 중앙에서 관리하기 위해 AWS Organizations를 사용합니다. IT 보안 팀은 2,000개 이상의 의료진 계정이 포함된 기존 온프레미스 Microsoft Active Directory 인프라를 통해 중앙 집중식 사용자 관리를 유지하면서 15개 AWS 계정 모두에서 작동하는 통합 SSO(Single Sign-On) 인증 시스템을 요구합니다. 이러한 요구 사항을 가장 효과적으로 충족하는 솔루션은 무엇입니까?
오답입니다. IAM Identity Center는 multi-account SSO에 적합한 서비스이지만, 여기서 설명된 trust model은 이 사용 사례에서 AWS Managed Microsoft AD를 on-premises self-managed AD와 통합하기 위한 표준 지원 접근 방식이 아닙니다. IAM Identity Center와 Microsoft AD를 위한 예상 아키텍처가 two-way forest trust에 의존하는 경우, one-way forest 또는 domain trust는 최선의 답이 아닙니다. 이 option은 잘못된 trust relationship를 지정하므로, 이 시나리오에서는 덜 효과적이며 기술적으로도 부정확합니다.
정답입니다. AWS IAM Identity Center는 AWS Organizations 내 여러 AWS accounts 전반에서 centralized workforce access를 위한 AWS-native 서비스이며, 이는 15개 accounts 전반에서 통합된 SSO에 대한 요구 사항과 직접적으로 일치합니다. 기존 on-premises self-managed Microsoft Active Directory의 identities를 사용하기 위해 IAM Identity Center는 AWS Directory Service for Microsoft Active Directory를 identity source로 사용할 수 있으며, on-premises AD와의 two-way forest trust를 사용할 수 있습니다. 이렇게 하면 기존 AD에서 centralized user management를 유지하면서 IAM Identity Center permission sets와 assignments를 통해 AWS account access를 중앙에서 관리할 수 있습니다.
오답입니다. AWS Directory Service 자체만으로는 15개 AWS accounts 전반에서 요구되는 centralized AWS account SSO 경험을 제공하지 않습니다. 이는 directory-aware workloads, domain joining, trust relationships를 지원할 수는 있지만, AWS Organizations를 통해 여러 AWS accounts에 users와 groups를 할당하는 IAM Identity Center를 대체하지는 않습니다. 문제는 accounts 전반에서 통합된 SSO authentication system을 명시적으로 요구하고 있으므로, 이는 Directory Service 단독이 아니라 IAM Identity Center를 가리킵니다.
오답입니다. AD FS와 같은 on-premises identity provider는 사용자를 AWS로 federation할 수 있지만, 이는 운영 오버헤드를 추가하며 많은 AWS accounts 전반에서 centralized access를 위한 가장 효과적인 솔루션은 아닙니다. IAM Identity Center는 이미 AWS Organizations와의 기본 통합, centralized permission sets, 간소화된 account assignments를 제공하며, 이는 여기서의 핵심 요구 사항입니다. 또한 이 option은 기존 Microsoft AD를 가장 단순한 AWS-native 방식으로 직접적인 centralized identity source로 유지하는 방법을 명확히 보여주지 않습니다.
문제 분석
핵심 개념: 이 문제는 기존 on-premises Microsoft Active Directory (AD)와 통합된 AWS IAM Identity Center(이전 명칭: AWS Single Sign-On)를 사용하여 AWS Organizations 내 여러 AWS accounts 전반에서 federated identity와 centralized access management를 테스트합니다. 정답인 이유: 가장 효과적인 접근 방식은 IAM Identity Center를 활성화하고 이를 조직의 기존 self-managed Microsoft AD에 연결하면서 user lifecycle과 group management를 AD에서 중앙 집중식으로 유지하는 것입니다. Option A는 IAM Identity Center가 사용하는 directory로 AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD)를 사용한 다음, AWS Managed Microsoft AD에서 on-prem AD로의 one-way trust를 설정함으로써 이를 수행합니다. 이를 통해 IAM Identity Center는 on-prem AD에 대해 사용자 인증을 수행하고(trust를 통해) 중앙에서 관리되는 일관된 permission sets와 assignments로 모든 15개 AWS accounts에 대한 SSO access를 제공할 수 있습니다. 주요 AWS 기능: IAM Identity Center는 AWS Organizations와 기본적으로 통합되어 여러 accounts 전반에서 SSO를 제공하며, 여기에는 account discovery와 centralized permission set management가 포함됩니다. AWS Managed Microsoft AD를 사용하면 AD trust relationships를 지원하는 managed되고 highly available한 AWS 내 AD를 제공할 수 있습니다. one-way trust(일반적으로 AWS Managed Microsoft AD가 on-prem AD를 신뢰)는 AWS 리소스가 on-prem identities를 인증할 수 있도록 하면서 on-prem domain이 AWS를 역으로 신뢰할 필요는 없게 하므로 위험과 복잡성을 줄이는 데 일반적으로 사용됩니다. 이는 least privilege와 통제된 trust boundaries에 부합합니다. 일반적인 오해: Two-way trust(Option B)는 더 “완전한” 것처럼 보일 수 있지만, trust boundary를 확장하며 AWS accounts로의 SSO에는 거의 필요하지 않습니다. 또한 추가적인 보안 고려 사항을 초래할 수 있습니다. Directory Service만 사용하는 것(Option C)은 여러 accounts 전반에서 통합된 AWS console/application SSO를 제공하지 않습니다. 이는 주로 directory-dependent workloads(예: Windows auth, LDAP/Kerberos 요구 사항)를 위한 것입니다. on-prem IdP를 배포하는 것(Option D)도 가능하지만, 운영 오버헤드를 추가하며 AWS Organizations와 AD 기반 user management를 사용해 모든 accounts 전반에서 centralized SSO를 요구하는 사항에 직접적으로 가장 잘 부합하지는 않습니다. 시험 팁: AWS Organizations를 사용하는 multi-account SSO의 경우, 먼저 IAM Identity Center를 떠올리세요. 엔터프라이즈 identity source가 Microsoft AD라면, 일반적인 시험 패턴은 IAM Identity Center + AWS Managed Microsoft AD + on-prem으로의 AD trust입니다. forests/domains 전반에서 양방향 리소스 access를 요구하는 특정 요구 사항이 없는 한 one-way trust를 선호하세요.
한 금융 기술 스타트업이 모바일 뱅킹 애플리케이션을 구축 중이며 AWS에 프로토타입 인프라를 수동으로 생성했습니다. 인프라는 EC2 인스턴스가 있는 Auto Scaling 그룹, 고성능 트래픽 처리를 위한 Network Load Balancer, 트랜잭션 처리를 위한 Amazon Aurora MySQL 클러스터로 구성됩니다. 보안 규정 준수 검증을 완료한 후, 회사는 4주 후로 예정된 출시를 지원하기 위해 완전히 자동화된 방식으로 스테이징 및 프로덕션 환경 모두에 대해 3개의 가용 영역(Availability Zone)에 걸쳐 동일한 인프라를 신속하게 배포해야 합니다. 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?
AWS Systems Manager Automation은 런북을 사용하여 운영 워크플로(패치 적용, AMI 베이킹 단계, 인스턴스 복구 작업)를 실행하는 데 가장 적합합니다. API 호출을 오케스트레이션할 수는 있지만 전체 다중 리소스 아키텍처를 재사용 가능한 선언적 블루프린트로 모델링하고 버전화하도록 설계되지 않았습니다. 또한 CloudFormation이 제공하는 것과 동일한 반복 가능하고 환경 파라미터화된 스택 수명 주기 관리를 본질적으로 제공하지 않습니다.
CloudFormation은 3개의 AZ와 스테이징/프로덕션에 걸쳐 동일한 인프라를 완전히 자동화되고 반복 가능하게 배포하기 위한 올바른 접근 방식입니다. AZ별 VPC/서브넷, NLB 서브넷 매핑, 해당 서브넷을 포괄하는 Auto Scaling 그룹, Aurora DB 서브넷 그룹 및 클러스터 리소스를 정의할 수 있습니다. 파라미터화 및 별도의 스택은 제어된 차이가 있는 일관된 환경을 가능하게 하여 신속한 롤아웃 및 규정 준수 재현성을 지원합니다.
AWS Config는 주로 구성 기록을 기록하고, 규칙에 따라 리소스를 평가하고, 규정 준수를 보고합니다. Config 자동 수정이 특정 규정 위반 설정을 수정하기 위해 자동화를 트리거할 수 있지만, 여러 AZ에 걸쳐 처음부터 전체 애플리케이션 스택을 프로비저닝하기 위한 것은 아닙니다. Config를 배포 메커니즘으로 사용하는 것은 오용이며 복잡하고 불안정하며 표준 IaC 모범 사례와 일치하지 않습니다.
Elastic Beanstalk는 지원되는 웹/앱 플랫폼에 대한 기본 리소스를 프로비저닝하는 관리형 애플리케이션 배포 서비스입니다. Network Load Balancer 구성, Auto Scaling 세부 정보 및 뱅킹 트랜잭션을 위해 설계된 Aurora 클러스터에 대한 명시적 제어가 필요한 맞춤형 아키텍처에는 적합하지 않습니다. Beanstalk는 여러 AZ에 걸쳐 배포할 수 있지만 인프라를 추상화하며 검증된 프로토타입을 정확하게 복제하는 데 가장 적합하지 않습니다.
문제 분석
핵심 개념: 이 질문은 여러 가용 영역(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 및 파라미터화된 스택을 강화하십시오.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
한 회사가 매일 EBS 스냅샷을 생성하며 EC2에서 SQL Server를 실행합니다. 정리 스크립트가 실수로 모든 스냅샷을 삭제했습니다. 이 회사는 스냅샷을 영구적으로 보관하지 않으면서 데이터 손실을 방지해야 합니다. 최소한의 개발로 우발적인 삭제에 대한 안전망을 제공해야 합니다. 최소한의 개발 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
IAM에서 ec2:DeleteSnapshot을 거부하면 특정 보안 주체에 대한 우발적인 삭제를 줄일 수 있지만 신뢰할 수 있는 안전망은 아닙니다. 스크립트가 다른 역할로 실행될 수 있고, 관리자가 여전히 삭제할 수 있으며, 삭제가 발생할 경우 복구를 제공하지 않습니다. 또한 예외 및 더 많은 정책 관리가 필요하기 때문에 삭제를 허용해야 하는(스냅샷을 영구적으로 보관하지 않음) 요구 사항과 충돌합니다.
스냅샷을 다른 리전으로 복사하는 것은 주로 리전 중단에 대한 재해 복구 전략이지 우발적인 삭제에 대한 안전망이 아닙니다. 동일한 자동화 또는 운영자가 두 리전 모두에서 스냅샷을 삭제하는 경우(또는 권한이 허용하는 경우) 여전히 스냅샷을 잃을 수 있습니다. 또한 단순한 휴지통 규칙에 비해 지속적인 비용과 운영 복잡성(복사 일정, 모니터링, 보존 관리)이 추가됩니다.
EBS 스냅샷 휴지통 보존 규칙은 우발적인 스냅샷 삭제로부터 보호하도록 특별히 설계되었습니다. 모든 스냅샷에 대해 7일 보존 규칙을 사용하면 삭제된 스냅샷은 해당 기간 동안 복구 가능한 상태로 유지된 다음 영구적으로 제거되어 "영구 보관 안 함" 요구 사항을 충족합니다. 이는 최소한의 개발입니다. 규칙을 한 번 구성하고 필요할 때 복원을 사용합니다.
EBS 스냅샷은 S3 버킷으로 직접 복사한 다음 S3 Standard-IA를 선택할 수 있는 객체가 아닙니다. 스냅샷은 EBS 스냅샷 서비스에 의해 저장되고 관리됩니다. 일부 AWS 서비스는 특정 데이터를 S3로 내보낼 수 있지만, "스냅샷을 S3 Standard-IA로 복사"는 이 컨텍스트에서 EBS 스냅샷 보존 및 복구를 위한 유효한 기본 메커니즘이 아닙니다.
문제 분석
핵심 개념 - 이 질문은 우발적인 삭제에 대한 복원력을 제공하는 AWS Backup/Amazon EBS 데이터 보호 제어, 특히 EBS 스냅샷 휴지통(Recycle Bin) 기능(EBS 스냅샷 관리의 일부) 및 보존 기반 복구를 테스트합니다. 이는 복구 가능성, 제어된 보존 및 운영 위험 최소화와 같은 복원력 있는 아키텍처 원칙과 일치합니다. 정답인 이유 - 7일 EBS 스냅샷 휴지통 보존 규칙은 "안전망"을 생성하여 스냅샷이 (스크립트나 사용자에 의해) 실수로 삭제되더라도 휴지통에 보존되고 보존 기간 동안 복원될 수 있도록 합니다. 이는 스냅샷을 영구적으로 보관하지 않아야 한다는 요구 사항을 충족하면서 인시던트(모든 스냅샷의 우발적 삭제)를 직접적으로 해결합니다. 또한 최소한의 개발이 필요합니다. 백업 워크플로를 재설계하는 대신 보존 규칙을 한 번만 구성하면 됩니다. 주요 AWS 기능 - EBS 스냅샷 휴지통을 사용하면 보존 규칙(태그별 또는 계정/리전의 모든 스냅샷에 대해)을 설정하여 삭제된 스냅샷을 보존 기간이 만료될 때까지 복구할 수 있습니다. 이는 우발적인 삭제를 위해 특별히 구축되었으며 일반적인 스냅샷 수명 주기 정책을 보완(대체하지 않음)합니다. 이는 계정/리전 수준의 제어이며 교차 리전 복사 파이프라인을 구축하는 것에 비해 운영상 간단합니다. 일반적인 오해 - IAM에서 스냅샷 삭제를 거부하는 것(옵션 A)은 삭제를 방지하는 것처럼 보이지만 불안정합니다. 정리 스크립트가 다른 역할로 실행될 수 있고, 관리자가 여전히 삭제할 수 있으며, 삭제가 이미 발생했거나 합법적인 삭제가 필요한 경우에는 도움이 되지 않습니다. 교차 리전 복사(옵션 B)는 재해 복구를 개선하지만 별도의 제어로 복사본을 보호하지 않는 한 본질적으로 우발적인 삭제로부터 보호하지 못합니다. 또한 비용과 운영 오버헤드가 추가됩니다. "스냅샷을 S3 Standard-IA로 복사"(옵션 D)는 EBS 스냅샷이 작동하는 방식이 아닙니다. 스냅샷은 EBS에서 관리하며 S3 스토리지 클래스로 직접 계층화할 수 없습니다. 시험 팁 - "우발적 삭제(accidental deletion)" + "영구 보관 안 함(don't keep forever)" + "최소한의 개발(least development)"이 보이면 관리형 보존/복구 기능인 EBS 스냅샷 휴지통, AWS Backup Vault Lock(백업용) 및 수명 주기 정책을 찾으십시오. 시간 제한 보존 및 최소한의 사용자 지정 자동화를 통해 삭제 후 복구 가능성을 직접 제공하는 옵션을 선택하십시오.
회사는 중요한 Amazon Machine Image(AMI)를 많이 저장합니다. 우발적으로 삭제된 AMI를 최소한의 노력으로 신속하게 복구할 수 있는 솔루션이 필요합니다. 우발적인 삭제로부터 AMI/스냅샷을 보호하고 쉽게 복구할 수 있도록 해야 합니다. 요구 사항을 충족하는 솔루션은 무엇입니까?
AMIs의 EBS snapshots를 생성하여 다른 account에 저장하면 기본 block data는 보호할 수 있지만, AMI registration 자체는 보존되지 않습니다. 복구하려면 회사는 올바른 snapshots를 식별하고 수동으로 새 AMI를 다시 등록해야 하므로 운영 단계와 복잡성이 추가됩니다. 이는 AMI를 직접 복사하는 것보다 덜 편리합니다. 따라서 최소한의 노력으로 쉬운 recovery라는 요구 사항을 가장 잘 충족하지는 못합니다.
AMIs를 다른 AWS account로 주기적으로 복사하면 연결된 EBS snapshots를 포함한 전체 AMI 리소스를 격리된 위치에서 보호할 수 있습니다. source AMI가 실수로 삭제되더라도 backup account에는 여전히 시작 가능한 복사본이 남아 있어 원래 account로 다시 공유하거나 다시 복사할 수 있습니다. 자동화가 이루어지면 비교적 적은 지속적 노력으로 실용적인 recovery 경로를 제공합니다. 또한 실수로 인한 삭제나 관리 실수에 대비해 account 수준의 격리를 사용하는 방식으로 중요한 자산을 보호하는 AWS 모범 사례와도 일치합니다.
Recycle Bin retention rule은 적절히 구성된 경우 삭제된 EBS snapshots와 일부 EBS-backed AMIs를 보존하는 데 도움이 될 수 있지만, 중요한 AMIs를 폭넓게 복구 가능하도록 보호하는 가장 강력한 답은 아닙니다. 이는 사전에 retention rules가 설정되어 있어야 하며, 별도의 backup account가 제공하는 account 격리 이점도 없습니다. 많은 시험 시나리오에서 Recycle Bin은 중요한 machine images의 전체 backup 보호보다는 snapshot 또는 AMI undelete retention 사용 사례에 더 적합합니다. 문제는 쉬운 recovery와 함께 AMIs와 snapshots를 보호하는 것을 묻고 있으므로, cross-account AMI copy가 더 완전한 솔루션입니다.
AMIs는 Cross-Region Replication을 위해 S3 bucket에 objects로 업로드하여 저장되지 않습니다. AMI는 EC2 image metadata와 기본 snapshots(일반적으로 EBS snapshots)에 대한 참조로 구성됩니다. AWS는 accounts 또는 regions 간에 AMIs를 복제하기 위해 S3 CRR이 아니라 AMI copy 기능을 제공합니다. 이 선택지는 기술적으로 틀렸으며 AWS에서 AMIs가 관리되는 방식에 대한 오해를 반영합니다.
문제 분석
핵심 개념: 이 문제는 중요한 Amazon Machine Images (AMIs)를 실수로 삭제하는 것으로부터 보호하면서, 복구는 간단하게 유지하고 운영 노력은 낮게 유지하는 것에 관한 것입니다. 핵심 아이디어는 AMI의 복구 가능한 복사본을 별도의 AWS account에 유지하여 원본 AMI가 삭제되더라도 회사가 backup account에서 이를 복원하거나 다시 복사할 수 있도록 하는 것입니다. Cross-account AMI copy는 AMI와 연결된 snapshots를 함께 보존하므로 일반적인 AWS 보호 패턴입니다. 정답인 이유: AMIs를 다른 AWS account로 주기적으로 복사하면 전체 AMI 리소스에 대해 간단한 backup 및 recovery 메커니즘을 제공합니다. 단순히 기본 snapshots만이 아닙니다. 기본 account에서 AMI가 실수로 삭제되더라도 backup 복사본은 secondary account에 계속 남아 있으며, 다시 공유하거나 복사해 올 수 있습니다. 이 접근 방식은 한 account에서의 사용자 실수로 인한 영구 손실 위험을 줄여 주며, snapshots로부터 수동으로 AMIs를 다시 구축하는 것보다 운영하기가 더 쉽습니다. 주요 특징: - AMI copy에는 image로부터 instances를 시작하는 데 필요한 연결된 EBS snapshots가 포함됩니다. - 별도의 AWS account는 source account에서의 실수로 인한 삭제로부터 격리를 제공합니다. - 이 프로세스는 AWS Backup, EventBridge, Lambda 또는 custom scripts를 사용하여 일정에 따라 자동화할 수 있습니다. - 복구 시 재구성이 필요하지 않고 이미 사용 가능한 image로서 AMI가 존재하므로 더 간단합니다. 흔한 오해: - Recycle Bin은 삭제된 리소스의 보존에 유용하지만, 문제가 삭제된 AMIs 또는 snapshots에 대한 retention rules에 명시적으로 초점을 맞추지 않는 한 포괄적인 AMI 보호에 대한 예상 정답은 항상 아닙니다. 또한 사전 구성이 필요하며 별도 account만큼의 격리 이점을 제공하지 않을 수 있습니다. - snapshots만 복사하면 AMI registration metadata는 보존되지 않으므로, AMI를 다시 생성하려면 추가 단계가 필요합니다. - AMIs는 Cross-Region Replication을 위해 S3 buckets에 업로드되지 않습니다. 시험 팁: 문제가 중요한 AMIs를 실수로 삭제하는 것으로부터 보호하고 recovery를 가능하게 하는 것을 강조한다면, AMI를 복구 가능한 artifact로 보존하는 솔루션을 우선적으로 선택하세요. Cross-account AMI copies는 machine images에 대한 전형적인 AWS backup 패턴입니다. 반대로 문제가 policy 기반 undelete를 통해 삭제된 EBS snapshots 또는 삭제된 AMIs의 보존을 구체적으로 언급한다면, Recycle Bin이 더 관련성이 높아집니다.
미디어 제작 회사가 5MB에서 300GB에 이르는 대용량 오디오 파일을 온프레미스 NFS 스토리지 시스템에 저장하고 있습니다. 총 스토리지 용량은 85TB이며 정적이고 더 이상의 증가는 예상되지 않습니다. 이 회사는 마이그레이션 프로세스 동안 네트워크 대역폭 사용을 최소화하면서 가능한 한 빨리 모든 오디오 파일을 Amazon S3로 마이그레이션하고자 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
인터넷을 통해 AWS CLI로 85TB를 업로드하면 상당한 WAN 대역폭을 소비하며 일반적으로 느리고 운영상 위험합니다(재시도, 긴 전송 시간). multipart upload가 대용량 객체에 도움이 되지만 네트워크 대역폭 사용을 최소화해야 하는 요구 사항을 충족하지는 않습니다. 이 옵션은 대역폭이 충분하고 시간 제약이 크지 않을 때만 가장 좋습니다.
Snowball Edge는 S3로의 대규모 오프라인 마이그레이션을 위해 특별히 제작되었습니다. 데이터는 디바이스에 로컬로 복사된 후(빠른 LAN 속도) 가져오기를 위해 AWS로 배송되어 인터넷/WAN 사용을 최소화합니다. 85TB의 경우 Snowball은 대규모 데이터 세트, 일회성 마이그레이션, 전송을 빠르게 완료하면서 네트워크 포화를 방지하려는 요구 사항을 충족하는 표준 시험 정답 패턴입니다.
S3 File Gateway는 S3를 백엔드로 사용하는 NFS 마운트를 제공하지만 여전히 네트워크를 통해 AWS로 데이터를 전송합니다. 게이트웨이를 통해 85TB를 복사하면 상당한 대역폭을 소비하며 인터넷 링크에 따라 오랜 시간이 걸릴 수 있습니다. File Gateway는 대량 마이그레이션 중 대역폭을 최소화하는 것이 아니라 지속적인 하이브리드 워크플로 및 캐싱에 더 적합합니다.
Direct Connect는 퍼블릭 인터넷보다 더 높고 일관된 처리량을 제공할 수 있지만 여전히 네트워크 대역폭을 사용하며 일반적으로 프로비저닝 리드 타임과 지속적인 비용이 발생합니다. 네트워크 사용을 최소화해야 하는 일회성 정적 85TB 마이그레이션의 경우 Snowball이 더 적합하며 일반적으로 Direct Connect를 설정하는 것보다 시작하는 것이 더 빠릅니다.
문제 분석
핵심 개념: 이 질문은 (1) 빠르게 마이그레이션해야 하고 (2) 네트워크 대역폭 사용을 최소화해야 할 때 Amazon S3로의 가장 적절한 데이터 마이그레이션 방법을 선택하는 것을 테스트합니다. 핵심 AWS 개념은 온라인 전송 방법(AWS CLI, Storage Gateway, Direct Connect)과 대비되는 AWS Snow Family(Snowball Edge)를 사용한 "오프라인/물리적 데이터 전송"입니다. 정답인 이유: 85TB의 정적 데이터와 마이그레이션 중 네트워크 대역폭을 최소화해야 하는 요구 사항이 있으므로 AWS Snowball Edge가 가장 적합합니다. Snowball은 로컬 네트워크(고처리량 LAN 복사)를 통해 온프레미스에서 데이터를 로드한 다음, AWS가 데이터를 Amazon S3로 직접 가져오는 AWS로 다시 배송하는 물리적 어플라이언스를 제공합니다. 이 접근 방식은 회사의 인터넷/WAN 대역폭 소비를 크게 방지하며, 제한된 네트워크 링크를 통해 85TB를 푸시하는 것보다 일반적으로 엔드투엔드로 더 빠릅니다. 주요 AWS 기능: Snowball Edge는 S3로의 대규모 데이터 전송을 지원하며 오프라인 마이그레이션을 위해 설계되었습니다. Snowball 클라이언트(또는 디바이스/옵션에 따라 S3 호환 인터페이스)를 사용하여 디바이스로 데이터를 복사합니다. AWS는 안전한 전송과 변조 방지 하드웨어를 처리하며, 데이터는 엔드투엔드로 암호화됩니다. 85TB의 경우 사용 가능한 용량에 따라 하나 이상의 디바이스를 주문하고 로딩을 병렬화하여 마이그레이션을 가속화할 수 있습니다. 일반적인 오해: Storage Gateway(S3 File Gateway)는 S3를 NFS로 제공할 수 있지만 여전히 네트워크를 통해 AWS로 데이터를 업로드합니다. 이는 대역폭 사용이 아니라 애플리케이션 변경을 줄여줍니다. Direct Connect는 일관성을 향상시키고 처리량을 늘릴 수 있지만 여전히 네트워크 대역폭을 사용하며 리드 타임과 비용이 필요합니다. AWS CLI 직접 업로드는 가장 간단하지만 대역폭을 가장 많이 사용하며 수십 TB의 경우 종종 느립니다. 시험 팁: "수십 TB 이상"과 "네트워크 대역폭 최소화" 또는 "제한된 연결성"이 보이면 기본적으로 Snowball/Snowmobile을 선택하십시오. 최소한의 WAN 사용으로 일회성 대량 마이그레이션을 수행할 때가 아니라 지속적인 하이브리드 액세스/캐싱이 필요할 때 Storage Gateway를 사용하십시오. Direct Connect는 일회성 마이그레이션을 시작하는 가장 빠른 방법이 아니라 안정적이고 예측 가능한 네트워크 연결 요구 사항을 위한 것입니다.
한 금융 서비스 회사가 일일 트랜잭션 조정 보고서를 처리하는 레거시 배치 처리 시스템을 현대화하고 있습니다. 현재 시스템은 조정 작업을 여러 처리 워커에 분배하는 중앙 코디네이터 서버를 사용합니다. 워크로드는 크게 변동합니다. 월말 기간에는 처리량이 300% 증가할 수 있는 반면, 주말에는 활동이 최소화됩니다. 이 회사는 운영 오버헤드를 최소화하면서 가변적인 워크로드를 효율적으로 처리하기 위해 최대의 복원력과 자동 조정 기능을 갖춘 AWS로 이 시스템을 마이그레이션해야 합니다. 솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 아키텍처를 어떻게 설계해야 합니까?
SQS + Auto Scaling 워커는 견고한 분리 패턴이지만, scheduled scaling은 변동성이 큰 워크로드에 대한 "최대 복원력 및 자동 조정"이 아닙니다. 이는 예측 및 과거 패턴에 의존하므로 예상치 못한 급증이나 월말 타이밍/볼륨의 변화를 놓칠 수 있습니다. 또한 활동이 적은 기간 동안 초과 용량을 계속 실행하여 대기열 깊이 기반 조정에 비해 비용과 운영 튜닝 노력을 증가시킬 수 있습니다.
이것이 최선의 선택입니다. SQS는 생산자와 소비자를 분리하고 코디네이터 병목 현상을 제거합니다. SQS 대기열 깊이를 기반으로 워커 Auto Scaling 그룹을 조정하면 용량이 수요와 직접 일치하여 갑작스러운 월말 급증을 처리하고 주말에는 자동으로 축소됩니다. visibility timeout, DLQ 및 다중 AZ 상태 비저장 워커와 결합되어 낮은 운영 오버헤드로 높은 복원력을 제공합니다.
코디네이터 서버를 유지하면 단일 장애점과 조정 병목 현상이 유지되어 복원력이 저하됩니다. CloudTrail은 작업 분배 이벤트를 캡처하거나 라우팅하기 위한 것이 아니라 API 호출을 감사하기 위한 것입니다. 코디네이터 CPU를 기반으로 한 조정은 백로그나 처리량과 상관관계가 없을 수 있는 간접적인 지표이며, 급증 시 지연되거나 불안정한 조정 동작으로 이어질 수 있습니다.
EventBridge는 이벤트를 라우팅할 수 있지만, 배치 워크로드에 대해 SQS가 수행하는 방식의 내구성 있는 작업 버퍼링 및 백프레셔의 필요성을 대체하지는 않습니다. 코디네이터 서버를 유지하면 여전히 단일 장애점과 운영 오버헤드가 발생합니다. 워커의 CPU 기반 조정은 CPU가 대기 중인 작업(예: I/O 대기)을 반영하지 않을 수 있으므로 대기열 깊이 조정보다 덜 정확하여 과소/과대 조정을 유발할 수 있습니다.
문제 분석
핵심 개념: 이 질문은 대기열 기반 워커 패턴과 이벤트 기반 조정을 사용하여 AWS에서 분리되고 복원력 있는 배치 처리를 테스트합니다. 핵심 서비스는 내구성 있는 작업 버퍼링을 위한 Amazon SQS와 탄력적인 워커 플릿을 위한 EC2 Auto Scaling입니다. 정답인 이유: 옵션 B는 확장 및 가용성 병목 현상인 단일 "중앙 코디네이터"를 제거하고 고가용성, 내구성 있는 메시지 스토리지 및 자연스러운 백프레셔를 제공하는 SQS로 대체하기 때문에 최상의 설계입니다. 워커는 SQS를 폴링하고 작업을 독립적으로 처리합니다. SQS 대기열 깊이(예: ApproximateNumberOfMessagesVisible 및/또는 ApproximateNumberOfMessagesNotVisible)를 기반으로 워커 Auto Scaling 그룹을 조정하면 용량이 미해결 작업에 직접 맞춰집니다. 이는 예측할 수 없는 급증(예: 월말 +300%)에 대한 자동 조정을 제공하고 활동이 적은 기간(주말)에는 축소하여 운영 오버헤드를 최소화합니다. 주요 AWS 기능: - SQS standard queue: 다중 AZ, 확장성이 뛰어난 버퍼링; 최소 한 번 전송(at-least-once delivery) 지원. - Visibility timeout: 여러 워커가 동일한 작업을 동시에 처리하는 것을 방지; 최대 처리 시간에 맞춰 조정. - Dead-letter queue (DLQ): maxReceiveCount 이후 포이즌 메시지 격리. - SQS 지표에 대한 target tracking/step scaling이 있는 EC2 Auto Scaling(종종 CloudWatch alarms를 통해): 배치 작업의 처리량과 더 직접적으로 연결된 CPU가 아닌 백로그를 기반으로 조정. - 복원력 모범 사례: 여러 AZ에 걸친 상태 비저장(stateless) 워커; 간헐적인 중복 전송을 처리하기 위한 멱등성(idempotent) 처리. 일반적인 오해: Scheduled scaling(옵션 A)은 회사에 알려진 월말 피크가 있기 때문에 매력적으로 보일 수 있지만, 계획되지 않은 급증에는 실패하고 조용한 기간에는 과도하게 프로비저닝될 수 있습니다. CPU 기반 조정(옵션 C/D)은 간접적이며 지연될 수 있습니다. 백로그가 증가하는 동안(I/O 바운드 작업) CPU가 낮거나 시끄러운 이웃(noisy neighbors)으로 인해 CPU가 높아 불안정한 조정으로 이어질 수 있습니다. CloudTrail은 작업 분배 메커니즘이 아닙니다. 시험 팁: 가변적인 배치/워커 워크로드의 경우 "SQS + Auto Scaling 워커"를 선호하고 코디네이터 CPU가 아닌 대기열 깊이/백로그를 기반으로 조정하십시오. 단일 장애점을 제거하고 분리 및 복원력을 위해 관리형 서비스를 사용하는 설계를 찾으십시오(AWS Well-Architected Reliability 원칙).
사용자는 SAML과 호환되지 않는 온프레미스 LDAP 디렉터리를 사용하여 AWS Management Console에 인증해야 합니다. 기존 LDAP를 IdP로 사용하여 콘솔 액세스를 제공해야 합니다. 요구 사항을 충족하는 솔루션은 무엇입니까?
오답입니다. AWS IAM Identity Center(이전의 AWS SSO)는 일반적으로 SAML 2.0을 사용하여 외부 IdP와 통합되며, 기본 디렉터리 옵션은 콘솔 액세스를 위한 "직접 LDAP 연동"과 동일하지 않습니다. LDAP 자체는 AWS 콘솔 로그인을 위한 웹 연동 프로토콜이 아닙니다. SAML 지원 IdP 또는 변환 계층이 없으면 사용자는 LDAP 자격 증명으로 AWS 콘솔에 직접 인증할 수 없습니다.
오답입니다. IAM 정책을 생성하고 이를 "LDAP에 통합"하는 것은 인증(당신이 누구인지)과 권한 부여(당신이 무엇을 할 수 있는지)의 분리를 오해한 것입니다. LDAP는 자격 증명과 그룹을 저장할 수 있지만 기본적으로 AWS 자격 증명을 발급하거나 IAM 정책을 적용하지 않습니다. AWS 권한은 연동을 대체하기 위해 LDAP에 포함되는 것이 아니라 AWS의 IAM 역할/정책에 의해 적용되어야 합니다.
오답입니다. LDAP 자격 증명이 변경될 때마다 IAM 자격 증명을 교체하는 것은 장기 IAM 사용자를 관리하고 시스템 간에 암호/키를 동기화하는 것을 의미합니다. 이는 운영상 복잡하고 진정한 연동 SSO를 제공하지 않으며 임시 자격 증명(STS) 및 중앙 집중식 자격 증명 관리를 사용할 것을 권장하는 모범 사례를 위반합니다. 또한 수명이 긴 자격 증명은 제어 및 감사가 더 어렵기 때문에 위험이 증가합니다.
정답입니다. 온프레미스 자격 증명 브로커는 LDAP에 대해 사용자를 인증한 다음 매핑된 LDAP 그룹/속성을 기반으로 AWS STS(예: AssumeRole)에서 임시 자격 증명을 요청할 수 있습니다. 그런 다음 브로커는 해당 임시 자격 증명을 사용하여 연동 로그인 URL을 생성함으로써 AWS Management Console 액세스를 제공할 수 있습니다. 이 패턴은 LDAP가 SAML과 호환될 필요 없이 콘솔 액세스를 가능하게 하며 장기 IAM 사용자 자격 증명을 피합니다.
문제 분석
핵심 개념: 이 질문은 엔터프라이즈 자격 증명 소스가 SAML을 지원하지 않는 온프레미스 LDAP 디렉터일 때 AWS Management Console에 대한 연동 액세스를 테스트합니다. 핵심 AWS 개념은 연동, 임시 자격 증명, 그리고 장기 IAM 사용자를 관리하는 대신 AWS Security Token Service(AWS STS)를 사용하여 수명이 짧은 세션을 얻는 것입니다. 정답인 이유: LDAP 디렉터리가 SAML과 호환되지 않기 때문에 AWS 콘솔에 대한 표준 SAML 연동을 직접 사용할 수 없습니다. 확립된 패턴은 LDAP 앞에 자격 증명 변환 계층(자격 증명 브로커)을 배치하는 것입니다. 브로커는 LDAP에 대해 사용자를 인증한 다음 AWS STS(일반적으로 AssumeRole)를 호출하여 해당 사용자/그룹에 매핑된 IAM 역할에 대한 임시 자격 증명을 얻습니다. 그런 다음 브로커는 STS 세션 자격 증명을 AWS 콘솔 세션으로 교환하는 연동 로그인 URL(연동 엔드포인트 사용)을 생성하여 콘솔 액세스를 활성화합니다. 이는 사용자가 기존 LDAP로 인증하고 수명이 짧은 자격 증명을 통해 AWS 액세스 권한이 부여된다는 요구 사항을 충족합니다. 주요 AWS 기능: - 제한된 기간의 임시 자격 증명을 발급하는 AWS STS AssumeRole. - 브로커(또는 제한된 AWS 보안 주체)가 역할을 수임할 수 있도록 허용하는 신뢰 정책이 있는 IAM 역할. - 역할에 연결된 IAM 정책을 통한 세분화된 권한 부여, 종종 LDAP 그룹에서 매핑됨. - 장기 IAM 사용자 자격 증명을 피하고 LDAP에서 중앙 집중식 자격 증명 수명 주기를 활성화하여 운영 위험 감소. 일반적인 오해: 많은 사람들이 IAM Identity Center가 LDAP에 "직접" 연결될 수 있다고 가정합니다. 실제로 IAM Identity Center는 SAML 2.0(및 특정 디렉터리 통합)을 통해 외부 자격 증명 공급자를 지원하지만, LDAP 자체는 AWS 콘솔 로그인을 위한 연동 프로토콜이 아닙니다. 또 다른 오해는 LDAP 변경 사항을 기반으로 IAM 사용자 자격 증명을 동기화하거나 교체하려는 것입니다. 이는 불안정하고 안전하지 않으며 AWS 모범 사례에 위배됩니다. 시험 팁: "SAML과 호환되지 않는 LDAP"와 "AWS Management Console 액세스"가 보이면 "사용자 지정 자격 증명 브로커 + STS + 연동 콘솔 URL"을 생각하십시오. IAM 사용자보다 임시 자격 증명 및 역할 기반 액세스를 선호하십시오. 또한 AWS 자격 증명을 LDAP에 포함하거나 시스템 간에 암호/자격 증명 교체를 관리하려고 시도하는 대신 엔터프라이즈 그룹을 IAM 역할/정책에 매핑하십시오.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
한 의료 컨설팅 회사가 원격 환자 상담을 진행하고 규정 준수를 위해 모든 비디오 상담 녹화본을 Amazon S3 버킷에 저장합니다. 이 회사는 분석 및 보고를 위해 비디오 파일에서 음성 콘텐츠를 추출해야 합니다. 회사는 HIPAA 규정 준수를 유지하기 위해 추출된 텍스트에서 모든 환자 건강 정보(PHI) 및 개인 식별 정보(PII)를 자동으로 제거해야 합니다. 솔루션은 파일이 업로드될 때 자동으로 파일을 처리하고 삭제 처리된(sanitized) 트랜스크립트를 별도로 저장해야 합니다. 솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?
Kinesis Data Streams는 S3에 있는 비디오 파일의 배치 처리가 아니라 실시간 스트리밍 수집을 위해 설계되었습니다. 음성 콘텐츠를 추출하려면 여전히 음성 텍스트 변환 서비스(예: Transcribe)가 필요합니다. 사용자 지정 정규식에 의존하여 PHI/PII를 제거하는 것은 불안정하고 민감한 데이터를 놓칠 가능성이 높아 HIPAA 위험을 초래합니다. 이 옵션은 요구 사항을 안정적으로 충족하지 못하면서 복잡성만 더합니다.
Amazon Textract는 비디오 녹화본의 오디오 트랙이 아니라 문서 및 이미지(OCR 및 양식/테이블)에서 텍스트를 추출합니다. Lambda가 트리거한 Textract 작업은 음성을 전사하지 않습니다. 텍스트가 자막으로 포함되어 있더라도 Textract는 PHI/PII redaction을 자동으로 처리하지 않습니다. 이 옵션은 미디어 유형 및 규정 준수 요구 사항과 일치하지 않습니다.
이것이 가장 적합합니다. Amazon Transcribe는 S3에 저장된 오디오/비디오에서 음성을 텍스트로 변환하고 트랜스크립트에서 민감한 식별자를 자동으로 제거하는 PII redaction을 지원합니다. S3 업로드 이벤트를 사용하여 Lambda를 호출하면 자동화된 이벤트 기반 처리가 제공됩니다. 수정된 트랜스크립트를 별도의 S3 버킷에 저장하면 데이터 분리, 최소 권한 액세스 및 더 간단한 규정 준수 제어를 지원합니다.
Amazon Chime SDK 미팅 흐름은 저장된 S3 비디오 파일의 오프라인 전사가 아니라 라이브 미팅 오디오 처리를 위한 것입니다. PHI 감지를 위해 Comprehend Medical을 추가하면 복잡성이 증가하고 여전히 전사 단계가 먼저 필요합니다. EventBridge는 워크플로를 트리거할 수 있지만 여기서는 S3 이벤트 알림이 더 간단합니다. 전반적으로 이는 명시된 업로드 시 배치 요구 사항에 대해 과도하게 엔지니어링되고 덜 적절한 아키텍처입니다.
문제 분석
핵심 개념: 이 질문은 미디어 파일에서 음성을 텍스트로 변환하고 HIPAA에 부합하는 비식별화를 보장하기 위해 올바른 관리형 AWS AI 서비스를 선택하는 것을 테스트합니다. 핵심 서비스는 Amazon Transcribe(음성 인식) 및 내장된 PII redaction 기능이며, Amazon S3 + AWS Lambda를 사용한 이벤트 기반 자동화가 포함됩니다. 정답인 이유: 옵션 C는 (1) 업로드된 비디오 녹화본에서 음성 콘텐츠를 자동으로 전사하고, (2) 트랜스크립트에서 PII/PHI를 자동으로 제거하며, (3) 삭제 처리된 출력을 별도로 저장하는 모든 요구 사항을 직접 충족합니다. Amazon Transcribe는 S3에 저장된 비디오 파일의 오디오 트랙에서 전사를 지원하며 PII redaction 기능을 사용하여 수정된 트랜스크립트를 생성할 수 있습니다. S3 이벤트 알림을 사용하여 Lambda를 호출하는 것은 새 객체가 업로드될 때마다 Transcribe 작업을 시작하는 표준 서버리스 패턴입니다. 수정된 출력을 별도의 S3 버킷에 기록하면 규정 준수 제어(민감한 데이터와 삭제 처리된 데이터의 분리)를 지원하고 다운스트림 분석을 간소화합니다. 주요 AWS 기능: - 객체 생성 시 처리를 트리거하는 Amazon S3 이벤트 알림. - 오케스트레이션을 위한 AWS Lambda: Transcribe 작업 시작, 입력 S3 URI 전달, 출력 버킷/접두사 지정, ContentRedaction(PII redaction) 활성화. - Amazon Transcribe PII redaction: 트랜스크립트에서 감지된 PII(예: 이름, 주소, 전화번호)를 수정하고 수정된 텍스트를 출력하여 사용자 지정 로직의 필요성을 줄일 수 있습니다. - 보안 모범 사례: 별도의 버킷, Lambda/Transcribe에 대한 최소 권한 IAM, S3 SSE-KMS 암호화, 버킷 정책 및 액세스 로깅. 이는 AWS Well-Architected Security 원칙(데이터 보호, 최소 권한, 감사 가능성)과 일치합니다. 일반적인 오해: A는 유연해 보일 수 있지만 S3의 파일 기반 배치 전사에는 Kinesis가 불필요하며, 정규식 기반 PHI/PII 제거는 오류가 발생하기 쉽고 규정 준수에 위험합니다. B는 Textract가 비디오/오디오의 음성이 아니라 문서/이미지에서 텍스트를 추출하기 때문에 오답입니다. D는 솔루션을 지나치게 복잡하게 만듭니다. Chime SDK 미팅 흐름은 저장된 녹화본을 처리하는 것이 아니라 라이브 미팅을 위한 것입니다. Comprehend Medical은 의료 엔터티를 감지할 수 있지만 Transcribe의 기본 redaction에 비해 가장 간단하거나 직접적인 요구 사항은 아닙니다. 시험 팁: 오디오/비디오에서 "음성 콘텐츠 추출"이 보이면 Amazon Transcribe를 생각하십시오. "자동으로 PII 제거"가 보이면 Transcribe PII redaction(또는 텍스트 분류를 위한 Comprehend, 단 redaction이 기본적으로 지원되지 않는 경우에만)을 찾으십시오. "업로드 시 처리"의 경우 기본적으로 S3 이벤트 알림 + Lambda 오케스트레이션을 사용하고 삭제 처리된 출력을 엄격하게 제어되는 별도의 위치에 저장하십시오.
한 의료 기관이 Amazon RDS MySQL 데이터베이스와 함께 Amazon EC2 인스턴스에서 환자 관리 시스템을 실행하고 있습니다. 애플리케이션은 현재 각 EC2 인스턴스의 구성 파일에 저장된 하드코딩된 자격 증명을 사용하여 데이터베이스에 연결합니다. 이 기관은 여러 가용 영역에 걸쳐 15개의 EC2 인스턴스를 보유하고 있으며 HIPAA 보안 요구 사항을 준수해야 합니다. 보안 팀은 하드코딩된 데이터베이스 자격 증명을 제거하고 자격 증명 관리의 관리 부담을 줄이는 동시에 민감한 환자 데이터에 대한 안전한 액세스를 보장하고자 합니다. 솔루션 아키텍트는 이러한 보안 및 운영 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?
정답입니다. AWS Secrets Manager는 보안 암호를 저장하고 관리하도록 설계되었으며 관리형 교체 Lambda 템플릿을 사용하여 Amazon RDS MySQL에 대한 자동 교체를 지원합니다. EC2 인스턴스는 IAM 역할을 사용하여 런타임에 보안 암호를 검색하므로 하드코딩된 자격 증명을 제거하고 운영 오버헤드를 줄입니다. 보안 암호는 KMS로 암호화되고 액세스는 CloudTrail을 통해 감사 가능하므로 HIPAA 보안 기대치와 잘 맞습니다.
오답입니다. Systems Manager Parameter Store SecureString은 암호화된 스토리지 및 IAM 제어 액세스를 제공하지만 Secrets Manager에 비해 대규모 자동화된 데이터베이스 자격 증명 교체에는 가장 적합하지 않습니다. 사용자 지정 자동화로 교체를 엔지니어링할 수 있지만 운영 부담과 복잡성이 증가합니다. RDS 자격 증명 교체 및 규정 준수와 관련된 시험 시나리오의 경우 일반적으로 Secrets Manager가 의도된 서비스입니다.
오답입니다. 암호화된 자격 증명 파일을 S3에 저장하는 것은 여전히 자격 증명 아티팩트를 배포하고 관리하는 데 의존하며 RDS와 강력하고 통합된 교체 메커니즘을 제공하지 않습니다. 또한 잘못된 구성(버킷 정책, 객체 ACL)의 위험을 증가시키고 최소 권한 액세스 패턴을 복잡하게 만듭니다. S3 암호화는 보안 암호 수명 주기 관리 및 교체가 아니라 저장 데이터를 다룹니다.
오답입니다. EBS 볼륨을 암호화하면 각 인스턴스의 저장된 자격 증명을 보호하지만 자격 증명은 로컬에 저장된 상태로 유지되며 15개 인스턴스 전체에서 교체해야 하므로 관리 부담과 불일치 위험이 증가합니다. 사용자 지정 Lambda 교체 스크립트는 복잡성을 더하며 RDS와의 원자적 교체 및 모든 인스턴스로의 즉각적인 전파를 본질적으로 보장하지 않습니다. 이는 권장되는 AWS 기본 접근 방식이 아닙니다.
문제 분석
핵심 개념: 이 질문은 특히 규제 대상 워크로드(HIPAA)에 대한 데이터베이스 자격 증명의 안전한 보안 암호 저장 및 수명 주기 관리를 테스트합니다. 핵심 AWS 서비스는 보안 암호를 저장하고 자동으로 교체하도록 특별히 제작된 AWS Secrets Manager입니다. 정답인 이유: AWS Secrets Manager는 보안 암호를 중앙 집중화하고 애플리케이션(또는 부트스트랩 스크립트/사이드카)이 IAM 권한을 사용하여 런타임에 자격 증명을 검색할 수 있도록 함으로써 15개의 EC2 인스턴스에서 하드코딩된 자격 증명을 제거합니다. Amazon RDS MySQL 데이터베이스의 경우 Secrets Manager는 AWS 관리형 교체 Lambda 템플릿을 사용하여 기본 통합 및 자동 교체를 지원합니다. 이는 관리 부담(인스턴스 전반에 걸친 수동 암호 변경 없음)을 줄이고 주기적인 교체를 강제하며 자격 증명 스프롤을 최소화하여 보안 태세를 개선합니다. 이는 HIPAA의 액세스 제어 및 감사 기대치에 중요합니다. 주요 AWS 기능 / 모범 사례: - 자동 교체: RDS 암호와 저장된 보안 암호를 원자적으로 업데이트하는 교체 Lambda를 사용하여 교체(예: 30일마다)를 구성합니다. - 세분화된 액세스 제어: EC2 인스턴스에서 IAM 역할을 사용하여 특정 보안 암호에 대해서만 secretsmanager:GetSecretValue를 허용합니다. 파일을 통해 자격 증명을 배포하지 마십시오. - 암호화 및 감사: 보안 암호는 AWS KMS로 암호화되며 액세스는 AWS CloudTrail에 기록되어 규정 준수 증거를 지원합니다. - 다중 AZ EC2 플릿: 모든 인스턴스는 AZ 간에 파일을 복사하지 않고도 동일한 보안 암호를 안전하게 검색할 수 있습니다. 일반적인 오해: Parameter Store(SecureString)는 암호화된 값을 저장할 수 있지만 Secrets Manager만큼 RDS 자격 증명에 대한 최고 수준의 관리형 보안 암호 교체 워크플로를 제공하지는 않습니다. S3/EBS 암호화는 저장 데이터를 보호하지만 보안 암호 배포, 교체 조정 또는 최소 권한 런타임 검색을 해결하지는 않습니다. 시험 팁: "하드코딩된 자격 증명 제거"와 "관리 부담 감소" 및 "교체"가 보이면 기본적으로 Secrets Manager(특히 RDS의 경우)를 선택하십시오. 교체가 주요 요구 사항이 아닐 때 구성 값과 더 간단한 보안 암호에는 Parameter Store를 사용하십시오. 규정 준수 시나리오의 경우 IAM 최소 권한, KMS 암호화 및 CloudTrail 감사를 지원 제어로 고려하십시오.
전자 상거래 회사의 마케팅 팀이 다가오는 Black Friday 할인 캠페인을 위한 프로모션 랜딩 페이지를 생성해야 합니다. 랜딩 페이지에는 제품 이미지, 프로모션 비디오, CSS 스타일링, 제품 캐러셀을 위한 대화형 JavaScript 요소 및 HTML 콘텐츠가 포함됩니다. 마케팅 팀은 캠페인 기간 동안 약 50,000명의 방문자를 예상하고 있으며, 이 정적 프로모션 콘텐츠를 호스팅하기 위해 가장 예산 친화적인 솔루션이 필요합니다. 이 페이지는 최소한의 인프라 관리 오버헤드로 전 세계 고객이 액세스할 수 있어야 합니다. 이 프로모션 랜딩 페이지에 가장 비용 효율적인 호스팅 솔루션은 무엇입니까?
EC2 기반의 Amazon ECS는 정적 랜딩 페이지에 비용 효율적이지 않습니다. EC2 인스턴스(및 잠재적으로 ALB)에 대한 비용을 지불하고, 확장 정책을 관리하며, 기본 호스트를 패치하고(Fargate를 사용하지 않는 한), 컨테이너 인프라를 운영해야 합니다. 트래픽을 처리할 수는 있지만 정적 HTML/CSS/JS 및 미디어 자산에 대해 S3와 비교할 때 불필요한 복잡성과 지속적인 비용이 추가됩니다.
Amazon S3 static website hosting은 인프라 관리가 거의 없이 정적 파일(HTML, CSS, JavaScript, 이미지, 비디오)을 제공하도록 특별히 구축되었습니다. 트래픽 급증(Black Friday 트래픽 등)을 처리하기 위해 자동으로 확장되며, 항상 켜져 있는 컴퓨팅 리소스가 아닌 스토리지 및 요청에 대해 비용을 지불하므로 일반적으로 가장 저렴한 옵션입니다. 필요한 경우 글로벌 저지연 전송을 위해 CloudFront와도 잘 통합됩니다.
Apache가 있는 단일 EC2 t3.medium은 고정된 컴퓨팅 비용과 운영 오버헤드(OS 패치, 웹 서버 유지 관리, 모니터링)를 발생시킵니다. 또한 가용성 및 확장성 위험을 초래합니다. 트래픽이 급증하는 동안 단일 인스턴스가 병목 현상이나 단일 장애점(SPOF)이 될 수 있습니다. Auto Scaling 및 로드 밸런싱을 사용하더라도 정적 콘텐츠의 경우 S3보다 솔루션이 더 비싸고 복잡해집니다.
페이지를 동적으로 렌더링하기 위한 Lambda가 포함된 API Gateway는 정적 프로모션 콘텐츠에 불필요합니다. 이 설계는 복잡성(템플릿, 함수 코드, 배포)을 추가하며, 특히 대용량 미디어 자산을 제공하는 경우 요청당 요금 및 실행 시간으로 인해 비용이 증가할 수 있습니다. 이미지/비디오/CSS/JS가 있는 정적 랜딩 페이지가 아니라 동적, 개인화 또는 API 기반 경험에 더 적합합니다.
문제 분석
핵심 개념: 이 질문은 최소한의 운영 오버헤드로 정적 웹 콘텐츠를 위한 비용 최적화된 호스팅을 테스트합니다. 주요 AWS 기능은 Amazon S3 static website hosting입니다(글로벌 성능을 위해 종종 Amazon CloudFront와 결합되지만, S3만으로도 요구 사항을 충족합니다). 정답인 이유: Amazon S3 static website hosting은 정적 자산(HTML, CSS, JavaScript, 이미지 및 비디오)을 제공하기 위한 가장 비용 효율적이고 관리가 적은 옵션입니다. 약 50,000명의 방문자가 있는 경우 S3는 서버, 로드 밸런서 또는 컨테이너 클러스터를 프로비저닝하지 않고도 자동으로 확장됩니다. 주로 스토리지 및 데이터 전송/요청에 대해서만 비용을 지불하므로 기한이 정해진 마케팅 캠페인에 예산 친화적입니다. 패치 적용, 용량 계획 또는 인스턴스 크기 조정이 없으므로 최소한의 인프라 관리가 필요한 마케팅 팀에 이상적입니다. 주요 AWS 기능: S3 static website hosting을 사용하면 인덱스 문서 및 오류 문서를 설정하고 HTTP를 통해 직접 콘텐츠를 제공할 수 있습니다. 프로덕션 수준의 글로벌 전송을 위한 일반적인 모범 사례는 S3 버킷 앞에 CloudFront를 배치하여 전 세계적으로 지연 시간을 줄이고, 트래픽을 오프로드하며, ACM 인증서 및 AWS WAF 보호를 통해 HTTPS를 추가하는 것입니다. CloudFront Origin Access Control (OAC)를 사용하여 액세스를 제어함으로써 버킷을 비공개로 유지하면서도 전 세계적으로 콘텐츠를 제공할 수 있습니다. 이러한 향상된 기능은 상당한 운영 부담 없이 성능과 보안을 개선합니다. 일반적인 오해: 팀은 "웹 서버"에 익숙하기 때문에 종종 EC2/ECS를 기본값으로 선택하지만, 정적 사이트의 경우 이는 불필요한 컴퓨팅 비용과 운영 작업(패치 적용, 확장, 모니터링)을 초래합니다. API Gateway + Lambda는 동적 렌더링에 강력하지만, 단순한 정적 페이지의 경우 과도하며 대규모에서는 더 많은 비용이 들 수 있습니다. 시험 팁: "정적 콘텐츠(static content)", "글로벌 사용자(global users)", "최소한의 관리(minimal management)", "가장 비용 효율적인(most cost-effective)"이라는 단어를 보면 S3 static website hosting(및 선택적으로 CloudFront)을 생각하십시오. 서버 측 처리, 사용자 지정 런타임 또는 복잡한 애플리케이션 로직이 필요한 경우에만 EC2/ECS를 예약하십시오. 마케팅 랜딩 페이지의 경우 비용 최적화 시나리오에서 S3가 표준 정답입니다. 참조: Amazon S3에서 정적 웹 사이트 호스팅 및 정적 콘텐츠 전송을 위한 CloudFront 모범 사례에 대한 AWS 설명서.
한 의료 기관이 3개의 다른 시설에 걸쳐 15대의 Linux 기반 연구 데이터 서버를 운영하고 있습니다. 각 서버에는 규정 준수 목적으로 보존해야 하는 엄격한 POSIX 파일 권한 및 심볼릭 링크(symbolic links)가 포함된 중요한 환자 연구 데이터가 있습니다. 이 기관은 고성능 컴퓨팅 워크로드를 위해 모든 연구 데이터를 Amazon FSx for Lustre 파일 시스템으로 통합해야 합니다. 마이그레이션 중에 POSIX 권한, 심볼릭 링크 및 메타데이터를 보존해야 합니다. 총 데이터 크기는 약 500TB입니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? (2개 선택)
오답입니다. AWS DataSync는 이 선택지에서 설명한 방식처럼 데이터를 Amazon FSx for Lustre로 직접 전송하는 것을 지원하지 않습니다. FSx for Lustre가 DataSync 대상 용도의 NFS endpoint를 노출한다는 설명은 부정확합니다. FSx for Lustre는 Lustre protocol을 사용하며 DataSync의 일반적인 NFS 대상처럼 동작하지 않습니다. 따라서 지원되는 시나리오에서 DataSync가 POSIX metadata를 보존하더라도, 전송 경로 자체가 유효하지 않으므로 이 선택지는 선택할 수 없습니다.
오답입니다. rsync를 사용해 파일을 Amazon S3로 복사하면 파일시스템 데이터가 object로 변환되며, POSIX permissions, ownership, symbolic links를 기본 파일시스템 구성 요소로서 보존하지 못합니다. 이런 방식으로 데이터가 S3에 staging되면, DataSync를 사용하기도 전에 필요한 metadata 정확성이 이미 손실되었을 수 있습니다. 따라서 POSIX attributes와 symlinks의 보존을 명시적으로 요구하는 compliance에 민감한 마이그레이션에는 이 선택지가 적합하지 않습니다.
정답입니다. 여러 시설에 분산된 500 TB 마이그레이션의 경우, 네트워크 전송이 느리거나 운영상 위험할 수 있다면 오프라인 대량 수집 방식이 적절할 수 있습니다. 데이터를 AWS로 배송하여 Amazon S3로 가져오는 것은 인정된 대규모 전송 패턴이며, 이후 AWS DataSync를 사용해 관리형 방식으로 데이터를 다음 단계로 이동시킬 수 있습니다. 나열된 선택지 중에서 이것은 매우 큰 데이터셋에 대한 AWS 관리형 대량 마이그레이션 서비스와 부합하는 두 가지 옵션 중 하나입니다. 비록 S3 staging이 기본 파일시스템 semantics를 보존하는 데 이상적이지는 않지만 말입니다.
정답입니다. AWS Snowball Edge Storage Optimized 디바이스는 온프레미스 환경에서의 대규모 데이터 마이그레이션을 위해 설계되었으며 수백 테라바이트의 데이터에 매우 적합합니다. Snowball Edge와 함께 DataSync를 사용하면 관리형 전송 워크플로를 제공하고, 파일 기반 마이그레이션 중 permissions, ownership, timestamps, symbolic links와 같은 파일 metadata를 보존합니다. 세 개의 시설 전체에 여러 디바이스를 주문하면 병렬 데이터 수집이 가능하고 WAN bandwidth 의존도를 줄일 수 있습니다.
오답입니다. AWS Snowmobile은 일반적으로 수 페타바이트 이상과 같은 극도로 큰 마이그레이션을 위한 서비스이므로 500 TB 워크로드에는 과도합니다. 또한 이 선택지는 Amazon S3를 중간 staging 계층으로 도입하는데, 이는 POSIX permissions와 symbolic links의 엄격한 보존이 필요한 경우 이상적이지 않습니다. 이 데이터 볼륨과 운영 시나리오에는 Snowball Edge가 더 적절한 오프라인 전송 서비스입니다.
문제 분석
핵심 개념: 이 문제는 POSIX permissions, symbolic links, metadata를 보존하면서 매우 큰 온프레미스 Linux 데이터셋을 Amazon FSx for Lustre로 마이그레이션하는 것에 관한 것입니다. 핵심 과제는 여러 시설에 걸쳐 있는 500 TB 규모의 파일시스템 인지 전송을 처리할 수 있는 AWS 마이그레이션 서비스를 선택하는 것입니다. DataSync는 파일 전송 중 POSIX metadata를 보존하도록 설계된 AWS 서비스이며, 네트워크 기반 전송이 비현실적인 경우 Snowball Edge를 사용할 수 있습니다. 흔한 시험 함정은 모든 AWS 파일 서비스가 DataSync의 직접 대상이라고 가정하거나, S3 staging이 항상 별다른 조건 없이 파일시스템 semantics를 보존한다고 생각하는 것입니다. 정답인 이유: Option D가 정답인 이유는 Snowball Edge Storage Optimized 디바이스를 각 사이트에 배치하고 DataSync와 함께 사용하여 대규모 파일 마이그레이션을 수행하면서 파일 attributes를 보존할 수 있기 때문입니다. Option C도 제공된 선택지의 맥락에서는 허용 가능한 또 다른 정답입니다. 네트워크 전송에 제약이 있을 수 있는 500 TB 규모에서는 데이터를 AWS로 물리적으로 배송하여 대량 수집하는 방식이 유효한 패턴이며, 이후 DataSync가 데이터를 다음 단계로 이동시킬 수 있기 때문입니다. S3는 기본 POSIX semantics를 보존하는 데 이상적이지 않지만, 시험 스타일의 의도는 이 규모에 적합한 AWS 관리형 대량 전송 메커니즘을 식별하는 것입니다. 주요 기능: AWS DataSync는 지원되는 파일 기반 스토리지 시스템 간 전송 시 ownership, permissions, timestamps, symbolic links를 보존합니다. Snowball Edge Storage Optimized는 디바이스당 수십에서 수백 테라바이트에 적합하며 여러 시설에서 병렬로 사용할 수 있습니다. WAN bandwidth가 충분하지 않아 적시에 마이그레이션하기 어려운 경우에는 대량 오프라인 전송 서비스가 선호되는 경우가 많습니다. 흔한 오해: 대표적인 오해 중 하나는 DataSync가 모든 AWS 파일 서비스에 직접 쓸 수 있다고 생각하는 것입니다. 실제 지원 여부는 서비스별로 다릅니다. 또 다른 오해는 S3가 POSIX metadata에 대해 파일시스템과 동등한 staging 계층이라는 생각인데, 그렇지 않습니다. Snowmobile도 자주 과도하게 선택되지만, 이는 500 TB 워크로드가 아니라 수 페타바이트에서 엑사바이트 규모의 마이그레이션을 위한 서비스입니다. 시험 팁: 문제가 POSIX permissions와 symlinks를 강조하면, S3로의 rsync 같은 일반적인 object-copy 도구보다 DataSync와 파일 인지 마이그레이션 경로를 우선 고려하세요. 매우 큰 데이터셋의 경우 규모가 수백 테라바이트이면 Snowball Edge를, 수 페타바이트 이상일 때만 Snowmobile을 찾으세요. 또한 선택지에 언급된 마이그레이션 도구가 대상 서비스에 실제로 직접 지원되는지도 확인하세요.
금융 서비스 회사가 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(보안 원칙) 지침.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
금융 서비스 회사가 디지털 뱅킹 플랫폼을 AWS 클라우드 인프라로 확장하고 있습니다. 이 회사는 피크 시간에 시간당 50,000건 이상의 트랜잭션을 처리하는 중요한 결제 처리 시스템을 운영합니다. 레거시 데이터 센터에서는 전용 네트워크 어플라이언스를 사용하여 보안 결제 네트워크를 드나드는 모든 트래픽에 대해 심층 패킷 검사(deep packet inspection), 맬웨어 탐지 및 프로토콜 검증을 수행했습니다. 이 회사는 모든 남북(north-south) 및 동서(east-west) 트래픽 흐름에 대해 상태 저장 검사(stateful inspection), 사용자 지정 규칙 기반 필터링 및 침입 방지를 수행할 수 있는 동등한 네트워크 보안 제어를 AWS 프로덕션 VPC에 구현해야 합니다. 이 솔루션은 높은 처리량 요구 사항을 지원하고 여러 가용 영역(AZ)에 걸쳐 중앙 집중식 정책 관리를 제공해야 합니다. 이러한 네트워크 보안 요구 사항을 가장 잘 충족하는 AWS 솔루션은 무엇입니까?
Amazon GuardDuty는 신호(예: VPC Flow Logs, DNS 로그, CloudTrail)를 분석하여 위협을 탐지하고 결과를 생성합니다. 주로 탐지 제어 기능이며 DPI, 프로토콜 검증 또는 침입 방지를 수행하는 인라인 방화벽으로 작동하지 않습니다. 리소스를 격리하기 위해 응답을 자동화(예: Lambda를 통해)할 수는 있지만 높은 처리량에서 모든 남북 및 동서 트래픽에 대해 상태 저장 필터링을 중앙에서 적용하도록 설계되지 않았습니다.
VPC Traffic Mirroring은 분석을 위해 ENI에서 모니터링 어플라이언스로 트래픽을 복사합니다. 이는 IDS 도구, 문제 해결 및 포렌식에 유용하지만 대역 외(out-of-band) 방식입니다. 미러링된 트래픽 검사는 본질적으로 원래 트래픽 흐름을 차단하거나 필터링하지 않습니다. 또한 운영 복잡성(EC2 어플라이언스 확장, 장애 조치 관리)을 초래하며 AZ 전반에 걸쳐 IPS와 유사한 제어에 필요한 네이티브 중앙 집중식 인라인 정책 적용을 제공하지 않습니다.
AWS Network Firewall은 VPC의 인라인 네트워크 보호를 위해 특별히 구축되었으며 상태 저장 검사, 상태 비저장 필터링 및 Suricata 호환 IPS 규칙을 지원합니다. 사용자 지정 규칙 그룹을 적용하고, 프로토콜 인식 검사를 수행하며, AZ당 방화벽 엔드포인트를 배포하고 라우팅 테이블을 통해 트래픽을 조향함으로써 여러 AZ에 걸쳐 일관된 적용으로 중앙 집중식 정책을 제공할 수 있습니다. 대규모 레거시 심층 패킷 검사 및 침입 방지 어플라이언스 요구 사항과 가장 잘 일치합니다.
AWS Firewall Manager는 계정 및 VPC 전반에 걸쳐 보호 기능(예: AWS WAF, Shield Advanced, 보안 그룹 정책 및 AWS Network Firewall 정책)을 중앙에서 배포하고 관리하는 데 도움이 되는 거버넌스 및 정책 오케스트레이션 서비스입니다. 그러나 그 자체가 트래픽 검사 또는 침입 방지 엔진은 아닙니다. 보안 그룹 및 NACL에도 DPI/IPS 기능이 부족하고 L3/L4 제어로 제한되므로 이 옵션은 명시된 요구 사항을 충족하지 않습니다.
문제 분석
핵심 개념: 이 질문은 남북(수신/송신) 및 동서(수평) VPC 트래픽을 모두 포괄하여 대규모로 기존의 심층 패킷 검사(DPI), 침입 방지 및 프로토콜 검증과 유사한 네트워크 계층 보안 제어를 AWS에 구현하는 방법을 테스트합니다. 이를 위해 설계된 AWS 네이티브 서비스는 AWS Network Firewall입니다. 정답인 이유: AWS Network Firewall은 Suricata 호환 규칙을 사용하여 상태 저장 검사, 상태 비저장 필터링 및 침입 방지 기능을 제공합니다. 각 가용 영역의 전용 방화벽 서브넷에 배포되며 VPC 라우팅을 사용하여 트래픽 경로에 삽입할 수 있습니다(예: 트래픽을 Network Firewall 엔드포인트로 전달). 이를 통해 결제 시스템의 전형적인 높은 처리량 요구 사항을 충족하면서 AZ 전반에 걸쳐 중앙 집중식의 일관된 정책 적용이 가능합니다. 프로토콜 검증 및 서명 기반 탐지를 위한 사용자 지정 규칙 그룹을 지원하여 설명된 레거시 어플라이언스 기능과 밀접하게 일치합니다. 주요 AWS 기능: 1) 상태 저장 및 상태 비저장 규칙 엔진: 연결 추적 및 애플리케이션/프로토콜 인식 검사를 위한 상태 저장 규칙; 고속 L3/L4 필터링을 위한 상태 비저장 규칙. 2) 관리형 규칙 그룹 및 사용자 지정 규칙 그룹: AWS 관리형 위협 서명을 사용하고 사용자 지정 허용/거부 규칙을 추가합니다. 3) 다중 AZ 아키텍처: 복원력을 위해 AZ당 엔드포인트를 배포하고 교차 AZ 병목 현상을 방지합니다. 남북 및 동서 검사를 위해 라우팅 테이블과 통합합니다. 4) 중앙 집중식 가시성: 금융 서비스에서 일반적인 SIEM 통합 및 감사 요구 사항을 위해 Amazon CloudWatch Logs, S3 또는 Kinesis Data Firehose에 로그를 기록합니다. 일반적인 오해: GuardDuty는 인라인 적용 방화벽이 아니라 탐지(경고) 기능입니다. Traffic Mirroring은 대역 외(out-of-band) 검사용이며 인라인으로 차단하지 않습니다. Firewall Manager는 정책 배포를 중앙 집중화하지만 기본 서비스(WAF, Shield, 보안 그룹, Network Firewall)에 의존합니다. 그 자체가 DPI/IPS 엔진은 아닙니다. 시험 팁: VPC 트래픽에 대한 "상태 저장 검사(stateful inspection)", "침입 방지(intrusion prevention)", "사용자 지정 규칙 기반 필터링(custom rule-based filtering)" 및 "인라인 적용(inline enforcement)"을 보면 AWS Network Firewall을 생각하십시오. 가시성/포렌식을 위해 Traffic Mirroring을, 위협 탐지를 위해 GuardDuty를, 다중 계정 거버넌스를 위해 Firewall Manager를 사용하십시오. 기본 인라인 IPS/방화벽 데이터 플레인으로는 사용하지 마십시오.
한 미디어 회사가 영화(1–10GB 파일)를 S3에 저장합니다. 스트리밍은 구매 후 5분 이내에 시작되어야 합니다. 최신 영화(20년 미만)는 오래된 영화보다 수요가 더 많습니다. 이 회사는 수요에 따라 호스팅 비용을 최소화하려고 합니다. 5분 가용성 목표를 충족하면서 비용을 최소화하는 스토리지 클래스 및 검색을 선택하십시오. 요구 사항을 충족하는 솔루션은 무엇입니까?
이 선택지는 S3 Standard가 immediate access를 제공하고 이후 IA로 전환하면 일부 비용을 줄일 수 있으므로 performance requirement는 충족합니다. 그러나 모든 콘텐츠가 가장 비싼 storage class에서 시작하므로, 오래된 영화의 수요가 명시적으로 더 낮다는 점을 고려하면 가장 cost-effective한 선택지는 아닙니다. 문제는 수요를 기준으로 hosting cost를 최소화하라고 묻고 있으며, 이 선택지는 오래된 콘텐츠에 대해 더 저렴한 archival storage를 활용하지 않습니다.
이 선택지는 오래된 영화에 대해 S3 Standard-IA에서 'standard retrieval'을 언급하고 있기 때문에 문제가 있습니다. 하지만 Standard-IA는 Glacier 스타일 retrieval tiers나 restore operations를 사용하지 않습니다. Standard-IA는 immediate access를 제공하므로 timing requirement를 충족할 수는 있지만, 이 표현은 service behavior에 대한 혼동을 드러냅니다. 더 중요한 점은, 매우 오래되고 수요가 낮은 영화에 대해서는 expedited retrieval이 가능한 Glacier Flexible Retrieval만큼 비용 효율적이지 않다는 것이며, 문제는 바로 그 방향으로 유도하고 있습니다.
정답입니다. S3 Intelligent-Tiering은 최신 영화에 적합한데, 최신 콘텐츠는 수요가 더 높고 변할 가능성도 있으며, Intelligent-Tiering은 immediate access performance를 희생하지 않고 비용을 자동으로 최적화할 수 있기 때문입니다. 오래된 영화의 경우, S3 Glacier Flexible Retrieval은 Standard 또는 Standard-IA와 비교해 storage cost를 크게 낮춥니다. expedited retrieval을 사용하면 archived objects를 약 1–5분 내에 restore할 수 있으므로, 구매 후 5분 이내에 streaming이 시작되어야 한다는 요구 사항과 일치합니다.
이 선택지는 S3 Glacier Flexible Retrieval의 bulk retrieval이 일반적으로 몇 분이 아니라 몇 시간이 걸리므로 5분 요구 사항을 충족하지 못합니다. Glacier Flexible Retrieval은 storage 측면에서는 비용 효율적이지만, 선택된 retrieval tier가 구매 직후 on-demand streaming을 제공하기에는 너무 느립니다. 따라서 명시된 availability target을 충족할 수 없습니다.
문제 분석
핵심 개념: 이 문제는 access frequency와 필요한 retrieval time을 기준으로 Amazon S3 storage classes를 선택하는지를 평가합니다. 핵심 요구 사항은 구매 후 5분 이내에 streaming이 시작되어야 한다는 점이며, 오래된 영화는 수요가 더 낮으므로 더 저렴하게 저장되어야 합니다. 가장 적절한 설계는 최신 콘텐츠에는 frequent-access class를 사용하고, 오래된 콘텐츠에는 retrieval option이 5분 목표를 여전히 충족할 수 있는 경우에만 더 저렴한 archival class를 사용하는 것입니다. 정답인 이유: S3 Intelligent-Tiering은 access patterns가 변하더라도 storage cost를 자동으로 최적화하면서 immediate access를 계속 제공하므로 최신 영화에 적합합니다. 오래되어 수요가 낮은 영화의 경우, S3 Glacier Flexible Retrieval은 훨씬 낮은 storage cost를 제공하며, expedited retrieval은 1–5분 내 access를 위해 설계되어 명시된 availability target과 일치합니다. 제공된 보기 중에서, 이것은 5분 요구 사항을 충족하도록 의도된 retrieval mode와 더 저렴한 archival storage를 명시적으로 결합한 유일한 선택지입니다. 주요 기능: S3 Intelligent-Tiering은 millisecond access와 함께 automatic tiering을 제공하며, access patterns가 불확실하거나 가변적일 때 유용합니다. S3 Glacier Flexible Retrieval은 expedited, standard, bulk의 세 가지 restore tiers를 지원하며, expedited가 가장 빠르고 몇 분 내 긴급 retrieval을 위해 설계되었습니다. S3 Standard와 Standard-IA는 모두 immediate access를 제공하지만, Glacier classes는 restore latency를 허용할 수 있을 때 infrequently accessed objects의 storage cost를 크게 줄일 수 있습니다. 흔한 오해: 흔한 함정은 Glacier retrieval은 모두 너무 느리다고 가정하는 것이지만, expedited retrieval은 분 단위 access를 위해 특별히 존재합니다. 또 다른 오해는 Standard-IA에 'standard retrieval'과 같은 Glacier 스타일 retrieval modes가 있다고 보는 것인데, 그렇지 않습니다. Standard-IA는 restore operations가 필요 없으며 즉시 access됩니다. 또한 Glacier의 bulk retrieval은 거의 즉시 streaming해야 하는 요구 사항에는 너무 느립니다. 시험 팁: 문제가 짧은 retrieval SLA를 충족하면서 가장 낮은 비용을 요구할 때는, 가장 빠른 restore tier를 가진 archival class가 timing requirement를 충족할 수 있는지 비교하세요. 요구 사항이 분 단위일 때는 bulk retrieval이 포함된 선택지를 제거하세요. 또한 Glacier retrieval terms를 non-Glacier storage classes에 적용하는 것처럼 AWS terminology를 잘못 사용하는 distractors도 주의하세요.
금융 서비스 회사가 규정 준수 테스트 및 위험 분석을 위해 프로덕션 환경에서 스테이징 환경으로 50TB의 고객 트랜잭션 데이터를 정기적으로 복제해야 합니다. 프로덕션 데이터는 us-east-1 리전의 Amazon EBS 볼륨을 사용하는 Amazon EC2 인스턴스에 상주합니다. 복제된 데이터는 테스트 중 영향을 방지하기 위해 프로덕션 데이터와 완전히 격리되어야 합니다. 위험 분석 소프트웨어는 10,000+ IOPS의 지속적으로 높은 IOPS 성능을 요구합니다. 복제 프로세스는 규제 기한을 맞추기 위해 4시간의 유지 관리 기간 내에 완료되어야 합니다. 모든 성능 및 격리 요구 사항을 충족하면서 프로덕션 데이터를 복제하는 데 필요한 시간을 최소화하는 솔루션은 무엇입니까?
Instance store는 매우 높은 IOPS를 제공할 수 있지만 EBS snapshot을 instance store로 직접 복원하는 것은 기본 "복원" 작업이 아닙니다. snapshot에서 EBS 볼륨을 생성한 후 OS/파일 수준에서 데이터를 복사해야 하므로 50TB의 경우 시간이 많이 걸립니다. 또한 운영 복잡성이 추가되고 4시간의 창을 놓칠 위험이 있습니다. 게다가 instance store는 임시적이므로 반복 가능한 규정 준수 테스트 데이터 세트에는 일반적으로 바람직하지 않습니다.
EBS Multi-Attach는 io1/io2에서만 지원되며 격리된 복제본을 생성하기 위한 것이 아니라 조정된 쓰기가 있는 클러스터링된 애플리케이션을 위한 것입니다. 동일한 프로덕션 볼륨을 스테이징에 연결하면 완전한 격리 요구 사항을 위반하고 스테이징 환경에서 쓰기를 수행할 경우 데이터 손상이나 성능 저하의 위험이 있습니다. Snapshot은 이 옵션이 프로덕션 볼륨 연결을 제안한다는 사실을 바꾸지 않으며, 이것이 핵심 문제입니다.
새로운 EBS 볼륨을 생성하고 snapshot에서 복원하면 격리가 제공되지만 Fast Snapshot Restore가 없으면 볼륨이 lazy-loading됩니다. 일관된 고성능을 달성하려면 모든 블록을 읽어 볼륨을 초기화해야 하는 경우가 많으며, 50TB의 경우 시간이 오래 걸리고 4시간의 창을 초과할 수 있습니다. 이 옵션은 그럴듯하지만 복제 시간을 최소화하지 않으며 복원 후 즉각적이고 지속적인 10,000+ IOPS 성능을 보장하지 않습니다.
이것은 즉각적인 고성능을 제공하는 대규모 복제를 위한 가장 빠르고 안정적인 접근 방식입니다. Snapshot은 깨끗하고 격리된 복사 메커니즘을 제공하며, Fast Snapshot Restore는 lazy loading의 초기 지연 시간/처리량 페널티를 제거합니다. 선택한 AZ에서 FSR이 활성화된 snapshot으로 생성된 볼륨은 프로비저닝된 전체 IOPS를 즉시 제공할 수 있으므로 50TB 데이터 세트에 대한 10,000+ IOPS 요구 사항과 4시간의 유지 관리 기간을 충족하는 데 도움이 됩니다.
문제 분석
핵심 개념: 이 질문은 엄격한 시간 창 내에서 높은 지속적 IOPS 요구 사항을 충족하고 복원 성능에 중점을 둔 대규모 Amazon EBS snapshot 기반 복제를 테스트합니다. 핵심 개념은 snapshot에서 표준 EBS 볼륨을 복원할 때 lazy-loading이 발생하여 복원 시간과 초기 I/O 성능 모두에 심각한 영향을 미칠 수 있다는 것입니다. 정답인 이유: 옵션 D는 특정 시점 복제를 위해 EBS snapshot을 사용하고 해당 snapshot에서 EBS Fast Snapshot Restore(FSR)를 활성화합니다. FSR은 대상 Availability Zone에서 snapshot의 데이터를 완전히 사용할 수 있도록 보장하여 일반적인 "first-read penalty"를 제거함으로써, 새로 생성된 볼륨이 프로비저닝된 성능을 즉시 제공할 수 있게 합니다. 4시간의 유지 관리 기간과 10,000+ IOPS의 지속적인 요구 사항이 있는 50TB 데이터 세트의 경우, 초기화 시간을 최소화하고 초기 읽기 중 성능 저하를 방지하는 것이 중요합니다. FSR이 활성화된 snapshot에서 새로운 EBS 볼륨을 생성하면 강력한 격리(프로덕션과 분리된 볼륨)와 고성능 테스트를 위한 신속한 준비 상태를 제공합니다. 주요 AWS 기능: - EBS Snapshots: 증분식이며 Amazon S3에 저장되고, 파일 수준에서 데이터를 복사하지 않고 볼륨을 복제하는 데 사용됩니다. - Fast Snapshot Restore: 특정 AZ에서 snapshot 데이터를 미리 웜업(pre-warm)하여 snapshot에서 생성된 볼륨이 즉시 전체 성능을 제공하도록 합니다. - High IOPS volumes: 10,000+ 지속적 IOPS 요구 사항을 충족하기 위해 일반적으로 io1/io2(또는 충분히 프로비저닝된 IOPS를 가진 gp3)를 사용합니다. 일반적인 오해: 많은 사람들이 "snapshot에서 복원"이 즉시 빠르다고 가정합니다. 실제로는 lazy loading으로 인해 표준 복원이 초기에는 느릴 수 있으며, 일관된 성능을 달성하기 위해 볼륨 초기화(모든 블록 읽기)를 실행해야 할 수 있습니다. 이는 50TB의 경우 4시간의 창을 초과하는 경우가 많습니다. 또 다른 오해는 프로덕션 스토리지 연결(예: Multi-Attach)이 빠른 복제를 제공한다는 것입니다. 이는 격리 요구 사항을 위반하고 위험을 초래할 수 있습니다. 시험 팁: 대규모 데이터 세트 + 촉박한 RTO/유지 관리 기간 + 복원 직후 높은 IOPS가 보이면 EBS Fast Snapshot Restore를 찾으십시오. 또한 격리 요구 사항의 경우 프로덕션 볼륨을 공유/연결하는 것보다 snapshot에서 새로운 볼륨을 생성하는 것을 선호하십시오. 요구 사항을 병목 현상에 매핑하십시오. 여기서 병목 현상은 단순한 원시 IOPS 프로비저닝이 아니라 snapshot 복원/초기화 시간과 초기 읽기 성능입니다.
한 의료 기술 스타트업이 6개월 동안 AWS에서 원격 의료 플랫폼을 운영해 왔습니다. 이 플랫폼은 3개의 지리적 리전에서 15,000명의 활성 사용자에게 서비스를 제공합니다. 최근 CFO는 월별 AWS 청구서, 특히 컴퓨팅 비용이 40% 급증한 것을 발견했습니다. 재무팀은 승인 없이 여러 Amazon EC2 인스턴스가 t3.medium에서 c5.2xlarge 인스턴스로 자동 업그레이드된 것을 발견했습니다. 이들은 지난 60일간의 컴퓨팅 지출 패턴을 분석하고 비용 증가를 주도하는 특정 인스턴스 패밀리를 식별해야 합니다. 최소한의 관리 노력으로 상세한 비용 분석 및 시각화를 제공하기 위해 솔루션 아키텍트는 무엇을 구현해야 합니까?
AWS Budgets는 주로 비용 또는 사용량 임계값을 설정하고 지출이 정의된 한도를 초과할 때 알림을 보내도록 설계되었습니다. budgets는 필터와 cost category로 범위를 지정할 수 있지만, 60일 기간 동안의 과거 EC2 지출 패턴을 상세하게 탐색 분석하는 용도로는 설계되지 않았습니다. 문제는 무엇이 증가를 유발했는지에 대한 조사와 시각화를 요구하며, 이는 Cost Explorer가 더 적합하게 처리합니다. Budgets는 보완적인 governance 도구로는 유용하지만, 여기서의 기본 분석 솔루션은 아닙니다.
AWS Cost Explorer가 정답인 이유는 최소한의 설정과 운영 오버헤드로 과거 지출 추세를 분석할 수 있는 AWS의 기본 도구이기 때문입니다. architect는 지난 60일을 선택하고, Amazon EC2로 필터링한 다음, instance type 또는 usage type과 같은 지원되는 차원으로 데이터를 그룹화하거나 drill down하여 어떤 업그레이드된 compute 리소스가 비용 증가를 초래했는지 식별할 수 있습니다. 이는 사용자 지정 data engineering 없이도 상세한 비용 분석과 시각화 요구 사항을 충족합니다. 최근 EC2 비용 급증을 신속하게 조사하기 위한 가장 효율적인 관리형 옵션입니다.
AWS Billing Dashboard는 요약 수준의 billing 보기와 기본 차트를 제공하지만, 어떤 EC2 instance type 또는 관련 family가 compute 비용 증가를 유발했는지 분리해낼 수 있을 정도의 drill-down 기능은 제공하지 않습니다. 비용이 변했다는 사실을 확인하는 데는 유용하지만, 유연한 그룹화와 함께 사용자 지정 기간 전반에 걸친 상세 분석을 수행하기에는 적합하지 않습니다. 요구 사항은 비용 급증의 구체적인 원인을 식별하는 것이므로, Billing Dashboard는 너무 제한적입니다. Cost Explorer에서 제공되는 더 풍부한 조사 기능이 부족합니다.
AWS Cost and Usage Reports를 Amazon S3 및 Amazon QuickSight와 결합하면 line-item billing 분석을 포함한 매우 상세하고 사용자 지정 가능한 비용 분석을 확실히 제공할 수 있습니다. 그러나 이 접근 방식은 CUR 활성화, report 데이터 저장 및 관리, dataset 준비, dashboard 구축이 필요하므로 구현 및 유지 관리 노력이 더 많이 듭니다. 문제는 명시적으로 최소한의 관리 노력을 요구하므로, 이 솔루션은 60일간의 EC2 비용 조사에는 불필요하게 복잡합니다. 기본 billing 도구를 넘어서는 고급 사용자 지정 보고가 필요한 조직에 더 적합합니다.
문제 분석
핵심 개념: 이 문제는 AWS 비용 분석 도구에 대한 지식과, 과거 EC2 비용 증가를 조사할 때 가장 관리 부담이 적은 옵션을 선택하는 능력을 평가합니다. 핵심 요구 사항은 지난 60일간의 compute 지출을 검토하고, 어떤 EC2 instance type 또는 관련 family가 비용 급증의 원인이 되었는지 식별하며, 이를 기본 제공 시각화와 최소한의 운영 노력으로 수행하는 것입니다. 정답인 이유: AWS Cost Explorer가 가장 적합한 이유는 사용자 지정 기간(지난 60일 포함)에 대한 과거 지출 추세를 보여줄 수 있는 관리형 billing 분석 도구이기 때문입니다. solutions architect는 Amazon EC2로 필터링하고 usage type 또는 instance type과 같은 차원으로 비용을 그룹화하여, 어떤 업그레이드된 instance가 비용 증가의 원인인지 확인할 수 있습니다. instance family가 항상 직접적인 그룹화 차원으로 노출되지는 않더라도, Cost Explorer는 사용자 지정 보고 파이프라인을 구축하지 않고도 비용을 유발한 EC2 type을 식별하는 가장 빠른 방법을 제공합니다. 주요 AWS 기능: Cost Explorer는 대화형 차트, 일별 또는 월별 세분성, service 수준 필터링, 지원되는 billing 차원별 그룹화를 제공합니다. 이는 AWS Billing console에서 직접 과거 비용 분석과 추세 시각화를 수행하도록 설계되었습니다. 상세 billing 데이터를 내보내고 사용자 지정 dashboard를 구축하는 방식과 비교하면 설정이 거의 필요 없거나 전혀 필요 없습니다. 흔한 오해: AWS Budgets는 주로 임계값 기반 모니터링과 알림을 위한 도구이며, 과거 데이터를 깊이 있게 탐색하는 용도는 아닙니다. Billing Dashboard는 어떤 EC2 instance type이 지출을 유발했는지 식별하기에는 너무 높은 수준의 정보만 제공합니다. Cost and Usage Reports와 QuickSight를 함께 사용하면 더 세밀하고 사용자 지정 가능한 분석이 가능하지만, 이 접근 방식은 문제에서 허용하는 것보다 훨씬 더 많은 설정과 유지 관리가 필요합니다. 시험 팁: 요구 사항이 과거 비용 분석, 시각화, 최소한의 관리 노력에 중점을 둘 때는 Cost Explorer가 일반적으로 가장 좋은 정답입니다. line-item billing 세부 정보, 사용자 지정 보고 로직, 또는 기본 billing 도구를 넘어서는 enterprise 규모의 보고가 명시적으로 요구될 때만 CUR 기반 분석을 선택하세요. Budgets와 같은 알림 도구를 Cost Explorer와 같은 조사 도구와 혼동하지 않도록 주의하세요.
한 금융 기술 스타트업이 분당 수천 건의 트랜잭션을 처리하는 실시간 결제 처리 플랫폼을 개발하고 있습니다. 이 플랫폼은 하루 종일 크게 변동하는 트랜잭션 볼륨(피크 시간대에는 비피크 시간대보다 10배 더 많은 트래픽 발생)에 따라 자동으로 확장되어야 하는 여러 마이크로서비스로 구성됩니다. 개발 팀은 빠른 배포와 고가용성을 달성하기 위해 마이크로서비스를 컨테이너화하고자 합니다. 이들은 인프라 관리보다는 애플리케이션 개발 및 결제 로직 최적화에 전적으로 집중해야 합니다. 솔루션은 자동 확장을 제공하고 서버 프로비저닝 및 유지 관리의 필요성을 제거해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?
Docker Engine 및 Auto Scaling 그룹이 있는 EC2는 인스턴스 수를 확장할 수 있지만 AMI 유지 관리, OS 패치 적용, 용량 계획, 컨테이너 예약, 서비스 검색 및 롤링 배포와 같은 상당한 운영 작업을 남깁니다. 또한 인스턴스 전체에서 컨테이너를 오케스트레이션하기 위해 추가 도구가 필요하거나 자체적으로 구축해야 합니다. 이는 서버 프로비저닝을 제거하고 인프라 관리를 최소화하라는 요구 사항과 모순됩니다.
EC2 시작 유형의 ECS는 원시 EC2 + Docker에 비해 오케스트레이션을 개선하지만 여전히 EC2 클러스터를 관리해야 합니다. 인스턴스 선택, 패치 적용, 조정 정책, 급증 시 작업 배치를 위한 충분한 여유 용량 확보 등이 포함됩니다. 클러스터 Auto Scaling이 도움이 되지만 여전히 Fargate보다 운영 부담이 크며 빠른 트래픽 급증 시 용량 부족을 방지하기 위해 신중한 튜닝이 필요할 수 있습니다.
AWS Fargate가 포함된 ECS는 요구 사항과 가장 잘 일치합니다. 관리형 컨테이너 오케스트레이션을 제공하면서 서버를 프로비저닝, 패치 및 관리할 필요성을 제거합니다. ECS Service Auto Scaling을 사용하여 수요에 따라 작업을 확장하고 고가용성을 위해 여러 AZ에서 실행할 수 있습니다. 이를 통해 빠른 배포가 가능하고 최소한의 운영 오버헤드로 큰 트래픽 변동성을 처리할 수 있습니다.
EC2에서 ECS-optimized AMI를 사용하고 오케스트레이션을 수동으로 구성하는 것은 옵션 중 운영 부담이 가장 높습니다. ECS를 사용하더라도 "수동으로 구성"한다는 것은 클러스터 용량, 배포 및 유지 관리에 대한 더 많은 실무 관리를 의미합니다. 이는 애플리케이션 로직에 집중하고 서버 프로비저닝 및 지속적인 인프라 유지 관리를 피하라는 요구 사항과 직접적으로 충돌합니다.
문제 분석
핵심 개념: 이 질문은 서버리스 컨테이너 오케스트레이션 및 운영 책임 경계를 테스트합니다. 핵심 서비스는 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로 이전합니다.
합격 후기(32)
학습 기간: 1 month
모의고사 780쯤 달성하고 시험도전했는데 800초반으로 합격했습니다 실제 문제는 지문이 더 짧고 간단했네요
학습 기간: 1 month
시험문제보다 난이도가 있는편이고 같은문제도 조금 나왔습니다
학습 기간: 1 week
요구사항 정확히 인지하기(이거 젤중요 이 훈련이 제일 중요한듯), 오답노트 갈겨서 200문제만 확실히 해서 갔어요 실제 시험 지문은 훨씬 간단한데 난이도는 앱이랑 비슷하거나 더 낮았던것같아요 느낌상 탈락이었는데 통과해서 기쁘네요 큰 도움 되었습니다 감사해요!
학습 기간: 1 week
그냥 문제 풀면서 개념들 GPT에 물어보면서 학습했어요 768점 턱걸이 합격,,
학습 기간: 3 months
그냥 꾸준히 공부하고 문제 풀고 합격했어요 saa 준비생분들 화이팅!!
모의고사
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
Practice Test #10
다른 AWS 자격증
AWS Certified AI Practitioner (AIF-C01)
Practitioner
AWS Certified Advanced Networking - Specialty (ANS-C01)
Specialty
AWS Certified Cloud Practitioner (CLF-C02)
Practitioner
AWS Certified Data Engineer - Associate (DEA-C01)
Associate
AWS Certified Developer - Associate (DVA-C02)
Associate
AWS Certified DevOps Engineer - Professional (DOP-C02)
Professional
AWS Certified Machine Learning Engineer - Associate (MLA-C01)
Associate
AWS Certified Security - Specialty (SCS-C02)
Specialty
AWS Certified Solutions Architect - Professional (SAP-C02)
Professional
지금 학습 시작하기
Cloud Pass를 다운로드하여 모든 AWS Certified Solutions Architecture - Associate (SAA-C03) 기출 문제를 풀어보세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
앱 받기
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.