AWS SAA-C03 Examtopics (861 ~ 880)

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

 

■ Question #861

한 회사가 온프레미스 MySQL 데이터베이스를 AWS로 이전하려고 합니다. 데이터베이스는 클라이언트 기반 애플리케이션에서 정기적으로 가져오기를 허용하여 많은 양의 쓰기 작업이 발생합니다. 이 회사는 트래픽 양이 애플리케이션 내에서 성능 문제를 일으킬 수수있다고 우려합니다.

솔루션 아키텍트는 AWS에서 아키텍처를 어떻게 설계해야 할까요?

A. Provisioned IOPS SSD 스토리지로 Amazon RDS for MySQL DB 인스턴스를 프로비저닝합니다. Amazon CloudWatch를 사용하여 쓰기 작업 메트릭을 모니터링합니다. 필요한 경우 프로비저닝된 IOPS를 조정합니다.

B. General Purpose SSD 스토리지가 있는 Amazon RDS for MySQL DB 인스턴스를 프로비저닝합니다. DB 인스턴스 앞에 Amazon ElastiCache 클러스터를 배치합니다. 대신 ElastiCache를 쿼리하도록 애플리케이션을 구성합니다.

C. 메모리 최적화 인스턴스 유형으로 Amazon DocumentDB(MongoDB 호환) 인스턴스를 프로비저닝합니다. 성능 관련 문제에 대해 Amazon CloudWatch를 모니터링합니다. 필요한 경우 인스턴스 클래스를 변경합니다.

D. General Purpose 성능 모드에서 Amazon Elastic File System(Amazon EFS) 파일 시스템을 프로비저닝합니다. Amazon CloudWatch에서 IOPS 병목 현상을 모니터링합니다. 필요한 경우 Provisioned Throughput 성능 모드로 변경합니다.

A. Provisioned IOPS SSD 스토리지로 Amazon RDS for MySQL DB 인스턴스를 프로비저닝합니다. Amazon CloudWatch를 사용하여 쓰기 작업 메트릭을 모니터링합니다. 필요한 경우 프로비저닝된 IOPS를 조정합니다.
- Provisioned IOPS SSD는 쓰기 작업이 많고 I/O가 중요한 데이터베이스에서 성능을 최적화하기 위한 최적의 선택입니다. 이 스토리지는 높은 일관성의 성능을 제공하며, 특히 많은 양의 쓰기 작업이 있는 환경에서 안정적으로 높은 성능을 보장합니다.

- Amazon RDS for MySQL은 AWS에서 관리형 MySQL 데이터베이스를 제공하며, 다양한 메트릭을 모니터링하고 필요에 따라 스토리지 성능을 조정할 수 있습니다.

- Amazon CloudWatch를 사용하면 DB 인스턴스의 메트릭을 모니터링하고, 쓰기 작업의 IOPS 사용량을 실시간으로 관찰하여 필요한 경우 빠르게 조정할 수 있습니다.

---

■ Question #862

한 회사가 AWS 클라우드에서 민감한 보관 데이터 파일을 생성하는 애플리케이션을 실행합니다. 이 회사는 애플리케이션의 데이터 저장소를 재구성하려고 합니다. 이 회사는 데이터 파일을 암호화하고 데이터가 암호화되어 AWS로 전송되기 전에 제3자가 데이터에 액세스하지 못하도록 하려고 합니다. 이 회사는 이미 Amazon S3 버킷을 만들었습니다.

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

A. Amazon S3 관리 암호화 키로 클라이언트 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷을 사용하여 보관 파일을 저장하도록 애플리케이션을 구성합니다

B. AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷을 사용하여 보관 파일을 저장하도록 애플리케이션을 구성합니다

C. AWS KMS 키(SSE-KMS)로 듀얼 레이어 서버 측 암호화를 사용하도록 S3 버킷을 구성합니다. S3 버킷을 사용하여 보관 파일을 저장하도록 애플리케이션을 구성합니다

D. AWS Key Management Service(AWS KMS)에 저장된 키로 클라이언트 측 암호화를 사용하도록 애플리케이션을 구성합니다. S3 버킷에 보관 파일을 저장하도록 애플리케이션을 구성합니다.

D. AWS Key Management Service(AWS KMS)에 저장된 키로 클라이언트 측 암호화를 사용하도록 애플리케이션을 구성합니다. S3 버킷에 보관 파일을 저장하도록 애플리케이션을 구성합니다.

- 클라이언트 측 암호화는 데이터가 AWS로 전송되기 전에 암호화가 수행됨을 의미합니다. 따라서, 전송 중에도 데이터가 암호화된 상태로 유지되며, 제3자가 중간에 데이터를 가로채더라도 내용을 해독할 수 없습니다.

- AWS Key Management Service(AWS KMS)에 저장된 키를 사용하면, 암호화 키의 관리 및 감사를 중앙에서 일관되게 수행할 수 있습니다.

- 클라이언트 측에서 암호화된 데이터는 S3 버킷에 안전하게 저장되며, AWS에 업로드되기 전에 데이터가 완전히 암호화된 상태가 보장됩니다.

---

■ Question #863

한 회사가 데이터베이스 계층에 대한 기본 백업 설정으로 Amazon RDS를 사용합니다. 이 회사는 규제 요구 사항을 충족하기 위해 매일 데이터베이스를 백업해야 합니다. 이 회사는 30일 동안 백업을 보관해야 합니다.

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

A. 매일 RDS 스냅샷을 생성하는 AWS Lambda 함수를 작성합니다.

B. 자동 백업에 대한 보관 기간이 30일이 되도록 RDS 데이터베이스를 수정합니다.

C. AWS Systems Manager Maintenance Windows를 사용하여 RDS 백업 보관 기간을 수정합니다.

D. AWS CLI를 사용하여 매일 수동 스냅샷을 생성합니다. RDS 백업 보관 기간을 수정합니다.

B. 자동 백업에 대한 보관 기간이 30일이 되도록 RDS 데이터베이스를 수정합니다.

- Amazon RDS는 자동 백업 기능을 제공하며, 백업의 보관 기간을 최대 35일로 설정할 수 있습니다. 자동 백업은 RDS가 자동으로 정해진 스케줄에 따라 백업을 수행하며, 관리자가 수동으로 개입할 필요가 없습니다.

