AWS SAA-C03 Examtopics (561 ~ 580)

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

 

■ Question #561

회사 웹사이트는 매일 수백만 건의 요청을 처리하고 있으며, 요청 수는 계속 증가하고 있습니다. 솔루션 아키텍트는 웹 애플리케이션의 응답 시간을 개선해야 합니다. 솔루션 아키텍트는 애플리케이션이 Amazon DynamoDB 테이블에서 제품 세부 정보를 검색할 때 대기 시간을 줄여야 한다고 판단합니다.

어떤 솔루션이 운영 오버헤드를 최소화하면서 이러한 요구 사항을 충족할까요?

A. DynamoDB Accelerator(DAX) 클러스터를 설정합니다. 모든 읽기 요청을 DAX를 통해 라우팅합니다.
B. DynamoDB 테이블과 웹 애플리케이션 사이에 Redis용 Amazon ElastiCache를 설정합니다. 모든 읽기 요청을 Redis를 통해 라우팅합니다.
C. DynamoDB 테이블과 웹 애플리케이션 사이에 Memcached용 Amazon ElastiCache를 설정합니다. 모든 읽기 요청을 Memcached를 통해 라우팅합니다.
D. 테이블에 Amazon DynamoDB Streams를 설정하고 AWS Lambda가 테이블에서 읽고 Amazon ElastiCache를 채우도록 합니다. 모든 읽기 요청을 ElastiCache를 통해 라우팅합니다.

A. DynamoDB Accelerator(DAX) 클러스터를 설정합니다. 모든 읽기 요청을 DAX를 통해 라우팅합니다.
- DAX는 DynamoDB의 기본 제공 인메모리 캐싱 솔루션으로, 읽기 작업의 대기 시간을 밀리초에서 마이크로초로 줄일 수 있습니다.
- DynamoDB와 완벽히 통합되며, 애플리케이션 코드를 약간만 수정하면 됩니다.
- 운영 오버헤드가 낮고, DynamoDB와의 호환성 및 사용 편의성이 뛰어납니다.

DAX의 이점
- DAX는 DynamoDB의 읽기 캐싱을 위한 턴키 솔루션입니다.
- 개발자가 추가적인 캐시 관리 로직을 작성할 필요가 없으므로 운영 오버헤드가 최소화됩니다.

---

■ Question #562

솔루션 아키텍트는 VPC의 Amazon EC2 인스턴스에서 Amazon DynamoDB로의 API 호출이 인터넷을 통과하지 않도록 해야 합니다.
솔루션 아키텍트는 이 요구 사항을 충족하기 위해 어떤 단계 조합을 취해야 합니까? (두 가지를 선택하세요.)

A. 엔드포인트에 대한 경로 테이블 항목을 만듭니다.
B. DynamoDB에 대한 게이트웨이 엔드포인트를 생성합니다.
C. Amazon EC2에 대한 인터페이스 엔드포인트를 생성합니다.
D. VPC의 각 서브넷에 있는 엔드포인트에 대한 탄력적 네트워크 인터페이스를 생성합니다.
E. 액세스를 제공하기 위해 엔드포인트의 보안 그룹에 보안 그룹 항목을 만듭니다.

A. 엔드포인트에 대한 경로 테이블 항목을 만듭니다.
- 게이트웨이 엔드포인트를 생성하면 이를 사용하는 VPC 서브넷의 라우팅 테이블에 경로를 추가해야 VPC 내부에서 DynamoDB로의 트래픽이 라우팅됩니다.
- 예를 들어, 라우팅 테이블에 `com.amazonaws.<region>.dynamodb`로의 경로를 추가해야 트래픽이 인터넷을 통하지 않고 VPC 엔드포인트를 통해 DynamoDB로 전달됩니다.

B. DynamoDB에 대한 게이트웨이 엔드포인트를 생성합니다.
- DynamoDB는 게이트웨이 엔드포인트를 사용하여 VPC 내부에서 인터넷을 통하지 않고 직접 연결할 수 있습니다.
- Amazon S3와 함께 게이트웨이 엔드포인트를 지원하는 서비스입니다.
- 게이트웨이 엔드포인트는 VPC에서 특정 AWS 서비스로의 트래픽을 라우팅할 수 있도록 설정합니다.

---

■ Question #563

한 회사가 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터와 온프레미스 Kubernetes 클러스터에서 모두 애플리케이션을 실행합니다. 이 회사는 중앙 위치에서 모든 클러스터와 워크로드를 보고 싶어합니다.

어떤 솔루션이 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. Amazon CloudWatch Container Insights를 사용하여 클러스터 정보를 수집하고 그룹화합니다.
B. Amazon EKS Connector를 사용하여 모든 Kubernetes 클러스터를 등록하고 연결합니다.
C. AWS Systems Manager를 사용하여 클러스터 정보를 수집하고 확인합니다.
D. Amazon EKS Anywhere를 기본 클러스터로 사용하여 기본 Kubernetes 명령을 사용하여 다른 클러스터를 확인합니다.

