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

Practice Test #9

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

한 의료 기술 회사가 Amazon RDS for PostgreSQL 데이터베이스에 의료 기록과 영상 데이터를 저장하는 환자 관리 시스템을 운영하고 있습니다. 이 데이터베이스에는 관련 메타데이터와 함께 1,500만 개 이상의 환자 기록이 포함되어 있습니다. 데이터베이스는 3TB의 General Purpose SSD 스토리지를 사용하며, 환자 데이터 업데이트, 예약 일정 관리, 의료 기록 삽입을 위해 병원과 클리닉에서 발생하는 매일 수백만 건의 트랜잭션을 처리합니다. 최근 성능 모니터링에 따르면 신규 환자 등록 작업이 완료되는 데 12~15초가 걸려 사용자 경험에 큰 영향을 미치고 있습니다. 분석 결과 데이터베이스 스토리지 I/O 성능이 병목 현상의 원인으로 확인되었습니다. 이 스토리지 성능 문제를 가장 효과적으로 해결할 수 있는 솔루션은 무엇입니까?

Provisioned IOPS SSD(io1/io2)로 변경하면 명시된 병목 현상인 스토리지 I/O를 직접 해결할 수 있습니다. io1/io2를 사용하면 지속적인 IOPS를 프로비저닝하고 General Purpose SSD보다 더 일관되고 지연 시간이 짧은 디스크 성능을 달성할 수 있습니다. 느린 삽입/등록이 있는 대규모(3TB) 및 트랜잭션이 많은 PostgreSQL RDS 워크로드의 경우, 이는 I/O 대기 시간을 줄이기 위한 가장 타겟팅되고 효과적인 개선 사항입니다.

Memory-optimized instance(r5/r6i)는 병목 현상이 CPU, 메모리 압박 또는 캐시 적중률(예: 더 많은 데이터가 버퍼 캐시에 들어감)인 경우 도움이 될 수 있습니다. 그러나 질문에서는 스토리지 I/O가 병목 현상임을 확인합니다. 워크로드가 이미 디스크를 기다리고 있는 경우 RAM/CPU를 추가하면 미미한 이점만 제공할 수 있으며 느린 쓰기 트랜잭션을 수정하는 데 필요한 예측 가능한 IOPS 증가를 제공하지 않습니다.

Burstable instance(t3/t4g)는 간헐적인 CPU 버스트가 있는 가변 워크로드를 위한 것이며 일반적으로 크고 지속적으로 바쁜 프로덕션 데이터베이스에는 권장되지 않습니다. EBS 스토리지 I/O 병목 현상을 해결하지 못하며 CPU 크레딧이 소진될 경우 추가적인 위험을 초래할 수 있습니다. 매일 수백만 건의 트랜잭션이 발생하는 의료 OLTP 시스템의 경우 이 옵션은 비효율적이고 운영상 위험합니다.

Multi-AZ는 동기식 대기 복제 및 자동 장애 조치를 통해 가용성과 내구성을 향상시키지만 primary 쓰기 I/O 성능을 증가시키지는 않습니다. 경우에 따라 동기식 복제로 인해 쓰기 커밋 지연 시간이 추가될 수 있습니다. Read replica는 읽기 트래픽을 확장할 수 있지만 primary의 신규 환자 등록과 같이 쓰기 작업이 많은 작업을 가속화하지는 않습니다. 이 옵션은 식별된 스토리지 I/O 병목 현상이 아니라 복원력/읽기 확장을 목표로 합니다.

문제 분석

핵심 개념: 이 질문은 Amazon RDS 스토리지 성능 튜닝, 특히 EBS 기반 RDS 스토리지 유형(General Purpose SSD 대 Provisioned IOPS SSD)이 쓰기 작업이 많은 OLTP 워크로드의 I/O 지연 시간 및 처리량에 미치는 영향을 테스트합니다. 정답인 이유: 모니터링 및 분석에서 스토리지 I/O가 병목 현상임을 명시적으로 식별했으며, 워크로드에는 느린 삽입/등록 작업(쓰기 경로)이 포함된 매일 수백만 건의 트랜잭션이 포함됩니다. 3TB의 General Purpose SSD(gp2/gp3)를 사용하면 스토리지의 IOPS/처리량 특성에 의해 성능이 제한됩니다. Provisioned IOPS SSD(io1/io2)는 I/O 집약적이고 지연 시간에 민감한 데이터베이스를 위해 설계되었으며, 더 예측 가능한 성능으로 높은 IOPS를 프로비저닝하고 유지할 수 있게 해줍니다. io1/io2로 직접 이동하는 것은 확인된 병목 현상을 타겟팅하며 I/O 대기 시간을 줄이고 트랜잭션 지연 시간을 개선하는 가장 효과적인 단일 변경 사항입니다. 주요 AWS 기능: - RDS 스토리지 유형: General Purpose SSD는 비용 효율적이지만 크고 바쁜 OLTP 시스템에 충분한 지속적 IOPS를 제공하지 못할 수 있습니다. Provisioned IOPS SSD는 일관되고 높은 IOPS를 제공합니다. - io2(및 지원되는 경우 io2 Block Express)는 대규모에서 io1보다 더 높은 내구성과 더 나은 가격/성능을 제공하며, 중요한 프로덕션 데이터베이스에 일반적으로 권장됩니다. - 스토리지 확장 및 성능 튜닝: 워크로드 수요에 맞게 RDS 스토리지 유형 및 프로비저닝된 IOPS(엔진/인스턴스 제한 내)를 수정할 수 있습니다. 일반적인 오해: 쿼리가 느릴 때 DB instance를 "스케일 업"(더 많은 RAM/CPU)하고 싶을 수 있지만, 병목 현상이 스토리지 I/O인 경우 추가 메모리/CPU는 종종 제한적인 개선만 가져옵니다. 마찬가지로 Multi-AZ/read replica는 가용성과 읽기 확장을 개선하지만, 스토리지 제약으로 인한 기본 쓰기 지연 시간은 개선하지 않습니다. 시험 팁: 질문에서 병목 현상이 스토리지 I/O라고 명시하는 경우, instance class 변경보다 스토리지 유형 변경(Provisioned IOPS, 처리량/IOPS 프로비저닝)을 우선시하십시오. RDS에서 쓰기 작업이 많은 OLTP의 경우, io1/io2는 예측 가능하고 지연 시간이 짧은 I/O를 위한 정답입니다. 또한 기억하십시오: Multi-AZ는 HA/장애 조치를 위한 것이고, read replica는 읽기 확장을 위한 것입니다. 둘 다 EBS I/O 제한으로 인한 primary의 느린 쓰기를 수정하지 않습니다.

2
문제 2
(2개 선택)

한 온라인 교육 플랫폼이 Amazon EC2에서 학습 관리 시스템(LMS)을 운영하고 있습니다. LMS는 단일 EC2 instance에서 실행되며 코스 데이터 및 학생 기록을 저장하기 위해 Amazon Aurora PostgreSQL Multi-AZ DB instance를 사용합니다. 코스 비디오 및 교육 자료는 EC2 instance 내부에 마운트된 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장됩니다. 이 플랫폼은 5,000명 이상의 동시 접속 학생이 코스 자료에 접근하는 등록 피크 기간 동안 성능 병목 현상을 겪습니다. 회사는 트래픽 급증을 처리하기 위해 시스템 성능을 개선하고 고가용성을 보장해야 합니다. 학습 플랫폼의 성능과 복원력을 개선하기 위해 솔루션 아키텍트가 취해야 할 작업 조합은 무엇입니까? (2개 선택)

