상세 컨텐츠

본문 제목

AWS SAA-C03 Examtopics (521 ~ 540)

let's study/AWS SAA-C03

by DarkSoul.Story 2024. 12. 20. 23:12

본문

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

 

■ Question #521

소매업체에 여러 사업이 있습니다. 각 사업의 IT 팀은 자체 AWS 계정을 관리합니다. 각 팀 계정은 AWS Organizations의 조직에 속합니다. 각 팀은 자체 AWS 계정의 Amazon DynamoDB 테이블에서 제품 재고 수준을 모니터링합니다.
이 회사는 공유 AWS 계정에 중앙 재고 보고 애플리케이션을 배포하고 있습니다. 이 애플리케이션은 모든 팀의 DynamoDB 테이블에서 항목을 읽을 수 있어야 합니다.

이러한 요구 사항을 가장 안전하게 충족하는 인증 옵션은 무엇입니까?

A. 인벤토리 애플리케이션 계정에서 DynamoDB를 AWS Secrets Manager와 통합합니다. DynamoDB 테이블을 인증하고 읽기 위해 Secrets Manager의 올바른 비밀을 사용하도록 애플리케이션을 구성합니다. 30일마다 비밀 로테이션을 예약합니다.

B. 모든 비즈니스 계정에서 프로그래밍 액세스 권한이 있는 IAM 사용자를 만듭니다. 올바른 IAM 사용자 액세스 키 ID와 비밀 액세스 키를 사용하여 DynamoDB 테이블을 인증하고 읽도록 애플리케이션을 구성합니다. 30일마다 IAM 액세스 키를 수동으로 순환합니다.

C. 모든 비즈니스 계정에서 DynamoDB 테이블에 대한 액세스 권한을 부여하는 정책과 인벤토리 애플리케이션 계정에서 특정 역할을 신뢰하는 신뢰 정책이 있는 BU_ROLE이라는 IAM 역할을 만듭니다. 인벤토리 계정에서 STS AssumeRole API 작업에 대한 액세스를 허용하는 APP_ROLE이라는 역할을 만듭니다. 애플리케이션이 APP_ROLE을 사용하도록 구성하고 DynamoDB 테이블을 읽기 위해 교차 계정 역할 BU_ROLE을 가정합니다.

D. DynamoDB를 AWS Certificate Manager(ACM)와 통합합니다. DynamoDB를 인증하기 위한 ID 인증서를 생성합니다. 올바른 인증서를 사용하여 DynamoDB 테이블을 인증하고 읽도록 애플리케이션을 구성합니다.

더보기

C. 모든 비즈니스 계정에서 DynamoDB 테이블에 대한 액세스 권한을 부여하는 정책과 인벤토리 애플리케이션 계정에서 특정 역할을 신뢰하는 신뢰 정책이 있는 BU_ROLE이라는 IAM 역할을 만듭니다. 인벤토리 계정에서 STS AssumeRole API 작업에 대한 액세스를 허용하는 APP_ROLE이라는 역할을 만듭니다. 애플리케이션이 APP_ROLE을 사용하도록 구성하고 DynamoDB 테이블을 읽기 위해 교차 계정 역할 BU_ROLE을 가정합니다.

IAM 역할과 AWS STS를 통한 교차 계정 액세스를 활용하여 가장 안전하고 유연한 방법으로 각 팀의 DynamoDB 테이블에 접근할 수 있게 합니다. 임시 자격 증명을 사용함으로써 보안 강화와 운영 편의성을 동시에 달성할 수 있습니다.

- AWS STS(AWS Security Token Service) : AWS에서 보안 토큰을 생성하는 서비스로, 사용자나 애플리케이션에 임시 보안 자격 증명(temporary security credentials)을 발급해주는 서비스입니다. 이러한 임시 자격 증명은 AWS 리소스에 제한된 시간 동안 안전하게 접근할 수 있도록 해줍니다.

교차 계정 액세스를 위한 AWS의 권장 방식
- AWS STS(AssumeRole)는 교차 계정 액세스에 대해 가장 안전하고 유연한 방식입니다. 여러 AWS 계정 간에 리소스에 접근해야 할 때, 특정 권한을 가진 IAM 역할을 생성하고, 이를 사용하여 필요할 때만 임시 자격 증명을 사용하여 액세스할 수 있습니다  이 방법은 영구 자격 증명을 사용하는 것보다 더 안전하며, 권한을 세밀하게 관리할 수 있습니다.
- AssumeRole는 AWS Identity and Access Management(IAM)에서 제공하는 API로, AWS 리소스에 접근할 수 있는 임시 자격 증명을 발급받아 다른 역할(Role)을 맡는 기능을 제공합니다. 이 기능은 주로 여러 AWS 계정 간의 리소스 접근을 제어하거나, 권한을 제한하는 환경에서 유용하게 사용됩니다. (주요 사례 : 교차 계정 접근, 임시 권한 위힘, 최소 권한 원칙 구현 등)

역할 기반 액세스 제어 (Role-Based Access Control, RBAC)
- IAM 역할은 특정 권한과 신뢰 정책을 바탕으로 정의되며, 계정 간의 신뢰 관계를 설정할 수 있습니다. 각 비즈니스 계정에서는 BU_ROLE 역할을 생성하여 해당 계정 내의 DynamoDB 테이블에 대한 접근 권한을 부여하고, 인벤토리 애플리케이션 계정에서 해당 역할을 신뢰하도록 설정합니다.
- 중앙에서 운영되는 인벤토리 애플리케이션은 APP_ROLE을 사용하여 이 역할을 가정(AssumeRole)하고, 각 팀 계정의 DynamoDB 테이블에 안전하게 접근할 수 있습니다.

STS와 임시 자격 증명
- AWS STS는 임시 자격 증명을 제공하므로, 자격 증명이 노출되더라도 시간 제한이 있습니다. 이로 인해 보안 위험이 크게 줄어듭니다. 애플리케이션은 필요할 때마다 역할을 가정하고 DynamoDB 테이블을 읽을 수 있습니다.
- 이 방식은 보안이 뛰어나고 관리의 유연성이 높습니다.


■ Question #522

한 회사가 Amazon Elastic Kubernetes Service(Amazon EKS)를 사용하여 컨테이너 애플리케이션을 실행합니다. 회사의 작업 부하가 하루 종일 일정하지 않습니다. 회사는 Amazon EKS가 작업 부하에 따라 확장 및 축소되기를 원합니다.

어떤 단계 조합이 이러한 요구 사항을 가장 적은 운영 오버헤드로 충족할 수 있을까요? (두 가지를 선택하세요.)

A. AWS Lambda 함수를 사용하여 EKS 클러스터의 크기를 조정합니다.
B. Kubernetes Metrics Server를 사용하여 수평 파드(pod) 자동 확장(Auto Scaling)을 활성화합니다.
C. Kubernetes Cluster Autoscaler를 사용하여 클러스터의 노드 수를 관리합니다.
D. Amazon API Gateway를 사용하여 Amazon EKS에 연결합니다.
E. AWS App Mesh를 사용하여 네트워크 활동을 관찰합니다.

더보기

B와 C가 EKS 클러스터와 Pod의 자동 확장 및 축소를 가장 적은 운영 오버헤드로 처리할 수 있는 최적의 조합입니다. Kubernetes Metrics Server와 Cluster Autoscaler는 EKS (Elastic Kubernetes Service)의 리소스를 자동으로 조정하는 데필요한 핵심 기능을 제공하며, 별도의 추가 관리 없이 효율적으로 트래픽 변화에 대응할 수 있습니다.

- Kubernetes Metrics Server : 클러스터 내에서 실행되는 리소스 사용량(예: CPU, 메모리)과 같은 실시간 메트릭 데이터를 수집하고 제공하는 경량화된 모니터링 솔루션입니다. Kubernetes의 클러스터 성능을 모니터링하거나 자동으로 스케일링(HPA, Horizontal Pod Autoscaler)을 설정할 때 사용