B. Amazon EKS Connector를 사용하여 모든 Kubernetes 클러스터를 등록하고 연결합니다.
- Amazon EKS Connector는 Amazon EKS 클러스터와 온프레미스 Kubernetes 클러스터를 AWS 관리 콘솔에 통합할 수 있도록 도와줍니다.
- EKS Connector를 사용하면 AWS Management Console에서 중앙 위치에서 모든 Kubernetes 클러스터와 워크로드를 볼 수 있습니다.
- 운영 오버헤드가 낮으며, 클러스터 상태 및 워크로드 상태를 한눈에 확인할 수 있습니다.

---

■ Question #564

어떤 회사가 전자상거래 애플리케이션을 구축하고 있으며 민감한 고객 정보를 저장해야 합니다. 이 회사는 고객에게 웹사이트에서 구매 거래를 완료할 수 있는 기능을 제공해야 합니다. 또한 이 회사는 데이터베이스 관리자로부터도 민감한 고객 데이터가 보호되도록 해야 합니다.

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

A. Amazon Elastic Block Store(Amazon EBS) 볼륨에 민감한 데이터를 저장합니다. EBS 암호화를 사용하여 데이터를 암호화합니다. IAM 인스턴스 역할을 사용하여 액세스를 제한합니다.
B. Amazon RDS for MySQL에 민감한 데이터를 저장합니다. AWS Key Management Service(AWS KMS) 클라이언트 측 암호화를 사용하여 데이터를 암호화합니다.
C. Amazon S3에 민감한 데이터를 저장합니다. AWS Key Management Service(AWS KMS) 서버 측 암호화를 사용하여 데이터를 암호화합니다. S3 버킷 정책을 사용하여 액세스를 제한합니다.
D. Amazon FSx for Windows Server에 민감한 데이터를 저장합니다. 애플리케이션 서버에 파일 공유를 마운트합니다. Windows 파일 권한을 사용하여 액세스를 제한합니다.

B. Amazon RDS for MySQL에 민감한 데이터를 저장합니다. AWS Key Management Service(AWS KMS) 클라이언트 측 암호화를 사용하여 데이터를 암호화합니다.

민감한 고객 데이터 보호 요구 사항
- Amazon RDS for MySQL은 내장된 데이터 암호화 기능을 제공하며, 데이터베이스를 관리하는 사용자가 암호화된 데이터를 직접 볼 수 없습니다.
- AWS KMS를 사용한 클라이언트 측 암호화를 통해 데이터를 암호화하여 데이터베이스 관리자로부터도 데이터를 보호할 수 있습니다.
- RDS의 Transparent Data Encryption(TDE)과 KMS 통합은 민감한 데이터 보호에 적합합니다.

데이터 암호화와 액세스 관리
- AWS KMS를 사용하면 민감한 데이터에 대한 암호화 키를 AWS에서 안전하게 관리할 수 있습니다.
- 데이터베이스 관리자는 암호화 키를 관리할 수 없으며, 애플리케이션 계층에서만 데이터 복호화가 가능합니다.

---

■ Question #565

한 회사에는 거래 데이터를 처리하는 온프레미스 MySQL 데이터베이스가 있습니다. 이 회사는 데이터베이스를 AWS 클라우드로 마이그레이션하고 있습니다. 마이그레이션된 데이터베이스는 데이터베이스를 사용하는 회사의 애플리케이션과 호환성을 유지해야 합니다. 마이그레이션된 데이터베이스는 또한 수요가 증가하는 기간 동안 자동으로 확장되어야 합니다.

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

A. 네이티브 MySQL 도구를 사용하여 데이터베이스를 Amazon RDS for MySQL로 마이그레이션합니다. 탄력적 스토리지 확장을 구성합니다.
B. mysqldump 유틸리티를 사용하여 데이터베이스를 Amazon Redshift로 마이그레이션합니다. Amazon Redshift 클러스터에 대한 자동 확장을 켭니다.
C. AWS Database Migration Service(AWS DMS)를 사용하여 데이터베이스를 Amazon Aurora로 마이그레이션합니다. Aurora Auto Scaling을 켭니다.
D. AWS Database Migration Service(AWS DMS)를 사용하여 데이터베이스를 Amazon DynamoDB로 마이그레이션합니다. 자동 확장 정책을 구성합니다.

C. AWS Database Migration Service(AWS DMS)를 사용하여 데이터베이스를 Amazon Aurora로 마이그레이션합니다. Aurora Auto Scaling을 켭니다.

호환성과 애플리케이션 호환성
- Amazon Aurora는 MySQL과 호환되는 관계형 데이터베이스 엔진을 제공하며, 온프레미스 MySQL 데이터베이스와의 호환성을 유지할 수 있습니다.
- 이로 인해 기존 애플리케이션 코드 및 데이터베이스와의 호환성을 유지하면서 마이그레이션이 가능합니다.

자동 확장 기능
- Amazon Aurora는 Aurora Auto Scaling을 통해 읽기 복제본을 자동으로 확장하여 수요가 증가하는 시점에 데이터베이스 성능을 유지할 수 있습니다.
- 읽기 작업이 많은 워크로드에서 특히 유용합니다.

AWS DMS를 통한 간편한 마이그레이션
- AWS Database Migration Service(AWS DMS)를 사용하면 데이터베이스를 온라인으로 복사할 수 있어 다운타임을 최소화하면서 클라우드로의 전환이 가능합니다.

---

■ Question #566

