AWS SAA-C03 Examtopics (581~ 600)

AWS Certified Solutions Architect - Associate 공부하면서 작성된 글로 일부오류가있을수있습니다.

 

■ Question #581

한 회사가 Amazon EC2 인스턴스에서 상태 저장 프로덕션 애플리케이션을 실행합니다. 이 애플리케이션은 항상 실행되려면 최소 두 개의 EC2 인스턴스가 필요합니다. 솔루션 아키텍트는 애플리케이션에 대해 고가용성 및 내결함성 아키텍처를 설계해야 합니다. 솔루션 아키텍트는 EC2 인스턴스의 자동 확장 그룹을 만듭니다. 솔루션

아키텍트는 이러한 요구 사항을 충족하기 위해 어떤 추가 단계를 수행해야 합니까?

A. 자동 확장 그룹의 최소 용량을 2로 설정합니다. 한 가용성 영역에 온디맨드 인스턴스 하나를 배포하고 두 번째 가용성 영역에 온디맨드 인스턴스 하나를 배포합니다.
B. 자동 확장 그룹의 최소 용량을 4로 설정합니다. 한 가용성 영역에 두 개의 온디맨드 인스턴스를 배포하고 두 번째 가용성 영역에 두 개의 온디맨드 인스턴스를 배포합니다.
C. 자동 확장 그룹의 최소 용량을 2로 설정합니다. 하나의 가용성 영역에 4개의 스팟 인스턴스를 배포합니다.
D. 자동 확장 그룹의 최소 용량을 4로 설정합니다. 한 가용성 영역에 두 개의 온디맨드 인스턴스를 배포하고 두 번째 가용성 영역에 두 개의 스팟 인스턴스를 배포합니다.

B. 자동 확장 그룹의 최소 용량을 4로 설정합니다. 한 가용성 영역에 두 개의 온디맨드 인스턴스를 배포하고 두 번째 가용성 영역에 두 개의 온디맨드 인스턴스를 배포합니다.

고가용성(High Availability)
- 최소 두 개의 가용 영역(AZ)에 리소스를 배치하여 한 AZ에서 문제가 발생하더라도 다른 AZ의 리소스가 애플리케이션을 계속 실행할 수 있습니다.

내결함성(Fault Tolerance)
- 각 AZ에 두 개의 인스턴스를 배치함으로써 한 AZ에서 장애가 발생해도 최소 두 개의 인스턴스가 남아 애플리케이션이 중단되지 않습니다.

AWS 모범 사례 준수
- AWS는 다중 AZ 배포와 AZ당 여러 인스턴스를 배치하는 방식을 권장합니다.
- B는 이러한 모범 사례를 충족하며, A는 이를 충족하지 못합니다.

---

■ Question #582

전자상거래 회사가 DNS 공급자로 Amazon Route 53을 사용합니다. 이 회사는 사내 및 AWS 클라우드에서 웹사이트를 호스팅합니다. 이 회사의 사내 데이터 센터는 us-west-1 지역 근처에 있습니다. 이 회사는 eu-central-1 지역을 사용하여 웹사이트를 호스팅합니다. 이 회사는 웹사이트의 로드 시간을 최대한 최소화하려고 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 지리적 위치 라우팅 정책을 설정합니다. us-west-1 근처의 트래픽을 온프레미스 데이터 센터로 보냅니다. eu-central-1 근처의 트래픽을 eu-central-1로 보냅니다.
B. eu-central-1 근처의 모든 트래픽을 eu-central-1로 라우팅하고 온프레미스 데이터 센터 근처의 모든 트래픽을 온프레미스 데이터 센터로 라우팅하는 간단한 라우팅 정책을 설정합니다.
C. 대기 시간 라우팅 정책을 설정합니다. 정책을 us-west-1과 연결합니다.
D. 가중치가 적용된 라우팅 정책을 설정합니다. eu-central-1과 온프레미스 데이터 센터 간에 트래픽을 균등하게 분할합니다.

A. 지리적 위치 라우팅 정책을 설정합니다. us-west-1 근처의 트래픽을 온프레미스 데이터 센터로 보냅니다. eu-central-1 근처의 트래픽을 eu-central-1로 보냅니다.

전자상거래 회사는 로드 시간을 최소화하고 웹사이트 성능을 최적화하기 위해 사용자 트래픽을 지리적으로 가까운 리소스로 라우팅해야 합니다. 각 지역의 사용자 트래픽을 특정 리소스로 보내는 지리적 위치 라우팅 정책은 다음과 같은 이유로 적합합니다.

지리적 위치 라우팅 정책의 기능
- 지리적 위치 라우팅 정책은 사용자의 물리적 위치(예: 국가 또는 지역)를 기준으로 트래픽을 라우팅합니다.
- us-west-1 근처 트래픽은 온프레미스 데이터 센터로, eu-central-1 근처 트래픽은 eu-central-1로 라우팅될 수 있습니다.

최소 로드 시간
- 사용자를 지리적으로 가까운 데이터 센터 또는 AWS 리소스로 연결하여 대기 시간을 줄이고 로드 시간을 최소화합니다.

부하 분산을 간소화
- 회사의 요구 사항에 따라 사용자를 특정 리소스로 라우팅할 수 있어 더 나은 제어와 효율성을 제공합니다.

---

■ Question #583

어떤 회사가 물리적 테이프에 5PB의 보관 데이터를 보관하고 있습니다. 이 회사는 규정 준수를 위해 테이프의 데이터를 10년 더 보존해야 합니다. 이 회사는 앞으로 6개월 안에 AWS로 마이그레이션하려고 합니다. 테이프를 보관하는 데이터 센터는 1Gbps 업링크 인터넷 연결을 갖추고 있습니다.

