AWS SAA-C03 Examtopics (661 ~ 680)

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

 

■ Question #661

한 회사가 회사의 Amazon RDS 데이터베이스에 연결되는 AWS에서 애플리케이션을 실행합니다. 애플리케이션은 주말과 연중 피크 타임에 확장됩니다. 회사는 데이터베이스에 연결되는 애플리케이션에 대해 데이터베이스를 보다 효과적으로 확장하려고 합니다.

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

A. 데이터베이스에 대한 대상 그룹 구성과 함께 연결 풀링이 있는 Amazon DynamoDB를 사용합니다. DynamoDB 엔드포인트를 사용하도록 애플리케이션을 변경합니다.
B. 데이터베이스의 대상 그룹과 함께 Amazon RDS Proxy를 사용합니다. RDS Proxy 엔드포인트를 사용하도록 애플리케이션을 변경합니다.
C. Amazon EC2에서 실행되는 사용자 지정 프록시를 데이터베이스의 중개자로 사용합니다. 사용자 지정 프록시 엔드포인트를 사용하도록 애플리케이션을 변경합니다.
D. AWS Lambda 함수를 사용하여 데이터베이스에 대한 대상 그룹 구성으로 연결 풀링을 제공합니다. Lambda 함수를 사용하도록 애플리케이션을 변경합니다.

B.데이터베이스의 대상 그룹과 함께 Amazon RDS Proxy를 사용합니다. RDS Proxy 엔드포인트를 사용하도록 애플리케이션을 변경합니다.

Amazon RDS Proxy는 AWS에서 관리형 데이터베이스 프록시 서비스입니다. 주로 애플리케이션과 RDS 간의 연결 풀링을 제공하여 데이터베이스 연결 관리를 최적화합니다.

RDS Proxy는 다음과 같은 장점을 제공합니다.
- 자동 연결 풀링: RDS에 연결되는 클라이언트의 연결을 관리하여 데이터베이스에 대한 부하를 줄입니다.
- 보안: IAM 인증 및 Secrets Manager 통합을 통해 자격 증명 관리가 간소화됩니다.
- 고가용성: RDS 인스턴스 장애 시에도 연결을 지속적으로 유지합니다.

애플리케이션에서 변경해야 하는 것은 프록시 엔드포인트로 연결을 전환하는 것이며, 이는 비교적 간단합니다.
AWS가 RDS Proxy를 완전히 관리하므로 운영 오버헤드가 매우 낮습니다.

---

■ Question #662

한 회사가 AWS Cost Explorer를 사용하여 AWS 비용을 모니터링합니다. 이 회사는 Amazon Elastic Block Store(Amazon EBS) 스토리지 및 스냅샷 비용이 매달 증가한다는 것을 알게 됩니다. 하지만 이 회사는 매달 추가 EBS 스토리지를 구매하지 않습니다. 이 회는 현재 스토리지 사용량에 대한 월별 비용을 최적화하려고 합니다.

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

A. Amazon CloudWatch Logs의 로그를 사용하여 Amazon EBS의 스토리지 활용도를 모니터링합니다. Amazon EBS Elastic Volumes를 사용하여 EBS 볼륨의 크기를 줄입니다.
B. 사용자 정의 스크립트를 사용하여 공간 사용량을 모니터링합니다. Amazon EBS Elastic Volumes를 사용하여 EBS 볼륨의 크기를 줄입니다.
C. 스냅샷 비용을 줄이려면 만료되었거나 사용되지 않는 모든 스냅샷을 삭제합니다.
D. 모든 불필요한 스냅샷을 삭제합니다. Amazon Data Lifecycle Manager를 사용하여 회사의 스냅샷 정책 요구 사항에 따라 스냅샷을 만들고 관리합니다.

D. 모든 불필요한 스냅샷을 삭제합니다. Amazon Data Lifecycle Manager를 사용하여 회사의 스냅샷 정책 요구 사항에 따라 스냅샷을 만들고 관리합니다.

스냅샷 관리 최적화
- 회사는 매달 추가 EBS 스토리지를 구매하지 않으면서도 비용이 증가하고 있으므로, 스냅샷이 비용 증가의 주요 원인일 가능성이 높습니다.
- 불필요한 스냅샷을 삭제하면 스냅샷 스토리지 비용을 줄일 수 있습니다.

Amazon Data Lifecycle Manager (DLM)
- DLM은 스냅샷을 자동으로 생성, 보존, 삭제할 수 있도록 정책을 설정할 수 있는 AWS 관리형 서비스입니다.
- 회사가 특정 보존 기간이나 정책을 설정하여 스냅샷의 생애 주기를 관리하면 불필요한 스냅샷이 누적되지 않습니다.

운영 오버헤드 감소
- 수동으로 스냅샷을 관리하는 대신 DLM을 사용하면 관리 부담이 크게 줄어듭니다.

최적화된 비용 관리
- 불필요한 스냅샷을 삭제함으로써 현재 불필요한 비용을 제거하고, DLM 정책을 통해 적절한 스냅샷 수를 유지함으로써 미래 비용 증가를 방지할 수 있습니다.

---

■ Question #663

한 회사가 AWS에서 새로운 애플리케이션을 개발하고 있습니다. 이 애플리케이션은 Amazon Elastic Container Service(Amazon ECS) 클러스터, 애플리케이션의 자산이 들어 있는 Amazon S3 버킷, 애플리케이션의 데이터 세트가 들어 있는 Amazon RDS for MySQL 데이터베이스로 구성되어 있습니다. 데이터 세트에는 민감한 정보가 들어 있습니다. 이 회사는 ECS 클러스터만 RDS for MySQL 데이터베이스의 데이터와 S3 버킷의 데이터에 액세스할 수 있도록 하려고 합니다.

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