B. Kubernetes Metrics Server를 사용하여 Horizontal Pod Autoscaler를 활성화합니다.
- Horizontal Pod Autoscaler(HPA)은 Kubernetes Metrics Server와 연동하여 Pod의 수를 자동으로 확장하거나 축소할 수 있는 기능으로, 애플리케이션의 부하에 따라 필요한 리소스를 동적으로 확장하거나 축소합니다.
- Metrics Server는 Pod의 CPU 및 메모리 사용량과 같은 메트릭을 수집하여, 미리 정의된 조건(예: CPU 사용률 70% 이상일 때)을 충족하면 Pod의 수를 자동으로 확장하거나 축소합니다. 이를 통해 애플리케이션의 트래픽이 급증하거나 감소할 때 자동으로 처리 용량을 조정할 수 있습니다.
- 운영 오버헤드가 적고, EKS (Elastic Kubernetes Service) 클러스터 내에서 간편하게 관리할 수 있기 때문에 이 방법은 Pod의 수를 조정하는 가장 적합한 솔루션입니다.

C. Kubernetes Cluster Autoscaler를 사용하여 클러스터의 노드 수를 관리합니다.
- Kubernetes Cluster Autoscaler는 EKS 클러스터의 노드 수를 자동으로 확장하거나 축소하는 기능을 제공합니다. 클러스터 내에 Pod를 배포하기 위한 충분한 리소스가 없으면 Cluster Autoscaler가 자동으로 새로운 노드를 추가하고, 더 이상 노드가가필요하지 않으면 노드를 축소시킵니다.
- 이는 Pod 수가 증가하여 더 많은 컴퓨팅 리소스가 필요할 때 자동으로 노드를 추가하고, 트래픽이 줄어들면 노드를 줄여 비용을 절감할 수 있게 해줍니다. Cluster Autoscaler는 노드 단위의 확장을 처리하며, 수동 개입 없이도 리소스를 효율적으로 관리할 수 있어 운영 오버헤드가 적습니다.


■ Question #523

회사는 마이크로서비스 기반의 서버리스 웹 애플리케이션을 운영하고 있습니다. 애플리케이션은 여러 Amazon DynamoDB 테이블에서 데이터를 조회할 수 있어야 하며, 애플리케이션의 기본 성능에 영향을 주지 않아야 합니다. 솔루션 아키텍트는 애플리케이션이 성능에 영향을 주지 않으면서 데이터를 조회할 수 있도록 해야 합니다.

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

A. AWS AppSync 파이프라인 리졸버
B. Amazon CloudFront와 Lambda@Edge 함수
C. 엣지 최적화된 Amazon API Gateway와 AWS Lambda 함수
D. Amazon Athena Federated Query와 DynamoDB 커넥터

더보기

A. AWS AppSync 파이프라인 리졸버 (AWS AppSync pipeline resolvers)

AWS AppSync 파이프라인 리졸버는 다양한 데이터 소스에서 병렬로 데이터를 조회하여, 성능에 영향을 주지 않고 데이터를 효율적으로 처리할 수 있습니다.

AWS AppSync
- AppSync는 GraphQL API를 통해 여러 데이터 소스에서 데이터를 가져오거나 업데이트할 수 있는 완전 관리형 서비스입니다. 이를 통해 DynamoDB와 같은 여러 데이터 소스에서 데이터를 조회할 수 있습니다.
- 파이프라인 리졸버 (pipeline resolvers)는 다양한 데이터 소스에서 데이터를 병렬로 조회할 수 있는 기능을 제공합니다. 이를 통해 애플리케이션이 여러 데이터 소스(DynamoDB 테이블 포함)에서 데이터를 효율적으로 가져와, 성능 저하 없이 데이터를 통합할 수 있습니다.
- AppSync는 서버리스 아키텍처로 동작하므로 운영 오버헤드가 적고, 자동으로 확장되어 트래픽이 많아도 성능에 영향을 주지 않도록 설계되어 있습니다.

성능과 효율성
- AppSync는 자동으로 API 요청을 최적화하고 병렬 처리를 통해 여러 데이터 소스에서 데이터를 가져올 수 있기 때문에, 애플리케이션 성능에 영향을 주지 않으면서도 필요한 데이터를 조회할 수 있습니다.
- DynamoDB와의 긴밀한 통합 덕분에 빠르고 효율적인 데이터 조회가 가능합니다. 이는 DynamoDB에 대한 직접적인 쿼리보다 더 높은 수준의 데이터 통합과 비용 효율성을 제공할 수 있습니다.


■ Question #524

회사는 IAM 권한과 관련된 엑세스 거부(Access Denied) 오류 및 권한 없음(Unauthorized) 오류를 분석하고 문제를 해결하고자 합니다. 회사는 AWS CloudTrail을 활성화한 상태입니다.

이 요구 사항을 가장 적은 노력으로 충족할 솔루션은 무엇입니까?

A. AWS Glue를 사용하고, 오류를 조회하기 위해 CloudTrail 로그에 대해 사용자 지정 스크립트를 작성합니다.
B. AWS Batch를 사용하고, 오류를 조회하기 위해 CloudTrail 로그에 대해 사용자 지정 스크립트를 작성합니다.
C. Amazon Athena 쿼리로 CloudTrail 로그를 검색하여 오류를 식별합니다.
D. Amazon QuickSight로 CloudTrail 로그를 검색하고, 오류를 식별하기 위한 대시보드를 만듭니다.

더보기

C. Amazon Athena 쿼리로 CloudTrail 로그를 검색하여 오류를 식별합니다.


- AWS CloudTrail : AWS 계정에서 이루어지는 모든 API 호출 및 활동을 추적하고 기록하는 서비스입니다. 이를 통해 사용자는 AWS 리소스에서 발생하는 작업들을 모니터링하고, 보안 분석, 감사, 규정 준수 확인, 문제 해결 등에 활용할 수 있습니다. CloudTrail은 특히 보안 및 규정 준수 요구 사항을 충족하는 데 매우 유용합니다. (API호출 기록, 변경 사항 추적, 로그 저장 및 분석, 실시간 모니터링, 보안 및 규정 준수 지원 등)

 

- Amazon Athena는 S3에 저장된 데이터를 표준 SQL 쿼리로 분석할 수 있는 서버리스 서비스입니다. CloudTrail 로그는 기본적으로 S3에 저장되므로, Athena에서 이를 바로 쿼리하여 Access Denied나 Unauthorized 오류를 식별할 수 있습니다.
- 추가적인 스크립트 작성 없이 간단한 SQL 쿼리로 로그를 분석할 수 있어, 가장 적은 노력을 필요로 합니다. CloudTrail 로그에 특정 패턴(예: "AccessDenied", "UnauthorizedOperation")을 검색하는 방식으로 쉽게 오류를 찾아낼 수 있습니다.
- 가장 적은 노력으로 CloudTrail 로그에서 오류를 빠르게 식별할 수 있는 매우 효율적인 방법입니다.


■ Question #525

회사는 기존 AWS 사용 비용을 운영 비용 대시보드에 추가하고 싶어합니다. 솔루션 아키텍트는 회사가 사용 비용에 프로그램적으로 접근할 수 있는 솔루션을 추천해야 합니다. 회사는 현재 연도의 비용 데이터를 액세스할 수 있어야 하며, 향후 12개월 동안의 비용을 예측할 수 있어야 합니다.

이 요구 사항을 최소한의 운영 오버헤드로 충족할 솔루션은 무엇입니까?

A. 페이지네이션을 사용하여 AWS Cost Explorer API로 사용 비용 관련 데이터를 액세스합니다.
B. 다운로드 가능한 AWS Cost Explorer 보고서 .csv 파일을 사용하여 사용 비용 관련 데이터를 액세스합니다.
C. AWS Budgets 작업을 구성하여 FTP를 통해 회사에 사용 비용 데이터를 전송합니다.
D. 사용 비용 데이터를 위한 AWS Budgets 보고서를 생성하고, SMTP를 통해 데이터를 회사에 전송합니다.