- 자동 백업 보관 기간을 30일로 설정하면, 자동으로 30일 동안 백업이 유지되며, 오래된 백업은 자동으로 삭제됩니다. 이를 통해 규정 준수를 유지할 수 있습니다.

- 운영 오버헤드가 거의 없으며, 설정 후에는 백업 관리에 대한 추가적인 작업이 필요 없습니다.

---

■ Question #864

AWS에서 애플리케이션을 실행하는 한 회사는 Amazon Aurora DB 클러스터를 데이터베이스로 사용합니다. 여러 사용자가 데이터에 액세스하고 읽는 피크 사용 시간 동안 모니터링 시스템은 쓰기 쿼리에 대한 데이터베이스 성능 저하를 보여줍니다. 이 회사는 피크 사용 수요를 충족하기 위해 애플리케이션의 확장성을 높이고자 합니다.

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

A. 두 번째 Aurora DB 클러스터를 만듭니다. 사용자 데이터를 새 데이터베이스에 복제하는 복사 작업을 구성합니다. 두 번째 데이터베이스를 사용하여 데이터를 읽도록 애플리케이션을 업데이트합니다.

B. 기존 Aurora DB 클러스터 앞에 Amazon DynamoDB Accelerator(DAX) 클러스터를 만듭니다. 읽기 전용 쿼리에 DAX 클러스터를 사용하도록 애플리케이션을 업데이트합니다. Aurora DB 클러스터에 직접 데이터를 씁니다.

C. 기존 Aurora DB 클러스터에 Aurora 읽기 복제본을 만듭니다. 읽기 전용 쿼리에 복제본 엔드포인트를 사용하고 쓰기 쿼리에 클러스터 엔드포인트를 사용하도록 애플리케이션을 업데이트합니다.

D. Amazon Redshift 클러스터를 만듭니다. 사용자 데이터를 Redshift 클러스터에 복사합니다. Redshift 클러스터에 연결하고 Redshift 클러스터에서 읽기 전용 쿼리를 수행하도록 애플리케이션을 업데이트합니다.

C. 기존 Aurora DB 클러스터에 Aurora 읽기 복제본을 만듭니다. 읽기 전용 쿼리에 복제본 엔드포인트를 사용하고 쓰기 쿼리에 클러스터 엔드포인트를 사용하도록 애플리케이션을 업데이트합니다.
- Aurora 읽기 복제본은 Amazon Aurora에서 기본 제공하는 기능으로, 읽기 전용 트래픽을 처리하는 데 최적화되어 있습니다. 읽기 복제본을 추가하면 읽기 쿼리 부하를 분산할 수 있어, 쓰기 작업에 영향을 줄이는 데 도움이 됩니다.

- Aurora 읽기 복제본은 쓰기 트래픽을 클러스터 엔드포인트에 유지하면서 읽기 전용 트래픽을 복제본 엔드포인트로 분리하여 처리할 수 있도록 지원합니다. 이를 통해 애플리케이션의 성능을 최적화할 수 있습니다.

- Aurora 읽기 복제본은 기존의 Aurora DB 클러스터와 같은 데이터베이스 엔진을 사용하므로 데이터 동기화 문제나 복잡한 데이터 복제 구성이 필요하지 않습니다.

- 비용 효율적이며, 기존 Aurora 클러스터의 추가 구성으로 간단히 설정할 수 있습니다.

---

■ Question #865

회사의 거의 실시간 스트리밍 애플리케이션이 AWS에서 실행 중입니다. 데이터가 수집되면 데이터에서 작업이 실행되고 완료하는 데 30분이 걸립니다. 작업 부하에는 들어오는 데이터가 많아 지연 시간이 길어지는 경우가 많습니다. 솔루션 아키텍트는 성능을 향상시키기 위해 확장 가능하고 서버리스 솔루션을 설계해야 합니다.

솔루션 아키텍트는 어떤 단계 조합을 취해야 합니까? (두 가지 선택)

A. Amazon Kinesis Data Firehose를 사용하여 데이터를 수집합니다.

B. AWS Lambda와 AWS Step Functions를 사용하여 데이터를 처리합니다.

C. AWS Database Migration Service (AWS DMS)를 사용하여 데이터를 수집합니다.

D. Auto Scaling 그룹의 Amazon EC2 인스턴스를 사용하여 데이터를 처리합니다.

E. AWS Fargate와 Amazon Elastic Container Service (Amazon ECS)를 사용하여 데이터를 처리합니다.

A. Amazon Kinesis Data Firehose를 사용하여 데이터를 수집합니다.
- Amazon Kinesis Data Firehose는 실시간 스트리밍 데이터를 수집하고 데이터를 Amazon S3, Amazon Redshift, Amazon Elasticsearch Service 등의 대상으로 전달할 수 있습니다. 데이터가 거의 실시간으로 수집되고 처리되어야 하는 요구사항에에 가장 적합한 솔루션입니다. Kinesis Data Firehose는 자동으로 확장되며, 실시간으로 대규모의 데이터를 수집하는 데 매우 유용합니다.

 

E. AWS Fargate와 Amazon Elastic Container Service(Amazon ECS)를 사용하여 데이터를 처리합니다.
- AWS Fargate는 서버리스 컨테이너 솔루션으로, 사용자가 인프라를 관리하지 않아도 되고, 데이터 처리 작업의 컴퓨팅 리소스를 자동으로 확장할 수 있습니다. 이를 통해 많은 양의 데이터를 유연하게 처리할 수 있습니다. 작업 부하가 일정한 시간이 소요되며 고정된 시간 안에 처리가 필요하므로, Fargate를 사용한 ECS는 지연 시간을 줄이고 서버리스 방식으로 확장 가능한 환경을 제공합니다.

---

■ Question #866

한 회사가 VPC의 여러 Amazon EC2 인스턴스에서 웹 애플리케이션을 실행합니다. 이 애플리케이션은 Amazon S3 버킷에 민감한 데이터를 써야 합니다. 이 데이터는 퍼블릭 인터넷을 통해 전송할 수 없습니다.

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