A. S3 버킷과 RDS for MySQL 데이터베이스를 모두 암호화하기 위해 새로운 AWS Key Management Service(AWS KMS) 고객 관리 키를 만듭니다. KMS 키 정책에 ECS 작업 실행 역할에 대한 암호화 및 암호 해독 권한이 포함되어 있는지 확인합니다.
B. S3 버킷과 RDS for MySQL 데이터베이스를 암호화하기 위해 AWS Key Management Service(AWS KMS) AWS 관리 키를 만듭니다. S3 버킷 정책이 ECS 작업 실행 역할을 사용자로 지정하는지 확인합니다.
C. ECS 작업 실행 역할에 대한 버킷 액세스를 제한하는 S3 버킷 정책을 만듭니다. Amazon RDS for MySQL에 대한 VPC 엔드포인트를 만듭니다. RDS for MySQL 보안 그룹을 업데이트하여 ECS 클러스터가 작업을 생성할 서브넷에서만 액세스를 허용합니다.
D. Amazon RDS for MySQL에 대한 VPC 엔드포인트를 만듭니다. ECS 클러스터가 작업을 생성할 서브넷에서만 액세스할 수 있도록 RDS for MySQL 보안 그룹을 업데이트합니다. Amazon S3에 대한 VPC 엔드포인트를 만듭니다. S3 VPC 엔드포인트에서만 액세스할 수 있도록 S3 버킷 정책을 업데이트합니다.

D. Amazon RDS for MySQL에 대한 VPC 엔드포인트를 만듭니다. ECS 클러스터가 작업을 생성할 서브넷에서만 액세스할 수 있도록 RDS for MySQL 보안 그룹을 업데이트합니다. Amazon S3에 대한 VPC 엔드포인트를 만듭니다. S3 VPC 엔드포인트에서만 액세스할 수 있도록 S3 버킷 정책을 업데이트합니다.

VPC 엔드포인트로 보안 향상
- VPC 엔드포인트를 사용하면 인터넷을 통해 AWS 서비스에 접근하지 않고, VPC 내부에서 S3 및 RDS 데이터베이스에 안전하게 연결할 수 있습니다.
- RDS 및 S3 모두에 VPC 엔드포인트를 사용하면 액세스를 특정 서브넷으로 제한할 수 있으므로 보안을 강화합니다.

보안 그룹으로 RDS 액세스 제한
- RDS의 보안 그룹을 업데이트하여 ECS 작업 실행이 생성되는 서브넷에서만 데이터베이스에 액세스할 수 있도록 설정하면, 민감한 정보에 대한 무단 액세스를 방지할 수 있습니다.

S3 버킷 정책으로 세부적인 권한 관리
- S3 VPC 엔드포인트에서만 액세스를 허용하도록 S3 버킷 정책을 설정하면, ECS 클러스터 외의 다른 리소스에서 S3 데이터에 접근하는 것을 방지할 수 있습니다.

민감한 정보 보호
- 애플리케이션의 민감한 데이터가 있는 RDS 데이터베이스와 S3 데이터는 ECS 클러스터에서만 접근할 수 있도록 설계되어 데이터 기밀성을 유지합니다.

---

■ Question #664

한 회사에 온프레미스에서 실행되는 웹 애플리케이션이 있습니다. 이 애플리케이션은 피크 시간 동안 지연 문제를 겪습니다. 지연 문제는 매달 두 번 발생합니다. 지연 문제가 시작되면 애플리케이션의 CPU 사용률이 정상 수준의 10배로 즉시 증가합니다. 이 회사는 지연 시간을 개선하기 위해 애플리케이션을 AWS로 마이그레이션하려고 합니다. 또한 이 회사는 애플리케이션 수요가 증가하면 애플리케이션을 자동으로 확장하려고 합니다. 이 회사는 애플리케이션 배포에 AWS Elastic Beanstalk를 사용합니다.

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

A. 무제한 모드에서 버스트 가능한 성능 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 요청에 따라 확장되도록 환경을 구성합니다.
B. Elastic Beanstalk 환경을 구성하여 컴퓨팅 최적화 인스턴스를 사용합니다. 요청에 따라 확장하도록 환경을 구성합니다.
C. 컴퓨팅 최적화 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 일정에 따라 확장되도록 환경을 구성합니다.
D. 무제한 모드에서 버스트 가능한 성능 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 예측 지표에 따라 확장하도록 환경을 구성합니다.

A.무제한 모드에서 버스트 가능한 성능 인스턴스를 사용하도록 Elastic Beanstalk 환경을 구성합니다. 요청에 따라 확장되도록 환경을 구성합니다.

redictive Scaling의 부재 및 데이터 부족
- AWS Elastic Beanstalk에는 Predictive Scaling이라는 내장 서비스가 없으며, 실제로 사용 가능한 데이터가 없는 상태에서는 트래픽 급증을 예측할 수 없습니다.
- Predictive Scaling은 Amazon EC2 Auto Scaling과 같은 서비스에서 사용 가능하지만, 과거 데이터가 있어야 효과적입니다.

즉각적인 트래픽 급증 문제 대응
- A 옵션은 무제한 모드에서 버스트 가능한 성능 인스턴스(Burstable Performance Instances)를 사용하므로, 예측 불가능한 트래픽 급증 상황에서도 탄력적으로 대응할 수 있습니다.
- 특히, CPU 사용량이 급증할 때 초기 크레딧을 사용할 수 있으므로 초기 성능 문제를 완화합니다.

AWS 마이그레이션 초기 단계에 적합
- A 옵션의 "요청 기반 확장(Request-based Scaling)"은 마이그레이션 초기 단계에서 가장 쉽게 구현할 수 있는 자동 확장 옵션입니다.
- 최소한의 설정으로 트래픽 변화에 따라 실시간으로 스케일링되며, 운영 부담을 줄일 수 있습니다.

---

■ Question #665

한 회사에는 전 세계에 고객이 있습니다. 이 회사는 자동화를 사용하여 시스템과 네트워크 인프라를 보호하고자 합니다. 이 회사의 보안 팀은 인프라에 대한 모든 증분적 변경 사항을 추적하고 감사할 수 있어야 합니다.

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

