본문 바로가기
Infrastructure/Certificate

[SAP] 오답노트 1주차

RoyOps 2024. 2. 18. 19:58

SAP 오답노트 1주차

  • SAP 시험을 준비하며 틀린 문제나 부족한 부분을 정리한다.

문제

  • 회사는 하이브리드 DNS 솔루션을 설계해야 합니다.
  • 이 솔루션은 VPC 내에 저장된 리소스에 대해 cloud.example.com 도메인에 대한 Amazon Route 53 프라이빗 호스팅 영역을 사용합니다.
  • 회사에는 다음과 같은 DNS 확인 요구 사항이 있습니다.
    • 온프레미스 시스템은 cloud.example.com을 확인하고 연결할 수 있어야 합니다.
    • 모든 VPC는 cloud.example.com을 확인할 수 있어야 합니다.
    • 온프레미스 기업 네트워크와 AWS Transit Gateway 간에는 이미 AWS Direct Connect 연결이 있습니다.
    • 최고의 성능으로 이러한 요구 사항을 충족하려면 회사에서 어떤 아키텍처를 사용해야 합니까?

보기

  • A: 프라이빗 호스팅 영역을 모든 VPC에 연결합니다. 공유 서비스에 VPC에서 Route 53 인바운드 해석기를 생성합니다. 모든 VPC를 전송 게이트웨이에 연결하고 인바운드 확인자를 가리키는 cloud.example.com에 대한 온프레미스 DNS 서버에서 전달 규칙을 생성합니다.
  • B: 프라이빗 호스팅 영역을 모든 VPC에 연결합니다. 공유 서비스 VPC에 Amazon EC2 조건부 전달자를 배포합니다. 모든 VPC를 전송 게이트웨이에 연결하고 조건부 전달자를 가리키는 cloud.example.com에 대한 온프레미스 DNS 서버에서 전달 규칙을 생성합니다.
  • C: 프라이빗 호스팅 영역을 공유 서비스 VPC에 연결합니다. 공유 서비스 VPC에서 Route 53 아웃바운드 해석기를 생성합니다. 모든 VPC를 전송 게이트웨이에 연결하고 아웃바운드를 가리키는 cloud.example.com에 대한 온프레미스 DNS 서버에서 전달 규칙을 생성합니다.
  • D: 프라이빗 호스팅 영역을 공유 서비스 VPC에 연결합니다. 공유 서비스 VPC에서 Route 53 인바운드 해석기를 생성합니다. 공유 서비스 VPC를 전송 게이트웨이에 연결하고 인바운드 확인자를 가리키는 cloud.example.com에 대한 온프레미스 DNS 서버에서 전달 규칙을 생성합니다.

정답

  • 정답: A
  • 공식문서
  • B의 EC2 조건부 전달자는 최고 성능 요구 사항을 충족하지 않는다.
  • C와 D는 프라이빗 호스팅 영역을 모든 VPC에 연결해야 요구사항을 만족시킬 수 있으므로 정답이 될 수 없다.
  • B와 C는 아웃바운드 확인자가 AWS에 있으므로 BC에는 온프레미스 트래픽에 대한 확인자 설정이 없다.

문제

  • 회사는 프로덕션이라는 단일 OU가 있는 AWS Organizations를 사용하여 여러 계정을 관리합니다.
  • 모든 계정은 Production OU의 구성원입니다. 관리자는 조직 루트의 거부 목록 SCP를 사용하여 제한된 서비스에 대한 액세스를 관리합니다.
  • 회사는 최근 새로운 사업부를 인수하고 새 사업부의 기존 AWS 계정을 조직에 초대했습니다.
  • 온보딩 후 새 사업부의 관리자는 회사 정책을 충족하도록 기존 AWS Config 규칙을 업데이트할 수 없다는 사실을 발견했습니다.
  • 관리자가 추가 장기 유지 관리를 도입하지 않고도 현재 정책을 변경하고 계속 시행할 수 있게 해주는 옵션은 무엇입니까?

보기

  • A: AWS Config에 대한 액세스를 제한하는 조직의 루트 SCP를 제거하십시오. 회사의 표준 AWS Config 규칙에 대한 AWS Service Catalog 제품을 생성하고 새 계정을 포함하여 조직 전체에 배포합니다.
  • B: 새 계정에 대해 온보딩이라는 임시 OU를 만듭니다. AWS Config 작업을 허용하려면 온보딩 OU에 SCP를 적용하세요. AWS Config 조정이 완료되면 새 계정을 프로덕션 OU로 이동합니다.
  • C: 조직의 루트 SCP를 거부 목록 SCP에서 변환하여 필요한 서비스만 허용하도록 목록 SCP를 허용합니다. 새 계정의 보안 주체에 대해서만 AWS Config 작업을 허용하는 SCP를 조직의 루트에 임시로 적용합니다.
  • D: 새 계정에 대해 온보딩이라는 임시 OU를 만듭니다. AWS Config 작업을 허용하려면 온보딩 OU에 SCP를 적용하세요. 조직의 루트 SCP를 프로덕션 OU로 이동합니다. AWS Config 조정이 완료되면 새 계정을 프로덕션 OU로 이동합니다.

정답

  • 정답: B
  • A는 모든 계정에 대한 AWS Config 액세스를 허용하여 회사 정책을 위반한다. C는 복잡하고 오류의 가능성이 높다. 옵션 D는 불필요하게 프로덕션 OU의 SCP를 이동한다.
  • B는 새로운 사업부의 AWS 계정을 조직에 추가할 때, 새로운 계정에 대한 임시 OU를 만들고 그 안에 SCP를 적용하여 AWS Config 작업을 허용한다. 작업이 완료되면 새 계정을 프로덕션 계정을 OU로 이동시킬 수 있다.
    • 이 방법은 새로운 사업부의 관리자가 회사의 정책을 충족하면서도 AWS Config를 업데이트할 수 있도록 허용하며, 추가 장기 유지 관리를 필요로 하지 않는다.

문제

  • 회사는 서비스를 사용하여 회사가 온프레미스에서 호스팅하는 애플리케이션에서 메타데이터를 수집합니다.
  • TV 및 인터넷 라디오와 같은 소비자 장치는 애플리케이션에 액세스합니다. 많은 구형 장치는 특정 HTTP 헤더를 지원하지 않으며 이러한 헤더가 응답에 있을 때 오류를 표시합니다.
  • 회사는 User-Agent 헤더로 식별한 이전 장치로 전송된 응답에서 지원되지 않는 헤더를 제거하도록 온프레미스 로드 밸런서를 구성했습니다.
  • 회사는 서비스를 AWS로 마이그레이션하고, 서버리스 기술을 채택하고, 이전 장치를 지원하는 기능을 유지하기를 원합니다. 회사는 이미 애플리케이션을 AWS Lambda 함수 세트로 마이그레이션했습니다.
  • 어떤 솔루션이 이러한 요구 사항을 충족합니까?

보기

  • A: 메타데이터 서비스용 Amazon CloudFront 배포를 생성합니다. ALB(Application Load Balancer)를 생성합니다. ALB에 요청을 전달하도록 CloudFront 배포를 구성합니다. 각 요청 유형에 대해 올바른 Lambda 함수를 호출하도록 ALB를 구성합니다. User-Agent 헤더 값을 기반으로 문제가 있는 헤더를 제거하는 CloudFront 함수를 생성합니다.
  • B: 메타데이터 서비스용 Amazon API Gateway REST API를 생성합니다. 각 요청 유형에 대해 올바른 Lambda 함수를 호출하도록 API 게이트웨이를 구성합니다. User-Agent 헤더 값을 기반으로 문제가 있는 헤더를 제거하도록 기본 게이트웨이 응답을 수정합니다.
  • C: 메타데이터 서비스를 위한 Amazon API Gateway HTTP API를 생성합니다. 각 요청 유형에 대해 올바른 Lambda 함수를 호출하도록 API 게이트웨이를 구성합니다. User-Agent의 값을 기반으로 문제가 있는 헤더를 제거하는 응답 매핑 템플릿을 만듭니다. 응답 데이터 매핑을 HTTP API와 연결합니다.
  • D. 메타데이터 서비스용 Amazon CloudFront 배포를 생성합니다. ALB(Application Load Balancer)를 생성합니다. ALB에 요청을 전달하도록 CloudFront 배포를 구성합니다. 각 요청 유형에 대해 올바른 Lambda 함수를 호출하도록 ALB를 구성합니다. User-Agent 헤더 값을 기반으로 최종 사용자 요청에 대한 응답으로 문제가 있는 헤더를 제거하는 Lambda@Edge 함수를 생성합니다.

정답

  • 정답: D
  • A, B, C는 모두 추가 구성 및 유지 관리가 필요하다. D는 Lambda@Edge를 사용하여 문제가 있는 헤더를 간단하고 효율적으로 제거한다.
  • D는 CloudFront 배포를 생성하여 메타데이터 서비스를 제공한다. ALB를 생성하여 CloudFront 배포에 요청을 전달한다. Lambda@Edge 함수를 생성하여 User-Agent 헤더 값을 기반으로 문제가 있는 헤더를 제거한다. Lambda@Edge 함수를 CloudFront 배포와 연결한다.
  • Lambda@Edge를 사용하여 문제가 있는 헤더를 제거하는 것은 간단하며 Lambda@Edge는 엣지 로케이션에서 실행되어 응답 시간을 단축한다. Lambda@Edge는 자동으로 확장되어 트래픽 증가를 처리한다.
  • CloudFront는 정적 및 동적 콘텐츠를 전송하는 전역 캐싱 및 배포 서비스이지만, Lambda 함수를 사용하여 HTTP 응답을 수정하거나 필터링하는 것은 Lambda@Edge를 사용해야 한다. Lambda@Edge는 CloudFront의 엣지 위치에서 실행되는 Lambda 함수를 지원한다.
  • A는 CloudFront를 통해 요청을 전달하지만 Lambda@Edge를 사용하여 문제가 있는 헤더를 제거하는 옵션을 제공하지 않는다.

문제

  • 소매 회사는 비즈니스 파트너인 다른 회사에 일련의 데이터 파일을 제공해야 합니다. 이러한 파일은 소매 회사에 속한 계정 A의 Amazon S3 버킷에 저장됩니다.
  • 비즈니스 파트너 회사는 IAM 사용자 중 한 명인 User_DataProcessor가 자체 AWS 계정(계정 B)에서 파일에 액세스하기를 원합니다.
  • User_DataProcessor가 S3 버킷에 성공적으로 액세스할 수 있도록 회사는 어떤 단계 조합을 수행해야 합니까? (2개를 선택하세요.)