A. Amazon S3에 대한 게이트웨이 VPC 엔드포인트를 만듭니다. VPC 경로 테이블에 엔드포인트로 가는 경로를 만듭니다.

B. S3 버킷을 대상으로 하는 내부 네트워크 로드 밸런서를 만듭니다.

C. VPC 내부에 S3 버킷을 배포합니다. VPC 경로 테이블에 버킷으로 가는 경로를 만듭니다.

D. VPC와 S3 지역 엔드포인트 간에 AWS Direct Connect 연결을 만듭니다.

A. Amazon S3에 대한 게이트웨이 VPC 엔드포인트를 만듭니다. VPC 경로 테이블에 엔드포인트로 가는 경로를 만듭니다.

- 게이트웨이 VPC 엔드포인트는 VPC 내부에서 퍼블릭 인터넷을 통하지 않고도 S3와 같은 AWS 서비스에 안전하게 액세스할 수 있는 방법을 제공합니다. VPC 엔드포인트를 사용하면 트래픽이 VPC 내에 머물러 민감한 데이터가 인터넷에 노출되지 않도록 보호할 수 있습니다.

- 게이트웨이 VPC 엔드포인트를 생성하고, 해당 엔드포인트를 VPC 경로 테이블에 추가하면 EC2 인스턴스는 인터넷을 거치지 않고 안전하게 S3 버킷에 데이터를 쓸 수 있습니다.

---

■ Question #867

한 회사가 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용하여 Amazon EC2 인스턴스에서 프로덕션 워크로드를 실행합니다. 솔루션 아키텍트는 현재 EBS 볼륨 비용을 분석하고 최적화를 권장해야 합니다. 권장 사항에는 추정 월별 절감 기회가 포함되어야 합니다.

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

A. Amazon Inspector 보고를 사용하여 최적화를 위한 EBS 볼륨 권장 사항을 생성합니다.

B. AWS Systems Manager 보고를 사용하여 최적화를 위한 EBS 볼륨 권장 사항을 결정합니다.

C. Amazon CloudWatch 메트릭 보고를 사용하여 최적화를 위한 EBS 볼륨 권장 사항을 결정합니다.

D. AWS Compute Optimizer를 사용하여 최적화를 위한 EBS 볼륨 권장 사항을 생성합니다.

D. AWS Compute Optimizer를 사용하여 최적화를 위한 EBS 볼륨 권장 사항을 생성합니다.

- AWS Compute Optimizer는 EBS 볼륨, EC2 인스턴스, Lambda 함수 등의 리소스에 대한 최적화 권장 사항을 제공합니다. 특히, EBS 볼륨에 대해 IOPS 및 스토리지 용량을 분석하여 비용 절감 기회를 식별할 수 있습니다. Compute Optimizer는 리소스 사용 패턴을 분석하고, 이러한 패턴에 따라 비용 절감 가능성을 추정한 권장 사항을 제공합니다. 이를 통해 추정 월별 절감 기회를 포함한 비용 최적화 전략을 제시할 수 있습니다.

---

■ Question #868

글로벌 기업이 AWS에서 워크로드를 실행합니다. 이 회사의 애플리케이션은 민감한 데이터 저장 및 분석을 위해 AWS 리전에서 Amazon S3 버킷을 사용합니다. 이 회사는 매일 여러 S3 버킷에 수백만 개의 객체를 저장합니다. 이 회사는 버전 관리가 활성화되지지않은 모든 S3 버킷을 식별하려고 합니다.

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

B. Amazon S3 Storage Lens를 사용하여 리전에서 버전 관리가 활성화되지 않은 모든 S3 버킷을 식별합니다.

C. IAM Access Analyzer for S3를 사용하여 리전에서 버전 관리가 활성화되지 않은 모든 S3 버킷을 식별합니다.

D. S3 다중 리전 액세스 포인트를 생성하여 리전에서 버전 관리가 활성화되지 않은 모든 S3 버킷을 식별합니다.

B. Amazon S3 Storage Lens를 사용하여 리전에서 버전 관리가 활성화되지 않은 모든 S3 버킷을 식별합니다.

- Amazon S3 Storage Lens는 S3 스토리지 사용량과 활동에 대한 메트릭과 인사이트를 제공하는 기능입니다. 이를 통해 버킷 및 객체 수준에서 사용량 통계와 보안 설정을 모니터링할 수 있습니다. Storage Lens는 버전 관리 상태와 같은 중요한 버킷 속성에 대한 정보를 제공할 수 있습니다. 따라서, S3 Storage Lens를 사용하면 버전 관리가 활성화되지 않은 S3 버킷을 쉽게 식별할 수 있습니다.

---

■ Question #869

한 회사가 AWS에 배포된 전자상거래 주문 처리 애플리케이션을 개선하고자 합니다. 이 애플리케이션은 예측할 수 없는 트래픽 급증 시 고객 경험에 영향을 미치지 않고 각 주문을 정확히 한 번만 처리해야 합니다.

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

A. Amazon Simple Queue Service(Amazon SQS) FIFO 대기열을 만듭니다. 모든 주문을 SQS 대기열에 넣습니다. AWS Lambda 함수를 대상으로 구성하여 주문을 처리합니다.

B. Amazon Simple Notification Service(Amazon SNS) 표준 주제를 만듭니다. 모든 주문을 SNS 표준 주제에 게시합니다. 애플리케이션을 알림 대상으로 구성합니다.

C. Amazon AppFlow를 사용하여 흐름을 만듭니다. 주문을 흐름으로 보냅니다. AWS Lambda 함수를 대상으로 구성하여 주문을 처리합니다.

D. 애플리케이션에서 AWS X-Ray를 구성하여 주문 요청을 추적합니다. Amazon CloudWatch에서 주문을 가져와서 주문을 처리하도록 애플리케이션을 구성합니다.

A. Amazon Simple Queue Service(Amazon SQS) FIFO 대기열을 만듭니다. 모든 주문을 SQS 대기열에 넣습니다. AWS Lambda 함수를 대상으로 구성하여 주문을 처리합니다.