A. AWS Organizations를 사용하여 인프라를 설정합니다. AWS Config를 사용하여 변경 사항을 추적합니다.
B. AWS CloudFormation을 사용하여 인프라를 설정합니다. AWS Config를 사용하여 변경 사항을 추적합니다.
C .AWS Organizations를 사용하여 인프라를 설정합니다. AWS Service Catalog를 사용하여 변경 사항을 추적합니다.
D. AWS CloudFormation을 사용하여 인프라를 설정합니다. AWS Service Catalog를 사용하여 변경 사항을 추적합니다.

요구 사항 분석
- 전 세계 고객: 글로벌 인프라를 지원해야 하므로 AWS 서비스의 확장성 필요
- 자동화: 시스템과 네트워크 인프라 설정을 자동화해야 함
- 증분적 변경 추적 및 감사: 인프라 상태 및 변경 내역을 지속적으로 모니터링하고 기록해야 함

B.AWS CloudFormation을 사용하여 인프라를 설정합니다. AWS Config를 사용하여 변경 사항을 추적합니다.
- WS CloudFormation: 인프라를 코드로 관리하여 자동화 및 일관성 있는 설정을 제공
- AWS Config: 인프라 변경 사항을 추적하고 규정 준수를 모니터링
- 적합함: CloudFormation으로 자동화된 설정을 수행하고, Config로 변경 사항을 추적 및 감사할 수 있음

---

■ Question #666

스타트업 회사가 Amazon EC2 인스턴스에서 고객을 위한 웹사이트를 호스팅하고 있습니다. 이 웹사이트는 상태 비저장 Python 애플리케이션과 MySQL 데이터베이스로 구성되어 있습니다. 이 웹사이트는 소량의 트래픽만 처리합니다. 이 회사는 인스턴스의 안정성에 대해 우려하고 있으며 고가용성 아키텍처로 마이그레이션해야 합니다. 이 회사는 애플리케이션 코드를 수정할 수 없습니다.

솔루션 아키텍트는 웹사이트의 고가용성을 달성하기 위해 어떤 조치 조합을 취해야 합니까? (두 가지를 선택하세요.)

A. 사용 중인 각 가용성 영역에 인터넷 게이트웨이를 제공합니다.
B. 데이터베이스를 Amazon RDS for MySQL Multi-AZ DB 인스턴스로 마이그레이션합니다.
C. 데이터베이스를 Amazon DynamoDB로 마이그레이션하고 DynamoDB 자동 크기 조정을 활성화합니다.
D. AWS DataSync를 사용하여 여러 EC2 인스턴스의 데이터베이스 데이터를 동기화합니다.
E. 두 개의 가용성 영역에 분산된 EC2 인스턴스의 자동 확장 그룹에 트래픽을 분산하기 위한 애플리케이션 로드 밸런서를 생성합니다.

B.데이터베이스를 Amazon RDS for MySQL Multi-AZ DB 인스턴스로 마이그레이션합니다.
- Amazon RDS의 Multi-AZ 배포는 데이터베이스의 고가용성을 보장합니다.
- 장애가 발생하면 자동으로 대기 인스턴스로 장애 조치를 수행합니다.

E.두 개의 가용성 영역에 분산된 EC2 인스턴스의 자동 확장 그룹에 트래픽을 분산하기 위한 애플리케이션 로드 밸런서를 생성합니다.
- 애플리케이션 로드 밸런서는 여러 가용성 영역의 EC2 인스턴스에 트래픽을 분산하여 고가용성을 보장합니다.
- 자동 확장 그룹은 EC2 인스턴스를 동적으로 확장하거나 축소할 수 있습니다.

---

■ Question #667

한 회사가 다년간의 마이그레이션 프로젝트 동안 데이터와 애플리케이션을 AWS로 옮기고 있습니다. 이 회사는 회사의 AWS 리전과 회사의 온프레미스 위치에서 Amazon S3의 데이터에 안전하게 액세스하려고 합니다. 데이터는 인터넷을 통과해서는 안 됩니다. 이 회사는 리전과 온프레미스 위치 사이에 AWS Direct Connect 연결을 설정했습니다.

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

A. Amazon S3에 대한 게이트웨이 엔드포인트를 만듭니다. 게이트웨이 엔드포인트를 사용하여 Region과 온프레미스 위치에서 데이터에 안전하게 액세스합니다.
B. AWS Transit Gateway에서 게이트웨이를 생성하여 리전과 온프레미스 위치에서 Amazon S3에 안전하게 액세스합니다.
C. Amazon S3에 대한 인터페이스 엔드포인트를 만듭니다. 인터페이스 엔드포인트를 사용하여 Region과 온프레미스 위치에서 데이터에 안전하게 액세스합니다.
D. AWS Key Management Service(AWS KMS) 키를 사용하여 지역 및 온프레미스 위치에서 안전하게 데이터에 액세스합니다.

C.Amazon S3에 대한 인터페이스 엔드포인트를 만듭니다. 인터페이스 엔드포인트를 사용하여 Region과 온프레미스 위치에서 데이터에 안전하게 액세스합니다.

온프레미스에서 Amazon S3에 액세스
- 게이트웨이 엔드포인트는 VPC 내부에서만 작동하며, 온프레미스 네트워크에서 S3에 직접 액세스하려면 사용할 수 없습니다.
- 인터페이스 엔드포인트는 AWS PrivateLink를 사용하여 VPC와 온프레미스 네트워크 간 안전한 연결을 지원합니다.
- AWS PrivateLink : AWS 서비스, VPC 간, 또는 온프레미스 네트워크와 AWS 서비스를 안전하게 연결하기 위한 기술입니다. 이를 통해 퍼블릭 인터넷을 통하지 않고 프라이빗 네트워크에서 AWS 서비스와의 통신이 가능합니다.
- AWS PrivateLink는 Elastic Network Interface(ENI)와 VPC Endpoint를 사용하여 연결을 설정하며, 보안과 성능을 모두 강화합니다.