어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적으로 충족할까요?

A. 온프레미스 테이프에서 데이터를 읽습니다. 로컬 NFS 스토리지에 데이터를 스테이징합니다. AWS DataSync를 사용하여 데이터를 Amazon S3 Glacier Flexible Retrieval로 마이그레이션합니다.
B. 온프레미스 백업 애플리케이션을 사용하여 테이프에서 데이터를 읽고 Amazon S3 Glacier Deep Archive에 직접 씁니다.

C. Tape Gateway가 있는 여러 AWS Snowball 장치를 주문합니다. Snowball의 가상 테이프에 물리적 테이프를 복사합니다. Snowball 장치를 AWS로 배송합니다. 테이프를 Amazon S3 Glacier Deep Archive로 이동하는 수명 주기 정책을 만듭니다.
D. 온프레미스 테이프 게이트웨이를 구성합니다. AWS 클라우드에서 가상 테이프를 만듭니다. 백업 소프트웨어를 사용하여 물리적 테이프를 가상 테이프에 복사합니다.

C. Tape Gateway가 있는 여러 AWS Snowball 장치를 주문합니다. Snowball의 가상 테이프에 물리적 테이프를 복사합니다. Snowball 장치를 AWS로 배송합니다. 테이프를 Amazon S3 Glacier Deep Archive로 이동하는 수명 주기 정책을 만듭니다.

데이터 전송 속도와 효율성
- AWS Snowball 장치는 대규모 데이터를 물리적으로 AWS로 전송할 수 있는 고속 옵션입니다.
- 5PB 데이터를 1Gbps 인터넷 연결로 전송하면 약 480일이 걸립니다. Snowball을 사용하면 훨씬 더 빠르게 데이터를 AWS로 전송할 수 있습니다.

Tape Gateway를 활용한 간편한 마이그레이션
- Tape Gateway를 사용하면 기존 백업 워크플로를 변경하지 않고도 물리적 테이프를 가상 테이프로 복사할 수 있습니다.
- Snowball의 가상 테이프는 AWS로 물리적으로 운송되며, 데이터는 Amazon S3 Glacier Deep Archive로 이동됩니다.

비용 효율성
- AWS Snowball은 대규모 데이터 전송에 대해 인터넷 기반 전송보다 비용 효율적입니다.
- Amazon S3 Glacier Deep Archive는 장기적인 데이터 보존을 위해 설계된 가장 저렴한 AWS 스토리지 옵션입니다.

규정 준수와 보안
- AWS Snowball과 Tape Gateway는 데이터 암호화를 지원하며, 데이터 전송 중 보안을 보장합니다.
- 데이터를 Amazon S3 Glacier Deep Archive로 이동하면 규정 준수를 위한 안전한 보관이 가능합니다.

---

■ Question #584

한 회사가 대량의 데이터를 병렬로 처리하는 애플리케이션을 배포하고 있습니다. 이 회사는 워크로드에 Amazon EC2 인스턴스를 사용할 계획입니다. 네트워크 아키텍처는 노드 그룹이 동일한 기본 하드웨어를 공유하지 못하도록 구성 가능해야 합니다.

어떤 네트워킹 솔루션이 이러한 요구 사항을 충족합니까?

A. EC2 인스턴스를 분산된 배치 그룹에서 실행합니다.
B. EC2 인스턴스를 별도 계정으로 그룹화합니다.
C. 전용 테넌시로 EC2 인스턴스를 구성합니다.
D. 공유 테넌시로 EC2 인스턴스를 구성합니다.

A. EC2 인스턴스를 분산된 배치 그룹에서 실행합니다.

병렬 데이터 처리를 위한 EC2 인스턴스 배포에서 "노드 그룹이 동일한 기본 하드웨어를 공유하지 못하도록" 요구하는 경우, 분산된 배치 그룹(Spread Placement Group)을 사용하는 것이 적합합니다.

분산된 배치 그룹(Spread Placement Group)
- 분산된 배치 그룹은 각 EC2 인스턴스를 서로 다른 기본 하드웨어로 분리합니다.
- 이는 하드웨어 장애로 인해 다수의 인스턴스가 동시에 영향을 받지 않도록 보장합니다.
- 높은 가용성과 복원력을 요구하는 병렬 처리 애플리케이션에 이상적입니다.

중복 및 장애 예방
- 동일한 하드웨어를 공유하지 않으므로, 하드웨어 장애가 발생해도 영향을 받는 인스턴스의 수를 최소화할 수 있습니다.

확장성
- 분산된 배치 그룹은 병렬 작업 노드가 필요한 대규모 처리 작업에서 요구되는 확장성을 지원합니다.

---

■ Question #585

솔루션 아키텍트가 장애 조치 AWS 지역에서 Amazon EC2 용량을 제공하기 위해 재해 복구(DR) 전략을 설계하고 있습니다. 비즈니스 요구 사항에 따르면 DR 전략은 장애 조치 지역의 용량을 충족해야 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 장애 조치 지역에서 온디맨드 인스턴스를 구매합니다.
B. 장애 조치 지역에서 EC2 절약 계획을 구매합니다.
C. 장애 조치 지역에서 지역별 예약 인스턴스를 구매합니다.
D. 장애 조치 지역에서 용량 예약을 구매합니다.

D. 장애 조치 지역에서 용량 예약을 구매합니다.

장애 조치(Disaster Recovery) 전략에서 중요한 것은 장애가 발생할 경우, 장애 조치 지역에서 필요한 EC2 용량이 즉시 가용하도록 보장하는 것입니다.