더보기

A. 페이지네이션(pagination)을 사용하여 AWS Cost Explorer API로 사용 비용 관련 데이터를 액세스합니다.

- AWS Cost Explorer API는 AWS 사용 비용 및 사용량 데이터를 프로그램적으로 액세스할 수 있는 기능을 제공합니다. 이 API는 비용 추적뿐만 아니라 향후 12개월 동안의 예측 기능도 지원합니다.
- 또한 페이지네이션(pagination)은 API에서 대량의 데이터를 다룰 때 데이터를 나눠서 가져오는 방식으로, 이를 사용해 큰 비용 데이터를 효율적으로 처리할 수 있습니다.
- 운영 오버헤드가 매우 적습니다. 기본적으로 API 호출을 통해 필요한 데이터를 직접 가져오고 분석할 수 있기 때문에 추가적인 관리 작업이 거의 없습니다.
- 현재 연도의 비용 데이터와 향후 12개월의 비용 예측을 프로그램적으로 액세스할 수 있으므로, 이 요구 사항을 충족하는 가장 적합한 솔루션입니다.


■ Question #526

솔루션 아키텍트가 애플리케이션의 복원력을 검토하고 있습니다. 솔루션 아키텍트는 데이터베이스 관리자가 최근 확장 작업의 일환으로 애플리케이션의 Amazon Aurora PostgreSQL 데이터베이스 작성기 인스턴스(writer instance)를 장애 조치(failover)한 사실을 알게 되었습니다. 이 장애 조치로 인해 애플리케이션이 3분간의 다운타임을 겪었습니다.

확장 작업 중 다운타임을 줄이면서 최소한의 운영 오버헤드를 요구하는 솔루션은 무엇입니까?

A. 클러스터 내에 더 많은 Aurora PostgreSQL 읽기 복제본을 생성하여 장애 조치 중에 부하를 처리합니다.
B. 동일한 AWS 리전에 보조 Aurora PostgreSQL 클러스터를 설정하고, 장애 조치 중에 애플리케이션을 보조 클러스터의 작성기 엔드포인트로 업데이트합니다.
C. 장애 조치 중 부하를 처리하기 위해 Amazon ElastiCache for Memcached 클러스터를 생성합니다.
D. 데이터베이스에 대한 Amazon RDS 프록시를 설정하고, 애플리케이션을 프록시 엔드포인트로 업데이트합니다.

더보기

D. 데이터베이스에 대한 Amazon RDS 프록시를 설정하고, 애플리케이션을 프록시 엔드포인트로 업데이트합니다.

애플리케이션의 복원력을 높이고, 확장 작업 중 다운타임을 최소화하며 운영 오버헤드를 줄이는 솔루션을 선택하는 것이 이번 질문의 핵심

- Amazon RDS 프록시는 데이터베이스와 애플리케이션 사이에 프록시를 두어 연결 풀링(connection pooling)을 제공하고, 장애 조치 중에도 연결을 유지하여 애플리케이션의 중단을 최소화합니다.

 

- 연결 풀링(connection pooling) : 데이터베이스나 서버와의 연결을 효율적으로 관리하기 위한 기법으로, 미리 일정 수의 연결 (Connection)을 생성해두고 필요할 때 이를 재사용함으로써 성능을 최적화하는 방법

 

- RDS 프록시는 장애 조치가 발생해도 애플리케이션에서의 재연결 시간을 줄여주기 때문에 다운타임이 최소화됩니다. 이는 특히 Aurora PostgreSQL과 같은 고가용성 데이터베이스와 함께 사용될 때 매우 효과적입니다.
- 운영 오버헤드가 적습니다, 왜냐하면 프록시를 설정하고 엔드포인트를 애플리케이션에 연결한 후에는 추가적인 관리 작업이 거의 없기 때문입니다.
- 쓰기 작업과 읽기 작업 모두에 대한 연결 관리가 가능하므로, 장애 조치 상황에서도 애플리케이션의 연속성을 보장할 수 있습니다.


■ Question #527

한 회사에 단일 AWS 지역에서 실행되는 지역 구독 기반 스트리밍 서비스가 있습니다. 아키텍처는 Amazon EC2 인스턴스의 웹 서버와 애플리케이션 서버로 구성되어 있습니다. EC2 인스턴스는 Elastic Load Balancer 뒤의 Auto Scaling 그룹에 있습니다. 아키텍처에는 여러 가용 영역에 걸쳐 확장되는 Amazon Aurora 글로벌 데이터베이스 클러스터가 포함됩니다. 
이 회사는 전 세계적으로 확장하고 애플리케이션의 다운타임을 최소화하고자 합니다.

어떤 솔루션이 가장 많은 내결함성을 제공할까요?

A. 웹 계층과 애플리케이션 계층에 대한 자동 확장 그룹을 확장하여 두 번째 지역의 가용성 영역에 인스턴스를 배포합니다. Aurora 글로벌 데이터베이스를 사용하여 기본 지역과 두 번째 지역에 데이터베이스를 배포합니다. 두 번째 지역에 대한 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용합니다.
B. 웹 티어와 애플리케이션 티어를 두 번째 리전에 배포합니다. 두 번째 리전에 Aurora PostgreSQL 크로스 리전 Aurora 복제본을 추가합니다. 두 번째 리전에 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용합니다. 필요에 따라 보조를 기본으로 승격합니다.
C. 웹 티어와 애플리케이션 티어를 두 번째 리전에 배포합니다. 두 번째 리전에 Aurora PostgreSQL 데이터베이스를 만듭니다. AWS Database Migration Service(AWS DMS)를 사용하여 기본 데이터베이스를 두 번째 리전에 복제합니다. 두 번째 리전에 장애 조치 라우팅 정책이 있는 Amazon Route 53 상태 확인을 사용합니다.
D. 웹 계층과 애플리케이션 계층을 두 번째 지역에 배포합니다. Amazon Aurora 글로벌 데이터베이스를 사용하여 기본 지역과 두 번째 지역에 데이터베이스를 배포합니다. 두 번째 지역에 대한 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용합니다. 필요에 따라 보조를 기본으로 승격합니다.

더보기

D. 웹 계층과 애플리케이션 계층을 두 번째 지역에 배포합니다. Amazon Aurora 글로벌 데이터베이스를 사용하여 기본 지역과 두 번째 지역에 데이터베이스를 배포합니다. 두 번째 지역에 대한 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용합니다. 필요에 따라 보조를 기본으로 승격합니다.

전 세계적으로 확장하고, 다운타임을 최소화하며 내결함성을 극대화하는 솔루션

- Aurora 글로벌 데이터베이스를 사용하여 기본 리전과 보조 리전 간에 데이터를 빠르고 효율적으로 복제합니다. Aurora 글로벌 데이터베이스는 초저지연 데이터 복제를 제공하며, 데이터베이스 인스턴스 장애 시 몇 분 이내에 장애 조치가 가능합니다.

 

- Aurora 글로벌 데이터베이스 : 여러 AWS 리전(Region)에 걸쳐 데이터를 복제할 수 있는 고성능, 고가용성 데이터베이스 솔루션입니다. 이를 통해 전 세계 여러 리전에서 동일한 데이터베이스를 실시간으로 사용할 수 있으며, 지역 장애나 재해복구에 대비한 복원력을 제공

 

- 두 번째 리전에 배포된 인프라는 Route 53 상태 확인과 자동화된 장애 조치 라우팅을 통해 트래픽을 보조 리전으로 자동으로 전환할 수 있습니다.


- Route 53 : 클라우드 기반 도메인 이름 시스템(DNS) 웹 서비스로, 인터넷 도메인 이름을 IP 주소로 변환하여 사용자가 웹사이트나 애플리케이션에 연결할 수 있도록 해줌

 

