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

Practice Test #4

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

한 미디어 스트리밍 회사가 us-west-2 리전에 위치한 Amazon S3 버킷으로 매일 테라바이트 단위의 비디오 콘텐츠를 업로드하고 다운로드하는 비디오 처리 서비스를 운영하고 있습니다. 이 처리 서비스는 동일한 리전의 VPC 내 여러 Availability Zone에 걸쳐 프라이빗 서브넷에 배포된 Amazon EC2 인스턴스에서 실행됩니다. 현재 모든 S3 통신은 퍼블릭 서브넷의 NAT Gateway를 통해 흐르며, 이로 인해 월 약 $500의 상당한 데이터 전송 요금이 발생합니다. 회사는 프라이빗 서브넷에서의 안전한 액세스를 유지하면서 데이터 송신 비용을 최소화하도록 네트워크 아키텍처를 최적화해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

NAT 인스턴스는 때때로 NAT Gateway에 비해 시간당 비용을 줄일 수 있지만 과도한 S3 트래픽에 대해 가장 비용 효율적이거나 운영상 건전한 솔루션은 아닙니다. 여전히 모든 S3 데이터를 NAT를 통해 강제로 전송하며(불필요함), 패치 적용, 확장 및 HA 설계(장애 조치 스크립트, 다중 인스턴스)가 필요합니다. 테라바이트/일의 경우 처리량 제한 및 관리 오버헤드로 인해 S3 Gateway Endpoint보다 열등합니다.

이 옵션은 아키텍처적으로 올바르지 않습니다. NAT 인스턴스는 송신을 제공하기 위해 Internet Gateway에 대한 경로가 있는 퍼블릭 서브넷에 있어야 합니다. 프라이빗 서브넷에 배치하면 인터넷에 도달할 수 없습니다. 또한 퍼블릭 서브넷 라우팅 테이블에서 NAT 인스턴스로 "S3 트래픽"을 라우팅해도 프라이빗 서브넷 송신 패턴이 해결되지 않습니다. 비용을 효과적으로 줄이지도 못하고 올바른 NAT 설계와 일치하지도 않습니다.

정답입니다. S3 VPC Gateway Endpoint를 사용하면 프라이빗 서브넷이 NAT Gateway나 퍼블릭 인터넷을 거치지 않고 S3에 도달할 수 있습니다. 엔드포인트를 대상으로 하는 S3 접두사 목록으로 프라이빗 라우팅 테이블을 업데이트합니다. 이렇게 하면 S3 트래픽에 대한 NAT 데이터 처리 요금이 제거되고 보안이 향상됩니다. 엔드포인트 정책 및 엔드포인트 ID를 조건으로 하는 S3 버킷 정책을 사용하여 액세스를 추가로 잠글 수 있습니다.

두 번째 NAT Gateway를 추가하면 시간당 비용이 증가하고 NAT GB당 데이터 처리 요금이 제거되지 않습니다. 실제로 총 지출이 증가할 수 있습니다. 다중 AZ NAT Gateway는 복원력을 향상시키고 AZ별로 구성할 때 교차 AZ 라우팅 요금을 피할 수 있지만, 여기서 핵심 문제는 S3 트래픽이 NAT를 전혀 사용해서는 안 된다는 것입니다. 가장 비용 효율적인 수정 사항은 S3 Gateway Endpoint입니다.

문제 분석

핵심 개념: 이 질문은 VPC에서 Amazon S3로의 비용 최적화된 프라이빗 연결을 테스트합니다. 주요 서비스는 NAT Gateway(일반적인 아웃바운드 인터넷 액세스용) 대 S3 VPC Gateway Endpoint(NAT 없이 S3로의 프라이빗 AWS 네트워크 라우팅)입니다. 정답인 이유: 프라이빗 서브넷에서 S3 액세스를 위해 NAT Gateway를 사용하면 S3 트래픽이 NAT Gateway를 통과하게 되어 NAT 데이터 처리 요금(및 아키텍처에 따라 추가 데이터 전송 구성 요소)이 발생합니다. 매일 테라바이트를 이동하는 워크로드의 경우 NAT 처리 비용이 상당해질 수 있습니다. S3 VPC Gateway Endpoint는 AWS 백본을 통해 프라이빗 서브넷에서 S3로의 직접 경로를 제공하여 S3 액세스를 위한 NAT의 필요성을 제거합니다. Gateway Endpoint에는 시간당 요금이 없고 NAT Gateway와 같은 GB당 데이터 처리 요금이 없기 때문에 이것이 일반적으로 가장 비용 효율적인 접근 방식입니다. 또한 트래픽을 퍼블릭 인터넷에서 차단하여 보안 태세를 개선합니다. 주요 AWS 기능: 1) S3용 VPC Gateway Endpoint: 프라이빗 서브넷 라우팅 테이블에 S3에 대한 접두사 목록(prefix-list) 경로를 추가합니다. 2) 엔드포인트 정책: 허용되는 S3 버킷/작업을 제한합니다(최소 권한). 3) aws:SourceVpce 조건이 있는 S3 버킷 정책: 버킷이 엔드포인트를 통해서만 액세스할 수 있도록 보장합니다. 4) Multi-AZ: Gateway Endpoint는 고가용성이며 수평으로 확장됩니다. AZ별 배포가 필요하지 않습니다. 일반적인 오해: 일반적인 함정은 더 저렴한 NAT 인스턴스가 비용을 줄일 것이라고 생각하는 것입니다(옵션 A). 시간당 NAT 비용을 줄일 수는 있지만 동일한 관리형 확장성/가용성을 제공하지 않으며 여전히 NAT를 통해 S3 트래픽을 라우팅하는데, 이는 엔드포인트가 존재할 때 불필요합니다. 또 다른 오해는 트래픽을 "최적화"하기 위해 더 많은 NAT Gateway를 추가하는 것입니다(옵션 D). 이는 시간당 비용을 증가시키며 GB당 처리 요금을 제거하지 않습니다. 시험 팁: 동일한 리전의 프라이빗 서브넷에서 대상이 S3(또는 DynamoDB)인 경우 비용 및 보안을 위해 기본적으로 VPC Gateway Endpoint를 사용하십시오. 일반적인 인터넷 송신(소프트웨어 업데이트, 외부 API)에는 주로 NAT Gateway/인스턴스를 사용하십시오. "프라이빗 서브넷에서 S3", "NAT 데이터 요금 절감", "트래픽을 프라이빗으로 유지"와 같은 키워드를 찾아 Gateway Endpoint를 가장 좋은 답변으로 빠르게 식별하십시오.

2
문제 2

한 의료 기관이 여러 부서에 걸쳐 Amazon S3 버킷에 환자 의료 기록과 진단 이미지를 저장하고 있습니다. 엄격한 HIPAA 규정 준수 요구 사항으로 인해 저장된 모든 의료 데이터는 완전히 비공개로 유지되어야 하며 무단 접근에 노출되어서는 안 됩니다. 이 기관은 50개 이상의 버킷에 분산된 약 150TB의 민감한 의료 데이터가 있는 AWS 계정의 모든 S3 버킷에서 의료 데이터의 우발적인 퍼블릭 노출을 방지하는 포괄적인 솔루션을 구현해야 합니다. 이러한 보안 요구 사항을 가장 효과적으로 충족하는 솔루션은 무엇입니까?

GuardDuty는 주로 탐지 서비스입니다. S3 보호와 관련된 결과(예: 의심스러운 접근 패턴)를 생성할 수 있고 Lambda로 수정을 자동화할 수 있지만 이는 여전히 사후 대응적입니다. 버킷을 퍼블릭으로 만드는 잘못된 구성과 수정 작업 사이에 시간 차이가 있을 수 있습니다. "절대 노출되지 않음"의 경우 S3 Block Public Access와 같은 예방적 제어가 더 적절합니다.