- Amazon SQS FIFO 대기열은 메시지가 정확히 한 번만 전달되도록 보장하며, 메시지의 순서가 보존됩니다. 이는 주문 처리와 같은 중요 작업에 매우 적합합니다. 주문이 예측할 수 없는 트래픽 급증 시에도 순서대로 정확히 한 번만 처리되어야 하는 요구사항을 충족합니다.
- AWS Lambda를 사용하면 서버리스 환경에서 자동으로 확장되며, 주문이 들어올 때마다 Lambda 함수를 실행할 수 있습니다. 이를 통해 주문을 적시에 처리할 수 있고, 트래픽의 증가에도 자동으로 대응할 수 있습니다.

---

■ Question #870

회사에 프로덕션 및 개발이라는 두 개의 AWS 계정이 있습니다. 이 회사는 개발 계정의 코드 변경 사항을 프로덕션 계정으로 푸시해야 합니다. 알파 단계에서는 개발팀의 두 명의 선임 개발자만 프로덕션 계정에 액세스할 수 있습니다. 베타 단계에서는 더 많은 개발자가 테스트를 수행하기 위해 액세스해야 합니다.

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

A. 각 계정에서 AWS Management Console을 사용하여 두 개의 정책 문서를 만듭니다. 액세스가 필요한 개발자에게 정책을 할당합니다.

B. 개발 계정에서 IAM 역할을 만듭니다. IAM 역할에 프로덕션 계정에 대한 액세스 권한을 부여합니다. 개발자가 역할을 맡을 수 있도록 허용합니다.

C. 프로덕션 계정에서 IAM 역할을 만듭니다. 개발 계정을 지정하는 신뢰 정책을 정의합니다. 개발자가 역할을 맡을 수 있도록 허용합니다.

D. 프로덕션 계정에서 IAM 그룹을 만듭니다. 프로덕션 계정을 지정하는 신뢰 정책에서 그룹을 주체로 추가합니다. 개발자를 그룹에 추가합니다.

C. 프로덕션 계정에서 IAM 역할을 만듭니다. 개발 계정을 지정하는 신뢰 정책을 정의합니다. 개발자가 역할을 맡을 수 있도록 허용합니다.
- 역할 기반 접근 제어: AWS의 모범 사례에 따르면, 프로덕션 계정에서 IAM 역할을 생성하고, 해당 역할에 대한 신뢰 정책으로 개발 계정을 지정하면, 개발 계정의 사용자가 프로덕션 계정의 리소스에 접근할 수 있습니다. 이는 중앙에서 접근 권한을 제어할 수 있도록 하며, 개발 계정에서 프로덕션으로의 액세스를 관리할 수 있게 합니다.

- 액세스 제한 가능: 알파 단계에서는 선임 개발자에게만 역할을 맡도록 제한하고, 베타 단계에서는 신뢰 정책을 수정하거나 필요한 권한을 부여하여 더 많은 개발자가 테스트에 접근할 수 있도록 할 수 있습니다.

- 보안성 강화: 프로덕션 계정에서 역할을 생성하고 개발 계정을 신뢰 주체로 지정하면, 개발자들이 프로덕션 리소스에 직접적으로 접근하지 않고, 대신 역할을 통해 필요한 시점에 접근 권한을 가질 수 있습니다.

---

■ Question #871

회사에서 웹 애플리케이션의 콘텐츠에 대한 액세스를 제한하려고 합니다. 이 회사는 AWS에서 제공하는 권한 부여 기술을 사용하여 콘텐츠를 보호해야 합니다. 또한 로그인 지연 시간이 짧은 권한 부여 및 인증을 위한 서버리스 아키텍처를 구현하려고 합니다. 솔루션은 웹 애플리케이션과 통합되어 웹 콘텐츠를 전 세계적으로 제공해야 합니다. 이 애플리케이션은 현재 사용자 기반이 작지만 이 회사는 애플리케이션의 사용자 기반이 증가할 것으로 예상합니다.

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

A. 인증을 위해 Amazon Cognito를 구성합니다. 권한을 위해 Lambda@Edge를 구현합니다. 웹 애플리케이션을 전 세계적으로 제공하도록 Amazon CloudFront를 구성합니다.

B. 인증을 위해 Microsoft Active Directory용 AWS Directory Service를 구성합니다. 권한을 위해 AWS Lambda를 구현합니다. Application Load Balancer를 사용하여 웹 애플리케이션을 전 세계적으로 제공합니다.

C. 인증을 위해 Amazon Cognito를 구성합니다. 권한을 위해 AWS Lambda를 구현합니다. Amazon S3 Transfer Acceleration을 사용하여 웹 애플리케이션을 전 세계적으로 제공합니다.

D. 인증을 위해 Microsoft Active Directory용 AWS Directory Service를 구성합니다. 권한을 위해 Lambda@Edge를 구현합니다. AWS Elastic Beanstalk를 사용하여 웹 애플리케이션을 전 세계적으로 제공합니다.

A. 인증을 위해 Amazon Cognito를 구성합니다. 권한을 위해 Lambda@Edge를 구현합니다. 웹 애플리케이션을 전 세계적으로 제공하도록 Amazon CloudFront를 구성합니다.

- Amazon Cognito를 통한 인증 : Amazon Cognito는 사용자가 웹 애플리케이션에 로그인하고 인증할 수 있는 서버리스 인증 서비스를 제공합니다. 사용자 풀과 권한 풀을 사용하여 사용자 관리를 수행할 수 있으며, 이를 통해 확장 가능한 인증 솔루션을 구축할 수 있습니다. 이는 로그인 지연 시간이 짧고, 사용자 수가 증가해도 자동으로 확장할 수 있는 서버리스 아키텍처를 지원합니다.

- Lambda@Edge를 통한 권한 관리 : Lambda@Edge를 사용하면 Amazon CloudFront 엣지 로케이션에서 실행되어 콘텐츠에 대한 액세스를 제어할 수 있습니다. Lambda@Edge는 전 세계적으로 분산되어 있어, 콘텐츠에 대한 액세스 제어 논리를 구현함으로써 지연 시간을 줄일 수 있습니다. Lambda@Edge를 통해 접근 정책을 정의하고, 특정 콘텐츠에 대한 사용 권한을 제한할 수 있습니다.

