모의고사 8

Cache-Control 헤더는 반복 다운로드의 캐싱 동작에는 영향을 줄 수 있지만, 대용량 업로드를 가속하거나 S3까지의 장거리 경로를 최적화하지 않습니다. 주의: S3와 캐싱을 언급하지만, 문제는 양방향 전송 처리량입니다.

EC2와 CloudFront는 서버 관리 부담을 추가하며 주로 캐시된 다운로드에 도움이 됩니다. 2GB~50GB 파일의 빈번한 글로벌 업로드에는 맞지 않습니다. 주의: CloudFront도 엣지 서비스이지만, 글로벌 S3 업로드 가속의 직접적인 시험 답은 아닙니다.

ElastiCache는 인메모리 애플리케이션 데이터용 서비스이지, 여러 대륙 간 수 GB 비디오 객체를 저장하거나 전송하는 서비스가 아닙니다. 주의: cache라는 단어가 유혹적이지만, 작은 핫 데이터 캐싱 문제가 아닙니다.

Directory Service와 신뢰 관계만으로 계정 SSO가 자동 생성되지는 않습니다. IAM Identity Center나 다른 페더레이션 계층이 여전히 필요합니다. 주의: 신뢰 관계는 정답의 일부이지만 SSO 서비스가 빠져 있습니다.

AWS에 호스팅되는 디렉터리를 ID 소스로 사용하면 기존 온프레미스 AD에서 사용자와 그룹을 계속 관리해야 한다는 요구 사항을 충족하지 못합니다. 주의: IAM Identity Center는 포함하지만 기존 디렉터리와의 신뢰가 빠져 있습니다.

EC2의 사용자 지정 IdP는 관리형 AWS ID 통합으로 요구 사항을 충족할 수 있는데도 패치, 가용성, 보안 운영 부담을 추가합니다. 주의: 이론적으로 사용자 지정 페더레이션은 가능하지만, 문제는 표준 관리형 접근 방식을 묻고 있습니다.

여기서는 NAT gateway가 최적의 답이 아닙니다. 인스턴스가 이미 IPv6 주소를 사용하며, AWS에서 네이티브 IPv6 아웃바운드 전용 인터넷 액세스를 제공하는 표준 설계는 egress-only internet gateway입니다. NAT gateway가 DNS64/NAT64를 통해 IPv6-to-IPv4 접근 패턴에 참여할 수는 있지만, private subnet에서 네이티브 IPv6 인터넷 egress를 위한 표준 해법은 아닙니다. 이 요구 사항에는 ::/0을 egress-only internet gateway로 라우팅하여 아웃바운드 연결은 유지하고 인터넷에서 시작하는 IPv6 연결은 방지해야 합니다. 주의: 관련 있어 보이지만, 네이티브 IPv6 아웃바운드 전용 연결 요구 사항을 정답 설계만큼 직접 충족하지 못합니다.

Internet gateway(IGW)는 라우팅된 subnet에 직접 인터넷 경로를 제공합니다. IGW로 기본 경로를 추가하면 IPv6 기준으로 subnet이 인터넷 라우팅 가능해지므로, 이후 SG/NACL에서 차단하더라도 라우팅 계층에서는 인바운드 시작이 가능해집니다. 이는 외부 서비스가 인바운드 연결을 시작할 수 없어야 한다는 요구 사항과 충돌합니다. 주의: 관련 있어 보이지만, 네이티브 IPv6 아웃바운드 전용 연결 요구 사항을 정답 설계만큼 직접 충족하지 못합니다.

Virtual private gateway(VGW)는 Site-to-Site VPN 연결에 사용되며 인터넷 egress 메커니즘이 아닙니다. 인터넷행 트래픽을 VGW로 라우팅해도 외부 데이터 공급자에 대한 일반 인터넷 액세스를 제공하지 못합니다. 이 선택지는 프라이빗 연결(VPN/Direct Connect)과 퍼블릭 인터넷 연결 요구 사항을 혼동하고 있습니다. 주의: 관련 있어 보이지만, 네이티브 IPv6 아웃바운드 전용 연결 요구 사항을 정답 설계만큼 직접 충족하지 못합니다.