Trusted Advisor는 퍼블릭으로 접근 가능한 S3 버킷을 보고할 수 있지만 예방적 제어가 아니며 주기적인 검사와 수동 수정에 의존합니다. 이메일 알림 및 사람의 개입은 지연 및 운영 위험을 초래하며 이는 엄격한 HIPAA 요구 사항과 충돌합니다. 이 옵션은 많은 버킷에 걸쳐 잘 확장되지 않으며 데이터가 절대 노출되지 않는다고 보장하지 않습니다.

AWS Resource Access Manager(RAM)는 AWS 계정 간에 리소스(예: 서브넷, Transit Gateway)를 공유하기 위한 것이며 퍼블릭 S3 버킷 접근을 검색하거나 관리하는 데 사용되지 않습니다. 설명된 탐지 및 수정 흐름은 RAM의 작동 방식과 일치하지 않습니다. 다른 서비스와 함께 구현되더라도 강력한 예방 가드레일이라기보다는 사후 대응적일 것입니다.

계정 수준의 S3 Block Public Access는 이 요구 사항에 가장 강력한 예방적 제어입니다. 버킷별 구성 없이도 50개 이상의 모든 버킷(기존 및 신규)에 즉시 적용됩니다. 퍼블릭 접근을 허용하는 버킷 수준 ACL 또는 버킷 정책을 재정의하여 "절대 노출되지 않음" 요구 사항을 직접적으로 충족합니다. AWS Organizations SCP로 이 설정을 강제하면 계정 관리자를 포함한 모든 IAM 사용자 및 역할이 BPA를 비활성화하지 못하도록 차단하는 거버넌스 계층이 추가됩니다. 이 조합은 사후 대응이 아닌 예방적 퍼블릭 접근 제어가 필요한 HIPAA 규제 환경의 표준 접근 방식입니다.

문제 분석

핵심 개념: 이 질문은 S3 Block Public Access(BPA) 및 거버넌스 가드레일(AWS Organizations SCP)을 사용하여 대규모 Amazon S3 퍼블릭 노출에 대한 예방적 제어를 테스트합니다. HIPAA 규제 데이터의 경우 목표는 노출 후 탐지 및 수정이 아니라 우발적인 잘못된 구성을 방지하는 것입니다. 정답인 이유: 계정 수준의 S3 Block Public Access는 ACL 또는 버킷 정책으로 인해 버킷(기존 또는 향후)이 퍼블릭이 될 수 없도록 보장하는 가장 포괄적이고 확장 가능한 제어입니다. 계정 수준 BPA는 (1) 퍼블릭 ACL 차단, (2) 퍼블릭 ACL 무시, (3) 퍼블릭 버킷 정책 차단, (4) 퍼블릭 버킷 정책 제한을 수행할 수 있습니다. 이는 버킷별 자동화 없이도 50개 이상의 버킷과 대용량 데이터 전반에 걸쳐 애초에 퍼블릭 접근이 부여되는 것을 방지하므로 "절대 노출되지 않음"을 직접적으로 해결합니다. 계정 수준 BPA(및 관련 S3 퍼블릭 접근 설정)를 비활성화하거나 수정하는 작업을 거부하는 AWS Organizations SCP(Service Control Policy)를 추가하면 IAM 보안 주체에게 광범위한 권한이 있더라도 제어가 강제됩니다. 이는 최소 권한 및 심층 방어에 부합하는 내구성 있는 가드레일을 생성합니다. 주요 AWS 기능: - S3 Block Public Access(계정 수준): 중앙 집중식으로 계정의 모든 버킷에 적용되며 버킷 수준 퍼블릭 설정을 재정의합니다. - AWS Organizations의 SCP: IAM 권한으로 우회할 수 없는 명시적 거부로, 규정 준수 가드레일에 이상적입니다. - 데이터 플레인 스캔이 아닌 컨트롤 플레인 설정이므로 데이터 크기(150TB)에 관계없이 작동합니다. 일반적인 오해: 탐지 서비스(GuardDuty, Trusted Advisor)는 노출에 대해 경고할 수 있지만 예방을 보장하지는 않습니다. 수정 전까지 퍼블릭 접근 창이 있을 수 있습니다. 또한 "수동 수정"은 엄격한 요구 사항에 허용되지 않습니다. 시험 팁: 요구 사항에 "모든 버킷에서 우발적인 퍼블릭 노출 방지"가 명시된 경우 S3 Block Public Access(계정 수준)와 거버넌스 강제(SCP)를 선호하십시오. "절대 퍼블릭이 되어서는 안 됨" 시나리오의 경우 탐지 제어(GuardDuty, Config)를 기본이 아닌 보완적으로 사용하십시오.

3
문제 3

한 차량 호출(ride-hailing) 스타트업이 Amazon DynamoDB 테이블에 이동(trip) 이벤트를 저장합니다. 잦은 버그 롤백으로 인해 팀은 수동 예약 없이 지난 24시간 내의 특정 시점으로 테이블을 복원해야 합니다. 최소한의 운영 노력으로 지난 24시간 내의 point-in-time recovery를 활성화하십시오. 최소한의 운영 오버헤드(가장 적은 operational overhead)로 요구 사항을 충족하는 솔루션은 무엇입니까?

정답입니다. DynamoDB Point-in-Time Recovery (PITR)는 지속적인 백업을 제공하며 보존 기간(최대 35일) 내의 어느 초로든 복원할 수 있게 해 주어 지난 24시간을 쉽게 포괄합니다. 기능을 활성화하기만 하면 되며 예약, 사용자 지정 코드 및 지속적인 운영이 거의 필요하지 않습니다. 이는 최소한의 운영 오버헤드 및 빈번한 롤백 복구에 대한 요구 사항과 가장 잘 일치합니다.

가장 적합하지 않습니다. AWS Backup은 백업 계획 및 일정을 통해 DynamoDB 백업을 관리할 수 있으므로 일부 노력을 줄일 수 있지만, 여전히 특정 시점의 어느 초가 아닌 개별 백업 시점으로 복원하는 것이 일반적입니다. "지난 24시간 내의 특정 시점"을 충족하려면 매우 빈번한 백업이 필요하며 여전히 PITR의 세분성과 일치하지 않습니다. 운영상 백업 계획, 일정 및 보존 정책을 관리해야 합니다.

오답입니다. Lambda를 통한 시간당 온디맨드 백업은 운영 오버헤드(Lambda 코드, IAM 권한, 예약, 모니터링, 재시도, 오류 처리)를 도입하고 "특정 시점"이 아닌 시간당 복원 지점만 제공합니다. 또한 실행이 실패하거나 스로틀링이 발생할 경우 공백이 생길 위험이 있습니다. 이는 DynamoDB PITR보다 더 많은 노력이 필요하고 복구 정밀도가 낮습니다.

최소 운영 복원(least-ops restore)에 대해 오답입니다. DynamoDB Streams와 S3 스토리지는 사용자 지정 재생/이벤트 소싱을 지원할 수 있지만 재생 메커니즘을 구축 및 운영하고 순서 지정, 중복, 스키마 변경 및 보존을 처리해야 합니다. PITR에 비해 복잡하고 운영 부담이 큽니다. 또한 추가 처리 없이는 테이블 상태에 대한 기본 특정 시점 복원 기능이 아닙니다.

문제 분석

