Q261
문제: 회사는 전 세계 고객을 대상으로 소매 웹 사이트를 배포했습니다. 웹 사이트는 Elastic Load Balancer 뒤에 있는 여러 Amazon EC2 인스턴스에서 실행됩니다. 회사는 고객이 웹 사이트에 액세스하는 데 사용하는 장치에 따라 다양한 버전의 콘텐츠를 제공하려고 합니다. 이러한 요구 사항을 충족하기 위해 솔루션 설계자는 어떤 작업 조합을 수행해야 합니까?
답: A. 여러 버전의 콘텐츠를 캐시하도록 Amazon CloudFront를 구성합니다. C. User-Agent 헤더를 기반으로 사용자에게 특정 객체를 보내도록 Lambda@Edge 함수를 구성합니다.
핵심 지문 및 개념:
- 장치에 따라 다양한 버전의 콘텐츠 제공
- 전 세계 고객 대상
- Elastic Load Balancer 뒤의 EC2 인스턴스
사용 기술 및 개념 설명:
Amazon CloudFront:
- 캐싱 기능: 다양한 버전의 콘텐츠를 캐시하여 전 세계 사용자에게 신속하게 제공.
- 에지 로케이션: 콘텐츠를 에지에서 제공하여 전송 시간을 최소화하고 사용자 경험을 향상.
Lambda@Edge:
- 헤더 기반 라우팅: User-Agent 헤더를 기반으로 요청을 검사하고 사용자 장치에 맞는 콘텐츠를 제공.
- 퍼포먼스 향상: Lambda@Edge는 CloudFront 에지 로케이션에서 실행되어 지연 시간을 줄이고 성능을 향상시킵니다.
Q262
문제: 회사는 다중 계층 웹 애플리케이션에 Amazon ElastiCache를 사용할 계획입니다. 솔루션 설계자는 ElastiCache 클러스터용 캐시 VPC와 애플리케이션의 Amazon EC2 인스턴스용 앱 VPC를 생성합니다. 두 VPC 모두 동일한 리전에 있습니다. 애플리케이션의 EC2 인스턴스에 ElastiCache 클러스터에 대한 액세스 권한을 제공하는 가장 비용 효율적인 솔루션은 무엇입니까?
답: A. VPC 간에 피어링 연결을 생성합니다. 두 VPC 모두에서 피어링 연결을 위한 라우팅 테이블 항목을 추가합니다. 애플리케이션의 보안 그룹에서 인바운드 연결을 허용하도록 ElastiCache 클러스터의 보안 그룹에 대한 인바운드 규칙을 구성합니다.
핵심 지문 및 개념:
- VPC 피어링
- 라우팅 테이블 항목 추가
- 보안 그룹 인바운드 규칙 구성
사용 기술 및 개념 설명:
VPC 피어링:
- 직접 연결: 두 VPC 간의 피어링 연결을 통해 저렴하고 고성능의 네트워크 연결 제공.
- 라우팅 구성: 피어링 연결을 위한 라우팅 테이블 항목을 추가하여 트래픽이 올바르게 흐르도록 설정.
보안 그룹 규칙:
- 인바운드 규칙 구성: ElastiCache 클러스터의 보안 그룹에서 애플리케이션 보안 그룹의 인바운드 연결을 허용하여 EC2 인스턴스가 ElastiCache에 액세스할 수 있도록 설정.
Q263
문제: 회사는 여러 마이크로서비스로 구성된 애플리케이션을 구축하고 있습니다. 회사는 유지 관리 및 확장을 위한 지속적인 노력을 최소화하는 솔루션이 필요합니다. 회사는 추가 인프라를 관리할 수 없습니다. 이러한 요구 사항을 충족하기 위해 솔루션 설계자는 어떤 작업 조합을 수행해야 합니까?
답: A. Amazon Elastic Container Service(Amazon ECS) 클러스터를 배포합니다. D. Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 서비스를 배포합니다. 2보다 크거나 같은 원하는 태스크 번호 레벨을 지정하십시오.
핵심 지문 및 개념:
- 유지 관리 및 확장 노력 최소화
- 추가 인프라 관리 불가
사용 기술 및 개념 설명:
Amazon ECS:
- 컨테이너 오케스트레이션: 여러 컨테이너를 효율적으로 관리하고 배포할 수 있는 서비스.
- 클러스터 배포: ECS 클러스터를 배포하여 컨테이너화된 애플리케이션을 실행.
AWS Fargate:
- 서버리스 컨테이너 관리: 인프라 관리 없이 컨테이너 실행.
- 자동 확장: Fargate 시작 유형을 사용하여 컨테이너를 자동으로 확장하고 축소.
Q264
문제: 회사의 웹 애플리케이션은 Amazon Route 53에서 트래픽을 전달받는 10개 이상의 Amazon EC2 인스턴스를 호스팅하고 있습니다. 애플리케이션을 검색할 때 간헐적으로 시간 초과 오류가 발생합니다. 비정상 인스턴스의 IP 주소가 반환되어 시간 초과 오류가 발생하는 문제를 극복하기 위해 솔루션 설계자는 무엇을 구현해야 합니까?
답: D. EC2 인스턴스 앞에서 상태 확인을 통해 Application Load Balancer(ALB)를 생성합니다. 루트 53에서 ALB로 이동합니다.
핵심 지문 및 개념:
- 간헐적 시간 초과 오류
- 비정상 인스턴스 IP 반환
- 상태 확인
사용 기술 및 개념 설명:
Application Load Balancer (ALB):
- 상태 확인: ALB는 주기적으로 인스턴스의 상태를 확인하고 비정상 인스턴스를 자동으로 제외합니다.
- 트래픽 분산: 정상 인스턴스로 트래픽을 분산하여 안정성과 가용성 향상.
Amazon Route 53:
- DNS 라우팅: ALB의 IP 주소를 반환하여 비정상 인스턴스의 IP 반환 문제를 해결.
Q265
문제: 솔루션 설계자는 웹, 애플리케이션 및 데이터베이스 계층으로 구성된 고가용성 애플리케이션을 설계해야 합니다. HTTPS 콘텐츠 전송은 전송 시간을 최소화하면서 가능한 한 에지에 가까워야 합니다. 이러한 요구 사항을 충족하고 가장 안전한 솔루션은 무엇입니까?
답: C. 프라이빗 서브넷에서 여러 중복 Amazon EC2 인스턴스로 퍼블릭 ALB(Application Load Balancer)를 구성합니다. 퍼블릭 ALB를 오리진으로 사용하여 HTTPS 콘텐츠를 제공하도록 Amazon CloudFront를 구성합니다.
핵심 지문 및 개념:
- 고가용성 애플리케이션
- HTTPS 콘텐츠 전송
- 에지 캐싱
사용 기술 및 개념 설명:
Application Load Balancer (ALB):
- 퍼블릭 ALB: 인터넷과의 트래픽을 관리하고 로드 밸런싱 제공.
- 프라이빗 서브넷의 EC2 인스턴스: 보안성을 유지하면서 인스턴스를 프라이빗 서브넷에 배치하여 공격 표면을 줄임.
Amazon CloudFront:
- 콘텐츠 전송 네트워크 (CDN): 전 세계적으로 콘텐츠를 캐시하여 사용자에게 빠르게 전달.
- HTTPS 지원: 안전한 콘텐츠 전송을 위한 HTTPS 지원.
Q266
문제: 회사는 대기 시간이 사용자 경험에 영향을 미칠 수 있는 인기 있는 게임 플랫폼을 운영하고 있습니다. 애플리케이션은 모든 AWS 리전에 배포되고, Application Load Balancer(ALB) 뒤에 있는 Auto Scaling 그룹의 일부인 Amazon EC2 인스턴스에서 실행됩니다. 솔루션 설계자는 애플리케이션의 상태를 모니터링하고 트래픽을 정상 엔드포인트로 리디렉션하는 메커니즘을 구현해야 합니다.
답: A. AWS Global Accelerator에서 액셀러레이터를 구성합니다. 애플리케이션이 청취하는 포트에 대한 리스너를 추가하고 각 리전의 리전 엔드포인트에 연결합니다. ALB를 엔드포인트로 추가하십시오.
핵심 지문 및 개념:
- 대기 시간에 민감
- 모든 AWS 리전 배포
- 정상 엔드포인트로 리디렉션
사용 기술 및 개념 설명:
AWS Global Accelerator:
- 상태 모니터링: Global Accelerator는 엔드포인트 상태를 지속적으로 모니터링하여 비정상 엔드포인트를 감지하고 트래픽을 정상 엔드포인트로 리디렉션합니다.
- 최적의 경로 선택: 트래픽을 최적의 경로로 라우팅하여 지연 시간을 최소화하고 사용자 경험을 향상시킵니다.
- 글로벌 성능 최적화: 전 세계적으로 사용자 요청을 가장 가까운 AWS 리전으로 라우팅하여 응답 시간을 줄입니다.
Q267
문제: 회사는 백만 명의 모바일 앱 사용자를 가지고 있으며, 거의 실시간으로 데이터 사용량을 분석하고 데이터를 암호화하여 Apache Parquet 형식으로 중앙 위치에 저장해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하려면 어떻게 해야 합니까?
답: D. Amazon Kinesis Data Firehose 전송 스트림을 생성하여 Amazon S3에 데이터를 저장합니다. 데이터를 분석할 Amazon Kinesis Data Analytics 애플리케이션을 생성합니다.
핵심 지문 및 개념:
- 거의 실시간 데이터 분석
- 데이터 암호화
- 중앙 위치에 Apache Parquet 형식으로 저장
사용 기술 및 개념 설명:
Amazon Kinesis Data Firehose:
- 실시간 데이터 스트리밍: 데이터를 거의 실시간으로 수집하고 전송할 수 있습니다.
- 자동 변환 및 저장: 데이터를 Apache Parquet 형식으로 변환하고 Amazon S3에 자동으로 저장.
- 데이터 암호화: Kinesis Data Firehose는 전송 중 데이터 암호화를 지원합니다.
Amazon Kinesis Data Analytics:
- 실시간 데이터 분석: 실시간 스트리밍 데이터를 분석할 수 있는 기능을 제공하여 거의 실시간 분석을 수행.
- 운영 오버헤드 최소화: 완전 관리형 서비스로, 추가 인프라 관리 없이 데이터 스트리밍 및 분석 가능.
Q268
문제: 게임 회사는 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행되는 웹 애플리케이션을 운영합니다. 애플리케이션은 Amazon RDS for MySQL 데이터베이스를 사용합니다. 사용자는 데이터베이스 읽기 성능 문제로 인해 긴 지연과 중단을 경험하고 있습니다. 애플리케이션 아키텍처 변경을 최소화하면서 사용자 경험을 개선하려면 어떻게 해야 합니까?
답: B. 애플리케이션과 데이터베이스 간에 RDS 프록시를 사용합니다.
핵심 지문 및 개념:
- 데이터베이스 읽기 성능 문제
- 애플리케이션 아키텍처 변경 최소화
사용 기술 및 개념 설명:
Amazon RDS Proxy:
- 연결 풀링: 데이터베이스 연결을 풀링하여 데이터베이스에 대한 연결 수를 줄이고 성능을 최적화.
- 자동 장애 조치: 데이터베이스 장애 시 자동으로 장애 조치를 수행하여 애플리케이션 가용성을 높임.
- 안전한 연결 관리: IAM 인증을 통해 안전하게 데이터베이스 연결을 관리.
Q269
문제: 전자 상거래 회사는 Amazon RDS 기반 웹 애플리케이션의 성능 저하를 발견했습니다. 이는 비즈니스 분석가가 트리거하는 읽기 전용 SQL 쿼리 수가 증가했기 때문입니다. 솔루션 설계자는 최소한의 변경으로 문제를 해결해야 합니다.
답: C. 기본 데이터베이스의 읽기 복제본을 생성하고 비즈니스 분석가가 쿼리를 실행하도록 합니다.
핵심 지문 및 개념:
- 성능 저하 원인: 읽기 전용 SQL 쿼리 증가
- 기존 애플리케이션 변경 최소화
사용 기술 및 개념 설명:
Amazon RDS 읽기 복제본:
- 읽기 성능 향상: 읽기 전용 쿼리를 읽기 복제본으로 오프로드하여 기본 데이터베이스의 부하를 줄임.
- 자동 복제: 기본 데이터베이스의 모든 변경 사항을 읽기 복제본으로 자동 복제.
- 애플리케이션 변경 최소화: 비즈니스 분석가는 읽기 복제본을 대상으로 쿼리를 실행하여 기존 애플리케이션 구조를 크게 변경하지 않음.
Q270
문제: 회사는 로그 데이터를 Amazon S3 버킷에 저장합니다. 솔루션 설계자는 데이터가 S3 버킷에 업로드되기 전에 암호화되었는지 확인해야 하며, 데이터는 전송 중에도 암호화되어야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
답: A. 클라이언트 측 암호화를 사용하여 S3 버킷에 업로드되는 데이터를 암호화합니다.
핵심 지문 및 개념:
- 데이터 업로드 전에 암호화
- 전송 중 암호화
사용 기술 및 개념 설명:
클라이언트 측 암호화:
- 데이터 보안: 데이터가 S3 버킷에 업로드되기 전에 암호화되어 안전하게 저장.
- 전송 중 암호화: 클라이언트에서 데이터를 암호화하고 S3로 전송하므로 전송 중에도 데이터가 보호됨.
- 키 관리: 사용자가 암호화 키를 관리하여 데이터 보안을 강화.