Amazon RDS는 관계 데이터를 테이블에 저장할 수 있지만, 역할/그룹/정책 체인을 따라 누가 무엇에 접근할 수 있는지 묻는 쿼리는 많은 조인과 재귀 쿼리가 필요합니다. 깊은 탐색에는 모델링과 유지 관리가 복잡하고 그래프 데이터베이스보다 비효율적일 수 있습니다. 주의: RDS가 관계형이라는 점 때문에 관련 있어 보이지만, 이 문제는 관계형 조인이 아니라 그래프 탐색 최적화를 묻습니다.

Amazon Redshift는 대규모 분석 쿼리와 집계에 최적화된 OLAP 데이터 웨어하우스입니다. 대화형 그래프 탐색이나 관계 경로 쿼리에 맞춰진 서비스가 아닙니다. SQL은 사용할 수 있지만 다중 홉 관계 모델링과 탐색은 번거롭고 비효율적입니다. 주의: Redshift는 분석에는 강하지만 실시간 접근 관계 탐색의 핵심 요구 사항을 직접 충족하지 못합니다.

DynamoDB는 예측 가능한 액세스 패턴을 대규모로 처리하는 키-값/문서 데이터베이스입니다. PartiQL은 SQL과 유사한 쿼리를 제공하지만 DynamoDB가 그래프 탐색을 네이티브로 지원하는 것은 아닙니다. 복잡한 관계는 비정규화, 인접 리스트, GSI, 애플리케이션 측 탐색이 필요해 운영 부담이 커집니다. 주의: DynamoDB가 확장성 있는 저장소처럼 보이지만, 고도로 연결된 보안 관계를 탐색하는 그래프 엔진 요구 사항과는 다릅니다.

수동 스냅샷은 특정 시점의 복사본이지만, 그 자체로 정확한 7년 보존과 삭제를 강제하거나 감사 추적을 제공하지 않습니다. 주의: 스냅샷은 데이터를 보존하지만, 요구 사항은 정책 관리형 보존과 감사 로깅입니다.

Aurora 자동 백업 보존은 이 요구 사항에서 S3 스타일 수명 주기 정책으로 관리되지 않습니다. 주의: 수명 주기라는 표현이 매력적이지만, 자동 데이터베이스 백업은 직접 수명 주기를 적용하는 S3 객체가 아닙니다.

Aurora 자동 백업 보존은 기본 자동 백업만으로 7년으로 단순 설정할 수 없습니다. 주의: 직접적인 답처럼 보이지만, 자동 백업 보존은 제한이 있어 규정 준수 목표에 충분하지 않습니다.

Volume Gateway 스냅샷은 500TB 아카이브를 S3로 직접 파일 마이그레이션하고 무결성을 검증하는 워크플로가 아닙니다. 주의: Storage Gateway는 마이그레이션 연결 수단처럼 들리지만, 자동화된 S3 마이그레이션 검증보다 하이브리드 스토리지 액세스에 맞춰져 있습니다.

Snowcone은 오프라인 엣지 디바이스 옵션이며 증가하는 500TB 데이터의 온라인 마이그레이션에는 가장 적합하지 않습니다. 또한 관리형 지속 전송 워크플로 대신 디바이스 물류가 추가됩니다. 주의: Snow Family 디바이스도 체크섬을 사용하지만, 여기서는 Snowcone 용량과 오프라인 처리가 DataSync만큼 잘 맞지 않습니다.

S3 Transfer Acceleration과 멀티파트 체크섬은 업로드에 도움이 될 수 있지만, 더 많은 사용자 지정 전송 오케스트레이션이 필요하고 DataSync가 제공하는 관리형 종단 간 마이그레이션 워크플로를 제공하지 않습니다. 주의: 체크섬은 무결성 검증처럼 들리지만, 문제는 직접 만든 업로드 절차가 아니라 자동화된 마이그레이션 솔루션을 요구합니다.

애플리케이션 계층이 서버리스인 점은 좋지만, Aurora는 DynamoDB보다 데이터베이스 운영 고려 사항이 더 많은 관계형 데이터베이스 서비스입니다. Aurora Auto Scaling은 보통 읽기 용량 확장이나 데이터베이스 용량 조정을 의미하며, 매우 버스티한 요청 패턴에서 DynamoDB 온디맨드와 같은 운영 모델은 아닙니다. 문제는 관계형 쿼리나 SQL 트랜잭션 필요성을 제시하지 않으므로 Aurora는 명확한 요구 없이 복잡성을 추가합니다. 주의: Lambda와 API Gateway는 관련 있어 보이지만, 인프라 관리 0과 빠른 버스트 확장 요구 사항을 정답 설계만큼 직접 충족하지 못합니다.