한 회사가 두 개의 가용성 영역에 걸쳐 VPC에서 여러 Amazon EC2 Linux 인스턴스를 실행합니다. 인스턴스는 계층적 디렉토리 구조를 사용하는 애플리케이션을 호스팅합니다. 애플리케이션은 공유 스토리지에 빠르게 동시에 읽고 쓸 수 있어야 합니다.

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

A. Amazon S3 버킷을 만듭니다. VPC의 모든 EC2 인스턴스에서 액세스를 허용합니다.
B. Amazon Elastic File System(Amazon EFS) 파일 시스템을 만듭니다. 각 EC2 인스턴스에서 EFS 파일 시스템을 마운트합니다.
C. Provisioned IOPS SSD(io2) Amazon Elastic Block Store(Amazon EBS) 볼륨에 파일 시스템을 만듭니다. EBS 볼륨을 모든 EC2 인스턴스에 연결합니다.
D. 각 EC2 인스턴스에 연결된 Amazon Elastic Block Store(Amazon EBS) 볼륨에 파일 시스템을 만듭니다. 다양한 EC2 인스턴스에서 EBS 볼륨을 동기화합니다.

B. Amazon Elastic File System(Amazon EFS) 파일 시스템을 만듭니다. 각 EC2 인스턴스에서 EFS 파일 시스템을 마운트합니다.

공유 스토리지와 동시 액세스
- Amazon EFS는 여러 Amazon EC2 인스턴스에서 동시에 액세스할 수 있는 완전 관리형 네트워크 파일 시스템(NFS)입니다.
- 계층적 디렉토리 구조를 지원하며, 애플리케이션이 데이터를 동시에 빠르게 읽고 쓸 수 있습니다.

고가용성과 내구성
- EFS는 여러 가용성 영역(AZ)에 걸쳐 작동하며 데이터가 자동으로 복제됩니다.
- 이는 두 개의 가용성 영역에 걸쳐 실행되는 EC2 인스턴스에 적합합니다.

운영 오버헤드 감소
- EFS는 완전 관리형 서비스로, 파일 시스템 관리, 확장, 백업을 자동으로 처리합니다.
- 운영 오버헤드를 최소화하면서 요구 사항을 충족합니다.

---

■ Question #567

솔루션 아키텍트는 건물 내 사업체 세입자의 시간당 에너지 소비량을 저장하는 워크로드를 설계하고 있습니다. 센서는 각 세입자의 사용량을 합산하는 HTTP 요청을 통해 데이터베이스에 공급합니다. 솔루션 아키텍트는 가능한 경우 관리형 서비스를 사용해야 합니다. 솔루션 아키텍트가 독립적인 구성 요소를 추가함에 따라 워크로드는 향후 더 많은 기능을 받게 됩니다.

어떤 솔루션이 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. AWS Lambda 함수와 함께 Amazon API Gateway를 사용하여 센서에서 데이터를 수신하고, 데이터를 처리하고, 해당 데이터를 Amazon DynamoDB 테이블에 저장합니다.
B. Amazon EC2 인스턴스의 Auto Scaling 그룹에서 지원하는 Elastic Load Balancer를 사용하여 센서에서 데이터를 수신하고 처리합니다. Amazon S3 버킷을 사용하여 처리된 데이터를 저장합니다.
C. AWS Lambda 함수와 함께 Amazon API Gateway를 사용하여 센서로부터 데이터를 수신하고, 데이터를 처리하고, 해당 데이터를 Amazon EC2 인스턴스의 Microsoft SQL Server Express 데이터베이스에 저장합니다.
D. Amazon EC2 인스턴스의 Auto Scaling 그룹에서 지원하는 Elastic Load Balancer를 사용하여 센서에서 데이터를 수신하고 처리합니다. Amazon Elastic File System(Amazon EFS) 공유 파일 시스템을 사용하여 처리된 데이터를 저장합니다.

A. AWS Lambda 함수와 함께 Amazon API Gateway를 사용하여 센서에서 데이터를 수신하고, 데이터를 처리하고, 해당 데이터를 Amazon DynamoDB 테이블에 저장합니다.

최소 운영 오버헤드
- Amazon API Gateway는 HTTP 요청을 처리하는 완전 관리형 서비스로, 센서 데이터를 수신하기에 적합합니다.
- AWS Lambda는 서버리스 환경에서 데이터를 처리하며, 워크로드 크기에 따라 자동으로 확장됩니다.
- Amazon DynamoDB는 서버리스 NoSQL 데이터베이스로 관리 오버헤드가 없고, 확장성 및 고가용성을 제공합니다.

확장성 및 관리형 서비스 사용
- Lambda와 DynamoDB는 둘 다 관리형 서비스로, 솔루션이 자동으로 확장되며 인프라 관리가 필요 없습니다.
- 이 조합은 향후 추가 기능이 필요할 때도 유연성과 확장성을 제공합니다.

독립적 구성 요소와의 통합
- 이 솔루션은 API Gateway, Lambda, DynamoDB를 결합하여 독립적으로 관리되고 확장 가능한 구성 요소를 사용합니다.
- Lambda를 사용하여 추가 비즈니스 로직이나 독립적인 기능을 쉽게 추가할 수 있습니다.

---

■ Question #568