핵심 개념: 이 질문은 운영 복원력을 위한 DynamoDB 데이터 보호 및 복구, 특히 Point-in-Time Recovery (PITR)를 테스트합니다. 요구 사항은 수동 예약 없이 최소한의 운영 노력으로 지난 24시간 내의 특정 시점으로 테이블을 복원하는 것입니다. 정답인 이유: DynamoDB PITR을 활성화하면 지속적인 백업이 제공되며 롤링 보존 기간(최대 35일) 내의 어느 초(second)로든 테이블을 복원할 수 있습니다. 팀은 지난 24시간 내의 복원이 필요하고 수동 예약을 원하지 않기 때문에 PITR이 목적에 가장 부합합니다. 활성화되면 DynamoDB가 자동으로 복원 기록을 유지 관리합니다. 사용자 지정 작업, 백업 일정 및 관리할 추가 데이터 파이프라인이 없으므로 운영 오버헤드가 최소화됩니다. 주요 AWS 기능: - DynamoDB PITR: 보존 기간 내에 초 단위 세분성을 갖춘 지속적이고 점진적인 백업. - 복원 동작: PITR은 새 테이블로 복원합니다(그런 다음 트래픽을 교체하거나 구성을 업데이트하거나 필요에 따라 이름을 바꿉니다). 이는 일반적인 복원력 패턴입니다. - 예약/자동화 불필요: 온디맨드 백업과 달리 PITR은 cron, Lambda 또는 외부 오케스트레이션이 필요하지 않습니다. - AWS Well-Architected 안정성(Reliability) 원칙과 일치: 복구 목표를 지원하고 백업을 자동화하여 인적 오류를 줄입니다. 일반적인 오해: - AWS Backup은 DynamoDB를 보호할 수 있지만 일반적으로 예약된 백업(또는 최소한 관리형 백업 계획)에 의존합니다. 백업을 자주 예약하더라도 초 단위 세분성으로 진정한 "특정 시점(any point in time)" 복원을 얻을 수는 없으며 백업 시점으로 복원합니다. PITR은 특정 시점 복원을 위해 명시적으로 설계된 DynamoDB 기본 기능입니다. - Lambda 기반의 시간당 백업은 간단해 보이지만 운영 부담(코드, 권한, 모니터링, 재시도, 스로틀링, 비용 관리)을 초래하며 여전히 시간당 복원 지점만 제공합니다. - 재생(replay)을 위해 DynamoDB Streams를 S3로 보내는 것은 이벤트 소싱 접근 방식이며 운영이 적은 복원 메커니즘이 아닙니다. 재생 시스템을 구축 및 운영하고 순서 지정, 멱등성(idempotency) 및 보존을 처리해야 합니다. 시험 팁: 최소한의 운영으로 DynamoDB에 대해 "특정 시점으로 복원(restore to any point in time)"을 볼 때 PITR을 선택하십시오. 질문에서 주기적인 백업, 서비스 전반의 중앙 집중식 정책 관리 또는 규정 준수 기반 보존을 요구하는 경우 AWS Backup이 적절할 수 있습니다. 항상 "특정 시점(point-in-time, 지속적)"과 "예약 시점(point-in-schedule, 스냅샷/백업)"을 구별하십시오.

4
문제 4
(2개 선택)

한 다국적 기업이 중요한 비즈니스 애플리케이션을 위해 일관되게 높은 사용률을 보이는 여러 Amazon RDS for Oracle On-Demand DB 인스턴스를 사용하고 있습니다. 이러한 RDS DB 인스턴스는 AWS Organizations 구조의 일부인 서로 다른 member accounts에서 관리됩니다. 모든 계정에 액세스할 수 있는 회사의 재무 계획 팀은 AWS 비용 최적화 도구를 활용하여 잠재적인 비용 절감 기회를 식별하는 임무를 맡고 있습니다. 재무 계획 팀이 비용 최적화 기회를 가장 효과적으로 식별하기 위해 취해야 할 단계의 조합은 무엇입니까? (2개 선택) 이러한 요구 사항을 충족하는 단계의 조합은 무엇입니까? (2개 선택)

"Amazon RDS Idle DB Instances" Trusted Advisor 검사는 데이터베이스가 활용도가 낮거나 사용되지 않을 때 유용하며 중지, 삭제 또는 축소 후보를 식별하는 데 도움이 됩니다. 그러나 질문에는 RDS for Oracle 인스턴스가 일관되게 높은 사용률을 보인다고 명시되어 있으므로 유휴 상태가 아닙니다. 이 검사는 이 워크로드 프로필에 대해 의미 있는 절감액을 표면화할 가능성이 낮습니다.

"Amazon RDS Reserved Instance Optimization" Trusted Advisor 검사는 일관되게 높은 On-Demand RDS 사용량에 가장 적합합니다. On-Demand 요금에 비해 RDS Reserved Instances를 구매하면 비용을 절감할 수 있는 곳을 식별합니다. 안정적인 사용률을 보이는 중요한 비즈니스 애플리케이션의 경우 RI는 고전적인 비용 최적화 레버이자 자주 테스트되는 시험 패턴입니다.

management account에서 Trusted Advisor 권장 사항을 사용하는 것은 조직 전체의 가시성이 필요한 재무 팀에 가장 효과적인 접근 방식입니다. AWS Organizations 통합(및 필수 지원 계획/기능)을 통해 management account는 member accounts 전반에 걸쳐 통합된 통찰력을 제공하여 수동 노력을 줄이고 비용 최적화 기회에 대한 일관된 거버넌스 및 보고를 보장할 수 있습니다.

각 member account에서 Trusted Advisor를 검토하면 RDS 인스턴스가 실행되는 RI 기회를 기술적으로 식별할 수 있지만 중앙 집중식 재무 계획 팀에는 덜 효과적입니다. 계정을 전환하고 결과를 수동으로 집계해야 합니다. AWS Organizations 환경에서 management account의 중앙 집중식 검토는 일반적으로 교차 계정 가시성을 위한 의도된 모범 사례입니다.

Trusted Advisor "컴퓨팅 최적화" 검사 및 AWS Compute Optimizer는 주로 EC2 인스턴스, Auto Scaling groups 및 Lambda functions와 같은 컴퓨팅 리소스에 중점을 둡니다. RDS for Oracle Reserved Instance 구매 기회를 식별하기 위한 기본 도구가 아닙니다. 귀중한 비용 도구이기는 하지만 설명된 RDS RI 최적화 요구 사항을 직접 해결하지는 않습니다.

문제 분석

핵심 개념: 이 질문은 AWS Trusted Advisor를 사용하여 여러 AWS Organizations 계정에서 Amazon RDS(Oracle)에 대한 AWS 비용 최적화를 테스트합니다. 핵심 아이디어는 (1) Reserved Instances (RIs)를 통해 일관되게 활용되는 On-Demand 데이터베이스에 대한 절감액을 식별하고 (2) 계정이 중앙에서 관리될 때 조직 전체의 권장 사항을 보는 방법을 이해하는 것입니다. 정답인 이유: RDS for Oracle 인스턴스는 일관되게 높은 사용률을 보이고 On-Demand이므로 가장 가능성 있는 비용 절감 기회는 RDS Reserved Instances를 구매하는 것입니다(또는 해당하는 경우 다른 약정 구성으로 이동). Trusted Advisor의 "Amazon RDS Reserved Instance Optimization" 검사는 On-Demand 사용 패턴이 잠재적인 RI 절감을 나타내는 곳을 강조합니다. 이는 시나리오와 직접적으로 일치합니다. 또한 재무 계획 팀은 모든 계정에 액세스할 수 있으며 member accounts에 분산된 인스턴스를 평가해야 합니다. 가장 효과적인 방법은 수동으로 계정별 검토를 요구하는 대신 통합된 다중 계정 보기를 제공할 수 있는 management account(AWS Organizations 통합 포함)에서 Trusted Advisor 권장 사항을 사용하는 것입니다. 주요 AWS 기능: Trusted Advisor는 RDS RI 최적화를 포함한 비용 최적화 검사를 제공합니다. AWS Organizations를 사용하면 Trusted Advisor를 사용하여 계정 전체의 결과를 집계할 수 있습니다(적절한 지원 계획 및 조직 보기 구성 가정). 이는 AWS Well-Architected 프레임워크의 비용 최적화 원칙과 일치합니다: 워크로드가 안정적일 때 용량을 약정하고 거버넌스를 위해 가시성을 중앙 집중화하십시오. 일반적인 오해: 옵션 A(Idle DB Instances)는 일반적인 비용 검사이지만 "일관되게 높은 사용률"에는 맞지 않습니다. 옵션 D(member accounts)는 운영상 작동할 수 있지만 팀이 이미 조직 전체의 액세스 권한을 가지고 있고 통합 보고가 필요할 때 중앙 집중식 검토보다 덜 효과적입니다. 옵션 E는 Compute Optimizer가 EC2, Auto Scaling, Lambda 및 일부 컨테이너 권장 사항에 중점을 두기 때문에 오해의 소지가 있습니다. RDS Oracle RI 구매 지침을 위한 기본 도구가 아닙니다. 시험 팁: "안정적/높은 사용률 + On-Demand"가 보이면 "Reserved Instances/Savings Plans"(RDS의 경우 일반적으로 RI)를 생각하십시오. "AWS Organizations 산하의 여러 계정 + 중앙 재무 팀"이 보이면 비용 거버넌스 도구(Cost Explorer, CUR 및 해당하는 경우 Trusted Advisor 조직 보기)에 대한 "management account 통합 가시성"을 생각하십시오.

