AWS SAA-C03 Examtopics (461 ~ 480)

by DarkSoul.Story 2024. 12. 20. 21:38

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

■ Question #461

한 회사가 단일 AWS 지역에서 모바일 게임 앱을 개발하고 있습니다. 앱은 Auto Scaling 그룹의 여러 Amazon EC2 인스턴스에서 실행됩니다. 이 회사는 앱 데이터를 Amazon DynamoDB에 저장합니다. 앱은 사용자와 서버 간에 TCP 트래픽과 UDP 트래픽을 사용하여 통신합니다. 이 애플리케이션은 전 세계적으로 사용됩니다. 이 회사는 모든 사용자에게 가능한 가장 낮은 지연 시간을 보장하고자 합니다.

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

A. AWS Global Accelerator를 사용하여 가속기를 만듭니다. Global Accelerator 통합을 사용하고 TCP 및 UDP 포트에서 수신하는 가속기 엔드포인트 뒤에 Application Load Balancer(ALB)를 만듭니다. ALB에 인스턴스를 등록하도록 Auto Scaling 그룹을 업데이트합니다.
B. AWS Global Accelerator를 사용하여 가속기를 만듭니다. Global Accelerator 통합을 사용하고 TCP 및 UDP 포트에서 수신하는 가속기 엔드포인트 뒤에 Network Load Balancer(NLB)를 만듭니다. NLB에 인스턴스를 등록하도록 Auto Scaling 그룹을 업데이트합니다.
C. Amazon CloudFront 콘텐츠 전송 네트워크(CDN) 엔드포인트를 만듭니다. 엔드포인트 뒤에 TCP 및 UDP 포트에서 수신 대기하는 네트워크 로드 밸런서(NLB)를 만듭니다. NLB에 인스턴스를 등록하도록 자동 확장 그룹을 업데이트합니다. NLB를 오리진으로 사용하도록 CloudFront를 업데이트합니다.
D. Amazon CloudFront 콘텐츠 전송 네트워크(CDN) 엔드포인트를 만듭니다. 엔드포인트 뒤에 TCP 및 UDP 포트에서 수신 대기하는 애플리케이션 로드 밸런서(ALB)를 만듭니다. ALB에 인스턴스를 등록하도록 자동 확장 그룹을 업데이트합니다. ALB를 오리진으로 사용하도록 CloudFront를 업데이트합니다.

B. AWS Global Accelerator를 사용하여 가속기를 만듭니다. Global Accelerator 통합을 사용하고 TCP 및 UDP 포트에서 수신하는 가속기 엔드포인트 뒤에 Network Load Balancer(NLB)를 만듭니다. NLB에 인스턴스를 등록하도록 Auto Scaling 그룹을 업데이트합니다.

Global Accelerator
- 전 세계 사용자에게 가까운 네트워크 엔드포인트로 트래픽을 라우팅하여 최저 지연 시간을 보장합니다.
- TCP와 UDP 트래픽 모두를 지원합니다.

Network Load Balancer
- NLB는 TCP와 UDP 트래픽을 모두 지원하며, 게임 앱의 통신 요구 사항을 충족합니다.

효율성
- 이 조합은 개발 및 관리가 간소화된 완전 관리형 AWS 솔루션으로, 요구 사항을 모두 충족합니다.

Global Accelerator와 NLB의 조합은 전 세계적으로 최저 지연 시간을 제공하며, TCP와 UDP 트래픽을 모두 처리할 수 있습니다.

■ Question #462

회사에 고객 주문을 처리하는 애플리케이션이 있습니다. 이 회사는 Amazon Aurora 데이터베이스에 주문을 저장하는 Amazon EC2 인스턴스에서 애플리케이션을 호스팅합니다. 가끔 트래픽이 많을 때 작업 부하가 주문을 충분히 빨리 처리하지 못합니다.

솔루션 아키텍트는 가능한 한 빨리 데이터베이스에 주문을 안정적으로 쓰기 위해 무엇을 해야 합니까?

A. 트래픽이 많을 때 EC2 인스턴스의 인스턴스 크기를 늘립니다. Amazon Simple Notification Service(Amazon SNS)에 주문을 씁니다. 데이터베이스 엔드포인트를 SNS 토픽에 구독합니다.
B. Amazon Simple Queue Service(Amazon SQS) 대기열에 주문을 씁니다. 애플리케이션 로드 밸런서 뒤에 있는 자동 확장 그룹의 EC2 인스턴스를 사용하여 SQS 대기열에서 읽고 데이터베이스로 주문을 처리합니다.
C. Amazon Simple Notification Service(Amazon SNS)에 주문을 씁니다. 데이터베이스 엔드포인트를 SNS 토픽에 구독합니다. 애플리케이션 로드 밸런서 뒤에 있는 자동 확장 그룹의 EC2 인스턴스를 사용하여 SNS 토픽에서 읽습니다.
D. EC2 인스턴스가 CPU 임계값 한계에 도달하면 Amazon Simple Queue Service(Amazon SQS) 대기열에 주문을 씁니다. Application Load Balancer 뒤의 Auto Scaling 그룹에서 EC2 인스턴스의 예약된 스케일링을 사용하여 SQS 대기열에서 읽고 주문을 데이터베이스로 처리합니다.

B. Amazon Simple Queue Service(Amazon SQS) 대기열에 주문을 씁니다. 애플리케이션 로드 밸런서 뒤에 있는 자동 확장 그룹의 EC2 인스턴스를 사용하여 SQS 대기열에서 읽고 데이터베이스로 주문을 처리합니다.

- Amazon SQS: SQS는 주문을 안정적으로 대기열에 저장하며, 메시지 중복 제거와 재처리 메커니즘을 제공합니다.
- Auto Scaling: EC2 인스턴스의 자동 확장은 트래픽 급증 시 주문을 효율적으로 처리할 수 있게 합니다.
- 분리된 처리: 애플리케이션과 데이터베이스 간의 작업을 분리하여 안정성을 높입니다.