솔루션 아키텍트는 엔지니어링 도면을 저장하고 보는 데 사용되는 새로운 웹 애플리케이션의 스토리지 아키텍처를 설계하고 있습니다. 모든 애플리케이션 구성 요소는 AWS 인프라에 배포됩니다. 애플리케이션 설계는 사용자가 엔지니어링 도면이 로드될 때까지 기다리는 시간을 최소화하기 위해 캐싱을 지원해야 합니다. 애플리케이션은 페타바이트 규모의 데이터를 저장할 수 있어야 합니다.

솔루션 아키텍트는 어떤 스토리지와 캐싱 조합을 사용해야 합니까?

A. Amazon CloudFront를 갖춘 Amazon S3
B. Amazon ElastiCache를 탑재한 Amazon S3 Glacier
C. Amazon CloudFront를 사용한 Amazon Elastic Block Store(Amazon EBS) 볼륨
D. Amazon ElastiCache를 사용한 AWS Storage Gateway

A. Amazon CloudFront를 갖춘 Amazon S3

페타바이트 규모의 데이터 저장
- Amazon S3는 페타바이트 이상의 데이터를 저장할 수 있는 완전 관리형 객체 스토리지 서비스입니다. 높은 내구성과 확장성을 제공하며, 엔지니어링 도면과 같은 대규모 데이터 세트를 저장하는 데 적합합니다.

캐싱을 통한 대기 시간 최소화
- Amazon CloudFront는 글로벌 콘텐츠 전송 네트워크(CDN)로, 캐싱을 통해 사용자가 데이터에 빠르게 접근할 수 있도록 합니다. S3와 통합하여 도면을 저장하고 이를 전 세계적으로 저지연으로 제공할 수 있습니다.

완전 관리형 솔루션
- S3와 CloudFront 조합은 운영 오버헤드가 낮아 관리가 용이합니다. 특히 글로벌 사용자에게 빠른 콘텐츠 전송이 중요한 웹 애플리케이션에 적합합니다.

---

■ Question #569

Amazon EventBridge 규칙은 타사 API를 대상으로 합니다. 타사 API는 들어오는 트래픽을 수신하지 않았습니다. 솔루션 아키텍트는 규칙 조건이 충족되는지, 규칙의 대상이 호출되는지 확인해야 합니다.

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

A. AWS/Events 네임스페이스의 Amazon CloudWatch에서 메트릭을 확인합니다.
B. Amazon Simple Queue Service(Amazon SQS) 배달 못한 편지 대기열의 이벤트를 검토합니다.
C. Amazon CloudWatch Logs에서 이벤트를 확인합니다.
D. AWS CloudTrail에서 EventBridge 이벤트에 대한 추적 내용을 확인하세요.

A. AWS/Events 네임스페이스의 Amazon CloudWatch에서 메트릭을 확인합니다.

Amazon EventBridge의 메트릭 제공
- EventBridge는 AWS/Events 네임스페이스를 사용하여 규칙이 트리거되고 대상이 호출되는지에 대한 메트릭을 제공합니다.
- 이를 통해 타사 API가 호출되었는지 확인할 수 있습니다.
- 예: 'Invocations' 및 'FailedInvocations' 메트릭을 통해 규칙의 대상 호출 상태를 확인할 수 있습니다.

실시간 상태 확인
- CloudWatch의 메트릭은 실시간으로 동작 상태를 모니터링할 수 있는 가장 적합한 방법입니다.
- 특히 EventBridge 대상 호출 여부를 빠르게 확인할 수 있습니다.

---

■ Question #570

어떤 회사에서 매주 금요일 저녁에 실행되는 대규모 워크로드가 있습니다. 워크로드는 us-east-1 지역의 두 가용성 영역에 있는 Amazon EC2 인스턴스에서 실행됩니다. 일반적으로 회사는 항상 두 개 이상의 인스턴스를 실행해서는 안 됩니다. 그러나 회사는 매주 금요일에 최대 6개의 인스턴스로 확장하여 정기적으로 반복되는 증가된 워크로드를 처리하려고 합니다.

어떤 솔루션이 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. Amazon EventBridge에서 인스턴스를 확장하기 위한 알림을 만듭니다.
B. 예약된 작업이 있는 자동 크기 조정 그룹을 만듭니다.
C. 수동 크기 조정을 사용하는 자동 크기 조정 그룹을 만듭니다.
D. 자동 크기 조정을 사용하는 자동 크기 조정 그룹을 만듭니다.

B. 예약된 작업이 있는 자동 크기 조정 그룹을 만듭니다.

예약된 작업으로 정기적인 스케줄링 지원
- Amazon EC2 자동 크기 조정 그룹은 예약된 작업을 통해 특정 시간에 자동으로 확장 및 축소를 수행할 수 있습니다.
- 매주 금요일 저녁과 같이 예측 가능한 워크로드 증가에 적합한 설정입니다.
- 예를 들어, 금요일 저녁에 최대 인스턴스를 6개로 늘리고, 작업이 끝난 후 기본 상태로 축소하도록 예약할 수 있습니다.

운영 오버헤드 감소
- 예약된 작업은 자동으로 수행되므로 운영 팀에서 수동으로 조정하거나 추가 작업을 수행할 필요가 없습니다.
- 설정 후 최소한의 관리로 자동으로 확장/축소를 관리합니다.

---

■ Question #571