5
문제 5

의료 기관이 환자 의료 기록 및 연구 문서를 저장하기 위해 Amazon S3를 사용합니다. HIPAA 규정 준수 요구 사항으로 인해 저장된 모든 데이터는 적절하게 분류되어야 하며 보호 대상 건강 정보(PHI)는 식별되고 적절하게 보호되어야 합니다. 이 기관은 500,000개의 S3 객체 중 약 15%에 업로드 중에 적절하게 태그가 지정되지 않은 PHI 데이터가 포함되어 있을 수 있음을 발견했습니다. S3 버킷에서 PHI를 지속적으로 스캔하고 민감한 데이터가 감지되면 규정 준수 팀에 즉시 알리는 자동화된 솔루션이 필요합니다. 이러한 요구 사항을 가장 효과적으로 충족하는 솔루션은 무엇입니까?

정답입니다. Amazon Macie는 S3에서 민감한 데이터(PII/PHI 관련 패턴 포함)를 검색하고 분류하도록 설계되었으며 결과를 생성합니다. 이러한 결과는 SensitiveData 결과와 일치하는 이벤트 패턴을 사용하여 Amazon EventBridge를 통해 라우팅된 다음 즉각적인 사람의 알림(이메일/SMS/HTTP)을 위해 Amazon SNS로 전달될 수 있습니다. 이는 규정 준수 대응을 위한 지속적인 스캔과 즉각적인 알림을 직접적으로 충족합니다.

오답입니다. Amazon Inspector는 컴퓨팅(EC2 인스턴스), ECR의 컨테이너 이미지 및 Lambda 함수에 대한 취약성 관리에 중점을 둡니다. PHI/PII를 감지하기 위해 S3 객체 콘텐츠를 스캔하지 않습니다. EventBridge + SNS가 유효한 알림 패턴이더라도 기본 감지 서비스는 S3 객체 내부의 민감한 데이터를 식별하는 요구 사항에 대해 잘못되었습니다.

오답입니다. Macie는 올바른 감지 서비스이지만 결과를 SQS로 보내는 것은 "규정 준수 팀에 즉시 알리는" 가장 효과적인 방법이 아닙니다. SQS는 애플리케이션 처리를 위한 대기열이며 소비자가 폴링한 다음 사람에게 알려야 합니다. 또한 SensitiveData:S3Object/Personal을 구체적으로 필터링하는 것은 PHI 사용 사례에 너무 좁을 수 있습니다. 광범위하게 SensitiveData 결과가 더 적절합니다.

오답입니다. 이 옵션은 이중으로 일치하지 않습니다. Inspector는 S3 객체에서 PHI를 감지하지 않으며 SQS는 규정 준수 팀을 위한 직접적인 알림 메커니즘이 아닙니다. 소비자가 SQS를 읽고 알림을 트리거하는 워크플로를 구축할 수는 있지만 불필요한 구성 요소를 추가하고 민감한 데이터에 대해 S3 콘텐츠를 스캔하는 핵심 요구 사항을 여전히 충족하지 못합니다.

문제 분석

핵심 개념: 이 질문은 Amazon S3의 민감한 데이터에 대한 데이터 검색 및 분류와 이벤트 기반 알림을 테스트합니다. S3에서 민감한 데이터(PHI/PII 패턴 포함)를 검색하고 보호하기 위해 특별히 구축된 AWS 서비스는 Amazon Macie입니다. Inspector는 S3 콘텐츠 검사가 아닌 취약성 관리(EC2, ECR, Lambda)를 위한 것입니다. 정답인 이유: Amazon Macie는 기계 학습 및 관리형 데이터 식별자를 사용하여 S3 객체를 지속적으로 평가하여 PHI 관련 요소에 매핑할 수 있는 개인 정보와 같은 민감한 데이터를 감지합니다. Macie가 결과를 생성하면 해당 결과는 Amazon EventBridge를 통해 라우팅할 수 있는 이벤트로 내보내집니다. SensitiveData 유형의 Macie 결과와 일치하는 EventBridge 규칙을 생성하고 Amazon SNS 알림을 보내면 규정 준수 팀(이메일, SMS, HTTPS 엔드포인트)에 즉각적인 푸시 기반 알림을 제공하여 "즉시 알림" 요구 사항을 충족합니다. 주요 AWS 기능 / 모범 사례: Macie는 S3 버킷에 대한 예약된 및 지속적인 검색 작업을 지원하여 새 객체가 도착하거나 기존 객체가 변경될 때 지속적인 스캔을 가능하게 합니다. 결과에는 심각도, 영향을 받는 버킷/객체 및 감지된 민감한 데이터 유형이 포함됩니다. EventBridge는 Macie 결과와 기본적으로 통합되어 세분화된 이벤트 패턴 필터링을 허용합니다. SNS는 사람이 대면하는 알림 및 여러 구독자에 대한 팬아웃을 위한 표준 서비스입니다. HIPAA에 부합하는 보안 태세를 위해 이를 S3 기본 암호화(SSE-KMS), 최소 권한 IAM 및 선택적으로 EventBridge에서 트리거되는 자동화된 수정(예: 태그/격리 접두사를 적용하는 Lambda)과 결합하십시오. 일반적인 오해: 자주 빠지는 함정은 Amazon Inspector도 "보안 스캔" 서비스이기 때문에 선택하는 것입니다. 그러나 Inspector는 PHI/PII에 대한 S3 객체 콘텐츠를 검사하지 않습니다. 소프트웨어 취약성 및 의도하지 않은 네트워크 노출을 식별합니다. 또 다른 함정은 "알림"에 SQS를 사용하는 것입니다. SQS는 사람에게 직접 알리는 것이 아니라 시스템 간의 분리 및 버퍼링을 위한 것입니다. 시험 팁: "S3에서 민감한 데이터 검색/분류" 또는 "PII/PHI 감지"가 보이면 Amazon Macie를 생각하십시오. "CVE, 패키지 취약성, EC2/ECR/Lambda 스캔"이 보이면 Amazon Inspector를 생각하십시오. 팀에 즉각적인 알림을 보내는 데는 일반적으로 SNS가 가장 적합합니다. SQS는 다운스트림 처리 워크플로에 더 적합합니다. 참조 (AWS 문서): Amazon Macie 결과 및 EventBridge 통합; SNS 알림; Inspector 지원 리소스 및 사용 사례.

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

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

6
문제 6

한 의료 기관이 의료 전문가들이 진단 이미지와 환자 문서를 업로드하는 환자 포털을 운영하고 있습니다. 이 기관은 의료 규정 준수를 유지하기 위해 부적절하거나 의료와 관련 없는 이미지가 업로드되는 것을 방지하는 자동화된 콘텐츠 필터링을 구현해야 합니다. 이 솔루션은 사용자 지정 기계 학습(machine learning) 모델 개발이나 훈련 없이 업로드된 이미지에서 부적절한 콘텐츠를 자동으로 감지하고 차단해야 합니다. 필터링은 웹 애플리케이션에 대한 지연 시간(latency) 영향을 최소화하면서 업로드 프로세스 중에 실시간으로 이루어져야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