- 데이터 안정성: SQS는 주문 데이터를 대기열에 안전하게 저장하며, 메시지 유실을 방지하기 위한 재처리 메커니즘을 제공합니다.
- 확장성: Auto Scaling 그룹과 SQS 대기열의 조합은 트래픽 급증에도 안정적으로 처리할 수 있습니다.
- 운영 효율성: SQS 대기열을 통해 애플리케이션과 데이터베이스 작업을 분리하여 병목현상을 줄이고 효율적으로 처리할 수 있습니다.
- 낮은 복잡성: 이 솔루션은 추가적인 조건 기반 트리거나 복잡한 예약된 스케일링이 필요하지 않아 간단하고 신뢰할 수 있습니다.

■ Question #463

IoT 회사가 사용자의 수면에 대한 데이터를 수집하는 센서가 장착된 매트리스를 출시합니다. 센서는 Amazon S3 버킷으로 데이터를 전송합니다. 센서는 매일 밤 각 매트리스에 대해 약 2MB의 데이터를 수집합니다. 회사는 각 매트리스에 대한 데이터를 처리하고 요약해야 합니다. 결과는 가능한 한 빨리 제공되어야 합니다. 데이터 처리에는 1GB의 메모리가 필요하며 30초 이내에 완료됩니다.

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

A. Scala 작업과 함께 AWS Glue 사용
B. Apache Spark 스크립트와 함께 Amazon EMR 사용
C. Python 스크립트와 함께 AWS Lambda 사용
D. PySpark 작업과 함께 AWS Glue 사용

C. Python 스크립트와 함께 AWS Lambda 사용

- AWS Lambda는 서버리스 컴퓨팅 서비스로, 소량의 데이터를 짧은 시간 내에 처리하기에 적합합니다.
- Lambda 함수는 최대 10GB의 메모리를 지원하며, 이 시나리오의 요구 사항인 1GB 메모리를 충분히 처리할 수 있습니다.
- Lambda는 이벤트 기반으로 실행되며, S3 업로드 이벤트를 트리거로 사용할 수 있습니다.
- 데이터 처리 시간이 30초 이내이며, Lambda의 실행 제한 시간(최대 15분) 내에 충분히 처리 가능합니다.
- 비용: Lambda는 실행한 시간과 메모리 사용량만큼만 비용이 부과되므로, 매우 비용 효율적입니다.

■ Question #464

한 회사가 모든 주문을 Amazon RDS for PostgreSQL Single-AZ DB 인스턴스에 저장하는 온라인 쇼핑 애플리케이션을 호스팅합니다. 경영진은 단일 장애 지점을 제거하고자 하며 솔루션 아키텍트에게 애플리케이션 코드를 변경하지 않고도 데이터베이스 다운타임을 최소화하는 방법을 추천해 달라고 요청했습니다.

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

A. 데이터베이스 인스턴스를 수정하고 Multi-AZ 옵션을 지정하여 기존 데이터베이스 인스턴스를 Multi-AZ 배포로 변환합니다.
B. 새 RDS Multi-AZ 배포를 만듭니다. 현재 RDS 인스턴스의 스냅샷을 찍고 스냅샷으로 새 Multi-AZ 배포를 복원합니다.
C. 다른 가용 영역에 PostgreSQL 데이터베이스의 읽기 전용 복제본을 만듭니다. Amazon Route 53 가중 레코드 세트를 사용하여 요청을 데이터베이스 전체에 분산합니다.
D. RDS for PostgreSQL 데이터베이스를 최소 그룹 크기가 2인 Amazon EC2 Auto Scaling 그룹에 배치합니다. Amazon Route 53 가중 레코드 세트를 사용하여 요청을 인스턴스 전체에 분산합니다.

A. 데이터베이스 인스턴스를 수정하고 Multi-AZ 옵션을 지정하여 기존 데이터베이스 인스턴스를 Multi-AZ 배포로 변환합니다.

- Amazon RDS에서 Single-AZ 인스턴스를 Multi-AZ 배포로 변경하면 데이터베이스를 다른 가용 영역(AZ)에 복제본을 생성하여 고가용성을 제공합니다.
- Multi-AZ 배포는 자동 장애 조치(Failover)를 지원하며, RDS는 장애 발생 시 복제본으로 자동으로 전환합니다.
- 이 과정에서 애플리케이션 코드 변경이 필요하지 않습니다.
- 기존 데이터베이스 인스턴스를 수정하는 작업은 자동화된 방식으로 진행되므로 다운타임이 최소화됩니다.
- 적합성: 애플리케이션 코드 변경 없이 단일 장애 지점을 제거하며, 최소한의 다운타임으로 고가용성을 확보할 수 있습니다.

■ Question #465

한 회사가 고객 요구 사항을 지원하기 위한 애플리케이션을 개발하고 있습니다. 이 회사는 동일한 가용성 영역 내의 여러 Amazon EC2 Nitro 기반 인스턴스에 애플리케이션을 배포하려고 합니다. 또한 이 회사는 애플리케이션에 여러 EC2 Nitro 기반 인스턴스의 여러 블록 스토리지 볼륨에 동시에 쓸 수 있는 기능을 제공하여 더 높은 애플리케이션 가용성을 달성하려고 합니다.

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

A. Amazon Elastic Block Store(Amazon EBS) 다중 연결과 함께 범용 SSD(gp3) EBS 볼륨 사용
B. Amazon Elastic Block Store(Amazon EBS) 다중 연결과 함께 처리량 최적화 HDD(st1) EBS 볼륨 사용
C. Amazon Elastic Block Store(Amazon EBS) 다중 연결과 함께 프로비저닝된 IOPS SSD(io2) EBS 볼륨 사용
D. Amazon Elastic Block Store(Amazon EBS) 다중 연결과 함께 범용 SSD(gp2) EBS 볼륨 사용

요구 사항 분석
- Nitro 기반 EC2 인스턴스에서 애플리케이션을 실행합니다.
- 여러 EC2 인스턴스가 동일한 블록 스토리지에 동시에 쓸 수 있는 기능이 필요합니다.
- 애플리케이션의 가용성을 높이기 위해 EBS 다중 연결 기능(Multi-Attach)을 사용해야 합니다.

EBS Multi-Attach와의 호환성 : EBS Multi-Attach는 Nitro 기반 EC2 인스턴스에서 작동하며, 특정 EBS 볼륨 유형에서만 지원됩니다:

프로비저닝된 IOPS SSD(io2)
- Multi-Attach 기능을 지원하며, 높은 IOPS와 안정적인 성능을 제공합니다.
- 여러 인스턴스에서 동시에 읽기 및 쓰기가 가능합니다.

기타 EBS 볼륨 유형 (gp2, gp3, st1)
- Multi-Attach 기능을 지원하지 않습니다.
- 단일 EC2 인스턴스에만 연결 가능합니다.

C. Amazon Elastic Block Store(Amazon EBS) 다중 연결과 함께 프로비저닝된 IOPS SSD(io2) EBS 볼륨 사용
- Multi-Attach 지원: io2 볼륨은 Multi-Attach를 지원하여 여러 Nitro 기반 EC2 인스턴스에서 동시에 읽기 및 쓰기가 가능합니다.
- 높은 성능: io2는 높은 IOPS와 안정성을 제공하므로 애플리케이션 가용성과 성능을 향상시킵니다.
- Nitro 기반 호환성: Multi-Attach는 Nitro 기반 인스턴스에서만 작동하며, io2는 이를 지원합니다.

■ Question #466

한 회사가 단일 가용성 영역에서 Amazon EC2와 Amazon RDS Multi-AZ DB 인스턴스를 사용하는 상태 없는 2계층 애플리케이션을 설계했습니다. 새로운 회사 경영진은 애플리케이션의 가용성을 높이고자 합니다.

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

A. Multi-AZ EC2 Auto Scaling을 사용하도록 애플리케이션을 구성하고 애플리케이션 로드 밸런서를 만듭니다.
B. EC2 인스턴스의 스냅샷을 찍어 다른 AWS 지역으로 보내도록 애플리케이션을 구성합니다.
C. Amazon Route 53 지연 기반 라우팅을 사용하여 애플리케이션에 요청을 공급하도록 애플리케이션을 구성합니다.
D. 들어오는 요청을 처리하고 Multi-AZ 애플리케이션 로드 밸런서를 만드는 Amazon Route 53 규칙을 구성합니다.

경영진은 애플리케이션의 가용성을 높이는 것을 요구하고 있습니다. 이 요구 사항을 충족하려면 다음을 고려해야 합니다.

- 단일 가용성 영역의 단점 제거: 단일 AZ에서만 실행 중인 EC2 인스턴스는 가용성 영역 장애 시 애플리케이션이 중단될 위험이 있습니다. 이를 해결하기 위해 EC2 인스턴스를 여러 AZ에 배포해야 합니다.
- 로드 밸런싱: 여러 AZ에 배포된 인스턴스 간에 요청을 분산하여 가용성을 높이고 부하를 관리해야 합니다.
- 기존 Multi-AZ RDS 활용: 데이터베이스는 이미 Multi-AZ로 설정되어 있어 가용성이 높습니다. 따라서 애플리케이션 계층에서 Multi-AZ 구성이 필요합니다.

A. Multi-AZ EC2 Auto Scaling을 사용하도록 애플리케이션을 구성하고 애플리케이션 로드 밸런서를 만듭니다.

Multi-AZ EC2 Auto Scaling
- EC2 인스턴스를 여러 AZ에 걸쳐 배포하여 단일 AZ 장애를 방지할 수 있습니다.
- Auto Scaling은 트래픽 부하에 따라 EC2 인스턴스를 자동으로 조정합니다.

Application Load Balancer (ALB)
- ALB는 여러 AZ에 걸쳐 배포된 EC2 인스턴스 간에 요청을 분산하여 가용성을 높입니다.

적합성
- 이 옵션은 애플리케이션 계층에서 가용성을 높이는 가장 효율적인 방법입니다.
- Multi-AZ 구성을 통해 단일 AZ 장애를 방지하고, 로드 밸런서를 통해 요청을 효과적으로 분산할 수 있습니다.

■ Question #467

한 회사가 AWS Organizations를 사용합니다. 멤버 계정이 Compute Savings Plan을 구매했습니다. 멤버 계정 내 워크로드가 변경되어 더 이상 Compute Savings Plan 약정의 전체 혜택을 받지 못합니다. 이 회사는 구매한 컴퓨팅 파워의 50% 미만을 사용합니다.

A. Compute Savings Plan을 구매한 회원 계정의 계정 콘솔의 청구 기본 설정 섹션에서 할인 공유를 켭니다.
B. 회사 조직 관리 계정의 계정 콘솔에 있는 청구 기본 설정 섹션에서 할인 공유를 켭니다.
C. 다른 AWS 계정에서 Compute Savings Plan이 있는 계정으로 추가 컴퓨팅 워크로드를 마이그레이션합니다.
D. Reserved Instance Marketplace에서 초과 저축 플랜 약정을 판매합니다.

AWS Organizations에서 Savings Plan 또는 Reserved Instance를 활용하려면 할인 공유 기능이 활성화되어야 합니다. 조직 관리 계정에서 이 설정을 활성화하면 Savings Plan 혜택이 조직 내 모든 멤버 계정으로 공유되어 미사용 약정을 최대한 활용할 수 있습니다.

B. 회사 조직 관리 계정의 계정 콘솔에 있는 청구 기본 설정 섹션에서 할인 공유를 켭니다.

- AWS Organizations에서는 Savings Plan 할인을 조직 전체로 공유하려면 관리 계정에서 할인 공유(Billing Preferences)를 활성화해야 합니다.
- 이를 통해 남은 약정이 다른 계정의 워크로드에 적용될 수 있습니다.

■ Question #468

어떤 회사가 고객에게 검색 카탈로그를 제공하는 마이크로서비스 애플리케이션을 개발하고 있습니다. 이 회사는 REST API를 사용하여 애플리케이션의 프런트엔드를 사용자에게 제공해야 합니다. REST API는 회사가 프라이빗 VPC 서브넷의 컨테이너에서 호스팅하는 백엔드 서비스에 액세스해야 합니다.

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

A. Amazon API Gateway를 사용하여 WebSocket API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service (Amazon ECS)에서 애플리케이션을 호스팅합니다. API Gateway가 Amazon ECS에 액세스할 수 있도록 프라이빗 VPC 링크를 만듭니다.
B. Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service (Amazon ECS)에서 애플리케이션을 호스팅합니다. API Gateway가 Amazon ECS에 액세스할 수 있도록 프라이빗 VPC 링크를 만듭니다.
C. Amazon API Gateway를 사용하여 WebSocket API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service (Amazon ECS)에서 애플리케이션을 호스팅합니다. API Gateway가 Amazon ECS에 액세스할 수 있도록 보안 그룹을 만듭니다.
D. Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service (Amazon ECS)에서 애플리케이션을 호스팅합니다. API Gateway가 Amazon ECS에 액세스할 수 있도록 보안 그룹을 만듭니다.