비디오/자료를 S3로 이동하는 것은 내구성과 확장성 측면에서 방향적으로 좋지만 "모든 EC2 instance에 마운트됨"은 위험 신호입니다. S3는 API/SDK를 통해 접근하는 객체 스토리지이며 일반적인 시험 시나리오를 위한 네이티브 공유 POSIX 파일 시스템 마운트가 아닙니다. EC2 Auto Scaling 아키텍처에서 EBS에 대한 더 올바른 공유 파일 대체재는 Amazon EFS이거나 마운트 없이 CloudFront+S3를 사용하는 것입니다.

기본 EC2 instance에서 NFS 공유를 내보내고 다른 instance에 마운트하면 주요 단일 장애 점과 확장 병목 현상(네트워크, 디스크, instance 제한)이 발생합니다. 기본 instance가 실패하거나 과부하가 걸리면 모든 instance가 코스 자료에 대한 접근 권한을 잃습니다. 이는 고가용성 및 복원력 요구 사항을 충족하지 않으며 AWS 관리형 모범 사례가 아닙니다.

Amazon EFS는 여러 EC2 instance가 동시에 접근해야 하는 공유 코스 자료를 저장하기 위한 올바른 관리형 대체재입니다. EFS는 다중 AZ이며 Auto Scaling group의 많은 instance에 마운트될 수 있어 단일 instance EBS 제약을 제거합니다. 이는 복원력(스토리지를 위한 단일 EC2 호스트 없음)을 향상시키고 애플리케이션 계층의 수평 확장을 지원합니다.

최소 2개의 instance가 있는 ALB + ASG는 고가용성 및 확장에 좋지만 AWS Global Accelerator는 주로 네트워크 경로를 최적화하고 정적 애니캐스트 IP를 제공합니다. 콘텐츠를 캐시하지는 않습니다. 비디오/자료에 대한 반복적인 접근이 지배적인 워크로드의 경우 캐싱이 핵심 성능 레버입니다. Global Accelerator가 도움이 될 수 있지만 여기서는 일반적으로 CloudFront가 더 적절한 서비스입니다.

AMI를 생성하고 ASG(최소 2개)와 함께 ALB 뒤에 배포하면 단일 instance 병목 현상을 해결하고 AZ 전반의 가용성을 향상시킵니다. CloudFront를 추가하면 엣지 로케이션에서 정적 및 캐시 가능한 콘텐츠를 캐싱하여 지연 시간을 줄이고 등록 피크 시 오리진을 오프로드하여 성능을 향상시킵니다. 이 조합은 복원력(다중 instance)과 성능(엣지 캐싱)을 모두 직접적으로 타겟팅합니다.

문제 분석

핵심 개념: 이 질문은 EC2에서 확장 가능하고 가용성이 높은 웹 애플리케이션 계층을 설계하고 단일 instance에서 공유 콘텐츠 스토리지를 분리하는 것을 테스트합니다. 또한 트래픽 급증 시 오리진 부하를 줄이기 위해 엣지 캐싱을 사용하는 것을 테스트합니다. 정답인 이유: LMS는 연결된 EBS 볼륨에 코스 자료가 있는 단일 EC2 instance입니다. EBS는 하나의 instance(및 하나의 AZ)에 연결된 블록 스토리지이므로 정적 콘텐츠에 대한 성능 병목 현상이자 단일 장애 점이 됩니다. 웹 계층을 수평으로 확장하려면 여러 EC2 instance가 동일한 공유 콘텐츠에 접근해야 합니다. Amazon EFS는 많은 EC2 instance가 동시에 마운트할 수 있는 관리형, 탄력적, 다중 AZ NFS 파일 시스템을 제공하여 복원력을 향상시키면서 비디오/자료에 대한 공유 접근을 가능하게 합니다. 다음으로 플랫폼은 5,000명 이상의 동시 학생을 처리해야 합니다. AMI를 생성하고 최소 2개의 instance가 있는 Auto Scaling group(ASG)의 Application Load Balancer(ALB) 뒤에 instance를 배치하면 여러 AZ에 걸쳐 고가용성을 제공하고 피크 시 스케일 아웃됩니다. 플랫폼 앞에 Amazon CloudFront를 추가하면 엣지 로케이션에서 자주 접근하는 코스 콘텐츠를 캐시하고 제공하여 학생들의 지연 시간을 줄이고 ALB/EC2 및 공유 파일 시스템의 요청을 오프로드합니다. 주요 AWS 기능: - Amazon EFS: 다중 AZ 내구성/가용성, 탄력적 처리량, 동시 마운트, POSIX 권한; ASG 전반의 공유 웹 콘텐츠에 이상적입니다. - ALB + ASG: 다중 AZ 로드 밸런싱, 상태 검사, 자동 교체, 스케일 아웃/인 정책; 최소 용량 2는 가용성을 향상시킵니다. - CloudFront: 엣지 캐싱, 오리진 장애 조치 패턴, 오리진 부하 감소, 글로벌 성능 향상; 아키텍처에 따라 ALB(동적) 및/또는 S3/EFS 기반 오리진을 사용할 수 있습니다. 일반적인 오해: - "모든 instance에 S3 마운트"는 프로덕션 워크로드를 위한 표준적이고 지원되는 POSIX 파일 시스템 접근 방식이 아닙니다. S3는 NFS가 아니라 API를 통해 접근하는 객체 스토리지입니다. - 기본 EC2 instance에서 NFS 공유를 사용하면 단일 장애 점이 유지되며 고가용성 목표를 충족하지 못합니다. - Global Accelerator는 리전 endpoint로의 TCP/UDP 라우팅을 최적화하지만 캐싱을 제공하지는 않습니다. 무거운 정적 콘텐츠 접근의 경우 일반적으로 CloudFront가 더 적합합니다. 시험 팁: "단일 EC2 instance 내부에 마운트된 EBS"와 "여러 instance 및 HA 필요"를 보면 EFS(공유 POSIX) 또는 S3(객체)를 생각하십시오. "많은 동시 사용자가 정적 자료에 접근"을 보면 ALB 뒤의 Auto Scaling 웹 계층과 CloudFront 캐싱을 생각하십시오.

3
문제 3

한 금융 서비스 회사가 단일 VPC 내의 Amazon EC2 instance에서 분산 문서 처리 시스템을 운영하고 있습니다. EC2 instance는 내결함성을 위해 서로 다른 Availability Zone의 여러 서브넷에 배포됩니다. 이러한 instance는 instance 간 통신 없이 독립적으로 작동하지만 단일 NAT gateway를 통해 Amazon S3에서 재무 보고서를 자주 다운로드하고 처리된 문서를 S3에 다시 업로드합니다. 회사는 매일 약 500GB의 문서를 처리하며 상당한 데이터 전송 비용을 겪고 있습니다. 현재 아키텍처를 유지하면서 리전 데이터 전송 요금을 없애기 위한 가장 비용 효율적인 솔루션을 찾아야 합니다. 회사가 리전 데이터 전송 요금을 피할 수 있는 가장 비용 효율적인 방법은 무엇입니까?

Availability Zone당 NAT gateway를 배포하는 것은 HA 모범 사례이며 다른 AZ의 NAT로 라우팅하여 발생하는 교차 AZ 데이터 전송 요금을 줄일 수 있습니다. 그러나 모든 S3 트래픽에 여전히 NAT gateway 데이터 처리 요금이 발생하고 여러 NAT 시간당 요금이 추가되므로 가장 비용 효율적인 방식으로 S3 접근에 대한 리전 데이터 전송 요금을 제거하지는 않습니다. 아키텍처를 개선하지만 일반적으로 S3 gateway endpoint보다 비용이 더 많이 듭니다.

NAT instance는 경우에 따라 시간당 NAT 비용을 줄일 수 있지만 상당한 운영 부담(패치, 확장, 장애 조치)을 초래하고 500GB/일의 처리량 병목 현상이 될 수 있습니다. 또한 본질적으로 리전 데이터 전송 요금을 제거하지 않습니다. 교차 AZ 라우팅이 여전히 발생할 수 있으며 트래픽은 S3로의 최적화된 프라이빗 경로를 사용하는 대신 여전히 NAT 디바이스를 통과합니다. 이는 시험에서 비용과 안정성에 대한 최선의 답인 경우가 거의 없습니다.