어떤 회사가 REST API를 만들고 있습니다. 이 회사는 TLS 사용에 대한 엄격한 요구 사항을 가지고 있습니다. 이 회사는 API 엔드포인트에서 TLSv1.3을 요구합니다. 또한 이 회사는 특정 공공 제3자 인증 기관(CA)이 TLS 인증서에 서명하도록 요구합니다.

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

A. 로컬 머신을 사용하여 타사가 서명한 인증서를 만듭니다. 인증서를 AWS Certificate Manager(ACM)로 가져옵니다. 사용자 지정 도메인이 있는 Amazon API Gateway에서 HTTP API를 만듭니다. 인증서를 사용하도록 사용자 지정 도메인을 구성합니다.
B. AWS Certificate Manager(ACM)에서 타사 CA가 서명한 인증서를 만듭니다. 사용자 지정 도메인이 있는 Amazon API Gateway에서 HTTP API를 만듭니다. 인증서를 사용하도록 사용자 지정 도메인을 구성합니다.
C. AWS Certificate Manager(ACM)를 사용하여 타사 CA에서 서명한 인증서를 만듭니다. 인증서를 AWS Certificate Manager(ACM)로 가져옵니다. Lambda 함수 URL로 AWS Lambda 함수를 만듭니다. 인증서를 사용하도록 Lambda 함수 URL을 구성합니다.
D. AWS Certificate Manager(ACM)에서 타사 CA가 서명한 인증서를 만듭니다. Lambda 함수 URL로 AWS Lambda 함수를 만듭니다. 인증서를 사용하도록 Lambda 함수 URL을 구성합니다.

A. 로컬 머신을 사용하여 타사가 서명한 인증서를 만듭니다. 인증서를 AWS Certificate Manager(ACM)로 가져옵니다. 사용자 지정 도메인이 있는 Amazon API Gateway에서 HTTP API를 만듭니다. 인증서를 사용하도록 사용자 지정 도메인을 구성합니다.

TLSv1.3 및 사용자 지정 인증서 요구 사항 충족
- AWS Certificate Manager(ACM)는 TLSv1.3을 지원하지만, 특정 제3자 인증 기관(CA)에서 서명한 인증서를 발급하려면 직접 인증서를 생성하고 해당 인증서를 ACM으로 가져와야 합니다.
- 로컬 머신에서 타사 인증서를 생성하고 이를 ACM으로 가져오면, TLSv1.3 요구 사항과 타사 CA 요구 사항을 모두 충족할 수 있습니다.

API Gateway와의 통합
- Amazon API Gateway는 사용자 지정 도메인을 설정하여 ACM 인증서를 연결할 수 있습니다.
- HTTP API 또는 REST API에서 사용자 지정 도메인을 구성할 때 TLS 인증서를 적용할 수 있습니다.

ACM으로 인증서 가져오기
- ACM을 통해 가져온 타사 인증서를 관리하면 인증서 갱신 등의 추가 작업이 간소화됩니다.

---

■ Question #572

한 회사가 AWS에서 애플리케이션을 실행합니다. 애플리케이션은 일관되지 않은 양의 사용량을 수신합니다. 애플리케이션은 AWS Direct Connect를 사용하여 온프레미스 MySQL 호환 데이터베이스에 연결합니다. 온프레미스 데이터베이스는 최소 2GiB의 메모리를 지속적으로 사용합니다. 회사는 온프레미스 데이터베이스를 관리형 AWS 서비스로 마이그레이션하려고 합니다. 회사는 자동 확장 기능을 사용하여 예상치 못한 작업 부하 증가를 관리하려고 합니다.

어떤 솔루션이 최소한의 관리 오버헤드로 이러한 요구 사항을 충족할까요?

A. 기본 읽기 및 쓰기 용량 설정으로 Amazon DynamoDB 데이터베이스를 프로비저닝합니다.
B. 최소 1 Aurora 용량 단위(ACU)의 용량을 갖춘 Amazon Aurora 데이터베이스를 프로비저닝합니다.
C. 최소 1 Aurora 용량 단위(ACU)의 용량을 갖춘 Amazon Aurora Serverless v2 데이터베이스를 프로비저닝합니다.
D. 2GiB 메모리가 있는 Amazon RDS for MySQL 데이터베이스를 프로비저닝합니다.

C. 최소 1 Aurora 용량 단위(ACU)의 용량을 갖춘 Amazon Aurora Serverless v2 데이터베이스를 프로비저닝합니다.

관리형 서비스 요구 사항
- 회사는 온프레미스 MySQL 호환 데이터베이스를 AWS 관리형 서비스로 마이그레이션하려고 합니다.
- Amazon Aurora는 MySQL 호환 관리형 데이터베이스로, 관리 오버헤드를 줄이고 고성능과 내구성을 제공합니다.

자동 확장 기능
- Amazon Aurora Serverless v2는 용량을 자동으로 조정하여 사용량에 따라 확장 및 축소할 수 있습니다.
- 예상치 못한 작업 부하 증가 시 자동 확장을 통해 필요할 때만 리소스를 사용하므로 비용 효율적입니다.

지속적인 메모리 요구 사항 충족
- Aurora Serverless v2는 최소 용량 단위(ACU)를 설정할 수 있어 지속적인 2GiB 메모리 사용량을 쉽게 충족할 수 있습니다.
- 1 ACU는 약 2GiB의 메모리 용량을 제공하므로 최소 용량을 1 ACU로 설정하면 기본 메모리 요구 사항을 충족할 수 있습니다.