- Aurora 글로벌 데이터베이스는 빠른 장애 조치 시간을 제공하여 다운타임을 최소화하며, 운영 오버헤드가 적습니다. 이 솔루션은 전 세계적으로 확장 가능하고 지연 시간이 적으며, 데이터 손실이 거의 발생하지 않습니다.


- 이 구조는 전 세계적으로 확장하고 내결함성을 극대화하는데 매우 적합합니다.


■ Question #528

데이터 분석 회사가 일괄 처리 시스템을 AWS로 마이그레이션하려고 합니다. 이 회사는 FTP를 통해 낮 동안 수천 개의 작은 데이터 파일을 주기적으로 수신합니다. 온프레미스 일괄 작업은 데이터 파일을 밤새 처리합니다. 그러나 일괄 작업을 완료하는 데 몇 시간이 걸립니다.

이 회사는 AWS 솔루션이 파일을 보내는 FTP 클라이언트를 최소한으로 변경하여 최대한 빨리 들어오는 데이터 파일을 처리하기를 원합니다. 솔루션은 파일이 성공적으로 처리된 후 들어오는 데이터 파일을 삭제해야 합니다. 각 파일에 대한 처리에는 3~8분이 걸립니다.

어떤 솔루션이 이러한 요구 사항을 가장 운영 효율적인 방식으로 충족할까요?

A. FTP 서버를 실행하는 Amazon EC2 인스턴스를 사용하여 들어오는 파일을 Amazon S3 Glacier Flexible Retrieval의 객체로 저장합니다. AWS Batch에서 작업 대기열을 구성합니다. Amazon EventBridge 규칙을 사용하여 작업을 호출하여 S3 Glacier Flexible Retrieval에서 매일 밤 객체를 처리합니다. 작업이 객체를 처리한 후 객체를 삭제합니다.
B. FTP 서버를 실행하는 Amazon EC2 인스턴스를 사용하여 Amazon Elastic Block Store(Amazon EBS) 볼륨에 수신 파일을 저장합니다. AWS Batch에서 작업 대기열을 구성합니다. Amazon EventBridge 규칙을 사용하여 작업을 호출하여 EBS 볼륨에서 매일 밤 파일을 처리합니다. 작업이 파일을 처리한 후 파일을 삭제합니다.
C. AWS Transfer Family를 사용하여 FTP 서버를 생성하여 Amazon Elastic Block Store(Amazon EBS) 볼륨에 수신 파일을 저장합니다. AWS Batch에서 작업 대기열을 구성합니다. 각 파일이 도착할 때 Amazon S3 이벤트 알림을 사용하여 AWS Batch에서 작업을 호출합니다. 작업이 파일을 처리한 후 파일을 삭제합니다.
D. AWS Transfer Family를 사용하여 Amazon S3 Standard에 수신 파일을 저장할 FTP 서버를 만듭니다. AWS Lambda 함수를 만들어 파일을 처리하고 처리 후 파일을 삭제합니다. S3 이벤트 알림을 사용하여 파일이 도착하면 Lambda 함수를 호출합니다.

더보기

D. AWS Transfer Family를 사용하여 Amazon S3 Standard에 수신 파일을 저장할 FTP 서버를 만듭니다. AWS Lambda 함수를 만들어 파일을 처리하고 처리 후 파일을 삭제합니다. S3 이벤트 알림을 사용하여 파일이 도착하면 Lambda 함수를 호출합니다.

- AWS Transfer Family : SFTP(Secure File Transfer Protocol), FTPS(File Transfer Protocol Secure), 및 FTP(File Transfer Protocol)를 지원하는 완전 관리형 파일 전송 서비스로, 이를 통해 기존의 파일 전송 워크플로우를 AWS 클라우드로 쉽게 마이그레이션할 수 있습니다.

 

- AWS Transfer Family는 FTP 클라이언트와 통합하여 Amazon S3에 파일을 저장하는 데 적합합니다. 클라이언트 쪽 변경 사항 없이 AWS에 파일을 업로드할 수 있으므로, 이 회사의 요구 사항인 최소한의 변경을 충족합니다. 

- Amazon S3는 객체 스토리지로, 비용 효율적이고 높은 내구성을 제공합니다. 파일 기반 작업을 처리하는 데 적합하며, 파일을 성공적으로 처리한 후 자동 삭제가 가능합니다.
- Lambda 함수는 S3 이벤트 알림에 의해 트리거되어 파일이 도착할 때마다 실시간으로 처리할 수 있습니다. Lambda는 서버리스로 작동하므로 운영 오버헤드가 매우 적으며, 파일 처리 후 자동으로 파일을 삭제하는 기능을 구현할 수 있습니다.
- Lambda는 15분까지 실행이 가능하므로, 3~8분의 처리 시간을 충분히 처리할 수 있습니다. 또한, S3와 Lambda의 결합으로 파일을 즉시 처리하고 불필요한 스토리지를 삭제할 수 있습니다.


■ Question #529

한 회사가 워크로드를 AWS로 마이그레이션하고 있습니다. 이 회사는 데이터베이스에 거래 및 민감한 데이터를 보유하고 있습니다. 이 회사는 AWS 클라우드 솔루션을 사용하여 보안을 강화하고 데이터베이스의 운영 오버헤드를 줄이고자 합니다.

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

A. 데이터베이스를 Amazon EC2로 마이그레이션합니다. 암호화를 위해 AWS Key Management Service(AWS KMS) AWS 관리 키를 사용합니다.
B. Amazon RDS로 데이터베이스를 마이그레이션하고 저장 중 암호화를 구성합니다.
C. Amazon S3로 데이터 마이그레이션 Amazon Macie를 사용하여 데이터 보안 및 보호

D. 데이터베이스를 Amazon RDS로 마이그레이션합니다. 데이터 보안 및 보호를 위해 Amazon CloudWatch Logs를 사용합니다.

더보기

거래 및 민감한 데이터를 보유하고 있으며, 보안을 강화하고 데이터베이스의 운영 오버헤드를 줄이는 것이 목표

 

B. Amazon RDS로 데이터베이스를 마이그레이션하고 저장 중 암호화를 구성합니다.

- Amazon RDS(Relational Database Service)는 관리형 데이터베이스 서비스로, 데이터베이스의 운영 오버헤드를 크게 줄일 수 있는 솔루션입니다. RDS(Relational Database Service)는 자동 백업, 패치 관리, 복구 등의 기능을 제공하므로, 인프라 관리에 대한 부담이 적습니다.
- 또한, 저장 중 암호화를 쉽게 설정할 수 있으며, AWS KMS와 통합하여 관리형 암호화를 사용할 수 있습니다. 이 방식은 민감한 데이터를 안전하게 보호하고, 데이터베이스를 운영하는 데 필요한 보안 수준을 크게 향상시킵니다.
- Key Management Service :  데이터를 보호하는 데 사용되는 암호화 키를 쉽게 만들고 제어할 수 있게 해주는 관리형 서비스
- 보안 강화와 운영 오버헤드 감소 측면에서 매우 적합한 솔루션입니다.


■ Question #530

한 회사에 TCP 및 UDP 멀티플레이어 게임 기능이 있는 온라인 게임 애플리케이션이 있습니다. 이 회사는 Amazon Route 53을 사용하여 애플리케이션 트래픽을 여러 AWS 지역의 여러 네트워크 로드 밸런서(NLB)로 연결합니다. 이 회사는 사용자 증가에 대비하여 온라인 게임의 애플리케이션 성능을 개선하고 지연 시간을 줄여야 합니다.

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