보기

  • A: 계정 A의 S3 버킷에 대한 CORS 기능을 활성화합니다.
  • B: 계정 A에서 S3 버킷 정책을 다음과 같이 설정합니다. 
    {
"Effect": "Allow",
"Action": [
  "s3:GetObject",
  "s3:ListBucket"
],
"Resource": "arn:aws:s3:::AccountABucketName/*"
}
  • C: 계정 A에서 S3 버킷 정책을 다음과 같이 설정합니다. 
    {
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam:AccountB:user/User_DataProcessor"
},
"Action": [
  "s3:GetObject",
  "s3:ListBucket"
],
"Resource": [
  "arn:aws:s3:::AccountABucketName/*"
]
}
  • D: 계정 B에서 User_DataProcessor의 권한을 다음과 같이 설정합니다. 
    {
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam::AccountB:user/User_DataProcessor"
},
"Action": [
  "s3:GetObject",
  "s3:ListBucket"
],
"Resource": [
  "arn:aws:s3:::AccountABucketName/*"
]
}
  • E: 계정 B에서 User_DataProcessor의 권한을 다음과 같이 설정합니다. 
    {
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam::AccountB:user/User_DataProcessor"
},
"Action": [
  "s3:GetObject",
  "s3:ListBucket"
],
"Resource": [
  "arn:aws:s3:::AccountABucketName/*"
]
}

정답

  • 정답: C, D
  • 계정 A에서 계정 B의 IAM 사용자가 버킷에 액세스할 수 있도록 S3 버킷 정책을 설정한다. 계정 B의 IAM 사용자가 버킷과 해당 콘텐츠에 대해 필요한 작업을 수행할 수 있도록 허용하는 버킷 정책에 설명을 추가한다.
  • 계정 B에서 IAM 사용자가 S3 버킷 및 해당 콘텐츠에 대해 필요한 작업을 수행하도록 허용하는 IAM 정책을 생성한다. 정책은 S3 버킷의 ARN과 사용자가 수행할 수 있는 작업을 참조해야 한다.
  • 계정 A의 S3 버킷에 대한 CORS 기능을 켤 필요가 없다. 일반적으로 웹 브라우저가 다른 도메인의 리소스에 액세스할 수 있도록 허용하는 데 사용되기 때문이다.

문제

  • 한 회사가 Amazon EC2 인스턴스에서 기존 웹 애플리케이션을 실행하고 있습니다. 회사는 애플리케이션을 컨테이너에서 실행되는 마이크로서비스로 리팩토링해야 합니다.
  • 별도의 애플리케이션 버전이 프로덕션과 테스트라는 두 가지 서로 다른 환경에 존재합니다. 애플리케이션 부하는 가변적이지만 최소 부하와 최대 부하가 알려져 있습니다.
  • 솔루션 설계자는 운영 복잡성을 최소화하는 서버리스 아키텍처로 업데이트된 애플리케이션을 설계해야 합니다.
  • 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

보기

  • A: 컨테이너 이미지를 AWS Lambda에 함수로 업로드합니다. 예상되는 최대 로드를 처리하기 위해 연결된 Lambda 함수에 대한 동시성 제한을 구성합니다. Amazon API Gateway 내에서 두 개의 개별 Lambda 통합을 구성합니다. 하나는 프로덕션용이고 다른 하나는 테스트용입니다.
  • B: 컨테이너 이미지를 Amazon Elastic Container Registry(Amazon ECR)에 업로드합니다. 예상 로드를 처리하기 위해 Fargate 시작 유형을 사용하여 자동 확장된 Amazon Elastic Container Service(Amazon ECS) 클러스터 2개를 구성합니다. ECR 이미지에서 작업을 배포합니다. 트래픽을 ECS 클러스터로 전달하도록 두 개의 별도 Application Load Balancer를 구성합니다.
  • C: 컨테이너 이미지를 Amazon Elastic Container Registry(Amazon ECR)에 업로드합니다. 예상 로드를 처리하기 위해 Fargate 시작 유형을 사용하여 자동 확장된 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터 2개를 구성합니다. ECR 이미지에서 작업을 배포합니다. 트래픽을 EKS 클러스터로 전달하도록 두 개의 별도 Application Load Balancer를 구성합니다.
  • D: 컨테이너 이미지를 AWS Elastic Beanstalk에 업로드합니다. Elastic Beanstalk에서는 프로덕션 및 테스트를 위해 별도의 환경과 배포를 생성합니다. 트래픽을 Elastic Beanstalk 배포로 전달하도록 두 개의 별도 Application Load Balancer를 구성합니다.

정답

  • 정답: B
  • A는 람다 함수의 동시성 제한으로 인해 확장성이 제한되며 람다는 15분 실행 제한으로 인해 마이크로서비스에 적합하지 않다.
  • C는 EKS가 ECS보다 복잡하고 관리하기 어려우므로 적합하지 않고 D는 ECS보다 비용이 더 많이 들고 B보다 효율적이지 않으므로 정답이 될 수 없다.
  • B는 Fargate 시작 유형을 사용하여 자동 확장된 ECS 클러스터는 예상 로드를 처리하기 위해 필요한 컨테이너 인스턴스를 자동으로 프로비저닝 및 종료한다. Fargate는 기본 서버 프로비저닝 및 관리를 처리하므로 컨테이너 실행에 집중할 수 있다.
  • Fargate는 컨테이너가 실행되는 시간만 비용을 청구하므로 낭비를 줄일 수 있다.

문제

  • 회사에서는 타사 SaaS(Software-as-a-Service) 애플리케이션을 사용하려고 합니다. 타사 SaaS 애플리케이션은 여러 API 호출을 통해 사용됩니다.
  • 타사 SaaS 애플리케이션도 VPC 내부의 AWS에서 실행됩니다. 회사는 VPC 내부에서 타사 SaaS 애플리케이션을 사용합니다. 회사에는 인터넷을 통과하지 않는 개인 연결의 사용을 의무화하는 내부 보안 정책이 있습니다.
  • 회사 VPC에서 실행되는 리소스는 회사 VPC 외부에서 액세스할 수 없습니다. 모든 권한은 최소 권한의 원칙을 준수해야 합니다.
  • 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

보기

A. AWS PrivateLink 인터페이스 VPC 엔드포인트를 생성합니다. 이 끝점을 타사 SaaS 애플리케이션이 제공하는 끝점 서비스에 연결합니다. 엔드포인트에 대한 액세스를 제한하려면 보안 그룹을 생성하십시오. 보안 그룹을 엔드포인트와 연결합니다.
B. 타사 SaaS 애플리케이션과 회사 VPC 간에 AWS Site-to-Site VPN 연결을 생성합니다. VPN 터널 전반에 걸쳐 액세스를 제한하도록 네트워크 ACL을 구성합니다.
C. 피어링 연결에 필요한 경로를 추가하여 타사 SaaS 애플리케이션과 회사 VPUpdate 라우팅 테이블 간에 VPC 피어링 연결을 생성합니다.
D. AWS PrivateLink 엔드포인트 서비스를 생성합니다. 타사 SaaS 공급자에게 이 엔드포인트 서비스에 대한 인터페이스 VPC 엔드포인트를 생성하도록 요청하세요. 타사 SaaS 공급자의 특정 계정에 엔드포인트 서비스에 대한 권한을 부여합니다.

정답

  • 정답: A
  • PrivateLink를 사용하여 인터페이스 VPC 엔드포인트를 생성하면 회사 VPC 내부에서 타사 SaaS 애플리케이션에 안전하게 연결할 수 있다. PrivateLink를 통해 애플리케이션과의 통신은 VPC 내부에서 이루어지므로 인터넷을 통과하지 않는다. 보안 그룹을 사용하여 엔드포인트에 대한 액세스를 제어할 수 있다.
  • B는 Site-to-Site VPN은 인터넷을 통해 트래픽을 전송하므로 내부 보안 정책을 준수하지 못한다.
  • C는 VPC 피어링을 통해 다른 VPC와 통신을 설정할 수 있지만, 타사 SaaS 애플리케이션을 VPC 외부에서 실행되므로 피어링 연결만으로는 이를 충족시킬 수 없다.
  • D는 PrivateLink 엔드포인트 서비스는 회사 VPC에서 제공하는 서비스에 대한 연결을 설정하는데 사용된다. 하지만 타사 SaaS 애플리케이션을 회사 VPC 외부에서 실행하므로 이 방법은 적절하지 않다.

문제

  • 회사에서 여러 AWS 계정을 사용하고 있습니다. DNS 레코드는 계정 A의 Amazon Route 53에 대한 프라이빗 호스팅 영역에 저장됩니다. 회사의 애플리케이션과 데이터베이스는 계정 B에서 실행됩니다.
  • 솔루션 아키텍트는 새 VPC에 2계층 애플리케이션을 배포합니다. 구성을 단순화하기 위해 Amazon RDS 엔드포인트에 대한 db.example.com CNAME 레코드 세트가 Amazon Route 53의 프라이빗 호스팅 영역에 생성되었습니다.
  • 배포 중에 애플리케이션을 시작하지 못했습니다. 문제 해결 결과 Amazon EC2 인스턴스에서 db.example.com을 확인할 수 없는 것으로 나타났습니다. 솔루션 설계자는 Route 53에서 레코드 세트가 올바르게 생성되었음을 확인했습니다.
  • 이 문제를 해결하려면 솔루션 설계자가 수행해야 하는 단계 조합은 무엇입니까? (2개를 선택하세요.)

보기

  • A: 새 VPC의 별도 EC2 인스턴스에 데이터베이스를 배포합니다. 프라이빗 호스팅 영역에서 인스턴스의 프라이빗 IP에 대한 레코드 세트를 생성합니다.
  • B: SSH를 사용하여 애플리케이션 계층 EC2 인스턴스에 연결합니다. /etc/resolv.conf 파일에 RDS 엔드포인트 IP 주소를 추가합니다.
  • C: 계정 A의 프라이빗 호스팅 영역을 계정 B의 새 VPC와 연결하기 위한 권한 부여를 생성합니다.
  • D: 계정 B에서 예제 com 도메인에 대한 프라이빗 호스팅 영역을 생성합니다. AWS 계정 간에 Route 53 복제를 구성합니다.
  • E: 계정 B의 새 VPC를 계정 A의 호스팅 영역과 연결합니다. 계정 A의 연결 인증을 삭제합니다.

정답

  • 정답: C, E
  • 공식 문서
  • 계정 A의 프라이빗 호스팅 영역을 계정 B의 새 VPC와 연결하기 위한 권한 부여를 생성한다. 이 단계는 계정 B의 VPC가 계정 A의 프라이빗 호스팅 영역과 연결되어야 문제를 해결할 수 있기 때문에 필요하다.
  • 계정 B의 새 VPC를 계정 A의 호스팅 영역과 연결한다. 계정 A의 연결 권한을 삭제한다. 계정 B에서 연결이 완료된 후 계정 A에서 연결 권한을 제거해야 하기 때문에 이 단계가 필요하다.
  • EC2 인스턴스의 /etc/resolv.conf 파일에 RDS 엔드포인트 IP 주소를 수동으로 추가하는 것은 자동화가 필요한 환경에서 실용적이지 않으며 RDS 엔드포인트가 변경되면 문제가 발생할 수 있다.
  • 계정 B에 별도의 프라이빗 호스팅 영역을 생성하고 AWS 계정 간에 Route 53 복제를 구성하는 작업은 복잡한 작업이므로 적절하지 않다.