---

■ Question #573

한 회사가 AWS Lambda에서 이벤트 기반 프로그래밍 모델을 사용하고자 합니다. 이 회사는 Java 11에서 실행되는 Lambda 함수의 시작 지연 시간을 줄이고자 합니다. 이 회사는 애플리케이션에 대한 엄격한 지연 시간 요구 사항이 없습니다. 이 회사는 함수가 확장될 때 콜드 스타트와 이상치 지연 시간을 줄이고자 합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족할 솔루션은 무엇입니까?

A. Lambda 프로비저닝 동시성을 구성합니다.
B. 람다 함수의 시간 초과를 늘립니다.
C. 람다 함수의 메모리를 늘립니다.
D. Lambda SnapStart를 구성합니다.

D. Lambda SnapStart를 구성합니다.

Lambda SnapStart
- Lambda SnapStart는 Java 기반 AWS Lambda 함수에서 콜드 스타트 시간을 크게 줄이도록 설계되었습니다.
- 이 기능은 함수의 초기화 단계를 미리 저장한 스냅샷을 생성하고, 이후 호출 시 해당 스냅샷을 사용하여 빠르게 초기화합니다.
- 특히, Java와 같은 언어에서 콜드 스타트 지연 시간을 줄이는 데 매우 효과적입니다.

엄격한 지연 시간 요구 사항 없음
- 문제에서 애플리케이션이 엄격한 지연 시간 요구 사항이 없다고 명시되었기 때문에 SnapStart를 사용하면 함수 확장 시 콜드 스타트 문제를 효율적으로 해결할 수 있습니다.

확장성과 비용 효율성
- SnapStart는 요청에 따라 필요한 시점에만 스냅샷을 활용하므로, 프로비저닝 동시성과 같은 고정 비용을 발생시키지 않습니다.
- 따라서 비용 효율적으로 확장성과 콜드 스타트 문제를 동시에 해결할 수 있습니다.

---

■ Question #574

금융 서비스 회사가 Amazon RDS for MySQL 데이터베이스를 사용하는 새로운 애플리케이션을 출시했습니다. 이 회사는 이 애플리케이션을 사용하여 주식 시장 동향을 추적합니다. 이 회사는 매주 말에 2시간만 애플리케이션을 운영해야 합니다. 이 회사는 데이터베이스 운영 비용을 최적화해야 합니다.

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

A. 기존 RDS for MySQL 데이터베이스를 Aurora Serverless v2 MySQL 데이터베이스 클러스터로 마이그레이션합니다.
B. 기존 RDS for MySQL 데이터베이스를 Aurora MySQL 데이터베이스 클러스터로 마이그레이션합니다.
C. 기존 RDS for MySQL 데이터베이스를 MySQL을 실행하는 Amazon EC2 인스턴스로 마이그레이션합니다. EC2 인스턴스에 대한 인스턴스 예약을 구매합니다.
D. 기존 RDS for MySQL 데이터베이스를 MySQL 컨테이너 이미지를 사용하여 작업을 실행하는 Amazon Elastic Container Service (Amazon ECS) 클러스터로 마이그레이션합니다.

A. 기존 RDS for MySQL 데이터베이스를 Aurora Serverless v2 MySQL 데이터베이스 클러스터로 마이그레이션합니다.

Aurora Serverless v2
- Aurora Serverless v2는 필요한 용량만큼 자동으로 확장 및 축소할 수 있으므로, 애플리케이션이 짧은 기간 동안만 운영되는 시나리오에 최적입니다.
- 데이터베이스가 사용 중이지 않을 때 비용이 최소화되며, 주간 2시간 운영과 같은 사용 사례에 비용 효율적인 솔루션입니다.

비용 효율성
- Aurora Serverless는 사용한 만큼만 비용이 청구되므로, 주간 몇 시간만 작동하는 애플리케이션에서 매우 경제적입니다.
- RDS for MySQL은 항상 실행 상태로 유지되어야 하므로 사용량이 적은 경우 비용 효율적이지 않습니다.

운영 오버헤드 최소화
- Aurora Serverless v2는 완전 관리형 서비스로, 클러스터 프로비저닝, 확장 및 축소를 자동으로 처리합니다.
- 회사는 데이터베이스 관리에 대한 추가 작업 없이 운영 비용을 절감할 수 있습니다.

---

■ Question #575

한 회사가 AWS 지역의 애플리케이션 로드 밸런서 뒤에 있는 Amazon Elastic Kubernetes Service(Amazon EKS)에 애플리케이션을 배포합니다. 애플리케이션은 PostgreSQL 데이터베이스 엔진에 데이터를 저장해야 합니다. 회사는 데이터베이스의 데이터를 고가용성으로 유지하고 싶어합니다. 또한 회사는 읽기 워크로드에 대한 용량을 늘려야 합니다.

어떤 솔루션이 가장 높은 운영 효율성으로 이러한 요구 사항을 충족할까요?