인터넷 트래픽 차단
- 인터페이스 엔드포인트는 인터넷을 통하지 않고 AWS 네트워크를 통해 통신하므로 보안 요구사항을 충족합니다.

추가 비용
- 인터페이스 엔드포인트에는 추가 비용이 있지만, 온프레미스 액세스를 지원하는 유일한 방법이므로 필요한 비용입니다.

---

■ Question #668

한 회사가 AWS Organizations에서 새로운 조직을 만들었습니다. 이 조직에는 회사의 개발팀을 위한 여러 계정이 있습니다. 개발팀 구성원은 AWS IAM Identity Center (AWS Single Sign-On)를 사용하여 계정에 액세스합니다. 회사의 각 애플리케이션에 대해 개발팀은 미리 정의된 애플리케이션 이름을 사용하여 생성된 리소스에 태그를 지정해야 합니다. 솔루션 아키텍트는 애플리케이션 이름 태그에 승인된 값이 있는 경우에만 개발팀이 리소스를 생성할 수 있는 솔루션을 설계해야 합니다.

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

A. 리소스를 생성하기 위해 애플리케이션 이름 태그를 지정해야 하는 조건부 허용 정책이 있는 IAM 그룹을 만듭니다.
B. 애플리케이션 이름 태그가 있는 모든 리소스에 대해 거부 정책이 있는 교차 계정 역할을 만듭니다.
C. AWS 리소스 그룹에서 리소스 그룹을 생성하여 모든 계정의 모든 리소스에 태그가 적용되는지 확인합니다.
D. 허용된 애플리케이션 이름 목록이 있는 태그 정책을 조직에 만듭니다.

D. 허용된 애플리케이션 이름 목록이 있는 태그 정책을 조직에 만듭니다.

태그 정책으로 태그 준수 보장
- AWS Organizations에서 태그 정책을 사용하면 조직 내 모든 계정에 태그를 강제로 적용하거나 제한할 수 있습니다.
- 특정 키(예: 'ApplicationName')와 승인된 값 목록을 지정하여 리소스에 태그를 적용하도록 강제할 수 있습니다.

조직 전체 적용 가능
- 태그 정책은 조직 전체에 적용할 수 있으므로 모든 계정과 리소스에 동일한 정책을 강제할 수 있습니다.

정책 유효성 검사
- 리소스 생성 시 승인된 태그 값만 사용할 수 있도록 설정하여 비승인된 값이나 누락된 태그로 리소스가 생성되지 않도록 방지합니다.

 

▼ 태그 정책의 예제

{
  "tags": {
    "ApplicationName": {
      "tag_key": "ApplicationName",
      "tag_value": {
        "enforced_for": "create",
        "values": ["AppA", "AppB", "AppC"]
      }
    }
  }
}

---

■ Question #669

한 회사가 Amazon RDS for PostgreSQL에서 데이터베이스를 실행합니다. 이 회사는 30일마다 암호를 순환하여 마스터 사용자 암호를 관리하는 안전한 솔루션을 원합니다.

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

A. Amazon EventBridge를 사용하여 사용자 지정 AWS Lambda 함수를 예약하여 30일마다 비밀번호를 교체합니다.
B. AWS CLI에서 modify-db-instance 명령을 사용하여 비밀번호를 변경합니다.
C. AWS Secrets Manager를 Amazon RDS for PostgreSQL과 통합하여 비밀번호 교체를 자동화합니다.
D. AWS Systems Manager Parameter Store를 Amazon RDS for PostgreSQL과 통합하여 비밀번호 교체를 자동화합니다.

문제 분석
- 회사는 자동 비밀번호 순환과 운영 오버헤드를 최소화하려고 합니다.
- 안전하고 관리가 용이한 솔루션이 필요합니다.

C.AWS Secrets Manager를 Amazon RDS for PostgreSQL과 통합하여 비밀번호 교체를 자동화합니다.
- Secrets Manager는 RDS 데이터베이스와 통합되어 비밀번호 교체를 완전히 자동화할 수 있습니다.
- Secrets Manager를 사용하면 자동 비밀번호 관리 기능을 활성화할 수 있습니다.
- 비밀번호를 교체한 후 연결된 애플리케이션이나 서비스가 Secrets Manager에서 최신 비밀번호를 검색하도록 구성할 수 있습니다.
- 운영 오버헤드가 가장 적고 관리가 간단한 솔루션입니다.

---

■ Question #670

한 회사가 Amazon DynamoDB 테이블을 사용하는 애플리케이션에서 테스트를 수행합니다. 테스트는 일주일에 한 번 4시간 동안 실행됩니다. 회사는 테스트 중에 애플리케이션이 테이블에 대해 초당 수행하는 읽기 및 쓰기 작업 수를 알고 있습니다. 회사는 현재 다른 사용 사례에 DynamoDB를 사용하지 않습니다. 솔루션 아키텍트는 테이블 비용을 최적화해야 합니다.

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

A. 주문형 모드를 선택합니다. 읽기 및 쓰기 용량 단위를 적절히 업데이트합니다.
B. 프로비저닝 모드를 선택합니다. 읽기 및 쓰기 용량 단위를 적절히 업데이트합니다.
C. 1년 기간 동안 DynamoDB 예약 용량을 구매합니다.
D. DynamoDB 예약 용량을 3년 기간으로 구매합니다.

B.프로비저닝 모드를 선택합니다. 읽기 및 쓰기 용량 단위를 적절히 업데이트합니다.

예측 가능한 워크로드
- 테스트가 주기적(일주일에 한 번)이며, 애플리케이션의 읽기 및 쓰기 용량 요구 사항을 미리 알고 있음.
- 이러한 예측 가능한 사용량은 프로비저닝된 모드에 적합합니다.

비용 효율성
- DynamoDB의 주문형 모드(On-Demand)는 편리하지만, 비용이 프로비저닝 모드의 약 6~7배입니다.
- 테스트처럼 간헐적이더라도 사용량이 예상 가능하다면, 프로비저닝 모드가 훨씬 저렴합니다.