문제

  • 한 회사에서는 대량의 보관 문서를 저장하고 회사 인트라넷을 통해 직원들이 해당 문서를 사용할 수 있도록 할 계획입니다.
  • 직원은 VPC에 연결된 클라이언트 VPN 서비스를 통해 연결하여 시스템에 액세스합니다. 데이터는 대중이 접근할 수 없어야 합니다.
  • 회사가 저장하고 있는 문서는 다른 곳의 물리적 매체에 보관된 데이터의 복사본입니다. 요청 횟수가 적습니다. 가용성과 검색 속도는 회사의 관심사가 아닙니다.
  • 가장 저렴한 비용으로 이러한 요구 사항을 충족할 수 있는 솔루션은 무엇입니까?

보기

  • A: Amazon S3 버킷을 생성합니다. S3 One Zone-IA(S3 One Zone-IA) 스토리지 클래스를 기본으로 사용하도록 S3 버킷을 구성합니다. 웹사이트 호스팅을 위해 S3 버킷을 구성합니다. S3 인터페이스 엔드포인트를 생성합니다. 해당 엔드포인트를 통해서만 액세스를 허용하도록 S3 버킷을 구성합니다.
  • B: 웹 서버를 실행하는 Amazon EC2 인스턴스를 시작합니다. Amazon Elastic File System(Amazon EFS) 파일 시스템을 연결하여 EFS One Zone-Infrequent Access(EFS One Zone-IA) 스토리지 클래스에 보관된 데이터를 저장합니다. 프라이빗 네트워크에서만 액세스를 허용하도록 인스턴스 보안 그룹을 구성합니다.
  • C: 웹 서버를 실행하는 Amazon EC2 인스턴스를 시작합니다. Amazon Elastic Block Store(Amazon EBS) 볼륨을 연결하여 보관된 데이터를 저장합니다. Cold HDD(sc1) 볼륨 유형을 사용합니다. 프라이빗 네트워크에서만 액세스를 허용하도록 인스턴스 보안 그룹을 구성합니다.
  • D: Amazon S3 버킷을 생성합니다. S3 Glacier Deep Archive 스토리지 클래스를 기본값으로 사용하도록 S3 버킷을 구성합니다. 웹사이트 호스팅을 위해 S3 버킷을 구성합니다. S3 인터페이스 엔드포인트를 생성합니다. 해당 엔드포인트를 통해서만 액세스를 허용하도록 S3 버킷을 구성합니다.

정답

  • 정답: A
  • B,C는 의미없는 보기이며 A와 D가 정답 후보다. 가장 저렴한 비용으로 운영할 수 있는 방법은 D에서 언급한 Glacier Deep Archive 스토리지 클래스지만 웹사이트 호스팅에 사용할 수 없다. 결과적으로 실현가능한 방법인 A가 정답이다.

문제 (Hard)

  • 회사는 사용자 인증을 위해 온프레미스 Active Directory 서비스를 사용하고 있습니다. 회사는 동일한 인증 서비스를 사용하여 AWS Organizations를 사용하는 회사의 AWS 계정에 로그인하려고 합니다.
  • 온프레미스 환경과 회사의 모든 AWS 계정 간에 AWS Site-to-Site VPN 연결이 이미 존재합니다. 회사의 보안 정책에 따라 사용자 그룹 및 역할을 기반으로 계정에 대한 조건부 액세스가 필요합니다.
  • 사용자 ID는 단일 위치에서 관리되어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

보기

  • A: SAML 2.0을 사용하여 Active Directory에 연결하도록 AWS IAM Identity Center(AWS Single Sign-On)를 구성합니다. SCIM(System for Cross-domain Identity Management) v2.0 프로토콜을 사용하여 자동 프로비저닝을 활성화합니다. ABAC(속성 기반 액세스 제어)를 사용하여 AWS 계정에 대한 액세스 권한을 부여합니다.
  • B: IAM 자격 증명 센터를 자격 증명 소스로 사용하여 AWS IAM 자격 증명 센터(AWS Single Sign-On)를 구성합니다. SCIM(System for Cross-domain Identity Management) v2.0 프로토콜을 사용하여 자동 프로비저닝을 활성화합니다. IAM Identity Center 권한 세트를 사용하여 AWS 계정에 대한 액세스 권한을 부여합니다.
  • C: 회사의 AWS 계정 중 하나에서 SAML 2.0 자격 증명 공급자를 사용하도록 AWS Identity and Access Management(IAM)를 구성합니다. 연합된 사용자에 매핑된 IAM 사용자를 프로비저닝합니다. Active Directory의 적절한 그룹에 해당하는 액세스 권한을 부여합니다. 교차 계정 IAM 사용자를 사용하여 필요한 AWS 계정에 대한 액세스 권한을 부여합니다.
  • D: 회사의 AWS 계정 중 하나에서 OpenID Connect(OIDC) 자격 증명 공급자를 사용하도록 AWS Identity and Access Management(IAM)를 구성합니다. Active Directory의 적절한 그룹에 해당하는 연동 사용자에게 AWS 계정에 대한 액세스 권한을 부여하는 IAM 역할을 프로비저닝합니다. 교차 계정 IAM 역할을 사용하여 필요한 AWS 계정에 대한 액세스 권한을 부여합니다.

정답

  • 정답: A
  • 공식 문서
  • A는 디렉터리 서비스를 사용하여 온프레미스 AD에서 신뢰 및 동기화 설정 목적을 해결하는 ID 소스 구성으로 Active Directory를 언급한다. 질문에서 요청한 Single Sign On으로 온프레미스 AD를 사용하는 목적을 해결한다.
  • 또한 AWS Identity Center와 잘 작동하는 AWS Organization이 언급된다. 또 다른 검증을 제공한다. 계정 내에서 RBAC를 관리하기 위해 Identity Center를 사용하여 AWS 조직 계정/OU를 효율적으로 관리하는 방법에 대한 힌트를 제공한다.
  • "회사의 보안 정책에 따라 사용자 그룹 및 역할을 기반으로 계정에 대한 조건부 액세스가 필요하다"라는 말을 보았을 때, ABAC(Attribute Based Access Control)로만 해결할 수 있는 조건부 액세스에 대해 이야기하고 있다.
  • B는 IAM 자격 증명 센터를 사용하여 자격 증명을 관리해야 하기 때문에 추가적인 관리 오버헤드가 발생한다.
  • C와 D는 AWS 계정 중 하나에 자격 증명 공급자를 설정해야 하기 때문에 중앙 관리가 어렵다.
  • AWS Single-Sign-On을 사용하여 온프레미스 AD를 AWS Organizations에 연결하면 모든 AWS 계정에서 사용자 ID를 중앙에서 관리할 수 있다.
  • SCIM v2.0 프로토콜을 사용하여 자동 프로비저닝을 활성화하면 AD의 사용자 및 그룹 변경 사항이 자동으로 AWS 계정에 동기화된다.
  • ABAC를 사용하여 사용자 그룹 및 역할에 따라 AWS 계정에 대한 액세스 권한을 부여할 수 있다.

문제 (Hard)

  • 한 소프트웨어 회사가 Amazon API Gateway, AWS Lambda 함수 및 Amazon DynamoDB 테이블을 사용하여 REST API를 사용하는 애플리케이션을 배포했습니다.
  • 애플리케이션은 PUT 요청 중에 오류 수가 증가하는 것을 보여줍니다. 대부분의 PUT 호출은 특정 API 키로 인증된 소수의 클라이언트에서 발생합니다.
  • 솔루션 설계자는 다수의 PUT 요청이 하나의 클라이언트에서 발생한다는 것을 확인했습니다. API는 중요하지 않으며 클라이언트는 실패한 호출의 재시도를 허용할 수 있습니다.
  • 그러나 이러한 오류는 고객에게 표시되며 API의 평판에 손상을 입히고 있습니다. 고객 경험을 개선하기 위해 솔루션 아키텍트가 권장해야 할 것은 무엇입니까?

보기

  • A: 클라이언트 애플리케이션에서 지수 백오프 및 불규칙 변형을 사용하여 재시도 논리를 구현합니다. 오류를 포착하고 설명적인 오류 메시지로 처리하는지 확인하세요.
  • B: API 게이트웨이 수준에서 사용량 계획을 통해 API 조절을 구현합니다. 클라이언트 애플리케이션이 오류 없이 코드 429 응답을 처리하는지 확인하십시오.
  • C: API 캐싱을 활성화하여 프로덕션 단계의 응답성을 향상시킵니다. 10분 동안 부하 테스트를 실행합니다. 캐시 용량이 워크로드에 적합한지 확인하십시오.
  • D: 트래픽이 갑자기 증가하는 동안 필요한 리소스를 제공하기 위해 Lambda 함수 수준에서 예약된 동시성을 구현합니다.

정답

  • 정답: B
  • 공식 문서
  • API 제한은 API에 대한 요청 속도를 제어하는데 사용할 수 있는 기술이다. 이는 소수의 클라이언트가 대량의 요청을 하여 오류가 발생하는 상황에서 유용할 수 있다.
  • API 게이트웨이 수준에서 사용 계획을 통해 API 조절을 구현함으로써 솔루션 아키텍트는 클라이언트가 만들 수 있는 요청 수를 제한할 수 있으며, 이는 오류 수를 줄이는데 도움이 된다.
  • 클라이언트 애플리케이션이 코드 429 응답을 오류 없이 처리하는 것이 중요하다. 이렇게 하면 고객에게 표시되는 오류 수를 줄여 고객 경험을 개선하는 데 도움이 된다.

문제

  • 회사는 온프레미스 데이터 분석 플랫폼을 사용합니다. 이 시스템은 회사 데이터 센터의 12개 서버에 걸쳐 완전히 중복된 구성으로 가용성이 높습니다.
  • 시스템은 사용자의 일회성 요청 외에도 매시간 및 매일 예약된 작업을 실행합니다. 예약된 작업은 실행을 완료하는 데 20분에서 2시간 정도 걸릴 수 있으며 엄격한 SLA가 적용됩니다.
  • 예약된 작업은 시스템 사용량의 65%를 차지합니다. 사용자 작업은 일반적으로 5분 이내에 실행이 완료되며 SLA가 없습니다. 사용자 작업은 시스템 사용량의 35%를 차지합니다.
  • 시스템 오류가 발생하는 동안 예약된 작업은 SLA를 계속 충족해야 합니다. 그러나 사용자 작업이 지연될 수 있습니다. 솔루션 아키텍트는 시스템을 Amazon EC2 인스턴스로 이동하고 소비 기반 모델을 채택하여 장기 약정 없이 비용을 절감해야 합니다.
  • 솔루션은 고가용성을 유지해야 하며 SLA에 영향을 주어서는 안 됩니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

보기

  • A: 선택한 AWS 지역의 두 가용 영역에 걸쳐 12개의 인스턴스를 분할합니다. 용량 예약을 통해 각 가용 영역에서 2개의 인스턴스를 온디맨드 인스턴스로 실행합니다. 각 가용 영역에서 4개의 인스턴스를 스팟 인스턴스로 실행합니다.
  • B: 선택한 AWS 지역의 3개 가용 영역에 걸쳐 12개의 인스턴스를 분할합니다. 가용 영역 중 하나에서 4개의 인스턴스를 모두 용량 예약이 포함된 온디맨드 인스턴스로 실행합니다. 나머지 인스턴스를 스팟 인스턴스로 실행합니다.
  • C: 선택한 AWS 지역의 3개 가용 영역에 걸쳐 12개의 인스턴스를 분할합니다. Savings Plan을 통해 각 가용 영역에서 2개의 인스턴스를 온디맨드 인스턴스로 실행합니다. 각 가용 영역에서 두 개의 인스턴스를 스팟 인스턴스로 실행합니다.
  • D: 선택한 AWS 지역의 3개 가용 영역에 12개의 인스턴스를 분할합니다. 용량 예약을 통해 각 가용 영역에서 3개의 인스턴스를 온디맨드 인스턴스로 실행합니다. 각 가용 영역에서 하나의 인스턴스를 스팟 인스턴스로 실행합니다.