A. 글로벌 테이블로 구성된 Amazon DynamoDB 데이터베이스 테이블을 만듭니다.
B. 다중 AZ 배포를 통해 Amazon RDS 데이터베이스를 생성합니다.
C. 다중 AZ DB 클러스터 배포를 통해 Amazon RDS 데이터베이스를 만듭니다.
D. 지역 간 읽기 복제본으로 구성된 Amazon RDS 데이터베이스를 만듭니다.

C. 다중 AZ DB 클러스터 배포를 통해 Amazon RDS 데이터베이스를 만듭니다.

고가용성
- 다중 AZ DB 클러스터 배포는 PostgreSQL 데이터베이스의 고가용성을 보장합니다. 장애가 발생하면 자동으로 대체 인스턴스로 장애 조치를 수행하여 다운타임을 최소화합니다.
- 읽기 복제본을 기본적으로 지원하므로 읽기 용량을 확장할 수 있습니다.

운영 효율성
- Amazon RDS는 완전 관리형 서비스로 데이터베이스 운영 작업(백업, 소프트웨어 패치, 장애 조치 등)을 자동으로 처리합니다.
- 다중 AZ DB 클러스터 배포는 쓰기 성능과 읽기 확장성을 모두 제공합니다.

읽기 워크로드 처리
- 다중 AZ DB 클러스터 배포는 여러 읽기 복제본을 지원하며, 읽기 워크로드를 복제본으로 분산하여 읽기 성능을 크게 향상시킬 수 있습니다.

---

■ Question #576

한 회사가 Amazon API Gateway와 AWS Lambda를 사용하여 AWS에서 RESTful 서버리스 웹 애플리케이션을 구축하고 있습습다. 이 웹 애플리케이션의 사용자는 지리적으로 분산되어 있으며, 회사는 이러한 사용자에게 API 요청의 지연 시간을 줄이고자 합니다.

솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 어떤 유형의 엔드포인트를 사용해야 합니까?

A. 개인 엔드포인트
B. 지역적 종착점
C. 인터페이스 VPC 엔드포인트
D. Edge 최적화 엔드포인트

D. Edge 최적화 엔드포인트

지리적으로 분산된 사용자
- 사용자가 전 세계에 분산되어 있는 경우, API Gateway의 Edge 최적화 엔드포인트는 가장 적합합니다. 이는 Amazon CloudFront를 통해 API Gateway 요청을 가속화하여 전 세계적으로 낮은 지연 시간을 제공합니다.

Edge 최적화 엔드포인트
- 요청을 사용자 가까운 CloudFront 엣지 로케이션으로 라우팅하고, API Gateway로 전달하기 전에 최적화합니다.
- 이를 통해 API Gateway와 Lambda 함수 간의 기본 네트워크 지연 시간을 줄이고, 사용자 경험을 향상시킵니다.

---

■ Question #577

한 회사가 Amazon CloudFront 배포판을 사용하여 웹사이트의 콘텐츠 페이지를 제공합니다. 이 회사는 클라이언트가 회사 웹사이트에 액세스할 때 TLS 인증서를 사용하도록 해야 합니다. 이 회사는 TLS 인증서의 생성 및 갱신을 자동화하려고 합니다.

어떤 솔루션이 가장 높은 운영 효율성으로 이러한 요구 사항을 충족할까요?

A. CloudFront 보안 정책을 사용하여 인증서를 만듭니다.
B. CloudFront 원본 액세스 제어(OAC)를 사용하여 인증서를 만듭니다.
C. AWS Certificate Manager(ACM)를 사용하여 인증서를 만듭니다. 도메인에 대한 DNS 검증을 사용합니다.
D. AWS Certificate Manager(ACM)를 사용하여 인증서를 만듭니다. 도메인에 대한 이메일 검증을 사용합니다.

C. AWS Certificate Manager(ACM)를 사용하여 인증서를 만듭니다. 도메인에 대한 DNS 검증을 사용합니다.

TLS 인증서의 생성 및 갱신 자동화
- AWS Certificate Manager(ACM)를 사용하면 TLS 인증서를 생성, 관리 및 자동 갱신할 수 있습니다. 특히 CloudFront와 같은 AWS 서비스와 통합이 원활합니다.
- DNS 검증은 한 번 설정하면 인증서 갱신 시 추가 작업이 필요 없으므로 높은 운영 효율성을 제공합니다.

DNS 검증의 이점
- DNS 검증은 인증서를 갱신할 때 수동 개입이 필요하지 않습니다. 따라서 TLS 인증서의 관리가 완전히 자동화됩니다.
- 반면, 이메일 검증은 갱신 시마다 이메일을 통해 수동 검증이 필요하므로 운영 오버헤드가 증가합니다.

---

■ Question #578

한 회사가 Amazon DynamoDB를 데이터베이스 계층으로 사용하는 서버리스 애플리케이션을 배포했습니다. 이 애플리케이션은 사용자가 크게 증가했습니다. 이 회사는 데이터베이스 응답 시간을 밀리초에서 마이크로초로 개선하고 데이터베이스에 대한 요청을 캐시하려고 합니다.

어떤 솔루션이 최소한의 운영 오버헤드로 이러한 요구 사항을 충족할까요?

A. DynamoDB Accelerator(DAX)를 사용하세요.
B. 데이터베이스를 Amazon Redshift로 마이그레이션합니다.
C. 데이터베이스를 Amazon RDS로 마이그레이션합니다.
D. Redis에 Amazon ElastiCache를 사용하세요.