유연성
- 필요에 따라 읽기 및 쓰기 용량 단위를 설정할 수 있습니다.
- 테스트 종료 후, 필요하지 않은 용량을 줄이는 것도 가능합니다.

---

■ Question #671

한 회사가 Amazon EC2 인스턴스에서 애플리케이션을 실행합니다. 이 회사는 AWS 비용에 대한 주기적 재무 평가를 수행합니다. 이 회사는 최근에 비정상적인 지출을 확인했습니다. 이 회사는 비정상적인 지출을 방지하기 위한 솔루션이 필요합니다. 이 솔루션은 비용을 모니터링하고 비정상적인 지출이 발생하는 경우 책임 있는 이해 관계자에게 알려야 합니다.

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

A. AWS Budgets 템플릿을 사용하여 지출이 없는 예산을 만듭니다.
B. AWS Billing and Cost Management 콘솔에서 AWS 비용 이상 감지 모니터를 만듭니다.
C. 현재 실행 중인 워크로드 가격 세부 정보에 대한 AWS 가격 계산기 추정치를 만듭니다.
D. Amazon CloudWatch를 사용하여 비용을 모니터링하고 비정상적인 지출을 파악합니다.

B. AWS Billing and Cost Management 콘솔에서 AWS 비용 이상 감지 모니터를 만듭니다.

AWS 비용 이상 감지(AWS Cost Anomaly Detection)
- AWS 비용 이상 감지(AWS Cost Anomaly Detection)는 비용 데이터에서 비정상적인 지출 패턴(이상)을 자동으로 식별합니다.
- 이를 통해 비정상적인 사용량 및 비용 증가를 빠르게 파악할 수 있습니다.

자동 알림 기능
- 이상 감지 모니터를 생성하면 책임 있는 이해 관계자에게 이메일이나 Amazon SNS 주제를 통해 알림을 보낼 수 있습니다.

유연한 규칙 및 임계값 설정
- 이상 감지 모니터를 통해 특정 서비스, 계정 또는 태그를 기준으로 비용 이상을 감지하는 규칙을 설정할 수 있습니다.
- 예산 초과를 사전에 방지하고 문제를 빠르게 해결할 수 있습니다.

---

■ Question #672

마케팅 회사가 마케팅 캠페인에서 Amazon S3에 대량의 새로운 클릭스트림 데이터를 수신합니다. 이 회사는 Amazon S3의 클릭스트림 데이터를 빠르게 분석해야 합니다. 그런 다음 이 회사는 데이터 파이프라인에서 데이터를 추가로 처리할지 여부를 결정해야 합니다.

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

A. Spark 카탈로그에서 외부 테이블을 만듭니다. AWS Glue에서 작업을 구성하여 데이터를 쿼리합니다.
B. AWS Glue 크롤러를 구성하여 데이터를 크롤링합니다. Amazon Athena를 구성하여 데이터를 쿼리합니다.
C. Hive 메타스토어에서 외부 테이블을 만듭니다. Amazon EMR에서 Spark 작업을 구성하여 데이터를 쿼리합니다.
D. AWS Glue 크롤러를 구성하여 데이터를 크롤링합니다. Amazon Kinesis Data Analytics를 구성하여 SQL을 사용하여 데이터를 쿼리합니다.

B. AWS Glue 크롤러를 구성하여 데이터를 크롤링합니다. Amazon Athena를 구성하여 데이터를 쿼리합니다.

운영 오버헤드 최소화
- AWS Glue 크롤러는 S3 버킷에 있는 데이터를 자동으로 탐색하고 스키마를 생성합니다. 이를 통해 수동으로 스키마를 정의하지 않아도 됩니다.
- Amazon Athena는 서버리스 쿼리 서비스로, 데이터를 로드하거나 관리할 필요 없이 즉시 SQL 쿼리를 실행할 수 있습니다.

빠른 분석
- Amazon Athena를 사용하면 Amazon S3에 저장된 데이터에 대해 즉각적으로 SQL 쿼리를 실행할 수 있습니다.
- Glue 크롤러가 생성한 메타데이터 카탈로그를 사용하여 데이터를 효율적으로 분석할 수 있습니다.

결정 지원
- Athena에서 데이터를 빠르게 분석한 결과를 바탕으로, 데이터를 추가로 처리할지 여부를 결정할 수 있습니다.

서버리스 아키텍처
- AWS Glue 및 Athena는 모두 서버리스 솔루션이므로, 클러스터 관리나 인프라 유지 관리에 대한 운영 오버헤드가 없습니다.

---

■ Question #673

한 회사가 데이터 센터에서 SMB 파일 서버를 운영합니다. 파일 서버는 회사가 자주 액세스하는 대용량 파일을 파일 생성일로부터 최대 7일 동안 저장합니다. 7일 후, 회사는 최대 24시간의 검색 시간으로 파일에 액세스할 수 있어야 합니다.

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

A. AWS DataSync를 사용하여 7일이 지난 데이터를 SMB 파일 서버에서 AWS로 복사합니다.
B. 회사의 저장 공간을 늘리기 위해 Amazon S3 파일 게이트웨이를 만듭니다. 7일 후 S3 Glacier Deep Archive로 데이터를 전환하기 위한 S3 라이프사이클 정책을 만듭니다.
C. 회사의 스토리지 공간을 늘리기 위해 Amazon FSx 파일 게이트웨이를 만듭니다. 7일 후 데이터를 전환하기 위한 Amazon S3 라이프사이클 정책을 만듭니다.
D. 각 사용자에 대해 Amazon S3에 대한 액세스를 구성합니다. 7일 후 S3 Glacier Flexible Retrieval로 데이터를 전환하기 위한 S3 Lifecycle 정책을 만듭니다.

B. 회사의 저장 공간을 늘리기 위해 Amazon S3 파일 게이트웨이를 만듭니다. 7일 후 S3 Glacier Deep Archive로 데이터를 전환하기 위한 S3 라이프사이클 정책을 만듭니다.