이 시나리오의 주요 요구 사항은 다음과 같습니다.

- REST API를 통해 프런트엔드를 사용자에게 제공해야 함
- API는 프라이빗 VPC 서브넷에서 실행 중인 백엔드 서비스(컨테이너 기반)에 액세스해야 함
- 백엔드와 API Gateway 간 연결은 VPC 내에서 안전하게 이루어져야 함

B. Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service (Amazon ECS)에서 애플리케이션을 호스팅합니다. API Gateway가 Amazon ECS에 액세스할 수 있도록 프라이빗 VPC 링크를 만듭니다.

- REST API: API Gateway를 사용하여 REST API를 설계하면 사용자 요청을 처리할 수 있습니다.
- 프라이빗 VPC 링크: API Gateway는 프라이빗 VPC 링크를 통해 ECS의 프라이빗 서브넷에 안전하게 액세스할 수 있습니다.
- 안전한 통신: VPC 링크는 API Gateway와 ECS 간의 트래픽을 안전하고 직접적으로 라우팅합니다.

■ Question #469

한 회사가 수집한 원시 데이터를 Amazon S3 버킷에 저장합니다. 이 데이터는 회사 고객을 대신하여 여러 유형의 분석에 사용됩니다. 요청된 분석 유형에 따라 S3 객체의 액세스 패턴이 결정됩니다.

회사는 액세스 패턴을 예측하거나 제어할 수 없습니다. 회사는 S3 비용을 줄이고자 합니다.

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

A. S3 복제를 사용하여 드물게 액세스되는 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환합니다.
B. S3 Lifecycle 규칙을 사용하여 S3 Standard에서 Standard-Infrequent Access(S3 Standard-IA)로 객체를 전환합니다.
C. S3 Lifecycle 규칙을 사용하여 S3 Standard에서 S3 Intelligent-Tiering으로 객체를 전환합니다.
D. S3 인벤토리를 사용하여 S3 Standard에서 S3 Intelligent-Tiering으로 액세스되지 않은 객체를 식별하고 전환합니다.

요구 사항을 충족해야 합니다.
- 액세스 패턴이 예측 불가: S3 객체가 자주 또는 드물게 액세스될지 사전에 알 수 없습니다.
- S3 비용 절감: 객체 저장 비용을 줄이고 싶습니다.
- 자동화된 전환: 회사는 수동으로 액세스 패턴을 관리하거나 예측할 필요가 없어야 합니다.

C. S3 Lifecycle 규칙을 사용하여 S3 Standard에서 S3 Intelligent-Tiering으로 객체를 전환합니다.

- Amazon S3 Intelligent-Tiering는 AWS에서 제공하는 비용 최적화 스토리지 클래스로, 액세스 패턴이 변동하는 데이터를 자동으로 관리하여 스토리지 비용을 줄여줍니다. 이 스토리지 클래스는 데이터의 액세스 빈도를 지속적으로 모니터링하고, 액세스 패턴에 따라 적절한 비용-성능 최적화 스토리지 계층으로 데이터를 자동으로 이동시킵니다.
- S3 Intelligent-Tiering은 객체의 액세스 패턴을 모니터링하여 자주 액세스되는 데이터는 Standard Tier에, 드물게 액세스되는 데이터는 Infrequent Access Tier에 자동으로 전환합니다.
- 액세스 패턴이 변하더라도 자동으로 최적의 비용을 유지합니다.
- 비용 절감 효과: 자주 액세스되지 않는 데이터를 자동으로 IA Tier로 전환하여 비용을 절감합니다.
- 자동화된 관리: 액세스 패턴을 사전에 알 필요가 없습니다.

■ Question #470

한 회사에 IPv6 주소가 있는 Amazon EC2 인스턴스에 호스팅된 애플리케이션이 있습니다. 애플리케이션은 인터넷을 사용하여 다른 외부 애플리케이션과 통신을 시작해야 합니다. 그러나 회사의 보안 정책에 따르면 외부 서비스는 EC2 인스턴스에 연결을 시작할 수 없습니다.

솔루션 아키텍트는 이 문제를 해결하기 위해 무엇을 권장해야 합니까?

A. NAT 게이트웨이를 생성하고 이를 서브넷의 경로 테이블의 목적지로 만듭니다.
B. 인터넷 게이트웨이를 생성하고 이를 서브넷의 경로 테이블의 목적지로 만듭니다.
C. 가상 사설 게이트웨이를 생성하고 이를 서브넷의 경로 테이블의 목적지로 만듭니다.
D. 이그레스 전용 인터넷 게이트웨이를 생성하고 이를 서브넷 경로 테이블의 목적지로 만듭니다.

요구 사항은 다음과 같습니다.
- EC2 인스턴스는 외부 애플리케이션에 연결 가능해야 함 : EC2 인스턴스에서 외부 애플리케이션으로 아웃바운드 연결을 시작할 수 있어야 합니다.
- 외부 서비스는 EC2 인스턴스에 연결할 수 없어야 함 : 회사의 보안 정책에 따라 인바운드 연결이 차단되어야 합니다.
- IPv6 환경 : 애플리케이션이 IPv6 주소를 사용하므로 IPv6 환경을 지원해야 합니다.

D. 이그레스 전용 인터넷 게이트웨이를 생성하고 이를 서브넷 경로 테이블의 목적지로 만듭니다.

- 이그레스 전용 인터넷 게이트웨이는 IPv6 주소를 가진 인스턴스가 인터넷으로 아웃바운드 트래픽을 전송할 수 있도록 허용합니다.
- 동시에 인바운드 연결을 차단하여 외부 서비스가 EC2 인스턴스에 연결을 시작할 수 없도록 보장합니다.
- IPv6 환경에 적합하며, 회사의 보안 정책을 충족합니다.

■ Question #471