- Amazon CloudFront를 통한 전 세계 콘텐츠 제공 : CloudFront는 Amazon의 콘텐츠 전송 네트워크(CDN) 서비스로, 전 세계적으로 웹 애플리케이션 콘텐츠를 캐시하고 빠르게 제공할 수 있습니다. CloudFront를 사용하면 지리적으로 분산된 엣지 로케이션에서 사용자에게 콘텐츠를 제공하여 응답 시간을 최적화할 수 있습니다.

---

■ Question #872

개발팀은 개발, 스테이징 및 프로덕션 환경에 여러 AWS 계정을 사용합니다. 팀원들은 활용도가 낮은 대규모 Amazon EC2 인스턴스를 시작했습니다. 솔루션 아키텍트는 모든 계정에서 대규모 인스턴스가 시작되는 것을 방지해야 합니다.

솔루션 아키텍트는 최소한의 운영 오버헤드로 이 요구 사항을 어떻게 충족할 수 있습니까?

A. 대규모 EC2 인스턴스 시작을 거부하도록 IAM 정책을 업데이트합니다. 모든 사용자에게 정책을 적용합니다.

B. AWS Resource Access Manager에서 대규모 EC2 인스턴스 시작을 방지하는 리소스를 정의합니다.

C. 각 계정에서 대규모 EC2 인스턴스 시작을 거부하는 IAM 역할을 만듭니다. 개발자에게 역할에 대한 IAM 그룹 액세스 권한을 부여합니다.

D. 기본 정책으로 관리 계정의 AWS Organizations에서 조직을 만듭니다. 대규모 EC2 인스턴스 시작을 거부하는 서비스 제어 정책(SCP)을 만들고 AWS 계정에 적용합니다.

D. 기본 정책으로 관리 계정의 AWS Organizations에서 조직을 만듭니다. 대규모 EC2 인스턴스 시작을 거부하는 서비스 제어 정책(SCP)을 만들고 AWS 계정에 적용합니다.
- 서비스 제어 정책(SCP)의 중앙 집중화된 관리 : 서비스 제어 정책(SCP)은 AWS Organizations를 통해 조직 내 모든 AWS 계정에서 허용할 수 있는 API 동작을 제어합니다. SCP를 사용하면 모든 계정에서 특정 크기 이상의 EC2 인스턴스 시작을 방지할 수 있으며, 이러한 정책은 각 계정의 IAM 정책보다 높은 수준에서 적용됩니다. 이는 중앙에서 쉽게 관리하고 제어할 수 있다는 장점이 있습니다.

- 최소한의 운영 오버헤드 : SCP는 모든 계정에 대한 정책을 일관되게 적용할 수 있으므로, 개별 계정이나 사용자에 대해 IAM 정책을 관리할 필요가 없습니다. 관리 계정에서 한 번 설정한 SCP는 자동으로 조직의 모든 계정에 적용되므로 운영 오버헤드가 적습니다.

- 안전하고 신뢰할 수 있는 접근 방법 : SCP를 통해 특정 인스턴스 유형의 시작을 거부함으로써, 실수로 또는 의도치 않게 비용이 많이 드는 대규모 인스턴스를 시작하는 위험을 줄일 수 있습니다. SCP는 모든 계정과 사용자에게 일관된 정책을 제공하므로 보다 안전한 접근 방식을 제공합니다.

---

■ Question #873

한 회사에서 수백 대의 온프레미스 가상 머신(VM)을 Amazon EC2 인스턴스로 마이그레이션했습니다. 인스턴스는 여러 Linux 배포판과 함께 다양한 Windows Server 버전을 실행합니다. 이 회사는 운영 체제의 인벤토리와 업데이트를 자동화하는 솔루션을 원합니다. 또한 이 회사는 정기적인 월별 검토를 위해 각 인스턴스의 일반적인 취약성 요약이 필요합니다.

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

A. 모든 EC2 인스턴스를 관리하도록 AWS Systems Manager Patch Manager를 설정합니다. 월별 보고서를 생성하도록 AWS Security Hub를 구성합니다.

B. 모든 EC2 인스턴스를 관리하도록 AWS Systems Manager Patch Manager를 설정합니다. Amazon Inspector를 배포하고 월별 보고서를 구성합니다.

C. AWS Shield Advanced를 설정하고 월별 보고서를 구성합니다. EC2 인스턴스에서 패치 설치를 자동화하도록 AWS Config를 배포합니다.

D. 모든 EC2 인스턴스를 모니터링하도록 계정에서 Amazon GuardDuty를 설정합니다. EC2 인스턴스에서 패치 설치를 자동화하도록 AWS Config를 배포합니다.

B. 모든 EC2 인스턴스를 관리하도록 AWS Systems Manager Patch Manager를 설정합니다. Amazon Inspector를 배포하고 월별 보고서를 구성합니다.
- AWS Systems Manager Patch Manager는 EC2 인스턴스의 운영 체제에 대한 패치 관리를 자동화하는 서비스입니다. 이를 사용하면 Linux 및 Windows 운영 체제에 대한 패치 적용을 자동으로 설정하고 관리할 수 있습니다. 또한 Patch Manager는 관리자가 패치 그룹을 구성하여 특정 패치 적용 일정을 관리할 수 있도록 도와줍니다.
- Amazon Inspector는 EC2 인스턴스를 분석하여 보안 취약성 및 모범 사례 준수 여부를 평가합니다. 이를 통해 모든 EC2 인스턴스의 취약성을 정기적으로 스캔하고, 월별 요약 보고서를 생성할 수 있습니다. 이러한 보고서는 정기적인 검토에 필요한 보안 요약 정보를 제공합니다.

---

■ Question #874

한 회사가 AWS 클라우드에서 애플리케이션을 호스팅합니다. 이 애플리케이션은 Elastic Load Balancing(ELB) 로드 밸런서 뒤에 있는 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행됩니다. 이 애플리케이션은 Amazon DynamoDB 테이블에 연결됩니다. 재해 복구(DR) 목적으로 이 회사는 최소한의 다운타임으로 다른 AWS 지역에서 애플리케이션을 사용할 수 있도록 하려고 합니다.

어떤 솔루션이 이러한 요구 사항을 최소한의 다운타임으로 충족할까요?

A. DR 지역에서 Auto Scaling 그룹과 ELB를 만듭니다. DynamoDB 테이블을 글로벌 테이블로 구성합니다. DNS 장애 조치를 구성하여 새 DR 지역의 ELB를 가리킵니다.