Amazon SageMaker JumpStart는 사전 구축되었거나 foundation-model 기반 솔루션의 배포를 도울 수 있지만, 여전히 inference endpoint를 선택하고, 배포하고, 운영해야 합니다. 이는 이미 기본 제공 managed moderation API로 충족되는 요구 사항에 비해 더 많은 복잡성과 운영 오버헤드를 초래합니다. 문제에서는 custom model 개발이나 training이 필요하지 않다고 명시하고 있으므로, 이는 SageMaker보다 Rekognition을 강하게 선호하게 만듭니다. 기술적으로는 가능하지만, image moderation을 위한 가장 직접적이고, 가장 낮은 지연 시간이며, 가장 AWS-native한 솔루션은 아닙니다.

이 옵션은 Amazon Rekognition image moderation을 사용하여 custom model 개발이나 training 없이 부적절한 콘텐츠를 탐지합니다. AWS Lambda는 가벼운 serverless 통합 계층을 제공하므로 patient portal이 upload workflow 중에 moderation logic을 호출하고 즉시 수락 또는 거부 결정을 내릴 수 있습니다. Rekognition의 DetectModerationLabels API는 정지 이미지에서 노골적이거나 안전하지 않은 시각적 콘텐츠를 식별하도록 특별히 설계되었으며, 이는 요구 사항과 직접적으로 일치합니다. 이 접근 방식은 운영적으로 단순하고, 자동으로 확장되며, custom inference endpoint를 배포하고 유지 관리하는 복잡성을 피할 수 있습니다.

Amazon CloudFront Functions는 AI 서비스를 호출하거나 무거운 처리를 수행하기 위한 것이 아니라, 단순한 HTTP request 및 response 조작을 위한 매우 가벼운 edge function입니다. 이들은 Amazon Textract를 직접 호출할 수 없으며, Textract 자체도 부적절한 이미지 탐지가 아니라 OCR, form extraction, document text analysis를 위해 설계되었습니다. 이미지에서 텍스트를 추출할 수 있다고 하더라도, 그것만으로 이미지 콘텐츠 자체가 부적절한지 또는 비의료적인지 판단할 수는 없습니다. 이 옵션은 서비스 불일치와 실행 환경의 부적합성이라는 두 가지 이유로 잘못되었습니다.

Amazon Rekognition Video는 web portal을 통해 업로드된 정지 이미지가 아니라 video 파일 또는 stream을 분석하기 위한 서비스입니다. 문제는 구체적으로 업로드된 이미지를 다루고 있으므로, 올바른 Rekognition 기능은 video analysis가 아니라 image moderation입니다. 또한 S3-triggered Lambda는 객체가 이미 업로드된 후에 실행되므로, upload transaction 중 실시간 차단을 본질적으로 제공하지 않습니다. 따라서 이 옵션은 media type과 timing requirement 모두에 적합하지 않습니다.

문제 분석

개요: 핵심 개념: 이 질문은 사용자 지정 ML 모델을 구축하거나 훈련하지 않고 실시간 콘텐츠 조정을 위해 관리형 AI 서비스를 사용하는 방법을 테스트합니다. Amazon Rekognition은 업로드 시 필터링에 일반적으로 사용되는 명시적이거나 부적절한 시각적 콘텐츠를 식별하기 위한 내장 DetectModerationLabels API를 제공합니다. 정답인 이유: 옵션 B는 업로드 워크플로 중에 AWS Lambda를 사용하여 Amazon Rekognition 조정 API를 호출하므로 애플리케이션이 거의 실시간으로 이미지를 수락/거부할 수 있습니다. 이는 사용자 지정 모델 개발/훈련이 필요 없고, 자동화된 감지 및 차단이 가능하며, 동기식으로 구현될 때 지연 시간 영향을 최소화한다는 요구 사항을 충족합니다(예: 사전 서명된(pre-signed) 업로드 + 업로드 후 검증 게이트, 또는 객체를 사용 가능하게 만들기 전에 즉각적인 검증을 수행하는 수집 버킷으로의 직접 업로드). 주요 AWS 기능: - Amazon Rekognition DetectModerationLabels: 이미지를 위한 관리형 조정 모델; 허용/거부 결정을 내리기 위한 레이블과 신뢰도 점수를 반환합니다. - AWS Lambda: 검증 로직을 위한 서버리스 실행; 업로드 볼륨에 따라 자동으로 확장됩니다. - API Gateway: 포털이 검증을 호출할 수 있는 짧은 지연 시간의 HTTPS 엔드포인트를 제공합니다. - 모범 사례 패턴: 격리/수집 위치로 업로드(또는 사전 서명된 URL 사용)하고, 조정을 실행한 다음, 승인된 객체로 이동/태그 지정(승인된 버킷/접두사로 복사, 객체 태그/메타데이터 추가)하거나 삭제/격리하고 다운스트림 액세스를 차단합니다. 이는 최소 권한 및 감사 가능성(의료 분야에서 중요)과 일치합니다. 일반적인 오해: - "모든 ML 서비스가 작동한다": Textract는 OCR용이며 조정용이 아닙니다. Rekognition Video는 정지 이미지가 아닌 비디오 스트림/파일용입니다. SageMaker JumpStart는 여전히 엔드포인트를 배포/운영하고 모델을 선택/조정해야 함을 의미하므로 필요한 것보다 더 복잡합니다. 시험 팁: "부적절한 콘텐츠 감지" + "사용자 지정 훈련 없음"을 보면 Amazon Rekognition 조정 레이블을 생각하십시오. "업로드 중 실시간"의 경우 동기식 호출 패턴(API Gateway/Lambda) 또는 콘텐츠에 액세스하기 전에 즉각적인 게이팅이 있는 수집 버킷을 선택하십시오. 또한 서비스 적합성에 유의하십시오: Rekognition(이미지), Rekognition Video(비디오), Textract(텍스트 추출), SageMaker(사용자 지정/관리형 ML 배포).

7
문제 7

한 금융 서비스 회사가 주식 시장 데이터를 처리하는 실시간 거래 플랫폼을 운영하고 있습니다. 거래 데이터는 8 vCPU 및 32 GB RAM을 갖춘 Amazon RDS PostgreSQL DB instance에 저장됩니다. 거래 피크 시간대(오전 9시 - 오후 4시) 동안 시스템은 거래 실행을 처리하는 동시에 시장 분석을 위한 과도한 읽기 작업을 겪습니다. 데이터베이스 팀은 데이터베이스 작업의 75%가 거래 보고서 및 시장 분석 생성을 위한 읽기 쿼리임을 확인했습니다. 현재 단일 데이터베이스 instance는 피크 시간대에 85%의 CPU utilization을 겪고 있으며, 이로 인해 쿼리 응답 시간이 50ms에서 300ms로 증가하고 있습니다. 최소한의 인프라 변경으로 데이터베이스 성능을 향상시키고 쿼리 응답 시간을 단축하기 위해 solutions architect는 무엇을 권장해야 합니까?

오답입니다. Multi-AZ는 주로 고가용성 및 자동 failover를 위한 것이며 읽기 확장을 위한 것이 아닙니다. 표준 RDS Multi-AZ에서 standby는 트래픽을 수락할 수 없으므로 쓰기나 읽기에 사용할 수 없습니다. 읽기를 primary로, 쓰기를 standby로 전달하는 것은 지원되지 않으며 지연 시간 증가를 유발하는 읽기 주도 CPU 병목 현상을 해결하지 못합니다.

오답입니다. 이 옵션은 Multi-AZ deployment의 standby가 읽기 트래픽을 처리할 수 있다고 가정합니다. 표준 Amazon RDS Multi-AZ에서 standby는 읽을 수 없으며 failover 목적으로만 유지됩니다. 따라서 분석 읽기를 standby로 오프로드할 수 없으며, primary는 피크 거래 시간 동안 계속해서 CPU 제약을 받게 됩니다.

Read Replica는 RDS primary instance의 읽기 위주 워크로드를 오프로드하는 올바른 메커니즘입니다. 75%에 달하는 분석/보고서 쿼리를 read replica로 라우팅하면 primary의 CPU 부하(현재 85%)를 직접적으로 해소하여 primary가 쓰기 작업(거래 실행)에 집중할 수 있게 됩니다. 더 작은 사양(4 vCPU/16 GB)으로 시작하는 것은 '최소한의 인프라 변경' 요건을 충족하며, 복제본 사양은 독립적으로 조정할 수 있어 ReplicaLag나 CPU 지표에 따라 필요 시 scale up 또는 추가 복제본 생성이 가능합니다. 이는 RDS 읽기/쓰기 분리의 표준 AWS 패턴이며 Well-Architected Performance Efficiency 원칙에 부합합니다.