용량 예약(Capacity Reservation)의 특성
- 특정 가용성 영역(AZ)에서 지정된 수량의 EC2 인스턴스 용량을 사전에 예약합니다.
- 예약된 용량은 온디맨드와 예약 인스턴스 모두에서 사용할 수 있으므로, 재해 발생 시 즉시 사용 가능합니다.
- 인스턴스가 생성되기 전에 용량을 확보해 두므로 장애 조치 시 EC2 용량 부족을 방지합니다.

장애 조치 대비
- 장애 조치 DR 전략에서 중요한 점은 장애 발생 시 용량을 보장하는 것입니다.
- 용량 예약은 이와 같은 요구 사항에 맞춰 설계되었습니다.

---

■ Question #586

회사는 AWS Organizations에서 조직의 일부로 5개의 조직 단위(OU)를 가지고 있습니다. 각 OU는 회사가 소유한 5개 사업과 상관 관계가 있습니다. 회사의 연구 개발(R&D) 사업은 회사와 분리되어 자체 조직이 필요합니다. 솔루션 아키텍트는 이 목적을 위해 별도의 새 관리 계정을 만듭니다.

솔루션 아키텍트는 새 관리 계정에서 다음에 무엇을 해야 합니까?

A. 전환 기간 동안 R&D AWS 계정이 두 조직에 모두 속하게 합니다.
B. R&D AWS 계정이 이전 조직을 떠난 후 R&D AWS 계정을 새 조직에 초대합니다.
C. 새 조직에서 새 R&D AWS 계정을 만듭니다. 이전 R&D AWS 계정에서 새 R&D AWS 계정으로 리소스를 마이그레이션합니다.
D. R&D AWS 계정을 새 조직에 가입시킵니다. 새 관리 계정을 이전 조직의 멤버로 만듭니다.

B. R&D AWS 계정이 이전 조직을 떠난 후 R&D AWS 계정을 새 조직에 초대합니다.

R&D AWS 계정을 이전 조직에서 분리
- AWS Organizations는 각 계정이 한 번에 하나의 조직에만 속할 수 있습니다.
- 따라서 기존 조직에서 R&D AWS 계정을 떠나게 한 뒤 새 조직으로 초대해야 합니다.

R&D AWS 계정을 새 조직으로 초대
- 새로 만든 관리 계정을 사용하여 새 조직에 R&D 계정을 초대하면 R&D 계정이 새 조직의 일부가 됩니다.

---

■ Question #587

한 회사가 분석을 처리하고 예측을 하기 위해 다양한 웹 애플리케이션에서 고객 활동을 포착하는 솔루션을 설계하고 있습니다. 웹 애플리케이션에서의 고객 활동은 예측할 수 없으며 갑자기 증가할 수 있습니다. 이 회사는 다른 웹 애플리케이션과 통합되는 솔루션이 필요합니다. 솔루션에는 보안을 위한 권한 부여 단계가 포함되어야 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. Amazon Elastic Container Service(Amazon ECS) 컨테이너 인스턴스 앞에 게이트웨이 로드 밸런서(GWLB)를 구성하여 회사가 Amazon Elastic File System(Amazon EFS) 파일 시스템에서 수신하는 정보를 저장합니다. 권한 부여는 GWLB에서 해결됩니다.
B. Amazon S3 버킷에서 회사가 수신하는 정보를 저장하는 Amazon Kinesis 데이터 스트림 앞에 Amazon API Gateway 엔드포인트를 구성합니다. AWS Lambda 함수를 사용하여 권한을 확인합니다.
C. Amazon S3 버킷에서 회사가 수신하는 정보를 저장하는 Amazon Kinesis Data Firehose 앞에 Amazon API Gateway 엔드포인트를 구성합니다. API Gateway Lambda 권한 부여자를 사용하여 권한을 확인합니다.
D. Amazon Elastic Container Service(Amazon ECS) 컨테이너 인스턴스 앞에 게이트웨이 로드 밸런서(GWLB)를 구성하여 회사가 Amazon Elastic File System(Amazon EFS) 파일 시스템에서 수신하는 정보를 저장합니다. AWS Lambda 함수를 사용하여 권한을 확인합니다.

요구사항 분석
- 예측 불가능한 고객 활동 및 갑작스러운 증가 처리: 이를 위해 Amazon Kinesis Data Firehose를 사용하여 데이터를 실시간으로 수집하고 저장할 수 있습니다.
- 다른 웹 애플리케이션과 통합: Amazon API Gateway는 다른 애플리케이션과 통합하는 RESTful API를 제공합니다.
- 보안을 위한 권한 부여 단계: API Gateway Lambda 권한 부여자를 사용하여 요청을 인증하고 권한을 확인할 수 있습니다.

C. Amazon S3 버킷에서 회사가 수신하는 정보를 저장하는 Amazon Kinesis Data Firehose 앞에 Amazon API Gateway 엔드포인트를 구성합니다. API Gateway Lambda 권한 부여자를 사용하여 권한을 확인합니다.

API Gateway
- Amazon API Gateway는 웹 애플리케이션에서 데이터를 수집하기 위한 안전하고 확장 가능한 엔드포인트를 제공합니다.

Kinesis Data Firehose
- Amazon Kinesis Data Firehose는 실시간 데이터 스트림을 처리할 수 있으며, 데이터를 S3와 같은 스토리지에 자동으로 저장할 수 있습니다.
- 갑작스러운 데이터 급증을 효율적으로 처리합니다.

Lambda 권한 부여자
- API Gateway에서 AWS Lambda를 사용하여 사용자 인증 및 권한 부여를 처리할 수 있습니다.
- 보안을 강화하고 액세스를 제어하는 데 적합합니다.

---

■ Question #588

전자상거래 회사가 Microsoft SQL Server Enterprise Edition을 실행하는 Amazon RDS DB 인스턴스에 대한 재해 복구 솔루션을 원합니다. 회사의 현재 복구 지점 목표(RPO)와 복구 시간 목표(RTO)는 24시간입니다.