B. AWS CloudFormation 템플릿을 만들어 필요할 때 시작할 EC2 인스턴스, ELB 및 DynamoDB 테이블을 만듭니다. DNS 장애 조치를 구성하여 새 DR 지역의 ELB를 가리킵니다.

C. AWS CloudFormation 템플릿을 만들어 필요할 때 시작할 EC2 인스턴스와 ELB를 만듭니다. DynamoDB 테이블을 글로벌 테이블로 구성합니다. DNS 장애 조치를 구성하여 새 DR 지역의 ELB를 가리킵니다.

D. DR 지역에서 자동 확장 그룹과 ELB를 만듭니다. DynamoDB 테이블을 글로벌 테이블로 구성합니다. 평가 기간이 10분인 Amazon CloudWatch 알람을 만들어 Amazon Route 53을 업데이트하여 DR 지역의 ELB를 가리키도록 AWS Lambda 함수를 호출합니다.

A. DR 지역에서 Auto Scaling 그룹과 ELB를 만듭니다. DynamoDB 테이블을 글로벌 테이블로 구성합니다. DNS 장애 조치를 구성하여 새 DR 지역의 ELB를 가리킵니다.

- Auto Scaling 그룹 및 ELB의 사전 구성 : DR 지역에 Auto Scaling 그룹과 ELB를 사전에 구성함으로써, DR 시나리오가 발생했을 때 EC2 인스턴스가 빠르게 확장되며 ELB가 트래픽을 분산할 수 있습니다. EC2 인스턴스가 DR 시나리오에서 필요할 때만 시작되도록 하여, 비용도 절약할 수 있습니다.
- DynamoDB 글로벌 테이블 : DynamoDB 글로벌 테이블을 사용하면 여러 지역 간에 DynamoDB 테이블의 데이터를 자동으로 복제할 수 있습니다. 이를 통해 DR 지역의 DynamoDB 인스턴스가 항상 최신 데이터를 가지고 있어, 애플리케이션이 지역 장애 발생 시에도 최신 데이터에 접근할 수 있습니다.
- DNS 장애 조치 : Route 53의 DNS 장애 조치를 구성하면, DR 시나리오가 발생했을 때 자동으로 DR 지역의 ELB를 가리키도록 할 수 있습니다. 이를 통해 애플리케이션 트래픽을 새로운 지역으로 신속하게 전환할 수 있습니다.

---

■ Question #875

한 회사가 프라이빗 서브넷의 Amazon EC2 인스턴스에서 애플리케이션을 실행합니다. 이 애플리케이션은 Amazon S3 버킷에 데이터를 저장하고 검색해야 합니다. 규정 요구 사항에 따라 데이터는 퍼블릭 인터넷을 통과해서는 안 됩니다.

솔루션 아키텍트는 이러한 요구 사항을 가장 비용 효율적으로 충족하기 위해 무엇을 해야 합니까?

A. S3 버킷에 액세스하기 위해 NAT 게이트웨이를 배포합니다.

B. S3 버킷에 액세스하기 위해 AWS Storage Gateway를 배포합니다.

C. S3 버킷에 액세스하기 위해 S3 인터페이스 엔드포인트를 배포합니다.

D. S3 버킷에 액세스하기 위해 S3 게이트웨이 엔드포인트를 배포합니다.

D. S3 버킷에 액세스하기 위해 S3 게이트웨이 엔드포인트를 배포합니다.

- S3 게이트웨이 엔드포인트는 VPC 내에서 Amazon S3에 대한 트래픽을 퍼블릭 인터넷을 통하지 않고, AWS 네트워크 내에서 직접 라우팅합니다. 이를 통해 보안 요구 사항을 충족하면서도 비용을 절감할 수 있습니다.

- 게이트웨이 엔드포인트는 VPC에서 S3에 접근하기 위해 사용되며, 추가적인 요금 없이 제공됩니다. 이를 통해 VPC의 경로 테이블에 S3로 가는 경로를 추가하여 데이터를 안전하게 전송할 수 있습니다.

---

■ Question #876

한 회사가 단일 가용 영역에서 실행되는 Amazon EC2 인스턴스에 애플리케이션을 호스팅합니다. 이 애플리케이션은 OSI (Open Systems Interconnection) 모델의 전송 계층을 사용하여 액세스할 수 있습니다. 이 회사는 고가용성을 위해 애플리케이션 아키텍처가 필요합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 단계 조합은 무엇입니까? (두 가지를 선택하세요.)

A. 다른 가용 영역에서 새 EC2 인스턴스를 구성합니다. Amazon Route 53을 사용하여 모든 인스턴스로 트래픽을 라우팅합니다.

B. EC2 인스턴스 앞에 네트워크 로드 밸런서를 구성합니다.

C. 인스턴스로의 TCP 트래픽을 위한 네트워크 로드 밸런서를 구성합니다. 인스턴스로의 HTTP 및 HTTPS 트래픽을 위한 애플리케이션 로드 밸런서를 구성합니다.

D. EC2 인스턴스에 대한 자동 확장 그룹을 만듭니다. 여러 가용 영역을 사용하도록 자동 확장 그룹을 구성합니다. 인스턴스에서 애플리케이션 상태 검사를 실행하도록 자동 확장 그룹을 구성합니다.

E. Amazon CloudWatch 알람을 만듭니다. 중지된 상태로 전환되는 EC2 인스턴스를 다시 시작하도록 알람을 구성합니다.

B. EC2 인스턴스 앞에 네트워크 로드 밸런서를 구성합니다.

D. EC2 인스턴스에 대한 자동 확장 그룹을 만듭니다. 여러 가용 영역을 사용하도록 자동 확장 그룹을 구성합니다. 인스턴스에서 애플리케이션 상태 검사를 실행하도록 자동 확장 그룹을 구성합니다.

 