DynamoDB를 사용하는 점은 변동 트래픽에 적합하지만, 컴퓨팅 계층이 EC2 인스턴스와 Auto Scaling group에 의존합니다. EC2 Auto Scaling은 AMI 유지, 패치, 스케일링 정책 조정, 인스턴스 수명 주기 처리 같은 인프라 관리를 계속 요구합니다. 새 인스턴스가 시작되고 로드 밸런서 뒤에서 정상 상태가 되기까지 시간이 필요하므로 서버리스 스택만큼 빠르게 반응하지 못할 수도 있습니다. 주의: DynamoDB와 Application Load Balancer는 관련 있어 보이지만, 인프라 관리 0과 빠른 버스트 확장 요구 사항을 정답 설계만큼 직접 충족하지 못합니다.

가장 맞지 않는 선택지입니다. EC2 기반 인프라 관리와, 시나리오에서 명확히 요구하지 않은 관계형 데이터베이스 계층을 함께 사용합니다. ALB, Auto Scaling, Aurora로 고가용성을 설계할 수는 있지만 서버리스 아키텍처보다 운영 노력이 큽니다. EC2 확장은 인스턴스 부팅과 등록 시간이 필요하므로 일반적으로 Lambda 기반 확장보다 느립니다. 주의: Amazon Aurora는 관련 있어 보이지만, 인프라 관리 0과 빠른 버스트 확장 요구 사항을 정답 설계만큼 직접 충족하지 못합니다.

Amazon ECS는 Kubernetes가 아니므로 Kubernetes 매니페스트를 ECS 태스크 정의와 서비스로 변환해야 합니다. 이는 배포 도구와 CI/CD 프로세스 변경을 유발할 가능성이 높아 파이프라인 변경 금지 요구 사항과 충돌합니다. 주의: ECS와 EC2 워커 노드 조합은 컨테이너 실행과 관련 있어 보이지만, 이 문제는 촉박한 일정에서 Kubernetes 및 PostgreSQL 호환성을 묻고 있습니다.

ECS와 Fargate는 컴퓨팅 관리 오버헤드를 줄이고 RDS for PostgreSQL도 적절한 관리형 데이터베이스 선택입니다. 하지만 ECS는 기존 Kubernetes 매니페스트를 직접 재사용할 수 없으므로 오케스트레이션 계층 재플랫폼과 CI/CD 조정이 필요합니다. 주의: ECS Fargate와 RDS 조합은 낮은 운영 부담처럼 보이지만, 이 문제는 촉박한 일정에서 Kubernetes 및 PostgreSQL 호환성을 묻고 있습니다.

Amazon EKS는 Kubernetes 호환성을 유지하고 Aurora PostgreSQL-Compatible도 유효한 관리형 PostgreSQL 호환 데이터베이스입니다. 하지만 EKS on Fargate는 일부 워크로드의 데몬 패턴이나 노드 수준 기능을 EC2 기반 노드만큼 넓게 지원하지 않을 수 있어, 기존 Kubernetes 워크로드를 제한된 일정 안에 이전할 때 위험이 커질 수 있습니다. 주의: EKS와 Aurora PostgreSQL-Compatible은 관련 있어 보이지만, 이 문제는 촉박한 일정에서 기존 Kubernetes 및 PostgreSQL 계층과의 가장 직접적인 호환성을 묻고 있습니다.

FTP가 있는 단일 Lightsail 서버는 단순하지만 패치, 보안, 백업, 복구가 필요한 서버이며 정적 파일에는 S3보다 복원력이 낮습니다. 주의: FTP 친숙성은 유지하지만 정적 콘텐츠에 가장 적합한 관리형 오리진을 놓칩니다.

EC2, Auto Scaling, ALB, FTP 서버는 월별로 업데이트되는 정적 문서에 불필요하게 복잡하고 비용이 큽니다. 주의: 복원력 있게 만들 수는 있지만 정적 포털의 오리진 계층을 과도하게 구성합니다.

S3는 좋은 오리진이지만, 버킷을 퍼블릭으로 만들고 정적 웹 사이트 호스팅을 사용하는 것은 CloudFront OAC로 제한된 프라이빗 버킷보다 약합니다. 주의: Transfer Family는 파일 전송 워크플로를 지원할 수 있지만 퍼블릭 버킷 오리진 설계가 문제입니다.