S3 gateway VPC endpoint는 S3에 대한 private subnet 접근을 위한 가장 비용 효율적인 솔루션입니다. S3 트래픽에 대한 NAT의 필요성을 제거하여 NAT gateway 데이터 처리 요금을 없애고 리전 데이터 전송 비용을 발생시킬 수 있는 교차 AZ NAT 라우팅을 방지합니다. 기존 아키텍처(private subnet의 EC2)를 유지하면서 보안을 향상시키고(인터넷 경로 필요 없음) endpoint 및 버킷 정책을 통해 세분화된 접근 제어를 가능하게 합니다.

EC2 Dedicated Host는 VPC 이그레스 데이터 전송 비용이 아니라 라이선스, 규정 준수 및 호스트 수준 격리 요구 사항을 해결합니다. Dedicated Host로 이동해도 instance가 S3에 도달하는 방식은 변경되지 않으며(여전히 NAT 또는 endpoint를 사용함) 컴퓨팅 비용이 크게 증가합니다. 이 옵션은 설명된 네트워킹 비용 동인과 무관하며 S3 데이터 전송 요금에 대한 비용 최적화 솔루션이 아닙니다.

문제 분석

핵심 개념: 이 질문은 Amazon S3에 접근하는 private subnet을 위한 비용 최적화된 VPC 이그레스 설계를 테스트합니다. 핵심 개념은 S3 접근에 NAT gateway를 사용하면 트래픽이 AZ 범위의 NAT를 통과하도록 강제되어 리전 데이터 전송 요금이 발생할 수 있는 반면(특히 여러 AZ의 서브넷이 한 AZ의 단일 NAT를 사용하는 경우), Amazon S3 gateway VPC endpoint는 NAT 없이 AWS 네트워크에 S3 트래픽을 유지한다는 것입니다. 정답인 이유: Amazon S3용 gateway VPC endpoint는 인터넷 게이트웨이, 퍼블릭 IP 또는 NAT 디바이스 없이 VPC에서 S3로의 프라이빗 직접 연결을 제공합니다. 이는 S3 바운드 트래픽에 대한 NAT gateway 데이터 처리 요금을 제거하고 AZ-B/C의 instance가 AZ-A에 있는 NAT gateway로 라우팅될 때 발생하는 교차 AZ 데이터 전송을 방지합니다. 매일 약 500GB의 S3 다운로드/업로드가 있는 경우 NAT 처리 및 교차 AZ 라우팅을 제거하는 것이 일반적으로 private subnet의 EC2 아키텍처를 동일하게 유지하면서 이러한 리전 데이터 전송 요금을 줄이거나 없애는 가장 비용 효율적인 방법입니다. 주요 AWS 기능: - Gateway VPC endpoint(S3/DynamoDB): private subnet의 라우팅 테이블에 추가됩니다. - Endpoint 정책: 허용되는 S3 버킷/작업을 제한합니다(최소 권한 지원). - aws:SourceVpce를 사용하는 S3 버킷 정책과 함께 작동하여 endpoint를 통해서만 접근을 강제합니다. - Gateway endpoint에 대한 시간당 요금은 없습니다. NAT 처리가 아니라 S3에 적용되는 S3 요청 및 데이터 전송에 대해서만 비용을 지불합니다. 일반적인 오해: "더 많은 NAT gateway"(AZ당 하나)가 해결책이라고 생각하기 쉽습니다. 교차 AZ 데이터 전송은 줄어들지만 NAT 시간당 비용이 증가하고 모든 S3 트래픽에 대해 여전히 NAT 데이터 처리 요금이 발생합니다. 또 다른 오해는 NAT instance가 더 저렴하다는 것입니다. 시간당 비용은 줄일 수 있지만 운영 오버헤드, 확장 제한이 발생하며 S3로의 목적에 맞게 구축된 프라이빗 경로를 사용하는 대신 트래픽이 여전히 NAT를 통해 흐르도록 유지합니다. 시험 팁: Private subnet이 대규모로 S3/DynamoDB에 접근해야 하는 경우 비용과 보안을 위해 기본적으로 gateway VPC endpoint를 사용하십시오. NAT gateway는 주로 일반 인터넷 이그레스(예: OS 업데이트, 외부 API)에 사용하십시오. "단일 NAT gateway" + "여러 AZ" + "높은 데이터 볼륨"이 표시되면 교차 AZ 요금을 생각하고 AWS 서비스 트래픽에 대해 먼저 endpoint를 고려하십시오.

4
문제 4

한 의료 연구 기관이 의료 이미지 처리 시스템을 AWS로 마이그레이션해야 합니다. 이 기관은 다양한 병원과 클리닉에서 SFTP를 통해 매일 수백 개의 DICOM 의료 이미지를 수신합니다. 현재 온프레미스 시스템은 완료하는 데 몇 시간이 걸리는 일괄(batch) 처리를 사용하여 밤새 이 이미지들을 처리합니다. 이 기관은 병원에서 사용하는 SFTP 클라이언트에 대한 변경을 최소화하면서 수신되는 의료 이미지가 도착하는 즉시 처리하는 AWS 솔루션을 원합니다. 이 솔루션은 성공적인 분석 후 처리된 이미지를 자동으로 삭제해야 합니다. 각 이미지 처리 작업은 완료하는 데 4-10분이 소요됩니다. 운영상 가장 효율적인 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

오답입니다. Amazon EC2에서 SFTP 서버를 실행하면 조직이 서버의 패치, 확장성, 가용성, 보안을 관리해야 하므로 불필요한 운영 오버헤드가 발생합니다. 새로 도착한 이미지를 S3 Glacier Deep Archive에 저장하는 것도 이미지가 도착하자마자 처리해야 한다는 요구 사항과 맞지 않습니다. 이 스토리지 클래스에서의 retrieval은 아카이브 용도로 설계되어 지연 시간이 매우 높기 때문입니다. 또한 매일 밤 직접 처리를 호출하는 방식은 near-real-time 처리 요구 사항과 정면으로 충돌합니다.

오답입니다. 이 옵션도 self-managed EC2 기반 SFTP 서버에 의존하므로 AWS Transfer Family보다 운영 효율성이 떨어집니다. EBS volume을 랜딩 영역으로 사용하면 데이터가 인스턴스에 종속되고, S3가 제공하는 단순한 event-driven object-ingestion 패턴을 제공하지 못합니다. 가장 중요한 점은 이미지가 도착 시점이 아니라 매일 밤 처리되므로, 이 설계는 핵심 비즈니스 요구 사항을 충족하지 못합니다.

오답입니다. AWS Transfer Family는 스토리지 백엔드로 Amazon S3 또는 Amazon EFS를 지원하며 Amazon EBS는 지원하지 않으므로, 이 아키텍처는 작성된 내용 그대로는 유효하지 않습니다. 또한 이 옵션은 파일이 EBS에 저장된다고 하면서도 S3 event notification 사용을 언급하고 있어 내부적으로 일관성이 없습니다. 4~10분 작업에 대해 AWS Batch는 적절한 컴퓨팅 선택일 수 있지만, 이 옵션은 스토리지와 이벤트 설계 때문에 오답입니다.

정답입니다. AWS Transfer Family는 managed SFTP 엔드포인트를 제공하므로 병원과 클리닉이 기존 SFTP 클라이언트를 최소한의 변경만으로 또는 변경 없이 계속 사용할 수 있습니다. 수신 파일을 Amazon S3 Standard에 저장하면 기본 S3 event notifications를 사용할 수 있어, 야간 batch window를 기다리지 않고 각 이미지가 도착하는 즉시 처리를 시작할 수 있습니다. Lambda function은 분석 워크플로를 수행한 뒤 성공적으로 완료된 경우에만 object를 삭제할 수 있으므로, 운영을 단순하게 유지하면서 정리 요구 사항도 충족하는 fully managed 솔루션이 됩니다.