정답

  • 정답: D
  • Saving Plan은 장기 약정을 요구하기 때문에 요구 사항을 충족하지 않는다.
  • D는 특정 리전에 장애가 발생하더라도 65% 또는 8개의 인스턴스가 동시에 실행되기 때문에 SLA를 준수할 수 있다.

문제

  • 보안 엔지니어는 기존 애플리케이션이 Amazon S3의 암호화된 파일에서 MySQL용 Amazon RDS 데이터베이스에 대한 자격 증명을 검색한다는 사실을 확인했습니다.
  • 애플리케이션의 다음 버전에서 보안 엔지니어는 보안을 강화하기 위해 다음과 같은 애플리케이션 설계 변경을 구현하려고 합니다.
  • 데이터베이스는 안전한 AWS 관리형 서비스에 저장된 무작위로 생성된 강력한 암호를 사용해야 합니다. 애플리케이션 리소스는 AWS CloudFormation을 통해 배포되어야 합니다.
  • 애플리케이션은 90일마다 데이터베이스에 대한 자격 증명을 교체해야 합니다. 솔루션 설계자는 애플리케이션을 배포하기 위해 CloudFormation 템플릿을 생성합니다.
  • CloudFormation 템플릿에 지정된 리소스는 최소한의 운영 오버헤드로 보안 엔지니어의 요구 사항을 충족합니까?

보기

  • A: AWS Secrets Manager를 사용하여 데이터베이스 비밀번호를 비밀 리소스로 생성합니다. 데이터베이스 암호를 교체하기 위한 AWS Lambda 함수 리소스를 생성합니다. 90일마다 데이터베이스 암호를 교체하려면 Secrets Manager RotationSchedule 리소스를 지정합니다.
  • B: AWS Systems Manager Parameter Store를 사용하여 SecureString 매개변수 유형으로 데이터베이스 비밀번호를 생성합니다. 데이터베이스 암호를 교체하기 위한 AWS Lambda 함수 리소스를 생성합니다. 90일마다 데이터베이스 암호를 교체하려면 Parameter Store RotationSchedule 리소스를 지정하십시오.
  • C: AWS Secrets Manager를 사용하여 데이터베이스 비밀번호를 비밀 리소스로 생성합니다. 데이터베이스 암호를 교체하기 위한 AWS Lambda 함수 리소스를 생성합니다. 90일마다 Lambda 함수 암호 교체를 트리거하는 Amazon EventBridge 예약 규칙 리소스를 생성합니다.
  • D: AWS Systems Manager Parameter Store를 사용하여 SecureString 매개변수 유형으로 데이터베이스 비밀번호를 생성합니다. 90일마다 데이터베이스 암호를 자동으로 교체하도록 AWS AppSync DataSource 리소스를 지정합니다.

정답

  • 정답: A
  • Parameter Store는 Secrets Manager만큼 안전하지 않다.
  • Secrets Manager의 RotationSchedule은 90일마다 암호를 교체하는 규정 요구 사항을 충족한다.

문제 (Hard)

  • 한 회사가 여러 Amazon DynamoDB 테이블에 데이터를 저장하고 있습니다. 솔루션 설계자는 서버리스 아키텍처를 사용하여 HTTPS를 통한 간단한 API를 통해 데이터에 공개적으로 액세스할 수 있도록 해야 합니다.
  • 솔루션은 수요에 따라 자동으로 확장되어야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? (2개를 선택하세요.)

보기

  • A: Amazon API Gateway REST API를 생성합니다. API Gateway의 AWS 통합 유형을 사용하여 DynamoDB에 직접 통합되도록 이 API를 구성합니다.
  • B: Amazon API Gateway HTTP API를 생성합니다. API Gateway의 AWS 통합 유형을 사용하여 DynamoDB에 직접 통합되도록 이 API를 구성합니다.
  • C: Amazon API Gateway HTTP API를 생성합니다. DynamoDB 테이블에서 데이터를 반환하는 AWS Lambda 함수에 대한 통합으로 이 API를 구성합니다.
  • D: AWS Global Accelerator에서 액셀러레이터를 생성합니다. DynamoDB 테이블에서 데이터를 반환하는 AWS Lambda@Edge 함수 통합으로 이 액셀러레이터를 구성합니다.
  • E: 네트워크 로드 밸런서를 생성합니다. 요청을 적절한 AWS Lambda 함수로 전달하도록 리스너 규칙을 구성합니다.

정답

  • 정답: A, C
  • 공식 문서
  • A의 API 게이트웨이 REST API는 DynamoDB를 직접 호출할 수 있다. 하지만 HTTP API는 DynamoDB를 직접 호출할 수 없으므로 DynamoDB 테이블에서 데이터를 반환하는 람다 함수와 통합되어야 한다.

문제

  • 한 회사가 10개의 새로운 도메인 이름을 등록했습니다. 회사는 온라인 마케팅을 위해 도메인을 사용합니다. 회사에는 온라인 방문자를 각 도메인의 특정 URL로 리디렉션하는 솔루션이 필요합니다.
  • 모든 도메인과 대상 URL은 JSON 문서에 정의됩니다. 모든 DNS 레코드는 Amazon Route 53에서 관리됩니다. 솔루션 아키텍트는 HTTP 및 HTTPS 요청을 수락하는 리디렉션 서비스를 구현해야 합니다.
  • 솔루션 설계자는 최소한의 운영 노력으로 이러한 요구 사항을 충족하기 위해 어떤 단계 조합을 수행해야 합니까? (3개를 선택하세요.)

보기

  • A: Amazon EC2 인스턴스에서 실행되는 동적 웹 페이지를 만듭니다. 이벤트 메시지와 함께 JSON 문서를 사용하여 리디렉션 URL을 조회하고 응답하도록 웹페이지를 구성합니다.
  • B: HTTP 및 HTTPS 리스너를 포함하는 Application Load Balancer를 생성합니다.
  • C: 이벤트 메시지와 함께 JSON 문서를 사용하여 리디렉션 URL을 조회하고 응답하는 AWS Lambda 함수를 생성합니다.
  • D: 사용자 지정 도메인과 함께 Amazon API Gateway API를 사용하여 AWS Lambda 함수를 게시합니다.
  • E: Amazon CloudFront 배포판을 생성합니다. Lambda@Edge 함수를 배포합니다.
  • F: ACM(AWS Certificate Manager)을 사용하여 SSL 인증서를 생성합니다. 도메인을 주체 대체 이름으로 포함합니다.

정답

  • 정답: B,C,F
  • A는 웹 서버 관리가 필요하여 운영 오버헤드가 발생하므로 정답이 될 수 없다. D는 API 게이트웨이가 추가로 필요하므로 정답이 될 수 없다. E는 CloudFront가 필요하지 않으므로 정답이 될 수 없다.
  • B의 ALB는 HTTP 및 HTTPS 요청을 처리하여 리디렉션 서비스에 대한 고가용성을 제공한다.
  • C의 람다 함수는 JSON 문서를 읽고 리디렉션 URL을 조회하는데 필요한 코드를 포함한다.
  • F의 ACM 인증서는 HTTPS 요청을 보호하는데 필요하다.

문제 (Hard)

  • 한 엔터프라이즈 회사에서는 개발자가 AWS Marketplace를 통해 타사 소프트웨어를 구매할 수 있도록 허용하려고 합니다.
  • 회사는 모든 기능이 활성화된 AWS Organizations 계정 구조를 사용하며, 조달 관리자가 사용할 각 조직 단위(OU)에 공유 서비스 계정을 가지고 있습니다.
  • 조달 팀의 정책에 따르면 개발자는 승인된 목록에서만 타사 소프트웨어를 얻을 수 있어야 하며 AWS Marketplace의 Private Marketplace를 사용하여 이 요구 사항을 충족할 수 있어야 합니다.
  • 조달 팀은 Private Marketplace의 관리가 조달 관리자가 맡을 수 있는 procurement-manager-role이라는 역할로 제한되기를 원합니다.
  • 회사의 다른 IAM 사용자, 그룹, 역할 및 계정 관리자는 Private Marketplace 관리 액세스가 거부되어야 합니다.
  • 이러한 요구 사항을 충족하도록 아키텍처를 설계하는 가장 효율적인 방법은 무엇입니까?

보기

  • A: 조직의 모든 AWS 계정에 procurement-manager-role이라는 IAM 역할을 생성합니다. PowerUserAccess 관리형 정책을 역할에 추가합니다. 모든 AWS 계정의 모든 IAM 사용자 및 역할에 인라인 정책을 적용하여 AWSPrivateMarketplaceAdminFullAccess 관리형 정책에 대한 권한을 거부합니다.
  • B: 조직의 모든 AWS 계정에 procurement-manager-role이라는 IAM 역할을 생성합니다. 역할에 AdministratorAccess 관리형 정책을 추가합니다. AWSPrivateMarketplaceAdminFullAccess 관리형 정책을 사용하여 권한 경계를 정의하고 이를 모든 개발자 역할에 연결합니다.
  • C: 조직의 모든 공유 서비스 계정에 procurement-manager-role이라는 IAM 역할을 생성합니다. 역할에 AWSPrivateMarketplaceAdminFullAccess 관리형 정책을 추가합니다. Procurement-manager-role이라는 역할을 제외한 모든 사람에게 Private Marketplace를 관리할 수 있는 권한을 거부하는 조직 루트 수준 SCP를 만듭니다. 다른 조직 루트 수준 SCP를 생성하여 조직의 모든 사람에게 procurement-manager-role이라는 IAM 역할을 생성할 수 있는 권한을 거부합니다.
  • D: 개발자가 사용할 모든 AWS 계정에 procurement-manager-role이라는 IAM 역할을 생성합니다. 역할에 AWSPrivateMarketplaceAdminFullAccess 관리형 정책을 추가합니다. 조달 관리자 역할이라는 역할을 제외한 모든 사람에게 Private Marketplace를 관리할 수 있는 권한을 거부하려면 조직에서 SCP를 만듭니다. 조직의 모든 공유 서비스 계정에 SCP를 적용합니다.

정답

  • 정답: C
  • A는 모든 계정에 PowerUserAccess 권한을 부여하여 보안 위험을 초래한다. B는 모든 개발자에게 관리 권한을 부여하여 역할 분리 위반을 초래한다. D는 모든 계정에 역할을 직접 생성하여 관리 오버헤드를 증가시킨다.
  • C의 조직 루트 수준 SCP는 Private Marketplace 관리 권한을 조달 관리자 역할로 제한한다. 공유 서비스 계정 역할을 생성하여 관리를 간소화한다. 조달 팀 정책을 Private Marketplace 사용에 적용한다.
  • C는 조직의 모든 공유 서비스 계정에 procurement-manager-role이라는 IAM 역할을 생성한다. 역할에 AWSPrivateMarketplaceAdminFullAccess 관리형 정책을 추가한다.
    • procurement-manager-role이라는 역할을 제외한 모든 사람에게 Private Marketplace를 관리할 수 있는 권한을 거부하는 조직 루트 수준 SCP를 만든다.
    • 다른 조직 루트 수준 SCP를 생성하여 조직의 모든 사람에게 procurement-manager-role이라는 IAM 역할을 생성할 수 있는 권한을 거부한다.