한 회사가 VPC의 컨테이너에서 실행되는 애플리케이션을 만들고 있습니다. 이 애플리케이션은 Amazon S3 버킷에 데이터를 저장하고 액세스합니다. 개발 단계에서 이 애플리케이션은 매일 Amazon S3에 1TB의 데이터를 저장하고 액세스합니다. 이 회사는 비용을 최소화하고 가능한 한 트래픽이 인터넷을 통과하는 것을 방지하고자 합니다.

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

A. S3 버킷에 대해 S3 Intelligent-Tiering 활성화
B. S3 버킷에 대한 S3 전송 가속 활성화
C. Amazon S3에 대한 게이트웨이 VPC 엔드포인트를 만듭니다. 이 엔드포인트를 VPC의 모든 경로 테이블과 연결합니다.
D. VPC에서 Amazon S3에 대한 인터페이스 엔드포인트를 만듭니다. 이 엔드포인트를 VPC의 모든 경로 테이블과 연결합니다.

요구 사항은 다음과 같습니다.
- 비용 최소화 : 데이터를 저장하고 액세스하는 데 드는 비용을 줄이고자 합니다.
- 트래픽이 인터넷을 통과하지 않도록 설정 : 애플리케이션과 S3 간의 트래픽이 VPC 내부에서만 처리되도록 해야 합니다.
- 매일 1TB의 데이터 처리 : 대량 데이터를 효율적으로 처리할 수 있는 솔루션이 필요합니다.

C. Amazon S3에 대한 게이트웨이 VPC 엔드포인트를 만듭니다. 이 엔드포인트를 VPC의 모든 경로 테이블과 연결합니다.

- 게이트웨이 VPC 엔드포인트는 Amazon S3와 DynamoDB에 대한 VPC 내 전용 연결을 제공합니다.
- 트래픽이 인터넷을 통과하지 않으며, VPC 내부에서 직접 처리됩니다.
- S3와의 통신은 데이터 전송 비용이 발생하지 않습니다(인터넷 게이트웨이 사용 없이 처리).
- 추가 비용 없이 설정 가능하며, 대량 데이터를 처리하는 애플리케이션에 적합합니다.
- 인터넷 트래픽을 방지하고 비용을 최소화합니다.

■ Question #472

한 회사에 Amazon DynamoDB에 기반한 데이터 저장소가 있는 모바일 채팅 애플리케이션이 있습니다. 사용자는 가능한 한 지연 시간이 짧은 새 메시지를 읽고 싶어합니다. 솔루션 아키텍트는 최소한의 애플리케이션 변경이 필요한 최적의 솔루션을 설계해야 합니다.

솔루션 아키텍트는 어떤 방법을 선택해야 합니까?

A. 새로운 메시지 테이블에 대해 Amazon DynamoDB Accelerator(DAX)를 구성합니다. DAX 엔드포인트를 사용하도록 코드를 업데이트합니다.
B. DynamoDB 읽기 복제본을 추가하여 증가된 읽기 부하를 처리합니다. 읽기 복제본의 읽기 엔드포인트를 가리키도록 애플리케이션을 업데이트합니다.
C. DynamoDB의 새 메시지 테이블에 대한 읽기 용량 단위 수를 두 배로 늘립니다. 기존 DynamoDB 엔드포인트를 계속 사용합니다.
D. 애플리케이션 스택에 Amazon ElastiCache for Redis 캐시를 추가합니다. DynamoDB 대신 Redis 캐시 엔드포인트를 가리키도록 애플리케이션을 업데이트합니다.

요구 사항은 다음과 같습니다.
- 지연 시간이 짧은 새 메시지 읽기 : 사용자 경험을 향상시키기 위해 가능한 한 빠르게 데이터를 제공해야 합니다.
- 최소한의 애플리케이션 변경 : 애플리케이션 코드를 최소한으로 수정해야 합니다.

A. 새로운 메시지 테이블에 대해 Amazon DynamoDB Accelerator(DAX)를 구성합니다. DAX 엔드포인트를 사용하도록 코드를 업데이트합니다.

- Amazon DynamoDB Accelerator(DAX)는 DynamoDB의 읽기 성능을 개선하기 위한 인메모리 캐싱 솔루션입니다.
- DAX는 애플리케이션이 DAX 엔드포인트를 통해 DynamoDB 테이블에 연결하도록 지원하며, 애플리케이션 변경이 최소화됩니다.
- 기존 DynamoDB API 호출과 호환되므로 코드 변경이 단순합니다.
- DAX는 읽기 성능을 크게 향상시키며, 낮은 지연 시간으로 새 메시지를 읽는 데 적합합니다.

■ Question #473

한 회사가 Application Load Balancer(ALB) 뒤의 Amazon EC2 인스턴스에서 웹사이트를 호스팅합니다. 이 웹사이트는 정적 콘텐츠를 제공합니다. 웹사이트 트래픽이 증가하고 있으며, 이 회사는 잠재적인 비용 증가에 대해 우려하고 있습니다.

A. 에지 위치에서 상태 파일을 캐시하기 위한 Amazon CloudFront 배포를 생성합니다.
B. Amazon ElastiCache 클러스터를 만듭니다. ALB를 ElastiCache 클러스터에 연결하여 캐시된 파일을 제공합니다.
C. AWS WAF 웹 ACL을 생성하고 ALB와 연결합니다. 정적 파일을 캐시하기 위해 웹 ACL에 규칙을 추가합니다.
D. 대체 AWS 리전에 두 번째 ALB를 만듭니다. 데이터 전송 비용을 최소화하기 위해 사용자 트래픽을 가장 가까운 리전으로 라우팅합니다.

요구 사항 분석
회사는 정적 콘텐츠를 호스팅하는 웹사이트의 트래픽 증가로 인해 발생할 수 있는 비용 증가를 줄이고자 합니다. 해결책은 다음 요구 사항을 충족해야 합니다

- 비용 효율성 : 트래픽 증가로 인한 비용을 최소화해야 합니다.
- 정적 콘텐츠 제공 최적화 : 정적 파일은 캐싱을 통해 효율적으로 제공하여 EC2 인스턴스의 부하를 줄이고 비용을 절감할 수 있어야 합니다.

A. 에지 위치에서 정적 파일을 캐시하기 위한 Amazon CloudFront 배포를 생성합니다.