문제 분석

핵심 개념: 요구 사항은 클라이언트 변경을 최소화한 managed SFTP 수집, 파일 도착 시 즉시 처리, 그리고 성공적으로 처리된 후 자동 삭제입니다. 가장 적합한 아키텍처 패턴은 SFTP 엔드포인트에 AWS Transfer Family를 사용하고 랜딩 영역으로 Amazon S3를 사용한 다음, S3 object creation events에서 처리를 트리거하는 것입니다. 정답인 이유: 보기 중 D만이 fully managed SFTP 서비스를 사용하고, 파일 도착 이벤트를 기본적으로 지원하는 S3에 파일을 저장하며, 야간 batch window를 기다리지 않고 파일이 도착하자마자 처리합니다. 주요 기능: AWS Transfer Family는 병원들이 프로토콜을 변경할 필요 없이 표준 SFTP 클라이언트를 지원하고, Amazon S3는 내구성 있는 object storage와 event notifications를 제공하며, AWS Lambda는 S3에서 직접 호출되어 이미지별 처리 로직을 실행하고 성공 후 object를 삭제할 수 있습니다. 흔한 오해: AWS Transfer Family는 파일을 Amazon EBS에 저장하지 않으므로, Transfer Family와 EBS를 함께 설명하는 보기는 아키텍처적으로 유효하지 않습니다. 또한 야간 처리는 이미지가 도착하자마자 처리해야 한다는 요구 사항을 충족하지 못합니다. 시험 팁: 문제가 운영 효율성을 강조할 때는 self-managed EC2보다 managed services를 우선 고려하고, 정답 보기에서 사용된 스토리지 백엔드와 이벤트 소스가 해당 AWS 서비스에서 실제로 지원되는지 확인하세요.

5
문제 5

글로벌 물류 회사가 Amazon S3 버킷에 JSON 파일로 저장된 일일 배송 매니페스트를 처리하기 위해 AWS Glue를 사용합니다. ETL 작업은 매일 아침 6시에 자동으로 실행되어 배송 데이터를 추출하고, 분석을 위해 변환한 후 데이터 웨어하우스에 로드합니다. 솔루션 아키텍트는 매일 실행될 때마다 지난 30일 동안 이전에 처리된 파일을 포함하여 약 500GB의 누적 데이터를 처리하는 것을 관찰했습니다. 이로 인해 작업 실행 시간이 초기 15분에서 현재 2시간 이상으로 증가하여 운영 비용에 큰 영향을 미치고 분석 보고가 지연되고 있습니다. AWS Glue가 매일 새로운 배송 데이터만 처리하도록 하려면 솔루션 아키텍트는 무엇을 구현해야 합니까?

정답입니다. AWS Glue job bookmarks는 이전에 처리된 데이터를 추적하고 작업 실행 전반에 걸쳐 상태를 유지합니다. 활성화되면 Glue는 이전의 성공적인 실행에서 이미 처리된 파일/파티션을 건너뛰어 증분 ETL을 가능하게 합니다. 이는 매일 스캔되는 데이터를 직접적으로 줄이고, 실행 시간을 안정화하며, S3에서 읽어오는 반복 작업의 비용을 낮춥니다.

가장 좋은 답이 아닙니다. 처리된 파일을 다른 버킷/접두사로 이동하면 재처리를 방지할 수 있지만, 운영 오버헤드(복사/삭제, 실패 처리, 권한), 추가적인 S3 요청 비용, 잠재적인 거버넌스/계보(lineage) 복잡성을 초래합니다. Glue는 이러한 요구 사항을 위해 특별히 구축되고 더 간단한 기본 증분 메커니즘(job bookmarks)을 제공합니다.

오답입니다. 작업을 1 DPU로 설정하면 컴퓨팅 용량만 줄어들 뿐 입력 범위는 변경되지 않습니다. 작업은 여전히 동일한 500GB의 데이터를 읽고 실행 시간이 훨씬 더 길어질 가능성이 높으며, 실행 시간 연장으로 인해 비용이 증가하고 보고 SLA를 놓칠 위험이 있습니다.

오답입니다. AWS Glue DataBrew recipe는 레코드를 정리하고 중복을 제거할 수 있지만, Glue가 이전에 처리된 S3 객체를 스캔하고 읽는 것을 방지하지는 못합니다. 문제는 새로운 일일 데이터 내의 중복 행이 아니라 파일 수준의 재처리(30일치 매니페스트를 다시 읽는 것)입니다.

문제 분석