Amazon S3 파일 게이트웨이
- SMB 파일 서버의 데이터와 통합하여 데이터를 클라우드에 저장할 수 있는 하이브리드 클라우드 스토리지 솔루션입니다.
- 파일은 Amazon S3에 저장되며, 온프레미스 사용자들은 기존 SMB 파일 서버와 동일한 방식으로 파일에 접근할 수 있습니다.

S3 Glacier Deep Archive
- S3 Glacier Deep Archive : Amazon S3의 스토리지 클래스 중 하나로, 가장 낮은 스토리지 비용을 제공하며, 데이터가 거의 액세스되지 않지만 장기 보관이 필요한 워크로드에 최적화되어 있습니다. 주로 데이터 보존 기간이 수년에서 수십 년에 달하는 경우 사용됩니다.
- 7일 후 액세스 빈도가 낮아진 파일을 S3 Glacier Deep Archive로 전환하여 스토리지 비용을 절감할 수 있습니다.
- 최대 24시간의 검색 시간은 S3 Glacier Deep Archive의 검색 시간과 잘 맞습니다.

S3 Lifecycle 정책
- 데이터를 7일 동안 S3 Standard에 유지한 뒤 S3 Glacier Deep Archive로 자동 전환할 수 있습니다.
- 라이프사이클 정책은 설정 후 자동으로 관리되므로 운영 오버헤드가 적습니다.

---

■ Question #674

한 회사가 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 웹 애플리케이션을 실행합니다. 이 애플리케이션은 Amazon RDS for PostgreSQL DB 인스턴스에서 실행되는 데이터베이스를 사용합니다. 트래픽이 증가하면 애플리케이션이 느리게 실행됩니다. 이 데이터베이스는 트래픽이 많은 기간 동안 많은 읽기 부하를 경험합니다.

솔루션 아키텍트는 이러한 성능 문제를 해결하기 위해 어떤 조치를 취해야 합니까? (두 가지를 선택하세요.)

A. DB 인스턴스에 대한 자동 크기 조정을 켭니다.
B. DB 인스턴스에 대한 읽기 복제본을 만듭니다. 읽기 복제본에 읽기 트래픽을 보내도록 애플리케이션을 구성합니다.
C. DB 인스턴스를 Multi-AZ DB 인스턴스 배포로 변환합니다. 대기 DB 인스턴스로 읽기 트래픽을 보내도록 애플리케이션을 구성합니다.
D. Amazon ElastiCache 클러스터를 만듭니다. ElastiCache 클러스터에서 쿼리 결과를 캐시하도록 애플리케이션을 구성합니다.
E. EC2 인스턴스가 DB 인스턴스와 동일한 가용성 영역에 프로비저닝되도록 자동 크기 조정 그룹 서브넷을 구성합니다.

B. DB 인스턴스에 대한 읽기 복제본을 만듭니다. 읽기 복제본에 읽기 트래픽을 보내도록 애플리케이션을 구성합니다.
- Amazon RDS는 읽기 전용 복제본을 지원하며, 읽기 부하를 분산시킬 수 있습니다.
- 읽기 복제본을 사용하면 읽기 요청을 처리하는 데 필요한 성능을 확장할 수 있으므로 DB의 주요 읽기/쓰기 인스턴스에 부하가 감소합니다.

D. Amazon ElastiCache 클러스터를 만듭니다. ElastiCache 클러스터에서 쿼리 결과를 캐시하도록 애플리케이션을 구성합니다.
- ElastiCache를 사용하여 자주 조회되는 데이터를 메모리에 저장하면 데이터베이스 쿼리 요청 수를 줄일 수 있습니다.
- 이 방법은 읽기 복제본과 결합하면 애플리케이션의 응답 시간을 대폭 줄이고 DB 부하를 완화할 수 있습니다.

---

■ Question #675

한 회사가 Amazon EC2 인스턴스와 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용하여 애플리케이션을 실행합니다. 이 회사는 규정 준수 요구 사항을 충족하기 위해 매일 각 EBS 볼륨의 스냅샷을 하나씩 만듭니다. 이 회사는 EBS 볼륨 스냅샷의 실수로 삭제되는 것을 방지하는 아키텍처를 구현하려고 합니다. 솔루션은 스토리지 관리자 사용자의 관리 권한을 변경해서는 안 됩니다.

어떤 솔루션이 최소한의 관리 노력으로 이러한 요구 사항을 충족할까요?

A. 스냅샷을 삭제할 수 있는 권한이 있는 IAM 역할을 만듭니다. 역할을 새 EC2 인스턴스에 연결합니다. 새 EC2 인스턴스에서 AWS CLI를 사용하여 스냅샷을 삭제합니다.
B. 스냅샷 삭제를 거부하는 IAM 정책을 만듭니다. 정책을 스토리지 관리자 사용자에게 연결합니다.
C. 스냅샷에 태그를 추가합니다. 태그가 있는 EBS 스냅샷에 대해 휴지통에 보관 규칙을 만듭니다.
D. EBS 스냅샷을 잠가 삭제를 방지합니다.

D.EBS 스냅샷을 잠가 삭제를 방지합니다.
- 스냅샷 잠금 기능은 스토리지 관리자 사용자의 관리 권한을 변경하지 않고도 실수로 삭제를 방지할 수 있으므로, 요구 사항에 정확히 부합합니다.
- 최소한의 운영 오버헤드로 요구 사항을 충족할 수 있는 적합한 선택입니다.

---

■ Question #676

회사의 애플리케이션은 Amazon VPC에 배포된 Network Load Balancer, Auto Scaling 그룹, Amazon EC2 인스턴스 및 데이터베이스를 사용합니다. 이 회사는 Amazon VPC에서 거의 실시간으로 네트워크 인터페이스와의 트래픽에 대한 정보를 수집하려고 합니다. 이 회사는 분석을 위해 Amazon OpenSearch Service로 정보를 보내려고 합니다.

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