- Amazon CloudFront는 전 세계 에지 위치에서 콘텐츠를 캐싱하는 CDN(Content Delivery Network) 서비스입니다.
- 정적 파일을 캐싱하여 사용자의 요청을 에지 위치에서 처리하므로, EC2 인스턴스 및 ALB의 부하를 줄이고 비용을 절감할 수 있습니다.
- CloudFront는 정적 콘텐츠 제공에 최적화되어 있으며, 사용자와 가까운 위치에서 파일을 제공하여 성능을 향상시킵니다.
- 정적 콘텐츠 제공을 최적화하고 비용 증가를 줄이는 데 가장 적합합니다.

■ Question #474

한 회사는 다른 지역의 워크로드와 격리된 워크로드를 지원하고 실행하기 위해 AWS 지역에 여러 개의 VPC를 두고 있습니다. 최근 애플리케이션 출시 요구 사항으로 인해 회사의 VPC는 모든 지역의 다른 모든 VPC와 통신해야 합니다.

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

A. VPC 피어링을 사용하여 단일 리전에서 VPC 통신을 관리합니다. 리전 간 VPC 피어링을 사용하여 VPC 통신을 관리합니다.
B. 모든 지역에서 AWS Direct Connect 게이트웨이를 사용하여 여러 지역의 VPC를 연결하고 VPC 통신을 관리합니다.
C. AWS Transit Gateway를 사용하여 단일 지역의 VPC 통신을 관리하고, 여러 지역 간의 Transit Gateway 피어링을 사용하여 VPC 통신을 관리합니다.
D. 모든 지역에서 AWS PrivateLink를 사용하여 지역 간 VPC를 연결하고 VPC 통신을 관리합니다.

요구 사항 분석
회사는 여러 AWS 지역에 걸쳐 있는 VPC 간 통신을 구현하려고 하며, 이를 최소한의 관리 노력으로 수행하려 합니다. 요구 사항은 다음과 같습니다.

- 다중 지역 지원 : 모든 지역의 VPC가 서로 통신할 수 있어야 합니다.
- 관리 최소화 : 복잡한 연결 설정 및 유지 관리 작업을 최소화해야 합니다.
- 확장 가능성 : 새로운 VPC가 추가될 경우, 통신 설정이 복잡해지지 않아야 합니다.

C. AWS Transit Gateway를 사용하여 단일 지역의 VPC 통신을 관리하고, 여러 지역 간의 Transit Gateway 피어링을 사용하여 VPC 통신을 관리합니다.

- AWS Transit Gateway는 여러 VPC를 중앙에서 연결하는 네트워크 허브 역할을 합니다.
- 단일 지역 내에서 VPC를 Transit Gateway로 연결하고, Transit Gateway 피어링을 사용하여 여러 지역 간 통신을 설정할 수 있습니다.
- 새로운 VPC를 추가할 때 기존 Transit Gateway에 간단히 연결할 수 있어 확장성이 뛰어납니다.
- 관리 부담이 낮으며, 모든 트래픽이 중앙 허브를 통해 라우팅됩니다.
- 요구 사항인 다중 지역 지원, 관리 최소화, 확장성을 모두 충족합니다.

■ Question #475

한 회사가 Amazon Elastic Container Service(Amazon ECS)를 사용할 컨테이너화된 애플리케이션을 설계하고 있습니다. 이 애플리케이션은 내구성이 뛰어나고 8시간의 복구 지점 목표(RPO)로 다른 AWS 지역으로 데이터를 복구할 수 있는 공유 파일 시스템에 액세스해야 합니다. 파일 시스템은 지역 내의 각 가용성 영역에 마운트 대상을 제공해야 합니다.

솔루션 아키텍트는 AWS Backup을 사용하여 다른 지역으로의 복제를 관리하려고 합니다.

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

A. 다중 AZ 배포를 갖춘 Windows 파일 서버용 Amazon FSx
B. 다중 AZ 배포를 갖춘 NetApp ONTAP용 Amazon FSx
C. 표준 스토리지 클래스를 갖춘 Amazon Elastic File System(Amazon EFS)
D. OpenZFS용 Amazon FSx

요구 사항 분석
- 컨테이너화된 애플리케이션 : Amazon ECS에서 실행되는 애플리케이션이 파일 시스템에 액세스해야 합니다.
- 내구성 및 복구 가능성 : 데이터는 8시간의 복구 지점 목표(RPO)를 충족하며, 다른 AWS 지역으로 복구할 수 있어야 합니다.
- 다중 AZ 지원 : 파일 시스템은 지역 내 모든 가용성 영역(AZ)에 마운트 대상을 제공해야 합니다.
- AWS Backup을 사용한 복제 : 데이터 복구를 위해 AWS Backup을 사용하여 복제를 관리합니다.

C. 표준 스토리지 클래스를 갖춘 Amazon Elastic File System (Amazon EFS)

- Amazon EFS는 NFS를 기반으로 하며, 다중 AZ 파일 시스템을 제공합니다.
- EFS는 ECS와 원활히 통합되어 컨테이너화된 애플리케이션에 적합합니다.
- AWS Backup과의 통합 및 데이터 복제도 지원합니다.
- 컨테이너화된 애플리케이션과 다중 AZ 지원에 적합하며, AWS Backup을 통한 복제 요구 사항도 충족합니다.

B vs C

B. NetApp ONTAP용 Amazon FSx
- 고성능 NFS 및 SMB 지원.
- 다중 AZ 배포 제공.
- AWS Backup을 통해 복제를 지원.
- 고성능 파일 시스템이 필요한 워크로드에 적합.

C. Amazon EFS
- 완전 관리형 NFS 파일 시스템.
- 다중 AZ 지원.
- AWS Backup을 통해 복제를 지원.
- 컨테이너화된 애플리케이션과 기본적으로 통합 가능.

Amazon EFS는 단순성, 관리 효율성, 그리고 컨테이너화된 워크로드와의 원활한 통합을 제공하며, 이 시나리오에 가장 적합한 선택입니다.

■ Question #476

가까운 미래에 회사가 급속한 성장을 기대하고 있습니다. 솔루션 아키텍트는 AWS에서 기존 사용자를 구성하고 새 사용자에게 권한을 부여해야 합니다. 솔루션 아키텍트는 IAM 그룹을 만들기로 결정했습니다. 솔루션 아키텍트는 부서에 따라 새 사용자를 IAM 그룹에 추가합니다.