핵심 개념: 이 질문은 S3 기반 데이터 레이크를 위한 AWS Glue 증분 처리 패턴을 테스트합니다. AWS Glue ETL 작업이 동일한 S3 접두사를 반복적으로 스캔할 때, 이미 처리된 항목을 추적하는 메커니즘을 구현하지 않으면 과거 객체를 다시 읽게 됩니다. 핵심 기능은 작업 실행 간의 상태를 유지하는 AWS Glue job bookmarks입니다. 정답인 이유: job bookmarks를 활성화하면 마지막으로 성공한 실행 이후의 새 데이터(또는 변경된 데이터)만 Glue 작업이 처리하도록 보장합니다. S3 소스의 경우, bookmarks는 이전에 처리된 파일/파티션을 추적하여 후속 실행에서 이를 건너뛸 수 있게 합니다. 이는 관찰된 동작(작업이 약 30일치 파일(누적 500GB)을 재처리하여 실행 시간과 비용이 증가하는 문제)을 직접적으로 해결합니다. bookmarks를 사용하면 매일 오전 6시 실행 시 새로 도착한 일일 매니페스트에만 집중하여 실행 시간을 안정화하고 소비되는 DPU를 줄일 수 있습니다. 주요 AWS 기능: Job bookmarks는 작업 수준(Enable job bookmark)에서 구성되며 Glue DynamicFrames 및 지원되는 소스와 함께 작동합니다. AWS Glue Data Catalog/메타데이터에 상태를 유지하여 작업이 재개되고 재처리를 방지할 수 있습니다. 모범 사례는 bookmarks를 파티셔닝된 S3 레이아웃(예: s3://bucket/manifests/dt=YYYY-MM-DD/) 및 조건부 푸시다운(predicate pushdown)/파티션 프루닝(partition pruning)과 결합하여 읽기 속도를 더욱 높이는 것입니다. 이는 스캔되는 데이터 감소, 실행 시간 단축, 컴퓨팅 리소스 최적화라는 비용 최적화 원칙과 일치합니다. 일반적인 오해: 처리된 파일을 이동하는 것(옵션 B)은 운영상 작동할 수 있지만 복잡성, 추가적인 S3 복사/삭제 비용, 잠재적인 데이터 거버넌스 문제를 야기하며 데이터 계보(lineage)/감사를 손상시킬 수 있습니다. DPU를 줄이는 것(옵션 C)은 읽는 데이터 양을 줄이지 않으며, 일반적으로 실행 시간을 늘리고 비용을 악화시킬 수 있습니다. DataBrew 중복 제거(옵션 D)는 반복적인 파일 스캔이 아니라 중복 레코드를 처리하는 것이므로 Glue는 여전히 모든 과거 파일을 읽게 됩니다. 시험 팁: AWS Glue에서 "새 데이터만 처리"라는 문구를 보면 가장 먼저 "job bookmarks"를 떠올리십시오. S3 기반 ETL의 경우 파티셔닝 + bookmarks가 일반적인 시험 패턴이라는 점도 기억하십시오. 오래된 객체를 다시 읽어 실행 시간이 증가하는 문제라면, 해결책은 컴퓨팅 제한이나 레코드 수준의 중복 제거가 아니라 증분 처리/상태 추적입니다.

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

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

6
문제 6

의료 연구 기관이 의료 영상 데이터와 연구 데이터 세트를 저장하는 온프레미스 NFS 파일 서버를 운영하고 있습니다. 영상 파일은 생성 후 처음 10일 동안 연구원들이 분석 및 처리를 위해 집중적으로 액세스합니다. 10일이 지나면 규정 준수 및 아카이브 목적으로 파일에 드물게 액세스합니다. 전체 데이터 볼륨이 빠르게 증가하여 기관의 스토리지 용량 한계에 도달하고 있습니다. 솔루션 아키텍트는 최근에 생성된 파일에 대한 low-latency 액세스를 유지하고 자동화된 데이터 수명 주기 관리(lifecycle management)를 구현하면서 스토리지 용량을 확장해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

AWS DataSync는 on-premises NFS 스토리지와 AWS 서비스 간에 데이터를 전송하는 데 유용하지만, 스토리지 확장 솔루션은 아닙니다. 활성 파일을 위한 로컬 캐시와 함께 지속적인 하이브리드 파일 인터페이스를 제공하지 않으므로, 새로 생성된 데이터셋에 필요한 low-latency 액세스 패턴을 유지할 수 없습니다. 또한 연구소는 별도의 스토리지 위치와 데이터 이동 로직을 관리해야 하므로 운영 복잡성이 증가합니다. 따라서 DataSync는 lifecycle 기반 스토리지 관리와 함께 투명한 용량 확장을 위한 주된 정답으로 적합하지 않습니다.

Amazon S3 File Gateway는 표준 NFS/SMB 액세스를 사용하여 on-premises 파일 스토리지를 확장하면서 기본 데이터를 Amazon S3에 저장하므로 가장 적합합니다. 이를 통해 연구소는 연구원들이 파일 액세스 방식이나 애플리케이션을 변경하지 않고도 로컬 스토리지 한계를 넘어 확장할 수 있습니다. File Gateway는 또한 로컬 캐시를 유지하므로, 처음 10일 동안 최근 생성되고 자주 사용되는 이미징 파일에 대해 low-latency 액세스를 지원합니다. 그 이후에는 S3 Lifecycle policies를 사용해 객체를 더 저렴한 아카이브 클래스로 자동 전환할 수 있으므로, 하이브리드 액세스, 확장성, lifecycle 자동화를 함께 해결하는 유일한 선택지입니다.

Amazon FSx for Lustre는 고성능 파일 처리 워크로드, 특히 analytics 및 HPC 사용 사례를 위해 설계되었지만, 여기서의 주요 요구 사항은 그것이 아닙니다. 이 문제는 기존 on-premises NFS 환경을 확장하고, 사용자 액세스 패턴을 유지하며, 오래된 데이터의 아카이빙을 자동화하는 데 초점을 맞추고 있습니다. FSx for Lustre는 S3 File Gateway처럼 on-premises 파일 서버의 단순한 하이브리드 확장으로 동작하지 않습니다. 또한 규정 준수를 위한 보관 목적으로 오래된 파일을 아카이브 스토리지로 lifecycle 기반 이동시키는 문제도 직접 해결하지 못합니다.

각 워크스테이션에 S3 client 소프트웨어를 설치하면 연구원들은 파일 기반 NFS 워크플로에서 직접 object storage 액세스로 전환해야 하며, 이는 애플리케이션 변경과 사용자 재교육이 필요할 가능성이 큽니다. 이 접근 방식은 기존 on-premises 파일 액세스 모델을 유지하지 못하고, 로컬 캐시를 통해 활성 파일에 대한 투명한 low-latency 액세스도 제공하지 않습니다. S3 Lifecycle을 S3 Glacier Flexible Retrieval과 함께 사용하는 것은 합리적인 아카이빙 메커니즘이지만, 액세스 방식이 운영상 큰 혼란을 초래하며 현재의 파일 제공 경험을 유지해야 한다는 요구 사항을 충족하지 못합니다. 따라서 이 선택지는 가끔 retrieval이 있는 경우 Deep Archive보다 더 적절한 아카이브 클래스를 사용한다는 점은 맞지만, 사용성과 아키텍처 측면에서 실패합니다.

문제 분석

핵심 개념: 이 문제는 on-premises의 NFS 기반 파일 워크로드를 AWS로 확장하면서, 활성 파일에 대한 low-latency 액세스를 유지하고 오래된 데이터를 더 저렴한 스토리지로 자동 이동하는 방법에 관한 것입니다. 이 패턴의 핵심 AWS 서비스는 Amazon S3 File Gateway이며, on premises에서 NFS/SMB 인터페이스를 제공하고 자주 액세스되는 데이터를 위한 로컬 캐시와 함께 파일을 Amazon S3의 객체로 저장합니다. 정답인 이유: 이 연구소는 연구원들이 파일에 액세스하는 방식을 변경하지 않고 스토리지 용량을 확장해야 하며, 최근에 생성된 파일은 계속 빠르게 액세스할 수 있어야 합니다. Amazon S3 File Gateway는 S3를 기반으로 하는 file share 인터페이스를 제공하고 활성 데이터를 로컬에 캐시하여 low-latency 액세스를 지원하므로 이 요구를 충족합니다. 그런 다음 Lifecycle management를 사용해 10일 후 오래된 객체를 더 저렴한 아카이브 스토리지 클래스로 자동 전환할 수 있어, hot-to-cold 액세스 패턴을 만족합니다. 주요 AWS 기능: - Amazon S3 File Gateway는 on-premises 사용자와 애플리케이션에 NFS/SMB 액세스를 제공하면서 데이터를 내구성 있게 Amazon S3에 저장합니다. - 로컬 캐싱은 최근에 사용된 파일을 low latency로 사용할 수 있게 유지하므로, 처음 10일 동안의 집중적인 액세스에 이상적입니다. - S3 Lifecycle policies는 오래된 객체를 S3 Glacier Flexible Retrieval과 같은 아카이브 클래스로 자동 전환하여 더 저렴한 비용으로 장기 보관할 수 있게 합니다. 흔한 오해: - AWS DataSync는 전송 및 마이그레이션 서비스이지, 로컬 캐싱이 있는 투명한 하이브리드 파일 스토리지 확장 솔루션이 아닙니다. - Amazon FSx for Lustre는 고성능 컴퓨팅 워크로드에 최적화되어 있으며, 기존 on-prem NFS 환경을 lifecycle 기반 아카이빙과 함께 확장하는 용도가 아닙니다. - 워크스테이션에서 직접 S3에 액세스하려면 S3가 native NFS 파일 시스템이 아닌 object storage이기 때문에 애플리케이션과 워크플로 변경이 필요합니다. 시험 팁: 문제에서 on-premises NFS 또는 SMB 워크로드를 언급하면서, 최소한의 애플리케이션 변경으로 AWS로 자연스럽게 확장해야 한다고 하면 AWS Storage Gateway, 특히 S3 File Gateway를 떠올리세요. 또한 데이터의 자동 노후화와 더 저렴한 스토리지로의 이동을 언급하면, File Gateway와 S3 Lifecycle policies를 함께 생각해야 합니다. Glacier 스토리지 클래스는 retrieval 요구 사항에 따라 구분해야 합니다. Deep Archive는 매우 드물게 검색되는 데이터와 매우 긴 retrieval 시간에 적합하고, Flexible Retrieval은 가끔 retrieval이 예상될 때 더 적합합니다.

7
문제 7

엔터프라이즈 'TechCorp'는 온프레미스 Microsoft Active Directory에서 AWS로 애플리케이션을 마이그레이션하고 있습니다. 이 회사는 AWS Organizations를 사용하여 여러 AWS 계정을 중앙에서 관리합니다. 보안 팀은 모든 AWS 계정에 걸쳐 SSO(Single Sign-On) 솔루션을 요구합니다. 회사는 기존 온프레미스 Active Directory에서 사용자 및 그룹을 계속 관리해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

정답입니다. AWS IAM Identity Center는 AWS Organizations로 관리되는 여러 AWS accounts 전반에 centralized single sign-on을 제공하도록 설계된 AWS 서비스입니다. AWS Directory Service for Microsoft Active Directory를 identity source로 사용하고, trust를 통해 기존 on-premises AD와 통합하면 회사는 users와 groups를 on-premises directory에서 계속 관리할 수 있습니다. 그런 다음 IAM Identity Center는 해당 identities를 사용하여 permission sets와 account access를 중앙에서 할당합니다. 이는 multi-account SSO 요구 사항과 on-premises AD를 권한 있는 identity store로 유지해야 한다는 요구 사항을 모두 직접 충족합니다.

오답입니다. AWS Directory Service와 AD trust relationship만으로는 조직의 모든 AWS accounts 전반에 centralized SSO를 제공하지 않습니다. AWS account SSO와 centralized account assignments를 제공하는 서비스는 Directory Service 자체가 아니라 AWS IAM Identity Center입니다. directory가 on-premises AD에 연결되어 있더라도, 관리자는 workforce access를 AWS accounts에 부여하기 위해 여전히 IAM Identity Center 또는 다른 federation mechanism이 필요합니다. 따라서 '모든 AWS accounts에 대해 자동으로 SSO를 활성화한다'는 표현은 기술적으로 부정확합니다.

오답입니다. AWS에서 AWS Managed Microsoft AD directory를 생성하고 이를 IAM Identity Center의 identity source로 사용하는 것은 SSO를 지원할 수 있지만, 이 선택지는 users와 groups가 계속 관리되는 위치로서 기존 on-premises AD를 유지하지 않습니다. 문장 그대로라면 on-premises 환경의 trust 기반 확장이 아니라 AWS에 호스팅된 directory가 primary identity source가 된다는 의미입니다. 이는 identity administration이 기존 on-premises Active Directory에 남아 있어야 한다는 요구 사항을 깔끔하게 충족하지 못합니다. on-premises directory에 대한 trust 또는 연결이 빠져 있다는 점이 핵심적인 결함입니다.

오답입니다. Amazon EC2에서 custom identity provider를 운영하면 patching, scaling, high availability 설계, security hardening을 포함한 불필요한 운영 오버헤드가 발생합니다. AWS IAM Identity Center는 이미 enterprise identity를 위한 managed integration patterns를 지원하므로, 이 사용 사례에서 self-hosted IdP는 불필요하게 복잡한 솔루션입니다. 문제는 custom federation platform 구축을 정당화할 만한 특별한 protocol 또는 legacy requirement를 나타내지 않습니다. AWS certification 시험에서는 요구 사항을 충족할 수 있다면 일반적으로 managed native services가 선호됩니다.

문제 분석

핵심 개념: 이 문제는 기존 on-premises Microsoft Active Directory를 권한 있는 identity store로 유지하면서, AWS Organizations의 여러 AWS accounts 전반에서 AWS IAM Identity Center(AWS SSO의 후속 서비스)를 사용해 federated identity와 centralized access management를 구현하는지를 테스트합니다. 정답인 이유: Option A는 표준 AWS 패턴과 일치합니다. management account(또는 delegated admin)에서 IAM Identity Center를 활성화하고, AWS Directory Service for Microsoft Active Directory(AWS Managed Microsoft AD)를 통해 Microsoft AD에 연결합니다. 그런 다음 AWS Managed Microsoft AD와 on-premises AD 사이에 trust relationship을 설정하여 사용자와 그룹을 계속 on-premises에서 관리할 수 있게 하면서, IAM Identity Center가 AD identities를 사용해 모든 member accounts에 SSO를 제공할 수 있습니다. IAM Identity Center는 Organizations와 기본적으로 통합되어 accounts 전반에 permission sets를 할당할 수 있으므로, “모든 AWS accounts에서 SSO” 요구 사항을 충족합니다. 주요 AWS 기능: - IAM Identity Center + AWS Organizations integration: 조직 전체에서 centralized user access, permission sets, account assignments 제공 - AWS Directory Service for Microsoft AD: on-prem AD와 trust를 설정할 수 있는 AWS의 managed AD로, 기존 users/groups를 사용할 수 있게 함 - Trust relationships: on-prem AD에 대한 authentication을 허용하면서 AWS 측 integrations를 가능하게 하는 데 일반적으로 사용됨 - Best practice: workforce access에는 account별 IAM users보다 IAM Identity Center를 사용하고, authorization은 permission sets와 groups를 통해 관리 흔한 오해: 자주 나오는 함정은 Directory Service와 trust를 생성하기만 하면 모든 곳에서 “자동으로 SSO가 활성화된다”고 생각하는 것입니다(그렇지 않습니다). 또 다른 오해는 사용자를 AWS Managed Microsoft AD로 반드시 마이그레이션해야 한다는 것인데, trust를 사용하면 users/groups를 on-prem에 그대로 유지할 수 있습니다. 또한 EC2에 custom IdP를 배포하는 것은 불필요하며, managed integrations에 비해 운영 및 보안 부담을 증가시킵니다. 시험 팁: “multiple accounts”, “AWS Organizations”, “SSO”가 보이면 IAM Identity Center를 떠올리세요. “users/groups를 on-prem AD에 유지해야 함”이 보이면 Directory Service + AD trust(또는 direct SAML을 기존 IdP(예: ADFS/Azure AD)에 연결하는 방식, 선택지에 있다면)를 떠올리세요. 요구 사항이 custom IdP deployment를 명시적으로 요구하지 않는 한, custom IdP deployment보다 managed services를 우선하세요.

8
문제 8

소셜 네트워킹 애플리케이션 'ConnectSphere'에는 5TB의 사용자 데이터가 있는 데이터베이스가 있습니다. 이 데이터는 100만 개의 사용자 프로필과 그 사이의 1,000만 개의 연결로 구성되어 복잡한 다대다(many-to-many) 관계를 나타냅니다. 애플리케이션은 고성능 방식으로 최대 5단계 깊이까지 사용자 간의 상호 연결을 자주 찾아야 합니다. 솔루션 아키텍트는 이러한 관계를 탐색하고 다단계 연결을 빠르게 찾는 데 매우 효율적인 데이터베이스 솔루션을 식별해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

S3와 Athena는 지연 시간이 짧은 대화형 탐색 쿼리가 아니라 파일의 대규모 데이터 세트(데이터 레이크 분석)를 스캔하는 데 최적화되어 있습니다. 최대 5단계 깊이의 상호 연결을 찾으려면 대규모 데이터 세트에 대해 반복적인 셀프 조인(self-joins)이 필요하므로 전체/대규모 스캔으로 인해 쿼리 지연 시간과 비용이 높아집니다. Athena는 애플리케이션의 실시간 그래프 탐색이 아니라 임시 분석 및 보고에 가장 적합합니다.

RDS for MySQL은 테이블과 외래 키를 사용하여 사용자와 연결을 나타낼 수 있지만, 다단계 탐색 및 상호 연결 쿼리에는 일반적으로 재귀 CTE와 여러 셀프 조인이 필요합니다. 이 규모(수백만 개의 노드/간선)에서는 조인 중심 쿼리를 튜닝하기 느리고 복잡해질 수 있으며 깊이가 증가함에 따라 성능이 저하될 수 있습니다. 관계형 데이터베이스는 깊은 그래프 탐색을 위해 특별히 구축되지 않았습니다.

Amazon Neptune은 정점(사용자 프로필)과 간선(연결)이 있는 그래프 워크로드를 위해 특별히 구축되었습니다. 그래프 최적화 스토리지 및 인덱싱을 활용하여 Gremlin 또는 SPARQL을 사용하여 다중 홉 탐색(예: 최대 5단계) 및 상호 연결 쿼리를 효율적으로 실행합니다. Neptune은 탐색이 빈번하고 고성능이어야 하는 소셜 네트워크 관계 탐색에 가장 적합합니다.

DynamoDB는 영리한 파티션/정렬 키를 사용하여 인접 리스트나 간선 레코드를 저장할 수 있지만, 다단계 탐색에는 반복적인 쿼리/가져오기 및 애플리케이션 측 재귀가 필요합니다. 이는 지연 시간(많은 네트워크 호출)을 증가시키고 일관성 및 페이지 매김을 복잡하게 만들며 깊이가 깊어질수록 비용이 많이 들 수 있습니다. DynamoDB는 예측 가능한 키 기반 액세스 패턴에 탁월하며, 여러 홉 떨어진 상호 연결과 같은 복잡한 그래프 탐색에는 적합하지 않습니다.

문제 분석

Core Concept: 이 질문은 고도로 연결된 데이터 및 깊은 관계 탐색에 적합한 데이터베이스를 선택하는 것을 테스트합니다. 그래프 데이터베이스는 다대다 관계 및 다중 홉(multi-hop) 쿼리(예: 최대 N단계까지의 "친구의 친구")를 예측 가능한 성능으로 처리하도록 특별히 구축되었습니다. Why the Answer is Correct: Amazon Neptune은 그래프 쿼리 언어를 사용하여 관계를 탐색하는 데 최적화된 AWS의 관리형 그래프 데이터베이스입니다. 100만 개의 사용자 정점(vertices)과 1,000만 개의 연결 간선(edges)이 있는 상황에서 "최대 5단계 깊이의 상호 연결"과 같은 쿼리는 그래프 탐색에 직접 매핑됩니다. Neptune은 관계를 저장하고 인덱싱하므로 다중 홉 탐색 시 비용이 많이 드는 테이블 조인을 피할 수 있으며 그래프가 커져도 효율적으로 실행될 수 있습니다. 이것이 바로 Neptune이 설계된 소셜 네트워크 패턴입니다. Key AWS Features: Neptune은 Property Graph(Gremlin)와 RDF(SPARQL)를 모두 지원하여 표현력 있는 탐색 쿼리(예: 가변 길이 경로 탐색, 공통 이웃/상호 연결)를 가능하게 합니다. 관리형(자동 백업, 패치 적용)이며, 읽기 확장을 위한 읽기 전용 복제본(read replicas)을 지원하고, 여러 AZ에 걸쳐 고가용성을 제공합니다. 성능 측면에서 Neptune의 그래프 최적화 스토리지 및 인덱싱은 관계형 JOIN 중심 접근 방식의 전형적인 컴퓨팅 오버헤드를 줄여줍니다. 이는 액세스 패턴에 맞는 데이터 스토어를 선택하라는 AWS Well-Architected Performance Efficiency 원칙과 일치합니다. Common Misconceptions: 관계형 데이터베이스(RDS MySQL)는 관계를 모델링할 수 있지만, 깊은 재귀 조인(CTE)은 대규모에서 복잡해지고 종종 느려지며, 특히 다단계 탐색 및 상호 연결 계산의 경우 더욱 그렇습니다. DynamoDB는 인접 리스트(adjacency lists)를 저장할 수 있지만, 다중 홉 탐색에는 많은 왕복(GetItem/Query 체인)과 복잡한 애플리케이션 측 로직이 필요하며 지연 시간이 길어질 수 있습니다. S3 + Athena는 지연 시간이 짧고 대화형인 그래프 탐색이 아니라 파일에 대한 분석을 위한 것입니다. Exam Tips: "highly connected data", "many-to-many", "path finding", "mutual friends", "recommendations" 또는 "multi-level traversal"을 보면 그래프 데이터베이스를 떠올리십시오. AWS 시험에서 Amazon Neptune은 빠른 관계 탐색이 필요한 그래프 워크로드를 위한 기본 관리형 서비스입니다. 반대로 Athena는 임시 분석용, RDS는 트랜잭션 관계형 패턴용, DynamoDB는 예측 가능한 한 자리 수 밀리초 조회가 가능한 키-값/문서 액세스 패턴용이며 깊은 그래프 탐색용이 아닙니다.

9
문제 9

글로벌 건강 보험 회사는 매일 100,000건 이상의 보험 청구를 처리하고 3,000만 명 이상의 보험 가입자에게 서비스를 제공합니다. 이 회사는 청구 처리 데이터를 Amazon S3에 저장하고 보험 가입자 정보를 Amazon RDS에 유지 관리합니다. 회사는 분석 목적으로 모든 데이터를 여러 부서(계리, 사기 탐지, 고객 서비스)에서 사용할 수 있도록 하려고 합니다. 솔루션은 세분화된 액세스 제어(fine-grained access control) 기능을 제공하고 운영 오버헤드를 최소화해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

모든 청구 데이터를 RDS로 마이그레이션하는 것은 대규모 분석에 적합하지 않으며 데이터 레이크 접근 방식과 일치하지 않습니다. RDS 액세스 제어는 이 규모의 광범위한 부서 간 분석을 위해 설계되지 않았으며, 대용량 S3 기반 청구 데이터를 OLTP 데이터베이스로 이동하면 비용과 운영 복잡성이 증가합니다. 또한 다양한 데이터 세트 전반에 걸쳐 최상의 세분화된 분석 지향 거버넌스를 제공하지 않습니다.

Lambda와 Glue 크롤러 및 Athena를 사용하여 RDS 데이터를 S3로 복사하면 쿼리가 가능하지만 주로 S3 버킷 정책에 의존하는 경우 세분화된 액세스 제어가 약하거나 복잡해집니다. 테이블/열 수준 권한 및 데이터 세트 전반의 일관된 제어를 위해 추가 거버넌스(예: Lake Formation)가 필요합니다. 주기적인 Lambda 복사도 운영 오버헤드를 추가하며 관리형 수집/거버넌스 패턴에 비해 규모가 커질수록 불안정해질 수 있습니다.

Lake Formation은 중앙 집중식의 세분화된 권한을 갖춘 S3의 관리형 데이터 레이크를 위해 특별히 구축되었습니다. S3 버킷을 등록하면 Lake Formation이 액세스를 관리할 수 있으며, RDS에 대한 Glue JDBC 연결을 사용하면 보험 가입자 데이터를 관리형 환경으로 가져올 수 있습니다(또는 Glue 작업을 통해 카탈로그화/처리). 이는 관리형 거버넌스를 통해 다중 부서 분석, 최소 권한 제어 및 운영 오버헤드 감소에 대한 요구 사항을 충족합니다.

Redshift는 강력한 분석 성능과 액세스 제어를 제공할 수 있지만 더 많은 운영 오버헤드(클러스터 크기 조정, 워크로드 관리, 수집 파이프라인)를 도입하고 일반적으로 지속적인 튜닝/비용 관리가 필요합니다. 요구 사항은 S3 및 RDS 데이터 전반에 걸쳐 최소한의 운영으로 세분화된 액세스 제어를 강조합니다. Lake Formation이 있는 관리형 데이터 레이크가 더 직접적으로 적합합니다. 또한 주기적인 Lambda 기반 로딩은 이 규모에서 이상적인 수집 전략이 아닙니다.

문제 분석

Core Concept: 이 질문은 세분화된 권한과 낮은 운영 오버헤드를 갖춘 관리형 분석 플랫폼(데이터 레이크) 구축을 테스트합니다. 주요 서비스는 AWS Lake Formation(중앙 집중식 데이터 레이크 거버넌스), AWS Glue Data Catalog(메타데이터) 및 S3(데이터 레이크 스토리지)이며 Glue를 통해 Amazon RDS에 연결합니다. Why the Answer is Correct: 옵션 C는 Lake Formation을 사용하여 데이터 레이크를 생성하고, S3 버킷을 등록하며, Glue JDBC 연결을 사용하여 RDS 데이터에 액세스/수집하여 레이크 거버넌스 모델로 가져옵니다. Lake Formation은 여러 분석 소비자 및 엔진(예: Athena, Redshift Spectrum, EMR, Glue) 전반에 걸쳐 중앙 집중식의 세분화된 액세스 제어(LF-Tags 및 권한 부여를 통한 데이터베이스/테이블/열/행 수준)를 제공합니다. 이는 사용자 지정 파이프라인과 분산된 IAM/S3 정책 대신 관리형 권한 모델을 통해 최소 권한을 적용하고 운영 오버헤드를 최소화하면서 여러 부서에서 모든 데이터를 사용할 수 있도록 하는 요구 사항과 직접적으로 일치합니다. Key AWS Features: - Lake Formation 권한: Data Catalog 리소스에 대한 세분화된 권한 부여; 확장 가능한 ABAC 스타일 거버넌스를 위한 LF-Tags; 필요한 경우 교차 계정 공유. - 중앙 집중식 거버넌스: 누가 어떤 테이블/열을 볼 수 있는지 관리하는 단일 장소(예: 고객 서비스는 제한된 PII를 보고, 사기 팀은 더 많은 속성을 봅니다). - Glue Data Catalog와의 통합: S3 데이터 세트에 대한 일관된 메타데이터; RDS 소스에 대한 Glue 연결. - 운영 단순성: 맞춤형 ETL 및 복잡한 정책 확산을 구축/유지 관리하지 않아도 됩니다. AWS Well-Architected Security Pillar(최소 권한, 중앙 집중식 제어) 및 Operational Excellence(관리형 서비스)와 일치합니다. Common Misconceptions: 팀은 종종 S3 버킷 정책만으로 "세분화된 액세스"를 해결하려고 합니다(옵션 B). S3 정책은 강력하지만 테이블/열 수준 거버넌스의 경우 복잡해지며 엔진 전반에 걸쳐 분석 수준 권한을 기본적으로 표현하지 않습니다. 다른 사람들은 혼합된 소스 전반에 걸쳐 최소한의 운영과 강력한 거버넌스를 갖춘 광범위한 부서별 분석이 요구 사항인 경우에도 웨어하우스(옵션 D)를 기본값으로 설정합니다. Exam Tips: "data lake", "multiple departments", "fine-grained access control" 및 "minimize operational overhead"를 보면 Lake Formation + Glue Data Catalog를 생각하십시오. 거버넌스(테이블/열/행 수준, 태그 기반 액세스, 중앙 집중식 권한)가 주요 요구 사항인 경우, 특히 S3를 레이크로 사용하고 여러 분석 페르소나가 데이터를 소비하는 경우 Lake Formation을 선택하십시오.

10
문제 10

한 의료 기관이 환자 관리 및 청구 정보를 저장하는 Microsoft SQL Server 데이터베이스를 on-premises에서 운영하고 있습니다. 이 기관은 AWS 클라우드 인프라로 마이그레이션할 계획이며, 마이그레이션 프로세스 중에 데이터베이스를 최신 SQL Server 버전으로 업그레이드하고자 합니다. 이 기관은 중요한 의료 데이터의 비즈니스 연속성을 보장하기 위해 여러 리전에 걸친 disaster recovery 솔루션이 필요합니다. 일상적인 운영과 DR 구현 모두에서 관리 오버헤드를 최소화해야 합니다. 또한, 의료 규정에서 요구하는 규정 준수 감사 및 사용자 지정 보안 구성을 위해 데이터베이스의 기본 Windows 운영 체제에 대한 전체 액세스 권한을 유지해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

오답입니다. Amazon EC2에서 SQL Server를 실행하면 Windows operating system에 대한 전체 access를 제공하며 SQL Server native replication technologies를 사용해 cross-Region disaster recovery도 지원할 수 있습니다. 그러나 EC2는 organization이 OS, database installation, patching, backups, monitoring, 그리고 DR orchestration까지 직접 관리해야 하므로 가장 많은 administrative effort가 필요합니다. 문제는 일상 운영과 disaster recovery 구현 모두에서 administrative overhead를 최소화하라고 명시하고 있습니다. 따라서 기술적으로는 가능하지만, EC2는 제시된 선택지 중 최적의 답은 아닙니다.

오답입니다. Amazon RDS for SQL Server는 operational overhead를 줄여 주며, cross-Region automated backups는 다른 Region에서 restore 기반 disaster recovery 전략을 지원할 수 있습니다. 그러나 표준 RDS는 기본 Windows operating system에 대한 access를 제공하지 않으므로 compliance 및 custom security configuration 요구 사항을 충족할 수 없습니다. 또한 copied backups는 actively replicated standby environment와 동일하지 않으며 일반적으로 recovery time이 더 길어집니다. 이 선택지는 핵심적인 OS-access 요구 사항을 충족하지 못합니다.

정답입니다. Amazon RDS Custom for SQL Server는 기본 operating system 및 database environment에 대한 access가 필요하면서도 완전히 self-managed인 EC2 deployment보다 더 많은 managed operations의 이점을 얻어야 하는 workload를 위해 특별히 설계되었습니다. 이는 표준 RDS로는 충족할 수 없는 compliance auditing 및 custom security configuration 요구 사항을 직접적으로 만족합니다. 또한 문제는 administrative overhead를 최소화하는 것도 강조하므로, RDS Custom은 SQL Server를 전적으로 EC2에서 실행하는 것보다 더 적합합니다. 제시된 선택지 중 C만이 OS-level access와 reduced operational burden을 모두 충족합니다.

오답입니다. Amazon RDS for SQL Server의 Multi-AZ는 동일한 AWS Region 내의 다른 Availability Zone에 synchronous standby를 유지하여 high availability를 제공합니다. 이는 로컬 infrastructure 장애에는 도움이 되지만, 문제에서 명시적으로 요구하는 여러 Region에 걸친 disaster recovery는 제공하지 않습니다. 또한 표준 RDS는 기본 Windows operating system에 대한 access도 허용하지 않습니다. 따라서 이 선택지는 multi-Region DR 요구 사항과 OS-level access 요구 사항을 모두 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 SQL Server migration 및 upgrade를 지원하고, 여러 Region에 걸친 disaster recovery를 제공하며, administrative overhead를 최소화하면서도 기본 Windows operating system에 대한 access를 허용하는 AWS database 옵션을 묻고 있습니다. 핵심적인 구분 요소는 OS-level access 요구 사항이며, 이로 인해 표준 Amazon RDS for SQL Server는 제외됩니다. 남은 선택지 중에서 가장 적절한 정답은 EC2에서 완전히 self-managed로 운영하는 것보다 administration을 줄이면서도 OS access를 유지하는 managed 옵션입니다. 핵심 기능에는 RDS Custom for SQL Server가 포함되며, 이는 표준 RDS와 달리 customization 및 compliance 요구 사항을 위해 database와 OS access를 제공합니다. 흔한 오해로는 Multi-AZ가 multi-Region DR와 같다는 것, 그리고 표준 RDS가 OS-level access를 허용한다는 것이 있지만 둘 다 사실이 아닙니다. 시험 팁: 문제에서 managed operations와 host-level access를 모두 요구한다면, managed 옵션이 architecture 요구 사항을 명확히 충족할 수 없는 경우가 아니라면 EC2보다 RDS Custom을 우선적으로 떠올리세요.

합격 후기(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 #3

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