어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적으로 충족할까요?

A. 지역 간 읽기 복제본을 만들고 읽기 복제본을 기본 인스턴스로 승격합니다.
B. AWS Database Migration Service(AWS DMS)를 사용하여 RDS 지역 간 복제를 생성합니다.
C. 24시간마다 지역 간 복제를 사용하여 기본 백업을 Amazon S3 버킷으로 복사합니다.
D. 24시간마다 다른 지역으로 자동 스냅샷을 복사합니다.

D. 24시간마다 다른 지역으로 자동 스냅샷을 복사합니다.

RPO와 RTO 24시간 충족
- Amazon RDS는 자동으로 스냅샷을 생성할 수 있으며, 스냅샷을 다른 AWS 지역으로 복사하면 재해 발생 시 해당 스냅샷을 사용해 복구할 수 있습니다.
- 복구 시 복원 및 데이터베이스 프로비저닝이 포함되므로 RTO는 24시간 이내에 충족 가능합니다.

비용 효율성
- 스냅샷 복사는 데이터 스토리지 비용만 발생하며 읽기 복제본과 같은 지속적인 리소스 소비가 없습니다.
- 이는 다른 옵션에 비해 훨씬 비용 효율적입니다.

---

■ Question #589

한 회사가 스티키 세션이 활성화된 애플리케이션 로드 밸런서 뒤의 자동 확장 그룹에서 Amazon EC2 인스턴스에서 웹 애플리케이션을 실행합니다. 웹 서버는 현재 사용자 세션 상태를 호스팅합니다. 이 회사는 웹 서버 중단 시 고가용성을 보장하고 사용자 세션 상태 손실을 방지하고자 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. Amazon ElastiCache for Memcached 인스턴스를 사용하여 세션 데이터를 저장합니다. ElastiCache for Memcached를 사용하여 세션 상태를 저장하도록 애플리케이션을 업데이트합니다.
B. Amazon ElastiCache for Redis를 사용하여 세션 상태를 저장합니다. ElastiCache for Redis를 사용하여 세션 상태를 저장하도록 애플리케이션을 업데이트합니다.
C. AWS Storage Gateway 캐시 볼륨을 사용하여 세션 데이터를 저장합니다. AWS Storage Gateway 캐시 볼륨을 사용하여 세션 상태를 저장하도록 애플리케이션을 업데이트합니다.
D. Amazon RDS를 사용하여 세션 상태를 저장합니다. Amazon RDS를 사용하여 세션 상태를 저장하도록 애플리케이션을 업데이트합니다.

B. Amazon ElastiCache for Redis를 사용하여 세션 상태를 저장합니다. ElastiCache for Redis를 사용하여 세션 상태를 저장하도록 애플리케이션을 업데이트합니다.

Amazon ElastiCache for Redis는 세션 데이터를 저장하기 위한 이상적인 솔루션입니다. 이 솔루션은 다음과 같은 이유로 애플리케이션 로드 밸런서(ALB) 뒤의 고가용성과 사용자 세션 상태를 보장합니다.

ElastiCache for Redis가 적합한 이유
고성능 데이터 저장
- Redis는 메모리 내 데이터 저장소로 세션 상태를 빠르게 읽고 쓸 수 있습니다.
- 초당 많은 요청을 처리해야 하는 웹 애플리케이션에 적합합니다.

내결함성
- ElastiCache for Redis는 클러스터 모드 및 다중 AZ 배포를 지원하여 데이터 손실을 방지합니다.
- 인스턴스 장애 시에도 데이터가 유지됩니다.

세션 공유
- 세션 데이터를 중앙 저장소로 Redis에 저장하면, 모든 EC2 인스턴스가 동일한 세션 데이터를 공유할 수 있습니다.
- 이는 EC2 인스턴스가 교체되더라도 세션 데이터가 유지되도록 보장합니다.

운영 오버헤드 감소
- 관리형 서비스로 제공되므로, 운영 및 유지보수 부담이 줄어듭니다.

---

■ Question #590

한 회사가 회사의 온프레미스 데이터 센터에서 MySQL 데이터베이스를 Amazon RDS for MySQL DB 인스턴스로 마이그레이션했습니다. 이 회사는 회사의 평균 일일 작업 부하에 맞게 RDS DB 인스턴스의 크기를 조정했습니다. 한 달에 한 번, 회사에서 보고서에 대한 쿼리를 실행할 때 데이터베이스가 느리게 실행됩니다. 이 회사는 보고서를 실행하고 일일 작업 부하의 성능을 유지할 수 있는 기능을 원합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 데이터베이스의 읽기 복제본을 만듭니다. 쿼리를 읽기 복제본으로 보냅니다.
B. 데이터베이스의 백업을 만듭니다. 백업을 다른 DB 인스턴스로 복원합니다. 쿼리를 새 데이터베이스로 보냅니다.
C. 데이터를 Amazon S3로 내보냅니다. Amazon Athena를 사용하여 S3 버킷을 쿼리합니다.
D. 추가 작업 부하를 수용할 수 있도록 DB 인스턴스 크기를 조정합니다.

A. 데이터베이스의 읽기 복제본을 만듭니다. 쿼리를 읽기 복제본으로 보냅니다.

보고서 쿼리 실행 시 데이터베이스 성능이 저하되는 문제를 해결하려면, 읽기 트래픽을 오프로드하여 기본 데이터베이스의 성능을 유지하는 것이 중요합니다. Amazon RDS 읽기 복제본은 이러한 요구를 충족하는 가장 적합한 솔루션입니다.