A. NLB 앞에 Amazon CloudFront 배포를 추가합니다. Cache-Control max-age 매개변수를 늘립니다.
B. NLB를 애플리케이션 로드 밸런서(ALB)로 교체합니다. Route 53을 구성하여 대기 시간 기반 라우팅을 사용합니다.
C. NLB 앞에 AWS Global Accelerator를 추가합니다. 올바른 리스너 포트를 사용하도록 Global Accelerator 엔드포인트를 구성합니다.
D. NLB 뒤에 Amazon API Gateway 엔드포인트를 추가합니다. API 캐싱을 활성화합니다. 다른 단계에 대한 메서드 캐싱을 재정의합니다.

더보기

C. NLB 앞에 AWS Global Accelerator를 추가합니다. 올바른 리스너 포트를 사용하도록 Global Accelerator 엔드포인트를 구성합니다.

- AWS Global Accelerator는 TCP 및 UDP 트래픽 모두에 대해 전 세계적으로 사용자 트래픽을 가속화할 수 있는 서비스입니다. 글로벌 네트워크를 통해 최적화된 경로를 사용하여 지연 시간을 줄이는 데 매우 효과적입니다.
- Global Accelerator는 애플리케이션 성능을 향상시키는 데 특히 유용하며, TCP 및 UDP 트래픽을 처리하는 애플리케이션에 적합합니다. 또한, 여러 지역에 분산된 인프라에서 가장 빠른 경로로 트래픽을 전달할 수 있습니다.
- NLB와 함께 사용하면, 게임 트래픽의 지연 시간을 크게 줄이고 성능을 개선할 수 있습니다. 리스너 포트는 트래픽 유형에 맞게 구성할 수 있으며, 최적의 성능을 제공할 수 있습니다.
- 이 솔루션은 게임 트래픽 가속화와 지연 시간 최소화에 매우 적합합니다.


■ Question #531

회사는 타사 데이터 피드와 통합해야 합니다. 데이터 피드는 새 데이터가 소비될 준비가 되면 외부 서비스에 알리기 위해 웹훅을 보냅니다. 개발자는 회사가 웹훅 콜백을 받을 때 데이터를 검색하는 AWS Lambda 함수를 작성했습니다. 개발자는 타사가 호출할 수 있도록 Lambda 함수를 제공해야 합니다.

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

A. Lambda 함수에 대한 함수 URL을 만듭니다. 웹훅을 위해 제3자에게 Lambda 함수 URL을 제공합니다.
B. Lambda 함수 앞에 ALB(Application Load Balancer)를 배포합니다. 웹훅을 위해 타사에 ALB URL을 제공합니다.
C. Amazon Simple Notification Service(Amazon SNS) 토픽을 만듭니다. 토픽을 Lambda 함수에 연결합니다. 웹훅을 위해 제3자에게 SNS 토픽의 공개 호스트 이름을 제공합니다.
D. Amazon Simple Queue Service(Amazon SQS) 대기열을 만듭니다. 대기열을 Lambda 함수에 연결합니다. 웹훅을 위해 제3자에게 SQS 대기열의 공개 호스트 이름을 제공합니다.

더보기

A. Lambda 함수에 대한 함수 URL을 만듭니다. 웹훅을 위해 제3자에게 Lambda 함수 URL을 제공합니다.

- Lambda 함수 URL은 Lambda 함수에 직접적으로 HTTPS 호출을 할 수 있도록 하는 기능입니다. 타사가 이 URL을 호출하면 Lambda 함수가 바로 실행됩니다.
- 이 방식은 설정이 간단하고 추가적인 인프라 관리가 필요하지 않으며, 운영 오버헤드가 최소화됩니다.
- 보안 측면에서는, Lambda 함수 URL에 대해 IAM 정책이나 CORS(Cross-Origin Resource Sharing) 설정을 통해 접근을 제어할 수 있습니다.
- Lambda 함수 URL을 직접 사용하는 것은 가장 효율적인 방식으로, 타사가 별도의 구성 없이 쉽게 웹훅을 호출할 수 있습니다.


■ Question #532

한 회사가 AWS 리전에 워크로드를 보유하고 있습니다. 고객은 Amazon API Gateway REST API를 사용하여 워크로드에 연결하고 액세스합니다. 이 회사는 DNS 공급자로 Amazon Route 53을 사용합니다. 이 회사는 모든 고객에게 개별적이고 안전한 URL을 제공하고자 합니다.

어떤 단계 조합이 이러한 요구 사항을 가장 높은 운영 효율성으로 충족할 수 있을까요? (세 가지를 선택하세요.)

A. 레지스트라에 필요한 도메인을 등록합니다. Route 53 호스팅 존에 와일드카드 사용자 지정 도메인 이름을 만들고 API Gateway 엔드포인트를 가리키는 존에 기록합니다.
B. 다른 지역의 AWS Certificate Manager(ACM)에 있는 도메인과 일치하는 와일드카드 인증서를 요청합니다.
C. Route 53에서 요구 사항에 따라 각 고객에 대한 호스팅 영역을 만듭니다. API Gateway 엔드포인트를 가리키는 영역 레코드를 만듭니다.
D. 동일한 지역의 AWS Certificate Manager(ACM)에서 사용자 지정 도메인 이름과 일치하는 와일드카드 인증서를 요청합니다.
E. API Gateway에서 각 고객에 대해 여러 개의 API 엔드포인트를 생성합니다.
F. REST API를 위한 API Gateway에서 사용자 지정 도메인 이름을 만듭니다. AWS Certificate Manager (ACM)에서 인증서를 가져옵니다.

더보기

A. 레지스트라에 필요한 도메인을 등록합니다. Route 53 호스팅 존에 와일드카드 사용자 지정 도메인 이름을 만들고 API Gateway 엔드포인트를 가리키는 존에 기록합니다.

- 도메인 등록은 회사가 사용하는 사용자 지정 도메인을 설정하는 첫 단계로 필수적입니다.
- 와일드카드 도메인을 설정하면 각 고객에게 고유한 URL을 제공할 수 있습니다. 예를 들어, *.example.com 형식의 URL을 통해 customer1.example.com과 같은 개별 URL을 생성할 수 있습니다.
- 와일드카드 도메인을 API Gateway 엔드포인트에 연결하여, 모든 고객이 개별 URL을 통해 API Gateway에 접근할 수 있도록 구성할 수 있습니다. 이 단계는 고유한 URL과 API Gateway 통합을 설정하는 데 필수적입니다.

 

D. 동일한 지역의 AWS Certificate Manager(ACM)에서 사용자 지정 도메인 이름과 일치하는 와일드카드 인증서를 요청합니다.

- AWS Certificate Manager(ACM)에서 와일드카드 인증서를 발급받으면, 모든 고객에 대해 개별적인 HTTPS 연결을 설정할 수 있습니다. 와일드카드 인증서는 *.example.com과 같은 도메인을 지원하므로, 고유한 URL을 HTTPS로 보호할 수 있습니다.
- AWS Certificate Manager(ACM) : SSL/TLS 인증서를 간편하게 관리하고 배포할 수 있도록 지원하는 AWS 서비스로 ACM을 사용하면 웹 애플리케이션이나 AWS 리소스에 필요한 SSL/TLS 인증서를 쉽게 요청, 배포, 갱신할 수 있음
- ACM 인증서는 API Gateway와 같은 지역에서 발급되어야 하므로, 이 단계는 필수적입니다.

F. REST API를 위한 API Gateway에서 사용자 지정 도메인 이름을 만듭니다. AWS Certificate Manager(ACM)에서 인증서를 가져옵니다.

- API Gateway에 사용자 지정 도메인 이름을 설정하면, API 엔드포인트에 사용자 지정 URL을 매핑할 수 있습니다. 이를 통해 고객마다 고유한 URL을 제공할 수 있습니다.
- ACM 인증서를 API Gateway에 연결하여 HTTPS 통신을 보장할 수 있습니다. 이는 보안과 운영 효율성을 동시에 충족하는 중요한 단계입니다.


■ Question #533