문제

  • 한 회사는 개발자가 Amazon EC2, Amazon S3 및 Amazon DynamoDB만 사용하도록 제한하기 위해 AWS Organizations를 구현하는 중입니다. 개발자 계정은 전용 조직 단위(OU)에 있습니다. 솔루션스 아키텍트는 개발자 계정에 다음 SCP를 구현했습니다.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEC2",
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*"
    }, {
      "Sid": "AllowDynamoDB",
      "Effect": "Allow",
      "Action": "dynamodb:*",
      "Resource": "*"
    }, {
      "Sid": "AllowS3",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}
  • 이 정책이 배포되면 개발자 계정의 IAM 사용자는 정책에 나열되지 않은 AWS 서비스를 계속 사용할 수 있습니다.
  • 개발자가 이 정책의 범위를 벗어나는 서비스를 사용할 수 없도록 솔루션 설계자는 어떻게 해야 합니까?

보기

  • A: 제한해야 하는 각 AWS 서비스에 대해 명시적인 거부 문을 생성합니다.
  • B: 개발자 계정의 OU에서 FullAWSAccess SCP를 제거합니다.
  • C: 모든 서비스를 명시적으로 거부하도록 FullAWSAccess SCP를 수정합니다.
  • D: SCP 끝에 와일드카드를 사용하여 명시적인 거부 문을 추가합니다.

정답

  • 정답: B
  • 공식 문서
  • AWS 관리 콘솔에서 SCP 작동 방식을 살펴보면 SCP가 활성화된 경우 기본적으로 FullAWSAccess 정책이 모든 OU에 연결되어 있음을 알 수 있다.

문제

  • 한 회사가 VPC의 퍼블릭 서브넷에 있는 5개의 Amazon EC2 인스턴스에서 모바일 앱용 모놀리식 REST 기반 API를 호스팅하고 있습니다.
  • 모바일 클라이언트는 Amazon Route 53에서 호스팅되는 도메인 이름을 사용하여 API에 연결합니다. 회사는 모든 EC2 인스턴스의 IP 주소를 사용하여 Route 53 다중 응답 라우팅 정책을 생성했습니다.
  • 최근 앱 트래픽이 대규모로 급증하면서 앱이 압도당했습니다. 앱이 트래픽을 따라잡지 못했습니다. 솔루션 설계자는 앱이 새롭고 다양한 로드를 처리할 수 있도록 솔루션을 구현해야 합니다.
  • 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

보기

  • A: API를 개별 AWS Lambda 함수로 분리합니다. 백엔드에 대한 Lambda 통합을 통해 Amazon API Gateway REST API를 구성합니다. API Gateway API를 가리키도록 Route 53 레코드를 업데이트합니다.
  • B: API 로직을 컨테이너화합니다. Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터를 생성합니다. Amazon EC2를 사용하여 클러스터에서 컨테이너를 실행합니다. Kubernetes 수신을 만듭니다. Kubernetes 수신을 가리키도록 Route 53 레코드를 업데이트합니다.
  • C: Auto Scaling 그룹을 생성합니다. 모든 EC2 인스턴스를 Auto Scaling 그룹에 배치합니다. CPU 사용률을 기반으로 조정 작업을 수행하도록 Auto Scaling 그룹을 구성합니다. Auto Scaling 그룹 변경 사항에 반응하고 Route 53 레코드를 업데이트하는 AWS Lambda 함수를 생성합니다.
  • D: API 앞에 ALB(Application Load Balancer)를 생성합니다. EC2 인스턴스를 VPC의 프라이빗 서브넷으로 이동합니다. EC2 인스턴스를 ALB의 대상으로 추가합니다. ALB를 가리키도록 Route 53 레코드를 업데이트합니다.

정답

  • 정답: D
  • A는 람다 함수를 관리하는 오버헤드를 증가시킨다. B는 Kubernetes에 대한 지식이 필요하며 관리가 복잡해진다. C는 트래픽 급증 시에도 확장 속도가 느릴 수 있다.
  • ALB와 Auto Scaling 그룹을 함께 사용하여 트래픽 증가에 따라 자동으로 확장된다. ALB는 단일 실패 지점을 제거하여 안정성을 향상시킨다.

문제

  • 회사는 Windows 파일 서버에 온프레미스로 데이터를 저장하고 있습니다. 회사는 매일 5GB의 새로운 데이터를 생성합니다.
  • 회사는 Windows 기반 워크로드의 일부를 AWS로 마이그레이션했으며 클라우드의 파일 시스템에서 데이터를 사용할 수 있어야 합니다. 회사는 이미 온프레미스 네트워크와 AWS 간에 AWS Direct Connect 연결을 설정했습니다.
  • 회사는 어떤 데이터 마이그레이션 전략을 사용해야 합니까?

보기

  • A: AWS Storage Gateway의 파일 게이트웨이 옵션을 사용하여 기존 Windows 파일 서버를 교체하고 기존 파일 공유가 새 파일 게이트웨이를 가리키도록 하십시오.
  • B: AWS DataSync를 사용하여 온프레미스 Windows 파일 서버와 Amazon FSx 간에 데이터를 복제하는 일일 작업을 예약합니다.
  • C: AWS Data Pipeline을 사용하여 온프레미스 Windows 파일 서버와 Amazon Elastic File System(Amazon EFS) 간에 데이터를 복제하는 일일 작업을 예약합니다.
  • D: AWS DataSync를 사용하여 온프레미스 Windows 파일 서버와 Amazon Elastic File System(Amazon EFS) 간에 데이터를 복제하는 일일 작업을 예약합니다.

정답

  • 정답: B
  • 클라우드와 온프레미스 Windows 모두에서 데이터에 액세스할 수 있어야 하므로 A는 정답이 될 수 없다.
  • EFS는 Linux 전용이므로 EFS 사용을 언급하는 C, D는 정답이 될 수 없다.

문제 (Hard)

  • 회사는 온프레미스 환경에서 3계층 웹 애플리케이션을 호스팅하고 있습니다. 최근 트래픽 급증으로 인해 가동 중단 시간이 발생하고 상당한 재정적 영향이 발생하여 회사 경영진은 애플리케이션을 AWS로 이전하도록 명령했습니다.
  • 애플리케이션은 .NET으로 작성되었으며 MySQL 데이터베이스에 종속됩니다. 솔루션 설계자는 매일 200,000명의 사용자 수요를 충족할 수 있는 확장 가능하고 가용성이 높은 솔루션을 설계해야 합니다.
  • 솔루션 아키텍트는 적절한 솔루션을 설계하기 위해 어떤 단계를 수행해야 합니까?

보기

  • A: AWS Elastic Beanstalk를 사용하여 웹 서버 환경과 Amazon RDS MySQL 다중 AZ DB 인스턴스로 새 애플리케이션을 생성하십시오. 환경은 여러 가용 영역의 Amazon EC2 Auto Scaling 그룹 앞에서 Network Load Balancer(NLB)를 시작해야 합니다. Amazon Route 53 별칭 레코드를 사용하여 회사 도메인에서 NLB로 트래픽을 라우팅합니다.
  • B: AWS CloudFormation을 사용하여 3개의 가용 영역에 걸쳐 있는 Amazon EC2 Auto Scaling 그룹 앞에 Application Load Balancer(ALB)가 포함된 스택을 시작합니다. 스택은 보존 삭제 정책을 사용하여 Amazon Aurora MySQL DB 클러스터의 다중 AZ 배포를 시작해야 합니다. Amazon Route 53 별칭 레코드를 사용하여 회사 도메인에서 ALB로 트래픽을 라우팅합니다.
  • C: AWS Elastic Beanstalk를 사용하여 각 지역에 ALB(Application Load Balancer)가 있는 두 개의 개별 지역에 걸쳐 자동으로 확장되는 웹 서버 환경을 생성합니다. 리전 간 읽기 전용 복제본을 사용하여 Amazon Aurora MySQL DB 클러스터의 다중 AZ 배포를 생성합니다. 지리 근접 라우팅 정책과 함께 Amazon Route 53을 사용하여 두 지역 간에 트래픽을 라우팅합니다.
  • D: AWS CloudFormation을 사용하여 3개의 가용 영역에 걸쳐 있는 스팟 인스턴스의 Amazon ECS 클러스터 앞에 Application Load Balancer(ALB)가 포함된 스택을 시작합니다. 스택은 스냅샷 삭제 정책을 사용하여 Amazon RDS MySQL DB 인스턴스를 시작해야 합니다. Amazon Route 53 별칭 레코드를 사용하여 회사 도메인에서 ALB로 트래픽을 라우팅합니다.

정답

  • 정답: B
  • A는 Beanstalk는 애플리케이션을 단일 리전에 배포하므로 200,000명의 사용자 수요를 충족할 수 없다. 또한 Auto Scaling 그룹을 사용하지 않으므로 트래픽 증가에 따라 수동으로 서버를 추가해야 한다.
  • C의 리전 간 읽기 전용 복제본을 사용하는 방식은 데이터 손실의 가능성이 있는 비동기 복제 방식이다.
  • D의 경우 스팟 인스턴스를 사용하므로 비용을 절감할 수는 있지만 가용성에 문제가 발생할 수 있다.

문제 (Hard)

  • 회사는 워크로드를 온프레미스에서 AWS로 마이그레이션하려고 합니다. 워크로드는 Linux 및 Windows에서 실행됩니다. 이 회사는 수많은 애플리케이션을 호스팅하는 VM과 물리적 머신으로 구성된 대규모 온프레미스 인프라를 보유하고 있습니다.
  • 회사는 온프레미스 워크로드의 시스템 구성, 시스템 성능, 실행 중인 프로세스 및 네트워크 연결에 대한 세부 정보를 캡처해야 합니다. 또한 회사는 AWS 마이그레이션을 위해 온프레미스 애플리케이션을 그룹으로 나누어야 합니다.
  • 회사는 가장 비용 효과적인 방식으로 AWS에서 워크로드를 실행할 수 있도록 Amazon EC2 인스턴스 유형에 대한 권장 사항이 필요합니다.
  • 이러한 요구 사항을 충족하려면 솔루션 설계자가 수행해야 하는 단계 조합은 무엇입니까? (3개를 선택하세요.)

보기

  • A: 물리적 시스템과 VM에 AWS Application Discovery Agent를 설치하여 기존 애플리케이션을 평가합니다.
  • B: 물리적 시스템과 VM에 AWS Systems Manager 에이전트를 설치하여 기존 애플리케이션을 평가합니다.
  • C: AWS Systems Manager Application Manager를 사용하여 마이그레이션할 애플리케이션으로 서버를 그룹화합니다.
  • D: AWS Migration Hub를 사용하여 마이그레이션할 애플리케이션으로 서버를 그룹화합니다.
  • E: AWS Migration Hub를 사용하여 권장 인스턴스 유형 및 관련 비용을 생성합니다.
  • F: 서버 크기에 대한 데이터를 AWS Trusted Advisor로 가져옵니다. 비용 최적화를 위한 권장 사항을 따르십시오.