- 네트워크 로드 밸런서 (B)는 OSI 모델의 전송 계층(TCP/UDP)을 지원하며, 고성능 및 짧은 대기 시간이 중요한 애플리케이션에 적합합니다. 네트워크 로드 밸런서는 인스턴스의 트래픽을 고가용성으로 분산할 수 있는 효율적인 방법입니다.
- 자동 확장 그룹 (D)은 다중 가용 영역(AZ)에 인스턴스를 분산 배치하여 고가용성을 보장합니다. 자동 확장 그룹은 인스턴스가 실패하거나 특정 임계값을 초과할 때 인스턴스를 자동으로 시작하거나 조정할 수 있습니다. 이를 통해 단일 장애 지점을 제거하고 애플리케이션의 가용성을 향상시킵니다.

---

■ Question #877

한 회사에서 Amazon S3를 사용하여 정적 웹사이트를 호스팅합니다. 이 회사는 웹페이지에 연락처 양식을 추가하려고 합니다. 연락처 양식에는 사용자가 이름, 이메일 주소, 전화번호, 사용자 메시지를 입력할 수 있는 동적 서버 측 구성 요소가 있습니다. 이 회사는 매달 100건 미만의 사이트 방문을 예상합니다. 연락처 양식은 고객이 양식을 작성하면 이메일로 회사에 알려야 합니다.

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

A. Amazon Elastic Container Service(Amazon ECS)에서 동적 연락처 양식을 호스팅합니다. Amazon Simple Email Service (Amazon SES)를 설정하여 타사 이메일 공급자에 연결합니다.

B. AWS Lambda 함수에서 연락처 양식을 반환하는 Amazon API Gateway 엔드포인트를 만듭니다. API Gateway에서 다른 Lambda 함수를 구성하여 Amazon Simple Notification Service(Amazon SNS) 주제에 메시지를 게시합니다.

C. 정적 콘텐츠 및 동적 콘텐츠에 AWS Amplify Hosting을 사용하여 웹사이트를 호스팅합니다. 서버 측 스크립팅을 사용하여 연락처 양식을 빌드합니다. Amazon Simple Queue Service(Amazon SQS)를 구성하여 회사에 메시지를 전달합니다.

D. Amazon S3에서 Windows Server를 실행하는 Amazon EC2 인스턴스로 웹사이트를 마이그레이션합니다. Windows Server용 인터넷 정보 서비스 (IIS)를 사용하여 웹페이지를 호스팅합니다. 클라이언트 측 스크립팅을 사용하여 연락처 양식을 작성합니다. 양식을 Amazon WorkMail과 통합합니다.

B. AWS Lambda 함수에서 연락처 양식을 반환하는 Amazon API Gateway 엔드포인트를 만듭니다. API Gateway에서 다른 Lambda 함수를 구성하여 Amazon Simple Notification Service(Amazon SNS) 주제에 메시지를 게시합니다.
- 비용 효율성 : 이 접근 방식은 서버리스 아키텍처를 사용하기 때문에 매달 100건 미만의 트래픽에 대해 매우 낮은 비용으로 운영할 수 있습니다. AWS Lambda와 API Gateway는 사용량 기반의 요금 구조를 가지고 있어, 적은 양의 요청이 있는 경우에 비용이 거의 발생하지 않습니다.
- 유연성 : Amazon API Gateway를 통해 프론트엔드에서 제공하는 연락처 양식 데이터를 쉽게 받을 수 있고, 이를 Lambda 함수로 전달할 수 있습니다. Lambda 함수는 데이터를 처리한 후, Amazon SNS를 통해 회사 이메일로 알림을 보낼 수 있습니다.
- 간편한 설정 : Lambda와 SNS를 사용하여 이메일 전송을 자동화할 수 있으며, 이러한 구성은 유지 보수가 거의 필요하지 않습니다. 또한, API Gateway와 Lambda를 사용한 서버리스 접근 방식은 인프라 관리에 대한 부담을 줄여줍니다.

---

■ Question #878

한 회사가 사업부를 위해 AWS Organizations에 전담 AWS 계정을 만듭니다. 최근에 중요한 알림이 할당된 계정 소유자 대신 사업부 계정의 루트 사용자 이메일 주소로 전송되었습니다. 이 회사는 모든 향후 알림을 청구, 운영 또는 보안의 알림 범주에 따라 다른 직원에게 보낼 수 있도록 하려고 합니다.

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

A. 각 AWS 계정이 회사에서 관리하는 단일 이메일 주소를 사용하도록 구성합니다. 모든 계정 소유자가 이메일 계정에 액세스하여 알림을 받을 수 있는지 확인합니다. 각 AWS 계정의 대체 연락처를 각 사업부의 청구 팀, 보안 팀 및 운영 팀에 해당하는 배포 목록으로 구성합니다.

B. 각 AWS 계정이 회사가 관리하는 각 사업부에 다른 이메일 배포 목록을 사용하도록 구성합니다. 알림에 응답할 수 있는 관리자 이메일 주소로 각 배포 목록을 구성합니다. 각 AWS 계정의 대체 연락처를 각 사업부의 청구 팀, 보안 팀 및 운영 팀에 해당하는 배포 목록으로 구성합니다.

C. 각 AWS 계정 루트 사용자 이메일 주소를 각 사업부의 한 사람의 개별 회사 관리 이메일 주소로 구성합니다. 각 AWS 계정에 대한 대체 연락처를 구성하고 각 사업부의 청구팀, 보안팀, 운영팀에 대한 해당 배포 목록을 사용합니다.

D. 각 AWS 계정 루트 사용자를 구성하여 중앙 사서함으로 이동하는 이메일 별칭을 사용합니다. 청구팀, 보안팀, 운영팀 각각에 대해 단일 비즈니스 관리 이메일 배포 목록을 사용하여 각 계정에 대한 대체 연락처를 구성합니다.

D. 각 AWS 계정 루트 사용자를 구성하여 중앙 사서함으로 이동하는 이메일 별칭을 사용합니다. 청구팀, 보안팀, 운영팀 각각에 대해 단일 비즈니스 관리 이메일 배포 목록을 사용하여 각 계정에 대한 대체 연락처를 구성합니다.
- 중앙 사서함 관리 : 회사의 모든 AWS 계정에 대한 중요한 알림이 중앙 사서함으로 집중되어 관리됩니다. 이를 통해 한 곳에서 전체 계정을 중앙 집중화하여 모니터링할 수 있습니다. 관리자는 해당 사서함을 통해 전사적으로 알림 상황을 한눈에 파악할 수 있습니다.