왜 읽기 복제본이 적합한가?
읽기 트래픽 오프로드
- 읽기 복제본은 기본 데이터베이스와 데이터를 동기화하며 읽기 요청만 처리합니다.
- 보고서 실행과 같은 읽기 집약적인 작업을 읽기 복제본으로 전환하여 기본 데이터베이스의 부하를 줄일 수 있습니다.

운영 간소화
- 읽기 복제본은 관리형 서비스로 운영 오버헤드가 적습니다.
- 별도의 구성 없이 손쉽게 읽기 복제본에서 쿼리를 실행할 수 있습니다.

실시간 데이터 가용성
- 읽기 복제본은 기본 데이터베이스와 실시간으로 동기화됩니다.
- 보고서가 항상 최신 데이터를 기반으로 생성됩니다.

비용 효율성
- 한 달에 한 번 실행되는 보고서 작업을 위해 기본 DB 인스턴스를 과도하게 크기를 조정하는 것보다 비용 효율적입니다.

---

■ Question #591

한 회사가 Amazon Elastic Kubernetes Service(Amazon EKS)를 사용하여 컨테이너 애플리케이션을 실행합니다. 이 애플리케이션에는 고객을 관리하고 주문을 하는 마이크로서비스가 포함되어 있습니다. 이 회사는 들어오는 요청을 적절한 마이크로서비스로 라우팅해야 합니다.

어떤 솔루션이 이 요구 사항을 가장 비용 효율적으로 충족할까요?

A. AWS Load Balancer Controller를 사용하여 네트워크 로드 밸런서를 프로비저닝합니다.
B. AWS Load Balancer Controller를 사용하여 Application Load Balancer를 프로비저닝합니다.
C. AWS Lambda 함수를 사용하여 요청을 Amazon EKS에 연결합니다.
D. Amazon API Gateway를 사용하여 요청을 Amazon EKS에 연결합니다.

B. AWS Load Balancer Controller를 사용하여 Application Load Balancer를 프로비저닝합니다.

AmazonEKS에서 마이크로서비스를 실행하며 들어오는 요청을 적절한 마이크로서비스로 라우팅하려면 AWS Load Balancer Controller를 사용하여 Application Load Balancer (ALB) 를 프로비저닝하는 것이 가장 적합하고 비용 효율적인 선택입니다.

애플리케이션 계층 라우팅
- ALB는 HTTP 및 HTTPS 요청에 대해 호스트 기반 및 경로 기반 라우팅을 지원합니다. 이를 통해 특정 요청을 특정 마이크로서비스로 라우팅할 수 있습니다.
- 예:  '/customer' 요청은 고객 마이크로서비스로, '/orders' 요청은 주문 마이크로서비스로 라우팅.

AWS Load Balancer Controller
- AWS Load Balancer Controller는 EKS 클러스터에서 자동으로 ALB를 프로비저닝하고 관리합니다.
- Kubernetes Ingress 리소스를 사용하여 라우팅 규칙을 쉽게 설정할 수 있습니다.

비용 효율성
- ALB는 트래픽을 효과적으로 분배하고, 마이크로서비스 기반 애플리케이션에서 널리 사용됩니다.
- 온디맨드 기반으로 실행되며, 불필요한 추가 컴퓨팅 리소스를 사용하지 않습니다.

통합 관리
- Kubernetes와 완벽하게 통합되며, 관리 오버헤드가 적습니다.
- ALB의 모니터링과 로깅 기능은 애플리케이션 성능 분석에도 유용합니다.

---

■ Question #592

한 회사가 AWS를 사용하고 저작권이 있는 이미지에 대한 액세스를 판매합니다. 이 회사의 글로벌 고객 기반은 이러한 이미지에 빠르게 액세스할 수 있어야 합니다. 이 회사는 특정 국가의 사용자에게 액세스를 거부해야 합니다. 이 회사는 가능한 한 비용을 최소화하려고 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. Amazon S3를 사용하여 이미지를 저장합니다. 다중 요소 인증(MFA) 및 퍼블릭 버킷 액세스를 켭니다. 고객에게 S3 버킷 링크를 제공합니다.
B. Amazon S3를 사용하여 이미지를 저장합니다. 각 고객에 대해 IAM 사용자를 만듭니다. S3 버킷에 액세스할 수 있는 권한이 있는 그룹에 사용자를 추가합니다.
C. Application Load Balancer(ALB) 뒤에 있는 Amazon EC2 인스턴스를 사용하여 이미지를 저장합니다. 회사가 서비스를 제공하는 국가에만 인스턴스를 배포합니다. 고객에게 해당 국가의 인스턴스에 대한 ALB 링크를 제공합니다.
D. Amazon S3를 사용하여 이미지를 저장합니다. Amazon CloudFront를 사용하여 지리적 제한이 있는 이미지를 배포합니다. 각 고객이 CloudFront의 데이터에 액세스할 수 있도록 서명된 URL을 제공합니다.

D. Amazon S3를 사용하여 이미지를 저장합니다. Amazon CloudFront를 사용하여 지리적 제한이 있는 이미지를 배포합니다. 각 고객이 CloudFront의 데이터에 액세스할 수 있도록 서명된 URL을 제공합니다.

글로벌 콘텐츠 배포
- Amazon CloudFront는 전 세계적으로 450개 이상의 엣지 로케이션을 사용하여 고객이 S3 버킷의 이미지를 빠르게 액세스할 수 있도록 지원합니다.
- 글로벌 고객 기반에 대한 짧은 대기 시간을 제공합니다.

지리적 제한 (Geo-Restriction)
- CloudFront의 지리적 제한(Geo-Restriction) 기능을 사용하여 특정 국가의 사용자를 차단할 수 있습니다.
- 지정된 허용 또는 차단 목록에 따라 콘텐츠 액세스를 제어합니다.