A. DynamoDB Accelerator(DAX)를 사용하세요.

DynamoDB Accelerator(DAX)의 적합성
- DAX는 Amazon DynamoDB의 전용 캐싱 솔루션으로 설계되었습니다.
- 데이터베이스 요청을 마이크로초 단위로 처리할 수 있는 인메모리 캐시를 제공하여 응답 시간을 획기적으로 줄입니다.
- DAX는 DynamoDB와 원활하게 통합되며, 최소한의 코드 변경으로 캐싱을 활용할 수 있습니다.
- 운영 오버헤드가 낮다: 관리형 서비스이므로 클러스터 설정 및 유지보수가 간소화되어 운영 부담이 적습니다.

---

■ Question #579

한 회사가 PostgreSQL용 Amazon RDS를 사용하는 애플리케이션을 실행합니다. 이 애플리케이션은 평일 업무 시간에만 트래픽을 수신합니다. 이 회사는 이 사용량에 따라 비용을 최적화하고 운영 오버헤드를 줄이고자 합니다.

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

A. AWS의 인스턴스 스케줄러를 사용하여 시작 및 중지 일정을 구성합니다.
B. 자동 백업을 끕니다. 데이터베이스의 주간 수동 스냅샷을 만듭니다.
C. 최소 CPU 사용률에 따라 데이터베이스를 시작 및 중지하는 사용자 지정 AWS Lambda 함수를 만듭니다.
D. 사전에 예약된 모든 DB 인스턴스를 구매합니다.

A. AWS의 인스턴스 스케줄러를 사용하여 시작 및 중지 일정을 구성합니다.

RDS 인스턴스 사용 시간에 따른 비용 최적화
- 회사는 데이터베이스를 평일 업무 시간에만 사용하므로, 데이터베이스를 사용하지 않는 시간 동안 인스턴스를 중지함으로써 비용을 절감할 수 있습니다.
- AWS Instance Scheduler는 시작 및 중지 일정을 자동으로 관리할 수 있는 AWS 솔루션입니다. 이를 통해 사용자가 수동으로 작업을 관리할 필요가 없으므로 운영 오버헤드를 줄입니다.

AWS Instance Scheduler의 장점
- 자동화: 사전에 정의된 일정에 따라 RDS 인스턴스를 시작하고 중지합니다.
- 유연성: 회사의 업무 시간에 맞춘 사용자 지정 일정 생성 가능.
- 비용 절감: 사용하지 않는 시간 동안 RDS 인스턴스를 중지함으로써 비용이 감소합니다.
- 운영 부담 감소: 스크립트 작성이나 사용자 지정 코드를 작성할 필요가 없습니다.

---

■ Question #580

한 회사가 로컬로 연결된 스토리지를 사용하여 사내에서 지연에 민감한 애플리케이션을 실행합니다. 이 회사는 리프트 앤 시프트 방식을 사용하여 애플리케이션을 AWS 클라우드로 이동합니다. 이 회사는 애플리케이션 아키텍처를 변경하고 싶어하지 않습니다.

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

A. Amazon EC2 인스턴스로 자동 확장 그룹을 구성합니다. Amazon FSx for Lustre 파일 시스템을 사용하여 애플리케이션을 실행합니다.
B. Amazon EC2 인스턴스에서 애플리케이션을 호스팅합니다. Amazon Elastic Block Store(Amazon EBS) GP2 볼륨을 사용하여 애플리케이션을 실행합니다.
C. Amazon EC2 인스턴스로 자동 확장 그룹을 구성합니다. Amazon FSx for OpenZFS 파일 시스템을 사용하여 애플리케이션을 실행합니다.
D. Amazon EC2 인스턴스에서 애플리케이션을 호스팅합니다. Amazon Elastic Block Store(Amazon EBS) GP3 볼륨을 사용하여 애플리케이션을 실행합니다.

D. Amazon EC2 인스턴스에서 애플리케이션을 호스팅합니다. Amazon Elastic Block Store(Amazon EBS) GP3 볼륨을 사용하여 애플리케이션을 실행합니다.

로컬 연결 스토리지와의 유사성
- 회사의 기존 애플리케이션은 로컬 연결된 스토리지를 사용하므로, Amazon EBS 볼륨은 이 요구 사항과 잘 맞습니다. EBS는 EC2 인스턴스에 로컬 디스크처럼 연결되며 높은 성능과 낮은 지연 시간을 제공합니다.

EBS GP3 볼륨의 이점
- GP3는 GP2에 비해 비용 효율적입니다.
- 성능(최대 16,000 IOPS 및 1,000MB/s)을 독립적으로 프로비저닝할 수 있어, 비용 효율적으로 지연에 민감한 애플리케이션의 요구 사항을 충족합니다.
- 스냅샷 지원과 같은 AWS 관리형 서비스를 통해 복구 및 백업이 간편합니다.

리프트 앤 시프트 방식을 고려
- 회사는 애플리케이션 아키텍처를 변경하고 싶지 않다고 했으므로, 기존 워크로드와의 호환성을 유지하는 솔루션이 필요합니다.
- EBS는 EC2 인스턴스에 직접 연결되므로 로컬 스토리지와 유사하게 작동하며, 기존 아키텍처를 변경할 필요가 없습니다.