한 회사가 Amazon S3에 데이터를 저장합니다. 규정에 따르면, 데이터는 개인 식별 정보(PII:Personally Identifiable Information)를 포함해서는 안 됩니다. 이 회사는 최근 S3 버킷에 PII가 포함된 일부 객체가 있다는 사실을 발견했습니다. 이 회사는 S3 버킷에서 PII를 자동으로 감지하고 회사의 보안 팀에 알려야 합니다.

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

A. Amazon Macie를 사용합니다. Macie 결과에서 SensitiveData 이벤트 유형을 필터링하고 Amazon Simple Notification Service (Amazon SNS) 알림을 보안 팀에 보내는 Amazon EventBridge 규칙을 만듭니다.

B. Amazon GuardDuty를 사용합니다. GuardDuty 결과에서 CRITICAL 이벤트 유형을 필터링하고 Amazon Simple Notification Service (Amazon SNS) 알림을 보안 팀에 보내는 Amazon EventBridge 규칙을 만듭니다.

C. Amazon Macie를 사용합니다. Macie 결과에서 SensitiveData:S3Object/Personal 이벤트 유형을 필터링하고 Amazon Simple Queue Service (Amazon SQS) 알림을 보안 팀에 보내는 Amazon EventBridge 규칙을 만듭니다.

D. Amazon GuardDuty를 사용합니다. GuardDuty 결과에서 CRITICAL 이벤트 유형을 필터링하고 Amazon Simple Queue Service (Amazon SQS) 알림을 보안 팀에 보내는 Amazon EventBridge 규칙을 만듭니다.

더보기

A. Amazon Macie를 사용합니다. Macie 결과에서 SensitiveData 이벤트 유형을 필터링하고 Amazon Simple Notification Service(Amazon SNS) 알림을 보안 팀에 보내는 Amazon EventBridge 규칙을 만듭니다.

- Amazon Macie는 S3 버킷에서 PII를 자동으로 감지하는 기능을 제공하는 AWS의 서비스입니다. 특히, 민감한 데이터 탐지를 목적으로 사용되며, 데이터 분석을 통해 PII와 같은 민감한 정보를 탐지할 수 있습니다.
- Macie 결과에서 SensitiveData 이벤트 유형을 필터링하면, S3에 PII가 포함된 객체를 감지할 수 있습니다.
- Amazon SNS는 보안 팀에게 알림을 전송하는 효율적인 방법입니다. SNS를 통해 즉각적인 알림을 전송할 수 있습니다.
- EventBridge 규칙은 자동화된 알림 시스템을 구성하는 데 유용하며, 감지된 PII 이벤트에 따라 보안 팀에게 자동으로 알림을 전송할 수 있습니다.


■ Question #534

한 회사가 여러 AWS 계정에 대한 로깅 솔루션을 구축하려고 합니다. 이 회사는 현재 모든 계정의 로그를 중앙 계정에 저장합니다. 이 회사는 중앙 계정에 Amazon S3 버킷을 만들어 VPC 흐름 로그와 AWS CloudTrail 로그를 저장했습니다. 모든 로그는 빈번한 분석을 위해 30일 동안 고가용성이어야 하고, 백업 목적으로 60일 동안 추가로 보관해야 하며, 생성 후 90일 후에 삭제해야 합니다.

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

A. 생성 후 30일 후에 객체를 S3 Standard 스토리지 클래스로 전환합니다. Amazon S3가 90일 후에 객체를 삭제하도록 지시하는 만료 작업을 작성합니다.
B. 생성 후 30일 후에 S3 Standard-Infrequent Access(S3 Standard-IA) 스토리지 클래스로 객체를 전환합니다. 90일 후에 모든 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 이동합니다. Amazon S3가 90일 후에 객체를 삭제하도록 지시하는 만료 작업을 작성합니다.
C. 생성 후 30일 후에 S3 Glacier Flexible Retrieval 스토리지 클래스로 객체를 전환합니다. Amazon S3가 90일 후에 객체를 삭제하도록 지시하는 만료 작업을 작성합니다.
D. 생성 후 30일이 지나면 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA) 스토리지 클래스로 전환합니다. 90일 후에는 모든 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 이동합니다. Amazon S3가 90일 후에 객체를 삭제하도록 지시하는 만료 작업을 작성합니다.

더보기

C. 생성 후 30일 후에 S3 Glacier Flexible Retrieval 스토리지 클래스로 객체를 전환합니다. Amazon S3가 90일 후에 객체를 삭제하도록 지시하는 만료 작업을 작성합니다.

- S3 Glacier Flexible Retrieval는 장기간의 데이터 보관 및 드물게 접근하는 데이터를 위한 저비용 스토리지 클래스입니다.
- S3 Glacier Flexible Retrieval에 저장된 데이터를 90일 후 삭제하는 것은 백업 목적으로 데이터를 장기 보관하면서, 필요한 기간 이후 데이터를 삭제하는 요구 사항에 부합합니다.
- Glacier에 데이터를 60일 동안 보관하고 나서 데이터를 삭제하는 것은 백업 목적을 달성하면서도 저비용 스토리지를 사용해 데이터를 관리할 수 있는 효율적인 방법입니다.


■ Question #535

한 회사가 워크로드를 위해 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터를 구축하고 있습니다. Amazon EKS에 저장된 모든 비밀은 Kubernetes etcd 키-값 저장소(Kubernetes etcd key-value store)에서 암호화되어야 합니다.

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

A. 새로운 AWS Key Management Service(AWS KMS) 키를 만듭니다. AWS Secrets Manager를 사용하여 Amazon EKS의 모든 비밀을 관리, 순환 및 저장합니다.
B. 새로운 AWS Key Management Service(AWS KMS) 키를 만듭니다. Amazon EKS 클러스터에서 Amazon EKS KMS 비밀 암호화를 활성화합니다.
C. 기본 옵션으로 Amazon EKS 클러스터를 만듭니다. Amazon Elastic Block Store(Amazon EBS) Container Storage Interface(CSI) 드라이버를 애드온으로 사용합니다.
D. 별칭/aws/ebs 별칭으로 새 AWS Key Management Service(AWS KMS) 키를 만듭니다. 계정에 대한 기본 Amazon Elastic Block Store(Amazon EBS) 볼륨 암호화를 활성화합니다.

더보기

B. 새로운 AWS Key Management Service(AWS KMS) 키를 만듭니다. Amazon EKS 클러스터에서 Amazon EKS KMS 비밀 암호화를 활성화합니다.

- Kubernetes etcd 키-값 저장소에서의 비밀 암호화 요구 사항을 직접 충족합니다.
- Amazon EKS KMS 비밀 암호화는 AWS KMS 키를 사용하여 Kubernetes의 etcd 키-값 저장소에서 비밀을 암호화합니다. Kubernetes에서 사용되는 비밀은 etcd에 저장되며, KMS를 통해 암호화할 수 있습니다.
- 이 설정은 Kubernetes 비밀을 안전하게 암호화하는 데 매우 적합합니다.


■ Question #536

한 회사에서는 데이터 과학자에게 회사의 프로덕션 Amazon RDS for PostgreSQL 데이터베이스에 대한 거의 실시간 읽기 전용 액세스를 제공하고자 합니다. 데이터베이스는 현재 Single-AZ 데이터베이스로 구성되어 있습니다. 데이터 과학자는 프로덕션 데이터베이스에 영향을 미치지 않는 복잡한 쿼리를 사용합니다. 회사에는 고가용성 솔루션이 필요합니다.

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

A.데이터 과학자에게 충분한 전력을 제공하기 위해 유지 관리 기간 동안 기존 프로덕션 데이터베이스를 확장합니다.
B. 단일 AZ에서 더 큰 보조 대기 인스턴스가 있는 다중 AZ 인스턴스 배포로 설정을 변경합니다. 데이터 과학자에게 보조 인스턴스에 대한 액세스 권한을 제공합니다.
C. Single-AZ에서 Multi-AZ 인스턴스 배포로 설정을 변경합니다. 데이터 과학자를 위해 두 개의 추가 읽기 복제본을 제공합니다.
D. 단일 AZ에서 두 개의 읽기 가능한 대기 인스턴스가 있는 다중 AZ 클러스터 배포로 설정을 변경합니다. 데이터 과학자에게 읽기 엔드포인트를 제공합니다.