서명된 URL을 통한 보안
- 서명된 URL은 인증된 고객만 콘텐츠에 액세스하도록 보장합니다.
- 각 사용자에게 개별적으로 URL을 발급하여 불법 공유를 방지할 수 있습니다.

비용 효율성
- CloudFront는 캐싱을 통해 요청 수와 S3에서의 데이터 전송 비용을 줄입니다.
- 동적 콘텐츠보다 정적 콘텐츠(이미지)에 더 적합한 솔루션입니다.

---

■ Question #593

솔루션 아키텍트는 Redis 기반 솔루션을 위한 고가용성 Amazon ElastiCache를 설계하고 있습니다. 솔루션 아키텍트는 장애로 인해 로컬 및 AWS 리전 내에서 성능 저하 또는 데이터 손실이 발생하지 않도록 해야 합니다. 솔루션은 노드 수준과 리전 수준에서 고가용성을 제공해야 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 여러 노드가 포함된 샤드가 있는 다중 AZ Redis 복제 그룹을 사용합니다.
B. Redis 추가 전용 파일(AOF)이 켜진 여러 노드가 포함된 Redis 샤드를 사용합니다.
C. 복제 그룹에 두 개 이상의 읽기 복제본이 있는 다중 AZ Redis 클러스터를 사용합니다.
D. 자동 크기 조정이 켜진 여러 노드가 포함된 Redis 샤드를 사용합니다.

A. 여러 노드가 포함된 샤드가 있는 다중 AZ Redis 복제 그룹을 사용합니다.

노드 수준 고가용성
- 다중 AZ 배포를 통해 기본 노드(primary node)와 하나 이상의 복제 노드(replica node)를 다른 가용성 영역(AZ)에 배치하여 고가용성을 보장합니다.
- 기본 노드 장애 시 복제 노드 중 하나를 자동으로 승격(failover)하여 서비스 연속성을 유지합니다.

리전 내 성능 보장
- 동일한 리전 내에서 각 AZ에 복제본이 있기 때문에 데이터 손실 없이 안정적으로 고성능을 제공합니다.

Redis 복제 그룹
- 복제 그룹은 데이터가 노드 간에 자동으로 동기화되도록 보장하므로 데이터 일관성을 유지합니다.

샤드(Shard)
- 데이터를 여러 샤드로 분산하여 확장성과 읽기/쓰기 성능을 극대화합니다.

---

■ Question #594

한 회사가 AWS로 마이그레이션하고 Amazon EC2 On-Demand Instances를 애플리케이션에 사용할 계획입니다. 마이그레이션 테스트 단계에서 기술 팀은 애플리케이션이 완전히 생산적이 되기 위해 메모리를 시작하고 로드하는 데 오랜 시간이 걸린다는 것을 관찰했습니다.

다음 테스트 단계에서 애플리케이션의 시작 시간을 줄이는 솔루션은 무엇입니까?

A. 두 개 이상의 EC2 온디맨드 인스턴스를 시작합니다. 자동 스케일링 기능을 켜고 다음 테스트 단계에서 EC2 온디맨드 인스턴스를 사용할 수 있도록 합니다.
B. 애플리케이션을 지원하고 다음 테스트 단계에서 사용할 수 있도록 애플리케이션을 확장하기 위해 EC2 Spot 인스턴스를 시작합니다.
C. 최대 절전 모드를 켜고 EC2 온디맨드 인스턴스를 시작합니다. 다음 테스트 단계에서 EC2 자동 확장 웜 풀을 구성합니다.
D. 용량 예약으로 EC2 온디맨드 인스턴스 시작. 다음 테스트 단계에서 추가 EC2 인스턴스를 시작합니다.

C. 최대 절전 모드를 켜고 EC2 온디맨드 인스턴스를 시작합니다. 다음 테스트 단계에서 EC2 자동 확장 웜 풀을 구성합니다.

애플리케이션이 시작 및 로드 시간 동안 메모리를 초기화하는 데 오랜 시간이 걸리는 문제가 있을 경우, EC2 인스턴스의 최대 절전 모드와 웜 풀(Warm Pool)을 사용하는 것이 시작 시간을 줄이는 가장 적합한 방법입니다.

최대 절전 모드(Hibernation)
- 최대 절전 모드는 인스턴스의 메모리(RAM) 상태를 유지하여 다음 번 시작 시 메모리 초기화 단계를 건너뛸 수 있습니다.
- 애플리케이션이 메모리 로드 및 초기화에 시간이 걸리는 경우, 최대 절전 모드는 시작 시간을 크게 줄일 수 있습니다.

웜 풀(Warm Pool)
- 웜 풀은 EC2 Auto Scaling에서 인스턴스를 미리 준비해 두어 필요할 때 빠르게 시작할 수 있도록 지원합니다.
- 인스턴스가 대기 상태에서 필요할 때 활성화되므로 애플리케이션 시작 시간이 단축됩니다.

결합된 효과
- 최대 절전 모드와 웜 풀을 함께 사용하면, 인스턴스가 메모리 상태를 유지한 채로 대기 상태에 있을 수 있어 테스트 단계에서 즉각적인 응답성과 빠른 시작을 제공합니다.

---

■ Question #595

회사의 애플리케이션은 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행됩니다. 이 회사는 애플리케이션이 주중 임의의 요일에 갑자기 트래픽이 증가하는 것을 알아차렸습니다. 이 회사는 갑자기 트래픽이 증가하는 동안 애플리케이션 성능을 유지하고자 합니다.

어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적으로 충족할까요?