새 사용자에게 권한을 부여하는 가장 안전한 추가 작업은 무엇입니까?

A. SCP(서비스 제어 정책)를 적용하여 액세스 권한을 관리합니다.
B. 최소 권한 권한을 가진 IAM 역할을 만듭니다. 역할을 IAM 그룹에 연결합니다.
C. 최소 권한 권한을 부여하는 IAM 정책을 만듭니다. 정책을 IAM 그룹에 연결합니다.
D. IAM 역할을 만듭니다. 최대 권한을 정의하는 권한 경계와 역할을 연결합니다.

요구 사항 분석
- 안전성 : 사용자에게 권한을 부여할 때 최소 권한 원칙을 준수해야 합니다.
- IAM 그룹 : 새 사용자를 부서별 IAM 그룹에 추가하는 방식으로 권한을 관리합니다.
- 확장성 : 회사의 급속한 성장에 대비해 관리가 효율적이어야 합니다.

C. 최소 권한 권한을 부여하는 IAM 정책을 만듭니다. 정책을 IAM 그룹에 연결합니다.

- IAM 정책은 사용자의 작업과 리소스에 대한 액세스를 허용하거나 거부하는 JSON 문서입니다.
- 최소 권한 원칙에 따라 IAM 정책을 설계하고, 이를 IAM 그룹에 연결하면 그룹에 속한 모든 사용자가 정책에 정의된 권한만 가지게 됩니다.
- 정책 변경은 그룹에 자동으로 적용되어 관리가 간단하고 확장성도 뛰어납니다.
- 최소 권한 원칙을 준수하며, IAM 그룹과 잘 통합됩니다.

■ Question #477

그룹은 Amazon S3 버킷을 나열하고 해당 버킷에서 객체를 삭제할 권한이 필요합니다. 관리자가 다음 IAM 정책을 생성하여 버킷에 대한 액세스를 제공하고 해당 정책을 그룹에 적용했습니다. 그룹은 버킷에서 객체를 삭제할 수 없습니다. 회사는 최소 권한 액세스 규칙을 따릅니다.

{
  "Version": "2012-10-17",
	"Statement": [
		{
			"Action": [
				"s3:ListBucket",
				"s3:DeleteObject"
			],
			"Resource": [
				"arn:aws:s3:::bucket-name"
			],
			"Effect": "Allow"
		}
	]
}

솔루션 아키텍트는 버킷 액세스를 수정하기 위해 정책에 어떤 문장을 추가해야 합니까?

{
	"Action": [
		"s3:*Object"
	],
	"Resource": [
		"arn:aws:s3:::bucket-name/*"
	],
	"Effect": "Allow"
}

{
	"Action": [
		"s3:*"
	],
	"Resource": [
		"arn:aws:s3:::bucket-name/*"
	],
	"Effect": "Allow"
}

{
	"Action": [
		"s3:DeleteObject"
	],
	"Resource": [
		"arn:aws:s3:::bucket-name*"
	],
	"Effect": "Allow"
}

{
	"Action": [
		"s3:DeleteObject"
	],
	"Resource": [
		"arn:aws:s3:::bucket-name/*"
	],
	"Effect": "Allow"
}

문제 분석
IAM 정책의 현재 문제는 's3:DeleteObject' 작업에 대한 리소스 ARN이 올바르지 않기 때문입니다.

- 's3:DeleteObject' 작업은 버킷 내의 객체를 대상으로 하므로, 리소스 ARN은 객체 수준을 지정해야 합니다.
- 현재 정책에서 's3:DeleteObject' 작업의 리소스 ARN은 버킷 수준 ARN('arn:aws:s3:::bucket-name')으로 지정되어 있습니다. 이 ARN은 객체 수준 작업에 적합하지 않습니다.

수정 요구 사항
- 버킷의 객체에 대한 ARN을 지정해야 합니다. 이는 버킷 이름 뒤에 '/*'를 추가하여 버킷 내 모든 객체를 나타냅니다. 예: 'arn:aws:s3:::bucket-name/*'

{
	"Action": [
		"s3:DeleteObject"
	],
	"Resource": [
		"arn:aws:s3:::bucket-name/*"
	],
	"Effect": "Allow"
}

- 's3:DeleteObject' 작업만 허용하며, 최소 권한 원칙을 준수합니다.
- 리소스 ARN은 '버킷 내 모든 객체'를 올바르게 지정('arn:aws:s3:::bucket-name/*')하였습니다.
- 최소 권한 원칙과 요구 사항을 완벽히 충족합니다.

■ Question #478

로펌은 대중과 정보를 공유해야 합니다. 정보에는 공개적으로 읽을 수 있어야 하는 수백 개의 파일이 포함됩니다. 지정된 미래 날짜 전에 누구든지 파일을 수정하거나 삭제하는 것은 금지됩니다.

어떤 솔루션이 가장 안전한 방식으로 이러한 요구 사항을 충족할까요?

A. 정적 웹사이트 호스팅을 위해 구성된 Amazon S3 버킷에 모든 파일을 업로드합니다. 지정된 날짜까지 S3 버킷에 액세스하는 모든 AWS 주체에게 읽기 전용 IAM 권한을 부여합니다.
B. S3 버전 관리가 활성화된 새 Amazon S3 버킷을 만듭니다. 지정된 날짜에 따라 보관 기간이 있는 S3 객체 잠금을 사용합니다. 정적 웹사이트 호스팅을 위해 S3 버킷을 구성합니다. 객체에 대한 읽기 전용 액세스를 허용하도록 S3 버킷 정책을 설정합니다.
C. S3 버전 관리가 활성화된 새 Amazon S3 버킷을 만듭니다. 객체 수정 또는 삭제 시 AWS Lambda 함수를 실행하도록 이벤트 트리거를 구성합니다. Lambda 함수를 구성하여 객체를 개인 S3 버킷의 원래 버전으로 바꿉니다.
D. 정적 웹사이트 호스팅을 위해 구성된 Amazon S3 버킷에 모든 파일을 업로드합니다. 파일이 들어 있는 폴더를 선택합니다. 지정된 날짜에 따라 보관 기간이 있는 S3 Object Lock을 사용합니다. S3 버킷에 액세스하는 모든 AWS 주체에게 읽기 전용 IAM 권한을 부여합니다.

