AWS Certified Solutions Architect - Associate 공부하면서 작성된 글로 일부 오류가 있을수 있습니다. |
■ Question #401
한 회사가 AWS 클라우드를 사용하여 기존 애플리케이션을 고가용성과 복원력으로 만들고자 합니다. 애플리케이션의 현재 버전은 회사의 데이터 센터에 있습니다. 이 애플리케이션은 예상치 못한 정전으로 인해 데이터베이스 서버가 충돌한 후 최근에 데이터 손실을 경험했습니다.
이 회사는 단일 장애 지점을 피하는 솔루션이 필요합니다. 이 솔루션은 애플리케이션이 사용자 수요를 충족하도록 확장할 수 있는 기능을 제공해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족할까요?
A. 여러 가용성 영역에 걸쳐 Auto Scaling 그룹에서 Amazon EC2 인스턴스를 사용하여 애플리케이션 서버를 배포합니다. Multi-AZ 구성에서 Amazon RDS DB 인스턴스를 사용합니다.
B. 단일 가용성 영역의 자동 확장 그룹에서 Amazon EC2 인스턴스를 사용하여 애플리케이션 서버를 배포합니다. EC2 인스턴스에 데이터베이스를 배포합니다. EC2 자동 복구를 활성화합니다.
C. 여러 가용 영역에 걸쳐 Auto Scaling 그룹의 Amazon EC2 인스턴스를 사용하여 애플리케이션 서버를 배포합니다. 단일 가용 영역에 읽기 복제본이 있는 Amazon RDS DB 인스턴스를 사용합니다. 기본 DB 인스턴스가 실패하면 읽기 복제본을 승격하여 기본 DB 인스턴스를 대체합니다.
D. 여러 가용성 영역에 걸쳐 Auto Scaling 그룹의 Amazon EC2 인스턴스를 사용하여 애플리케이션 서버를 배포합니다. 여러 가용성 영역에 걸쳐 EC2 인스턴스에 기본 및 보조 데이터베이스 서버를 배포합니다. Amazon Elastic Block Store(Amazon EBS) Multi-Attach를 사용하여 인스턴스 간에 공유 스토리지를 만듭니다.
A. 여러 가용성 영역에 걸쳐 Auto Scaling 그룹에서 Amazon EC2 인스턴스를 사용하여 애플리케이션 서버를 배포합니다. Multi-AZ 구성에서 Amazon RDS DB 인스턴스를 사용합니다.
고가용성
- Auto Scaling 그룹을 사용하면 여러 가용성 영역(AZ)에 걸쳐 EC2 인스턴스가 배포됩니다. 이는 한 AZ에 문제가 발생하더라도 다른 AZ에서 애플리케이션이 계속 작동하도록 보장합니다.
- Amazon RDS의 Multi-AZ 구성은 기본 DB 인스턴스와 동기화된 대기 인스턴스를 다른 AZ에 배치합니다. 기본 인스턴스가 실패하면 대기 인스턴스로 자동 장애 조치가 이루어집니다.
데이터 손실 방지
- Multi-AZ RDS는 동기 복제를 사용하므로 데이터 손실 위험이 최소화됩니다.
확장성
- Auto Scaling 그룹은 사용자 수요에 따라 EC2 인스턴스의 수를 자동으로 조정하여 확장성을 제공합니다.
- RDS는 읽기 복제본을 추가하여 읽기 작업의 부하를 분산시킬 수 있습니다.
복원력
- RDS의 관리형 서비스는 정기적인 백업, 자동 장애 조치, 지속적인 복구 등의 기능을 제공하여 데이터 복원력을 높입니다.
■ Question #402
한 회사는 애플리케이션에서 생성하는 대량의 스트리밍 데이터를 수집하고 처리해야 합니다. 이 애플리케이션은 Amazon EC2 인스턴스에서 실행되고 기본 설정으로 구성된 Amazon Kinesis Data Streams로 데이터를 전송합니다. 이 애플리케이션은 이틀에 한 번씩 데이터를 소비하고 비즈니스 인텔리전스(BI) 처리를 위해 Amazon S3 버킷에 데이터를 씁니다. 이 회사는 Amazon S3가 애플리케이션에서 Kinesis Data Streams로 전송하는 모든 데이터를 수신하지 못한다는 것을 알게 되었습니다.
이 문제를 해결하기 위해 솔루션 아키텍트는 무엇을 해야 할까요?
A. 데이터 보존 기간을 수정하여 Kinesis Data Streams 기본 설정을 업데이트합니다.
B. Kinesis Producer Library(KPL)를 사용하여 데이터를 Kinesis Data Streams로 전송하도록 애플리케이션을 업데이트합니다.
C. Kinesis Data Streams에 전송되는 데이터의 처리량을 처리하기 위해 Kinesis 샤드 수를 업데이트합니다.
D. S3 버킷 내에서 S3 버전 관리를 켜서 S3 버킷에 수집된 모든 객체의 모든 버전을 보존합니다.
A. 데이터 보존 기간을 수정하여 Kinesis Data Streams 기본 설정을 업데이트합니다.
Amazon Kinesis Data Streams는 기본적으로 24시간의 데이터 보존 기간을 제공합니다. 이 회사는 이틀에 한 번(48시간마다) 데이터를 소비한다고 설명했으므로, 기본 데이터 보존 기간(24시간)이 문제를 일으키고 있습니다. 데이터를 소비하기 전에 데이터가 Kinesis 스트림에서 삭제되기 때문에 Amazon S3 버킷으로 데이터를 성공적으로 전송하지 못하는 것입니다.
해결책:
- Kinesis Data Streams의 기본 데이터 보존 기간(24시간)을 최대 7일까지 늘릴 수 있습니다.
- 이틀에 한 번 데이터를 소비하려면 보존 기간을 48시간 이상으로 설정해야 합니다.
왜 올바른 선택인가?
- 보존 기간을 늘리면 애플리케이션이 데이터를 소비하기 전에 데이터가 삭제되지 않습니다.
- 설정 변경만으로 문제를 해결할 수 있으므로 운영 오버헤드 가 최소화됩니다.
■ Question #403
개발자는 AWS Lambda 함수를 사용하여 Amazon S3에 파일을 업로드하는 애플리케이션을 보유하고 있으며 작업을 수행하는 데 필요한 권한이 필요합니다. 개발자에게는 Amazon S3에 필요한 유효한 IAM 자격 증명을 가진 IAM 사용자가 이미 있습니다.
솔루션 설계자는 권한을 부여하기 위해 무엇을 해야 합니까?
A. Lambda 함수의 리소스 정책에 필요한 IAM 권한을 추가합니다.
B. Lambda 함수의 기존 IAM 자격 증명을 사용하여 서명된 요청을 생성합니다.
C. 새로운 IAM 사용자를 생성하고 Lambda 함수에서 기존 IAM 자격 증명을 사용합니다.
D. 필요한 권한이 있는 IAM 실행 역할을 생성하고 IAM 역할을 Lambda 함수에 연결합니다.
D. 필요한 권한이 있는 IAM 실행 역할을 생성하고 IAM 역할을 Lambda 함수에 연결합니다.
AWS Lambda 함수는 보안상 가장 좋은 방법으로 IAM 실행 역할(role)을 사용하여 AWS 리소스에 액세스합니다. Lambda 함수에 직접 IAM 자격 증명을 사용하지 않으며, 대신 역할(Role)을 통해 필요한 권한을 부여해야 합니다.
IAM 실행 역할 사용:
- Lambda 함수에는 AWS 리소스에 액세스하는 데 필요한 권한을 부여하기 위해 IAM 실행 역할을 연결합니다.
- 이 실행 역할은 Lambda 함수가 Amazon S3와 같은 AWS 리소스와 상호작용할 수 있는 권한을 제공합니다.
안전한 접근 방식:
- Lambda 함수에서 자격 증명(IAM 사용자 키 또는 시크릿)을 직접 사용하는 것은 보안 위험이 있으므로 권장되지 않습니다.
- 역할을 사용하면 필요한 최소 권한을 정의할 수 있습니다(원칙: 최소 권한 부여).
작동 방식:
- Lambda 함수는 연결된 실행 역할을 통해 S3에 파일 업로드 작업을 수행합니다.
- 실행 역할의 정책에 S3에 대한 작업(예: s3:PutObject) 권한을 추가하면 Lambda 함수가 해당 작업을 수행할 수 있습니다.
■ Question #404
한 회사는 새 문서가 Amazon S3 버킷에 업로드될 때 AWS Lambda 함수를 호출하는 서버리스 애플리케이션을 배포했습니다. 애플리케이션은 Lambda 함수를 사용하여 문서를 처리합니다. 최근 마케팅 캠페인 이후 회사는 애플리케이션이 많은 문서를 처리하지 않는다는 사실을 발견했습니다.
이 애플리케이션의 아키텍처를 개선하려면 솔루션 설계자가 무엇을 해야 합니까?
A. Lambda 함수의 런타임 제한 시간 값을 15분으로 설정합니다.
B. S3 버킷 복제 정책을 구성합니다. 나중에 처리하기 위해 S3 버킷에 문서를 준비합니다.
C. 추가 Lambda 함수를 배포합니다. 두 개의 Lambda 함수에 걸쳐 문서 처리의 로드 밸런싱을 수행합니다.
D. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성합니다. 요청을 대기열로 보냅니다. 대기열을 Lambda의 이벤트 소스로 구성합니다.
D. Amazon Simple Queue Service(Amazon SQS) 대기열을 생성합니다. 요청을 대기열로 보냅니다. 대기열을 Lambda의 이벤트 소스로 구성합니다.
애플리케이션이 많은 문서를 처리하지 못하는 문제는 Lambda 함수와 Amazon S3 간의 이벤트 트리거 방식에서 발생할 수 있습니다. S3 이벤트 알림은 트래픽 급증 시 일부 이벤트를 손실할 수 있으며, 이는 문서 처리가 지연되거나 누락될 수 있습니다. SQS 대기열을 사용하여 이벤트를 관리하고 트래픽 급증을 처리할 수 있습니다.
SQS를 사용한 메시지 큐 관리 :
- Amazon SQS 대기열은 S3 이벤트를 처리하는 동안 안정적인 중간 버퍼 역할을 합니다.
- S3에서 발생하는 모든 이벤트를 SQS 대기열로 보내면 트래픽 급증 시에도 모든 이벤트가 대기열에 저장됩니다.
Lambda와의 통합 :
- Lambda 함수를 SQS 대기열의 이벤트 소스로 설정하면 대기열에 있는 메시지가 순차적으로 Lambda로 전달됩니다.
- Lambda 함수는 병렬 실행으로 메시지를 처리할 수 있어 확장성이 증가합니다.
트래픽 급증 처리 :
- 대기열을 사용하면 트래픽 급증 시에도 이벤트를 손실하지 않고 저장할 수 있으며, Lambda 함수가 처리할 수 있는 속도로 이벤트를 소비할 수 있습니다.
최소한의 운영 오버헤드 :
- SQS 대기열과 Lambda는 관리형 서비스로, 별도의 인프라를 관리하지 않아도 됩니다.
- 메시지 수명 주기 정책과 재시도 메커니즘을 통해 신뢰성을 추가로 확보할 수 있습니다.
■ Question #405
솔루션 아키텍트가 소프트웨어 데모 환경을 위한 아키텍처를 설계하고 있습니다. 이 환경은 Application Load Balancer(ALB) 뒤의 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행됩니다. 이 시스템은 근무 시간 동안 트래픽이 상당히 증가하지만 주말에는 작동할 필요가 없습니다.
솔루션 아키텍트는 어떤 조합의 조치를 취해야 시스템이 수요를 충족하도록 확장할 수 있습니까?(두 가지를 선택하세요.)
A. AWS Auto Scaling을 사용하여 요청 속도에 따라 ALB 용량을 조정합니다.
B. AWS Auto Scaling을 사용하여 VPC 인터넷 게이트웨이의 용량을 확장합니다.
C. 여러 AWS 지역에서 EC2 인스턴스를 시작하여 여러 지역에 걸쳐 부하를 분산합니다.
D. 대상 추적 확장 정책을 사용하여 인스턴스 CPU 사용률에 따라 자동 확장 그룹을 확장합니다.
E. 예약된 스케일링을 사용하여 주말에 자동 스케일링 그룹 최소, 최대 및 원하는 용량을 0으로 변경합니다. 주 초에 기본값으로 되돌립니다.
D. 대상 추적 확장 정책을 사용하여 인스턴스 CPU 사용률에 따라 자동 확장 그룹을 확장합니다.
- 대상 추적 확장 정책(Target Tracking Scaling Policy)은 자동으로 시스템 성능 메트릭(CPU 사용률 등)에 따라 인스턴스의 크기를 조정합니다.
- 트래픽이 증가하면 자동으로 더 많은 인스턴스를 시작하고, 감소하면 불필요한 인스턴스를 종료하여 비용을 절감합니다.
E. 예약된 스케일링을 사용하여 주말에 자동 스케일링 그룹 최소, 최대 및 원하는 용량을 0으로 변경합니다. 주 초에 기본값으로 되돌립니다.
- 예약된 스케일링(Scheduled Scaling)을 사용하면 시간 기반으로 인스턴스를 시작하거나 중지할 수 있습니다.
- 주말에 시스템을 작동하지 않도록 Auto Scaling 그룹의 용량을 0으로 설정하여 비용을 줄일 수 있습니다.
■ Question #406
솔루션 아키텍트는 퍼블릭 서브넷과 데이터베이스 서브넷을 포함하는 2계층 아키텍처를 설계하고 있습니다. 퍼블릭 서브넷의 웹 서버는 포트 443에서 인터넷에 열려 있어야 합니다. 데이터베이스 서브넷의 Amazon RDS for MySQL DB 인스턴스는 포트 3306에서 웹서버에만 액세스할 수 있어야 합니다.
솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 어떤 단계 조합을 취해야 합니까? (두 가지를 선택하세요.)
A. 퍼블릭 서브넷에 대한 네트워크 ACL을 만듭니다. 포트 3306에서 0.0.0.0/0으로의 아웃바운드 트래픽을 거부하는 규칙을 추가합니다.
B. DB 인스턴스에 대한 보안 그룹을 만듭니다. 포트 3306에서 퍼블릭 서브넷 CIDR 블록의 트래픽을 허용하는 규칙을 추가합니다.
C. 퍼블릭 서브넷의 웹 서버에 대한 보안 그룹을 만듭니다. 포트 443에서 0.0.0.0/0의 트래픽을 허용하는 규칙을 추가합니다.
D. DB 인스턴스에 대한 보안 그룹을 만듭니다. 포트 3306에서 웹 서버 보안 그룹의 트래픽을 허용하는 규칙을 추가합니다.
E. DB 인스턴스에 대한 보안 그룹을 만듭니다. 포트 3306에서 웹 서버 보안 그룹의 트래픽을 제외한 모든 트래픽을 거부하는 규칙을 추가합니다.
C. 퍼블릭 서브넷의 웹 서버에 대한 보안 그룹을 만듭니다. 포트 443에서 0.0.0.0/0의 트래픽을 허용하는 규칙을 추가합니다.
- 웹 서버는 퍼블릭 서브넷에 위치하며 인터넷에서 들어오는 HTTPS 트래픽(포트 443)을 허용해야 합니다. 이를 위해 웹 서버의 보안 그룹에서 포트 443에 대해 0.0.0.0/0(모든 IP 주소)에서 들어오는 트래픽을 허용해야 합니다.
D. DB 인스턴스에 대한 보안 그룹을 만듭니다. 포트 3306에서 웹 서버 보안 그룹의 트래픽을 허용하는 규칙을 추가합니다.
- Amazon RDS 인스턴스의 보안 그룹은 웹 서버 보안 그룹에서 들어오는 포트 3306 트래픽만 허용하도록 설정해야 합니다. 이를 통해 웹 서버만 데이터베이스에 접근할 수 있습니다.
■ Question #407
한 회사가 AWS 클라우드에 호스팅된 게임 애플리케이션에 대한 공유 스토리지 솔루션을 구현하고 있습니다. 이 회사는 Lustre 클라이언트를 사용하여 데이터에 액세스할 수 있어야 합니다. 솔루션은 완전히 관리되어야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
A. 마운트 가능한 파일 시스템으로 데이터를 공유하는 AWS DataSync 작업을 만듭니다. 파일 시스템을 애플리케이션 서버에 마운트합니다.
B. AWS Storage Gateway 파일 게이트웨이를 만듭니다. 필요한 클라이언트 프로토콜을 사용하는 파일 공유를 만듭니다. 애플리케이션 서버를 파일 공유에 연결합니다.
C. Amazon Elastic File System(Amazon EFS) 파일 시스템을 만들고 Lustre를 지원하도록 구성합니다. 파일 시스템을 원본 서버에 연결합니다. 애플리케이션 서버를 파일 시스템에 연결합니다.
D. Amazon FSx for Lustre 파일 시스템을 만듭니다. 파일 시스템을 원본 서버에 연결합니다. 애플리케이션 서버를 파일 시스템에 연결합니다.
D. Amazon FSx for Lustre 파일 시스템을 만듭니다. 파일 시스템을 원본 서버에 연결합니다. 애플리케이션 서버를 파일 시스템에 연결합니다.
- Amazon FSx for Lustre는 고성능 컴퓨팅(HPC) 워크로드와 같이 빠른 I/O, 저지연, 높은 처리량을 필요로 하는 애플리케이션을 위해 설계된 완전 관리형 병렬 파일 시스템입니다.
- Lustre 클라이언트를 사용하여 데이터에 액세스해야 한다는 요구 사항에 완벽하게 부합합니다.
- FSx for Lustre는 게임 애플리케이션과 같이 공유 스토리지가 필요한 시나리오에 적합하며, AWS가 파일 시스템의 관리를 처리하므로 운영 오버헤드가 낮습니다.
■ Question #408
한 회사에서 UDP를 사용하는 수천 개의 지리적으로 분산된 원격 장치에서 데이터를 수신하는 애플리케이션을 실행합니다. 이 애플리케이션은 데이터를 즉시 처리하고 필요한 경우 장치로 메시지를 다시 보냅니다. 데이터는 저장되지 않습니다.
이 회사는 장치에서 데이터 전송에 대한 지연 시간을 최소화하는 솔루션이 필요합니다. 이 솔루션은 또한 다른 AWS 지역으로의 빠른 장애 조치를 제공해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족할까요?
A. Amazon Route 53 장애 조치 라우팅 정책을 구성합니다. 두 리전 각각에 네트워크 로드 밸런서(NLB)를 만듭니다. NLB를 구성하여 AWS Lambda 함수를 호출하여 데이터를 처리합니다.
B. AWS Global Accelerator를 사용합니다. 두 리전 각각에 엔드포인트로 Network Load Balancer(NLB)를 만듭니다. Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 클러스터를 만듭니다. 클러스터에서 ECS 서비스를 만듭니다. NLProcess의 대상으로 ECS 서비스를 설정합니다. Amazon ECS에서 데이터를 처리합니다.
C. AWS Global Accelerator를 사용합니다. 두 리전 각각에 엔드포인트로 Application Load Balancer(ALB)를 만듭니다. Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 클러스터를 만듭니다. 클러스터에서 ECS 서비스를 만듭니다. ECS 서비스를 ALB의 대상으로 설정합니다. Amazon ECS에서 데이터를 처리합니다.
D. Amazon Route 53 장애 조치 라우팅 정책을 구성합니다. 두 리전 각각에 Application Load Balancer(ALB)를 만듭니다. Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 클러스터를 만듭니다. 클러스터에서 ECS 서비스를 만듭니다. ECS 서비스를 ALB의 대상으로 설정합니다. Amazon ECS에서 데이터를 처리합니다.
B. AWS Global Accelerator를 사용합니다. 두 리전 각각에 엔드포인트로 Network Load Balancer(NLB)를 만듭니다. Fargate 시작 유형으로 Amazon Elastic Container Service (Amazon ECS) 클러스터를 만듭니다. 클러스터에서 ECS 서비스를 만듭니다. NLB의 대상으로 ECS 서비스를 설정합니다. Amazon ECS에서 데이터를 처리합니다.
이 요구 사항에서의 주요 포인트는 다음과 같습니다.
- UDP 프로토콜 지원 : 원격 장치가 데이터를 전송하는 데 UDP를 사용합니다. 따라서 Network Load Balancer (NLB)가 필요합니다.
- 지연 시간 최소화 : AWS Global Accelerator는 사용자가 가장 가까운 리전으로 라우팅되도록 하여 네트워크 지연 시간을 줄입니다.
- 빠른 장애 조치 : Global Accelerator는 지연 시간이 짧은 경로를 유지하고 장애 발생 시 자동으로 트래픽을 대체 리전으로 라우팅합니다.
- 지리적으로 분산된 장치 : 다중 리전 배포를 통해 전 세계적으로 장치와 통신할 수 있어야 합니다.
- 데이터 처리 : ECS의 Fargate 시작 유형은 관리형 컴퓨팅 환경을 제공하므로 인프라 관리 오버헤드를 줄일 수 있습니다.
■ Question #409
솔루션 아키텍트는 Windows 인터넷 정보 서비스(IIS) 웹 애플리케이션을 AWS로 마이그레이션해야 합니다. 이 애플리케이션은 현재 사용자의 온프레미스 네트워크 연결 스토리지(NAS)에 호스팅된 파일 공유에 의존합니다. 솔루션 아키텍트는 IIS 웹 서버를 스토리 솔루션에 연결된 여러 가용성 영역의 Amazon EC2 인스턴스로 마이그레이션하고 인스턴스에 연결된 Elastic Load Balancer를 구성할 것을 제안했습니다.
온프레미스 파일 공유를 대체하는 것 중 가장 탄력적이고 내구성이 좋은 것은 무엇입니까?
A. 파일 공유를 Amazon RDS로 마이그레이션합니다.
B. 파일 공유를 AWS Storage Gateway로 마이그레이션합니다.
C. 파일 공유를 Amazon FSx for Windows File Server로 마이그레이션합니다.
D. 파일 공유를 Amazon Elastic File System(Amazon EFS)으로 마이그레이션합니다.
C. 파일 공유를 Amazon FSx for Windows File Server로 마이그레이션합니다.
Windows IIS 웹 애플리케이션은 Windows 기반 파일 공유 및 SMB 프로토콜에 의존하는 경우가 많습니다. 따라서 이 요구 사항을 충족하기 위해 Windows 네이티브 파일 시스템을 제공하는 Amazon FSx for Windows File Server가 가장 적합합니다.
Windows 네이티브 지원:
- FSx for Windows File Server는 SMB 프로토콜을 완벽히 지원하며, Windows 환경에 최적화되어 있습니다.
- 기존 온프레미스 NAS 파일 공유를 그대로 대체할 수 있습니다.
고가용성과 내구성:
- FSx는 다중 AZ 배포를 지원하여 고가용성과 데이터 내구성을 제공합니다.
IIS 웹 애플리케이션과 호환성:
- IIS와 통합하기에 적합하며, Windows 인증(Active Directory 통합) 및 NTFS 권한 관리도 지원합니다.
성능 및 확장성:
- 높은 처리량과 저지연 성능을 제공하며, 필요에 따라 스토리지를 손쉽게 확장할 수 있습니다.
■ Question #410
한 회사가 Amazon EC2 인스턴스에 새 애플리케이션을 배포하고 있습니다. 이 애플리케이션은 Amazon Elastic Block Store(Amazon EBS) 볼륨에 데이터를 씁니다. 이 회사는 EBS 볼륨에 쓰여진 모든 데이터가 휴면 상태에서 암호화되도록 해야 합니다.
어떤 솔루션이 이 요구 사항을 충족할까요?
A. EBS 암호화를 지정하는 IAM 역할을 만듭니다. 역할을 EC2 인스턴스에 연결합니다.
B. EBS 볼륨을 암호화된 볼륨으로 만듭니다. EBS 볼륨을 EC2 인스턴스에 연결합니다.
C. Encrypt 키와 True 값을 갖는 EC2 인스턴스 태그를 만듭니다. EBS 수준에서 암호화가 필요한 모든 인스턴스에 태그를 지정합니다.
D. 계정에서 EBS 암호화를 시행하는 AWS Key Management Service(AWS KMS) 키 정책을 만듭니다. 키 정책이 활성화되어 있는지 확인합니다.
B. EBS 볼륨을 암호화된 볼륨으로 만듭니다. EBS 볼륨을 EC2 인스턴스에 연결합니다.
- EBS 볼륨의 암호화는 Amazon Elastic Block Store에서 제공하는 내장 기능으로, 데이터를 저장할 때 자동으로 암호화하고 복호화할 수 있습니다. 선택한 AWS Key Management Service(AWS KMS) 키를 사용하여 데이터를 암호화합니다.
자동 암호화 활성화:
- AWS 계정에 대해 EBS 기본 암호화를 활성화하면 생성되는 모든 새 EBS 볼륨이 자동으로 암호화됩니다.
AWS KMS 키 사용:
- 기본 AWS 관리형 키 또는 사용자 지정 KMS 키를 선택하여 암호화를 수행할 수 있습니다.
암호화 성능:
- EBS 암호화는 스토리지 작업에 추가적인 성능 영향을 주지 않습니다.
■ Question #411
한 회사에는 산발적인 사용 패턴이 있는 웹 애플리케이션이 있습니다. 매월 초에는 사용량이 많고, 매주 초에는 보통 사용하며, 주중에는 예측할 수 없는 사용량이 있습니다. 이 애플리케이션은 데이터 센터 내부에서 실행되는 웹 서버와 MySQL 데이터베이스 서버로 구성되어 있습니다. 이 회사는 애플리케이션을 AWS 클라우드로 옮기고 싶어하며, 데이터베이스 수정이 필요 없는 비용 효율적인 데이터베이스 플랫폼을 선택해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족할까요?
A. Amazon DynamoDB
B. MySQL용 Amazon RDS
C. MySQL 호환 Amazon Aurora Serverless
D. Amazon EC2에 Auto Scaling 그룹으로 배포된 MySQL
C. MySQL 호환 Amazon Aurora Serverless
- Amazon Aurora Serverless는 산발적인 사용 패턴을 처리하기에 적합한 데이터베이스 플랫폼입니다. 특히, 트래픽 패턴이 일정하지 않고 사용량이 예측하기 어려운 경우, Aurora Serverless는 자동으로 확장하거나 축소하여 데이터베이스 용량을 조정할 수 있으므로 비용 효율적입니다. MySQL과 호환되기 때문에 기존 데이터베이스와의 수정 없이 사용할 수 있습니다.
Aurora Serverless 장점 :
- 자동 확장: 사용량에 따라 데이터베이스의 컴퓨팅 용량을 자동으로 조정합니다.
- 비용 효율성: 사용한 만큼만 요금이 부과되며, 트래픽 변동성이 큰 워크로드에 이상적입니다.
- 관리 간소화: 데이터베이스 인프라 관리 부담이 적습니다.
RDS와의 차이점 :
- RDS는 고정 용량을 사용해야 하며, Aurora Serverless는 온디맨드로 용량을 확장합니다.
■ Question #412
이미지 호스팅 회사가 Amazon S3 버킷에 객체를 저장합니다. 이 회사는 S3 버킷의 객체가 실수로 대중에게 노출되는 것을 피하고자 합니다. 전체 AWS 계정의 모든 S3 객체는 비공개로 유지되어야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족할까요?
A. Amazon GuardDuty를 사용하여 S3 버킷 정책을 모니터링합니다. AWS Lambda 함수를 사용하여 객체를 공개하는 모든 변경 사항을 수정하는 자동 수정 작업 규칙을 만듭니다.
B. AWS Trusted Advisor를 사용하여 공개적으로 액세스 가능한 S3 버킷을 찾습니다. 변경 사항이 감지되면 Trusted Advisor에서 이메일 알림을 구성합니다. 공개 액세스를 허용하는 경우 S3 버킷 정책을 수동으로 변경합니다.
C. AWS Resource Access Manager를 사용하여 공개적으로 액세스 가능한 S3 버킷을 찾습니다. Amazon Simple Notification Service(Amazon SNS)를 사용하여 변경 사항이 감지되면 AWS Lambda 함수를 호출합니다. 변경 사항을 프로그래밍 방식으로 수정하는 Lambda 함수를 배포합니다.
D. 계정 수준에서 S3 Block Public Access 기능을 사용합니다. AWS Organizations를 사용하여 IAM 사용자가 설정을 변경하지 못하도록 하는 서비스 제어 정책(SCP)을 만듭니다. SCP를 계정에 적용합니다.
D. 계정 수준에서 S3 Block Public Access 기능을 사용합니다. AWS Organizations를 사용하여 IAM 사용자가 설정을 변경하지 못하도록 하는 서비스 제어 정책(SCP)을 만듭니다. SCP를 계정에 적용합니다.
- Amazon S3 Block Public Access 기능은 S3 버킷과 객체에 대해 계정 수준에서 공개 액세스를 차단하는 강력한 메커니즘을 제공합니다. 이 설정은 모든 S3 버킷 및 객체가 비공개로 유지되도록 보장합니다. AWS Organizations를 사용하여 서비스 제어 정책(SCP)을 적용하면, 누구도 Block Public Access 설정을 변경할 수 없도록 방지할 수 있습니다. 이는 실수나 악의적인 변경으로 인해 객체가 공개적으로 노출되는 위험을 최소화합니다.
S3 Block Public Access의 주요 이점:
- 모든 버킷 및 객체 보호: 기본적으로 모든 객체가 비공개로 유지되도록 설정합니다.
- 계정 수준 적용: 계정 내 모든 버킷과 객체에 자동으로 적용됩니다.
- 운영 오버헤드 감소: 정책을 수동으로 관리할 필요가 없습니다.
- IAM과의 통합: SCP를 사용하면 설정 변경을 방지할 수 있습니다.
■ Question #413
전자상거래 회사에서 사용자 트래픽이 증가하고 있습니다. 이 회사의 매장은 웹 계층과 별도의 데이터베이스 계층으로 구성된 2계층 웹 애플리케이션으로 Amazon EC2 인스턴스에 배포됩니다. 트래픽이 증가함에 따라 이 회사는 아키텍처로 인해 사용자에게 적시에 마케팅 및 주문 확인 이메일을 보내는 데 상당한 지연이 발생한다는 것을 알게 되었습니다. 이 회사는 복잡한 이메일 전달 문제를 해결하는 데 소요되는 시간을 줄이고 운영 오버헤드를 최소화하고자 합니다.
솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 무엇을 해야 할까요?
A. 이메일 처리에 전담된 EC2 인스턴스를 사용하여 별도의 애플리케이션 계층을 만듭니다.
B. Amazon Simple Email Service(Amazon SES)를 통해 이메일을 보내도록 웹 인스턴스를 구성합니다.
C. Amazon Simple Notification Service(Amazon SNS)를 통해 이메일을 보내도록 웹 인스턴스를 구성합니다.
D. 이메일 처리에 전담된 EC2 인스턴스를 사용하여 별도의 애플리케이션 계층을 만듭니다. 인스턴스를 Auto Scaling 그룹에 배치합니다.
B. Amazon Simple Email Service(Amazon SES)를 통해 이메일을 보내도록 웹 인스턴스를 구성합니다.
- Amazon SES(Amazon Simple Email Service)는 AWS에서 제공하는 완전 관리형 이메일 서비스로, 이메일 전송, 수신, 모니터링에 대한 복잡성을 줄이고 운영 오버헤드를 최소화하는 데 적합합니다. Amazon SES는 이메일 전송 문제를 간소화하고 확장성을 제공하며, SMTP 인터페이스 또는 AWS SDK를 통해 쉽게 통합할 수 있습니다.
Amazon SES의 주요 이점 :
- 확장성: 대량 이메일 전송 지원.
- 관리형 서비스: 이메일 전달 문제 해결 및 관리 부담 감소.
- 비용 효율성: 전용 인프라를 운영할 필요가 없어 비용 절감.
- 간편 통합: AWS SDK 및 SMTP 인터페이스를 통해 쉽게 애플리케이션과 통합 가능.
- 고가용성: Amazon의 글로벌 인프라에서 안정적으로 동작.
■ Question #414
어떤 회사에는 매일 수백 개의 보고서를 생성하는 비즈니스 시스템이 있습니다. 이 비즈니스 시스템은 보고서를 CSV 형식으로 네트워크 공유에 저장합니다. 이 회사는 분석을 위해 이 데이터를 거의 실시간으로 AWS 클라우드에 저장해야 합니다.
어떤 솔루션이 최소한의 관리 오버헤드로 이러한 요구 사항을 충족할까요?
A. AWS DataSync를 사용하여 파일을 Amazon S3로 전송합니다. 매일 종료 시 실행되는 예약 작업을 만듭니다.
B. Amazon S3 파일 게이트웨이를 만듭니다. S3 파일 게이트웨이에서 새 네트워크 공유를 사용하도록 비즈니스 시스템을 업데이트합니다.
C. AWS DataSync를 사용하여 파일을 Amazon S3로 전송합니다. 자동화 워크플로에서 DataSync API를 사용하는 애플리케이션을 만듭니다.
D. SFTP 엔드포인트에 AWS Transfer를 배포합니다. 네트워크 공유에서 새 파일을 확인하고 SFTP를 사용하여 새 파일을 업로드하는 스크립트를 만듭니다.
B. Amazon S3 파일 게이트웨이를 만듭니다. S3 파일 게이트웨이에서 새 네트워크 공유를 사용하도록 비즈니스 시스템을 업데이트합니다.
- Amazon S3 파일 게이트웨이는 온프레미스 네트워크 공유를 AWS 클라우드의 Amazon S3와 통합하여 데이터를 거의 실시간으로 저장할 수 있는 솔루션을 제공합니다. 이 솔루션은 회사의 비즈니스 시스템이 기존 네트워크 공유 방식을 변경하지 않으면서도 데이터를 Amazon S3로 전송할 수 있도록 지원합니다.
- 최소한의 관리 오버헤드: 파일 게이트웨이는 완전 관리형 서비스로, 파일을 S3로 자동으로 업로드하고 유지 관리 노력을 줄입니다.
- 실시간 데이터 전송: 게이트웨이는 파일이 업로드되자마자 S3에 즉시 저장되므로 실시간 데이터 분석이 가능합니다.
- 비즈니스 시스템 통합: 기존 워크플로와 쉽게 통합되며, 네트워크 공유 인터페이스를 통해 운영됩니다.
Amazon S3 파일 게이트웨이의 주요 이점:
- 간소화된 운영: 기존 네트워크 공유와 동일한 인터페이스 제공.
- 실시간 데이터 통합: 파일을 S3로 즉시 업로드.
- 저비용: 별도의 스크립트나 애플리케이션 개발 필요 없음.
- 확장성: AWS의 스토리지 및 분석 서비스와 원활하게 통합 가능.
■ Question #415
한 회사가 Amazon S3 Standard에 페타바이트 규모의 데이터를 저장하고 있습니다. 데이터는 여러 S3 버킷에 저장되고 다양한 빈도로 액세스됩니다. 회사는 모든 데이터에 대한 액세스 패턴을 알지 못합니다. 회사는 각 S3 버킷에 대한 솔루션을 구현하여 S3 사용 비용을 최적화해야 합니다.
어떤 솔루션이 이러한 요구 사항을 가장 높은 운영 효율성으로 충족할까요?
A. S3 버킷의 객체를 S3 Intelligent-Tiering으로 전환하는 규칙으로 S3 수명 주기 구성을 만듭니다.
B. S3 스토리지 클래스 분석 도구를 사용하여 S3 버킷의 각 객체에 대한 올바른 계층을 확인합니다. 각 객체를 식별된 스토리지 계층으로 이동합니다.
C. S3 버킷의 객체를 S3 Glacier Instant Retrieval로 전환하는 규칙으로 S3 수명 주기 구성을 만듭니다.
D. S3 버킷의 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환하는 규칙이 있는 S3 수명 주기 구성을 만듭니다.
A. S3 버킷의 객체를 S3 Intelligent-Tiering으로 전환하는 규칙으로 S3 수명 주기 구성을 만듭니다.
S3 Intelligent-Tiering은 액세스 패턴을 알 수 없거나 예측할 수 없는 데이터를 위한 AWS 스토리지 클래스입니다. Intelligent-Tiering은 자동으로 데이터를 액세스 빈도에 따라 가장 비용 효율적인 스토리지 계층으로 이동합니다.
- 운영 효율성: 사용자가 별도로 객체의 액세스 패턴을 분석하거나 데이터를 이동할 필요가 없습니다.
- 비용 최적화: 자주 액세스되는 데이터는 더 비싼 계층에 저장되고, 액세스 빈도가 낮아지면 자동으로 저비용 계층으로 이동됩니다.
- 적합성: 다양한 빈도의 데이터를 처리하며, 사용 패턴을 모르는 경우에도 적합합니다.
- 자동화된 접근: 설정만으로 데이터를 효율적으로 관리할 수 있습니다.
S3 Intelligent-Tiering의 주요 이점
- 자동화된 계층 이동: 데이터 액세스 패턴에 따라 자동으로 적절한 계층으로 이동.
- 비용 절감: 빈번하게 액세스되지 않는 데이터를 저렴한 계층으로 이동시켜 비용 절감.
- 운영 간소화: 사용자는 데이터를 관리할 필요 없이 비용을 최적화할 수 있음.
- 다양한 스토리지 계층: 빈도에 따라 Frequent Access, Infrequent Access, Archive Instant Access 계층으로 분류.
■ Question #416
빠르게 성장하는 글로벌 전자상거래 회사가 AWS에서 웹 애플리케이션을 호스팅하고 있습니다. 웹 애플리케이션에는 정적 콘텐츠와 동적 콘텐츠가 포함됩니다. 웹사이트는 Amazon RDS 데이터베이스에 온라인 거래 처리(OLTP) 데이터를 저장합니다. 웹사이트 사용자는 페이지 로드 속도가 느립니다.
솔루션 아키텍트는 이 문제를 해결하기 위해 어떤 조치 조합을 취해야 합니까? (두 가지를 선택하세요.)
A. Amazon Redshift 클러스터를 구성합니다.
B. Amazon CloudFront 배포를 설정합니다.
C. Amazon S3에 동적 웹 콘텐츠를 호스팅합니다.
D. RDS DB 인스턴스에 대한 읽기 복제본을 생성합니다.
E. RDS DB 인스턴스에 대한 다중 AZ 배포를 구성합니다.
AWS에서 웹 애플리케이션의 성능을 최적화하기 위해서는 페이지 로드 속도와 데이터베이스 효율성을 개선하는 것이 중요합니다.
B. Amazon CloudFront 배포를 설정합니다.
- 정적 콘텐츠 캐싱: CloudFront는 전 세계적으로 분산된 엣지 로케이션을 사용하여 정적 콘텐츠(예: 이미지, CSS, JavaScript)를 캐싱합니다. 이로 인해 정적 콘텐츠의 로드 속도가 크게 개선됩니다.
- 지연 시간 감소: 사용자와 콘텐츠 소스 간의 거리가 줄어들어 페이지 로드 시간이 단축됩니다.
- 동적 콘텐츠 최적화: CloudFront는 동적 콘텐츠의 전달 성능도 개선할 수 있습니다.
D. RDS DB 인스턴스에 대한 읽기 복제본을 생성합니다.
- 읽기 트래픽 분산: 읽기 복제본은 읽기 요청을 처리할 수 있는 별도의 데이터베이스 인스턴스를 제공합니다. 이는 기본 데이터베이스에 대한 부하를 줄이고 동적 콘텐츠의 데이터베이스 응답 속도를 개선합니다.
- 확장성: 읽기 트래픽이 많아질수록 추가 읽기 복제본을 생성하여 확장할 수 있습니다.
■ Question #417
한 회사에서 Amazon EC2 인스턴스와 AWS Lambda 함수를 사용하여 애플리케이션을 실행합니다. 이 회사는 AWS 계정에 퍼블릭 서브넷과 프라이빗 서브넷이 있는 VPC를 가지고 있습니다. EC2 인스턴스는 VPC 중 하나의 프라이빗 서브넷에서 실행됩니다. Lambda 함수는 애플리케이션이 작동하려면 EC2 인스턴스에 대한 직접 네트워크 액세스가 필요합니다.
애플리케이션은 최소 1년 동안 실행됩니다. 이 회사는 그 기간 동안 애플리케이션에서 사용하는 Lambda 함수의 수가 증가할 것으로 예상합니다. 이 회사는 모든 애플리케이션 리소스에서 절감 효과를 극대화하고 서비스 간의 네트워크 지연 시간을 낮게 유지하고자 합니다.
어떤 솔루션이 이러한 요구 사항을 충족할까요?
A. EC2 인스턴스 절약 플랜 구매 Lambda 함수의 지속 시간과 메모리 사용량, 호출 횟수를 최적화합니다. Lambda 함수를 EC2 인스턴스가 포함된 프라이빗 서브넷에 연결합니다.
B. EC2 인스턴스 절약 플랜 구매 Lambda 함수의 지속 시간과 메모리 사용량, 호출 횟수, 전송되는 데이터 양을 최적화합니다. EC2 인스턴스가 실행되는 동일한 VPC의 퍼블릭 서브넷에 Lambda 함수를 연결합니다.
C. Compute Savings Plan을 구매합니다. Lambda 함수의 지속 시간과 메모리 사용량, 호출 횟수, 전송되는 데이터 양을 최적화합니다. Lambda 함수를 EC2 인스턴스가 포함된 프라이빗 서브넷에 연결합니다.
D. Compute Savings Plan을 구매합니다. Lambda 함수의 지속 시간과 메모리 사용, 호출 횟수, 전송되는 데이터 양을 최적화합니다. Lambda 함수를 Lambda 서비스 VPC에 보관합니다.
C. Compute Savings Plan을 구매합니다. Lambda 함수의 지속 시간과 메모리 사용량, 호출 횟수, 전송되는 데이터 양을 최적화합니다. Lambda 함수를 EC2 인스턴스가 포함된 프라이빗 서브넷에 연결합니다.
직접 네트워크 액세스가 필요합니다. 애플리케이션 리소스의 비용 효율성을 극대화하고 네트워크 지연 시간을 최소화하려면 다음이 필요합니다.
Compute Savings Plan 구매
- Compute Savings Plan은 모든 AWS 컴퓨팅 서비스(예: EC2, Lambda)에 대해 유연성과 비용 절감을 제공합니다. 절약 플랜은 리소스를 특정 인스턴스 유형에 묶지 않으므로 Lambda와 EC2를 함께 사용할 때 유리합니다.
Lambda 함수를 프라이빗 서브넷에 연결
- Lambda 함수가 프라이빗 서브넷의 EC2 인스턴스에 접근하려면 Lambda 함수도 동일한 VPC와 프라이빗 서브넷에 연결되어야 합니다. 이를 통해 네트워크 지연 시간을 줄일 수 있습니다.
Lambda 비용 최적화
- Lambda 함수의 지속 시간, 메모리 사용량, 호출 횟수, 데이터 전송량을 최적화하여 비용을 추가로 절감합니다.
■ Question #418
솔루션 아키텍트는 팀원이 개발 계정과 프로덕션 계정의 두 가지 AWS 계정에서 Amazon S3 버킷에 액세스할 수 있도록 허용해야 합니다. 팀은 현재 계정에서 적절한 권한이 있는 IAM 그룹에 할당된 고유한 IAM 사용자를 사용하여 개발 계정에서 S3 버킷에 액세스 할 수 있습니다.
솔루션 아키텍트는 프로덕션 계정에서 IAM 역할을 만들었습니다. 이 역할에는 프로덕션 계정에서 S3 버킷에 대한 액세스 권한을 부여하는 정책이 있습니다.
최소 권한 원칙을 준수하는 동시에 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
A. 개발 계정 사용자에게 관리자 액세스 정책을 연결합니다.
B. 프로덕션 계정의 역할에 대한 신뢰 정책에서 개발 계정을 주체로 추가합니다.
C. 프로덕션 계정의 S3 버킷에서 S3 블록 공개 액세스 기능을 끕니다.
D. 각 팀원에 대해 고유한 자격 증명을 가진 프로덕션 계정에 사용자를 만듭니다.
B. 프로덕션 계정의 역할에 대한 신뢰 정책에서 개발 계정을 주체로 추가합니다.
프로덕션 계정의 S3 버킷에 접근하려면 두 계정 간의 신뢰 관계를 설정하고 개발 계정 사용자가 역할을 가질 수 있도록 설정해야 합니다. 최소 권한 원칙을 준수하면서 이러한 요구 사항을 충족하려면 다음을 수행합니다:
역할 기반 액세스 설정 (Option B):
- 프로덕션 계정의 IAM 역할에 신뢰 정책을 추가하여 개발 계정을 주체로 지정합니다.
- 신뢰 정책은 "개발 계정에서 특정 역할을 맡을 수 있도록 허용"하는 설정입니다.
- 개발 계정의 사용자는 프로덕션 계정 역할을 "가정(assume)"하여 프로덕션 S3 버킷에 접근할 수 있습니다.
■ Question #419
한 회사에서 모든 기능이 활성화된 AWS Organizations를 사용하고 ap-southeast-2 지역에서 여러 Amazon EC2 워크로드를 실행합니다. 이 회사에는 다른 지역에서 리소스가 생성되는 것을 방지하는 서비스 제어 정책(SCP)이 있습니다. 보안 정책에 따라 회사는 모든 저장 데이터를 암호화해야 합니다.
감사 결과 직원들이 볼륨을 암호화하지 않고 EC2 인스턴스에 대한 Amazon Elastic Block Store (Amazon EBS) 볼륨을 생성한 것으로 밝혀졌습니다. 이 회사는 IAM 사용자 또는 루트 사용자가 ap-southeast-2에서 시작하는 모든 새 EC2 인스턴스에서 암호화된 EBS 볼륨을 사용하기를 원합니다. 이 회사는 EBS 볼륨을 생성하는 직원에게 최소한의 영향을 미치는 솔루션을 원합니다.
이러한 요구 사항을 충족하는 단계의 조합은 무엇입니까? (두 가지를 선택하십시오.)
A. Amazon EC2 콘솔에서 EBS 암호화 계정 속성을 선택하고 기본 암호화 키를 정의합니다.
B. IAM 권한 경계를 만듭니다. 권한 경계를 루트 조직 단위(OU)에 연결합니다. ec2:Encrypted 조건이 false 일 때 ec2:CreateVolume 작업을 거부하도록 경계를 정의합니다.
C. SCP를 만듭니다. SCP를 루트 조직 단위(OU)에 연결합니다. ec2:Encrypted 조건이 false와 같을 때 ec2:CreateVolume 작업을 거부하도록 SCP를 정의합니다.
D. ec2:Encrypted 조건이 false인 경우 ec2:CreateVolume 작업을 거부하도록 각 계정에 대한 IAM 정책을 업데이트합니다.
E. 조직 관리 계정에서 기본 EBS 볼륨 암호화 설정을 지정합니다.
C. SCP를 만듭니다. SCP를 루트 조직 단위(OU)에 연결합니다. ec2:Encrypted 조건이 false와 같을 때 ec2:CreateVolume 작업을 거부하도록 SCP를 정의합니다.
- SCP(서비스 제어 정책)는 조직의 모든 계정에 일괄적으로 정책을 적용할 수 있는 강력한 도구입니다.
- 'ec2:Encrypted' 조건을 'false'로 설정한 상태에서 'ec2:CreateVolume' 작업을 거부하면 암호화되지 않은 볼륨 생성이 전역적으로 차단됩니다.
- 이를 통해 사용자가 실수로 암호화되지 않은 볼륨을 생성하는 것을 방지할 수 있습니다.
E. 조직 관리 계정에서 기본 EBS 볼륨 암호화 설정을 지정합니다.
- 조직 관리 계정에서 기본 EBS 암호화 설정을 활성화하면, 모든 계정에서 새로 생성되는 볼륨이 자동으로 암호화됩니다.
- 이 설정은 관리 오버헤드를 줄이고, 보안을 강화하며, 사용자가 추가적인 작업 없이 자동으로 정책을 준수하도록 만듭니다.
A와 E 조합과의 비교
C와 E 강점
- SCP는 암호화되지 않은 볼륨 생성을 강제로 막을 수 있으므로 강력한 보안 정책을 제공할 수 있습니다.
- 기본 EBS 암호화와 결합하면 이중 보안 계층이 형성됩니다.
C와 E 한계
- SCP로 인해 사용자가 암호화되지 않은 볼륨을 생성하려 할 경우 에러가 발생합니다. 이는 사용자가 혼란을 겪을 가능성을 내포하며, 운영 중단으로 이어질 수 있습니다.
A와 E 강점
- 기본 EBS 암호화를 활성화하면 모든 EBS 볼륨이 자동으로 암호화됩니다.
- 사용자는 별도의 작업을 요구받지 않으므로 직관적이며 사용자 경험에 영향을 덜 미칩니다.
A와 E 한계
- A는 EC2 콘솔 설정에 국한되며, 조직 계정 전체에 대한 제어 수준이 낮습니다.
- 일부 관리 요구 사항을 충족하지 못할 수 있습니다.
C와 E 조합은 더 강력한 보안과 조직 수준의 정책 강제를 제공합니다.
- 이 조합은 규정 준수가 필수적인 환경에서 이상적입니다.
A와 E 조합은 사용자 친화적이고 최소한의 관리 오버헤드로 보안을 강화합니다.
- 이 조합은 사용자의 작업 흐름에 영향을 덜 미치는 환경에 적합합니다.
■ Question #420
한 회사에서는 Amazon RDS for PostgreSQL DB 클러스터를 사용하여 프로덕션 데이터베이스 워크로드에 대한 시간 소모적인 데이터베이스 관리 작업을 간소화하고자 합니다. 이 회사는 데이터베이스가 고가용성을 유지하고 대부분의 시나리오에서 40초 이내에 자동 장애 조치 지원을 제공하려고 합니다. 이 회사는 기본 인스턴스에서 읽기를 오프로드하고 비용을 최대한 낮추고자 합니다.
어떤 솔루션이 이러한 요구 사항을 충족할까요?
A. Amazon RDS Multi-AZ DB 인스턴스 배포를 사용합니다. 읽기 복제본 하나를 만들고 읽기 워크로드를 읽기 복제본으로 가리킵니다.
B. Amazon RDS Multi-AZ DB Duster 배포를 사용합니다. 두 개의 읽기 복제본을 만들고 읽기 워크로드를 읽기 복제본으로 가리킵니다.
C. Amazon RDS Multi-AZ DB 인스턴스 배포를 사용합니다. 읽기 워크로드를 Multi-AZ 쌍의 보조 인스턴스로 지정합니다.
D. Amazon RDS Multi-AZ DB 클러스터 배포를 사용하여 읽기 워크로드를 리더 엔드포인트로 지정합니다.
D. Amazon RDS Multi-AZ DB 클러스터 배포를 사용하여 읽기 워크로드를 리더 엔드포인트로 지정합니다.
- 고가용성: Amazon RDS Multi-AZ DB 클러스터는 고가용성과 짧은 복구 시간을 제공합니다. 장애 조치 시 40초 이내의 복구가 가능하며 대부분의 시나리오에서 이 요구를 충족합니다.
- 읽기 오프로드: 클러스터의 리더 엔드포인트를 사용하여 읽기 전용 트래픽을 전담 처리할 수 있습니다. 이는 읽기 작업을 기스턴스에서 분리해 성능을 최적화합니다.
- 비용 효율성: Multi-AZ DB 클러스터 배포는 내장된 읽기 복제본 기능을 제공하며, 별도로 추가 리소스를 관리할 필요가 없습니다.
- 자동 장애 조치: 클러스터 아키텍처는 자동 장애 조치 기능을 기본으로 제공합니다.
AWS SAA-C03 Examtopics (501 ~ 520) (0) | 2024.12.20 |
---|---|
AWS SAA-C03 Examtopics (481 ~ 500) (1) | 2024.12.20 |
AWS SAA-C03 Examtopics (461 ~ 480) (1) | 2024.12.20 |
AWS SAA-C03 Examtopics (441 ~ 460) (2) | 2024.12.19 |
AWS SAA-C03 Examtopics (421 ~ 440) (0) | 2024.12.17 |