A. 수동 크기 조정을 사용하여 자동 크기 조정 그룹의 크기를 변경합니다.
B. 예측적 크기 조정을 사용하여 자동 크기 조정 그룹의 크기를 변경합니다.
C. 자동 크기 조정 그룹의 크기를 변경하려면 동적 크기 조정을 사용합니다.
D. 일정 크기 조정을 사용하여 자동 크기 조정 그룹의 크기를 변경합니다.

C. 자동 크기 조정 그룹의 크기를 변경하려면 동적 크기 조정을 사용합니다.
- 동적 크기 조정은 애플리케이션의 트래픽 증가와 같은 갑작스러운 변화에 빠르게 반응할 수 있도록 자동으로 EC2 인스턴스를 확장하거나 축소하는 데 적합합니다. 이를 통해 트래픽 증가 동안 성능을 유지하면서 비용 효율성을 유지할 수 있습니다.

---

■ Question #596

전자상거래 애플리케이션은 Amazon EC2 인스턴스에서 실행되는 PostgreSQL 데이터베이스를 사용합니다. 월별 판매 이벤트 동안 데이터베이스 사용량이 증가하고 애플리케이션에 대한 데이터베이스 연결 문제가 발생합니다. 이후 월별 판매 이벤트의 트래픽은 예측할 수 없으며, 이는 판매 예측에 영향을 미칩니다. 회사는 트래픽이 예측할 수 없이 증가할 때 성과를 유지해야 합니다.

어떤 솔루션이 이 문제를 가장 비용 효율적인 방식으로 해결합니까?

A. PostgreSQL 데이터베이스를 Amazon Aurora Serverless v2로 마이그레이션합니다.
B. EC2 인스턴스에서 PostgreSQL 데이터베이스에 대한 자동 크기 조정을 활성화하여 사용량 증가에 대처합니다.
C. 더 큰 인스턴스 유형을 사용하여 PostgreSQL 데이터베이스를 Amazon RDS for PostgreSQL로 마이그레이션합니다.
D. 증가된 사용량을 수용하기 위해 PostgreSQL 데이터베이스를 Amazon Redshift로 마이그레이션합니다.

A. PostgreSQL 데이터베이스를 Amazon Aurora Serverless v2로 마이그레이션합니다.
- Amazon Aurora Serverless v2는 자동으로 확장 및 축소할 수 있어 예측할 수 없는 트래픽 증가에 대해 적응하는 데 적합합니다. 월별 판매 이벤트 동안 데이터베이스 사용량이 증가하면 Aurora Serverless v2는 필요에 따라 처리 용량을 빠르게 확장하여 성능 문제를 방지합니다. 이벤트 후 트래픽이 줄어들면 자동으로 용량을 줄여 비용을 최적화합니다.

---

■ Question #597

한 회사가 Amazon API Gateway와 AWS Lambda를 사용하여 AWS에서 내부 서버리스 애플리케이션을 호스팅합니다. 회사 직원들은 매일 애플리케이션을 사용하기 시작할 때 지연 시간이 길다는 문제를 보고합니다. 회사는 지연 시간을 줄이고자 합니다.

어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. API Gateway 제한을 늘립니다.
B. 직원들이 매일 애플리케이션을 사용하기 전에 Lambda 프로비저닝 동시성을 늘리기 위해 예약된 확장을 설정합니다.
C. 매일 시작 시 알람 대상으로 Lambda 함수를 시작하기 위해 Amazon CloudWatch 알람을 생성합니다.
D. 람다 함수 메모리를 늘립니다.

B. 직원들이 매일 애플리케이션을 사용하기 전에 Lambda 프로비저닝 동시성을 늘리기 위해 예약된 확장을 설정합니다.
- AWS Lambda의 콜드 스타트 문제는 함수가 첫 번째 호출에서 초기화되는 데 시간이 걸리는 경우 발생하며, 특히 지연 시간이 길다는 보고와 관련됩니다. 이 문제는 프로비저닝된 동시성을 설정하여 해결할 수 있습니다. 프로비저닝된 동시성은 콜드 스타트 없이 즉시 호출할 준비가 된 컨테이너를 유지하여 초기 지연 시간을 줄입니다.
- 예약된 확장을 사용하면 매일 애플리케이션 사용 전에 프로비저닝된 동시성을 설정하여 지연 시간을 줄이고 필요하지 않을 때 비용을 절감할 수 있습니다.

---

■ Question #598

연구 회사는 온프레미스 장치를 사용하여 분석용 데이터를 생성합니다. 이 회사는 AWS 클라우드를 사용하여 데이터를 분석하려고 합니다. 이 장치는 .csv 파일을 생성하고 SMB 파일 공유에 데이터를 쓰는 것을 지원합니다. 회사 분석가는 SQL 명령을 사용하여 데이터를 쿼리할 수 있어야 합니다. 분석가는 하루 종일 주기적으로 쿼리를 실행합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 단계 조합은 무엇입니까? (세 가지를 선택하십시오.)

A. Amazon S3 파일 게이트웨이 모드에서 온프레미스에 AWS Storage Gateway를 배포합니다.
B. Amazon FSx File Gateway에서 온프레미스에 AWS Storage Gateway를 배포합니다.
C. Amazon S3에 있는 데이터를 기반으로 테이블을 생성하기 위해 AWS Glue 크롤러를 설정합니다.
D. Amazon S3에 있는 데이터를 쿼리하기 위해 EMR 파일 시스템(EMRFS)을 사용하여 Amazon EMR 클러스터를 설정합니다. 분석가에게 액세스를 제공합니다.
E. Amazon S3에 있는 데이터를 쿼리하기 위해 Amazon Redshift 클러스터를 설정합니다. 분석가에게 액세스를 제공합니다.
F. Amazon S3에 있는 데이터를 쿼리하기 위해 Amazon Athena를 설정합니다. 분석가에게 액세스를 제공합니다.