요구 사항 분석
- 파일의 공개 읽기 가능 : 파일은 대중이 읽을 수 있도록 해야 합니다.
- 수정 및 삭제 방지 : 지정된 미래 날짜 전에는 파일을 수정하거나 삭제할 수 없어야 합니다.
- 가장 안전한 방식 : 데이터를 안전하게 보호하고 권한 관리를 강화해야 합니다.

B. S3 버전 관리가 활성화된 새 Amazon S3 버킷을 만듭니다. 지정된 날짜에 따라 보관 기간이 있는 S3 객체 잠금을 사용합니다. 정적 웹사이트 호스팅을 위해 S3 버킷을 구성합니다. 객체에 대한 읽기 전용 액세스를 허용하도록 S3 버킷 정책을 설정합니다.

- S3 Object Lock은 Write Once Read Many (WORM) 모델을 구현하여 데이터를 보호합니다.
- 보존 기간을 설정하여 지정된 날짜까지 객체가 삭제되거나 수정되지 않도록 강제할 수 있습니다.
- S3 버전 관리를 활성화하여 객체의 이전 버전을 유지할 수 있습니다.
- 버킷 정책을 통해 대중에게 읽기 전용 액세스를 제공할 수 있습니다.
- 파일의 공개 읽기 및 수정/삭제 방지 요구 사항을 완벽히 충족합니다.

■ Question #479

한 회사가 필요한 인프라를 수동으로 프로비저닝하여 새로운 웹사이트의 인프라 프로토타입을 만들고 있습니다. 이 인프라에는 Auto Scaling 그룹, Application Load Balancer 및 Amazon RDS 데이터베이스가 포함됩니다. 구성이 철저히 검증된 후, 회사는 자동화된 방식으로 두 개의 가용성 영역에서 개발 및 프로덕션 사용을 위해 인프라를 즉시 배포할 수 있는 기능을 원합니다.

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

A. AWS Systems Manager를 사용하여 두 개의 가용성 영역에서 프로토타입 인프라를 복제하고 프로비저닝합니다.
B. 프로토타입 인프라를 가이드로 사용하여 인프라를 템플릿으로 정의합니다. AWS CloudFormation으로 인프라를 배포합니다.
C. AWS Config를 사용하여 프로토타입 인프라에서 사용되는 리소스 인벤토리를 기록합니다. AWS Config를 사용하여 프로토타입 인프라를 두 개의 가용성 영역에 배포합니다.
D. AWS Elastic Beanstalk를 사용하여 프로토타입 인프라에 대한 자동화된 참조를 사용하여 두 개의 가용성 영역에 자동으로 새 환경을 배포하도록 구성합니다.

요구 사항 분석
- 자동화된 배포 : 철저히 검증된 프로토타입 인프라를 개발 및 프로덕션 환경에 자동으로 배포할 수 있어야 합니다.
- 재사용 가능한 인프라 정의 : 두 개의 가용성 영역에 동일한 구성을 신속하게 배포할 수 있는 기능이 필요합니다.
- 현재 리소스 : 프로토타입에는 Auto Scaling 그룹, Application Load Balancer 및 Amazon RDS 데이터베이스가 포함됩니다.

B. 프로토타입 인프라를 가이드로 사용하여 인프라를 템플릿으로 정의합니다. AWS CloudFormation으로 인프라를 배포합니다.

- AWS CloudFormation은 인프라를 코드로 정의하는 템플릿 기반 도구입니다.
- 프로토타입 인프라를 기반으로 템플릿을 작성하여 Auto Scaling 그룹, ALB, RDS 등 모든 구성 요소를 자동화할 수 있습니다.
- 동일한 템플릿을 사용하여 두 개의 가용성 영역에 개발 및 프로덕션 환경을 빠르게 배포할 수 있습니다.
- 요구 사항인 자동화된 배포 및 인프라의 재사용 가능한 정의를 완벽히 충족합니다.

■ Question #480

비즈니스 애플리케이션이 Amazon EC2에 호스팅되고 암호화된 객체 스토리지에 Amazon S3를 사용합니다. 최고 정보 보안 책임자는 두 서비스 간의 애플리케이션 트래픽이 퍼블릭 인터넷을 통과해서는 안 된다고 지시했습니다.

솔루션 아키텍트는 규정 준수 요구 사항을 충족하기 위해 어떤 기능을 사용해야 합니까?

A. AWS 키 관리 서비스(AWS KMS)
B. VPC 엔드포인트
C. 개인 서브넷
D. 가상 사설 게이트웨이

요구 사항 분석
애플리케이션 트래픽이 퍼블릭 인터넷을 통과하지 않도록 설정해야 합니다.
- Amazon EC2와 Amazon S3 간의 통신이 퍼블릭 네트워크를 거치지 않아야 합니다.
안전하고 규정을 준수하는 연결 방법이 필요합니다.

B. VPC 엔드포인트
- VPC 엔드포인트는 VPC 내부에서 AWS 서비스(Amazon S3 등)에 대한 비공개 연결을 제공합니다.
- 퍼블릭 인터넷을 거치지 않고, VPC 내부의 네트워크 경로를 통해 EC2와 S3 간 통신을 가능하게 합니다.

- EC2와 S3 간의 통신에서 퍼블릭 인터넷 경로를 제거하며, 보안 및 규정 준수 요구 사항을 충족합니다.

두 가지 유형의 VPC 엔드포인트
- 게이트웨이 엔드포인트: S3 및 DynamoDB와 같은 서비스에 적합
- 인터페이스 엔드포인트: 기타 AWS 서비스에 적합

저작자표시 비영리 변경금지

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

AWS SAA-C03 Examtopics (501 ~ 520) (0)	2024.12.20
AWS SAA-C03 Examtopics (481 ~ 500) (1)	2024.12.20
AWS SAA-C03 Examtopics (441 ~ 460) (2)	2024.12.19
AWS SAA-C03 Examtopics (421 ~ 440) (0)	2024.12.17
AWS SAA-C03 Examtopics (401 ~ 420) (2)	2024.12.15