더보기

C. Single-AZ에서 Multi-AZ 인스턴스 배포로 설정을 변경합니다. 데이터 과학자를 위해 두 개의 추가 읽기 복제본을 제공합니다.

프로덕션 데이터베이스에 영향을 미치지 않는 접근
- 데이터 과학자는 복잡한 쿼리를 사용하며, 이러한 쿼리는 프로덕션 데이터베이스 성능에 부정적인 영향을 미칠 수 있습니다. 따라서 읽기 전용 복제본을 활용하는 것이 이상적인 방법입니다.
- 읽기 복제본을 사용하면 데이터 과학자가 복잡한 쿼리를 실행하는 동안 프로덕션 데이터베이스에 직접적인 영향을 미치지 않습니다.

Multi-AZ 배포의 고가용성
- Multi-AZ 배포는 고가용성을 제공합니다. 프로덕션 데이터베이스의 장애가 발생하면 자동으로 대기 인스턴스로 전환되므로, 비즈니스 연속성을 유지할 수 있습니다.
- 다만, Multi-AZ 설정의 대기 인스턴스는 읽기 작업을 허용하지 않기 때문에, 이를 보완하기 위해 읽기 복제본을 사용하는 것이 적합 합니다.

읽기 복제본 제공
- 읽기 복제본은 프로덕션 데이터베이스의 데이터를 복제하면서, 읽기 전용 쿼리에 응답할 수 있습니다. 데이터 과학자는 복제본에 연결하여 실시간 데이터에 가까운 정보를 바탕으로 분석 작업을 수행할 수 있습니다.
- 이 방식은 데이터베이스 성능과 운영 안정성을 유지하면서도, 데이터 과학자의 분석 요구를 충족시킵니다.

비용 효율성
- 읽기 복제본을 사용하는 방식은 읽기 전용 워크로드를 효과적으로 분산시킬 수 있는 비용 효율적인 방법입니다. Multi-AZ 구성을 통해 고가용성을 유지하면서, 읽기 복제본으로 데이터 과학자가 필요한 리소스를 제공할 수 있습니다.


■ Question #537

한 회사가 AWS 클라우드에서 3개의 가용성 영역에서 작동하는 3계층 웹 애플리케이션을 실행합니다. 애플리케이션 아키텍처에는 애플리케이션 로드 밸런서, 사용자 세션 상태를 호스팅하는 Amazon EC2 웹 서버, EC2 인스턴스에서 실행되는 MySQL 데이터베이스가 있습니다. 이 회사는 애플리케이션 트래픽이 갑자기 증가할 것으로 예상합니다. 이 회사는 미래의 애플리케이션 용량 수요를 충족하고 3개의 가용성 영역 모두에서 높은 가용성을 보장하기 위해 확장할 수 있기를 원합니다.

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

A. MySQL 데이터베이스를 Multi-AZ DB 클러스터 배포를 사용하여 Amazon RDS for MySQL로 마이그레이션합니다. 고가용성을 갖춘 Amazon ElastiCache for Redis를 사용하여 세션 데이터를 저장하고 읽기를 캐시합니다. 웹 서버를 세 개의 가용성 영역에 있는 자동 확장 그룹으로 마이그레이션합니다.
B. MySQL 데이터베이스를 Multi-AZ DB 클러스터 배포를 사용하여 Amazon RDS for MySQL로 마이그레이션합니다. 고가용성을 갖춘 Amazon ElastiCache for Memcached를 사용하여 세션 데이터를 저장하고 읽기를 캐시합니다. 웹 서버를 세 개의 가용성 영역에 있는 자동 확장 그룹으로 마이그레이션합니다.
C. MySQL 데이터베이스를 Amazon DynamoDB로 마이그레이션 DynamoDB Accelerator(DAX)를 사용하여 읽기를 캐시합니다. 세션 데이터를 DynamoDB에 저장합니다. 웹 서버를 세 개의 가용성 영역에 있는 자동 확장 그룹으로 마이그레이션합니다.
D. MySQL 데이터베이스를 단일 가용 영역에서 Amazon RDS for MySQL로 마이그레이션합니다. 고가용성을 각춘 Amazon ElastiCache for Redis를 사용하여 세션 데이터를 저장하고 읽기를 캐시합니다. 웹 서버를 세 개의 가용 영역에 있는 자동 확장 그룹으로 마이그레이션합니다.

더보기

A. MySQL 데이터베이스를 Multi-AZ DB 클러스터 배포를 사용하여 Amazon RDS for MySQL로 마이그레이션합니다. 고가용성을 갖춘 Amazon ElastiCache for Redis를 사용하여 세션 데이터를 저장하고 읽기를 캐시합니다. 웹 서버를 세 개의 가용성 영역에 있는 자동 확장 그룹으로 마이그레이션합니다.

MySQL 데이터베이스의 Multi-AZ RDS 배포
- Amazon RDS for MySQL의 Multi-AZ DB 클러스터는 고가용성과 내구성을 제공하여, 데이터베이스가 장애가 발생했을 때 도 자동으로 복구됩니다. 이를 통해 데이터베이스의 가용성을 보장할 수 있습니다.
- Multi-AZ 클러스터는 세 개의 가용성 영역에서 장애 복구가 가능하므로, 트래픽이 증가하거나 문제가 발생해도 안정적인 서비스가 가능합니다.

세션 데이터를 ElastiCache for Redis에 저장
- Amazon ElastiCache for Redis는 세션 상태와 데이터를 메모리 내 캐시로 저장하여 빠른 세션 관리와 낮은 응답 시간을 제공합니다. Redis는 또한 고가용성 클러스터 구성을 지원하므로, 세션 데이터의 안정적인 처리가 가능합니다.
- Redis는 세션 데이터를 효율적으로 캐시하며, 읽기 성능을 최적화해 트래픽 증가에 따른 응답 시간 저하를 방지할 수 있습니다.

웹 서버의 자동 확장
- EC2 웹 서버를 자동 확장 그룹(Auto Scaling Group, ASG)으로 구성하면, 트래픽 증가에 따라 자동으로 서버 인스턴스가 추가되어 필요한 용량을 처리할 수 있습니다. 자동 확장은 3개의 가용성 영역에서 서버 인스턴스를 관리하므로, 가용성과 확장성을 보장할 수 있습니다.
- 자동 확장 그룹은 각 가용성 영역에 고르게 분배되어, 한 영역에 장애가 발생해도 다른 가용성 영역에서 애플리케이션을 계속 실행할 수 있습니다.


■ Question #538

글로벌 비디오 스트리밍 회사가 Amazon CloudFront를 콘텐츠 배포 네트워크(CDN)로 사용합니다. 이 회사는 여러 국가에 걸쳐 단계적으로 콘텐츠를 출시하려고 합니다. 이 회사는 회사가 콘텐츠를 출시하는 국가 외부에 있는 시청자가 콘텐츠를 볼 수 없도록 해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족할까요?

A. 허용 목록을 사용하여 CloudFront의 콘텐츠에 지리적 제한을 추가합니다. 사용자 지정 오류 메시지를 설정합니다.
B. 제한된 콘텐츠에 대한 새 URL을 설정합니다. 서명된 URL과 쿠키를 사용하여 액세스를 승인합니다. 사용자 지정 오류 메시지를 설정합니다.
C. 회사가 배포하는 콘텐츠에 대한 데이터를 암호화합니다. 사용자 지정 오류 메시지를 설정합니다.
D. 제한된 콘텐츠에 대한 새 URL을 만듭니다. 서명된 URL에 대한 시간 제한 액세스 정책을 설정합니다.