부분적으로 합리적이지만 '최소한의 인프라 변경'을 고려할 때 최선의 선택은 아닙니다. read replica는 맞지만, primary 크기(8 vCPU/32 GB)와 일치시키는 것은 불필요할 수 있으며 더 작은 복제본이 분석 워크로드를 충족하지 못한다는 증거 없이 비용만 증가시킵니다. 더 나은 접근 방식은 더 작은 복제본으로 시작하여 성능/지연을 모니터링하고 필요한 경우에만 scale up/out하는 것입니다.

문제 분석

핵심 개념: 이 질문은 읽기 작업이 많은 워크로드에 대한 Amazon RDS PostgreSQL 확장 패턴을 테스트합니다. 핵심 개념은 주로 고가용성을 위한 Multi-AZ에 의존하는 대신, RDS Read Replica를 사용하여 쓰기 확장과 읽기 확장(수평적)을 분리하는 것입니다. 정답인 이유: 워크로드의 75%가 읽기(분석/보고서)이며, 피크 시간대에 primary instance가 CPU 바운드(85%) 상태가 되어 지연 시간이 증가합니다. read replica를 생성하고 분석/읽기 전용 쿼리를 해당 복제본으로 라우팅하면 primary instance의 CPU 및 I/O 부하를 덜어주어, primary가 쓰기 트랜잭션(거래 실행) 및 중요한 읽기에 집중할 수 있게 됩니다. 이는 최소한의 인프라 변경으로 병목 현상을 직접적으로 해결합니다: 복제본을 추가하고 애플리케이션의 연결 라우팅을 업데이트합니다(또는 reader endpoint/proxy 패턴 사용). 주요 AWS 기능: PostgreSQL용 RDS Read Replica는 primary로부터의 비동기식 복제를 사용합니다. 읽기 트래픽을 분산시켜 읽기 처리량을 확장하고 writer의 읽기 지연 시간을 줄이도록 설계되었습니다. 하나 이상의 복제본을 생성하고 크기를 독립적으로 조정할 수 있습니다. 최소한의 변경과 비용 효율성을 위해 더 작은 복제본(4 vCPU/16 GB)으로 시작하는 것이 합리적입니다. 복제본의 CPU/지연을 모니터링하고 필요에 따라 scale up하거나 더 많은 복제본을 추가할 수 있습니다. 이는 AWS Well-Architected Performance Efficiency와 일치합니다: 관리형 서비스를 사용하고 읽기 위주의 패턴에 대해 scale-out을 수행합니다. 일반적인 오해: Multi-AZ는 종종 읽기 확장 기능으로 오해받습니다. 표준 RDS Multi-AZ에서 standby는 읽을 수 없으며 failover를 위해 존재합니다. 따라서 읽기를 standby로 전달할 수 없습니다. Multi-AZ DB cluster 변형에서도 질문의 옵션들은 읽기 라우팅에 대해 고전적인 'standby instance' 동작을 잘못 설명하고 있습니다. 따라서 Multi-AZ는 요구되는 방식으로 primary의 피크 읽기 CPU를 줄이지 못합니다. 시험 팁: RDS에서 '대부분 읽기' + '높은 CPU/지연 시간'을 보면 Read Replica와 읽기/쓰기 분리를 생각하십시오. '가용성/failover/RTO/RPO'를 보면 Multi-AZ를 생각하십시오. 또한 복제본 크기 조정은 유연하다는 점에 유의하십시오. 성능 목표를 충족하는 가장 작은 변경을 선택하고 CPUUtilization, ReadIOPS 및 ReplicaLag와 같은 지표를 기반으로 반복(scale up/out)할 수 있습니다.

8
문제 8

금융 기술 스타트업이 AWS에 안전한 거래 플랫폼을 구축하고 있습니다. 아키텍처는 규정 준수 및 내결함성을 위해 3개의 가용 영역(Availability Zones)에 걸쳐 퍼블릭 및 프라이빗 서브넷이 모두 있는 VPC를 요구합니다. 퍼블릭 서브넷은 로드 밸런서와 배스천 호스트를 호스팅하고, 프라이빗 서브넷은 핵심 거래 애플리케이션 서버와 데이터베이스 인스턴스를 포함합니다. 프라이빗 서브넷의 거래 애플리케이션 서버는 중요한 보안 패치를 다운로드하고, 외부 시장 데이터 피드에 연결하며, 타사 결제 프로세서와 통신하기 위해 인터넷 연결이 필요합니다. 그러나 보안상의 이유로 이러한 서버는 인터넷에서 직접 액세스할 수 없어야 합니다. 솔루션 아키텍트는 최고 수준의 가용성을 유지하면서 프라이빗 서브넷의 거래 애플리케이션 서버에 안전한 아웃바운드 인터넷 액세스를 제공하기 위해 무엇을 구현해야 합니까?

정답입니다. 각 퍼블릭 서브넷(AZ당 하나)에 NAT 게이트웨이를 배포하고 각 프라이빗 서브넷을 로컬 NAT 게이트웨이로 라우팅하는 것은 고가용성 및 장애 격리를 위한 AWS 모범 사례입니다. NAT 게이트웨이는 관리형이며 AZ 내에서 자동으로 확장됩니다. AZ 로컬 라우팅은 교차 AZ 이그레스를 방지하고 지연 시간을 줄이며 한 AZ에 장애가 발생하더라도 다른 AZ가 아웃바운드 연결을 유지하도록 보장합니다.

오답입니다. NAT 인스턴스는 아웃바운드 액세스를 제공할 수 있지만 패치 적용, 확장 및 신중한 구성(소스/대상 확인 비활성화, 보안 그룹, 장애 조치 스크립트)이 필요한 자체 관리형 EC2 인스턴스입니다. NAT 디바이스는 IGW를 통해 인터넷에 도달할 수 있어야 하며, 이를 위해서는 일반적으로 퍼블릭 IP/EIP가 있는 퍼블릭 서브넷에 있어야 하므로 프라이빗 서브넷에 배치하는 것도 잘못되었습니다.

오답입니다. 인터넷 게이트웨이를 서브넷에 연결할 수 없습니다. IGW는 VPC에 연결됩니다. 또한 프라이빗 서브넷을 IGW로 직접 라우팅하면 (인스턴스에 퍼블릭 IP가 있는 경우) 사실상 퍼블릭 서브넷이 되며 거래 애플리케이션 서버가 인터넷에서 직접 액세스할 수 없어야 한다는 요구 사항을 위반합니다. "보조 IGW"는 이 목적에 유효한 구성 요소가 아닙니다.

오답입니다. 외부 전용 인터넷 게이트웨이는 인바운드 시작 연결을 차단하면서 아웃바운드 전용 인터넷 액세스를 허용하기 위해 IPv6에 사용됩니다. 대부분의 패치 리포지토리, 시장 데이터 피드 및 타사 엔드포인트가 일반적으로 사용하는 IPv4 NAT 기능을 제공하지 않습니다. 또한 외부 전용 IGW는 VPC에 연결되며(서브넷에 배치되지 않음) IPv4용 NAT 게이트웨이를 대체하지 않습니다.

문제 분석