A. Amazon CloudWatch Logs에서 로그 그룹을 만듭니다. VPC Flow Logs를 구성하여 로그 데이터를 로그 그룹으로 보냅니다. Amazon Kinesis Data Streams를 사용하여 로그 그룹에서 OpenSearch Service로 로그를 스트리밍합니다.
B. Amazon CloudWatch Logs에서 로그 그룹을 만듭니다. VPC Flow Logs를 구성하여 로그 데이터를 로그 그룹으로 보냅니다. Amazon Kinesis Data Firehose를 사용하여 로그 그룹에서 OpenSearch Service로 로그를 스트리밍합니다.
C. AWS CloudTrail에서 트레일을 만듭니다. VPC Flow Logs를 구성하여 로그 데이터를 트레일로 보냅니다. Amazon Kinesis Data Streams를 사용하여 트레일에서 OpenSearch Service로 로그를 스트리밍합니다.
D. AWS CloudTrail에서 트레일을 만듭니다. VPC Flow Logs를 구성하여 로그 데이터를 트레일로 보냅니다. Amazon Kinesis Data Firehose를 사용하여 트레일에서 OpenSearch Service로 로그를 스트리밍합니다.

요구사항 분석
- VPC 트래픽에 대한 정보 수집: VPC Flow Logs는 네트워크 인터페이스의 트래픽 데이터를 수집하는 데 사용됩니다.
- Amazon OpenSearch Service로 데이터 전달: 실시간 또는 거의 실시간으로 OpenSearch Service에 데이터를 전송하려면 효율적인 데이터 스트리밍 도구가 필요합니다.

B.Amazon CloudWatch Logs에서 로그 그룹을 만듭니다. VPC Flow Logs를 구성하여 로그 데이터를 로그 그룹으로 보냅니다. Amazon Kinesis Data Firehose를 사용하여 로그 그룹에서 OpenSearch Service로 로그를 스트리밍합니다.

 

- Amazon CloudWatch Logs는 AWS에서 애플리케이션, 시스템, 및 AWS 리소스에서 생성된 로그 데이터를 수집, 저장 및 분석할 수 있는 관리형 로그 모니터링 서비스입니다. 이를 통해 로그 데이터를 실시간으로 모니터링하고, 문제를 진단하며, 시스템 및 애플리케이션의 상태를 이해할 수 있습니다.
- Amazon Kinesis Data Firehose는 AWS에서 제공하는 실시간 스트리밍 데이터 수집 및 전송 서비스입니다. Kinesis Data Firehose를 사용하면 데이터 소스로부터 데이터를 캡처하고, 데이터 변환(옵션), 처리 후 다양한 AWS 서비스(Amazon S3, Redshift, Elasticsearch, OpenSearch 등) 또는 타사 도구로 데이터를 자동으로 전달할 수 있습니다.
- Amazon OpenSearch Service는 AWS에서 제공하는 완전 관리형 검색 및 분석 서비스로, 애플리케이션 로그, 시스템 메트릭, 웹사이트 검색 기능 등을 구현할 수 있도록 돕는 서비스입니다. 이는 오픈 소스 검색 및 분석 엔진인 OpenSearch 및 Elasticsearch와 호환되며, Kibana와 OpenSearch Dashboards를 통해 시각화를 지원합니다.
- Kinesis Data Firehose는 OpenSearch Service로 데이터를 직접 스트리밍할 수 있는 네이티브 지원을 제공합니다.
- CloudWatch Logs + Kinesis Data Firehose + OpenSearch Service : 데이터 배치 크기와 전송 빈도를 조정할 수 있어 효율적인 데이터 전송이 가능합니다.
- 운영 오버헤드가 낮습니다.

---

■ Question #677

한 회사에서 프로덕션 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터에서 실행되는 애플리케이션을 개발하고 있습니다. EKS 클러스터에는 온디맨드 인스턴스로 프로비저닝된 관리형 노드 그룹이 있습니다. 이 회사는 개발 작업을 위한 전담 EKS 클러스터가 필요합니다. 이 회사는 애플리케이션의 복원력을 테스트하기 위해 개발 클러스터를 드물게 사용합니다. EKS 클러스터는 모든 노드를 관리해야 합니다.

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

A. 스팟 인스턴스만 포함하는 관리형 노드 그룹을 생성합니다.
B. 두 개의 관리형 노드 그룹을 만듭니다. 온디맨드 인스턴스로 한 노드 그룹을 프로비저닝합니다. 스팟 인스턴스로 두 번째 노드 그룹을 프로비저닝합니다.
C. Spot Instances를 사용하는 시작 구성이 있는 Auto Scaling 그룹을 만듭니다. 노드를 EKS 클러스터에 추가하기 위한 사용자 데이터를 구성합니다.
D. 온디맨드 인스턴스만 포함하는 관리형 노드 그룹을 만듭니다.

A.스팟 인스턴스만 포함하는 관리형 노드 그룹(Amazon EKS Managed Node Group)을 생성합니다.
- Amazon EKS Managed Node Group은 AWS에서 관리하기 때문에 사용자 입장에서 운영 복잡성이 크게 줄어듭니다.
- Spot Instances는 온디맨드 인스턴스에 비해 최대 90%까지 비용을 절감할 수 있으므로 비용 효율성이 뛰어납니다.
- Spot Instances는 드물게 사용되는 개발 클러스터와 복원력 테스트 같은 시나리오에 적합합니다.

---

■ Question #678

한 회사가 Amazon S3에 민감한 데이터를 저장합니다. 솔루션 아키텍트는 암호화 솔루션을 만들어야 합니다. 회사는 암호화해야 하는 모든 데이터에 대해 최소한의 노력으로 사용자가 암호화 키를 만들고, 순환하고, 비활성화할 수 있는 기능을 완전히 제어해야 합니다.

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