더보기

A. 허용 목록을 사용하여 CloudFront의 콘텐츠에 지리적 제한을 추가합니다. 사용자 지정 오류 메시지를 설정합니다.

지리적 제한(Geo-Restriction)
- Amazon CloudFront는 지리적 제한(Geo-Restriction) 기능을 제공하여 특정 국가에서만 콘텐츠에 접근할 수 있도록 제어할 수 있습니다. 즉, 특정 국가의 시청자만 콘텐츠를 볼 수 있고, 회사가 허용하지 않은 국가에 있는 시청자는 콘텐츠에 접근할 수 없습니다.
- 허용 목록을 사용하면 콘텐츠가 제공될 국가들을 지정할 수 있고, 그 외 국가에서는 콘텐츠를 차단할 수 있습니다. 이는 요구 사항인 국가별 콘텐츠 제한을 정확히 충족합니다.

사용자 지정 오류 메시지
- 지리적 제한에 걸린 사용자가 콘텐츠에 접근하려고 할 때 사용자 지정 오류 메시지를 설정할 수 있습니다. 이를 통해 사용자에게 콘텐츠를 제공할 수 없는 이유를 명확하게 전달할 수 있습니다.


■ Question #539

한 회사가 AWS 클라우드를 사용하여 온프레미스 재해 복구(DR) 구성을 개선하고자 합니다. 회사의 핵심 프로덕션 비즈니스 애플리케이션은 가상 머신(VM)에서 실행되는 Microsoft SQL Server Standard를 사용합니다. 이 애플리케이션은 30초 이하의 복구 지점 목표(RPO)와 60분의 복구 시간 목표(RTO)를 갖습니다. DR 솔루션은 가능한 한 비용을 최소화해야 합니다.

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

A. Always On 가용성 그룹이 있는 Microsoft SQL Server Enterprise를 사용하여 온프레미스 서버와 AWS 간에 다중 사이트 액티브/액티브 설정을 구성합니다.
B. AWS에서 SQL Server 데이터베이스용 웜 스탠바이 Amazon RDS를 구성합니다. AWS Database Migration Service (AWS DMS)를 구성하여 변경 데이터 캡처(CDC)를 사용합니다.
C. AWS Elastic Disaster Recovery를 사용하여 파일럿 라이트로 디스크 변경 사항을 AWS에 복제하도록 구성합니다.
D. 타사 백업 소프트웨어를 사용하여 매일 밤 백업을 캡처합니다. Amazon S3에 보조 백업 세트를 저장합니다.

더보기

C. AWS Elastic Disaster Recovery를 사용하여 파일럿 라이트로 디스크 변경 사항을 AWS에 복제하도록 구성합니다.

RPO(Recovery Point Objective)와 RTO(Recovery Time Objective) 충족
- 복구 지점 목표(RPO)가 30초 이하이며, 복구 시간 목표(RTO)가 60분인 경우, AWS Elastic Disaster Recovery(DRS)는 파일럿 라이트(Pilot Light) 방식으로 최소한의 리소스를 유지하고 디스크 변경 사항을 AWS에 실시간으로 복제하여 빠른 복구를 지원할 수 있습니다. 이를 통해 최소한의 데이터 손실로 복구할 수 있으며, RTO와 RPO 요구 사항을 충족할 수 있습니다.
- DRS는 복제된 데이터를 빠르게 시작하여 60분 이내에 시스템을 복구할 수 있습니다.

 

- AWS Elastic Disaster Recovery(DRS) : AWS 클라우드에서 비즈니스 연속성과 재해 복구(Disaster Recovery)를 지원하는 관리형 서비스

비용 효율성
- 파일럿 라이트 방식은 AWS에서 최소한의 리소스만 유지하며, 필요한 경우에만 추가 자원을 활성화하는 방식이므로 비용을 절감할 수 있습니다. DR 리소스가 항상 활성화된 상태가 아니므로 비용을 크게 줄일 수 있습니다.

- AWS Elastic Disaster Recovery는 온프레미스 워크로드를 AWS로 복제하는 데 최적화되어 있으며, 비용 효율적인 DR 솔루션을 제공합니다.


■ Question #540

한 회사에 고객 정보를 처리하고 저장하기 위해 Oracle 데이터베이스를 사용하는 온프레미스 서버가 있습니다. 이 회사는 AWS 데이터베이스 서비스를 사용하여 더 높은 가용성을 달성하고 애플리케이션 성능을 개선하고자 합니다. 또한 이 회사는 기본 데이터베이스 시스템에서 보고를 오프로드하고자 합니다.

어떤 솔루션이 가장 운영적으로 효율적인 방식으로 이러한 요구 사항을 충족할까요?

A. AWS Database Migration Service(AWS DMS)를 사용하여 여러 AWS 리전에서 Amazon RDS DB 인스턴스를 만듭니다. 보고 기능을 기본 DB 인스턴스와 별도의 DB 인스턴스로 지정합니다.
B. Single-AZ 배포에서 Amazon RDS를 사용하여 Oracle 데이터베이스를 만듭니다. 기본 DB 인스턴스와 동일한 영역에 읽기 복제본을 만듭니다. 보고 기능을 읽기 복제본으로 보냅니다.
C. Multi-AZ 클러스터 배포에 배포된 Amazon RDS를 사용하여 Oracle 데이터베이스를 만듭니다. 보고 기능에 클러스터 배포에서 리더 인스턴스를 사용하도록 지시합니다.
D. Multi-AZ 인스턴스 배포에 배포된 Amazon RDS를 사용하여 Amazon Aurora 데이터베이스를 만듭니다. 보고 기능을 리더 인스턴스로 보냅니다.

더보기

C. Multi-AZ 클러스터 배포에 배포된 Amazon RDS를 사용하여 Oracle 데이터베이스를 만듭니다. 보고 기능에 클러스터 배포에서 리더 인스턴스를 사용하도록 지시합니다.

고가용성
- Multi-AZ 배포는 고가용성을 보장하며, 가용성 영역 중 하나에서 문제가 발생할 경우 자동으로 다른 영역으로 전환되어 다운타임을 최소화할 수 있습니다. 이로 인해 고객 정보 처리와 저장에 있어 데이터베이스의 신뢰성을 유지할 수 있습니다.
- Multi-AZ 클러스터에서는 리더 인스턴스와 리더 노드가 제공되어 읽기 작업을 분산할 수 있습니다. 이를 통해 보고 작업을 오프로드하여 애플리케이션 성능을 향상시킬 수 있습니다.

리더 인스턴스를 통한 보고 오프로드
- 리더 인스턴스는 데이터베이스의 읽기 전용 작업을 처리하는 데 사용되며, 보고 기능과 같은 읽기 중심 작업을 처리하는 데 적합합니다. 이를 통해 기본 데이터베이스에 대한 부담을 줄이고 성능을 최적화할 수 있습니다.
- 기본 데이터베이스는 쓰기와 트랜잭션 처리에 집중하고, 리더 인스턴스는 읽기 작업과 보고를 처리함으로써 애플리케이션 성능이 크게 향상됩니다.

운영 효율성
- Amazon RDS는 관리형 데이터베이스 서비스로, 백업, 패치, 모니터링 등 데이터베이스 관리를 자동화합니다. 이를 통해 운영 오버헤드가 최소화되며, 데이터베이스 관리에 필요한 인력을 줄일 수 있습니다.
- 또한, Multi-AZ 클러스터는 복구 시간이 짧고, 유지보수가 용이해 운영적으로 효율적입니다.

 

반응형

'let's study > AWS SAA-C03' 카테고리의 다른 글

AWS SAA-C03 Examtopics (561 ~ 580)  (2) 2024.12.21
AWS SAA-C03 Examtopics (541 ~ 560)  (2) 2024.12.20
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

관련글 더보기