핵심 개념: 이 질문은 여러 가용 영역(AZ)에 걸쳐 고가용성을 유지하면서 NAT(Network Address Translation)를 사용하여 프라이빗 서브넷에서 안전한 아웃바운드 인터넷 액세스를 테스트합니다. AWS에서 프라이빗 서브넷은 인터넷 게이트웨이(IGW)에 대한 라우팅을 가질 수 없으며 여전히 "프라이빗" 상태를 유지합니다. 대신 퍼블릭 서브넷의 NAT 디바이스를 사용하여 원치 않는 인바운드 인터넷 액세스를 방지하면서 아웃바운드 연결을 시작합니다. 정답인 이유: 옵션 A(AZ별 NAT 게이트웨이 및 AZ 로컬 라우팅)는 가장 높은 가용성과 모범 사례 설계를 제공합니다. NAT 게이트웨이는 AZ 내에서 AWS가 관리하는 고가용성 서비스입니다. AZ당 하나의 NAT 게이트웨이를 배포하고 각 프라이빗 서브넷의 0.0.0.0/0 트래픽을 동일한 AZ의 NAT 게이트웨이로 라우팅하면 교차 AZ 종속성을 피할 수 있습니다. 한 AZ에 장애가 발생하더라도 다른 AZ의 프라이빗 서브넷은 여전히 로컬 NAT 게이트웨이를 통해 아웃바운드 액세스를 가지므로 내결함성 및 규정 기대치를 충족합니다. 주요 AWS 기능 / 구성: - IGW에 대한 기본 경로(0.0.0.0/0)가 있는 퍼블릭 서브넷에 NAT 게이트웨이를 배치합니다. - 프라이빗 서브넷 라우팅 테이블은 0.0.0.0/0을 NAT 게이트웨이(IGW가 아님)로 보내야 합니다. - AZ 선호도를 보장하기 위해 프라이빗 서브넷당(또는 AZ당) 하나의 라우팅 테이블을 사용합니다. - NAT 게이트웨이는 자동으로 확장되고 관리되므로 자체 관리형 NAT 인스턴스에 비해 운영 위험이 줄어듭니다. - 보안 태세: 인스턴스는 퍼블릭 IP 없이 유지됩니다. NAT는 아웃바운드 시작 흐름을 위한 것이므로 인터넷에서의 인바운드는 불가능합니다. 일반적인 오해: - "NAT 인스턴스는 동일하다": 패치 적용, 확장, 장애 조치 자동화가 필요하며 병목 현상이 될 수 있습니다. 거래 플랫폼에는 바람직하지 않습니다. - "프라이빗 서브넷에 IGW 연결": IGW는 서브넷이 아닌 VPC에 연결되며, 프라이빗 서브넷을 IGW로 라우팅하면 퍼블릭 IP가 있는 경우 퍼블릭 서브넷이 됩니다. - "외부 전용 IGW가 해결한다": 외부 전용 IGW는 IPv6 아웃바운드 전용 트래픽을 위한 것이며 IPv4의 NAT를 대체하지 않습니다. 시험 팁: 다중 AZ 프라이빗 서브넷 아웃바운드 인터넷의 경우 시험에서 선호하는 패턴은 "AZ당 NAT 게이트웨이 + 동일한 AZ NAT로의 프라이빗 서브넷 라우팅"입니다. 기억하십시오: IGW는 퍼블릭 서브넷용이고 NAT는 프라이빗 서브넷 이그레스(IPv4)용입니다. 외부 전용 IGW는 특별히 IPv6용입니다.

9
문제 9

한 스타트업 회사가 콘텐츠 제작자가 비디오를 업로드하고 다양한 템플릿과 효과가 있는 사용자 지정 썸네일을 자동으로 생성할 수 있는 비디오 썸네일 생성 플랫폼을 개발했습니다. 사용자는 적용하려는 썸네일 스타일, 타임스탬프 및 오버레이 효과를 지정하는 구성 데이터와 함께 비디오 파일을 업로드합니다. 이 플랫폼은 현재 단일 Amazon EC2 instance에서 실행되며 구성 메타데이터를 저장하기 위해 Amazon DynamoDB를 사용합니다. 플랫폼이 스트리머와 유튜버 사이에서 인기를 얻음에 따라 사용자 트래픽이 상당한 변동을 겪고 있습니다. 콘텐츠 제작자가 가장 활동적인 저녁 시간(오후 8-11시)과 주말에 최대 사용량이 발생합니다. 회사는 비수기 50명의 동시 사용자에서 피크 시간대 2000명 이상의 동시 사용자에 이르는 다양한 워크로드를 처리하기 위해 플랫폼이 자동으로 확장(scale)될 수 있도록 보장해야 합니다. 이 비디오 썸네일 생성 플랫폼의 확장성 요구 사항을 가장 잘 충족하는 솔루션은 무엇입니까?

Lambda는 버스트 워크로드에 좋은 컴퓨팅 선택이지만 DynamoDB는 비디오 파일을 저장하는 데 적합하지 않습니다. DynamoDB는 400KB의 항목 크기 제한이 있으며 대용량 바이너리가 아닌 키-값/문서 메타데이터에 최적화되어 있습니다. 비디오를 청크로 나누더라도 비용과 복잡성이 높고 성능을 예측할 수 없습니다. 이 옵션은 대용량 업로드 미디어에 대한 스토리지 요구 사항을 충족하지 못합니다.

Kinesis Data Firehose는 선택적인 경량 변환을 통해 S3, Redshift 또는 OpenSearch와 같은 대상으로 스트리밍 데이터를 수집하고 전송하도록 설계되었습니다. 범용 비디오 처리 서비스가 아니며 임의의 썸네일 생성 워크로드를 실행하지 않습니다. 또한 구성 메타데이터를 기본 데이터베이스로 저장하기 위한 것이 아닙니다. 이 옵션은 워크로드 유형과 일치하지 않습니다.

S3는 대규모로 업로드된 비디오 객체를 저장하고 프로비저닝 없이 트래픽 스파이크를 처리하기 위한 올바른 서비스입니다. Lambda는 업로드를 처리(종종 S3 이벤트에 의해 트리거됨)하고 썸네일을 생성하기 위해 자동으로 scale out할 수 있습니다. DynamoDB는 on-demand/auto scaling capacity를 갖춘 구성 메타데이터에 여전히 이상적입니다. 이 조합은 변동성이 큰 수요에 대해 탄력성, 내구성 및 최소한의 운영을 제공합니다.

EC2 instance를 5개로 고정적으로 늘리는 것은 50명에서 2000명 이상의 동시 사용자로의 자동 확장을 제공하지 않습니다. 피크 수요를 충족하지 못할 가능성이 높으며 비수기에는 용량을 낭비합니다. EBS volume은 연결된 스토리지이며 추가 아키텍처 없이는 instance 간 업로드를 위한 확장 가능한 공유 리포지토리가 아닙니다. 이 접근 방식은 관리형/서버리스 옵션에 비해 운영 부담을 증가시키고 복원력을 감소시킵니다.

문제 분석