A. Amazon S3 관리 암호화 키(SSE-S3)를 사용하여 기본 서버 측 암호화를 사용하여 민감한 데이터를 저장합니다.
B. AWS Key Management Service(AWS KMS)를 사용하여 고객 관리 키를 만듭니다. AWS KMS 키(SSE-KMS)를 사용하여 서버 측 암호화를 사용하여 새 키를 사용하여 S3 객체를 암호화합니다.
C. AWS Key Management Service(AWS KMS)를 사용하여 AWS 관리형 키를 만듭니다. 새 키를 사용하여 AWS KMS 키(SSE-KMS)를 사용하여 서버 측 암호화를 사용하여 S3 객체를 암호화합니다.
D. Amazon EC2 인스턴스에 S3 객체를 다운로드합니다. 고객 관리 키를 사용하여 객체를 암호화합니다. 암호화된 객체를 다시 Amazon S3에 업로드합니다.

B. AWS Key Management Service(AWS KMS)를 사용하여 고객 관리 키를 만듭니다. AWS KMS 키(SSE-KMS)를 사용하여 서버 측 암호화를 사용하여 새 키를 사용하여 S3 객체를 암호화합니다.

고객 관리 키(CMK)
- 회사는 암호화 키의 생성, 순환 및 비활성화를 직접 제어하고 싶어합니다.
- AWS KMS의 고객 관리 키(CMK)를 사용하면 사용자가 키를 생성, 순환, 비활성화, 삭제할 수 있습니다. 이는 사용자에게 키의 완전한 제어 권한을 제공합니다.

SSE-KMS
- S3의 서버 측 암호화 옵션 중 하나인 SSE-KMS는 AWS KMS와 통합되어 있으며, S3 객체를 암호화할 때 KMS 키를 활용합니다.
- 이를 통해 데이터 암호화와 키 관리 기능을 AWS KMS를 통해 간편하게 사용할 수 있습니다.

---

■ Question #679

한 회사가 온프레미스 가상 머신(VM)을 AWS에 백업하려고 합니다. 회사의 백업 솔루션은 온프레미스 백업을 Amazon S3 버킷에 객체로 내보냅니다. S3 백업은 30일 동안 보관해야 하며 30일 후에는 자동으로 삭제해야 합니다.

이러한 요구 사항을 충족하는 단계 조합은 무엇입니까? (세 가지를 선택하세요.)

A. S3 객체 잠금이 활성화된 S3 버킷을 생성합니다.
B. 객체 버전 관리가 활성화된 S3 버킷을 생성합니다.
C. 객체에 대한 기본 보존 기간을 30일로 구성합니다.
D. 객체를 30일 동안 보호하기 위해 S3 수명 주기 정책을 구성합니다.
E. 30일 후에 객체가 만료되도록 S3 수명 주기 정책을 구성합니다.
F. 개체에 30일 보존 기간을 태그 지정하도록 백업 솔루션을 구성합니다.

A. S3 객체 잠금이 활성화된 S3 버킷을 생성합니다.
- S3 객체 잠금(Object Lock)은 객체를 지정된 보존 기간 동안 삭제 또는 덮어쓰지 못하도록 방지합니다. 이는 데이터의 무결성을 보장하며 백업 데이터를 30일 동안 안전하게 보호하는 데 필요합니다.

C. 객체에 대한 기본 보존 기간을 30일로 구성합니다.
- S3 객체 잠금을 활성화한 경우, 기본 보존 기간을 설정하여 객체가 자동으로 30일 동안 보호되도록 구성할 수 있습니다. 이를 통해 수동 관리 없이도 데이터 보존 요구 사항을 충족할 수 있습니다.

E. 30일 후에 객체가 만료되도록 S3 수명 주기 정책을 구성합니다.
- S3 수명 주기 정책은 데이터 보관 비용을 최적화하고 자동으로 만료된 객체를 삭제하는 데 사용됩니다. 30일 후에 백업 데이터를 삭제하려면 수명 주기 정책을 구성해야 합니다.

---

■ Question #680

솔루션 아키텍트는 Amazon S3 버킷에서 Amazon Elastic File System(Amazon EFS) 파일 시스템과 다른 S3 버킷으로 파일을 복사해야 합니다. 파일은 지속적으로 복사해야 합니다. 새 파일은 원래 S3 버킷에 일관되게 추가됩니다. 복사된 파일은 소스 파일이 변경되는 경우에만 덮어써야 합니다.

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

A. 대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 만듭니다. 대상 S3 버킷과 EFS 파일 시스템에 대한 작업을 만듭니다. 전송 모드를 변경된 데이터만 전송하도록 설정합니다.
B. AWS Lambda 함수를 만듭니다. 파일 시스템을 함수에 마운트합니다. Amazon S3에서 파일이 생성되고 변경될 때 함수를 호출하도록 S3 이벤트 알림을 설정합니다. 파일을 파일 시스템과 대상 S3 버킷에 복사하도록 함수를 구성합니다.
C. 대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 만듭니다. 대상 S3 버킷과 EFS 파일 시스템에 대한 작업을 만듭니다. 전송 모드를 모든 데이터 전송으로 설정합니다.
D. 파일 시스템과 동일한 VPC에서 Amazon EC2 인스턴스를 시작합니다. 파일 시스템을 마운트합니다. 원본 S3 버킷에서 변경된 모든 객체를 대상 S3 버킷과 마운트된 파일 시스템에 정기적으로 동기화하는 스크립트를 만듭니다.

A.대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 만듭니다. 대상 S3 버킷과 EFS 파일 시스템에 대한 작업을 만듭니다. 전송 모드를 변경된 데이터만 전송하도록 설정합니다.
- AWS DataSync는 데이터 전송을 자동화하고 효율적으로 수행할 수 있는 완전 관리형 서비스입니다. 변경된 데이터만 전송하는 모드를 사용하면 운영 오버헤드를 최소화하고 네트워크 및 스토리지 비용을 절감할 수 있습니다.
- DataSync는 S3 버킷과 EFS 간의 데이터 전송을 지원하며, 덮어쓰기 조건도 처리할 수 있어 요구 사항을 충족합니다.