정답

  • 정답: A,D,E
  • 공식 문서
  • Application Discovery Agent는 서버, 네트워크 종속성, 성능 지표를 포함하여 온프레미스 데이터 센터에 대한 자세한 정보를 수집하는데 도움이 된다.
  • Migration Hub를 사용하여 마이그레이션할 애플리케이션으로 서버를 그룹화할 수 있으며, 여러 AWS 및 파트너 솔루션 전반에 걸쳐 애플리케이션 마이그레이션 진행 상황을 추적할 수 있는 중앙 위치를 제공한다.
  • 검색된 서버를 애플리케이션으로 그룹화할 수 있으므로 마이그레이션 작업 구성이 단순화된다.
  • Migration Hub를 사용하여 권장 인스턴스 유형 및 관련 비용을 생성한다. 서버가 검색되어 애플리케이션으로 그룹화되면 Migration Hub는 수집된 데이터를 분석하여 적합한 EC2 인스턴스 유형을 추천할 수 있다.
  • Trusted Advisor를 사용하여 비용 최적화를 위한 권장 사항을 제공받을 수 있지만 Migration Hub만큼 마이그레이션에 특화되지 않는다.

문제 (Hard)

  • 한 회사는 최근 AWS에 애플리케이션을 배포했습니다. 애플리케이션은 Amazon DynamoDB를 사용합니다. 회사는 애플리케이션 로드를 측정하고 예상되는 최대 로드와 일치하도록 DynamoDB 테이블의 RCU 및 WCU를 구성했습니다.
  • 최대 부하는 일주일에 한 번 4시간 동안 발생하며 평균 부하의 두 배입니다. 애플리케이션 부하는 이번 주의 나머지 기간 동안의 평균 부하에 가깝습니다. 액세스 패턴에는 테이블 읽기보다 테이블에 대한 쓰기가 더 많이 포함됩니다.
  • 솔루션 설계자는 테이블 비용을 최소화하는 솔루션을 구현해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

보기

  • A: 피크 기간 동안 용량을 늘리려면 AWS Application Auto Scaling을 사용하십시오. 평균 부하에 맞게 예약된 RCU 및 WCU를 구매하세요.
  • B: 테이블에 대한 주문형 용량 모드를 구성합니다.
  • C: 테이블 앞에 DynamoDB Accelerator(DAX)를 구성합니다. 테이블의 새로운 최대 로드에 맞춰 프로비저닝된 읽기 용량을 줄입니다.
  • D: 테이블 앞에 DynamoDB Accelerator(DAX)를 구성합니다. 테이블에 대한 주문형 용량 모드를 구성합니다.

정답

  • 정답: B
  • A: 최대 부하와 평균 부하를 고려하지만, 사용량이 적은 시간에도 예약된 RCU 및 WCU에 대한 비용을 지불해야 하므로 불필요한 비용이 발생할 수 있다.
  • B: 온디맨드 용량 모드는 실제 수요에 따라 동적으로 조정될 수 있어 특히 피크가 4시간 동안만 지속된다는 점을 고려하면 적합한 옵션이다.
  • B: 온디맨드 용량 모드에 대한 테이블 구성은 피크 시간 동안 동적 용량 확장을 허용하고 피크 시간이 아닐 때 필요한 용량 비용만 지불하므로 가장 적절한 선택이다.

문제

  • 솔루션 아키텍트는 회사에 온프레미스 데이터 처리 애플리케이션을 AWS 클라우드로 마이그레이션하는 방법에 대해 조언해야 합니다. 현재 사용자는 웹 포털을 통해 입력 파일을 업로드합니다.
  • 그런 다음 웹 서버는 업로드된 파일을 NAS에 저장하고 메시지 대기열을 통해 처리 서버에 메시지를 보냅니다. 각 미디어 파일을 처리하는 데 최대 1시간이 걸릴 수 있습니다.
  • 회사에서는 처리 대기 중인 미디어 파일의 수가 업무 시간 중에 훨씬 더 많고, 업무 시간 이후에는 파일 수가 급격하게 감소한다는 사실을 확인했습니다.
  • 가장 비용 효율적인 마이그레이션 권장 사항은 무엇입니까?

보기

  • A: Amazon SQS를 사용하여 대기열을 생성합니다. 새 큐에 게시하도록 기존 웹 서버를 구성합니다. 대기열에 메시지가 있으면 AWS Lambda 함수를 호출하여 대기열에서 요청을 가져와 파일을 처리합니다. 처리된 파일을 Amazon S3 버킷에 저장합니다.
  • B: Amazon MQ를 사용하여 대기열을 생성합니다. 새 큐에 게시하도록 기존 웹 서버를 구성합니다. 대기열에 메시지가 있으면 새 Amazon EC2 인스턴스를 생성하여 대기열에서 요청을 가져와 파일을 처리합니다. 처리된 파일을 Amazon EFS에 저장합니다. 작업이 완료된 후 EC2 인스턴스를 종료합니다.
  • C: Amazon MQ를 사용하여 대기열을 생성합니다. 새 큐에 게시하도록 기존 웹 서버를 구성합니다. 대기열에 메시지가 있으면 AWS Lambda 함수를 호출하여 대기열에서 요청을 가져와 파일을 처리합니다. 처리된 파일을 Amazon EFS에 저장합니다.
  • D: Amazon SQS를 사용하여 대기열을 생성합니다. 새 큐에 게시하도록 기존 웹 서버를 구성합니다. EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스를 사용하여 대기열에서 요청을 가져와 파일을 처리합니다. SQS 대기열 길이를 기준으로 EC2 인스턴스를 확장합니다. 처리된 파일을 Amazon S3 버킷에 저장합니다.

정답

  • 정답: D
  • A는 비용 효율적인 방식이지만 미디어 파일을 처리하는데 최대 1시간이 소요되므로 람다를 사용할 수 없다. 람다의 최대 실행시간은 15분으로 제한된다.
  • Amazon MQ의 경우 Amazon SQS보다 비용이 비싸기 때문에 정답이 될 수 없다.

문제 (Hard)

  • 한 회사에서 Amazon OpenSearch Service를 사용하여 데이터를 분석하고 있습니다. 이 회사는 S3 Standard 스토리지를 사용하는 Amazon S3 버킷에서 10개의 데이터 노드가 있는 OpenSearch Service 클러스터에 데이터를 로드합니다.
  • 데이터는 읽기 전용 분석을 위해 1개월 동안 클러스터에 보관됩니다. 1개월 후 회사는 해당 데이터가 포함된 인덱스를 클러스터에서 삭제합니다. 규정 준수를 위해 회사는 모든 입력 데이터의 사본을 보관해야 합니다.
  • 회사는 지속적인 비용을 우려하고 솔루션 설계자에게 새로운 솔루션을 추천해 달라고 요청합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

보기

  • A: 예상 용량을 처리하려면 모든 데이터 노드를 UltraWarm 노드로 교체하세요. 회사가 데이터를 클러스터에 로드할 때 입력 데이터를 S3 Standard에서 S3 Glacier Deep Archive로 전환합니다.
  • B: 클러스터의 데이터 노드 수를 2개로 줄입니다. UltraWarm 노드를 추가하여 예상 용량을 처리합니다. OpenSearch 서비스가 데이터를 수집할 때 UltraWarm으로 전환되도록 인덱스를 구성합니다. S3 수명 주기 정책을 사용하여 1개월 후에 입력 데이터를 S3 Glacier Deep Archive로 전환합니다.
  • C: 클러스터의 데이터 노드 수를 2로 줄입니다. UltraWarm 노드를 추가하여 예상 용량을 처리합니다. OpenSearch 서비스가 데이터를 수집할 때 UltraWarm으로 전환되도록 인덱스를 구성합니다. 클러스터에 콜드 스토리지 노드를 추가합니다. 인덱스를 UltraWarm에서 콜드 스토리지로 전환합니다. S3 수명 주기 정책을 사용하여 1개월 후에 S3 버킷에서 입력 데이터를 삭제합니다.
  • D: 클러스터의 데이터 노드 수를 2로 줄입니다. 인스턴스 지원 데이터 노드를 추가하여 예상 용량을 처리합니다. 회사가 데이터를 클러스터에 로드할 때 입력 데이터를 S3 Standard에서 S3 Glacier Deep Archive로 전환합니다.

정답

  • 정답: B
  • UltraWarm 노드는 OpenSearch Service에서 제공하는 저렴한 온보드 스토리지 옵션으로, 오래된 데이터를 보관하고 분석하는데 적합하다.
    • 데이터 노드보다 최대 80% 저렴하고, 오래된 데이터를 저렴하게 보관할 수 있다.
    • 필요에 따라 용량을 쉽게 확장하거나 축소할 수 있으므로, 트래픽의 변동에 유연하게 대응할 수 있다.
    • 별도의 인프라 관리가 필요하지 않고, OpenSearch Service에서 쉽게 관리할 수 있다.
  • UltraWarm 노드는 아래와 같은 경우에 적합하다.
    • 오래된 데이터를 보관하고 분석해야 하는 경우
    • 비용을 절감해야 하는 경우
    • 탄력적인 확장성이 필요한 경우
    • 쉬운 관리를 원하는 경우
    • 빠른 쿼리 성능을 요구하는 경우
    • 긴 데이터 보존 기간이 필요한 경우
  • A는 초기 비용이 많이 들 수 있으며, 1개월 후 데이터를 삭제해야 하므로 불필요한 비용이 발생할 수 있다.
  • C에서 콜드 스토리지 노드는 데이터 액세스 속도가 느리고, 규정 준수를 위한 데이터 사본 보관 요구 사항을 충족하지 못할 수 있다.
  • D의 인스턴스 지원 데이터 노드는 UltraWarm 노드보다 비용이 더 많이 발생할 수 있다.

문제

  • 회사는 온프레미스 데이터 센터에서 Git 저장소를 호스팅합니다. 회사는 웹후크를 사용하여 AWS 클라우드에서 실행되는 기능을 호출합니다.
  • 회사는 회사가 ALB(Application Load Balancer)의 대상으로 설정한 Auto Scaling 그룹의 Amazon EC2 인스턴스 세트에서 웹후크 논리를 호스팅합니다.
  • Git 서버는 구성된 웹후크에 대해 ALB를 호출합니다. 회사는 솔루션을 서버리스 아키텍처로 이동하려고 합니다.
  • 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

보기

  • A: 각 웹후크에 대해 AWS Lambda 함수 URL을 생성하고 구성합니다. 개별 Lambda 함수 URL을 호출하도록 Git 서버를 업데이트합니다.
  • B: Amazon API Gateway HTTP API를 생성합니다. 별도의 AWS Lambda 함수에서 각 웹훅 로직을 구현합니다. API 게이트웨이 엔드포인트를 호출하도록 Git 서버를 업데이트합니다.
  • C: AWS App Runner에 웹후크 로직을 배포합니다. ALB를 생성하고 App Runner를 대상으로 설정합니다. ALB 엔드포인트를 호출하도록 Git 서버를 업데이트합니다.
  • D: 웹후크 로직을 컨테이너화합니다. Amazon Elastic Container Service(Amazon ECS) 클러스터를 생성하고 AWS Fargate에서 웹후크 로직을 실행하십시오. Amazon API Gateway REST API를 생성하고 Fargate를 대상으로 설정합니다. API 게이트웨이 엔드포인트를 호출하도록 Git 서버를 업데이트합니다.

