SAA - C03 Examtopics Dump (#31 - 40)

2025.01.16 - [분류 전체보기] - SAA - C03 Examtopics Dump (#26 - 30)

SAA - C03 Examtopics Dump (#26 - 30)

2025.01.15 - [클라우드] - SAA - C03 Examtopics Dump (#21 - 25)

SAA - C03 Examtopics Dump (#21 - 25)

 

문제풀이

#31번

AWS에서 웹 애플리케이션을 호스팅하는 회사는 모든 Amazon EC2 인스턴스, Amazon RDS DB 인스턴스, Amazon Redshift 클러스터가 태그로 구성되도록 보장하려고 합니다. 회사는 이 검사를 구성하고 운영하는 노력을 최소화하고자 합니다. 이를 달성하려면 솔루션 아키텍트가 무엇을 해야 합니까?

A. AWS Config 규칙을 사용하여 올바르게 태그가 지정되지 않은 리소스를 정의하고 감지합니다.
B. 비용 탐색기를 사용하여 태그가 제대로 지정되지 않은 리소스를 표시합니다. 해당 리소스에 수동으로 태그를 지정하세요.
C. 적절한 태그 할당을 위해 모든 리소스를 확인하는 API 호출을 작성합니다. EC2 인스턴스에서 코드를 주기적으로 실행합니다.
D. 적절한 태그 할당을 위해 모든 리소스를 확인하는 API 호출을 작성합니다. Amazon CloudWatch를 통해 AWS Lambda 함수를 예약하여 코드를 주기적으로 실행합니다.

정답 : A

 

이유:

• AWS Config는 AWS 리소스의 구성 변경 사항을 모니터링하고, 설정된 규칙에 따라 리소스의 상태를 평가할 수 있는 서비스입니다. AWS Config 규칙을 사용하면 태그가 올바르게 지정되지 않은 리소스를 자동으로 감지하고 보고할 수 있으므로, 운영 노력을 최소화할 수 있습니다. 이 방법은 태그 정책을 엄격하게 관리하고 준수하도록 도와줍니다.

정답이 아닌 옵션들:

B. 비용 탐색기를 사용하여 태그가 제대로 지정되지 않은 리소스를 표시합니다. 해당 리소스에 수동으로 태그를 지정하세요.

• 비용 탐색기는 태그를 기반으로 비용을 분석하는 도구이지만, 태그가 없거나 잘못된 리소스를 감지하는 데 있어서 자동화된 솔루션이 아니므로 운영 노력을 최소화하는 데 적합하지 않습니다.

C. 적절한 태그 할당을 위해 모든 리소스를 확인하는 API 호출을 작성합니다. EC2 인스턴스에서 코드를 주기적으로 실행합니다.

• API 호출을 사용하여 리소스를 확인하는 방법은 수동으로 관리해야 하며, EC2 인스턴스에서 코드가 실행되어야 하므로 관리 및 운영 노력이 증가하게 됩니다.

D. 적절한 태그 할당을 위해 모든 리소스를 확인하는 API 호출을 작성합니다. Amazon CloudWatch를 통해 AWS Lambda 함수를 예약하여 코드를 주기적으로 실행합니다.

• Lambda와 CloudWatch를 사용하여 태그를 확인하고 자동으로 잘못된 태그를 식별할 수 있지만, 이 방법은 여전히 사용자가 코드를 작성해야 하고, 단순히 태그를 감지하는 측면에서는 AWS Config에 비해 더 복잡한 솔루션입니다.

따라서, 태그 관리와 관련하여 최소한의 운영 노력을 유지하면서 가장 효과적인 해결책은 A입니다.

 

 

#32번

개발팀은 다른 팀이 액세스할 수 있는 웹사이트를 호스팅해야 합니다. 웹사이트 콘텐츠는 HTML, CSS, 클라이언트 측 JavaScript, 이미지로 구성됩니다.웹사이트 호스팅에 가장 비용 효과적인 방법은 무엇입니까?

A. 웹 사이트를 컨테이너화하고 AWS Fargate에서 호스팅합니다.
B. Amazon S3 버킷을 생성하고 거기에서 웹사이트를 호스팅합니다.
C. Amazon EC2 인스턴스에 웹 서버를 배포하여 웹 사이트를 호스팅합니다.
D. Application Load Balancer를 구성하고 Express.js 프레임워크를 사용하는 AWS Lambda 대상을 설정합니다.

정답 : B

 

이유:

• Amazon S3는 정적 웹사이트 호스팅을 지원하며, HTML, CSS, 클라이언트 측 JavaScript, 이미지와 같은 정적 콘텐츠를 저장하고 제공하는 데 매우 적합합니다. S3는 낮은 비용으로 데이터 저장과 웹사이트 호스팅이 가능하며, 복잡한 서버 설정이 필요하지 않기 때문에 관리가 간편합니다. 정적 웹사이트를 호스팅하는 데 있어 가장 비용 효과적이고 효율적인 방법입니다.

정답이 아닌 옵션들:

A. 웹 사이트를 컨테이너화하고 AWS Fargate에서 호스팅합니다.

• AWS Fargate는 컨테이너를 실행하기 위한 관리형 서비스입니다. 그러나 컨테이너링은 정적 웹사이트 호스팅에는 과도한 솔루션이며, 비용이 비쌀 수 있습니다. 정적 웹사이트에는 S3가 더 적합합니다.

C. Amazon EC2 인스턴스에 웹 서버를 배포하여 웹 사이트를 호스팅합니다.

• EC2 인스턴스는 유연성과 제어를 제공하지만, 서버 비용 및 운영에 대한 추가 관리 부담이 있습니다. 정적 콘텐츠를 위해 EC2를 사용하는 것은 비용 효율적이지 않습니다.

D. Application Load Balancer를 구성하고 Express.js 프레임워크를 사용하는 AWS Lambda 대상을 설정합니다.

• Lambda와 Application Load Balancer를 사용하여 웹사이트를 호스팅할 수 있지만, 이는 서버리스 아키텍처에 대한 복잡한 설정이 필요하며, 정적 웹사이트에 대해서는 불필요한 비용과 복잡성을 초래합니다.

결론적으로, 정적 웹사이트를 호스팅하는 가장 비용 효율적인 방법은 B입니다.

 

 

#33번
한 회사가 AWS에서 온라인 마켓플레이스 웹 애플리케이션을 실행하고 있습니다. 이 애플리케이션은 피크 시간 동안 수십만 명의 사용자에게 서비스를 제공합니다. 회사에는 수백만 건의 금융 거래 세부 정보를 여러 다른 내부 애플리케이션과 공유하기 위해 확장 가능하고 실시간에 가까운 솔루션이 필요합니다. 또한 짧은 지연 시간의 검색을 위해 문서 데이터베이스에 저장되기 전에 민감한 데이터를 제거하기 위해 트랜잭션을 처리해야 합니다.
솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?

A. 거래 데이터를 Amazon DynamoDB에 저장합니다. 쓰기 시 모든 트랜잭션에서 중요한 데이터를 제거하도록 DynamoDB에서 규칙을 설정합니다. DynamoDB 스트림을 사용하여 다른 애플리케이션과 트랜잭션 데이터를 공유합니다.

B. 트랜잭션 데이터를 Amazon Kinesis Data Firehose로 스트리밍하여 Amazon DynamoDB 및 Amazon S3에 데이터를 저장합니다.Kinesis Data Firehose와 AWS Lambda 통합을 사용하여 민감한 데이터를 제거하십시오. 다른 애플리케이션은 Amazon S3에 저장된 데이터를 사용할 수 있습니다.

C. 트랜잭션 데이터를 Amazon Kinesis Data Streams로 스트리밍합니다. AWS Lambda 통합을 사용하여 모든 트랜잭션에서 민감한 데이터를 제거한 다음 Amazon DynamoDB에 트랜잭션 데이터를 저장합니다. 다른 애플리케이션은 Kinesis 데이터 스트림에서 트랜잭션 데이터를 사용할 수 있습니다.

D. 일괄 처리된 트랜잭션 데이터를 Amazon S3에 파일로 저장합니다. Amazon S3에서 파일을 업데이트하기 전에 AWS Lambda를 사용하여 모든 파일을 처리하고 민감한 데이터를 제거하십시오. 그런 다음 Lambda 함수는 Amazon DynamoDB에 데이터를 저장합니다. 다른 애플리케이션은 Amazon S3에 저장된 트랜잭션 파일을 사용할 수 있습니다.

정답 : C

 

이유:

• Kinesis Data Streams는 실시간 데이터 스트리밍을 처리하기 적합하며, 대규모 사용자 요청에 대해 확장 가능합니다. AWS Lambda와 통합하여 각 트랜잭션 데이터를 처리하면서 민감한 데이터를 제거할 수 있습니다. 처리된 데이터를 Amazon DynamoDB에 저장함으로써 짧은 지연 시간 검색을 달성할 수 있고, 다른 애플리케이션은 Kinesis 데이터 스트림을 통해 트랜잭션 데이터를 실시간으로 사용할 수 있습니다.

정답이 아닌 옵션들:

A. 거래 데이터를 Amazon DynamoDB에 저장합니다. 쓰기 시 모든 트랜잭션에서 중요한 데이터를 제거하도록 DynamoDB에서 규칙을 설정합니다. DynamoDB 스트림을 사용하여 다른 애플리케이션과 트랜잭션 데이터를 공유합니다.

• DynamoDB에서 중요한 데이터를 제거하는 기능이 없음과 동시에, 스트리밍 혹은 실시간 처리에 적합하지 않습니다. DynamoDB 자체는 실시간 트랜잭션 처리 및 민감한 데이터 제거에 적합하지 않습니다.

B. 트랜잭션 데이터를 Amazon Kinesis Data Firehose로 스트리밍하여 Amazon DynamoDB 및 Amazon S3에 데이터를 저장합니다. Kinesis Data Firehose와 AWS Lambda 통합을 사용하여 민감한 데이터를 제거하십시오. 다른 애플리케이션은 Amazon S3에 저장된 데이터를 사용할 수 있습니다.

• Kinesis Data Firehose는 배치 처리를 더 잘 지원하며, 실시간 처리가 아닌 경우에 적합합니다. 이 경우 요구 사항에 맞추기 어렵습니다.

D. 일괄 처리된 트랜잭션 데이터를 Amazon S3에 파일로 저장합니다. Amazon S3에서 파일을 업데이트하기 전에 AWS Lambda를 사용하여 모든 파일을 처리하고 민감한 데이터를 제거하십시오. 그런 다음 Lambda 함수는 Amazon DynamoDB에 데이터를 저장합니다. 다른 애플리케이션은 Amazon S3에 저장된 트랜잭션 파일을 사용할 수 있습니다.

• 이 방법은 일괄 처리 방식이므로 실시간 상태를 필요로 하는 요구사항에 적합하지 않으며, 데이터가 즉시 사용 가능해야 하므로 불리합니다.

결론적으로, 요구 사항을 가장 잘 충족하는 솔루션은 C입니다.

 

 

#34번

한 회사가 AWS에서 다중 계층 애플리케이션을 호스팅합니다. 규정 준수, 거버넌스, 감사 및 보안을 위해 회사는 AWS 리소스의 구성 변경 사항을 추적하고 이러한 리소스에 대한 API 호출 기록을 기록해야 합니다.솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?
A. AWS CloudTrail을 사용하여 구성 변경 사항을 추적하고 AWS Config를 사용하여 API 호출을 기록하십시오.
B. AWS Config를 사용하여 구성 변경 사항을 추적하고 AWS CloudTrail을 사용하여 API 호출을 기록하십시오.
C. AWS Config를 사용하여 구성 변경 사항을 추적하고 Amazon CloudWatch를 사용하여 API 호출을 기록합니다.
D. AWS CloudTrail을 사용하여 구성 변경 사항을 추적하고 Amazon CloudWatch를 사용하여 API 호출을 기록합니다.

정답 : B

 

이유:

• AWS Config는 AWS 리소스의 구성 변경 사항을 추적하고, 규정 준수 및 거버넌스를 지원하는 데 적합합니다. AWS CloudTrail은 AWS API 호출 기록을 저장하여 보안 및 감사 목적에 필요한 모든 API 요청을 추적합니다. 따라서 이 두 서비스를 함께 사용하면 구성 변경 사항 추적 및 API 호출 기록 요구 사항을 모두 충족할 수 있습니다.

정답이 아닌 옵션들:

A. AWS CloudTrail을 사용하여 구성 변경 사항을 추적하고 AWS Config를 사용하여 API 호출을 기록하십시오.

• 이 옵션은 AWS Config와 CloudTrail의 역할이 잘못 배분되어 있습니다. AWS Config가 구성 변경을 추적하고 CloudTrail이 API 호출을 기록해야 올바릅니다.

C. AWS Config를 사용하여 구성 변경 사항을 추적하고 Amazon CloudWatch를 사용하여 API 호출을 기록합니다.

• Amazon CloudWatch는 통계 및 로그 모니터링을 위한 서비스이며, API 호출을 기록하는 기능은 제공하지 않습니다. CloudTrail이 필요한 역할을 수행하기에 적합합니다.

D. AWS CloudTrail을 사용하여 구성 변경 사항을 추적하고 Amazon CloudWatch를 사용하여 API 호출을 기록합니다.

• 이 옵션 또한 잘못된 역할 배분입니다. CloudTrail은 API 호출을 기록해야 하며, 구성 변경 사항은 AWS Config에서 관리해야 합니다.

결론적으로, 요구 사항을 가장 잘 충족하는 솔루션은 B입니다.

 

 

#35번

한 회사가 AWS 클라우드에서 공개 웹 애플리케이션 출시를 준비하고 있습니다. 아키텍처는 Elastic Load Balancer(ELB) 뒤의 VPC 내의 Amazon EC2 인스턴스로 구성됩니다. DNS에는 타사 서비스가 사용됩니다. 회사의 솔루션 설계자는 대규모 DDoS 공격을 탐지하고 방어할 수 있는 솔루션을 권장해야 합니다.이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. Enable Amazon GuardDuty on the account.
B. EC2 인스턴스에서 Amazon Inspector를 활성화합니다.
C. AWS Shield를 활성화하고 Amazon Route 53을 할당합니다.
D. AWS Shield Advanced를 활성화하고 여기에 ELB를 할당합니다.

정답 : D

 

이유:

• AWS Shield Advanced는 DDoS 공격으로부터 AWS 리소스를 보호하기 위한 서비스로, 자동으로 DDoS 공격을 탐지하고 방어하는 기능을 제공합니다. ELB와 함께 사용할 수 있어 대규모 트래픽을 관리하면서 애플리케이션의 가용성을 높일 수 있습니다. 또한, Shield Advanced는 진단, 방어 및 공격에 대한 실시간 대응을 제공합니다.

정답이 아닌 옵션들:

A. Enable Amazon GuardDuty on the account.

• Amazon GuardDuty는 보안 탐지 서비스로, 악성 활동을 모니터링하지만 DDoS 공격을 방어하는 기능은 없습니다. GuardDuty는 주로 내부 위협 및 비정상적인 행동을 식별하는 데 도움을 줍니다.

B. EC2 인스턴스에서 Amazon Inspector를 활성화합니다.

• Amazon Inspector는 보안 취약점을 찾아내는 서비스를 제공하지만, DDoS 공격을 탐지하거나 방어하는 기능은 없습니다.

C. AWS Shield를 활성화하고 Amazon Route 53을 할당합니다.

• AWS Shield는 기본 수준(DDoS 공격 방어 기능)을 제공하지만, 강력한 DDoS 방어를 위해서는 Shield Advanced가 필요합니다. 또한 Route 53은 DNS 관리 서비스로, DDoS 방어와 직접적으로 관련이 없습니다.

결론적으로, DDoS 공격 탐지와 방어를 위해 가장 적합한 솔루션은 D입니다.

 

#36번

한 회사가 AWS 클라우드에 애플리케이션을 구축하고 있습니다. 애플리케이션은 두 AWS 지역의 Amazon S3 버킷에 데이터를 저장합니다. 회사는 AWS Key Management Service(AWS KMS) 고객 관리형 키를 사용하여 S3 버킷에 저장된 모든 데이터를 암호화해야 합니다. 두 S3 버킷의 데이터는 동일한 KMS 키를 사용하여 암호화 및 해독되어야 하며, 데이터와 키는 두 리전에 각각 저장되어야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. 각 리년에 S3 버킷을 생성합니다. Amazon S3 관리형 암호화 키(SSE-S3)와 함께 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.
B. 고객 관리형 다중 리전 KMS 키를 생성합니다. 각 리전에 S3 버킷을 생성합니다. S3 버킷 간의 복제를 구성합니다. 클라이언트 측 암호화와 함께 KMS 키를 사용하도록 애플리케이션을 구성합니다.
C. 각 리전에 고객 관리형 KMS 키와 S3 버킷을 생성합니다. Amazon S3 관리형 암호화 키(SSE-S3)와 함께 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.
D. 각 리전에 고객 관리형 KMS 키와 S3 버킷을 생성합니다. AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.

정답 : D

 

이유:

• AWS KMS(SSE-KMS)로 서버 측 암호화를 사용하여 S3에 저장된 데이터를 암호화하며, 고객 관리형 KMS 키를 생성함으로써 키 관리 및 갖는 통제권도 유지할 수 있습니다. 또한, 각 리전에서 동일한 KMS 키를 사용하여 데이터를 암호화 및 해독할 수 있도록 지원하므로, 모든 요구 사항을 충족합니다.

정답이 아닌 옵션들:

A. 각 리전에 S3 버킷을 생성합니다. Amazon S3 관리형 암호화 키(SSE-S3)와 함께 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.

• SSE-S3는 AWS가 관리하는 키를 사용하므로 고객 관리형 키 요구 사항을 충족하지 않습니다.

B. 고객 관리형 다중 리전 KMS 키를 생성합니다. 각 리전에 S3 버킷을 생성합니다. S3 버킷 간의 복제를 구성합니다. 클라이언트 측 암호화와 함께 KMS 키를 사용하도록 애플리케이션을 구성합니다.

• 클라이언트 측 암호화는 최소한의 운영 오버헤드를 요구하지 않으며, 두 S3 버킷 간에 동일한 KMS 키를 사용하여 암호화 및 해독을 보장하기 어렵습니다.

C. 각 리전에 고객 관리형 KMS 키와 S3 버킷을 생성합니다. Amazon S3 관리형 암호화 키(SSE-S3)와 함께 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷 간의 복제를 구성합니다.

• 다시 말하지만, SSE-S3는 고객 관리형 키가 아니므로 요구 사항을 충족하지 않습니다.

따라서, 요구 사항을 가장 잘 충족하는 솔루션은 D입니다.

 

 

#37번

최근 한 회사가 AWS 계정에서 다양한 새로운 작업을 Amazon EC2 인스턴스에서 시작했습니다. 회사는 인스턴스에 원격으로 안전하게 접근하고 관리하는 전략을 수립해야 합니다. 회사는 기본 AWS 서비스와 함께 작동하고 AWS Well-Architected Framework를 따르는 반복 가능한 프로세스를 구현해야 합니다. 운영 오버헤드가 가장 적은 솔루션은 무엇입니까?

A. EC2 Serial Console을 사용하여 각 인스턴스의 터미널 인터페이스에 직접 액세스합니다.
EC2 Serial Console은 대부분의 문제를 해결하는 데 유용하지만, 모든 인스턴스에 대한 지속적이고 안전한 접근을 제공하지는 않습니다. 따라서 이 옵션은 반복적이고 자동화된 접근 방법으로는 적합하지 않습니다.

B. 각 기존 인스턴스와 새 인스턴스에 적절한 IAM 역할을 연결하고 AWS Systems Manager Session Manager를 사용하여 원격 SSH 세션을 설정합니다.
AWS Systems Manager의 Session Manager를 사용하면 SSH 키나 인스턴스에 직접 접근하지 않고도 안전하게 EC2 인스턴스를 관리할 수 있습니다. IAM 역할을 통해 인스턴스를 관리하며, 이는 안전하고 반복 가능한 방식으로, AWS Well-Architected Framework와 잘 맞습니다. 이 옵션은 최소한의 운영 오버헤드를 제공합니다.

C. 관리 SSH 키 쌍을 생성하여 공개 키를 각 EC2 인스턴스에 로드하고 퍼블릭 서브넷에 배스천 호스트를 배포합니다.
이 방법은 관리하기 복잡하고 추가적인 보안 리스크가 있습니다. SSH 키 관리는 여러 인스턴스의 경우 오버헤드가 클 수 있습니다. 또한, 배스천 호스트의 유지 관리가 필요하게 되어, 운영 오버헤드가 증가합니다.

D. AWS Site-to-Site VPN 연결을 설정합니다. VPN 터널을 통해 SSH 키를 사용하여 로컬 온프레미스 머신을 사용하여 인스턴스에 직접 연결합니다.
Site-to-Site VPN은 복잡성을 추가하고 운영 비용이 증가하며, 온프레미스 머신에서 직접 연결하는 방식은 모든 인스턴스에 대한 접근성을 제한할 수 있습니다. 이는 관리 및 보안 측면에서 비효율적일 수 있습니다.

최종 결론:
따라서, 최소한의 운영 오버헤드와 더불어 AWS Well-Architected Framework를 따르며, 안전하고 반복 가능한 인스턴스 관리 방법을 제공하는 B가 가장 적합한 솔루션입니다.

정답 : B

 

 

 

#38번

한 회사가 Amazon S3에서 정적 웹 사이트를 호스팅하고 있으며 DNS에 Amazon Route 53을 사용하고 있습니다. 이 웹사이트는 전 세계적으로 수요가 증가하고 있습니다. 회사는 웹사이트에 접속하는 사용자의 지연 시간을 줄여야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?
선택지:
A. 웹 사이트가 포함된 S3 버킷을 모든 AWS 리전에 복제하고 Route 53 지리적 위치 라우팅 항목을 추가합니다.
B. AWS Global Accelerator에서 액셀러레이터를 프로비저닝하고 제공된 IP 주소를 S3 버킷과 연결합니다. 액셀러레이터의 IP 주소를 가리키도록 Route 53 항목을 편집합니다.
C. S3 버킷 앞에 Amazon CloudFront 배포를 추가하고 Route 53 항목을 CloudFront 배포를 가리키도록 편집합니다.
D. 버킷에서 S3 Transfer Acceleration을 활성화하고 Route 53 항목을 새 엔드포인트를 가리키도록 편집합니다.

정답:

C. S3 버킷 앞에 Amazon CloudFront 배포를 추가하고 Route 53 항목을 CloudFront 배포를 가리키도록 편집합니다.

정답이 아닌 이유:

A. 웹 사이트가 포함된 S3 버킷을 모든 AWS 리전에 복제하고 Route 53 지리적 위치 라우팅 항목을 추가합니다.

• 여러 리전에 S3 버킷을 복제하면 관리의 복잡성이 증가하고, 여러 리전에서 데이터 저장에 따른 추가 비용이 발생합니다. 또한, 지리적 위치 라우팅은 위치에 기반한 요청을 처리하지만 CloudFront보다 성능 개선 효과가 낮습니다.

B. AWS Global Accelerator에서 액셀러레이터를 프로비저닝하고 제공된 IP 주소를 S3 버킷과 연결합니다. 액셀러레이터의 IP 주소를 가리키도록 Route 53 항목을 편집합니다.

• Global Accelerator는 지연 시간을 줄이는 데 도움이 되지만, 비용이 비쌉니다. S3 버킷에 직접 연결하는 방식은 비용 효율적이지 않습니다.

D. 버킷에서 S3 Transfer Acceleration을 활성화하고 Route 53 항목을 새 엔드포인트를 가리키도록 편집합니다.

• S3 Transfer Acceleration은 파일 업로드 성능을 개선할 수 있지만, 웹사이트의 정적 콘텐츠 제공과 관련해서는 지연 시간 단축에 제한적입니다.

 

#39번

회사는 웹사이트에서 검색 가능한 항목 저장소를 유지 관리합니다. 데이터는 천만 개가 넘는 행이 포함된 MySQL용 Amazon RDS 데이터베이스 테이블에 저장됩니다. 데이터베이스에는 2TB의 범용 SSD 스토리지가 있습니다. 회사 웹사이트를 통해 매일 이 데이터에 대한 수백만 개의 업데이트가 있습니다. 회사에서는 일부 삽입 작업이 10초 이상 걸리는 것을 확인했습니다. 회사에서는 데이터베이스 스토리지 성능이 문제라고 판단했습니다.이 성능 문제를 해결하는 솔루션은 무엇입니까?

A. 스토리지 유형을 프로비저닝된 IOPS SSD로 변경합니다.
B. DB 인스턴스를 메모리 최적화 인스턴스 클래스로 변경합니다.
C. DB 인스턴스를 성능 확장이 가능한 인스턴스 클래스로 변경합니다.
D. Multi-AZ RDS 읽기 복제본을 활성화하고 MySQL 기본 비동기 복제를 사용합니다.

정답 : B

 

 

A. 스토리지 유형을 프로비저닝된 IOPS SSD로 변경합니다.

• 프로비저닝된 IOPS SSD는 I/O 성능을 향상시킬 수 있지만, 이 경우 특정 삽입 작업의 문제는 메모리 사용량과 관련이 있을 수 있습니다. 삽입 작업이 많을 때 메모리 최적화 인스턴스가 도움이 될 수 있습니다.

C. DB 인스턴스를 성능 확장이 가능한 인스턴스 클래스로 변경합니다.

• 성능 확장이 가능한 인스턴스 클래스로의 변경은 유연성을 제공하지만, 메모리 최적화를 통해 직접적으로 성능을 향상시키는 것이 더 효과적일 수 있습니다.

D. Multi-AZ RDS 읽기 복제본을 활성화하고 MySQL 기본 비동기 복제를 사용합니다.

• Multi-AZ 설정은 가용성을 높이고 장애 조치 기능을 제공하지만, 삽입 성능을 개선하는 데는 도움이 되지 않습니다. 주로 읽기 성능 개선에 집중됩니다.

 

#40번

한 회사에는 매일 1TB의 상태 경고를 집합적으로 생성하는 수천 개의 엣지 장치가 있습니다. 각 경고의 크기는 약 2KB입니다. 솔루션설계자는 향후 분석을 위해 경고를 수집하고 저장하는 솔루션을 구현해야 합니다. 회사는 가용성이 높은 솔루션을 원합니다. 그러나 회사는 비용을 최소화해야 하며 추가 인프라를 관리하고 싶지 않습니다. 또한 회사는 즉각적인 분석을 위해 14일 동안의 데이터를 보관하고 14일보다 오래된 모든 데이터를 보관하기를 원합니다. 이러한 요구 사항을 충족하는 가장 운영 효율적인 솔루션은 무엇입니까?

A. Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon S3 버킷에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.

B. 두 개의 가용 영역에서 Amazon EC2 인스턴스를 시작하고 Elastic Load Balancer 뒤에 배치하여 알림을 수집합니다. Amazon S3 버킷에 알림을 저장할 EC2 인스턴스에 대한 스크립트를 생성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.

C. Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 매일 수동 스냅샷을 생성하고 14일이 지난 클러스터의 데이터를 삭제하도록 Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터를 설정합니다.

D. Amazon Simple Queue Service(Amazon SQS) 표준 대기열을 생성하여 알림을 수집하고 메시지 보존 기간을 14일로 설정합니다.SQS 대기열을 폴링하고, 메시지 기간을 확인하고, 필요에 따라 메시지 데이터를 분석하도록 소비자를 구성합니다. 메시지가 14일된 경우 소비자는 메시지를 Amazon S3 버킷에 복사하고 SQS 대기열에서 메시지를 삭제해야 합니다.

정답 : A

정답이 아닌 이유:

B. 두 개의 가용 영역에서 Amazon EC2 인스턴스를 시작하고 Elastic Load Balancer 뒤에 배치하여 알림을 수집합니다. Amazon S3 버킷에 알림을 저장할 EC2 인스턴스에 대한 스크립트를 생성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.

• 이 솔루션은 EC2 인스턴스 관리가 필요하며, 이는 운영 오버헤드를 증가시키고 비용을 높입니다. 또한, 가용성 확보를 위해 EC2 인스턴스를 이중화하면 추가 리소스 관리가 필요하게 됩니다.

C. Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 매일 수동 스냅샷을 생성하고 14일이 지난 클러스터의 데이터를 삭제하도록 Amazon OpenSearch Service(Amazon Elasticsearch Service) 클러스터를 설정합니다.

• OpenSearch Service는 분석을 위한 좋은 옵션이지만, 클러스터 관리와 수동 스냅샷 생성은 운영 오버헤드를 증가시킬 수 있습니다. 또한 저장 비용이 S3보다 더 높을 수 있습니다.

D. Amazon Simple Queue Service(Amazon SQS) 표준 대기열을 생성하여 알림을 수집하고 메시지 보존 기간을 14일로 설정합니다. SQS 대기열을 폴링하고, 메시지 기간을 확인하고, 필요에 따라 메시지 데이터를 분석하도록 소비자를 구성합니다. 메시지가 14일이 된 경우 소비자는 메시지를 Amazon S3 버킷에 복사하고 SQS 대기열에서 메시지를 삭제해야 합니다.

• SQS를 사용하는 방법은 운영 오버헤드가 커지고, 별도의 소비자 애플리케이션 관리가 필요합니다. 직접적인 데이터를 S3로 전송하며 수명 주기 관리를 통한 저장 관리가 효율적이지 않을 수 있습니다.