- 배포 목록을 통한 역할 분담 : 각 역할(청구, 보안, 운영)에 맞는 단일 비즈니스 관리 이메일 배포 목록을 구성하면 각 역할별로 적절한 팀에게 알림이 전달될 수 있습니다. 이렇게 함으로써 특정 역할별로 대응이 가능해집니다.

- 대체 연락처 구성 : 중앙 사서함과 배포 목록의 조합으로 중요한 알림이 회사 전반에 걸쳐 분산 및 관리됩니다. 이를 통해 특정 담당자 부재 시에도 대응할 수 있는 체계를 만들 수 있습니다.

---

■ Question #879

한 회사가 AWS에서 전자상거래 애플리케이션을 실행합니다. Amazon EC2 인스턴스는 구매를 처리하고 Amazon Aurora PostgreSQL DB 클러스터에 구매 세부 정보를 저장합니다. 고객은 사용량이 가장 많은 시간에 애플리케이션 시간 초과를 경험하고 있습니다. 솔루션 아키텍트는 애플리케이션이 최대 사용량 수요를 충족하도록 확장할 수 있도록 애플리케이션을 재구성해야 합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 작업 조합은 무엇입니까? (두 가지 선택)

A. 처리가 완료될 때까지 구매를 다시 시도하도록 새 EC2 인스턴스의 자동 확장 그룹을 구성합니다. Amazon RDS 프록시를 사용하여 DB 클러스터에 연결하도록 애플리케이션을 업데이트합니다.

B. Aurora PostgreSQL DB 클러스터 앞에 있는 Amazon ElastiCache 클러스터를 사용하도록 애플리케이션을 구성합니다.

C. 구매 요청을 Amazon Simple Queue Service(Amazon SQS) 대기열로 보내도록 애플리케이션을 업데이트합니다. SQS 대기열에서 읽는 새 EC2 인스턴스의 자동 확장 그룹을 구성합니다.

D. 처리가 완료될 때까지 티켓 구매를 다시 시도하도록 AWS Lambda 함수를 구성합니다.

E. 사용 계획으로 Amazon API Gateway REST API를 구성합니다.

A. 처리가 완료될 때까지 구매를 다시 시도하도록 새 EC2 인스턴스의 자동 확장 그룹을 구성합니다. Amazon RDS 프록시를 사용하여 DB 클러스터에 연결하도록 애플리케이션을 업데이트합니다.
- 이점: RDS 프록시는 데이터베이스 연결을 최적화하여 EC2 인스턴스가 증가하는 데이터베이스 연결을 효율적으로 처리하도록 돕습니다. 이는 데이터베이스 연결 관리의 오버헤드를 줄이고 성능을 향상시킵니다. 또한, EC2 인스턴스의 자동 확장은 트래픽 급증을 대비해 인스턴스 수를 조정하여 확장성을 제공합니다.

C. 구매 요청을 Amazon Simple Queue Service(Amazon SQS) 대기열로 보내도록 애플리케이션을 업데이트합니다. SQS 대기열에서 읽는 새 EC2 인스턴스의 자동 확장 그룹을 구성합니다.
- 이점: SQS는 요청을 일시적으로 저장하여 EC2 인스턴스가 처리할 수 있는 속도로 소비할 수 있도록 도와줍니다. 이를 통해 피크 시간 동안 발생하는 트래픽 급증을 관리할 수 있습니다. 또한, 대기열에 있는 메시지는 중복 없이 처리가 가능하도록 FIFO (First-In-First-Out)와 같은 기능을 제공합니다.

---

■ Question #880

AWS Organizations를 사용하는 한 회사가 30개의 다른 AWS 계정에서 150개의 애플리케이션을 실행합니다. 이 회사는 AWS 비용 및 사용 보고서를 사용하여 관리 계정에서 새 보고서를 만들었습니다. 이 보고서는 데이터 수집 계정의 버킷에 복제되는 Amazon S3 버킷으로 전달됩니다. 이 회사의 고위 경영진은 현재 월 초부터 매일 NAT 게이트웨이 비용을 제공하는 사용자 지정 대시보드를 보고 싶어합니다.

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

A. 요청된 테이블 비주얼이 포함된 Amazon QuickSight 대시보드를 공유합니다. AWS DataSync를 사용하여 새 보고서를 쿼리하도록 QuickSight를 구성합니다.

B. 요청된 테이블 비주얼이 포함된 Amazon QuickSight 대시보드를 공유합니다. Amazon Athena를 사용하여 새 보고서를 쿼리하도록 QuickSight를 구성합니다.

C. 요청된 테이블 비주얼이 포함된 Amazon CloudWatch 대시보드를 공유합니다. AWS DataSync를 사용하여 새 보고서를 쿼리하도록 CloudWatch를 구성합니다.

D. 요청된 테이블 비주얼이 포함된 Amazon CloudWatch 대시보드를 공유합니다. Amazon Athena를 사용하여 새 보고서를 쿼리하도록 CloudWatch를 구성합니다.

B. 요청된 테이블 비주얼이 포함된 Amazon QuickSight 대시보드를 공유합니다. Amazon Athena를 사용하여 새 보고서를 쿼리하도록 QuickSight를 구성합니다.
- Amazon QuickSight는 AWS에서 제공하는 완전관리형 비즈니스 인텔리전스(BI) 도구로, 데이터를 시각화하고 사용자 지정 대시보드를 생성하는 데 적합합니다. 회사의 고위 경영진은 매일 NAT 게이트웨이 비용을 확인해야 하므로, 대시보드를 통해 일일 비용을 쉽게 파악할 수 있습니다.

- Amazon Athena는 S3에 저장된 비용 및 사용 데이터를 쿼리하는 데 사용됩니다. Athena는 S3에 있는 데이터를 서버리스 방식으로 쿼리할 수 있어, 보고서 데이터를 신속하게 처리하고 필요한 데이터를 추출할 수 있습니다.
- Amazon QuickSight는 Athena와 통합되어 보고서 데이터를 시각화하는 대시보드를 쉽게 생성할 수 있습니다. 이렇게 하면 매일 자동으로 업데이트된 데이터로 구성된 대시보드를 제공할 수 있습니다.