정답

  • 정답: C
  • A에서 람다는 단일 함수만 지원하며, 여러 웹후크를 처리하기에는 적합하지 않다.
  • B에서 API 게이트웨이와 람다 함수를 사용하는 것을 제안하지만 C보다 더 복잡하고 관리하기 어려울 수 있다.
  • D에서 ECS와 Fargate를 사용하는 것을 제안하지만 이는 C보다 더 많은 리소스를 필요로 하고 관리하기 더 어려울 수 있다.
  • C에서 App Runner는 서버리스 컴퓨팅 서비스이므로 서버 프로비저닝이나 관리가 필요하지 않다.
    • 웹후크 로직을 컨테이너화하고 App Runner에 배포하기만 하면되고, App Runner는 자동으로 확장되어 트래픽 증가를 처리한다. App Runner는 사용한 만큼만 비용을 지불하면 된다.

문제 (Hard)

  • 한 회사가 VPC에 연결된 AWS Lambda 함수에서 실행되는 서버리스 애플리케이션을 구축하고 있습니다. 회사는 애플리케이션을 외부 공급자의 새로운 서비스와 통합해야 합니다.
  • 외부 공급자는 허용 목록에 있는 공용 IPv4 주소에서 오는 요청만 지원합니다. 회사는 애플리케이션이 새로운 서비스를 사용하기 시작하기 전에 외부 공급자에게 단일 공용 IP 주소를 제공해야 합니다.
  • 애플리케이션에 새로운 서비스에 액세스할 수 있는 기능을 제공하는 솔루션은 무엇입니까?

보기

  • A: NAT 게이트웨이를 배포합니다. 탄력적 IP 주소를 NAT 게이트웨이와 연결합니다. NAT 게이트웨이를 사용하도록 VPC를 구성합니다.
  • B: 외부 전용 인터넷 게이트웨이를 배포합니다. 탄력적 IP 주소를 외부 전용 인터넷 게이트웨이와 연결합니다. 외부 전용 인터넷 게이트웨이를 사용하도록 Lambda 함수에서 탄력적 네트워크 인터페이스를 구성합니다.
  • C: 인터넷 게이트웨이를 배포합니다. 탄력적 IP 주소를 인터넷 게이트웨이와 연결합니다. 인터넷 게이트웨이를 사용하도록 Lambda 함수를 구성합니다.
  • D: 인터넷 게이트웨이를 배포합니다. 탄력적 IP 주소를 인터넷 게이트웨이와 연결합니다. 인터넷 게이트웨이를 사용하도록 퍼블릭 VPC 라우팅 테이블에서 기본 경로를 구성합니다.

정답

  • 정답: A
  • 외부 전용 인터넷 게이트웨이(Egress-Only Internet Gateway)는 IPv6 전용이므로 IPv4를 위해서 사용될 수 없다.
  • C에서 인터넷 게이트웨이는 람다 함수에 공용 IP 주소를 제공하지 않는다.
  • D에서 인터넷 게이트웨이와 퍼블릭 VPC 라우팅 테이블을 사용하는 방식은 람다 함수에 공용 IP 주소를 제공하지 않는다.
  • NAT 게이트웨이를 배포하고 탄력적 IP 주소를 할당하여 외부 공급자의 허용 목록에 있는 공용 IPv4 주소에서 오는 요청을 처리할 수 있다. 람다 함수는 이 NAT 게이트웨이를 사용하여 외부 서비스에 연결할 수 있다.

문제

  • 한 회사가 AWS에서 웹 애플리케이션을 호스팅할 계획이며 Amazon EC2 인스턴스 그룹 전체에 트래픽 로드 밸런싱을 원합니다.
  • 보안 요구 사항 중 하나는 클라이언트와 웹 서버 간 전송 시 종단 간 암호화를 활성화하는 것입니다.
  • 이 요구 사항을 충족하는 솔루션은 무엇입니까?

보기

  • A: ALB(Application Load Balancer) 뒤에 EC2 인스턴스를 배치합니다. AWS Certificate Manager(ACM)을 사용하여 SSL 인증서를 프로비저닝하고 SSL 인증서를 ALB와 연결합니다. SSL 인증서를 내보내고 각 EC2 인스턴스에 설치합니다. 포트 443에서 수신 대기하고 인스턴스의 포트 443으로 트래픽을 전달하도록 ALB를 구성합니다.
  • B: EC2 인스턴스를 대상 그룹과 연결합니다. AWS Certificate Manager(ACM)를 사용하여 SSL 인증서를 프로비저닝합니다. Amazon CloudFront 배포를 생성하고 SSL 인증서를 사용하도록 구성합니다. 대상 그룹을 오리진 서버로 사용하도록 CloudFront를 설정합니다.
  • C: ALB(Application Load Balancer) 뒤에 EC2 인스턴스를 배치합니다. ACM(AWS Certificate Manager)을 사용하여 SSL 인증서를 프로비저닝하고 SSL 인증서를 ALB와 연결합니다. 타사 SSL 인증서를 프로비저닝하고 각 EC2 인스턴스에 설치합니다. 포트 443에서 수신 대기하고 인스턴스의 포트 443으로 트래픽을 전달하도록 ALB를 구성합니다.
  • D: NLB(Network Load Balancer) 뒤에 EC2 인스턴스를 배치합니다. 타사 SSL 인증서를 프로비저닝하고 NLB와 각 EC2 인스턴스에 설치합니다. 포트 443에서 수신 대기하고 인스턴스의 포트 443으로 트래픽을 전달하도록 NLB를 구성합니다.

정답

  • 정답: C
  • EC2 인스턴스에는 ACM을 통해 생성된 SSL 인증서를 설치할 수 없으므로 A는 정답이 될 수 없다.

문제 (Hard)

  • 건강 보험 회사는 개인 식별 정보(PII)를 Amazon S3 버킷에 저장합니다. 회사는 S3 관리형 암호화 키(SSE-S3)를 사용한 서버 측 암호화를 사용하여 객체를 암호화합니다.
  • 새로운 요구 사항에 따라 S3 버킷의 현재 및 미래의 모든 객체는 회사 보안 팀이 관리하는 키로 암호화되어야 합니다. S3 버킷에는 버전 관리가 활성화되어 있지 않습니다.
  • 어떤 솔루션이 이러한 요구 사항을 충족합니까?

보기

  • A: S3 버킷 속성에서 고객 관리형 키를 사용하여 기본 암호화를 SSE-S3으로 변경합니다. AWS CLI를 사용하여 S3 버킷의 모든 객체를 다시 업로드합니다. 암호화되지 않은 PutObject 요청을 거부하도록 S3 버킷 정책을 설정합니다.
  • B: S3 버킷 속성에서 기본 암호화를 AWS KMS 관리형 암호화 키(SSE-KMS)를 사용한 서버 측 암호화로 변경합니다. 암호화되지 않은 PutObject 요청을 거부하도록 S3 버킷 정책을 설정합니다. AWS CLI를 사용하여 S3 버킷의 모든 객체를 다시 업로드합니다.
  • C: S3 버킷 속성에서 기본 암호화를 AWS KMS 관리형 암호화 키(SSE-KMS)를 사용한 서버 측 암호화로 변경합니다. GetObject 및 PutObject 요청 시 객체를 자동으로 암호화하도록 S3 버킷 정책을 설정합니다.
  • D: S3 버킷 속성에서 고객 관리형 키를 사용하여 기본 암호화를 AES-256으로 변경합니다. S3 버킷에 액세스하는 모든 엔터티에 대한 암호화되지 않은 PutObject 요청을 거부하는 정책을 연결합니다. AWS CLI를 사용하여 S3 버킷의 모든 객체를 다시 업로드합니다.

정답

  • 정답: B
  • 공식 문서
  • A에서 SSE-S3는 고객 관리형 키가 아닌 AWS에서 관리하는 키를 사용한다. 따라서 회사 보안 팀이 관리하는 키로 암호화해야 한다는 요구 사항을 충족하지 못한다.
  • C에서 S3 버킷 정책에서 GetObject 및 PutObject 요청 시 객체를 자동으로 암호화하도록 설정할 수는 없다. 이 정책은 암호화되지 않은 객체의 업로드를 방지하는데 사용된다.
  • 고객 관리형 키를 사용하는 방식은 AWS에서 관리하는 키를 사용하는 방식이다.
  • SSE-KMS는 AWS KMS에서 관리하는 키로, 고객이 키를 완전히 제어하고 관리할 수 있다.

문제 (Hard)

  • 한 회사가 AWS 클라우드에서 웹 애플리케이션을 실행하고 있습니다. 애플리케이션은 Amazon EC2 인스턴스 세트에서 생성된 동적 콘텐츠로 구성됩니다. EC2 인스턴스는 ALB(Application Load Balancer)의 대상 그룹으로 구성된 Auto Scaling 그룹에서 실행됩니다.
  • 이 회사는 Amazon CloudFront 배포를 사용하여 애플리케이션을 전 세계적으로 배포하고 있습니다. CloudFront 배포판은 ALB를 오리진으로 사용합니다. 이 회사는 DNS에 Amazon Route 53을 사용하고 CloudFront 배포를 위해 www.example.com이라는 A 레코드를 생성했습니다.
  • 솔루션 설계자는 가용성이 높고 내결함성이 있도록 애플리케이션을 구성해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

보기

  • A: 다른 AWS 리전에서 전체 보조 애플리케이션 배포를 프로비저닝합니다. Route 53 A 레코드를 장애 조치 레코드로 업데이트합니다. 두 CloudFront 배포를 모두 값으로 추가합니다. Route 53 상태 확인을 생성합니다.
  • B: 다른 AWS 지역에 ALB, Auto Scaling 그룹 및 EC2 인스턴스를 프로비저닝합니다. CloudFront 배포를 업데이트하고 새 ALB에 대한 두 번째 오리진을 생성합니다. 두 오리진에 대한 오리진 그룹을 생성합니다. 하나의 원본을 기본으로 구성하고 하나의 원본을 보조로 구성합니다.
  • C: 다른 AWS 지역에 Auto Scaling 그룹과 EC2 인스턴스를 프로비저닝합니다. ALB에서 새 Auto Scaling 그룹에 대한 두 번째 대상을 생성합니다. ALB에서 장애 조치 라우팅 알고리즘을 설정합니다.
  • D: 다른 AWS 지역에 전체 보조 애플리케이션 배포를 프로비저닝합니다. 두 번째 CloudFront 배포를 생성하고 새 애플리케이션 설정을 오리진으로 추가합니다. AWS Global Accelerator 액셀러레이터를 생성합니다. 두 CloudFront 배포를 모두 엔드포인트로 추가합니다.