핵심 개념: 이 질문은 관리형 서비스를 사용하여 스파이크가 있는 워크로드를 위한 복원력 있고 자동으로 확장되는 이벤트 기반 아키텍처를 설계하는 것을 테스트합니다. 핵심 패턴은 수집(객체 스토리지)을 처리(서버리스 컴퓨팅)에서 분리하면서 메타데이터를 지연 시간이 짧은 데이터베이스에 유지하는 것입니다. 정답인 이유: 옵션 C(비디오용 Lambda + S3 + 구성 메타데이터용 DynamoDB)는 큰 변동과 함께 약 50명에서 2000명 이상의 동시 사용자로 확장해야 하는 요구 사항과 가장 잘 일치합니다. Amazon S3는 업로드된 비디오 객체를 위해 사실상 무제한의 내구성이 뛰어난 스토리지를 제공하며 사전 프로비저닝 없이 트래픽 스파이크를 자연스럽게 흡수합니다. AWS Lambda는 이벤트(예: S3 ObjectCreated 이벤트 또는 S3에 쓰고 처리를 트리거하는 API 계층을 통해)당 함수를 호출하여 수평으로 확장할 수 있습니다. DynamoDB는 짧은 지연 시간의 액세스와 수요에 따라 처리량(on-demand 또는 auto scaling)을 확장할 수 있는 기능으로 인해 구성 메타데이터에 여전히 매우 적합합니다. 주요 AWS 기능: - Amazon S3: 내구성 있는 객체 스토리지(11개의 9 내구성), 높은 요청 속도, 처리를 트리거하는 이벤트 알림. - AWS Lambda: 자동 확장, 사용한 만큼만 지불, 다운스트림 시스템을 보호하기 위한 동시성 제어(reserved concurrency). - DynamoDB: on-demand capacity 또는 auto scaling, 임시 작업/구성 레코드를 위한 TTL, 추가 이벤트가 필요한 경우 Streams. - (일반적인 실제 개선 사항) 옵션에서 요구하지는 않지만 S3와 Lambda 사이에 SQS를 추가하여 버스트를 버퍼링하고 동시성을 제어합니다. 일반적인 오해: 옵션 A는 Lambda가 확장되기 때문에 매력적으로 보이지만 대용량 비디오 바이너리를 DynamoDB에 저장하는 것은 적합하지 않습니다. DynamoDB에는 항목 크기 제한(400KB)이 있으며 대용량 객체 스토리지를 위한 것이 아닙니다. 옵션 B는 스트리밍 데이터를 대상(S3, OpenSearch, Redshift)으로 전송하기 위한 것이지 일반적인 비디오 처리 워크플로를 위한 것이 아닌 Kinesis Data Firehose를 잘못 사용합니다. 옵션 D는 고전적인 "EC2 scale up/scale out"이지만 5개의 instance로 구성된 고정 플릿은 2000명 이상의 동시 사용자를 안정적으로 처리하지 못하며 EBS는 확장 가능한 공유 업로드 저장소가 아닙니다. 또한 운영 오버헤드를 증가시키고 탄력성을 감소시킵니다. 시험 팁: 수요가 급증하는 미디어/파일 업로드 워크로드의 경우 객체는 S3, 메타데이터는 DynamoDB, 처리는 Lambda(또는 컨테이너 서비스)를 기본으로 사용하십시오. DynamoDB 크기 제한에 주의하고 Firehose를 컴퓨팅 엔진이 아닌 스트리밍 레코드를 위한 전송/ETL로 인식하십시오. "큰 변동에 따른 자동 확장"이 보이면 일반적으로 서버리스 + 관리형 스토리지가 의도된 정답입니다.

10
문제 10

한 금융 서비스 회사가 AWS 인프라에서 거래 플랫폼을 운영하고 있습니다. 이 회사는 서드파티 금융 데이터 제공업체로부터 실시간 시장 데이터에 액세스하기 위해 보안 연결을 설정해야 합니다. 데이터 제공업체는 AWS의 자체 전용 VPC에서 시장 데이터 서비스를 호스팅합니다. 회사의 규정 준수 팀에 따르면, 연결은 완전히 프라이빗하게 유지되어야 하며 특정 시장 데이터 서비스로만 제한되어야 합니다. 또한 감사 추적 목적을 위해 모든 연결은 오직 금융 회사의 VPC에서만 시작되어야 합니다. 이러한 보안 및 연결 요구 사항을 충족하는 솔루션은 무엇입니까?

VPC peering은 두 VPC 간에 프라이빗 IP 연결을 제공하지만 이는 네트워크 수준의 액세스입니다. 라우팅 및 보안 규칙이 허용되면 소비자는 단일 시장 데이터 서비스뿐만 아니라 제공업체 VPC의 많은 리소스에 잠재적으로 도달할 수 있습니다. 이는 특정 서비스로만 연결을 제한해야 한다는 요구 사항을 충족하지 못하며, 더 넓은 영향 범위(blast radius)로 인해 규제 환경에서 종종 허용되지 않습니다.

virtual private gateway(VGW)는 AWS PrivateLink가 아닌 Site-to-Site VPN 또는 Direct Connect에 사용됩니다. PrivateLink는 제공업체 측에 VGW를 요구하지 않으며, NLB가 지원하는 VPC endpoint service가 필요합니다. 이 옵션은 프라이빗 연결 메커니즘(VPN/DX)과 서비스 수준 프라이빗 액세스(PrivateLink) 간의 일반적인 혼동을 반영합니다.

NAT gateway는 private subnet의 인스턴스가 퍼블릭 IP를 통해 인터넷으로 아웃바운드 연결을 시작할 수 있게 해줍니다. 서드파티 VPC 서비스에 대한 프라이빗 연결을 생성하지 않으며, 일반적으로 퍼블릭 인터넷을 통해 트래픽을 라우팅합니다(대상이 AWS에 있더라도). 이는 "완전히 프라이빗" 요구 사항을 위반하며 특정 서비스에만 액세스를 제한하지 않습니다.

이것이 올바른 접근 방식입니다. 제공업체는 시장 데이터 애플리케이션을 PrivateLink endpoint service로 노출하고, 금융 회사는 이를 소비하기 위해 interface VPC endpoint를 생성합니다. 연결은 프라이빗하고 AWS 네트워크에 유지되며, 제공업체의 전체 VPC가 아닌 해당 특정 서비스로 범위가 제한됩니다. 모든 세션은 소비자 VPC에서 endpoint ENI로 시작되므로 감사 요구 사항을 지원합니다.

문제 분석

핵심 개념: 이 문제는 VPC 간의 private하고 service-specific한 연결을 위해 AWS PrivateLink를 테스트하며, 특히 다른 AWS account 또는 VPC에 호스팅된 third-party service를 사용할 때를 다룹니다. 정답인 이유: 요구 사항은 완전히 private한 연결, 특정 market data service로만 제한된 액세스, 그리고 금융 회사의 VPC에서만 시작되는 연결입니다. AWS PrivateLink는 정확히 이러한 패턴을 위해 설계되었습니다. service provider는 애플리케이션을 VPC endpoint service로 게시하고, consumer는 자신의 VPC에 interface VPC endpoint를 생성합니다. 이렇게 하면 provider의 전체 VPC를 노출하지 않아도 되며, 모든 트래픽이 public internet를 통과하지 않고 AWS backbone에 머물게 됩니다. 선택지 D에서는 provider가 “VPC endpoint”를 생성해야 한다고 되어 있지만, 의도된 그리고 기술적으로 올바른 모델은 provider가 VPC endpoint service를 생성하고 consumer가 VPC endpoint를 생성하는 것입니다. 주요 AWS 기능 / 구성: - Provider 측: Network Load Balancer를 기반으로 하는 VPC endpoint service를 생성하고, 필요에 따라 consumer 연결에 대한 acceptance를 요구할 수 있습니다. - Consumer 측: 회사 VPC에 interface VPC endpoint를 생성하고 access 제어를 위해 security group을 연결합니다. - DNS: private DNS를 사용하여 consumer VPC 내에서 service가 private IP address로 확인되도록 할 수 있습니다. - Compliance 및 audit: 트래픽은 AWS private networking 내부에 머물며, CloudTrail과 VPC Flow Logs는 auditing 및 monitoring 지원에 도움이 될 수 있습니다. 흔한 오해: VPC peering도 private하지만, 단일 service에 대한 액세스로 제한하는 대신 VPC 간 network-level 연결을 활성화하므로 범위가 너무 넓습니다. NAT gateway는 internet egress용이지, VPC 간 private service consumption용이 아닙니다. Virtual private gateway는 VPN 또는 Direct Connect에 사용되며, PrivateLink 구현용이 아닙니다. 시험 팁: 문제에서 다른 VPC의 third-party service를 언급하고, private connectivity를 요구하며, 오직 하나의 application 또는 service로만 제한된 액세스를 원한다면 AWS PrivateLink가 보통 가장 좋은 정답입니다. service-level isolation과 consumer-initiated access가 필요할 때는 VPC peering보다 PrivateLink를 우선하세요. 용어에 주의하세요. provider는 endpoint service를 생성하고, consumer는 interface endpoint를 생성합니다.

합격 후기(31)

이
이**Apr 25, 2026

학습 기간: 1 month

시험문제보다 난이도가 있는편이고 같은문제도 조금 나왔습니다

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한 지문들 다시 확인하니까 문제 없었습니다.

다른 모의고사

Practice Test #1

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

Practice Test #2

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

Practice Test #3

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.