A. Amazon S3 파일 게이트웨이 모드에서 온프레미스에 AWS Storage Gateway를 배포합니다.
- 장치가 SMB 파일 공유를 지원하기 때문에 Amazon S3 File Gateway는 데이터를 SMB를 통해 온프레미스에서 AWS로 전송하는 데 적합합니다. 게이트웨이는 데이터를 Amazon S3로 자동 업로드합니다.

C. Amazon S3에 있는 데이터를 기반으로 테이블을 생성하기 위해 AWS Glue 크롤러를 설정합니다.
- AWS Glue 크롤러는 S3에 저장된 .csv 데이터를 스캔하고 메타데이터를 생성하여 데이터 카탈로그를 만듭니다. 이는 데이터를 SQL 기반 도구(Athena)로 쿼리할 수 있도록 준비합니다.

F. Amazon S3에 있는 데이터를 쿼리하기 위해 Amazon Athena를 설정합니다. 분석가에게 액세스를 제공합니다.
- Amazon Athena는 서버리스 SQL 쿼리 서비스로, 데이터를 Amazon S3에서 직접 쿼리할 수 있습니다. 분석가는 SQL 명령을 사용하여 데이터를 효율적으로 쿼리할 수 있습니다.

---

■ Question #599

한 회사에서 Amazon Elastic Container Service(Amazon ECS) 클러스터와 Amazon RDS DB 인스턴스를 사용하여 결제 처리 애플리케이션을 빌드하고 실행하려고 합니다. 이 회사는 규정 준수 목적으로 온프레미스 데이터 센터에서 애플리케이션을 실행합니다. 솔루션 아키텍트는 AWS Outposts를 솔루션의 일부로 사용하려고 합니다. 솔루션 아키텍트는 회사의 운영 팀과 협력하여 애플리케이션을 빌드합니다.

어떤 활동이 회사 운영 팀의 책임입니까? (세 가지를 선택하십시오.)

A. Outposts 랙에 탄력적인 전원 및 네트워크 연결 제공
B. Outposts에서 실행되는 가상화 하이퍼바이저, 스토리지 시스템 및 AWS 서비스 관리
C. 데이터 센터 환경의 물리적 보안 및 접근 제어
D. Outposts 랙 내의 전원 공급 장치, 서버 및 네트워킹 장비를 포함한 Outposts 인프라의 가용성
E. 전초기지 구성요소의 물리적 유지 관리
F. 서버 오류 및 유지 관리 이벤트를 완화하기 위해 Amazon ECS 클러스터에 추가 용량 제공

A. Outposts 랙에 탄력적인 전원 및 네트워크 연결 제공
- AWS Outposts가 원활히 작동하려면 안정적인 전원과 네트워크 연결이 필요합니다. 이 인프라는 고객이 제공해야 합니다.

C. 데이터 센터 환경의 물리적 보안 및 접근 제어
- 고객은 데이터 센터의 물리적 보안을 유지해야 합니다. Outposts는 고객 데이터 센터에 배치되므로 보안은 고객의 책임입니다.

F. 서버 오류 및 유지 관리 이벤트를 완화하기 위해 Amazon ECS 클러스터에 추가 용량 제공
- 애플리케이션의 가용성을 유지하기 위해 ECS 클러스터에 충분한 용량을 제공하는 것은 고객의 운영 팀이 관리해야 할 작업입니다.

---

■ Question #600

한 회사가 TCP 기반 애플리케이션을 회사의 VPC로 마이그레이션할 계획입니다. 이 애플리케이션은 회사 데이터 센터의 하드웨어 어플라이언스를 통해 비표준 TCP 포트에서 공개적으로 액세스할 수 있습니다. 이 퍼블릭 엔드포인트는 낮은 지연 시간으로 초당 최대 300만 개의 요청을 처리할 수 있습니다. 이 회사는 AWS의 새로운 퍼블릭 엔드포인트에 대해 동일한 수준의 성능이 필요합니다.

솔루션 아키텍트는 이 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?

A. 네트워크 로드 밸런서(NLB)를 배포합니다. 애플리케이션에 필요한 TCP 포트를 통해 공개적으로 액세스할 수 있도록 NLB를 구성합니다.
B. 애플리케이션 로드 밸런서(ALB)를 배포합니다. 애플리케이션에 필요한 TCP 포트를 통해 ALB를 공개적으로 액세스할 수 있도록 구성합니다.
C. 애플리케이션에 필요한 TCP 포트에서 수신 대기하는 Amazon CloudFront 배포를 배포합니다. Application Load Balancer를 원본으로 사용합니다.
D. 애플리케이션에 필요한 TCP 포트로 구성된 Amazon API Gateway API를 배포합니다. 프로비저닝된 동시성을 사용하여 AWS Lambda 함수를 구성하여 요청을 처리합니다.

A. 네트워크 로드 밸런서(NLB)를 배포합니다. 애플리케이션에 필요한 TCP 포트를 통해 공개적으로 액세스할 수 있도록 NLB를 구성합니다.

고성능 처리 능력
- NLB는 초당 수백만 개의 요청을 처리할 수 있는 매우 높은 처리량을 지원하며, TCP와 같은 비표준 프로토콜 및 포트를 사용할 수 있습니다.
- 이 애플리케이션은 초당 최대 300만 요청을 처리해야 하므로 NLB가 적합합니다.

낮은 지연 시간
- NLB는 네트워크 계층(Layer 4)에서 작동하며, 낮은 지연 시간으로 빠르게 요청을 전달할 수 있습니다.
- 애플리케이션의 낮은 지연 시간 요구사항을 충족합니다.

비표준 TCP 포트 지원
- NLB는 TCP/UDP를 기본적으로 지원하며, 비표준 포트에서도 작동할 수 있습니다.