정답

  • 정답: B
  • A에서 다른 AWS 리전에 전체 보조 애플리케이션을 배포하는 것은 가용성을 높일 수는 있지만, Route 53의 장애 조치 레코드를 사용하여 트래픽을 다른 리전으로 전환하는 것만으로는 자동화된 내결함성이 부족하다.
  • C에서 다른 AWS 리전에 Auto Scaling 그룹과 EC2 인스턴스를 프로비저닝하여 내결함성을 향상시키는 것은 가능하지만 ALB에서 새 Auto Scaling 그룹에 대한 두 번재 대상을 생성하고 장애 조치 라우팅을 설정하는 것만으로는 CloudFront와의 통합된 내결함성이 부족하다.
  • D에서 Global Accelerator를 사용하여 두 CloudFront 배포를 엔드포인트로 추가하는 것은 가용성을 높일 수 있지만, 이것만으로는 자동으로 관리할 수 없다. Global Accelerator는 두 리전 간의 트래픽 분산을 지원하지만, 애플리케이션 자체의 내부 상태를 모니터링하거나 트래픽을 자동으로 전환하는 기능은 제공하지 않는다.

문제

  • 회사에는 AWS 계정이 많은 AWS Organizations 조직이 있습니다. AWS 계정 중 하나가 전송 계정으로 지정되고 다른 모든 AWS 계정과 공유되는 전송 게이트웨이가 있습니다.
  • AWS Site-to-Site VPN 연결은 회사의 모든 글로벌 사무소와 전송 계정 간에 구성됩니다. 회사는 모든 계정에서 AWS Config를 활성화했습니다.
  • 회사의 네트워킹 팀은 글로벌 사무소에 속한 내부 IP 주소 범위 목록을 중앙에서 관리해야 합니다. 개발자는 이 목록을 참조하여 애플리케이션에 안전하게 액세스할 수 있습니다.
  • 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

보기

  • A: Amazon S3에서 호스팅되고 모든 내부 IP 주소 범위를 나열하는 JSON 파일을 생성합니다. JSON 파일이 업데이트될 때 호출할 수 있는 각 계정에서 Amazon Simple 알림 서비스(Amazon SNS) 주제를 구성합니다. 업데이트된 IP 주소 범위로 모든 관련 보안 그룹 규칙을 업데이트하려면 SNS 주제에 대한 AWS Lambda 함수를 구독하세요.
  • B: 모든 내부 IP 주소 범위를 포함하는 새로운 AWS Config 관리형 규칙을 생성합니다. 규칙을 사용하여 각 계정의 보안 그룹을 확인하여 IP 주소 범위 목록을 준수하는지 확인하세요. 감지된 모든 비준수 보안 그룹을 자동으로 교정하도록 규칙을 구성하십시오.
  • C: 전송 계정에서 모든 내부 IP 주소 범위가 포함된 VPC 접두사 목록을 생성합니다. AWS Resource Access Manager를 사용하여 접두사 목록을 다른 모든 계정과 공유합니다. 공유 접두사 목록을 사용하여 다른 계정의 보안 그룹 규칙을 구성합니다.
  • D: 전송 계정에서 모든 내부 IP 주소 범위를 포함하는 보안 그룹을 생성합니다. "/sg-1a2b3c4d”라는 중첩된 보안 그룹 참조를 사용하여 전송 계정의 보안 그룹을 참조하도록 다른 계정의 보안 그룹을 구성합니다.

정답

  • 정답: C
  • 모든 내부 IP 주소 범위가 포함된 전송 계층에 VPC 접두사 목록이 생성된 다음 AWS Resource Access Manager를 사용하여 다른 모든 계정과 공유된다.
    • 이를 통해 IP 주소 범위를 중앙에서 관리할 수 있으며 각 계정의 보안 그룹 규칙을 수동으로 업데이트할 필요가 없다.
    • 이 솔루션을 사용하면 AWS Config를 사용하여 규정 준수 파일을 실행하고 규정을 준수하지 않는 보안 그룹을 자동으로 교정할 수 있다.

문제 (Hard)

  • 회사는 Amazon S3에서 정적 웹 사이트로 새 애플리케이션을 실행합니다. 회사는 프로덕션 AWS 계정에 애플리케이션을 배포하고 Amazon CloudFront를 사용하여 웹 사이트를 제공합니다. 웹사이트는 Amazon API Gateway REST API를 호출합니다.
  • AWS Lambda 함수는 각 API 메서드를 지원합니다. 회사는 각 API Lambda 함수의 권장 구성 메모리, 권장 비용, 현재 구성과 권장 사항 간의 가격 차이를 표시하기 위해 2주마다 CSV 보고서를 생성하려고 합니다. 회사는 보고서를 S3 버킷에 저장합니다.
  • 가장 짧은 개발 시간으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

보기

  • A: 2주 동안 Amazon CloudWatch Logs에서 각 API Lambda 함수에 대한 지표 데이터를 추출하는 Lambda 함수를 생성합니다. 데이터를 표 형식으로 대조합니다. 데이터를 S3 버킷에 .csv 파일로 저장합니다. Amazon EventBridge 규칙을 생성하여 Lambda 함수가 2주마다 실행되도록 예약합니다.
  • B: AWS Compute Optimizer를 선택합니다. ImportLambdaFunctionRecommendations 작업을 호출하는 Lambda 함수를 생성합니다. .csv 파일을 S3 버킷으로 내보냅니다. Amazon EventBridge 규칙을 생성하여 Lambda 함수가 2주마다 실행되도록 예약합니다.
  • C: AWS Compute Optimizer를 선택합니다. 향상된 인프라 측정항목을 설정하세요. Compute Optimizer 콘솔 내에서 Lambda 권장 사항을 .csv 파일로 내보내는 작업을 예약합니다. 2주마다 S3 버킷에 파일을 저장합니다.
  • D: 프로덕션 계정에 대한 AWS Business Support 플랜을 구매합니다. AWS Trusted Advisor 점검을 위해 AWS Compute Optimizer를 선택합니다. Trusted Advisor 콘솔에서 비용 최적화 검사를 .csv 파일로 내보내는 작업을 예약합니다. 2주마다 S3 버킷에 파일을 저장합니다.

정답

  • 정답: B
  • AWS Compute Optimizer를 선택하고 ImportLambdaFunctionRecommendations 작업을 호출하는 람다 함수를 생성하는 것이 개발 시간이 가장 짧은 솔루션이다.
    • 이 옵션을 사용하면 내장된 AWS Compute Optimizer 서비스를 사용하여 지표 데이터를 추출하고 이를 CSV 파일로 내보낸 다음 S3 버킷에 저장할 수 있다.
  • A는 메트릭 데이터를 추출하고 이를 표 형식으로 대조하는 람다 함수의 개발이 필요하므로 정답이 될 수 없다.
  • C는 향상된 인프라 측정항목 설정이 필요하여 개발 시간이 추가되므로 올바르지 않다.
  • D는 AWS Business Support 플랜을 구매하고 Trusted Advisor 콘솔을 사용해야 하므로 개발시간이 추가되므로 올바르지 않다.
    • Trusted Advisor는 특정 리전에 대한 정보를 제공하며 모든 리전의 데이터를 포함하지 않는다.

문제

  • 회사의 공장 및 자동화 애플리케이션이 단일 VPC에서 실행되고 있습니다. Amazon EC2, Amazon Elastic Container Service(Amazon ECS) 및 Amazon RDS의 조합에서 20개 이상의 애플리케이션이 실행됩니다.
  • 이 회사에는 세 팀에 소프트웨어 엔지니어가 분산되어 있습니다. 세 팀 중 하나가 각 애플리케이션을 소유하며, 매번 모든 애플리케이션의 비용과 성능을 책임집니다. 팀 리소스에는 해당 애플리케이션과 팀을 나타내는 태그가 있습니다. 팀은 일상 활동에 IAM 액세스를 사용합니다.
  • 회사는 월별 AWS 청구서에서 각 애플리케이션이나 팀에 발생한 비용을 확인해야 합니다. 또한 회사는 지난 12개월의 비용을 비교하고 향후 12개월의 비용을 예측하는 데 도움이 되는 보고서를 작성할 수 있어야 합니다. 솔루션 아키텍트는 이러한 비용 보고서를 제공하는 AWS Billing and Cost Management 솔루션을 권장해야 합니다.
  • 이러한 요구 사항을 충족하는 작업 조합은 무엇입니까? (3개를 선택하세요.)

보기

  • A: 애플리케이션과 팀을 나타내는 사용자 정의 비용 할당 태그를 활성화합니다.
  • B: 애플리케이션과 팀을 나타내는 AWS 생성 비용 할당 태그를 활성화합니다.
  • C: Billing and Cost Management에서 각 애플리케이션에 대한 비용 범주를 생성합니다.
  • D: Billing and Cost Management에 대한 IAM 액세스를 활성화합니다.
  • E: 비용 예산을 수립합니다.
  • F: 비용 탐색기를 활성화합니다.

정답

  • 정답: A, C, F
  • A에서 애플리케이션과 팀을 나타내는 사용자 정의 비용 할당 태그를 활성화하면 회사는 특정 애플리케이션과 팀에 비용을 할당할 수 있다.
    • 이를 통해 회사는 각 애플리케이션과 팀에서 비용이 얼마나 드는지 확인할 수 있으며 이는 비용 예측 및 예산 책정에 중요하다.
  • C의 Billing and Cost Management에서 각 애플리케이션에 대한 비용 범주를 생성하면 회사에서 애플리케이션별로 비용을 그룹화할 수 있다.
    • 이를 통해 각 애플리케이션과 관련된 비용을 더 쉽게 이해하고 시간이 지남에 따라 다양한 애플리케이션의 비용을 비교할 수 있다.
  • F에서 Cost Explorer를 활성화하면 회사는 시간 경과에 따른 비용과 사용량을 분석하고 맞춤형 보고서와 예측을 생성할 수 있다.
    • 이는 각 애플리케이션 및 팀과 관련된 비용을 이해하고 향후 비용을 예측하는 데 중요하다.
  • 일부 AWS 리소스에 대해 AWS 생성 비용 할당 태그가 자동으로 생성되지만 회사의 애플리케이션 및 팀에 필요한 비용 보고서 및 분석을 제공하지 않기 때문에 B는 정답이 될 수 없다.
  • IAM 액세스 제어를 사용하여 청구 및 비용 관리 기능에 대한 액세스를 제한하므로 D는 올바르지 않지만 요구 사항을 충족하도록 구성할 필요는 없다.
  • 비용 예산을 생성하면 회사에서 비용에 대한 예산을 설정하고 비용이 예산을 초과할 때 알림을 받을 수 있지만 회사의 애플리케이션 및 팀에 필요한 비용 보고서 및 분석을 제공하지 않기 떄문에 E는 정답이 될 수 없다.

참고한 강의

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

'Infrastructure > Certificate' 카테고리의 다른 글

[SAP] 오답노트 3주차  (0) 2024.03.17
[SAP] 오답노트 2주차  (0) 2024.02.26
[DOP] 목차  (0) 2024.02.05
[DOP] Other Services  (0) 2024.02.05
[DOP] Security & Compliance  (0) 2024.02.04

'Infrastructure/Certificate' Related Articles

티스토리툴바