AWS DeOp #1

Ace your homework & exams now with Quizwiz!

DevOps 엔지니어가 AWS에서 애플리케이션을 테스트하는 카나리아 메커니즘을 구현하고 있습니다. 응용프로그램은 최근에 수정되었으며 보안, 단위 및 기능 테스트를 거쳤습니다. 애플리케이션은 AutoScaling 그룹에 배포해야하며 Classic Load Balancer를 사용해야합니다. 카나리아 테스트 요구 사항을 충족하는 디자인은 무엇입니까? A. 블루 / 그린 환경을 위해 다른 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다. Amazon Route 53을 사용하고 Classic Load Balancer에서 가중 A 레코드를 생성합니다. B. 블루 / 그린 환경을위한 단일 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다. Amazon Route 53을 사용하고 Classic Load Balancer IP에 대한 A 레코드를 생성합니다. A 레코드를 사용하여 트래픽을 조정합니다. C. 블루 / 그린 환경을위한 단일 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다. Classic Load Balancer를 오리진으로 사용하여 Amazon CloudFront 배포를 생성합니다. CloudFront를 사용하여 트래픽을 조정합니다. D. 블루 / 그린 환경에 대해 다른 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다. Classic Load Balancer를위한 별도의 단계로 Amazon API Gateway를 생성합니다. 이 단계에 가중치를 부여하여 트래픽을 조정합니다.

개발 팀은 40 개 이상의 애플리케이션을 구축하고 있습니다. 각 앱은 ELB Application Load Balancer, Amazon EC2 및 Amazon RDS를 기반으로하는 3 계층 웹 애플리케이션입니다. 애플리케이션이 내부적으로 사용되기 때문에 보안 팀은 회사 네트워크에서만 40 개의 애플리케이션에 대한 액세스를 허용하고 외부 IP 주소의 액세스를 차단하려고합니다. 회사 네트워크는 프록시 서버를 통해 인터넷에 연결됩니다. 프록시 서버에는 월 1 ~ 2 회 변경되는 12 개의 프록시 IP 주소가 있습니다. 네트워크 인프라 팀은 프록시 서버를 관리합니다.최신 프록시가 포함 된 파일을 업로드합니다. Amazon S3 버킷에 IP 주소. DevOps 엔지니어는 기업 네트워크에서 애플리케이션에 액세스 할 수 있도록 솔루션을 구축해야합니다. 애플리케이션 개발에 미치는 영향을 최소화하고 운영 노력을 최소화하며 인프라 비용을 최소화하면서 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? A. AWS Lambda 함수를 구현하여 S3 객체에서 프록시 IP 주소 목록을 읽고 지정된 IP 주소에서만 HTTPS를 허용하도록 ELB 보안 그룹을 업데이트합니다. 객체가 업데이트 될 때 Lambda 함수를 호출하도록 S3 버킷을 구성합니다. IP 주소 목록이 변경되면 S3 버킷에 저장합니다. B. 모든 애플리케이션이 동일한 Virtual Private Cloud (VPC)에서 호스팅되는지 확인합니다. 그렇지 않으면 애플리케이션을 단일 VPC로 통합하십시오. 활성 / 대기 구성으로 AWS Direct Connect 연결을 설정합니다. 회사 네트워크 IP 주소의 인바운드 HTTPS 연결 만 허용하도록 ELB 보안 그룹을 변경합니다. C. Python 용 AWS SDK (Boto)를 사용하여 Python 스크립트를 구현합니다. 이 스크립트는 프록시 IP 주소가 포함 된 S3 객체를 다운로드하고, ELB 보안 그룹을 스캔하고, 지정된 IP 주소에서 HTTPS 인바운드 만 허용하도록 업데이트합니다. EC2 인스턴스를 시작하고 인스턴스에 스크립트를 저장합니다. 크론 작업을 사용하여 매일 스크립트를 실행하십시오. D. 인터넷에서 HTTPS 인바운드 액세스를 허용하도록 ELB 보안 그룹을 활성화합니다. Amazon Cognito를 사용하여 회사의 Active Directory를 자격 증명 공급자로 통합합니다. 회사 직원 만 애플리케이션에 로그인 할 수 있도록 40 개의 애플리케이션을 Amazon Cognito와 통합하도록 변경합니다. 사용자 액세스 활동을 기록하려면 사용자 액세스 로그를 Amazon CloudWatch Logs에 저장합니다.

DevOps 엔지니어가 새로운 웹 애플리케이션을 배포하고 있습니다. 이 회사는 웹 애플리케이션 배포 및 관리를 위해 AWS Elastic Beanstalk를 선택합니다. 영구 데이터를 처리하기위한 Amazon RDS MySQL. 회사는 새로운 배포가 실패하더라도 최소한의 영향을 미치도록 요구합니다. 응용 프로그램 리소스는 배포 중에 최대 용량이어야 하며 배포 롤백도 가능해야 합니다. 이러한 요구 사항을 충족하는 배포 순서는 무엇입니까? A. Elastic Beanstalk를 사용하여 애플리케이션을 배포하고 Elastic Beanstalk 환경 속성을 사용하여 외부 RDS MySQL 인스턴스에 연결합니다. 블루 / 그린 배포에 Elastic Beanstalk 기능을 사용하여 새 릴리스를 별도의 환경에 배포 한 다음 두 환경에서 CNAME을 교체하여 트래픽을 새 버전으로 리디렉션합니다. B. Elastic Beanstalk를 사용하여 애플리케이션을 배포하고 RDS MySQL을 환경의 일부로 포함합니다. 기본 Elastic Beanstalk 동작을 사용하여 변경 사항을 애플리케이션에 배포하고 롤링 업데이트가 변경 사항을 애플리케이션에 배포하도록 합니다. C. Elastic Beanstalk를 사용하여 애플리케이션을 배포하고 RDS MySQL을 환경의 일부로 포함합니다. 애플리케이션 배포를 위해 Elastic Beanstalk 변경 불가능한 업데이트를 사용합니다. D. Elastic Beanstalk를 사용하여 애플리케이션을 배포하고 Elastic Beanstalk 환경 속성을 사용하여 외부 RDS MySQL 인스턴스에 연결합니다. 애플리케이션 배포를 위해 Elastic Beanstalk 변경 불가능한 업데이트를 사용합니다

DevOps 엔지니어는 Amazon EFS에 대한 백업 메커니즘을 설계하고 구현해야 합니다. 엔지니어에게는 다음과 같은 요구 사항이 있습니다. ▶ 백업은 예정대로 실행되어야 합니다. ▶ 백업 기간이 만료되면 백업을 중지해야 합니다. ▶ 백업이 시작되기 전에 백업이 완료되면 백업을 중지해야 합니다. ▶ 추가 분석을 위해 백업 로그를 보관해야 합니다. ▶ 디자인은 고 가용성 및 내결함성 패러다임을 지원해야합니다. ▶ 관리자에게 백업 메타 데이터를 알려야 합니다. 이러한 요구 사항을 충족하는 디자인은 무엇입니까? A. 백업 활동의 시작 / 중지를 예약하기 위해 Amazon CloudWatch Events 규칙과 함께 AWS Lambda를 사용합니다. Auto Scaling 그룹의 Amazon EC2에서 백업 스크립트를 실행합니다. Amazon S3에 백업 로그를 업로드하려면 Auto Scaling 수명주기 후크와 EC2에서 SSM Run Command를 사용합니다. Amazon SNS를 사용하여 관리자에게 백업 활동 메타 데이터를 알립니다. B. 백업 활동의 시작 / 중지를 예약하기 위해 Amazon CloudWatch Events 규칙과 함께 Amazon SWF를 사용합니다. Auto Scaling 그룹의 Amazon EC2에서 백업 스크립트를 실행합니다. Amazon Redshift에 백업 로그를 업로드하려면 Auto Scaling 수명주기 후크 및 EC2에서 SSM Run Command를 사용합니다. CloudWatch 경보를 사용하여 관리자에게 백업 활동 메타 데이터를 알립니다. C. 백업 활동의 시작 / 중지를 예약하기 위해 Amazon CloudWatch Events 규칙과 함께 AWS Data Pipeline을 사용합니다. 단일 가용 영역의 Amazon EC2에서 백업 스크립트를 실행합니다. Amazon RDS에 백업 로그를 업로드하려면 Auto Scaling 수명주기 후크와 EC2에서 SSM Run Command를 사용합니다. Amazon SNS를 사용하여 관리자에게 백업 활동 메타 데이터를 알립니다. D. 백업 활동의 시작 / 중지를 예약하기 위해 Amazon CloudWatch Events 규칙과 함께 AWS CodePipeline을 사용합니다. 단일 가용 영역의 Amazon EC2에서 백업 스크립트를 실행합니다. Amazon S3에 백업 로그를 업로드하려면 Amazon EC2에서 Auto Scaling 수명주기 후크 및 SSM Run Command를 사용합니다. Amazon SES를 사용하여 백업 활동 메타 데이터를 관리자에게 알립니다.

DevOps 엔지니어는 Classic Load Balancer 뒤에 있는 상태 비 저장 RESTful 서비스의 상태를 추적해야 합니다. 새로운 애플리케이션 개정의 배포는 Cl / CD 파이프 라인을 통해 이루어집니다. 서비스의 지연 시간이 정의된 임계 값 이상으로 증가하면 서비스가 복구될 때까지 배포를 중지해야 합니다. 다음 중 가장 빠른 감지 시간을 허용하는 방법은 무엇입니까? A. Elastic Load Balancing에서 제공하는 Amazon CloudWatch 지표를 사용하여 평균 지연 시간을 계산합니다. 지연 시간이 정의된 임계 값 이상으로 증가하면 경보 및 배포 중지. B. AWS Lambda 및 Elastic Load Balancing 액세스 로그를 사용하여 평균 지연 시간을 감지합니다. 지연 시간이 정의 된 임계 값 이상으로 증가하면 경보 및 배포 중지. C. AWS CodeDeploy의 MinimumHealthyHosts 설정을 사용하여 배포 롤백을 위한 임계 값을 정의합니다. 이러한 임계 값이 위반되면 배포를 롤백 하십시오. D. 지표 필터를 사용하여 Amazon CloudWatch Logs에서 애플리케이션 로그를 구문 분석합니다. 지연 시간에 대한 필터를 만듭니다. 지연 시간이 정의된 임계 값 이상으로 증가하면 경보 및 배포 중지.

DevOps 엔지니어는 비디오 제작 회사의 비디오 파일을 관리하는 애플리케이션을 관리합니다. 이 애플리케이션은 ELB Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행됩니다. 인스턴스는 여러 가용 영역에 걸쳐 Auto Scaling 그룹에서 실행됩니다. 데이터는 Amazon RDS PostgreSQL에 저장됩니다. 다중 AZ DB 인스턴스 및 비디오 파일은 Amazon S3 버킷에 저장됩니다. 일반적인 날에는 50GB의 새 비디오가 S3 버킷에 추가됩니다. 엔지니어는 데이터 손실과 복구 시간을 최소화하면서 다중 지역 재해 복구 계획을 구현해야 합니다. 현재 애플리케이션 인프라는 AWS CloudFormation을 사용하여 이미 설명되어 있습니다. 엔지니어는 시스템의 가동 시간 및 복구 목표를 충족하기 위해 어떤 배포 옵션을 선택해야합니까? A. 두 번째 리전의 CloudFormation 템플릿에서 애플리케이션을 시작하면 Auto Scaling 그룹의 용량이 1로 설정됩니다. 두 번째 리전에서 Amazon RDS 읽기 전용 복제본을 생성합니다. 두 번째 리전에서 원래 S3 버킷과 새 S3 버킷 간의 교차 리전 복제를 활성화합니다. 페일 오버하려면 읽기 전용 복제본을 마스터로 승격하십시오. CloudFormation 스택을 업데이트하고 Auto Scaling 그룹의 용량을 늘립니다. B. Auto Scaling 그룹의 용량을 1로 설정하는 두 번째 리전의 CloudFormation 템플릿에서 애플리케이션을 시작합니다. 매일 Amazon RDS 리전 간 스냅 샷을 두 번째 리전으로 가져오는 예약된 작업을 생성합니다. 두 번째 리전에서 원래 S3 버킷과 Amazon Glacier 간의 교차 리전 복제를 활성화합니다. 재해 발생시 두 번째 지역에서 새 애플리케이션 스택을 시작하고 최신 스냅 샷에서 데이터베이스를 복원합니다. C. Auto Scaling 그룹의 용량을 1로 설정하는 두 번째 리전의 CloudFormation 템플릿에서 애플리케이션을 시작합니다. Amazon CloudWatch Events를 사용하여 야간 작업을 예약하여 데이터베이스의 스냅 샷을 만들고 스냅 샷을 두 번째 리전으로 복사한 다음 스냅 샷에서 두 번째 리전의 DB 인스턴스를 교체합니다. 두 번째 리전에서 원래 S3 버킷과 새 S3 버킷 간의 교차 리전 복제를 활성화합니다. 페일 오버하려면 Auto Scaling 그룹의 용량을 늘립니다. D. Amazon CloudWatch Events를 사용하여 데이터베이스의 스냅 샷을 생성하고 두 번째 리전에 스냅 샷을 복사하는 야간 작업을 예약합니다. S3 이벤트 알림에 대한 응답으로 두 번째 리전의 새 S3 버킷에 각 객체를 복사하는 AWS Lambda 함수를 생성합니다. 두 번째 리전에서 CloudFormation 템플릿에서 애플리케이션을 시작하고 최신 스냅 샷에서 데이터베이스를 복원합니다.

IT 부서는 내부 및 AWS에서 윈도우즈 및 리눅스(Amazon 및 Red Hat Enterprise 리눅스) 서버로 포트폴리오를 관리합니다. 감사 결과 OS 및 핵심 애플리케이션 패치를 업데이트하는 프로세스가 없으며 서버의 패치 수준이 일치하지 않는 것으로 나타났습니다. 다음 중 최신 OS 및 핵심 애플리케이션 패치 수준에서 모든 서버를 업데이트하고 유지하기 위한 가장 안정적이고 일관된 메커니즘을 제공하는 것은 무엇입니까? A. 모든 사내 및 AWS 서버에 AWS Systems Manager 에이전트를 설치합니다. 시스템 관리자 리소스 그룹을 만듭니다. 시스템즈 매니저 패치 관리자를 사전 구성된 패치 기준선과 함께 사용하여 유지 관리 기간 동안 예약된 패치 업데이트를 실행합니다. B. 모든 사내 및 AWS 서버에 AWS OpsWorks 에이전트를 설치합니다. 각 운영 체제에 대해 별도의 레이어가 있는 OpsWorks 스택을 만들고, Chef 수퍼마켓에서 Recipe를 받아 유지보수 기간 동안 각 레이어에 대한 패치 명령을 실행합니다. C. 셸 스크립트를 사용하여 yum을 사용하여 리눅스 서버에 최신 OS 패치를 설치하고 cron을 사용하여 자동으로 실행되도록 예약합니다. Windows Update를 사용하여 Windows 서버에 자동으로 패치를 적용합니다. D. AWS Systems Manager Parameter Store를 사용하여 각 Linux 및 Windows 서버에 대한 자격 증명을 안전하게 저장합니다. Systems Manager 리소스 그룹을 생성합니다. Systems Manager Run Command를 사용하여 Systems Manager Parameter Store의 자격 증명을 사용하여 원격으로 패치 업데이트를 배포합니다.

한 회사에서 테스트 프로세스를 자동화하기 위해 AWS CodePipeline을 구현하고 있습니다. 회사는 실행 상태가 실패 할 때 알림을 받기를 원하고 Amazon CloudWatch에서 다음 사용자 지정 이벤트 패턴을 사용했습니다. 이 이벤트 패턴과 일치하는 이벤트 유형은 무엇입니까? A. 모든 파이프 라인에서 배포 및 빌드 작업에 실패했습니다. B. 모든 파이프 라인에서 거부되거나 실패한 모든 승인 작업. C. 모든 파이프 라인의 모든 이벤트. D. 모든 파이프 라인에 대한 승인 작업.

개발 팀은 소스 코드 제어를 위해 AWS CodeCommit을 사용합니다. 개발자는 다양한 기능 브랜치에 변경 사항을 적용하고 프로덕션 준비가되면 변경 사항을 마스터 브랜치로 이동하기위한 풀 요청을 생성합니다. 마스터 브랜치에 대한 직접 푸시는 허용되지 않아야 합니다. 팀은 AWS 관리 형 정책 AWSCodeCommitPowerUser가 개발자의 IAM Rote에 있지만 이제 구성원은 AWS 계정의 모든 리포지토리에서 직접 마스터 브랜치로 푸시 할 수 있습니다. 이를 제한하려면 어떤 조치를 취해야합니까? A. codecommit : GitPush 작업에 대한 거부 규칙을 포함하는 추가 정책을 생성하고 마스터 참조에 대한 조건과 함께 리소스 문에 특정 리포지토리에 대한 제한을 포함합니다. B. IAM 정책을 제거하고 AWSCodeCommitReadOnly 정책을 추가합니다. 마스터 참조에 대한 조건이있는 리소스 문에서 특정 리포지토리에 대한 codecommit : GitPush 작업에 대한 허용 규칙을 추가합니다. C. IAM 정책을 수정하고 마스터 참조에 대한 조건과 함께 리소스 설명에 특정 리포지토리에 대한 codecommit : GitPush 작업에 대한 거부 규칙을 포함합니다. D. codecommit : GitPush 작업에 대한 허용 규칙을 포함하는 추가 정책을 생성하고 기능 분기 참조에 대한 조건과 함께 리소스 문에 특정 리포지토리에 대한 제한을 포함합니다.

개발 팀은 현재 AWS CodeDeploy를 사용하여 Auto Scaling 그룹에 애플리케이션 개정을 배포하고 있습니다. 배포 프로세스가 실패하면 자동으로 롤백하고 알림을 보내야합니다. 모든 요구 사항을 충족할 수 있는 가장 효과적인 구성은 무엇입니까? A. CodeDeploy 작업에 대한 Amazon CloudWatch Events 규칙을 생성합니다. 배포가 실패 할 때 Amazon SNS 메시지를 보내도록 CloudWatch Events 규칙을 구성합니다. 배포 실패시 자동으로 롤백하도록 CodeDeploy를 구성합니다. B. CodeDeploy에 사용 가능한 Amazon CloudWatch 지표를 사용하여 CloudWatch 경보를 생성합니다. 배포가 실패 할 때 Amazon SNS 메시지를 보내도록 CloudWatch 경보를 구성합니다. AWS CLI를 사용하여 이전에 배포 한 개정을 재배포합니다. C. 배포가 실패하면 Amazon SNS 주제로 알림을 보내는 트리거를 생성하도록 CodeDeploy 에이전트를 구성합니다. 배포 실패시 자동으로 롤백하도록 CodeDeploy를 구성합니다. D. AWS CloudTrail을 사용하여 AWS 계정에서 CodeDeploy가 수행하거나 대신하는 API 호출을 모니터링합니다. 배포가 실패하면 Amazon SNS 메시지를 보냅니다. AWS CLI를 사용하여 이전에 배포 한 개정을 재배포합니다.

개발자는 AWS에서 소스 코드 승격 프로세스를 용이하게하기 위해 새로운 개발 팀을위한 지속적인 배포 워크 플로를 설계하고 있습니다. 개발자는 배포가 실패 할 경우 해당 배포를 롤백하는 기능을 유지하면서 개발에서 프로덕션으로 배포 할 코드를 저장하고 승격하려고합니다. 가동 중지 시간이 가장 적게 발생하는 설계는 무엇입니까? A. AWS CodeCommit에서 하나의 리포지토리를 생성합니다. 병합 된 변경 사항을 보관할 개발 분기를 만듭니다. AWS CodeBuild를 사용하여 새 커밋에서 트리거 된 개발 브랜치에 저장된 코드를 빌드하고 테스트합니다. 블루 / 그린 배포를 위해 AWS CodeDeploy를 사용하여 마스터에 병합하고 프로덕션에 배포합니다. B. AWS CodeCommit의 각 개발자에 대해 하나의 리포지토리와 프로덕션 코드를 보관할 다른 리포지토리를 생성합니다. AWS CodeBuild를 사용하여 개발 및 프로덕션 리포지토리를 병합하고 블루 / 그린 배포를 위해 AWS CodeDeploy를 사용하여 프로덕션에 배포합니다. C. AWS CodeCommit에서 개발 코드 용 리포지토리 하나와 프로덕션 코드를 보관할 다른 리포지토리를 생성합니다. AWS CodeBuild를 사용하여 개발 및 프로덕션 리포지토리를 병합하고 블루 / 그린 배포를 위해 AWS CodeDeploy를 사용하여 프로덕션에 배포합니다. D. 개발 팀이 코드를 저장할 공유 Amazon S3 버킷을 생성합니다. 블루 / 그린 배포를 위해 AWS CodeDeploy를 사용하여 프로덕션에 코드를 배포하는 AWS Lambda 함수를 트리거하도록 Amazon CloudWatch Events 규칙을 설정합니다.

금융 기관은 애플리케이션 팀이 배포에 사용할 수 있도록 Red Hat Enterprise Linux 7.4 및 Windows Server 2016의 보안 강화 AMI를 제공합니다. DevOps 엔지니어는 최신 CVE를 모니터링하기 위해 각 AMI의 자동화 된 일일 검사를 구현해야합니다. 엔지니어는 Amazon Inspector를 사용하여 이러한 검사를 어떻게 구현해야합니까? A. 각 AMI에 Amazon Inspector 에이전트를 설치합니다. 강화 된 AMI에서 각 운영 체제에 대해 Amazon EC2 인스턴스를 시작하도록 AWS Step Functions를 구성하고 SecurityCheck : True로 인스턴스에 태그를 지정합니다. EC2 인스턴스가 부팅되면 Step Functions는 SecurityCheck : True 태그가있는 모든 인스턴스에 대해 Amazon Inspector 평가를 트리거합니다. 매일 한 번씩 Step Functions를 트리거하는 예약 된 Amazon CloudWatch Events 규칙을 구현합니다. B. SecurityCheck : True로 각 AMI에 태그를 지정합니다. 먼저 SecurityCheck : True 태그가있는 모든 AMI에 대해 Amazon Inspector 평가 템플릿을 구성하도록 AWS Step Functions를 구성하고 두 번째로 Amazon Inspector API 작업 StartAssessmentRun을 호출하도록 구성합니다. 매일 한 번씩 Step Functions를 트리거하는 예약 된 Amazon CloudWatch Events 규칙을 구현합니다. C. SecurityCheck : True로 각 AMI에 태그를 지정합니다. SecurityCheck : True 태그를 사용하여 모든 AMI에 대해 매일 한 번씩 실행되도록 예약 된 Amazon Inspector 평가를 구현합니다. Amazon Inspector는 각 AMI에 대해 Amazon EC2 인스턴스를 자동으로 시작하고 보안 평가를 수행해야합니다. D. SecurityCheck : True로 각 인스턴스에 태그를 지정합니다. SecurityCheck : True 태그가있는 모든 인스턴스에 대해 매일 한 번씩 실행되도록 예약 된 Amazon Inspector 평가를 구현합니다. Amazon Inspector는 각 AMI에 대한 내부 보안 평가를 자동으로 수행해야합니다.

보안 팀은 AWS CloudTrail에 의존하여 회사의 AWS 계정에서 민감한 보안 문제를 감지합니다. DevOps 엔지니어는 AWS 계정에서 꺼지는 CloudTrail을 자동으로 치료하는 솔루션이 필요합니다. CloudTrail 로그 전송을 위해 최소한의 다운 타임을 보장하는 솔루션은 무엇입니까? A. CloudTrail StopLogging 이벤트에 대한 Amazon CloudWatch Events 규칙을 생성합니다. AWS SDK를 사용하여 StopLogging이 호출된 리소스의 ARN에서 StartLogging을 호출하는 AWS Lambda 함수를 생성합니다. Lambda 함수 ARN을 CloudWatch 이벤트 규칙에 대상으로 추가합니다. B. 주기적으로 1 시간 간격으로 설정된 AWS 관리 형 CloudTrail 지원 AWS Config 규칙을 배포합니다. AWS Config 규칙 규정 준수 변경에 대한 Amazon CloudWatch Events 규칙을 생성합니다. AWS SDK를 사용하여 StopLogging이 호출 된 리소스의 ARN에서 StartLogging을 호출하는 AWS Lambda 함수를 생성합니다. Lambda 함수 ARN을 CloudWatch 이벤트 규칙에 대상으로 추가합니다. C. 5 분마다 예약 된 이벤트에 대한 Amazon CloudWatch Events 규칙을 생성합니다. AWS SDK를 사용하여 AWS 계정의 CloudTrail 추적에서 StartLogging을 호출하는 AWS Lambda 함수를 생성합니다. Lambda 함수 ARN을 CloudWatch 이벤트 규칙에 대상으로 추가합니다. D. AWS SDK를 사용하여 현재 계정에서 CloudTrail을 쿼리하는 스크립트가 5 분마다 실행되는 t2.nano 인스턴스를 시작합니다. CloudTrail 추적이 비활성화 된 경우 스크립트가 추적을 다시 활성화하도록합니다.

온라인 회사는 Amazon EC2 Auto Scaling을 광범위하게 사용하여 실행중인 EC2 인스턴스 수를 최소화하면서 우수한 고객 경험을 제공합니다. 응용 프로그램 계층에 있는 회사의 자체 호스팅 Puppet 환경은 인스턴스 구성을 관리합니다. IT 관리자는 가장 낮은 라이선스 비용을 원하고 EC2 Auto Scaling 그룹이 축소될 때마다 제거된 EC2 인스턴스가 가능한 한 빨리 Puppet 마스터에서 등록 취소되도록 하려고 합니다. 요구 사항을 어떻게 충족할 수 있습니까? A. 인스턴스 시작 시 EC2 사용자 데이터를 사용하여 AWS CodeDeploy 에이전트를 배포합니다. CodeDeploy를 사용하여 Puppet 에이전트를 설치합니다. Auto Scaling 그룹이 확장되면 스크립트를 실행하여 새로 배포된 인스턴스를 Puppet 마스터에 등록합니다. Auto Scaling 그룹이 축소되면 EC2 Auto Scaling 수명주기 후크를 사용하여 Puppet 마스터에서 등록 취소를 트리거합니다. EC2_INSTANCE_TERMINATING B. AWS CodeDeploy 에이전트를 기본 AMI에 적용합니다. Auto Scaling 그룹이 확장되면 CodeDeploy를 사용하여 Puppet 에이전트를 설치하고 스크립트를 실행하여 새로 배포된 인스턴스를 Puppet 마스터에 등록합니다. Auto Scaling 그룹이 축소되면 CodeDeploy ApplicationStop 수명주기 후크를 사용하여 스크립트를 실행하여 Puppet 마스터에서 인스턴스를 등록 취소합니다. C. 인스턴스 시작시 EC2 사용자 데이터를 사용하여 AWS CodeDeploy 에이전트를 배포합니다. Auto Scaling 그룹이 확장되면 CodeDeploy를 사용하여 Puppet 에이전트를 설치하고 스크립트를 실행하여 새로 배포 된 인스턴스를 Puppet 마스터에 등록합니다. Auto Scaling 그룹이 축소되면 EC2 사용자 데이터 인스턴스 중지 스크립트를 사용하여 스크립트를 실행하여 Puppet 마스터에서 인스턴스를 등록 취소합니다. D. AWS Systems Manager 에이전트를 기본 AMI에 적용합니다. Auto Scaling 그룹이 확장되면 AWS Systems Manager를 사용하여 Puppet 에이전트를 설치하고 스크립트를 실행하여 새로 배포된 인스턴스를 Puppet 마스터에 등록합니다. Auto Scaling 그룹이 축소되면 Systems Manager 인스턴스 중지 수명주기 후크를 사용하여 Puppet 마스터에서 인스턴스를 등록 취소하는 스크립트를 실행합니다.

정보 보안 정책에 따르면 암호화된 비밀이 포함된 프로덕션 Amazon S3 버킷 내부의 객체 콘텐츠는 신뢰할 수 있는 관리자 그룹 만 변경해야 합니다. DevOps 엔지니어는 이 요구 사항을 충족하기 위해 실시간 자동 검사를 어떻게 생성해야 합니까? A. 객체 변경에 대해 Amazon S3 데이터 이벤트에 의해 트리거 되고 관리자의 IAM 역할에서 IAM 사용자의 멤버십을 확인하는 AWS Lambda 함수를 생성합니다. B.주기적인 AWS Config 규칙을 생성하여 Amazon S3 로그에 변경 사항을 쿼리하고 관리자의 IAM 역할에서 IAM 사용자의 멤버십을 확인합니다. C. Amazon CloudWatch 로그에 대한 지표 필터를 생성하여 Amazon S3 버킷 수준 권한 변경 사항을 확인하고 관리자의 IAM 역할에서 IAM 사용자의 멤버십을 확인합니다. D. 정기적 인 AWS Config 규칙을 생성하여 Amazon S3 버킷 수준 권한의 변경 사항에 대해 AWS CloudTrail 로그를 쿼리하고 관리자의 IAM 역할에서 IAM 사용자의 멤버십을 확인합니다.

한 회사가 전 세계 고객을 위해 AWS에 새로운 모바일 게임을 배포하고 있습니다. 개발 팀은 AWS Code 서비스를 사용하며 다음 요구 사항을 충족해야 합니다. - 클라이언트는 최소한의 지연 시간으로 자주 백 엔드에서 실시간 재생 데이터를 송수신해야 합니다. - 게임 데이터는 데이터 상주 요건을 충족해야 합니다. DevOps 엔지니어는 요구 사항을 충족하기 위해 어떤 전략을 구현할 수 있습니까? A. 백엔드 애플리케이션을 여러 지역에 배포합니다. 코드 저장소에 대한 모든 업데이트는 2 단계 빌드 및 배포 파이프 라인을 트리거 합니다. 한 지역에서 성공적으로 배포하면 AWS Lambda 함수를 호출하여 빌드 아티팩트를 다른 지역의 Amazon S3 버킷에 복사합니다. 아티팩트가 복사되면 새 지역에서 배포 파이프 라인을 트리거 합니다. B. 백엔드 애플리케이션을 단일 지역의 여러 가용 영역에 배포합니다. 글로벌 고객에게 애플리케이션 백엔드를 제공할 Amazon CloudFront 배포를 생성합니다. 코드 리포지토리에 대한 모든 업데이트는 2 단계 빌드 및 배포 파이프 라인을 트리거합니다. 파이프 라인은 모든 가용 영역에 백엔드 애플리케이션을 배포합니다. C. 백엔드 애플리케이션을 여러 지역에 배포합니다. AWS Direct Connect를 사용하여 글로벌 고객에게 애플리케이션 백엔드를 제공합니다. 코드 리포지토리에 대한 모든 업데이트는 리전에서 2 단계 빌드 및 배포 파이프 라인을 트리거 합니다. 지역에서 성공적으로 배포한 후 파이프 라인은 아티팩트를 다른 지역에 계속 배포합니다. D. 백엔드 애플리케이션을 여러 지역에 배포합니다. 코드 리포지토리에 대한 모든 업데이트는 리전에서 2 단계 빌드 및 배포 파이프 라인을 트리거 합니다. 리전에서 성공적으로 배포 된 후 파이프 라인은 다른 리전에서 파이프 라인을 호출하고 빌드 아티팩트 위치를 전달합니다. 파이프 라인은 아티팩트 위치를 사용하고 새 지역에 애플리케이션을 배포합니다.

한 회사가 전 세계에 여러 응용 프로그램을 배포했습니다. 최근 Security Auditors는 Amazon EBS 디스크 암호화없이 시작된 Amazon EC2 인스턴스가 거의 없다는 사실을 발견했습니다. 감사관은 여러 AWS 계정 및 리전에서 암호화되지 않은 모든 EBS 볼륨을 자세히 설명하는 보고서를 요청했습니다. 또한 향후 이러한 상황이 발생할 때마다 알림을 받기를 원합니다. 최소한의 운영 오버 헤드로 어떻게 자동화할 수 있습니까? A. AWS Lambda 함수를 생성하여 모든 대상 계정에 AWS Config 규칙을 설정합니다. AWS Config 집계기를 사용하여 여러 계정 및 리전에서 데이터를 수집합니다. 집계된 보고서를 Amazon S3 버킷으로 내보내고 Amazon SNS를 사용하여 알림을 전달합니다. B. 중앙집중식 계정의 Amazon S3 버킷에 모든 이벤트를 전송하도록 AWS CloudTrail을 설정합니다. S3 이벤트 알림 기능을 사용하여 S3 버킷에 로그가 전달될 때마다 AWS Lambda 함수를 호출하여 AWS CloudTrail 로그를 구문 분석합니다. 동일한 Lambda 함수를 사용하여 Amazon SNS 주제에 출력을 게시합니다. C. EBS 암호화를 위한 AWS Config 관리 형 규칙을 추가하는 AWS CloudFormation 템플릿을 생성합니다. CloudFormation 스택 세트를 사용하여 모든 계정 및 리전에 템플릿을 배포합니다. 구성 규칙의 통합 평가 결과를 Amazon S3에 저장합니다. 규정을 준수하지 않는 리소스가 감지되면 Amazon SNS를 사용하여 알림을 보냅니다. D. AWS CLI를 사용하여 JMESPATH 쿼리 필터로 aws ec2 describe-volumes 쿼리를 호출하는 스크립트를 주기적으로 실행합니다. 그런 다음 Amazon S3 버킷에 출력을 씁니다. S3 버킷에 새 데이터가 기록될 때 Amazon SNS를 사용하여 이벤트를 보내도록 S3 이벤트 알림을 설정합니다.

한 회사에서 AWS CloudFormation을 사용하여 Amazon RDS MySOL 다중 AZ DB 인스턴스에 데이터를 저장하는 3 계층 웹 애플리케이션을 배포했습니다. DevOps 엔지니어는 가동 중지 시간을 최소화하면서 RDS 인스턴스를 MySQL의 최신 메이저 버전으로 업그레이드해야합니다. 엔지니어는 다운 타임을 최소화하면서 인스턴스를 어떻게 업그레이드 해야합니까? A. CloudFormation 템플릿에서 AWS :: RDS :: DBInstance 리소스 유형의 EngineVersion 속성을 원하는 최신 버전으로 업데이트합니다. 두 번째 스택을 시작하고 새 RDS 인스턴스를 읽기 전용 복제본으로 만듭니다. B. CloudFormation 템플릿에서 AWS :: RDS :: DBInstance 리소스 유형의 DBEngineVersion 속성을 원하는 최신 버전으로 업데이트합니다. 스택 업데이트 작업을 수행합니다. 업그레이드할 인스턴스와 동일한 속성을 사용하여 새 RDS 읽기 전용 복제본 리소스를 생성합니다. 두 번째 스택 업데이트 작업을 수행합니다. C. CloudFormation 템플릿에서 AWS :: RDS :: DBInstance 리소스 유형의 DBEngineVersion 속성을 원하는 최신 버전으로 업데이트합니다. 업그레이드할 인스턴스와 동일한 속성을 사용하여 새 RDS 읽기 전용 복제본 리소스를 생성합니다. 스택 업데이트 작업을 수행합니다. D. CloudFormation 템플릿에서 AWS :: RDS :: DBInstance 리소스 유형의 EngineVersion 속성을 최신 버전으로 업데이트하고 작업을 수행합니다. 스택 업데이트

한 회사에서 AWS를 기반으로하는 독점 엔터프라이즈 인 메모리 데이터 스토어에 그리드 시스템을 사용하려고합니다. 이 시스템은 여러 서버 노드에서 실행할 수 있습니다. Linux 기반 배포. 시스템은 노드가 추가되거나 제거 될 때마다 전체 클러스터를 재구성 할 수 있어야합니다. 노드를 추가하거나 제거 할 때 /etc./cluster/nodes.config 파일을 업데이트하여 해당 클러스터의 현재 노드 구성원의 IP 주소를 나열해야합니다. 회사는 클러스터에 새 노드를 추가하는 작업을 자동화하려고합니다. DevOps 엔지니어는 이러한 요구 사항을 충족하기 위해 무엇을 할 수 있습니까? A. AWS OpsWorks Stacks를 사용하여 해당 클러스터의 서버 노드를 계층화합니다. /etc/cluster/nodes.config 파일의 내용을 채우고 계층의 현재 구성원을 사용하여 서비스를 다시 시작하는 Chef 레시피를 만듭니다. 해당 레시피를 Configure lifecycle 이벤트에 할당합니다. B. nodes.config 파일을 버전 제어에 넣습니다. 클러스터 노드에 대한 Amazon EC2 태그 값을 기반으로 AWS CodeDeploy 배포 구성 및 배포 그룹을 생성합니다. 클러스터에 새 노드를 추가 할 때 태그가 지정된 모든 인스턴스로 파일을 업데이트하고 버전 제어에서 커밋을 수행합니다. 새 파일을 배포하고 서비스를 다시 시작합니다. C. Amazon S3 버킷을 생성하고 etc/cluster/nodes.config 파일의 버전을 업로드합니다. 해당 S3 파일을 폴링하고 자주 다운로드하는 crontab 스크립트를 생성합니다. Monit 또는 systemd와 같은 프로세스 관리자를 사용하여 새 파일이 수정되었음을 감지하면 클러스터 서비스를 다시 시작하십시오. 클러스터에 노드를 추가 할 때 파일의 가장 최근 멤버를 편집하십시오. 새 파일을 S3 버킷에 업로드합니다. D. 클러스터의 현재 보안 그룹의 모든 구성원을 나열하는 사용자 데이터 스크립트를 생성하고 새 인스턴스가 클러스터에 추가 될 때마다 /etc/cluster/nodes.config 파일을 자동으로 업데이트합니다.

회사에는 자동화된 배포 파이프 라인을 위한 코드를 작성하는 단일 개발자가 있습니다. 개발자는 각 프로젝트의 Amazon S3 버킷에 소스 코드를 저장합니다. 이 회사는 더 많은 개발자를 팀에 추가하려고 하지만 코드 충돌 및 작업 손실에 대해 우려하고 있습니다. 또한이 회사는 테스트 용 코드의 최신 버전을 배포하고 리포지토리에서 코드가 변경될 때 개발자가 두 환경 모두에 자동으로 배포 할 수 있도록 테스트 환경을 구축하고자 합니다. 이러한 요구 사항을 충족하는 가장 효율적인 방법은 무엇입니까? A. 각 프로젝트에 대해 AWS CodeCommit 리포지토리를 생성하고, 프로덕션 코드에 마스터 브랜치를 사용하고, 테스트에 배포 된 코드에 대한 테스트 브랜치를 생성합니다. 기능 브랜치를 사용하여 새로운 기능을 개발하고 코드를 테스트 및 마스터 브랜치에 병합하는 요청을 가져옵니다. B. 코드 테스트를 위해 각 프로젝트에 대해 다른 S3 버킷을 생성하고 AWS Lambda 함수를 사용하여 테스트 및 프로덕션 버킷 간의 코드 변경을 촉진합니다. 코드 충돌을 방지하려면 모든 버킷에서 버전 관리를 활성화합니다. C. 각 프로젝트에 대해 AWS CodeCommit 리포지토리를 생성하고 각 환경에 대해 서로 다른 배포 파이프 라인을 사용하여 프로덕션 및 테스트 코드에 마스터 브랜치를 사용합니다. 기능 분기를 사용하여 새 기능을 개발하십시오. D. 각 S3 버킷에서 버전 관리 및 분기를 활성화하고, 프로덕션 코드에 마스터 분기를 사용하고, 테스트에 배포 된 코드에 대한 테스트 분기를 생성합니다. 개발자가 각 환경에서 개발하기 위해 각 분기를 사용하도록 합니다.

회사는 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 애플리케이션을 실행합니다. 인스턴스는 us-east1의 여러 가용 영역에 걸쳐 Amazon EC2 Auto Scaling 그룹에서 실행됩니다. 이 애플리케이션은 Amazon RDS MySQL 다중 AZ DB 인스턴스에 데이터를 저장합니다. DevOps 엔지니어는 us-east-1에서 문제가 발생하는 경우 다운 타임을 최소화하기 위해 현재 솔루션을 수정하고 다른 지역에서 환경의 상시 대기를 생성하려고 합니다. DevOps 엔지니어는 이러한 요구 사항을 충족하기 위해 어떤 단계 조합을 취해야합니까? (3 개를 선택) A. Amazon Route 53 별칭 레코드에 상태 확인을 추가하여 기본 리전의 상태를 평가합니다. Amazon CloudWatch Events 트리거로 구성된 AWS Lambda를 사용하여 재해 복구 지역에서 Amazon RDS 마스터를 선택합니다. B. 재해 복구 지역에 새 Application Load Balancer 및 Auto Scaling 그룹을 생성합니다. C. 현재 Auto Scaling 그룹을 재해 복구 지역의 서브넷으로 확장합니다. D. 데이터베이스 인스턴스의 RDS 구성에 대해 다중 지역 장애 조치를 활성화합니다. E. 재해 복구 지역에 RDS 인스턴스의 읽기 전용 복제본을 배포합니다. F. AWS Lambda 함수를 생성하여 기본 리전의 상태를 평가합니다. 실패하면 재해 복구 지역을 가리 키도록 Amazon Route 53 레코드를 수정하고 RDS 마스터를 선택합니다.

ABE

DevOps 엔지니어는 다운 타임없이 웹 애플리케이션에 업데이트를 배포하기위한 전략을 구현해야 합니다. 애플리케이션 인프라는 AWS CloudFormation은 Amazon Route 53 레코드, Application Load Balancer, EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스로 구성됩니다. Amazon DynamoDB 테이블. 다운 타임을 방지하려면 항상 애플리케이션을 제공하는 활성 인스턴스가 있어야합니다. 다운 타임없이 배포를 수행할 수 있는 전략은 무엇입니까? (2 개 선택) A. CloudFormation 템플릿에서 AWS :: AutoScaling :: AutoscalingGroup 리소스를 수정하고 UpdatePolicy 속성을 추가하여 다운 타임없이 배포에 필요한 요소를 정의합니다. B. CloudFormation 템플릿에서 AWS :: AutoScaling :: DeploymentUpdates 리소스를 수정하고 UpdatePolicy 속성을 추가하여 다운 타임이 없는 배포에 필요한 요소를 정의합니다. C. CloudFormation 템플릿에 새 Application Load Balancer 및 Auto Scaling 그룹을 추가합니다. 비활성 Auto Scaling 그룹에 새 변경 사항을 배포합니다. Route 53을 사용하여 활성 Application Load Balancer를 변경합니다. D. CloudFormation 템플릿에 새 Application Load Balancer 및 Auto Scaling 그룹을 추가합니다. AWS :: AutoScaling :: AutoScalingGroup 리소스를 수정하고 UpdatePolicy 속성을 추가하여 롤링 업데이트를 수행합니다. E. CloudFormation 템플릿에서 CloudFormation 스택의 UpdatePolicy 속성을 수정하고 업데이트 할 Auto Scaling 그룹을 지정합니다. MinSuccessfulInstancesPercent 및 PauseTime을 구성하여 다운 타임없이 배포가 이루어 지도록 합니다.

회사는 재해 복구 또는 대기 설치에 분산 웹 애플리케이션에 대한 자동 DNS 장애 조치를 도입해야합니다. DevOps 엔지니어는 애플리케이션 오류 발생시 대체 엔드 포인트에 DNS 라우팅을 제공하도록 Amazon Route 53을 구성할 계획입니다. 이를 위해 엔지니어는 어떤 조치를 취해야합니까? (2 개 선택) A. 별칭 레코드로 입력 할 수 없는 각 엔드 포인트에 대해 Amazon Route 53 상태 확인을 생성합니다. 방화벽 및 라우팅 규칙이 Amazon Route 53이 상태 확인에 지정된 엔드 포인트로 요청을 보낼 수 있도록 허용하는지 확인합니다. B. 트래픽을 AWS 리소스로 라우팅하는 별칭 레코드를 생성하고 Evaluate Target Health 옵션의 값을 Yes로 설정 한 다음 모든 비 별칭 레코드를 생성합니다. C. 통제되는 Amazon Route 53 레코드 세트를 생성하고 장애 조치로 설정 한 다음 기본 및 보조 Amazon Route 53 레코드 세트와 연결하여 트래픽을 정상적인 DNS 항목으로 분산합니다. D. Amazon CloudWatch 경보를 생성하여 기본 Amazon Route 53 DNS 항목을 모니터링합니다. 그런 다음 연결된 AWS Lambda 함수를 생성하여 보조 DNS 항목에 대한 Route 53에 대한 장애 조치 API 호출을 실행합니다. E. 기본 및 보조 오리진을 사용하여 기본 및 보조 Amazon Route 53 레코드 세트를 Amazon CloudFront 배포에 매핑합니다.

교육 회사에는 Amazon ECS 클러스터의 여러 Amazon EC2 인스턴스에서 실행되는 Docker 기반 애플리케이션이 있습니다. 새 버전의 애플리케이션을 배포 할 때 개발자는 새 이미지를 개인 Docker 컨테이너 레지스트리에 푸시 한 다음 모든 작업을 중지하고 시작하여 모두 최신 버전의 애플리케이션을 사용하도록합니다. 개발자는 새 작업이 때때로 이전 이미지로 실행되고 있음을 발견합니다. 이 문제를 어떻게 예방할 수 있습니까? A. 새 이미지를 푸시 한 후 ECS 에이전트를 다시 시작한 다음 작업을 시작합니다. B. 작업 정의에서 Docker 이미지 태그에 "latest"를 사용합니다. C. 새 이미지를 푸시 할 때 작업 정의에 대한 다이제스트를 업데이트합니다. D. Docker 컨테이너 레지스트리에 Amazon ECR을 사용합니다.

회사에서 워크로드를 실행하기 위해 Amazon ECS 클러스터를 구현하고 있습니다. 회사 아키텍처는 클러스터에서 여러 ECS 서비스를 실행합니다. 프런트 엔드의 Application Load Balancer, 여러 대상 그룹을 사용하여 트래픽을 라우팅합니다. 애플리케이션 개발 팀은 거의 실시간 분석을 위해 수집하여 Amazon S3 버킷으로 전송해야 하는 로그를 수집하는 데 어려움을 겪고 있습니다. DevOps 엔지니어는 이러한 요구 사항을 충족하기 위해 배포에서 무엇을 구성해야 합니까? (3 개 선택) A. ECS 인스턴스에 Amazon CloudWatch Logs 로깅 에이전트를 설치합니다. ECS 작업 정의의 로깅 드라이버를 'awslogs'로 변경합니다. B. AWS에서 Amazon CloudWatch Logs 컨테이너 인스턴스를 다운로드하고 작업으로 구성합니다. 로깅 태스크를 포함하도록 애플리케이션 서비스 정의를 업데이트하십시오. C. Amazon CloudWatch Events를 사용하여 create-export -task CloudWatch Logs 명령을 실행하여 60 초마다 실행되는 AWS Lambda 함수를 예약 한 다음 출력을 로깅 S3 버킷으로 지정합니다. D. Application Load Balancer에서 액세스 로깅을 활성화 한 다음 S3 로깅 버킷을 직접 가리 킵니다. E. ECS 서비스에서 사용하는 대상 그룹에서 액세스 로깅을 활성화 한 다음 S3 로깅 버킷을 직접 가리 킵니다. F. S3 로깅 버킷의 대상으로 Amazon Kinesis Data Firehose를 생성 한 다음 Kinesis에 대한 Amazon CloudWatch Logs 구독 필터를 생성합니다.

ADF

DevOps 엔지니어가 Amazon EC2 인스턴스에서 이미 워크로드를 실행중인 새로운 회사에 합류했습니다. AWS는 중앙 거버넌스없이 점진적으로 채택되었습니다. 엔지니어는 이제 기존 배포가 다음 요구 사항을 얼마나 잘 준수하는지 평가해야 합니다. ▶ EC2 인스턴스는 승인된 AMI 만 실행합니다. ▶ Amazon EBS 볼륨은 암호화됩니다. ▶ EC2 인스턴스에는 소유자 태그가 있습니다. ▶ SSH를 통한 루트 로그인은 EC2 인스턴스에서 비활성화됩니다. 엔지니어는 최소한의 노력으로 이 평가를 수행하기 위해 어떤 서비스를 사용해야합니까? (2 개 선택) A. AWS 구성 B. Amazon GuardDuty C. AWS 시스템 관리자 D. AWS 디렉터리 서비스 E. Amazon Inspector

AWS CodePipeline 파이프 라인은 코드 릴리스 프로세스를 구현했습니다. 파이프 라인은 AWS CodeDeploy와 통합되어 각 CodePipeline 단계의 여러 Amazon EC2 인스턴스에 애플리케이션 버전을 배포합니다. 최근 배포 중에 CodeDeploy 문제로 인해 파이프 라인이 실패했습니다. DevOps 팀은 배포 중 모니터링 및 알림을 개선하여 해결 시간을 단축하고자 합니다. DevOps 엔지니어는 문제가 발견될 때 알림을 생성하기 위해 무엇을 해야 합니까? A. CodePipeline 및 CodeDeploy에 대한 AWS CloudWatch Logs를 구현하고, 코드 배포 문제를 평가하기위한 AWS Config 규칙을 생성하고, 배포 문제를 이해 관계자에게 알리는 Amazon SNS 주제를 생성합니다. B. CodePipeline 및 CodeDeploy에 대한 AWS CloudWatch Events를 구현하고, 코드 배포 문제를 평가하기위한 AWS Lambda 함수를 생성하고, 배포 문제를 이해 관계자에게 알리는 Amazon SNS 주제를 생성합니다. C. AWS CloudTrail을 구현하여 CodePipeline 및 CodeDeploy API 호출 정보를 기록하고 AWS Lambda 함수를 생성하여 코드 배포 문제를 평가하고 Amazon SNS 주제를 생성하여 이해 관계자에게 배포 문제를 알립니다. D. CodePipeline 및 CodeDeploy에 대한 AWS CloudWatch Events를 구현하고 Amazon Inspector 평가 대상을 생성하여 코드 배포 문제를 평가하고 Amazon SNS 주제를 생성하여 이해 관계자에게 배포 문제를 알립니다.

DevOps 엔지니어가 웹 애플리케이션에 대한 배포 전략을 설계하고 있습니다. 애플리케이션은 Auto Scaling 그룹을 사용하여 AMI를 사용하여 Amazon EC2 인스턴스를 시작합니다. 동일한 인프라가 여러 환경 (개발, 테스트 및 품질 보증)에 배포됩니다. 배포 전략은 다음 요구 사항을 충족해야 합니다. ▶ 인스턴스의 시작 시간 최소화 ▶ 동일한 AMI가 여러 환경에서 작동하도록 허용 ▶ 여러 환경에 대한 비밀을 안전하게 저장 어떻게해야합니까? A. Amazon EC2 인스턴스를 시작하는 AWS Lambda 함수를 사용하여 AMI를 사전 구성한 다음 스크립트를 실행하여 소프트웨어를 설치하고 AMI를 생성합니다. Auto Scaling 수명주기 후크를 구성하여 인스턴스가 시작되는 환경을 결정하고 그 결과에 따라 구성 스크립트를 실행합니다. .ini 파일에 비밀을 저장하고 Amazon S3에 저장합니다. EC2 사용자 데이터의 구성 스크립트를 사용하여 비밀을 검색합니다. B. AWS Systems Manager 자동화를 사용하여 모든 소프트웨어를 설치하여 AMI를 사전 구성하고 시작 시 인스턴스에 특정 환경에 태그를 지정하도록 Auto Scaling을 구성합니다. 그런 다음 사용자 데이터에서 부트 스트랩 스크립트를 사용하여 태그를 읽고 환경 설정을 구성합니다. AWS Systems Manager Parameter Store를 사용하여 AWS KMS를 사용하여 암호를 저장합니다. C. AWS Marketplace의 표준 AMI를 사용합니다. 현재 환경을 감지하도록 Auto Scaling을 구성합니다. Amazon EC2 사용자 데이터의 스크립트를 사용하여 소프트웨어를 설치합니다. AWS Secrets Manager를 사용하여 모든 환경에 대한 자격 증명을 저장합니다. D. 모든 환경에 대한 모든 소프트웨어 및 구성을 설치하여 AMI를 사전 구성합니다. 시작 시 인스턴스에 해당 환경에 태그를 지정하도록 Auto Scaling을 구성합니다. Amazon EC2 사용자 데이터를 사용하여 인스턴스 ID를 읽은 다음 적절한 환경에 맞게 설정을 재구성하는 AWS Lambda 함수를 트리거 합니다. AWS Systems Manager Parameter Store를 사용하여 AWS KMS를 사용하여 암호를 저장합니다.

DevOps 엔지니어는 PHP 애플리케이션 배포를 담당합니다. 엔지니어는 온 프레미스 서버와 Amazon EC2 인스턴스 모두에서 실행되는 애플리케이션과 함께 하이브리드 배포에서 작업하고 있습니다. 애플리케이션은 매우 기밀 정보가 포함된 데이터베이스에 액세스해야 합니다. 애플리케이션 인스턴스는 데이터베이스 자격 증명에 대한 액세스 권한이 필요합니다. 데이터베이스 자격 증명은 인스턴스에 도달하기 전에 저장 및 전송 중에 암호화되어야 합니다. 엔지니어는 보안 요구 사항을 충족하면서 배포 프로세스를 어떻게 자동화해야 합니까? A. PHP 플랫폼 구성과 함께 AWS Elastic Beanstalk를 사용하여 애플리케이션 패키지를 인스턴스에 배포합니다. 보안 문자열 데이터 유형을 사용하여 AWS Systems Manager Parameter Store에 데이터베이스 자격 증명을 저장합니다. 액세스를 허용하는 Amazon EC2에 대한 IAM 역할을 정의하고 데이터베이스 자격 증명 만 해독합니다. 이 역할을 모든 인스턴스에 연결합니다. B. AWS CodeDeploy를 사용하여 인스턴스에 애플리케이션 패키지를 배포합니다. 보안 문자열 데이터 유형을 사용하여 AWS Systems Manager Parameter Store에 데이터베이스 자격 증명을 저장합니다. 액세스를 허용하기위한 IAM 정책을 정의하고 데이터베이스 자격 증명 만 해독합니다. IAM 정책을 CodeDeploy 관리 형 인스턴스의 인스턴스 프로필에 연결된 역할과 CodeDeploy에서 온 프레미스 인스턴스 등록에 사용되는 역할에 연결합니다. C. AWS CodeDeploy를 사용하여 인스턴스에 애플리케이션 패키지를 배포합니다. 보안 문자열 데이터 유형을 사용하여 AWS Systems Manager Parameter Store에 데이터베이스 자격 증명을 저장합니다. 데이터베이스 자격 증명의 암호 해독을 허용하는 연결된 정책으로 IAM 역할을 정의합니다. 이 역할을 모든 인스턴스 및 온 프레미스 서버에 연결합니다. D. AWS CodeDeploy를 사용하여 인스턴스에 애플리케이션 패키지를 배포합니다. AppSpec file에 데이터베이스 자격 증명을 저장합니다. 데이터베이스 자격 증명에만 액세스 할 수 있도록 IAM 정책을 정의합니다. CodeDeploy 관리 형 인스턴스의 인스턴스 프로필에 연결된 역할과 CodeDeploy의 온 프레미스 인스턴스 등록에 사용되는 역할에 IAM 정책을 연결합니다.

DevOps 엔지니어는 웹 사이트의 페이지로드 시간이 갑작스럽게 급증하고 최근 배포가 발생했음을 발견했습니다. 관련 커밋의 간단한 차이점은 외부 API 호출의 URL이 변경되고 연결 포트가 80에서 443으로 변경되었음을 보여줍니다. 외부 API가 확인되었으며 애플리케이션 외부에서 작동합니다. 애플리케이션 로그에 연결 시간이 초과되어 여러 번 재 시도하고 결국 호출이 실패하는 것으로 표시됩니다. 엔지니어는 문제의 근본 원인을 확인하기 위해 어떤 디버그 단계를 수행해야합니까? A. VPC 흐름 로그에서 웹 Auto Scaling 그룹의 일부인 Amazon EC2 인스턴스에서 발생하는 거부를 찾습니다. VPC에 대한 수신 보안 그룹 규칙 및 라우팅 규칙을 확인하십시오. B. VPC에 대한 기존 송신 보안 그룹 규칙 및 네트워크 ACL을 확인합니다. 또한 디버그 정보는 Amazon CloudWatch Logs에 기록되는 애플리케이션 로그를 확인하십시오. C. VPC에 대한 송신 보안 그룹 규칙 및 네트워크 ACL을 확인합니다. 또한 웹 Auto Scaling 그룹에서 시작된 수락을 찾고있는 VPC 흐름 로그를 확인합니다. D. 디버그 정보는 Amazon CloudWatch Logs에 기록되는 애플리케이션 로그를 확인합니다. VPC에 대한 수신 보안 그룹 규칙 및 라우팅 규칙을 확인하십시오.

DevOps 엔지니어는 자동화된 방식으로 Linux AMI를 생성해야 합니다. 새로 생성된 AMI ID는 다른 빌드 파이프 라인이 프로그래밍 방식으로 새 ID에 액세스 할 수 있는 위치에 저장되어야 합니다. 이를 수행하는 가장 비용 효율적인 방법은 무엇입니까? A. AWS CodePipeline에서 파이프 라인을 구축하여 최신 운영 체제 OVF (Open Virtualization Format) 이미지를 Amazon S3 버킷에 다운로드하고 저장 한 다음 guestfish 유틸리티를 사용하여 이미지를 사용자 지정합니다. 가상 머신 (VM) import 명령을 사용하여 OVF를 AMI로 변환하고 AMI 식별 출력을 AWS Systems Manager 파라미터로 저장합니다. B. 이미지 생성 방법을 지시하는 값으로 AWS Systems Manager 자동화 문서를 생성합니다. 그런 다음 AWS CodePipeline에서 파이프 라인을 구축하여 트리거 될 때 AMI를 구축하는 자동화 문서를 실행합니다. AMI 식별 출력을 Systems Manager 파라미터로 저장합니다. C. AWS CodePipeline에서 파이프 라인을 구축하여 최신 버전의 애플리케이션을 실행하는 Amazon EC2 인스턴스의 스냅 샷을 생성합니다. 그런 다음 스냅 샷에서 새 EC2 인스턴스를 시작하고 AWS Lambda 함수를 사용하여 실행중인 인스턴스를 업데이트합니다. 업데이트 된 인스턴스의 스냅 샷을 생성한 다음 AMI로 변환합니다. AMI 식별 출력을 Amazon DynamoDB 테이블에 저장합니다. D. Amazon EC2 인스턴스를 시작하고 Packer를 설치합니다. 그런 다음 이미지 생성 방법을 정의하는 값으로 Packer 빌드를 구성합니다. Jenkins 파이프 라인을 빌드하여 AMI 빌드를 트리거 할 때 Packer 빌드를 호출합니다. AMI 식별 출력을 Amazon DynamoDB 테이블에 저장합니다.

DevOps 엔지니어는 전자 상거래 플랫폼의 트랜잭션을 처리하는 재무 팀 지불 마이크로 서비스의 모니터링을 개선해야합니다. 마이크로 서비스는 여러 Amazon EC2 인스턴스에서 실행됩니다. 재무 팀은 분당 지불 횟수를 알고 싶어하며 이 측정 항목이 지정된 임계 값 아래로 떨어질 때 팀에 알림을 받고자 합니다. 이를 비용 효율적으로 자동화할 수 있는 방법은 무엇입니까? A. 개발 팀이 성공적인 트랜잭션을 응용 프로그램 로그에 기록하도록 합니다. Amazon ES 클러스터로 로그를 보내는 각 인스턴스에 Logstash를 설정합니다. 지표를 그래프로 표시하는 재무 팀용 Kibana 대시 보드를 생성합니다. B. 개발 팀이 성공적인 트랜잭션 수를 Amazon CloudWatch에 사용자 지정 지표로 게시하도록 합니다. 임계 값 위반시 CloudWatch 경보를 생성하고 Amazon SNS를 사용하여 재무 팀에 알립니다. C. 개발 팀이 성공적인 트랜잭션을 응용 프로그램 로그에 기록하도록 합니다. 각 인스턴스에서 애플리케이션 로그를 CloudWatch Logs로 보내도록 Amazon CloudWatch Logs 에이전트를 설정합니다. EC2 인스턴스를 사용하여 지표 필터를 모니터링하고 재무 팀에 알림을 보냅니다. D. 개발 팀이 성공적인 트랜잭션을 응용 프로그램 로그에 기록하도록 합니다. 각 인스턴스에서 Amazon CloudWatch 에이전트를 설정합니다. 임계 값 위반시 CloudWatch 경보를 생성하고 Amazon SNS를 사용하여 재무 팀에 알립니다.

IT 팀이 AWS CloudFormation 템플릿을 구축하여 회사의 다른 직원이 애플리케이션을 빠르고 안정적으로 배포하고 종료할 수 있습니다. 템플릿은 애플리케이션을 설치하기위한 사용자 데이터 스크립트와 애플리케이션이 실행되는 동안 정적 웹 페이지를 제공하는 데 사용하는 Amazon S3 버킷으로 Amazon EC2 인스턴스를 생성합니다. CloudFormation 스택이 삭제되면 모든 리소스를 제거해야 합니다. 그러나 팀은 CloudFormation이 스택 삭제 중에 오류를 보고하고 스택에 의해 생성된 S3 버킷이 삭제되지 않음을 관찰합니다. 모든 리소스가 오류 없이 삭제되도록 하려면 팀이 가장 효율적인 방식으로 오류를 해결하는 방법은 무엇입니까? A. DeletionPolicy 속성을 S3 버킷 리소스에 추가하고 Delete 값을 사용하면 스택이 삭제 될 때 버킷이 제거됩니다. B. S3 버킷을 지정하는 DependsOn 속성과 IAM 역할이있는 AWS Lambda 함수가있을 때 사용자 지정 리소스를 추가합니다. RequestType이 Delete 인 경우 Lambda 함수를 작성하여 버킷에서 모든 객체를 삭제합니다. C. 삭제되지 않은 리소스를 식별합니다. S3 콘솔에서 S3 버킷을 비운 다음 삭제합니다. D. EC2 및 S3 버킷 리소스를 단일 AWS OpsWorks Stacks 리소스로 바꿉니다. 스택에 대한 사용자 지정 레시피를 정의하여 EC2 인스턴스와 S3 버킷을 생성 및 삭제합니다.

개발 팀이 전자 상거래 애플리케이션에 새로운 국가를 추가하고 있습니다. 이 추가 기능을 사용하려면 새로운 애플리케이션 기능이 애플리케이션의 제공 구성 요소에 추가 되어야합니다. 일부 기능은 빌드하는 데 약 6 주가 걸리므로 팀은 모든 새로운 기능을 추가해야 하는지 결정하지 않았습니다. 배송 구성 요소 기능에 대한 최종 결정이 내려지는 동안 다른 팀 구성원은 계속해서 응용 프로그램의 다른 기능에 대해 작업합니다. 이 상황을 기반으로 애플리케이션 기능 배포를 어떻게 관리해야 합니까? A. 코드 업데이트를 릴리스 브랜치에 커밋으로 추가합니다. 팀은 모든 기능이 준비될 때까지 배포를 지연할 수 있습니다. B. 코드 업데이트를 기능 브랜치에 커밋으로 추가합니다. 기능이 준비되면 커밋을 릴리스 브랜치에 병합합니다. C. 기능이 준비되면 코드 업데이트를 단일 커밋으로 추가합니다. 이 커밋을 "new-country"로 태그 지정합니다. D. "new-country"라는 새 저장소를 만듭니다. 모든 코드 변경 사항을 새 저장소에 커밋합니다.

대기업이 AWS에 웹 애플리케이션을 배포하고 있습니다. 애플리케이션은 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행됩니다. 인스턴스는 여러 가용 영역에 걸쳐 Auto Scaling 그룹에서 실행됩니다. 이 애플리케이션은 Amazon RDS Oracle DB 인스턴스와 Amazon DynamoDB에 데이터를 저장합니다. 개발, 테스트 및 프로덕션을위한 별도의 환경이 있습니다. 배포 중에 암호 자격 증명을 얻는 가장 안전하고 유연한 방법은 무엇입니까? A. AWS 서비스에 액세스하려면 AWS Systems Manager SecureString 파라미터에서 액세스 키를 검색합니다. Systems Manager SecureString 파라미터에서 데이터베이스 자격 증명을 검색합니다. B. EC2 IAM 역할로 EC2 인스턴스를 시작하여 AWS 서비스에 액세스합니다. AWS Secrets Manager에서 데이터베이스 자격 증명을 검색합니다. C. AWS 서비스에 액세스하려면 AWS Systems Manager 일반 텍스트 파라미터에서 액세스 키를 검색합니다. Systems Manager SecureString 파라미터에서 데이터베이스 자격 증명을 검색합니다. D. EC2 IAM 역할로 EC2 인스턴스를 시작하여 AWS 서비스에 액세스합니다. 애플리케이션 아티팩트와 함께 암호화 된 구성 파일에 데이터베이스 비밀번호를 저장하십시오.

배포 팀은 최근 몇 달 동안 크게 성장했으며 별도의 코드 리포지토리를 사용하는 프로젝트 수도 증가했습니다. 현재 프로세스에는 수동으로 AWS CodePipeline 구성이 포함되며 Amazon S3 버킷 수에 대한 서비스 제한 알림이 있습니다. S3 버킷 스프롤 경고를 줄이는 파이프 라인 옵션은 무엇입니까? A. 여러 개의 개별 코드 리포지토리를 단일 리포지토리로 결합하고 각 프로젝트에 대한 로직이있는 글로벌 AWS CodePipeline을 사용하여 배포합니다. B. AWS API 또는 AWS CLI를 사용하여 새 파이프 라인을 생성하고 각 프로젝트에 대해 별도의 접두사가있는 단일 글로벌 S3 버킷을 사용하도록 구성합니다. C. 단일 지역의 S3 버킷에 대한 서비스 제한을 우회하기 위해 각 프로젝트에 대해 다른 지역에 새 파이프 라인을 생성합니다. D. AWS API 또는 AWS CLI를 사용하여 단일 계정의 S3 버킷에 대한 서비스 제한을 우회하여 각 프로젝트에 대한 새 파이프 라인 및 S3 버킷을 생성합니다.

소셜 네트워킹 서비스는 파트너가 공개 게시물을 검색할 수 있는 웹 API를 실행합니다. 게시 데이터는 Amazon DynamoDB에 저장되고 AWS에서 인덱싱 됩니다. Amazon ES 도메인이 인덱스를 저장하고 애플리케이션에 검색 기능을 제공하는 Lambda 함수. 이 서비스는 배포 중에 전체 용량을 유지하고 실패한 배포로 인해 다운 타임이 발생하거나 용량이 감소하지 않도록 하거나 후속 배포를 방해하지 않도록 해야 합니다. 이러한 요구 사항을 어떻게 충족할 수 있습니까? (2 개 선택) A. 배포 정책을 All at Once로 설정하여 AWS Elastic Beanstalk에서 웹 애플리케이션을 실행합니다. AWS CloudFormation 템플릿을 사용하여 Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다. B. AWS CloudFormation 템플릿에서 웹 애플리케이션, Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다. AWS CodeDeploy 인플레 이스 배포로 변경 사항을 배포합니다. C. 배포 정책을 변경 불가능으로 설정하여 AWS Elastic Beanstalk에서 웹 애플리케이션을 실행합니다. AWS CloudFormation 템플릿을 사용하여 Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다. D. AWS CloudFormation 템플릿에 웹 애플리케이션, Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다. AWS CodeDeploy 블루 / 그린 배포로 변경 사항을 배포합니다. E. 배포 정책을 Rolling으로 설정하여 AWS Elastic Beanstalk에서 웹 애플리케이션을 실행합니다. AWS CloudFormation 템플릿을 사용하여 Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다.

애플리케이션은 각각 Application Load Balancer로 구성된 두 개의 Amazon EC2 Auto Scaling 그룹과 함께 배포됩니다. 애플리케이션은 Auto Scaling 그룹 중 하나에 배포되고 Amazon Route 53 별칭 레코드는 마지막으로 배포 된 Auto Scaling 그룹의 Application Load Balancer를 가리 킵니다. 두 Auto Scaling 그룹간에 배포가 번갈아 나타납니다. 홈 보안 장치가 애플리케이션에 요청을 하고 있습니다. 개발 팀은 배포 후 이전 스택에 새 요청이 들어오고 있음을 확인합니다. 이 문제는 Amazon Route 53 별칭 레코드에서 TTL (Time to Live) 설정을 준수하지 않는 디바이스로 인해 발생합니다. DevOps 엔지니어는 최소한의 추가 리소스를 생성하면서 이전 스택으로 들어오는 요청 문제를 해결하기 위해 어떤 조치를 취해야합니까? A. Application Load Balancer 뒤에서 HAProxy를 실행하는 Amazon EC2 인스턴스 집합을 생성합니다. HAProxy 인스턴스는 기존 Auto Scaling 그룹 중 하나에 요청을 프록시 합니다. 배포 후 HAProxy 인스턴스가 업데이트되어 새로 배포된 Auto Scaling 그룹에 요청을 보냅니다. B. 애플리케이션을 하나의 Application Load Balancer로 줄입니다. Blue 및 Green이라는 두 개의 대상 그룹을 만듭니다. 단일 대상 그룹을 가리키는 Application Load Balancer에서 규칙을 생성합니다. 새로 배포된 Auto Scaling 그룹의 대상 그룹으로 Application Load Balancer 규칙을 업데이트하는 로직을 배포에 추가합니다. C. 두 가지 환경이 있는 AWS Elastic Beanstalk 애플리케이션으로 애플리케이션을 이동합니다. 비 라이브 환경에서 새 배포를 수행합니다. 배포 후 Elastic Beanstalk CNAME 스왑을 수행하여 새로 배포된 환경을 라이브 환경으로 만듭니다. D. Amazon CloudFront 배포를 생성합니다. 두 개의 기존 Application Load Balancer를 배포에서 오리진으로 설정합니다. 배포 후 새로 배포된 Auto Scaling 그룹에 요청을 보내도록 CloudFront 배포 동작을 업데이트합니다.

의료 회사는 AWS에서 실행되는 중요한 애플리케이션을 가지고 있습니다. 최근에 회사는 약간의 다운 타임을 경험했습니다. 다시 발생하면 회사는 다른 AWS 리전에서 애플리케이션을 복구 할 수 있어야합니다. 이 애플리케이션은 Elastic Load Balancing 및 Amazon EC2 인스턴스를 사용합니다. 이 회사는 애플리케이션이 포함 된 사용자 지정 AMI도 유지합니다. 이 AMI는 자주 변경됩니다. 워크로드는 지역 서비스 중단이 발생하지 않는 한 기본 지역에서 실행되어야 합니다 이 경우 트래픽이 새 지역으로 장애 조치되어야 합니다. 또한 두 번째 지역의 비용은 낮아야 합니다. RTO는 2 시간입니다. 장애 발생시 회사가 다른 지역으로 장애 조치하고 위의 요구 사항을 충족할 수 있는 솔루션은 무엇입니까? A. 백업 리전의 기본 리전에서 AMI 사본을 유지합니다. 복사된 AMI가 포함된 시작 구성을 사용하여 하나의 인스턴스로 Auto Scaling 그룹을 생성합니다. Amazon Route 53 레코드를 사용하여 필요에 따라 장애 발생시 백업 지역의 로드밸런서로 트래픽을 보냅니다. Auto Scaling 그룹이 장애 중에 필요에 따라 확장되도록 허용합니다. B. 메인 리전의 AMI를 백업 리전으로 복사하는 작업을 자동화합니다. AMI에서 EC2 인스턴스를 생성하고 로드밸런서 뒤에 배치할 AWS Lambda 함수를 생성합니다. 동일한 Lambda 함수를 사용하여 Amazon Route 53 레코드가 백업 리전의 로드밸런서를 가리 키도록 합니다. 실패 시 Lambda 함수를 트리거 합니다. C. 복제 된 Amazon S3 버킷에 AMI를 배치합니다. 시작 구성을 생성하고 이미 생성된 Auto Scaling 그룹에 할당할 수 있는 AWS Lambda 함수를 생성합니다. 이 Auto Scaling 그룹에 하나의 인스턴스가 트래픽을 허용할 준비가 되어 있습니다. 실패 시 Lambda 함수를 트리거 합니다. Amazon Route 53 레코드를 사용하고 백업 리전의로드 밸런서를 가리 키도록 동일한 Lambda 함수로 수정합니다. D. 백업 리전에 AMI 복사를 자동화합니다. 시작 구성을 생성하고 이미 생성된 Auto Scaling 그룹에 할당할 수 있는 AWS Lambda 함수를 생성합니다. Auto Scaling 그룹 최대 크기를 0으로 설정하고 실패 시 Lambda 함수로만 늘리십시오. 실패 시 Lambda 함수를 트리거 합니다. Amazon Route 53 레코드를 사용하고 백업 리전의로드 밸런서를 가리 키도록 동일한 Lambda 함수로 수정합니다.

재해 복구 연습을 수행한 후 엔터프라이즈 아키텍트는 대규모 데이터베이스 및 스토리지 관리자 팀이 주력 애플리케이션의 데이터베이스가 다른 AWS 리전에서 작동하도록 하려면 7 시간 이상의 수동 작업이 필요하다는 사실을 발견했습니다. 또한 아키텍트는 복구된 데이터베이스에 2 시간 정도의 데이터 트랜잭션이 누락되는 경우가 많습니다. 지역 간 장애 조치 시나리오에서 개선된 RTO 및 RPO를 제공하는 솔루션은 무엇입니까? A. 다중 리전 Amazon EFS에서 지원하는 Amazon RDS 다중 AZ 인스턴스를 배포합니다. 지역 간 복구 및 연속 데이터 복제의 기본 자동화를 위해 다중 지역 가용성을 활성화하도록 RDS 옵션 그룹을 구성합니다. 단일 가용 영역에서 중요한 쿼리 지연 시간이 감지되면 RDS 영향 이벤트를 구독하는 Amazon SNS 주제를 생성하여 데이터베이스 관리 팀에 이메일을 보냅니다. B. Amazon SNS 주제를 사용하여 Amazon RDS 가용성 및 백업 이벤트에서 게시 된 메시지를 수신합니다. Amazon RDS를 호출하여 데이터베이스 인스턴스를 스냅 샷하고, 교차 리전 스냅 샷 사본을 생성하고, 스냅 샷에서 인스턴스를 복원하는 세 가지 개별 함수에 AWS Lambda를 사용합니다. RPO와 일치하는 빈도로 예약된 Amazon CloudWatch Events 규칙을 사용하여 Lambda 함수를 트리거 하여 데이터베이스 인스턴스를 스냅샷 합니다. 백업 이벤트에 대한 SNS 주제가 새 메시지를 수신하면 Lambda 함수를 트리거 하여 교차 리전 스냅 샷 복사본을 생성합니다. 가용성 SNS 주제에 게시된 새 메시지 전송을 트리거 하도록 스냅 샷에서 인스턴스를 복원하도록 Lambda 함수를 구성합니다. C. 예약 된 Amazon CloudWatch Events 규칙을 생성하여 Amazon RDS를 호출하여 데이터베이스 인스턴스에서 스냅 샷을 생성하고 RPO와 일치하는 빈도를 지정합니다. AWS Step Functions 작업을 생성하여 Amazon RDS를 호출하여 장애 조치 지역으로 교차 리전 스냅 샷 복사를 수행하고 RDS 스냅 샷 생성 상태가 완료되면 작업을 실행하도록 상태 시스템을 구성합니다. RDS 가용성 이벤트를 구독하는 SNS 주제를 생성하고 이러한 메시지를 장애 조치 지역에 있는 Amazon SQS 대기열로 푸시 합니다. Auto Scaling 작업자 노드 그룹을 구성하여 새 메시지에 대한 대기열을 폴링하고 Amazon RDS를 호출하여 리전 간 복사된 스냅 샷의 체크 섬 이 유효한 것으로 반환 된 후 스냅 샷에서 데이터베이스를 복원합니다. D. Amazon RDS 예약 인스턴스 수명주기 이벤트를 사용하여 스냅 샷을 생성하고 RPO와 일치하는 빈도를 지정합니다. Amazon RDS 예약 인스턴스 수명주기 이벤트 구성을 사용하여 SnapshotCreateComplete 이벤트시 장애 조치 지역으로 교차 리전 스냅 샷 복사를 수행합니다. 데이터베이스 인스턴스에 대한 CloudWatch RDS 네임 스페이스 CPUUtilization 지표가 0 %로 떨어지면 경고하도록 Amazon CloudWatch를 구성하고 Amazon RDS를 호출하여 장애 조치 리전에서 데이터베이스 스냅 샷을 복원합니다.

정부 기관이 암호화된 Amazon S3 버킷에 기밀 파일을 저장하고 있습니다. 에이전시는 연합 액세스를 구성했으며 특정 온-프레미스 Active Directory 사용자 그룹 만이 버킷에 액세스하도록 허용했습니다. 이 기관은 감사 기록을 유지하고 관리자가 이 제한된 연동 액세스를 제공하는 데 사용되는 IAM 정책에 대한 실수로 변경 한 사항을 자동으로 감지하고 되돌리려 고합니다. 다음 옵션 중 이러한 요구 사항을 충족하는 가장 빠른 방법을 제공하는 것은 무엇입니까? A. 변경을 감지하고 되 돌리는 AWS Lambda 함수를 트리거 하기 위해 AWS CloudTrail API에서 Amazon CloudWatch Events 이벤트 버스를 구성합니다. B. 구성 변경을 감지하도록 AWS Config 규칙을 구성하고 AWS Lambda 함수를 실행하여 변경 사항을 되돌립니다. C. 변경 사항을 감지하고 되돌리기 위해 연동 액세스 역할에 연결된 IAM 정책을 스캔하는 AWS Lambda 함수를 예약합니다. D. 온 프레미스 Active Directory의 관리자가 IAM 정책을 변경하지 못하도록 제한합니다.

한 소매 회사가 배포 관리를 위해 AWS OpsWorks를 채택했습니다. 지난 3 개월 동안 회사는 일부 프로덕션 인스턴스가 이유없이 다시 시작되었음을 발견했습니다. AWS CloudTrail 로그를 검사 한 DevOps 엔지니어는 해당 인스턴스가 OpsWorks에 의해 다시 시작되었음을 확인했습니다. 엔지니어는 이제 인스턴스가 비정상이거나 서비스 엔드 포인트와 통신할 수 없는 것으로 간주될 때 OpsWorks가 인스턴스를 다시 시작할 때마다 자동화된 이메일 알림을 원합니다. 엔지니어는 이 요구 사항을 어떻게 충족할 수 있습니까? A. OpsWorks 에이전트가 인스턴스 오류를 감지하면 Amazon SES를 사용하여 팀에 이메일을 보내는 Amazon EC2 인스턴스 내에서 사용자 지정 스크립트를 실행하는 크론을 배치하는 Chef 레시피를 생성합니다. B. Amazon SNS 주제를 생성하고 대상 이메일 주소가 포함 된 이 주제에 대한 구독을 생성합니다. Amazon CloudWatch 규칙 생성 : 소스로 지정하고 initialized_by 세부 정보에서 자동 복구를 지정합니다. SNS 주제를 대상으로 사용합니다. aws.opsworks C. Amazon SNS 주제를 생성하고 대상 이메일 주소가 포함 된 이 주제에 대한 구독을 생성합니다. Amazon CloudWatch 규칙을 생성하여 소스로 지정하고 initialized_by 세부 정보에서 인스턴스 교체를 지정합니다. SNS 주제를 대상으로 사용합니다. aws.opsworks D. 이메일 주소가 포함 된 이 주제에 대한 구독을 생성합니다. OpsWorks 계층 내에서 인스턴스 다시 시작 알림을 활성화하고 알림의 대상 이메일 주소를 표시합니다.

한 회사가 AWS CodeDeploy를 채택하여 Apache 웹 서버와 함께 Java-Apache Tomcat 애플리케이션에 대한 애플리케이션 배포를 자동화하고 있습니다. 그만큼 개발 팀은 개념 증명으로 시작하여 개발자 환경을 위한 배포 그룹을 만들고 애플리케이션 내에서 기능 테스트를 수행했습니다. 완료 후 팀은 스테이징 및 프로덕션을 위한 추가 배포 그룹을 만듭니다. 현재 로그 수준은 Apache 설정 내에서 구성되지만 팀은 배포가 발생할 때이 구성을 동적으로 변경하여 각 그룹에 대해 다른 애플리케이션 개정을 사용하지 않고도 배포 그룹에 따라 다른 로그 수준 구성을 설정할 수 있기를 원합니다. 각 배포 그룹에 대해 다른 스크립트 버전을 요구하지 않고 최소 관리 오버 헤드로 이러한 요구 사항을 어떻게 충족할 수 있습니까? A. 배포 그룹에 따라 Amazon EC2 인스턴스에 태그를 지정합니다. 그런 다음 메타 데이터 서비스 및 EC2 API를 호출하는 스크립트를 애플리케이션 개정에 배치하여 인스턴스가 속한 배포 그룹을 식별합니다. 이 정보를 사용하여 로그 수준 설정을 구성합니다. appspec.yml 파일에서 Afterinstall 수명주기 후크의 일부로 스크립트를 참조합니다. B. CodeDeploy 환경 변수 DEPLOYMENT_GROUP_NAME을 사용하여 인스턴스가 속한 배포 그룹을 식별하는 스크립트를 생성합니다. 이 정보를 사용하여 로그 수준 설정을 구성합니다. appspec.yml 파일에서 BeforeInstall 수명주기 후크의 일부로 이 스크립트를 참조하세요. C. 각 환경에 대한 CodeDeploy 사용자 지정 환경 변수를 생성합니다. 그런 다음이 환경 변수를 확인하는 스크립트를 애플리케이션 개정에 배치하여 인스턴스가 속한 배포 그룹을 식별합니다. 이 정보를 사용하여 로그 수준 설정을 구성합니다. appspec.yml 파일에서 ValidateService 라이프 사이클 후크의 일부로 이 스크립트를 참조하십시오. D. CodeDeploy 환경 변수 DEPLOYMENT_GROUP_ID를 사용하여 로그 수준 설정을 구성하기 위해 인스턴스가 속한 배포 그룹을 식별하는 스크립트를 생성합니다. 이 스크립트를 appspec.yml 파일에서 설치 라이프 사이클 후크의 일부로 참조하십시오

한 회사가 AWS에서 실행되는 인프라 리소스에 대한 태깅 및 구성 표준을 수립했습니다. DevOps 엔지니어는 위반 사항을 강조 할 수 있는 기능과 함께 규정 준수 상태의 거의 실시간 대시 보드를 제공하는 설계를 개발하고 있습니다. 명시된 요구 사항을 충족하는 접근 방식은 무엇입니까? A. AWS Service Catalog에서 리소스 구성을 정의하고 Amazon CloudWatch에서 AWS Service Catalog 규정 준수 및 위반을 모니터링합니다. 그런 다음 라이브 CloudWatch 대시 보드를 설정하고 공유합니다. 위반 및 수정에 대한 Amazon SNS 알림을 설정합니다. B. AWS Config를 사용하여 구성 변경 사항을 기록하고 데이터를 Amazon S3 버킷에 출력합니다. 데이터 세트의 Amazon QuickSight 분석을 생성하고 대시 보드 및 모바일 장치의 정보를 사용합니다. C. 지정된 태그 가 있는 리소스와 태그 가 없는 리소스를 표시하는 리소스 그룹을 만듭니다. AWS Management Console을 사용하여 규정 준수 및 비준수 리소스를 확인합니다. D. Amazon inspector에서 규정 준수 및 태그 지정 요구 사항을 정의합니다. 결과를 Amazon CloudWatch Logs에 출력합니다. 모니터링되는 관심 요소를 격리하고 CloudWatch 대시 보드에 데이터를 표시하는 지표 필터를 구축합니다.

한 회사가 Amazon Route 53, AWS Elastic Beanstalk 및 Amazon RDS를 사용하는 단일 AWS 계정에서 프로덕션 애플리케이션 워크로드를 실행합니다. 보안 사고가 발생하는 경우 보안 팀은 애플리케이션 워크로드가 새 AWS 계정으로 장애 조치되기를 원합니다. 보안 팀은 포렌식 분석 중에 원래 AWS 계정의 AWS 리소스에 대한 액세스 권한없이 즉시 원래 계정에 대한 모든 액세스를 차단하려고 합니다. 보안 사고가 발생하기 전에 두 번째 계정으로 장애 조치를 준비하는 가장 비용 효율적인 방법은 무엇입니까? A. Amazon Route 53 구성을 전용 AWS 계정으로 마이그레이션합니다. 다른 계정에서 Elastic Beanstalk 구성을 미러링 합니다. 다른 계정에서 RDS 데이터베이스 읽기 전용 복제본을 활성화합니다. B. Amazon Route 53 구성을 전용 AWS 계정으로 마이그레이션합니다. 다른 AWS 계정에 Elastic Beanstalk 구성 파일을 저장 / 복사합니다. RDS 데이터베이스의 스냅 샷을 다른 계정에 복사합니다. C. 사고 후 다른 AWS 계정에서 사용할 수 있도록 Amazon Route 53 구성을 저장 / 복사합니다. Elastic Beanstalk 구성 파일을 다른 계정에 저장 / 복사합니다. 다른 계정에서 RDS 데이터베이스 읽기 전용 복제본을 활성화합니다. D. 사고 후 다른 AWS 계정에서 사용할 수 있도록 Amazon Route 53 구성을 저장 / 복사합니다. 다른 계정에서 Elastic Beanstalk의 구성을 미러링 합니다. RDS 데이터베이스의 스냅 샷을 다른 계정에 복사합니다.

한 회사가 Amazon S3 버킷에서 호스팅되는 정적 웹 사이트를 개발했습니다. 웹 사이트는 AWS CloudFormation을 사용하여 배포됩니다. CloudFormation 템플릿은 S3 버킷과 소스 위치에서 버킷으로 콘텐츠를 복사하는 사용자 지정 리소스를 정의합니다. 회사는 웹 사이트를 새 위치로 이동해야 하므로 기존 CloudFormation 스택을 삭제하고 다시 만들어야 한다고 결정했습니다. 하나 CloudFormation은 스택을 완전히 삭제할 수 없다고 보고합니다. 가장 가능성이 높은 원인은 무엇이며 DevOps 엔지니어는 웹 사이트의 현재 버전과 향후 버전에서 이 문제를 어떻게 완화할 수 있습니까? A. S3 버킷에 활성 웹 사이트 구성이 있으므로 삭제에 실패했습니다. CloudFormation 템플릿을 수정하여 S3 버킷 리소스에서 WebsiteConfiguration 속성을 제거합니다. B. S3 버킷이 비어 있지 않아 삭제에 실패했습니다. 삭제 시 버킷을 재귀 적으로 비우도록 사용자 지정 리소스의 AWS Lambda 함수 코드를 수정합니다. RequestType C. 사용자 지정 리소스가 삭제 정책을 정의하지 않아 삭제에 실패했습니다. RemoveOnDeletion 값을 사용하여 사용자 지정 리소스 정의에 DeletionPolicy 속성을 추가합니다. D. S3 버킷이 비어 있지 않아 삭제에 실패했습니다. CloudFormation 템플릿에서 S3 버킷 리소스를 수정하여 값이 Empty 인 DeletionPolicy 속성을 추가합니다

한 회사가 특정 병렬 처리 메커니즘을 실행하는 소프트웨어 솔루션을 만들고 있습니다. 소프트웨어는 일부 특수 시나리오에서 수십 대의 서버로 확장 할 수 있습니다. 이 솔루션은 라이센스 기반의 독점 라이브러리를 사용하므로 각 개별 서버에 하나의 전용 라이센스가 설치되어 있어야합니다. 이 회사는 200 개의 라이센스를 보유하고 있으며 최대 200 개의 서버 노드를 동시에 실행할 계획입니다. 회사는 다음 기능을 요청했습니다. ▶ 대규모 라이선스 사용을 자동화하는 메커니즘. ▶ 향후 사용할 수있는 대시 보드를 생성하여 언제든지 사용할 수있는 라이선스를 확인할 수 있습니다. 이러한 요구 사항을 충족하는 가장 효과적인 방법은 무엇입니까? A. 프라이빗 Amazon S3 버킷에 라이선스를 업로드합니다. 라이선스에 대한 매핑 섹션이 있는 AWS CloudFormation 템플릿을 생성합니다. 템플릿에서 서버를 시작할 Auto Scaling 그룹을 생성합니다. 사용자 데이터 스크립트에서 매핑 섹션에서 사용 가능한 라이선스를 얻습니다. Auto Scaling 수명주기 후크를 생성 한 다음 인스턴스가 종료 된 후이를 사용하여 매핑을 업데이트합니다. B. Amazon DynamoDB 테이블에 라이선스를 업로드합니다. Auto Scaling 그룹을 사용하여 서버를 시작하는 AWS CloudFormation 템플릿을 생성합니다. 사용자 데이터 스크립트에서 DynamoDB 테이블에서 사용 가능한 라이선스를 얻습니다. Auto Scaling 수명주기 후크를 생성 한 다음 인스턴스가 종료 된 후이를 사용하여 매핑을 업데이트합니다. C. 프라이빗 Amazon S3 버킷에 라이선스를 업로드합니다. S3에 저장된 라이선스 목록으로 Amazon SQS 대기열을 채웁니다. Auto Scaling 그룹을 사용하여 서버를 시작하는 AWS CloudFormation 템플릿을 생성합니다. 사용자 데이터 스크립트에서 SQS에서 사용 가능한 라이센스를 얻습니다. Auto Scaling 수명주기 후크를 생성 한 다음 인스턴스가 종료 된 후이를 사용하여 라이선스를 SQS에 다시 넣습니다. D. Amazon DynamoDB 테이블에 라이선스를 업로드합니다. --count 파라미터를 사용하여 서버를 시작하는 AWS CLI 스크립트를 생성하고 최소 : max 인스턴스를 시작합니다. 사용자 데이터 스크립트에서 DynamoDB 테이블에서 사용 가능한 라이선스를 얻습니다. 각 인스턴스를 모니터링하고 실패 할 경우 인스턴스를 교체 한 다음 DynamoDB 테이블을 수동으로 업데이트합니다.

한 회사는 일부 레거시 시스템이 온 프레미스로 유지되고 특정 서버 클러스터가 AWS로 이동되는 하이브리드 아키텍처 솔루션을 보유하고 있습니다. 회사는 레거시 시스템을 재구성 할 수 없으므로 클러스터 노드에는 클러스터의 일부인 각 서버에 대해 고정 된 호스트 이름과 로컬 IP 주소가 있어야합니다. DevOps 엔지니어는 3 개의 가용 영역 (AZ)에 걸쳐 고 가용성으로 6 노드 클러스터의 구성을 자동화하여 각 AZ의 특정 서브넷에 2 개의 탄력적 네트워크 인터페이스를 배치해야합니다. 각 노드의 호스트 이름과 로컬 IP 주소는 재부팅 또는 인스턴스 실패간에 동일하게 유지되어야합니다. 이 작업을 자동화하는 데 최소한의 노력이 필요한 솔루션은 무엇입니까? A. 클러스터의 각 서버에 대해 AWS Elastic Beanstalk 애플리케이션과 특정 환경을 생성합니다. 각 환경에 대해 호스트 이름, 탄력적 네트워크 인터페이스 및 AZ를 입력 매개 변수로 제공합니다. 로컬 상태 에이전트를 사용하여 인스턴스 이름을 지정하고 현재 환경을 기반으로 특정 탄력적 네트워크 인터페이스를 연결합니다. B. 재사용 가능한 AWS CloudFormation 템플릿을 생성하여 최소 크기가 1이고 최대 크기가 1 인 Amazon EC2 Auto Scaling 그룹을 관리합니다. 호스트 이름, 탄력적 네트워크 인터페이스 및 AZ를 스택 파라미터로 지정합니다. 이러한 파라미터를 사용하여 EC2 Auto Scaling 및 사용자 데이터 스크립트로 EC2 인스턴스를 설정하여 특정 탄력적 네트워크 인터페이스에 연결합니다. CloudFormation 중첩 스택을 사용하여 클러스터에 필요한 총 6 개의 노드에 대해 템플릿을 6 번 중첩하고 마스터 템플릿을 사용하여 배포합니다. C. 사용할 호스트 이름 서브넷 및 탄력적 네트워크 인터페이스 목록이있는 Amazon DynamoDB 테이블을 생성합니다. 최소 크기가 6이고 최대 크기가 6 인 Auto Scaling 그룹을 관리하기위한 단일 AWS CloudFormation 템플릿을 생성합니다. 각 호스트 이름 및 로컬 IP 주소의 할당을 잠 그거나 해제 할 각 인스턴스에 설치된 프로그래밍 솔루션을 생성합니다. 새 인스턴스가 시작될 서브넷에 따라 다릅니다. D. 재사용 가능한 AWS CLI 스크립트를 생성하여 각 인스턴스를 개별적으로 시작하면 인스턴스 이름이 지정되고 특정 AZ에 배치되고 특정 탄력적 네트워크 인터페이스가 연결됩니다. 인스턴스를 모니터링하고 오류가 발생한 경우 스크립트를 다시 실행하여 누락 된 인스턴스를 수동으로 교체합니다.

한 회사에서 AWS CloudFormation 템플릿을 사용하여 웹 애플리케이션을 배포하고 있습니다. 템플릿을 사용하려면 프로덕션, 스테이징 및 개발의 세 가지 주요 환경 각각에 대해 수동으로 변경 해야합니다. 현재 스프린트에는 자동화된 배포를 위한 AWS CodePipeline의 새로운 구현 및 구성이 포함됩니다. CloudFormation 템플릿을 여러 파이프 라인에서 재사용 할 수 있도록 DevOps 엔지니어는 어떤 변경을 해야합니까? A. CloudFormation 사용자 지정 리소스를 사용하여 CodePipeline의 상태를 쿼리하여 시작된 환경을 확인합니다. Amazon EC2 인스턴스의 시작 구성을 동적으로 변경합니다. B. 입력 매개 변수를 사용하도록 각 환경에 대해 CodePipeline 파이프 라인을 설정합니다. CloudFormation 매핑을 사용하여 Amazon EC2 인스턴스에 대한 연결된 UserData를 시작중인 환경과 일치하도록 전환합니다. C. 각 개발 환경에 대해 하나씩 여러 단계가 있는 CodePipeline 파이프 라인을 설정합니다. AWS Lambda 함수를 사용하여 CloudFormation 배포를 트리거 하여 각 환경에서 시작된 Amazon EC2 인스턴스의 UserData를 동적으로 변경합니다. D. CloudFormation 입력 파라미터를 사용하여 CloudFormation 스택이 업데이트 될 때마다 각 Amazon EC2 인스턴스의 LaunchConfiguration 및 UserData 섹션을 동적으로 변경합니다.

한 회사에서 유출 및 손상된 IAM 액세스 키의 보안 위협을 처리하기 위한 방법론을 채택하려고 합니다. DevOps 엔지니어는 사용자 식별, 권한 취소, 사용자에게 알림 전송 등 손상된 액세스 키에 대한 작업 프로세스를 자동화하도록 요청 받았습니다. 보안 팀. 다음중 이 목표를 달성할 수 있는 것은 무엇입니까? A. 액세스 키에 대해 AWS Trusted Advisor 생성 보안 보고서를 사용합니다. Amazon EMR을 사용하여 보고서에서 분석을 실행합니다. 손상된 IAM 액세스 키를 식별하고 삭제합니다. EMR 클러스터 상태 변경 이벤트와 함께 Amazon CloudWatch를 사용하여 보안 팀에 알립니다. B. AWS Trusted Advisor를 사용하여 손상된 액세스 키를 식별합니다. Trusted Advisor를 이벤트 소스로 사용하고 AWS Lambda 및 Amazon SNS를 대상으로 사용하여 Amazon CloudWatch Events 규칙을 생성합니다. AWS Lambda를 사용하여 손상된 IAM 액세스 키를 삭제하고 Amazon SNS를 사용하여 보안 팀에 알립니다. C. 액세스 키에 대해 AWS Trusted Advisor 생성 보안 보고서를 사용합니다. AWS Lambda를 사용하여 보고서를 스캔합니다. AWS Lambda 내에서 스캔 결과를 사용하고 손상된 IAM 액세스 키를 삭제합니다. Amazon SNS를 사용하여 보안 팀에 알립니다. D. 타사 라이브러리와 함께 AWS Lambda를 사용하여 손상된 액세스 키를 스캔합니다. AWS Lambda 내에서 스캔 결과를 사용하고 손상된 IAM 액세스 키를 삭제합니다. 손상된 키에 대한 Amazon CloudWatch 사용자 지정 지표를 생성합니다. 지표에 대한 CloudWatch 경보를 생성하여 보안 팀에 알립니다.

한 회사에서 포럼에서 메타 데이터를 유지하기 위해 Amazon DynamoDB를 사용하려고 합니다. 아래 이미지의 샘플 데이터 세트를 참조하십시오. DevOps 엔지니어는 파티션 키, 정렬 키, 로컬 보조 인덱스, 프로젝션 된 속성 및 가져오기 작업으로 테이블 스키마를 정의해야 합니다. 스키마는 비용을 최소화하기 위해 최소 프로비저닝 된 읽기 용량 단위를 사용하는 다음 예제 검색을 지원해야합니다. - 제목이 "˜a"로 시작하는 항목을 ForumName 내에서 검색합니다. - 주어진 LastPostDateTime 기간 내에 포럼을 검색합니다. - LastPostDateTime이 지난 3 개월 이내 인 스레드 값을 반환합니다. 요구 사항을 충족하는 스키마는 무엇입니까? A. Subject를 기본 키로 사용하고 ForumName을 정렬 키로 사용합니다. LastPostDateTime이있는 LSI를 정렬 키로 사용하고 스레드에 대한 작업을 가져옵니다. B. ForumName을 기본 키로 사용하고 Subject를 정렬 키로 사용합니다. LastPostDateTime을 정렬 키로 사용하고 프로젝션 된 속성 스레드가있는 LSI가 있습니다. C. ForumName을 기본 키로 사용하고 Subject를 정렬 키로 사용합니다. 정렬 키로 Thread가있는 LSI와 예상 속성 LastPostDateTime이 있습니다. D. Subject를 기본 키로 사용하고 ForumName을 정렬 키로 사용합니다. Thread와 함께 LSI를 정렬 키로 사용하고 LastPostDateTime에 대한 작업을 가져옵니다.

회사에서 AWS에 배포 된 애플리케이션에 대한 CI / CD 파이프 라인을 구현하려고 합니다. 이 회사는 또한 보안 결함을 확인하는 온 프레미스에서 호스팅되는 소스 코드 분석 도구를 보유하고 있습니다. 이 도구는 아직 AWS로 마이그레이션되지 않았으며 온 프레미스에서만 액세스 할 수 있습니다. 회사는 코드가 컴파일되기 전에 파이프 라인의 일부로 소스 코드에 대한 검사를 실행하려고 합니다. 확인을 완료하는 데 몇 분에서 1 시간이 걸립니다. DevOps 엔지니어는 이러한 요구 사항을 어떻게 충족할 수 있습니까? A. AWS CodePipeline을 사용하여 파이프 라인을 생성합니다. 소스 단계 후에 AWS Lambda 함수를 호출하는 작업을 파이프 라인에 추가합니다. Lambda 함수가 CodePipeline의 소스 입력에 대해 온 프레미스에서 소스 코드 분석 도구를 호출하도록 합니다. 그런 다음 함수는 실행이 완료될 때까지 기다렸다가 지정된 Amazon S3 위치에 출력을 배치합니다. B. AWS CodePipeline을 사용하여 파이프 라인을 생성 한 다음 사용자 지정 작업 유형을 생성합니다. 온 프레미스에서 호스팅되는 하드웨어에서 실행되는 사용자 지정 작업에 대한 작업자를 만듭니다. 작업자는 온 프레미스 코드 분석 도구로 실행중인 보안 검사를 처리한 다음 작업 결과를 CodePipeline에 반환합니다. 파이프 라인이 소스 단계 후에 사용자 지정 작업을 호출하도록 합니다. C. AWS CodePipeline을 사용하여 파이프 라인을 생성합니다. 소스 단계 뒤에 단계를 추가하여 소스 코드 분석 도구로 테스트를 호출하는 온 프레미스 호스팅 웹 서비스에 HTTPS 요청을 작성하십시오. 분석이 완료되면 웹 서비스는 CodePipeline에서 제공하는 Amazon S3 출력 위치에 결과를 넣어 결과를 다시 보냅니다. D. AWS CodePipeline을 사용하여 파이프 라인을 생성합니다. 입력 소스 코드를 온 프레미스 위치로 복사하는 셸 스크립트를 만듭니다. 소스 코드 분석 도구를 호출하고 결과를 CodePipeline에 반환합니다. 소스 단계 후에 사용자 지정 스크립트 작업을 추가하여 셸 스크립트를 호출합니다.

회사에서 애플리케이션에 AWS를 사용하고 있습니다. 개발 팀은 배포를 자동화해야 합니다. 팀은 AWS CodeBuild 서비스를 사용하여 구축된 후 AWS CodeDeploy를 사용하여 Amazon EC2 인스턴스에 애플리케이션을 배포하도록 AWS CodePipeline을 설정했습니다. 팀은 동일한 코드를 사용하여 파이프 라인의 다음 단계에 애플리케이션을 배포하기 전에 애플리케이션이 정상인지 확인하기 위해 파이프 라인에 자동화된 테스트를 추가하려고 합니다. 팀은 테스트가 성공한 경우에도 애플리케이션을 배포하기 전에 수동 승인 조치를 취해야합니다. 가장 간단한 관리 솔루션을 사용하여 가장 낮은 비용으로 테스트 및 승인을 수행해야합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? A. 파이프 라인의 마지막 배포 작업 후에 수동 승인 작업을 추가합니다. Amazon SNS를 사용하여 트리거되는 단계를 팀에 알립니다. 다음으로 CodeBuild를 사용하여 테스트 작업을 추가하여 필요한 테스트를 수행합니다. 파이프 라인이 끝나면 배포 작업을 추가하여 애플리케이션을 다음 단계에 배포합니다. B. 파이프 라인의 마지막 배포 작업 후에 테스트 작업을 추가합니다. CodeBuild를 사용하여 필요한 테스트를 수행하도록 작업을 구성합니다. 이러한 테스트가 성공하면 작업을 성공으로 표시하십시오. Amazon SNS를 사용하여 팀에 알리는 수동 승인 작업을 추가하고 배포 작업을 추가하여 애플리케이션을 다음 단계에 배포합니다. C. 첫 번째 파이프 라인과 동일한 리포지토리에서 코드를 가져 오는 소스 작업을 사용하는 새 파이프 라인을 만듭니다. 배포 작업을 추가하여 코드를 테스트 환경에 배포합니다. AWS Lambda를 사용하는 테스트 작업을 사용하여 배포를 테스트합니다. Amazon SNS를 사용하여 팀에 알리는 수동 승인 작업을 추가하고 배포 작업을 추가하여 애플리케이션을 다음 단계에 배포합니다. D. 마지막 배포 작업 후에 테스트 작업을 추가합니다. Amazon EC2에서 Jenkins 서버를 사용하여 필요한 테스트를 수행하고 테스트가 통과하면 작업을 성공으로 표시합니다. Amazon SQS를 사용하여 팀에 알리고 배포 작업을 추가하여 애플리케이션을 다음 단계에 배포하는 수동 승인 작업을 생성합니다.

DevOps 엔지니어는 AWS 시스템을 사용하여 하이브리드 클라우드 환경에서 Windows 기반 워크 스테이션의 패치를 자동화하기위한 구현을 이끌고 있습니다. 관리자 (SSM). 엔지니어는 이 환경에서 패치를 자동화하도록 Systems Manager를 설정하기 위해 어떤 단계를 따라야합니까? (2 개 선택) A. ssm.amazonaws.com 서비스가 모든 인스턴스에서 AssumeRole 작업을 실행할 수 있도록 Systems Manager에 대한 여러 IAM 서비스 역할을 생성합니다. 리소스 별 역할을 등록하여 서비스 토큰을 만들 수 있습니다. 각 관리 형 인스턴스에 연결된 새로 생성 된 서비스 역할을 사용하여 관리 형 인스턴스 활성화를 수행합니다. B. ssm.amazonaws.com 서비스가 AssumeRole 작업을 실행할 수 있도록 Systems Manager에 대한 IAM 서비스 역할을 생성합니다. 서비스 토큰을 만들 수 있도록 역할을 등록합니다. 새로 생성 된 서비스 역할로 관리 형 인스턴스 활성화를 수행합니다. C. 이전에 얻은 활성화 코드와 활성화 ID를 사용하여 하이브리드 서버에 SSM 에이전트를 다운로드 및 설치하고 시스템 관리자 서비스에 서버 또는 가상 머신을 등록합니다. 하이브리드 인스턴스는 SSM 콘솔에서 "mi-"접두사와 함께 표시됩니다. D. 이전에 얻은 활성화 코드 및 활성화 ID를 사용하여 하이브리드 서버에 SSM 에이전트를 다운로드 및 설치하고 시스템 관리자 서비스에 서버 또는 가상 머신을 등록합니다. 하이브리드 인스턴스는 일반 Amazon EC2 인스턴스로 프로비저닝 된 것처럼 SSM 콘솔에 "i-"접두사로 표시됩니다. E. AWS Config를 실행하여 패치가 적용되지 않고 규정을 준수하지 않는 인스턴스 목록을 생성합니다. 인스턴스 스케줄러 작업을 생성하고 AWS Lambda 함수를 통해 인스턴스 패치를 수행하여 규정을 준수하도록합니다.

DevOps 엔지니어가 Amazon Linux에서 호스팅되는 프로젝트에서 작업 중이며 보안 검토에 실패했습니다. DevOps Manager는 AWS CodeBuild 프로젝트에 대한 회사 buildspec.yaml 파일을 검토하고 권장 사항을 제공하라는 요청을 받았습니다. buildspec.yaml 파일은 다음과 같이 구성됩니다. AWS 보안 모범 사례를 준수하려면 어떤 변경을 권장해야합니까? (3 개를 선택하십시오.) A. 다른 CodeBuild 사용자가 볼 수 없도록 종료하기 전에 컨테이너에서 임시 파일을 제거하는 빌드 후 명령을 추가합니다. B. 필요한 권한으로 CodeBuild 프로젝트 역할을 업데이트 한 다음 환경 변수에서 AWS 자격 증명을 제거합니다. C. DB_PASSWORD를 AWS Systems Manager Parameter Store에 SecureString 값으로 저장 한 다음 환경 변수에서 DB_PASSWORD를 제거합니다. D. 환경 변수를 "~ db-deploy-bucket 'Amazon S3 버킷으로 이동하고 다운로드 할 사전 빌드 단계를 추가 한 다음 변수를 내 보냅니다. E. 인스턴스에 직접 AWS Systems Manager run 명령과 scp 및 ssh 명령을 사용합니다. F. XOR 다음에 Base64를 사용하여 환경 변수를 스크램블하고 설치할 섹션을 추가 한 다음 빌드 단계에서 XOR 및 Base64를 실행합니다.

BCE

인터넷 액세스가 없는 Amazon EC2 인스턴스가 Virtual Private Cloud (VPC)에서 실행 중이며 제한된 Amazon S3 버킷에서 객체를 다운로드해야 합니다. DevOps 엔지니어가 객체에 대한 액세스 권한을 얻으려고 하면 AccessDenied 오류가 수신됩니다. 이 오류의 가능한 원인은 무엇입니까? (3 개를 선택하십시오.) A. S3 버킷 기본 암호화가 활성화됩니다. B. S3 버킷 정책에 오류가 있습니다. C. VPC 엔드 포인트 정책에 오류가 있습니다. D. 객체가 Amazon Glacier로 이동되었습니다. E. IAM 역할 구성에 오류가 있습니다. F. S3 버전 관리가 활성화됩니다.

BCE

개발 팀이 AWS에서 서버리스 애플리케이션을 개발하고 있습니다. 잠재적 인 프로덕션 문제를 신속하게 식별하고 수정하기 위해 팀은 전체 릴리스 전에 테스트로 소수의 사용자에게 변경 사항을 적용하기로 결정합니다. DevOps 엔지니어는 다운 타임과 영향을 최소화하기위한 솔루션을 개발해야 합니다. 다음 중 요구 사항을 충족하기 위해 사용해야하는 솔루션은 무엇입니까? (2 개 선택) A. 두 개의 대상 그룹이있는 Application Load Balancer를 생성합니다. Amazon API Gateway 프라이빗 통합을 위해 Application Load Balancer를 설정합니다. 하나의 대상 그룹을 현재 버전에 연결하고 다른 대상 그룹을 새 버전에 연결합니다. 들어오는 트래픽의 10 %를 새 버전으로 라우팅하도록 API Gateway를 구성합니다. 새 버전이 안정되면 모든 트래픽을 새 버전으로 전송하고 로드밸런서 에서 이전 버전을 분리하도록 API Gateway를 구성합니다. B. 현재 버전과 새 버전을 모두 가리키는 AWS Lambda 함수에 대한 별칭을 생성합니다. 수신 트래픽의 10 %를 새 버전으로 라우팅하도록 별칭을 구성합니다. 새 버전이 안정적인 것으로 간주되므로 모든 트래픽을 새 버전으로 라우팅하도록 별칭을 업데이트합니다. C. AWS Route 53에서 이전 버전과 새 버전에 대한 AWS Lambda 엔드 포인트를 가리키는 장애 조치 레코드 세트를 생성합니다. 들어오는 트래픽의 10 %를 새 버전으로 라우팅하도록 Route 53을 구성합니다. 새 버전이 안정되면 DNS 레코드를 업데이트하여 모든 트래픽을 새 버전으로 라우팅하십시오. D. 두 개의 대상 그룹이있는 ELB Network Load Balancer를 생성합니다. Amazon API Gateway 프라이빗 통합을 위한 Network Load Balancer 설정 하나의 대상 그룹을 현재 버전에 연결하고 다른 대상 그룹을 새 버전에 연결합니다. 수신 트래픽의 10 %를 새 버전으로 라우팅 하도록 로드 밸런서를 구성합니다. 새 버전이 안정되면 로드밸런서 에서 이전 버전을 분리하십시오. E. Amazon API Gateway에서 일반 배포 단계에 카나리아 설정을 추가하여 카나리아 릴리스 배포를 생성합니다. 수신 트래픽의 10 %를 Canary 릴리스로 라우팅하도록 API Gateway를 구성합니다. 카나리아 릴리스가 안정적인 것으로 간주되므로 프로덕션 릴리스로 승격하십시오.

애플리케이션 팀에는 개발, 사전 프로덕션 및 프로덕션의 세 가지 애플리케이션 환경이 있습니다. 이 팀은 최근 AWS CodePipeline을 채택했습니다. 그러나 팀은 잘못 구성되었거나 작동하지 않는 개발 코드를 프로덕션 환경에 여러 번 배포하여 사용자 중단과 다운 타임을 초래했습니다. DevOps 엔지니어는 파이프 라인을 검토하고 배포하기 전에 애플리케이션 문제를 식별하는 단계를 추가해야합니다. 엔지니어는 배포 프로세스 중에 기능 문제를 식별하기 위해 무엇을 해야 합니까? (2 개 선택) A. Amazon Inspector를 사용하여 파이프 라인에 테스트 작업을 추가합니다. Amazon Inspector Runtime Behavior Analysis Inspector 규칙 패키지를 사용하여 배포된 코드가 프로덕션에 배포하기 전에 회사 보안 표준을 준수하는지 확인합니다. B. AWS CodeBuild를 사용하여 파이프 라인에 테스트 작업을 추가하여 일반적인 사용자 활동을 복제하고 프로덕션 배포로 진행하기 전에 결과가 예상대로인지 확인합니다. C. 제한된 수의 인스턴스에 애플리케이션 코드를 자동으로 배포하는 배포 구성을 사용하여 파이프 라인에서 AWS CodeDeploy 작업을 생성합니다. 그런 다음 작업은 QA 팀이 애플리케이션 기능을 검토할 수 있도록 배포를 일시 중지합니다. 검토가 완료되면 CodeDeploy가 애플리케이션을 재개하고 나머지 프로덕션 Amazon EC2 인스턴스에 배포합니다. D. 배포 프로세스가 완료된 후 애플리케이션에 액세스하는 다른 리전의 Amazon EC2 인스턴스에서 테스트 활동을 실행하여 사용자 동작을 시뮬레이션 합니다. 예상치 못한 결과가 발생하면 테스트 활동이 Amazon SNS 주제에 경고를 보냅니다. 업데이트를 받으려면 주제를 구독하십시오. E. 파이프 라인에 AWS CodeDeploy 작업을 추가하여 최신 버전의 개발 코드를 사전 프로덕션에 배포합니다. QA 팀이 예상되는 기능을 테스트하고 확인할 수 있도록 파이프 라인에 수동 승인 작업을 추가합니다. 수동 승인 작업 후에 승인된 코드를 프로덕션 환경에 배포하는 두 번째 CodeDeploy 작업을 추가합니다.

Amazon Linux에서 실행되는 프로덕션 웹 집합을 즉시 패치 해야 하는 OpenSSL에서 새로운 제로 데이 취약점이 발견되었습니다. 현재 OS 업데이트는 매월 수동으로 수행되며 프로덕션 Auto Scaling Group의 시작 구성에 대한 업데이트를 사용하여 배포됩니다. DevOps 엔지니어가 다운 타임없이 패키지를 제자리에서 업데이트하려면 어떤 방법을 사용해야합니까? A. AWS CodePipline 및 AWS CodeBuild를 사용하여 이러한 패키지의 새 복사본을 생성하고 Auto Scaling 그룹의 시작 구성을 업데이트합니다. B. AWS Inspector를 사용하여 실행중인 모든 프로덕션 인스턴스에서 "yum upgrade"를 실행하고 다음 유지 관리 기간을 위해 AMI를 수동으로 업데이트합니다. C. Amazon EC2 Run Command를 사용하여 실행중인 모든 프로덕션 인스턴스에 패키지 업데이트 명령을 실행하고 향후 배포를 위해 AMI를 업데이트합니다. D. 실행중인 프로덕션 인스턴스와 일치하도록 새 AWS OpsWorks 계층을 정의하고 레시피를 사용하여 실행중인 모든 프로덕션 인스턴스에 패키지 업데이트 명령을 실행합니다.

DevOps 엔지니어는 AWS CodePipeline 및 AWS CodeBuild를 사용하여 서버리스 애플리케이션을 위한 지속적 배포 파이프 라인을 구축하고 있습니다. 배포 단계가 남아있는 소스, 빌드 및 테스트 단계가 생성되었습니다. 이 회사는 지정된 고객 하위 집합에 배포하고 모든 고객에게 정식 릴리스 전에 모니터링하여 배포 실패의 위험을 줄이고 자합니다. 이러한 요구 사항을 충족하려면 배포 단계를 어떻게 구성해야 합니까? A. AWS CloudFormation을 사용하여 모든 스택 업데이트에 새 버전을 게시합니다. 그런 다음 개발자가 새 버전을 테스트하고 승인할 수 있도록 CodePipeline 승인 작업을 설정합니다. 마지막으로 CodePipeline 호출 작업을 사용하여 프로덕션 별칭을 사용하도록 AWS Lambda 함수를 업데이트합니다. B. CodeBuild를 사용하여 AWS CLI를 사용하여 AWS Lambda 함수 코드를 업데이트 한 다음 새 버전의 함수를 게시하고 새 버전의 함수를 가리 키도록 프로덕션 별칭을 업데이트합니다. C. AWS CloudFormation을 사용하여 서버리스 애플리케이션을 정의하고 AWS CodeDeploy를 사용하여 DeploymentPreference :를 사용하여 AWS Lambda 함수를 배포합니다. Canary10Percent15Minutes D. AWS CloudFormation을 사용하여 모든 스택 업데이트에 새 버전을 게시합니다. AWS :: Lambda :: Alias 리소스의 RoutingConfig 속성을 사용하여 스택 업데이트 중에 트래픽 라우팅을 업데이트합니다.

DevOps 엔지니어는 AWS에 확장 가능한 3 계층 Node.js 애플리케이션을 배포해야 합니다. 애플리케이션은 배포 중에 다운 타임이 없어야 하며 이전 버전으로 롤백 할 수 있어야합니다. 다른 애플리케이션도 동일한 MySQL 백 엔드 데이터베이스에 연결됩니다. CIO는 로깅에 대한 다음 지침을 제공했습니다. ▶ 모든 현재 웹 액세스 서버 로그를 중앙에서 볼 수 있습니다. ▶ 거의 실시간으로 웹 및 애플리케이션 로그를 검색하고 필터링합니다. ▶ 로그 데이터를 3 개월 동안 보관합니다. 이러한 요구 사항을 어떻게 충족해야합니까? A. AWS Elastic Beanstalk를 사용하여 애플리케이션을 배포합니다. Elastic Load Balancing 및 Auto Scaling에 대한 환경 유형을 구성합니다. Elastic Beanstalk 스택 내에 Amazon RDS MySQL 인스턴스를 생성합니다. Amazon CloudWatch Logs로 로그를 스트리밍하도록 Elastic Beanstalk 로그 옵션을 구성합니다. 보존을 90 일로 설정합니다. B. Amazon EC2에 애플리케이션을 배포합니다. Elastic Load Balancing 및 Auto Scaling을 구성합니다. 데이터베이스 계층에 Amazon RDS MySQL 인스턴스를 사용합니다. Amazon S3에 로그 파일을 저장하도록 애플리케이션을 구성합니다. Amazon EMR을 사용하여 데이터를 검색하고 필터링합니다. 90 일 후에 객체가 만료되도록 Amazon S3 수명주기 규칙을 설정합니다. C. AWS Elastic Beanstalk를 사용하여 애플리케이션을 배포합니다. Elastic Load Balancing 및 Auto Scaling에 대한 환경 유형을 구성합니다. Elastic Beanstalk 스택 외부에 Amazon RDS MySQL 인스턴스를 생성합니다. Amazon CloudWatch Logs로 로그를 스트리밍하도록 Elastic Beanstalk 로그 옵션을 구성합니다. 보존을 90 일로 설정합니다. D. Amazon EC2에 애플리케이션을 배포합니다. Elastic Load Balancing 및 Auto Scaling을 구성합니다. 데이터베이스 계층에 Amazon RDS MySQL 인스턴스를 사용합니다. Amazon Kinesis Data Firehouse를 사용하여 스트리밍 로그 데이터를 Amazon ES로로드하도록 애플리케이션을 구성합니다. 90 일마다 새 Amazon ES 도메인을 삭제하고 생성합니다.

DevOps 엔지니어에는 배송 주문을 받고 재고를 추적하는 단일 Amazon DynamoDB 테이블이 있습니다. 엔지니어에는 해당 테이블의 DymamoDB 스트림에서 읽는 세 가지 AWS Lambda 함수가 있습니다. Lambda 함수는 항목 개수 수행, Amazon Kinesis로 항목 이동과 같은 다양한 기능을 수행합니다. Data Firehose, 재고 수준 모니터링 및 부품 부족 시 공급 업체 주문 생성. 엔지니어는 로그를 검토하는 동안 Lambda 함수가로드 증가 시 가끔 실패하여 스트림 조절 오류를 수신함을 발견했습니다. 최소한의 운영 관리가 필요한 가장 비용 효율적인 솔루션은 무엇입니까? A. AWS Glue 통합을 사용하여 DynamoDB 스트림을 수집 한 다음 Lambda 코드를 AWS Fargate 작업으로 마이그레이션합니다. B. DynamoDB 스트림 대신 Amazon Kinesis 스트림을 사용한 다음 Kinesis 분석을 사용하여 Lambda 함수를 트리거합니다. C. 네 번째 Lambda 함수를 생성하고 스트림에서 유일한 Lambda 읽기가 되도록 구성합니다. 그런 다음이 Lambda 함수를 사용하여 페이로드를 다른 세 개의 Lambda 함수에 전달합니다. D. Lambda 함수가 테이블을 직접 쿼리하고 DynamoDB 스트림을 비활성화 하도록 합니다. 그런 다음 글로벌 보조 인덱스에서 Lambda

두 팀이 아키텍처의 서로 다른 부분에서 함께 작업하고 있으며 AWS CloudFormation을 사용하여 리소스를 관리하고 있습니다. 한 팀은 운영 체제 수준의 업데이트 및 패치를 관리하고 다른 팀은 응용 프로그램 수준의 종속성 및 업데이트를 관리합니다. 애플리케이션 팀은 새 인스턴스를 생성하고 애플리케이션을 배포할 때 최신 AMI를 가져와야 합니다. 이 두 팀과 프로세스를 연결하는 가장 확장 가능한 방법은 무엇입니까? A. 운영 체제 팀은 CloudFormation을 사용하여 AMI의 새 버전을 생성하고 스택 출력 섹션의 일부로 암호화 된 Amazon S3 객체에 AMI의 Amazon 리소스 이름 (ARN)을 나열합니다. 애플리케이션 팀은 교차 스택 참조를 사용하여 암호화된 S3 객체를 로드하고 최신 AMI ARN을 얻습니다. B. 운영 체제 팀은 CloudFormation 스택을 사용하여 새 AMI를 구축하는 AWS CodePipeline 파이프 라인을 생성 한 다음 파이프 라인 출력의 일부로 암호화 된 Amazon S3 객체에 최신 AMI ARN을 배치합니다. 애플리케이션 팀은 자체 CloudFormation 템플릿 내에서 교차 스택 참조를 사용하여 해당 S3 객체 위치를 얻고 애플리케이션 배포 시 사용할 최신 AMI ARN을 얻습니다. C. 운영 체제 팀은 CloudFormation 스택을 사용하여 새 AMI를 구축하는 AWS CodePipeline 파이프 라인을 생성합니다. 그런 다음 팀은 AMI ARN을 파이프 라인 출력의 일부로 AWS Systems Manager Parameter Store에 매개 변수로 배치합니다. 애플리케이션 팀은 CloudFormation 스택에서 ssm 유형의 파라미터를 지정하여 Parameter Store에서 최신 AMI ARN을 얻습니다. D. 운영 체제 팀은 운영 체제와 응용 프로그램 팀 템플릿을 모두 포함하는 중첩 스택을 유지합니다. 운영 체제 팀은 스택 업데이트를 사용하여 애플리케이션 팀이 애플리케이션 코드를 변경할 때마다 애플리케이션 스택에 업데이트를 배포합니다.

미국에 본사를 둔 한 온라인 소매 회사는 향후 6개월 내에 유럽과 아시아로 사업을 확장 할 계획입니다. 현재 제품은 Application Load Balancer 뒤의 Amazon EC2 인스턴스. 인스턴스는 여러 가용 영역에 걸쳐 Amazon EC2 Auto Scaling 그룹에서 실행됩니다. 모든 데이터는 Amazon Aurora 데이터베이스 인스턴스에 저장됩니다. 제품이 여러 지역에 배포되는 경우 회사는 모든 지역에서 단일 제품 카탈로그를 원하지만 규정 준수를 위해 고객 정보 및 구매를 각 지역에 보관해야합니다. 회사는 최소한의 응용 프로그램 변경으로 이러한 요구 사항을 어떻게 충족해야합니까? A. 제품 카탈로그에는 Amazon Redshift를 사용하고 고객 정보 및 구매에는 Amazon DynamoDB 테이블을 사용하십시오. B. 제품 카탈로그에는 Amazon DynamoDB 글로벌 테이블을 사용하고 고객 정보 및 구매에는 지역 테이블을 사용합니다. C. Aurora를 제품 카탈로그에 대한 읽기 전용 복제본과 함께 사용하고 고객 정보 및 구매를 위해 각 지역의 추가 로컬 Aurora 인스턴스를 사용합니다. D. 제품 카탈로그에는 Aurora를 사용하고 고객 정보 및 구매에는 Amazon DynamoDB 글로벌 테이블을 사용합니다.

보안 팀은 DevOps 엔지니어에게 AWS CloudTrail 파일이 생성된 후 변조되지 않았는지 확인하라는 요청을 받았습니다. 현재 AWS IAM을 사용하여 특정 추적에 대한 액세스를 제한하는 여러 추적이 있는 프로세스가 있습니다. 보안 팀은 각 파일의 무결성을 추적하고 변조가 없는지 확인하려고 합니다. 보안 팀이 로그의 신뢰성을 증명할 수 있도록 허용하면서 파일의 적법성을 구현하고 보장하는 데 최소한의 노력이 필요한 옵션은 무엇입니까? A. 새 파일이 전송 될 때 AWS Lambda 함수를 트리거하는 Amazon CloudWatch Events 규칙을 생성합니다. Lambda 함수를 구성하여 파일에서 MD5 해시 검사를 수행하고, 파일의 이름과 위치를 저장하고, 반환된 해시를 Amazon DynamoDB 테이블에 게시합니다. 보안 팀은 DynamoDB에 저장된 값을 사용하여 파일 신뢰성을 확인할 수 있습니다. B. Amazon S3 버킷에서 CloudTrail 파일 무결성 기능을 활성화합니다. 보안 팀에 S3 버킷에 저장된 파일 무결성 로그에 대한 액세스 권한을 부여하는 IAM 정책을 생성합니다. C. 추적에서 CloudTrail 파일 무결성 기능을 활성화합니다. CloudTrail에서 생성 한 다이제스트 파일을 사용하여 제공된 CloudTrail 파일의 무결성을 확인합니다. D. 새 파일이 CloudTrail 버킷에 전달 될 때마다 트리거되는 AWS Lambda 함수를 생성합니다. 파일에서 MD5 해시 검사를 실행하도록 Lambda 함수를 구성하고 Amazon S3 객체의 태그에 결과를 저장합니다. 보안 팀은 태그의 정보를 사용하여 파일의 무결성을 확인할 수 있습니다.

비즈니스에는 5 개의 독립적 인 AWS Lambda 함수로 구성된 애플리케이션이 있습니다. DevOps 엔지니어는 각 Lambda 함수를 순서대로 빌드, 테스트, 패키징 및 배포하는 AWS CodePipeline 및 AWS CodeBuild를 사용하여 CI / CD 파이프 라인을 구축했습니다. 파이프 라인은 Amazon CloudWatch Events 규칙을 사용하여 애플리케이션 소스 코드가 변경된 후 파이프 라인 실행이 가능한 한 빨리 시작되도록합니다. 몇 달 동안 파이프 라인 작업을 마친 DevOps 엔지니어는 파이프 라인을 완료하는 데 너무 오래 걸린다는 것을 알게되었습니다. DevOps 엔지니어는 파이프 라인 속도를 가장 잘 개선하기 위해 무엇을 구현해야합니까? A. 사용 가능한 네트워크 처리량이 더 많은 컴퓨팅 유형을 사용하도록 파이프 라인 내의 CodeBuild 프로젝트를 수정합니다. B. 대칭형 다중 처리 구성이 포함 된 사용자 지정 CodeBuild 실행 환경을 만들어 병렬로 빌드를 실행합니다. C. 동일한 runOrder를 지정하여 각 Lambda 함수에 대한 작업을 병렬로 실행하도록 CodePipeline 구성을 수정합니다. D. VPC 내에서 실행되도록 각 CodeBuild 프로젝트를 수정하고 전용 인스턴스를 사용하여 처리량을 늘립니다.

응용 프로그램을 실행하기 위해 DevOps Engineer는 공용 서브넷에 공용 IP 주소가 있는 Amazon EC2 인스턴스를 시작합니다. 사용자 데이터 스크립트는 응용 프로그램 아티팩트를 가져와 실행 시 인스턴스에 설치합니다. 이제 응용 프로그램의 보안 분류를 변경하려면 인터넷에 대한 액세스 권한 없이 인스턴스를 실행해야 합니다. 인스턴스가 성공적으로 시작되고 정상적으로 표시되지만 응용 프로그램이 설치되지 않은 것 같습니다. 다음 중 새 규칙을 준수하면서 응용 프로그램을 성공적으로 설치해야 하는 것은 무엇입니까? A. Elastic IP 주소가 연결된 공용 서브넷에서 인스턴스를 시작합니다. 응용 프로그램이 설치되고 실행되면 스크립트를 실행하여 나중에 Elastic IP 주소의 연결을 끊습니다. B. NAT 게이트웨이를 설정합니다. EC2 인스턴스를 개인 서브넷에 배포합니다. NAT 게이트웨이를 기본 경로로 사용하도록 개인 서브넷의 경로 테이블을 업데이트합니다. C. 애플리케이션 아티팩트를 Amazon S3 버킷에 게시하고 S3용 VPC 끝점을 생성합니다. IAM 인스턴스 프로파일을 EC2 인스턴스에 할당하여 S3 버킷에서 애플리케이션 아티팩트를 읽을 수 있도록 합니다. D. 응용 프로그램 인스턴스에 대한 Security Group을 만들고 아티팩트 저장소에 대한 아웃바운드 트래픽만 화이트리스트에 추가합니다. 설치가 완료되면 Security Group 규칙을 제거합니다.

의료 제공 업체는 RedHat를 실행하는 120 개의 온 프레미스 VMware 서버와 Amazon을 실행하는 50 개의 Amazon EC2 인스턴스를 포함하는 하이브리드 아키텍처를 가지고 있습니다. 리눅스. 이 회사는 AWS 로의 올인 마이그레이션을 진행 중이며 데이터 분석을 위해 온 프레미스 가상 머신 및 EC2 인스턴스에서 정보를 수집하는 솔루션을 구현하려고 합니다. 정보에는 다음이 포함됩니다. -운영 체제 유형 및 버전 -설치된 애플리케이션에 대한 데이터 -MAC 및 IP 주소와 같은 네트워크 구성 정보 -Amazon EC2 인스턴스 AMI ID 및 IAM 프로필 최소 관리량으로 이러한 요구 사항을 어떻게 충족할 수 있습니까? A. EC2 인스턴스에서 cron 작업으로 실행할 셸 스크립트를 작성하여 데이터를 수집하고 Amazon S3에 푸시 합니다. 온 프레미스 리소스의 경우 VMware vSphere를 사용하여 데이터를 수집하고 S3에 데이터를 저장하기 위해 파일 게이트웨이에 기록합니다. 마지막으로 분석을 위해 S3 버킷에서 Amazon Athena를 사용합니다. B. 온 프레미스 가상 머신 과 EC2 인스턴스에서 스크립트를 사용하여 데이터를 수집하고 Amazon S3로 푸시 한 다음 분석을 위해 Amazon Athena를 사용합니다. C. 온 프레미스 가상 머신 과 EC2 인스턴스 모두에 AWS Systems Manager 에이전트를 설치합니다. 인벤토리 수집을 활성화하고 Amazon S3 버킷에 대한 리소스 데이터 동기화를 구성하여 Amazon Athena로 데이터를 분석합니다. D. VMware 환경에서 Agentless Discovery Connector를 배포하려면 AWS Application Discovery Service를 사용하고 데이터 수집을 위해 EC2 인스턴스에는 Discovery Agent를 사용합니다. 그런 다음 분석을 위해 AWS Migration Hub 대시 보드를 사용합니다.

정부 기관에는 여러 AWS 계정이 있으며 그 중 대부분은 민감한 시민 정보를 저장합니다. 보안 팀은 모든 계정에서 비정상적인 계정 및 네트워크 활동 (예 : SSH 무차별 대입 공격)을 감지하고 해당 정보를 전용 보안 계정에 중앙 집중화 하려고 합니다. 이벤트 정보는 부서의 SIEM (Security Information and Even Manager) 시스템에서 모니터링하는 보안 계정의 Amazon S3 버킷에 저장되어야 합니다. 어떻게 이룰 수 있습니까? A. 모든 계정에서 Amazon Macie를 활성화합니다. 초대 / 수락을 사용하여 모든 구성원 계정에 대해 Macie 관리자로 보안 계정을 구성합니다. 보안 계정에서 Amazon CloudWatch Events 규칙을 생성하여 모든 결과를 Amazon Kinesis Data Firehouse로 보내면 결과가 S3 버킷으로 푸시됩니다. B. 보안 계정에서만 Amazon Macie를 활성화합니다. 초대 / 수락을 사용하여 모든 구성원 계정에 대해 Macie 관리자로 보안 계정을 구성합니다. 보안 계정에서 Amazon CloudWatch Events 규칙을 생성하여 모든 결과를 Amazon Kinesis Data Streams로 보냅니다. KCL을 사용하여 쓰기 및 적용하여 Kinesis Data Streams에서 데이터를 읽고 S3 버킷에 씁니다. C. 모든 계정에서 Amazon GuardDuty를 활성화합니다. 초대 / 수락을 사용하여 모든 멤버 계정에 대해 GuardDuty 관리자로 보안 계정을 구성합니다. 보안 계정에서 Amazon CloudWatch 규칙을 생성하여 모든 결과를 Amazon Kinesis Data Firehouse로 보내면 결과가 S3 버킷으로 푸시됩니다. D. 보안 계정에서만 Amazon GuardDuty를 활성화합니다. 초대 / 수락을 사용하여 모든 멤버 계정에 대해 GuardDuty 관리자로 보안 계정을 구성합니다. 보안 계정에서 Amazon CloudWatch 규칙을 생성하여 모든 결과를 Amazon Kinesis Data Streams로 보냅니다. KCL을 사용하여 쓰기 및 적용하여 Kinesis Data Streams에서 데이터를 읽고 S3 버킷에 씁니다.

한 게시 회사는 AWS Elastic Beanstalk, Amazon S3 및 Amazon DynamoDB를 사용하여 웹 애플리케이션을 개발했습니다. 웹 애플리케이션의 인기가 급격히 증가하여 예기치 않은 트래픽 급증이 발생했습니다. DevOps 엔지니어는 요청의 90 %가 중복 읽기 요청이라고 지적했습니다. 엔지니어는 웹 사이트의 성능을 어떻게 향상시킬 수 있습니까? A. Redis 용 Amazon ElastiCache를 사용하여 반복 된 읽기 요청을 DynamoDB 및 AWS Elemental MediaStore에 캐시하여 S3에 저장된 이미지를 캐시합니다. B. Memcached 용 Amazon ElastiCache를 사용하여 반복되는 읽기 요청을 DynamoDB 및 Varnish에 캐시하여 S3에 저장된 이미지를 캐시합니다. C. DynamoDB Accelerator를 사용하여 반복 된 읽기 요청을 DynamoDB 및 Amazon CloudFront에 캐시하여 S3에 저장된 이미지를 캐시합니다. D. DynamoDB 스트림을 사용하여 반복 된 읽기 요청을 DynamoDB 및 API Gateway에 캐시하여 S3에 저장된 이미지를 캐시합니다.

한 의료 서비스 회사가 환자 건강 모니터링 애플리케이션의 소프트웨어 라이선스 비용 증가에 대해 우려하고 있습니다. 이 회사는 애플리케이션이 Amazon EC2 전용 호스트에서 독점적으로 실행되고 있는지 확인하는 감사 프로세스를 생성하려고 합니다. DevOps 엔지니어는 규정 준수를 보장하기 위해 애플리케이션을 감사하는 워크플로를 만들어야 합니다. 엔지니어는 최소한의 관리 오버 헤드로이 요구 사항을 충족하기 위해 어떤 조치를 취해야합니까? A. AWS Systems Manager 구성 규정 준수를 사용합니다. put-compliance- items API 작업에 대한 호출을 사용하여 호스트 배치 구성을 기반으로 비준수 EC2 인스턴스의 데이터베이스를 스캔하고 구축합니다. 빠른 액세스를 위해 Amazon DynamoDB 테이블을 사용하여 이러한 인스턴스 ID를 저장합니다. list-compliance-summaries API 작업을 호출하여 Systems Manager를 통해 보고서를 생성합니다. B. EC2 인스턴스에서 실행되는 사용자 지정 Java 코드를 사용합니다. 확인할 인스턴스 수에 따라 인스턴스에 대한 EC2 Auto Scaling을 설정합니다. 비 준수 EC2 인스턴스 ID 목록을 Amazon SQS 대기열로 보냅니다. 다른 작업자 인스턴스를 설정하여 SQS 대기열에서 인스턴스 ID를 처리하고 Amazon DynamoDB에 기록합니다. AWS Lambda 함수를 사용하여 대기열에서 얻은 비 준수 인스턴스 ID를 종료하고 배포를 위해 Amazon SNS 이메일 주제로 보냅니다. C. AWS Config를 사용합니다. 리전의 모든 Amazon EC2 리소스에서 Config Recording을 활성화하여 감사할 모든 EC2 인스턴스를 식별합니다. "config-rule-change-triggered"청사진을 사용하여 AWS Lambda 함수를 트리거 하는 사용자 지정 AWS Config 규칙을 생성합니다. 인스턴스가 EC2 전용 호스트에서 실행되고 있지 않은 경우 NON_COMPLIANT 결과를 반환하도록 호스트 배치를 확인하도록 Lambda evaluationCompliance () 함수를 수정합니다. AWS Config 보고서를 사용하여 비준수 인스턴스를 해결하십시오. D. AWS CloudTrail을 사용합니다. EC2 RunCommand API 작업에 대한 모든 호출을 분석하여 감사할 모든 EC2 인스턴스를 식별합니다. 인스턴스의 호스트 배치를 분석하는 AWS Lambda 함수를 호출합니다. Amazon RDS MySOL DB 인스턴스에 비 준수 리소스의 EC2 인스턴스 ID를 저장합니다. RDS 인스턴스를 쿼리하고 쿼리 결과를 CSV 텍스트 파일로 내보내 보고서를 생성합니다.

한 회사가 AWS Lambda 및 Amazon API Gateway로 구동되는 서버리스 아키텍처를 사용하는 웹 및 모바일 애플리케이션을 구축하고 있습니다. 이 회사는 AWS CodeCommit 리포지토리의 적절한 환경 브랜치로 푸시되는 코드를 기반으로 백 엔드 Lambda 배포를 완전히 자동화하려고 합니다. 배포에는 다음이 있어야합니다. ▶ 테스트 및 프로덕션을 위한 별도의 환경 파이프 라인. ▶ 테스트 환경에서만 발생하는 자동 배포. 이러한 요구 사항을 충족하려면 어떤 조치를 취해야합니까? A. 새 AWS CodePipeline 서비스를 구성합니다. 각 환경에 대한 CodeCommit 리포지토리를 생성합니다. 적절한 리포지토리에서 소스 코드를 검색하도록 CodePipeline을 설정합니다. AWS CloudFormation으로 Lambda 함수를 배포하기위한 배포 단계를 설정합니다. B. 테스트 및 프로덕션 환경을 위한 두 개의 AWS CodePipeline 구성을 생성합니다. 수동 승인 단계를 갖도록 프로덕션 파이프 라인을 구성하십시오. 각 환경에 대한 CodeCommit 리포지토리를 생성합니다. 적절한 리포지토리에서 소스 코드를 검색하도록 각 CodePipeline을 설정합니다. AWS CloudFormation으로 Lambda 함수를 배포하기위한 배포 단계를 설정합니다. C. 테스트 및 프로덕션 환경을 위한 두 개의 AWS CodePipeline 구성을 생성합니다. 수동 승인 단계를 갖도록 프로덕션 파이프 라인을 구성하십시오. 각 환경에 대한 브랜치가 있는 하나의 CodeCommit 리포지토리를 생성합니다. 리포지토리의 적절한 브랜치에서 소스 코드를 검색하도록 각 CodePipeline을 설정합니다. AWS CloudFormation으로 Lambda 함수를 배포하기위한 배포 단계를 설정합니다. D. 테스트 및 프로덕션 환경을위한 AWS CodeBuild 구성을 생성합니다. 수동 승인 단계를 갖도록 프로덕션 파이프 라인을 구성하십시오. 각 환경에 대한 브랜치가있는 하나의 CodeCommit 리포지토리를 생성합니다. Lambda 함수 코드를 Amazon S3 버킷에 푸시합니다. S3 버킷에서 Lambda 함수를 배포하도록 배포 단계를 설정합니다.

회사에는 여러 AWS 계정이 있습니다. 계정은 주로 Amazon EC2 인스턴스를 위해 전 세계 여러 팀에서 공유되고 사용됩니다. 각 EC2 인스턴스에는 정확한 비용 할당을 보장하기 위해 팀, 환경 및 비용 센터에 대한 태그가 있습니다. DevOps 엔지니어는 팀이 비용을 감사하고 여러 공유 환경 및 계정에서 인프라 비용 최적화를 자동화하도록 어떻게 도와야합니까? A. 사용률을 보고하고 Amazon DynamoDB 테이블에 인스턴스를 저장하도록 EC2 인스턴스에 예약 된 스크립트를 설정합니다. DynamoDB를 소스 데이터로 사용하여 Amazon QuickSight에서 대시 보드를 생성하여 활용도가 낮은 인스턴스를 찾습니다. AWS Lambda의 Amazon QuickSight에서 트리거를 설정하여 활용도가 낮은 인스턴스를 줄이십시오. B. 비용 센터, 환경 및 팀을 기반으로 EC2 인스턴스 태그에 대한 별도의 Amazon CloudWatch 대시 보드를 생성하고 각 팀에 대한 고유 링크를 사용하여 인스턴스 태그를 게시합니다. 각 팀에 대해 CloudWatch 대시 보드를 소스로 사용하여 CloudWatch Events 규칙을 설정하고 AWS Lambda 함수를 시작하는 트리거를 설정하여 활용도가 낮은 인스턴스를 줄이십시오. C. AWS Trusted Advisor를 사용률이 낮은 EC2 인스턴스의 소스로 사용하여 Amazon CloudWatch Events 규칙을 생성합니다. 각 팀, 환경 및 비용 센터의 태그를 기반으로보고 된 데이터를 필터링하고 Amazon S3에 Lambda 함수를 저장하는 AWS Lambda 함수를 트리거합니다. Lambda 함수를 시작하는 두 번째 트리거를 설정하여 활용도가 낮은 인스턴스를 줄이십시오. D. AWS Systems Manager를 사용하여 인스턴스 사용률을 추적하고 사용률이 낮은 인스턴스를 Amazon CloudWatch 에 보고합니다. 팀, 환경 및 비용 센터에 대한 태그를 기반으로 CloudWatch의 데이터를 필터링합니다. CloudWatch에서 AWS Lambda로 트리거를 설정하여 활용도가 낮은 인스턴스를 줄입니다.

한 회사가 AWS에 중앙 집중식 로깅 솔루션을 설정하고 있으며 몇 가지 요구 사항이 있습니다. 이 회사는 Amazon CloudWatch Logs 및 VPC Flow 로그가 서로 다른 하위 계정에서 가져와 단일 감사 계정으로 전달되기를 원합니다. 그러나 서브 계정의 수는 계속 변경됩니다. 또한 회사는 실행 가능한 통찰력을 수집하기 위해 감사 계정의 로그를 인덱싱해야합니다. DevOps 엔지니어는 회사의 모든 요구 사항을 충족하기 위해 솔루션을 어떻게 구현해야합니까? A. AWS Lambda를 사용하여 감사 계정의 Amazon ES에 로그를 작성합니다. Amazon CloudWatch 구독 필터를 생성하고 하위 계정에서 Amazon Kinesis Data Streams를 사용하여 감사 계정에 배포 된 Lambda 함수로 로그를 스트리밍합니다. B. Amazon Kinesis Streams를 사용하여 감사 계정에서 Amazon ES에 로그를 작성합니다. CloudWatch 구독 필터를 생성하고 하위 계정에서 Kinesis Data Streams를 사용하여 감사 계정의 Kinesis 스트림으로 로그를 스트리밍합니다. C. Amazon Kinesis Firehose와 Kinesis Data Streams를 사용하여 감사 계정의 Amazon ES에 로그를 작성합니다. CloudWatch 구독 필터를 생성하고 하위 계정의 로그를 감사 계정의 Kinesis 스트림으로 스트리밍합니다. D. AWS Lambda를 사용하여 감사 계정의 Amazon ES에 로그를 작성합니다. CloudWatch 구독 필터를 생성하고 하위 계정에서 Lambda를 사용하여 감사 계정에 배포 된 Lambda 함수로 로그를 스트리밍합니다.

한 회사가 단일 Amazon EC2 인스턴스에서 실행되는 AWS로 애플리케이션을 마이그레이션하고 있습니다. 라이센스 제한으로 인해 응용 프로그램은 수평 확장을 지원하지 않습니다. 애플리케이션은 데이터베이스로 Amazon Aurora를 사용합니다. DevOps 엔지니어 아키텍트는 가용성 전반에서 복구하는 것 외에도 EC2 및 Aurora 장애로부터 자동으로 복구하기 위해 자동 치유를 어떻게 수행할 수 있습니까? 가장 비용 효율적인 방식으로 영역 (AZ)? A. 최소 및 최대 인스턴스 수가 1 인 EC2 Auto Scaling 그룹을 생성하고 AZ에 걸쳐 있습니다. 단일 노드 Aurora 인스턴스를 사용하십시오. B. EC2 인스턴스를 생성하고 인스턴스 복구를 활성화합니다. 두 번째 AZ에 읽기 전용 복제본이 있는 Aurora 데이터베이스를 생성하고 기본 데이터베이스 인스턴스가 실패하면 기본 데이터베이스 인스턴스로 승격합니다. C. 인스턴스 상태가 실패 상태에 도달하면 사용 가능한 AZ에서 새 EC2 인스턴스를 시작하도록 AWS Lambda 함수를 트리거 하는 Amazon CloudWatch Events 규칙을 생성합니다. 두 번째 AZ에 읽기 전용 복제본이 있는 Aurora 데이터베이스를 생성하고 기본 데이터베이스 인스턴스가 실패하면 기본 데이터베이스 인스턴스로 승격합니다. D. 인스턴스에 탄력적 IP 주소를 할당합니다. 두 번째 AZ에 두 번째 EC2 인스턴스를 생성합니다. 첫 번째 인스턴스가 실패할 때 탄력적 IP 주소를 두 번째 인스턴스로 이동하도록 AWS Lambda 함수를 트리거하는 Amazon CloudWatch Events 규칙을 생성합니다. 단일 노드 Aurora 인스턴스를 사용하십시오.

한 회사는 네트워킹, IAM 정책 및 여러 3 계층 애플리케이션으로 구성된 복잡한 시스템을 사용합니다. 새로운 시스템에 대한 요구 사항은 아직 정의 중이므로 최종 설계에 존재하는 AWS 구성 요소의 수를 알 수 없습니다. DevOps 엔지니어는 AWS를 사용하여 AWS 리소스 정의를 시작해야합니다. CloudFormation은 새로운 인프라를 자동화하고 버전을 제어합니다. CloudFormation을 사용하여 새로운 환경을 만드는 모범 사례는 무엇입니까? A. Amazon VPC를 사용하여 네트워킹 계층을 수동으로 구성한 다음 CloudFormation을 사용하여 다른 모든 리소스를 정의합니다. B. 시스템에 필요한 모든 리소스를 포함하는 단일 템플릿을 생성하여 버전 제어 할 템플릿이 하나만 있도록합니다. C. 시스템의 각 논리적 부분에 대해 여러 개의 개별 템플릿을 생성하고 CloudFormation에서 교차 스택 참조를 사용하며 버전 제어에서 여러 템플릿을 유지합니다. D. 시스템의 각 논리적 부분에 대해 여러 개의 개별 템플릿을 생성하고 세분화 된 제어를 위해 SDK를 실행하는 Amazon EC2 인스턴스를 사용하여 하나에서 다음으로 출력을 제공합니다.

한 회사에서 AWS CodeDeploy를 사용하여 소프트웨어 배포를 자동화하고 있습니다. 배포는 다음 요구 사항을 충족해야 합니다. ▶ 배포 중에 트래픽을 제공하기 위해 여러 인스턴스를 사용할 수 있어야합니다. 트래픽은 이러한 인스턴스간에 균형을 이루어야 하며 장애 발생시 인스턴스가 자동으로 복구되어야 합니다. ▶ 수동 프로비저닝없이 새 개정을 자동으로 배포하려면 새 인스턴스 집합을 시작해야합니다. ▶ 트래픽은 한 번에 새 인스턴스의 절반으로 새 환경으로 다시 라우팅 되어야 합니다. 트래픽이 인스턴스의 절반 이상으로 다시 라우팅 되면 배포가 성공해야 합니다. 그렇지 않으면 실패합니다. ▶ 트래픽을 새로운 인스턴스 집합으로 라우팅하기 전에 배포 프로세스 중에 생성된 임시 파일을 삭제해야 합니다. ▶ 성공적인 배포가 끝나면 배포 그룹의 원래 인스턴스를 즉시 삭제하여 비용을 줄여야 합니다. DevOps 엔지니어는 이러한 요구 사항을 어떻게 충족할 수 있습니까? A. Application Load Balancer 및 현재 위치 배포를 사용합니다. Auto Scaling 그룹을 배포 그룹과 연결합니다. 자동 복사 옵션을 사용하고 배포 구성으로 CodeDeployDefault.OneAtAtime을 사용합니다. 배포 그룹에서 원래 Auto Scaling 그룹 인스턴스를 종료하도록 AWS CodeDeploy에 지시하고 appspec.yml 내의 AllowTraffic 후크를 사용하여 임시 파일을 삭제합니다. B. Application Load Balancer 및 블루 / 그린 배포를 사용합니다. Auto Scaling 그룹 및 Application Load Balancer 대상 그룹을 배포 그룹과 연결합니다. Auto Scaling 그룹 자동 복사 옵션을 사용하고 최소 정상 호스트가 50 %로 정의 된 사용자 지정 배포 구성을 생성하고 해당 구성을 배포 그룹에 할당합니다. AWS CodeDeploy에 배포 그룹의 원래 인스턴스를 종료하도록 지시하고 appsec.yml 내의 BeforeBlock 트래픽 후크를 사용하여 임시 파일을 삭제합니다. C. Application Load Balancer 및 블루 / 그린 배포를 사용합니다. Auto Scaling 그룹 및 Application Load Balancer 대상 그룹을 배포 그룹과 연결합니다. Auto Scaling 그룹 자동 복사 옵션을 사용하고 CodeDeployDefault HalfAtAtime을 배포 구성으로 사용합니다. AWS CodeDeploy에 배포 그룹의 원래 권한을 종료하도록 지시하고 appspec.yml 내의 BeforeAllowTraffic 후크를 사용하여 임시 파일을 삭제합니다. D. Application Load Balancer 및 현재 위치 배포를 사용합니다. Auto Scaling 그룹 및 Application Load Balancer 대상 그룹을 배포 그룹과 연결합니다. Auto Scaling 그룹 자동 복사 옵션을 사용하고 CodeDeployDefault AllatOnce를 배포 구성으로 사용합니다. AWS CodeDeploy에 배포 그룹의 원래 인스턴스를 종료하도록 지시하고 appsec.yml 내의 BlockTraffic 후크를 사용하여 임시 파일을 삭제합니다.

한 회사에서 인프라를 코드로 배포하기 위해 여러 AWS CloudFormation 템플릿을 사용하고 있습니다. 대부분의 배포에서 회사는 Amazon EC2를 사용합니다. Auto Scaling 그룹. 새로운 AMI를 사용할 수있는 경우 DevOps 엔지니어는 템플릿에서 Auto Scaling 그룹에 대한 AMI를 업데이트해야합니다. 이러한 요구 사항을 어떻게 충족 할 수 있습니까? A. CloudFormation 템플릿에서 AMI 매핑을 관리합니다. Amazon CloudWatch Events를 사용하여 새 AMI를 감지하고 템플릿에서 매핑을 업데이트합니다. 시작 구성 리소스 블록에서 맵을 참조하십시오. B. AWS CloudFormation 템플릿의 조건을 사용하여 새 AMI를 사용할 수 있는지 확인하고 AMI ID를 반환합니다. 시작 구성 리소스 블록에서 반환 된 AMI ID를 참조합니다. C. 템플릿에서 AWS Lambda 지원 사용자 지정 리소스를 사용하여 AMI ID를 가져옵니다. 시작 구성 리소스 블록에서 반환 된 AMI ID를 참조합니다. D. Amazon EC2 m4.small 인스턴스를 시작하고 여기에서 스크립트를 실행하여 새 AMI를 확인합니다. 새 AMI를 사용할 수있는 경우 스크립트는 새 AMI ID로 시작 구성 리소스 블록을 업데이트해야합니다.

한 회사에서 일부 IAM 사용자가 Git 리포지토리 호스팅 서비스로 푸시 된 구성 파일에 AWS 액세스 키를 저장하고 있음을 발견했습니다. 노출 된 AWS 액세스 키가 사용되지 않도록 방지하면서 최소한의 관리 오버 헤드가 필요한 솔루션은 무엇입니까? A. 계정의 모든 AWS 액세스 키 목록을 생성하고 Git 리포지토리 호스팅 서비스에서 각 키를 검색하는 애플리케이션을 구축합니다. 일치하는 항목이 있으면 연결된 액세스 키를 비활성화하도록 응용 프로그램을 구성합니다. 그런 다음 애플리케이션을 AWS Elastic Beanstalk 작업자 환경에 배포하고 매시간 애플리케이션을 호출하는 주기적 작업을 정의합니다. B. Amazon Inspector를 사용하여 키가 온라인에 노출된 시기를 감지합니다. 키가 노출되면 Amazon Inspector에서 Amazon SNS 주제에 알림을 보내도록 합니다. SNS 주제를 구독하는 AWS Lambda 함수를 생성하여 키가 속한 IAM 사용자를 비활성화 한 다음 키를 사용할 수 없도록 삭제합니다. C. AWS Trusted Advisor를 구성하고 Trusted Advisor를 이벤트 소스로 사용하는 Amazon CloudWatch Events 규칙을 생성합니다. AWS Lambda 함수를 대상으로 호출하도록 CloudWatch 이벤트 규칙을 구성합니다. Lambda 함수가 노출된 액세스 키를 찾으면 사용할 수 없도록 액세스 키를 비활성화하도록 합니다. D. 키가 온라인에 노출되는 시기를 감지하는 AWS Config 규칙을 생성합니다. Haw AWS Config는 SNS 주제에 변경 알림을 보냅니다. SNS 주제를 구독하는 AWS Lambda 함수를 구성하여 AWS Config에서 보낸 알림을 확인한 다음 액세스 키를 비활성화하여 사용할 수 없도록 합니다.

회사 정책에 따라 프로덕션 Amazon VPC의 인스턴스간에 이동하는 IP 트래픽에 대한 정보를 캡처해야합니다. 캡처 메커니즘은 항상 활성화되어 있어야하며 구성 변경이 발생하면 보안 팀에 알려야합니다. 이러한 요구 사항을 충족하려면 어떻게해야합니까? A. AWS CloudFormation 템플릿의 UserData 섹션을 사용하여 프로비저닝 된 모든 Amazon EC2 인스턴스에 tcpdump를 설치합니다. 도구의 출력은 집계 및 쿼리를 위해 Amazon EFS로 전송됩니다. 또한 Amazon CloudWatch Events 규칙을 예약하면 AWS Lambda 함수를 호출하여 tcpdump가 실행 중인지 확인하고 예외가있는 경우 보안 조직에 이메일을 보냅니다. B. 프로덕션 VPC에 대한 흐름 로그를 생성하고 Amazon S3 버킷을 전송 대상으로 할당합니다. Amazon S3 이벤트 알림을 사용하여 새 로그 파일이 전송될 때 트리거되는 AWS Lambda 함수를 설정합니다. 이 Lambda 함수는 Amazon DynamoDB의 항목을 업데이트합니다. 이 항목은 로그가 도착하지 않았을 때 보안을 알리도록 Amazon CloudWatch Events 규칙을 예약하여 주기적으로 확인합니다. C. 프로덕션 VPC에 대한 흐름 로그를 생성합니다. "~ EC2 : VPC '유형의 리소스 구성 변경에 의해 트리거되는 AWS Config를 사용하여 새 규칙을 생성합니다. 규칙 구성의 일부로 지정된 VPC에 대한 흐름 로그를 조회하는 AWS Lambda 함수를 생성합니다. VPC 흐름 인 경우 로그가 구성되지 않은 경우 "~ NON_COMPLIANT"상태를 반환하고 보안 조직에 알립니다. D. AWS CloudTrail 서비스를 사용하여 새 추적을 구성합니다. AWS CloudFormation 템플릿의 UserData 섹션을 사용하여 프로비저닝 된 모든 Amazon EC2 인스턴스에 tcpdump를 설치합니다. Amazon Athena를 CloudTrail에 연결하고 흐름 로그 비활성화 이벤트를 모니터링하는 AWS Lambda 함수를 작성합니다. CloudTrail 항목이 발견되면 보안 조직에 알립니다.

회사는 개발 환경의 단일 Amazon EC2 인스턴스에서 데이터베이스를 실행합니다. 데이터는 EC2 인스턴스에 연결된 별도의 Amazon EBS 볼륨에 저장됩니다. Amazon Route 53 A 레코드가 생성되고 EC2 인스턴스를 가리 키도록 구성되었습니다. 회사는 인스턴스 또는 가용 영역 (AZ)이 실패할 때 데이터베이스 인스턴스의 복구를 자동화하려고 합니다. 이 회사는 또한 비용을 낮게 유지하고자 합니다. RTO는 4 시간이며 RPO는 12 시간입니다. DevOps 엔지니어는 이러한 요구 사항을 충족하기 위해 어떤 솔루션을 구현해야 합니까? A. 여러 AZ에서 최소 및 최대 인스턴스 수가 1 인 Auto Scaling 그룹에서 데이터베이스를 실행합니다. Auto Scaling 그룹에 수명주기 후크를 추가하고 수명주기 이벤트가 발생할 때 트리거되는 Amazon CloudWatch Events 규칙을 정의합니다. CloudWatch Events 규칙이 AWS Lambda 함수를 호출하여 이벤트를 기반으로 EC2 인스턴스에서 Amazon EBS 데이터 볼륨을 분리하거나 연결하도록 합니다. 데이터 볼륨을 마운트 하도록 EC2 인스턴스 UserData를 구성한 다음 (짧은 지연으로 실패 시 재시도) 데이터베이스를 시작하고 Route 53 레코드를 업데이트합니다. B. 서로 다른 AZ에있는 두 개의 개별 EC2 인스턴스에서 데이터베이스를 하나는 활성이고 다른 하나는 대기로 실행합니다. 활성 인스턴스에 데이터 볼륨을 연결합니다. EC2 인스턴스 종료 시 AWS Lambda 함수를 호출하도록 Amazon CloudWatch Events 규칙을 구성합니다. Lambda 함수는 대체 EC2 인스턴스를 시작합니다. 종료된 인스턴스가 활성 노드 인 경우 함수는 데이터 볼륨을 대기 노드에 연결합니다. 데이터베이스를 시작하고 Route 53 레코드를 업데이트합니다. C. 여러 AZ에서 최소 및 최대 인스턴스 수가 1 인 Auto Scaling 그룹에서 데이터베이스를 실행합니다. 4 시간마다 예약된 Amazon CloudWatch Events 규칙에 의해 트리거되는 AWS Lambda 함수를 생성하여 데이터 볼륨의 스냅 샷을 만들고 태그를 적용합니다. 인스턴스 UserData가 최신 스냅 샷을 가져와서 새 볼륨을 생성하고 볼륨을 연결 및 마운트 하도록 합니다. 그런 다음 데이터베이스를 시작하고 Route 53 레코드를 업데이트합니다. D. 서로 다른 AZ에있는 두 개의 개별 EC2 인스턴스에서 데이터베이스를 실행합니다. 인스턴스 중 하나를 마스터로 구성하고 다른 인스턴스를 대기로 구성합니다. 마스터와 대기 인스턴스 간의 복제를 설정합니다. Route 53 레코드를 마스터에 지정합니다. EC2 인스턴스 종료 시 AWS Lambda 함수를 호출하도록 Amazon CloudWatch Events 규칙을 구성합니다. Lambda 함수는 대체 EC2 인스턴스를 시작합니다. 종료된 인스턴스가 활성 노드 인 경우이 기능은 대기를 마스터로 승격하고 Route 53 레코드를 가리 킵니다.

회사에 예측 가능한 최대 트래픽 시간이있는 애플리케이션이 있습니다. 회사는 사용량이 많은 시간에만 애플리케이션 인스턴스가 확장되기를 원합니다. 애플리케이션은 Amazon DynamoDB에 상태를 저장합니다. 애플리케이션 환경은 개인 Git 리포지토리에 저장된 표준 Node.js 애플리케이션 스택 및 사용자 지정 Chef 레시피를 사용합니다. 어떤 솔루션이 가장 비용 효율적이고 애플리케이션 환경의 롤링 업데이트를 수행할 때 최소한의 관리 오버 헤드를 필요로합니까? A. Chef 레시피를 사용하여 Node.js 환경 및 애플리케이션 스택으로 사용자 지정 AMI를 생성합니다. Auto Scaling 그룹에서 AMI를 사용하고 필요한 시간 동안 예약된 조정을 설정한 다음 DynamoDB에 액세스 할 수있는 권한을 제공하는 Amazon EC2 IAM 역할을 설정합니다. B. 공식 Node.js Docker 이미지를 기반으로 애플리케이션 환경에 Chef 레시피를 사용하는 Docker 파일을 생성합니다. 애플리케이션 환경을위한 Amazon ECS 클러스터 및 서비스를 생성한 다음이 Docker 이미지를 기반으로 작업을 생성합니다. 예약된 조정을 사용하여 적절한 시간에 컨테이너를 조정하고 DynamoDB에 액세스 할 수있는 권한을 제공하는 작업 수준 IAM 역할을 연결합니다. C. AWS OpsWorks 스택을 구성하고 사용자 지정 Chef 쿡북을 사용합니다. 사용자 지정 레시피가 저장된 Git 리포지토리 정보를 추가하고 Node.js 애플리케이션 서버용 OpsWorks에 계층을 추가합니다. 그런 다음 배포 단계에서 애플리케이션을 배포하도록 사용자 지정 레시피를 구성합니다. 시간 기반 인스턴스를 구성하고 DynamoDB 액세스 권한을 제공하는 Amazon EC2 IAM 역할을 연결합니다. D. AWS OpsWorks 스택을 구성하고 사용자 지정 레시피를 Amazon S3 버킷에 푸시하고 S3 버킷을 가리 키도록 사용자 지정 레시피를 구성합니다. 그런 다음 표준 Node.js 애플리케이션 서버에 대한 애플리케이션 계층 유형을 추가하고 S3 버킷의 배포 단계에서 애플리케이션을 배포하도록 사용자 지정 레시피를 구성합니다. 시간 기반 인스턴스를 구성하고 DynamoDB 액세스 권한을 제공하는 Amazon EC2 IAM 역할을 연결합니다.

회사에는 Amazon DynamoDB에서 데이터를 읽는 AWS Lambda에서 실행되는 마이크로 서비스가 있습니다. Lambda 코드는 성공적인 테스트 후 개발자가 수동으로 배포합니다. 이제 회사는 테스트와 배포를 자동화하고 클라우드에서 실행해야합니다. 또한 각 마이크로 서비스의 새 버전에 대한 트래픽은 배포 후 시간이 지남에 따라 점진적으로 이동해야합니다. 어떤 솔루션이 모든 요구 사항을 충족하여 가장 빠른 개발자 속도를 보장합니까? A. AWS CodePipeline 구성을 생성하고 테스트를 통과 한 후 파이프 라인을 트리거하는 사후 커밋 후크를 설정합니다. AWS CodeDeploy를 사용하고 트래픽 비율과 간격을 지정하는 Canary 배포 구성을 생성합니다. B. 테스트 코드가 푸시 될 때 트리거되는 AWS CodeBuild 구성을 생성합니다. AWS CloudFormation을 사용하여 새 Lambda 버전을 배포하고 트래픽 이동 비율 및 간격을 지정하는 AWS CodePipeline 구성을 트리거합니다. C. AWS CodePipeline 구성을 생성하고 코드가 푸시 될 때 트리거 할 소스 코드 단계를 설정합니다. AWS CodeBuild를 사용하여 테스트를 실행하도록 빌드 단계를 설정합니다. 배포할 AWS CodeDeploy 구성을 설정한 다음 CodeDeployDefault.LambdaLinear10PercentEvery3Minutes 옵션을 선택합니다. D. AWS CLI를 사용하여 테스트를 통과 한 후 Amazon S3 버킷에 코드를 업로드하는 커밋 후 후크를 설정합니다. 새 버전을 배포하는 Lambda 함수를 실행하는 S3 이벤트 트리거를 설정합니다. Lambda 함수에서 간격을 사용하여 필요한 비율로 시간이 지남에 따라 코드를 배포합니다.

한 회사에서 Amazon ECS를 사용하여 Docker 컨테이너 런타임 환경을 제공하려고 합니다. 규정 준수를 위해 ECS 클러스터에 사용되는 모든 Amazon EBS 볼륨을 암호화해야 합니다. 클러스터 인스턴스에 대한 롤링 업데이트가 수행되고 회사는 종료되기 전에 인스턴스가 모든 작업에서 드레이닝 되기를 원합니다. 이러한 요구 사항을 어떻게 충족할 수 있습니까? (2 개 선택) A. 기본 ECS AMI 사용자 데이터를 수정하여 실행중인 모든 컨테이너 인스턴스에 대해 docker rm ""f {id}를 실행하는 스크립트를 생성합니다. 스크립트를 /etc/init.d/rc.d 디렉토리에 복사하고 chconfig를 실행하여 운영 체제 종료 중에 스크립트가 실행되도록 합니다. B. AWS CodePipeline을 사용하여 Amazon에서 제공 한 최신 ECS AMI를 검색하는 파이프 라인을 구축 한 다음 이미지를 암호화 된 AMI ID를 출력하는 암호화 된 AMI에 복사합니다. 클러스터를 배포할 때 암호화된 AMI ID를 사용하십시오. C. ECS가 클러스터 인스턴스를 배포하는 데 사용하는 기본 AWS CloudFormation 템플릿을 복사합니다. 템플릿 리소스 EBS 구성 설정을 수정하여 "˜Encrypted : True '를 설정하고 AWS KMS 별칭 :"˜aws / ebs'를 포함하여 AMI를 암호화합니다. D. AWS SDK를 사용하여 종료 인스턴스를 DRAINING으로 표시하는 AWS Lambda 함수로 지원되는 Auto Scaling 수명주기 후크를 생성합니다. 인스턴스에서 실행중인 작업이 0이 될 때까지 수명주기 후크가 완료되지 않도록 합니다. E. ECS :: EncryptedImage 작업을 허용하는 IAM 역할을 생성합니다. 이 역할을 사용하도록 AWS CLI 및 프로필을 구성합니다. --use-encrypted-image 및 --kms-key 인수를 create-cluster ECS 명령에 제공하는 AWS CLI를 사용하여 클러스터를 시작합니다.

AWS API Gateway를 사용하는 새 애플리케이션에 대한 작업 개념 증명을 제시한 후 개발자는 프로젝트에 대한 팀 개발 환경을 설정해야 합니다. 빡빡한 일정으로 인해 개발자는 인프라 설정에 소요되는 시간을 최소화하고 개념 증명을 위해 생성 된 코드 저장소를 재사용하려고 합니다. 현재 모든 소스 코드는 AWS CodeCommit에 저장됩니다. 회사 정책은 모든 단계에서 코드를 빌드하고 테스트를 실행하기 위해 별도의 Jenkins 서버가있는 알파, 베타 및 프로덕션 단계를 요구합니다. 개발 관리자는 언제든지 관리자 간의 코드 전파를 차단할 수 있어야합니다. 보안 팀은 사용자가 허가없이 환경을 수정할 수 없도록하려고 합니다. 어떻게 이룰 수 있습니까? A. API Gateway 알파, 베타 및 프로덕션 단계를 생성합니다. AWS Lambda 함수를 사용하여 여러 단계에 코드를 배포하는 CodeCommit 트리거를 생성합니다. B. API Gateway 알파, 베타 및 프로덕션 단계를 생성합니다. CodeCommit 리포지토리에서 코드를 가져오는 AWS CodePipeline을 생성합니다. CodePipeline 작업을 생성하여 API Gateway 단계에 코드를 배포합니다. C. Amazon EC2 인스턴스에서 알파, 베타 및 프로덕션 단계를위한 Jenkins 서버를 생성합니다. AWS Lambda 함수를 사용하여 여러 단계에 코드를 배포하는 여러 CodeCommit 트리거를 생성합니다. D. CodeCommit 리포지토리에서 코드를 가져 오는 AWS CodePipeline 파이프 라인을 생성합니다. CodePipeline에서 Jenkins 서버로 알파, 베타 및 프로덕션 단계를 생성합니다.

DevOps 엔지니어는 EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스 집합에서 AWS CodeDeploy를 사용하고 있습니다. EC2 Auto Scaling과 통합된 연결된 CodeDeploy 배포 그룹은 CodeDeployDefault.OneAtATime을 사용하여 인플레 이스 배포를 수행하도록 구성됩니다. 진행중인 새 배포 중에 엔지니어는 전체 배포가 성공적으로 완료되었지만 인스턴스 5 개 중 2 개에 이전 애플리케이션 개정이 배포되어 있음을 발견했습니다. 다른 세 개의 인스턴스에는 최신 애플리케이션 개정이 있습니다. 이 문제의 원인은 무엇입니까? A. 영향을 받는 두 인스턴스가 새 배포를 가져 오지 못했습니다. B. 실패한 AfterInstall 수명주기 이벤트 후크로 인해 CodeDeploy 에이전트가 영향을받는 인스턴스의 이전 버전으로 롤백 되었습니다. C. CodeDeploy 에이전트가 영향을받는 두 인스턴스에 설치되지 않았습니다. D. EC2 Auto Scaling은 새 배포가 아직 완료되지 않은 상태에서 두 개의 새 인스턴스를 시작하여 영향을받는 인스턴스에 이전 버전이 배포되었습니다.

개발자는 50 대의 Amazon EC2 Linux 서버를 유지 관리하고 있습니다. 서버는 Amazon EC2 Auto Scaling 그룹의 일부이며 Elastic Load도 사용합니다. 로드 밸런싱을 위한 밸런싱. 때때로 일부 애플리케이션 서버는 ELB HTTP 상태 확인에 실패한 후 종료됩니다. 개발자가 문제에 대한 근본 원인 분석을 수행하려고하지만 애플리케이션 로그에 액세스하기 전에 서버가 종료됩니다. 로그 수집은 어떻게 자동화할 수 있습니까? A. Auto Scaling 수명주기 후크를 사용하여 인스턴스를 Pending : Wait 상태로 설정합니다. EC2 인스턴스에 대한 Amazon CloudWatch 경보 생성 SSM Run Command 스크립트를 실행하는 AWS Lambda 함수를 종료하고 트리거 하여 로그를 수집하고 Amazon S3로 푸시 한 후 로그가 수집되면 성공적인 수명주기 작업을 완료합니다. B. Auto Scaling 수명주기 후크를 사용하여 인스턴스를 Terminating : Wait 상태로 설정합니다. EC2 Instance-terminate Lifecycle에 대한 Config 규칙을 생성하고 스크립트를 실행하여 로그를 수집하고 Amazon S3로 푸시하고 로그가 수집되면 수명주기 작업을 완료하는 단계 함수를 트리거 합니다. 동작 C. Auto Scaling 수명주기 후크를 사용하여 인스턴스를 Terminating : Wait 상태로 설정합니다. EC2 인스턴스에 대한 Amazon CloudWatch 구독 필터를 생성하고 로그를 호출하는 스크립트를 실행하는 CloudWatch 에이전트를 트리거하고,이를 Amazon S3로 푸시하고, 로그가 수집되면 수명주기 작업 종료 성공을 완료합니다. D. Auto Scaling 수명주기 후크를 사용하여 인스턴스를 Terminating : Wait 상태로 설정합니다. EC2 인스턴스에 대한 Amazon CloudWatch Events 규칙을 생성하고 SSM Run Command 스크립트를 실행하여 로그를 수집하고 Amazon S3로 푸시하고 수명주기 작업을 종료하고 로그가 수집되면 수명주기 작업을 완료하는 AWS Lambda 함수를 트리거 합니다.

레거시 웹 애플리케이션은 액세스 로그를 독점적 인 텍스트 형식으로 저장합니다. 보안 요구 사항 중 하나는 애플리케이션 액세스 이벤트를 검색하고 이를 다양한 시스템의 액세스 데이터와 연관시키는 것입니다. 이러한 검색은 거의 실시간이어야 합니다. 어떤 솔루션이 애플리케이션 서버의 처리 부하를 덜어주고 거의 실시간으로 데이터를 검색하는 메커니즘을 제공합니까? A. 애플리케이션 서버에 Amazon CloudWatch Logs 에이전트를 설치하고 CloudWatch 이벤트 규칙을 사용하여 액세스 이벤트에 대한 로그를 검색합니다. Amazon CloudSearch를 인터페이스로 사용하여 이벤트를 검색합니다. B. 타사 파일 입력 플러그인 Logstash를 사용하여 애플리케이션 로그 파일을 모니터링 한 다음 에이전트에서 사용자 지정 dissect 필터를 사용하여 로그 항목을 JSON 형식으로 구문 분석합니다. 검색할 Amazon ES에 이벤트를 출력합니다. Elasticsearch API를 사용하여 데이터를 쿼리하십시오. C. S3 sync 명령을 사용하여 Amazon S3에 로그 파일을 업로드합니다. Amazon Athena를 사용하여 데이터 구조를 테이블로 정의하고 Athena SQL 쿼리를 통해 액세스 이벤트를 검색합니다. D. 애플리케이션 서버에 Amazon Kinesis 에이전트를 설치하고 로그 파일을 모니터링하도록 구성한 다음 Kinesis 스트림으로 보냅니다. AWS Lambda 함수를 사용하여 데이터를 변환하도록 Kinesis를 구성하고 분석을 위해 이벤트를 Amazon ES로 전달합니다. Elasticsearch API를 사용하여 데이터를 쿼리하십시오.

애플리케이션에는 여러 AWS 계정에 분산된 마이크로 서비스가 있으며 일부 기능을 위해 온 프레미스 레거시 시스템과 통합됩니다. 세그먼트 화 된 아키텍처와 누락된 로그로 인해 애플리케이션에 문제가 발생할 때마다 문제를 식별하기 위해 로그를 수집하는 데 너무 오래 걸립니다. DevOps 엔지니어는 로그 집계 프로세스를 수정하고 로그를 중앙에서 분석하는 방법을 제공해야합니다. 가장 효율적이고 비용 효율적인 솔루션은 무엇입니까? A. Amazon CloudWatch Logs 에이전트를 사용하여 시스템 로그 및 애플리케이션 로그를 수집합니다. Amazon S3 API를 사용하여 온 프레미스 로그를 내보내고 중앙 계정의 S3 버킷에 로그를 저장합니다. Amazon EMR 클러스터를 구축하여 로그를 줄이고 근본 원인을 도출하십시오. B. Amazon CloudWatch Logs 에이전트를 사용하여 시스템 로그 및 애플리케이션 로그를 수집합니다. Amazon S3 API를 사용하여 온 프레미스 로그를 가져옵니다. 개별 계정의 S3 버킷에 모든 로그를 저장합니다. Amazon Macie를 사용하여 필요한 특정 이벤트 관련 데이터 포인트를 검색하는 쿼리를 작성합니다. C. Amazon CloudWatch Logs 에이전트를 사용하여 시스템 로그 및 애플리케이션 로그를 수집합니다. 온 프레미스 서버에 CloudWatch Logs 에이전트를 설치합니다. AWS의 모든 로그를 온 프레미스 데이터 센터로 전송합니다. Amazon Elasticsearch Logstash Kibana 스택을 사용하여 온 프레미스 에서 로그를 분석합니다. D. Amazon CloudWatch Logs 에이전트를 사용하여 시스템 로그 및 애플리케이션 로그를 수집합니다. 온 프레미스 리소스 용 CloudWatch Logs 에이전트를 설치합니다. 중앙 계정의 S3 버킷에 모든 로그를 저장합니다. Amazon S3 트리거와 AWS Lambda 함수를 설정하여 수신 로그를 분석하고 이상 징후를 자동으로 식별합니다. Amazon Athena를 사용하여 중앙 계정의 로그에 대해 임시 쿼리를 실행합니다.

애플리케이션은 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행됩니다. Amazon RDS MySOL은 백 엔드에서 사용됩니다. 인스턴스는 자동으로 실행됩니다. 여러 가용 영역에 걸쳐 그룹 조정. Application Load Balancer 상태 확인은 웹 서버가 작동하고 있고 읽기 / 쓰기가 가능한지 확인합니다. SQL 연결. Amazon Route 53은 Application Load Balancer를 가리키는 레코드와 함께 DNS 기능을 제공합니다. 새 정책에는 RTO가 4 시간이고 RPO가 15 분인 지리적으로 격리된 재해 복구 사이트가 필요합니다. 애플리케이션 스택을 최소한으로 변경해야 하는 재해 복구 전략은 무엇입니까? A. 다른 가용 영역에서 RDS를 제외한 모든 항목의 복제 본 스택을 시작합니다. 새 가용 영역에 RDS 읽기 전용 복제본을 생성하고 로컬 RDS 인스턴스를 가리 키도록 새 스택을 구성합니다. 장애 조치 라우팅 정책을 사용하여 Route 53 레코드 세트에 새 스택을 추가합니다. B. 다른 리전에서 RDS를 제외한 모든 항목의 복제 본 스택을 시작합니다. 새 리전에 RDS 읽기 전용 복제본을 생성하고 로컬 RDS 인스턴스를 가리 키도록 새 스택을 구성합니다. 지연 시간 라우팅 정책을 사용하여 Route 53 레코드 세트에 새 스택을 추가합니다. C. 다른 지역에서 RDS를 제외한 모든 항목의 복제 본 스택을 시작합니다. 실패 시 기본 지역에서 재해 복구 지역으로 스냅 샷을 복사합니다. 재해 복구 지역의 Application Load Balancer를 가리 키도록 Amazon Route 53 레코드 세트를 조정합니다. D. 다른 지역에서 RDS를 제외한 모든 항목의 복제본 스택을 시작합니다. 새 리전에 RDS 읽기 전용 복제본을 생성하고 로컬 RDS 인스턴스를 가리 키도록 새 스택을 구성합니다. 장애 조치 라우팅 정책을 사용하여 Amazon Route 53 레코드 세트에 새 스택을 추가합니다.

엔지니어링 팀은 Node.js 전자 상거래 애플리케이션을 관리합니다. 현재 환경은 다음 구성 요소로 구성됩니다. ▶ 콘텐츠 저장을위한 Amazon S3 버킷 ▶ 프런트 엔드 웹 서버를위한 Amazon EC2 ▶ 이미지 처리를 실행하기위한 AWS Lambda ▶ 세션 관련 데이터를 저장하기위한 Amazon DynamoDB 팀은 사이트에 대한 트래픽이 크게 증가 할 것으로 예상합니다. 애플리케이션은 중단없이 추가로드를 처리해야합니다. 팀은 더 큰 부하를 처리하기 위해 EC2 프런트 엔드에 새 서버를 추가하여 초기 테스트를 실행했지만 인스턴스가 완전히 구성되는 데 최대 20 분이 걸렸습니다. 팀은 이 구성 시간을 줄이고 자합니다. 예상되는 수요 증가를 충족하면서 가장 탄력적이고 가용성이 뛰어난 솔루션을 만들기 위해 엔지니어링 팀이 구현해야하는 변경 사항은 무엇입니까? A. AWS OpsWorks를 사용하여 새로운 EC2 인스턴스가 시작될 때마다 자동으로 구성합니다. 여러 가용 영역에서 Application Load Balancer 뒤의 Auto Scaling 그룹을 사용하여 EC2 인스턴스를 구성합니다. Amazon DynamoDB Auto Scaling을 구현합니다. Amazon Route 53을 사용하여 애플리케이션 DNS 레코드가 Application Load Balancer를 가리 키도록합니다. B. EC2 인스턴스 집합을 배포하고 현재 용량을 두 배로 늘린 다음 Application Load Balancer 뒤에 배치합니다. Amazon DynamoDB 읽기 및 쓰기 용량 단위를 늘립니다. Application Load Balancer 엔드 포인트를 포함하는 별칭 레코드를 애플리케이션을 가리키는 기존 Amazon Route 53 DNS 레코드에 추가합니다. C. Amazon CloudFront를 구성하고 웹 애플리케이션을 호스팅하기 위해 Amazon S3를 원점으로 설정합니다. Amazon DynamoDB Auto Scaling을 구현합니다. Amazon Route 53을 사용하여 애플리케이션 DNS 레코드가 CloudFront DNS 이름을 가리 키도록합니다. D. 모든 웹 구성 요소를 포함하는 사용자 지정 AMI와 함께 AWS Elastic Beanstalk를 사용합니다. 여러 가용 영역에서 Application Load Balancer 뒤의 Auto Scaling 그룹을 사용하여 플랫폼을 배포합니다. Amazon DynamoDB Auto Scaling을 구현합니다. Amazon Route 53을 사용하여 애플리케이션 DNS 레코드가 Elastic Beanstalk로드 밸런서를 가리 키도록합니다.

온라인 소매 업체의 개발 팀은 비즈니스 지원으로 이동했으며 AWS 상태 대시 보드 및 AWS 상태 API를 활용하여 AWS 리소스 상태 문제에 대한 교정 작업을 자동화하려고 합니다. 첫 번째 사용 사례는 퍼블릭 코드 리포지토리 사이트에 나열된 IAM 액세스 키를 감지하는 AWS에 대응하는 것입니다. 자동 응답은 IAM 액세스 키를 삭제하고 보안 팀에 알림을 보내는 것입니다. 어떻게 해야 합니까? A. AWS Lambda 함수를 생성하여 IAM 액세스 키를 삭제합니다. AWS CloudTrail 로그를 AWS CloudWatch 로그로 보냅니다. 두 가지 작업으로 AWS_RISK_CREDENTIALS_EXPOSED 이벤트에 대한 CloudWatch Logs 지표 필터를 생성합니다. 먼저 Lambda 함수를 실행합니다. 둘째, Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다. B. AWS Lambda 함수를 생성하여 IAM 액세스 키를 삭제합니다. 두 가지 작업으로 aws.health 및 AWS_RISK_CREDENTIALS_EXPOSED 이벤트의 변경 사항에 대한 AWS Config 규칙을 생성합니다. 먼저 Lambda 함수를 실행합니다. 둘째, Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다. C. AWS Step Functions를 사용하여 IAM 액세스 키를 삭제하는 함수를 생성 한 다음 Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다. AWS_RISK_CREDENTIALS_EXPOSED 이벤트에 대한 AWS Personal Health Dashboard 규칙을 생성합니다. Personal Health Dashboard 규칙의 대상을 Step Functions로 설정합니다. D. AWS Step Functions를 사용하여 IAM 액세스 키를 삭제하는 함수를 생성 한 다음 Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다. aws.health 이벤트 소스 및 AWS_RISK_CREDENTIALS_EXPOSED 이벤트를 사용하여 Amazon CloudWatch Events 규칙을 생성하고 CloudWatch Events 규칙의 대상을 Step Functions로 설정합니다.

프로덕션 계정에는 수동으로 로그인 한 모든 Amazon EC2 인스턴스를 24 시간 이내에 종료 해야 한다는 요구 사항이 있습니다. 프로덕션 계정의 모든 애플리케이션은 Amazon CloudWatch Logs 에이전트가 구성된 Auto Scaling 그룹을 사용하고 있습니다. 이 프로세스를 어떻게 자동화 할 수 있습니까? A. AWS Step Functions 애플리케이션에 대한 CloudWatch Logs 구독을 생성합니다. 로그인 이벤트를 생성 한 EC2 인스턴스에 태그를 추가하고 인스턴스를 해제 할 것으로 표시하도록 함수를 구성합니다. 그런 다음이 태그 가 있는 모든 인스턴스를 종료하는 두 번째 AWS Lambda 함수를 하루에 한 번 트리거하는 CloudWatch Events 규칙을 생성합니다. B. 로그인 이벤트에서 트리거 할 CloudWatch 경보를 생성합니다. 운영 팀이 구독 한 Amazon SNS 주제에 알림을 보내고 24 시간 이내에 EC2 인스턴스를 종료 하도록 합니다. C. 로그인 이벤트에서 트리거 할 CloudWatch 경보를 생성합니다. Amazon SQS 대기열로 보내도록 경보를 구성합니다. 작업자 인스턴스 그룹을 사용하여 대기열의 메시지를 처리 한 다음 Amazon CloudWatch Events 규칙이 트리거되도록 예약합니다. D. AWS Lambda 함수에서 CloudWatch Logs 구독을 생성합니다. 로그인 이벤트를 생성 한 EC2 인스턴스에 태그를 추가하고 인스턴스를 해제 할 것으로 표시하도록 함수를 구성합니다. 이 태그 가 있는 모든 인스턴스를 종료하는 일일 Lambda 함수를 트리거하는 CloudWatch 이벤트 규칙을 생성합니다.

한 스타트 업 회사가 AWS에서 웹 애플리케이션을 개발하고 있습니다. 지속성을 위해 Amazon RDS를 사용하고 자동으로 Amazon EC2에 애플리케이션을 배포할 계획입니다. 스케일링 그룹. 회사는 또한 개발, 테스트 및 생산을 위해 환경을 분리하려고 합니다. 애플리케이션 구성을 관리하기위한 가장 안전하고 유연한 접근 방식은 무엇입니까? A. 구성 및 암호화 된 암호를 포함하는 속성 파일을 만듭니다. 속성 파일을 소스 저장소에 체크인하고 애플리케이션과 함께 속성 파일을 패키징 한 다음 애플리케이션을 배포합니다. EC2 인스턴스에 대한 환경 태그를 생성하고 인스턴스에 각각 태그를 지정합니다. 애플리케이션은 환경 태그를 기반으로 필요한 속성 값을 추출합니다. B. 환경 별 구성 및 암호화 된 암호를 포함하도록 각 환경에 대한 속성 파일을 만듭니다. 소스 저장소에 특성 파일을 체크인하십시오. 배포 중에는 응용 프로그램과 함께 환경 별 속성 파일 만 사용하십시오. 응용 프로그램은 배포된 속성 파일에서 필요한 속성 값을 읽습니다. C. 환경 별 구성을 포함하도록 각 환경에 대한 속성 파일을 만듭니다. 프라이빗 Amazon S3 버킷을 생성하고 버킷에 속성 파일을 저장합니다. AWS KMS 암호화를 사용하여 버킷에 암호를 저장합니다. 배포 중에 애플리케이션은 S3 버킷의 환경 별 속성 파일에서 필요한 속성 값을 읽습니다. D. 환경 별 구성을 포함하도록 각 환경에 대한 속성 파일을 만듭니다. 프라이빗 Amazon S3 버킷을 생성하고 버킷에 속성 파일을 저장합니다. AWS Systems Manager Parameter Store에 암호화 된 암호를 저장합니다. EC2 인스턴스에 대한 환경 태그를 생성하고 인스턴스에 각각 태그를 지정합니다. 애플리케이션은 S3 버킷 및 파라미터 스토어의 환경 별 속성 파일에서 필요한 속성 값을 읽습니다.

한 컨설팅 회사를 고용하여 클라이언트 회사의 애플리케이션 내 보안 취약성을 평가하고 확인된 모든 문제를 해결하기위한 계획을 제안했습니다. 아키텍처는 콘텐츠 용 Amazon S3 스토리지, Amazon EBS 스토리지가 연결된 Elastic Load Balancer 뒤의 Amazon EC2 인스턴스의 Auto Scaling 그룹, Amazon RDS MySQL 데이터베이스로 식별됩니다. 코드의 연결 문자열 문을 사용하여 RDS 데이터베이스와 직접 통신하는 여러 AWS Lambda 함수도 있습니다. 컨설턴트는 다음과 같이 주요 보안 위협을 식별했습니다. 애플리케이션이 유휴 상태의 암호화 요구 사항을 충족하지 않습니다. 최소한의 운영 오버 헤드로이 문제를 해결하고 잠재적 인 향후 위반에 대한 모니터링을 제공하는 솔루션은 무엇입니까? A. S3 버킷 및 RDS 데이터베이스에서 SSE 암호화를 활성화합니다. EBS 볼륨에서 데이터의 OS 기반 암호화를 활성화합니다. 안전하지 않은 암호화 암호에 대해 보고하도록 EC2 인스턴스에서 Amazon Inspector 에이전트를 구성합니다. 암호화되지 않은 S3 객체를 주기적으로 확인하도록 AWS Config 규칙을 설정합니다. B. Amazon S3에 저장하기 전에 각 파일을 암호화하도록 애플리케이션을 구성합니다. EBS 볼륨에서 데이터의 OS 기반 암호화를 활성화합니다. RDS에 쓸 때 데이터를 암호화합니다. 각 인스턴스에서 크론 작업을 실행하여 암호화된 데이터를 확인하고 Amazon SNS를 통해 알립니다. S3 이벤트를 사용하여 AWS Lambda 함수를 호출하고 파일이 암호화되었는지 확인합니다. C.로드 밸런서에서 SSL (Secure Sockets Layer)을 활성화하고 AWS Lambda가 SSL을 사용하여 RDS 데이터베이스와 통신하는지 확인하고 S3 암호화를 활성화합니다. 들어오는 연결에 SSL을 적용하도록 애플리케이션을 구성하고 세션이 암호화된 경우에만 액세스 권한을 부여하도록 RDS를 구성합니다. 안전하지 않은 암호화 암호에 대해 보고하도록 EC2 인스턴스에서 Amazon Inspector 에이전트를 구성합니다. D. S3 버킷, EBS 볼륨 및 RDS 데이터베이스에서 SSE 암호화를 활성화합니다. EC2 Parameter Store에 RDS 자격 증명을 저장합니다. S3 버킷에서 정책을 활성화하여 암호화되지 않은 넣기를 거부합니다. 암호화되지 않은 S3 객체 및 EBS 볼륨을 주기적으로 확인하고 RDS 스토리지가 암호화되었는지 확인하도록 AWS Config 규칙을 설정합니다.

한 회사는 ELB Application Load Balancer 뒤의 Amazon EC2 인스턴스로 구성된 단일 AWS CloudFormation 템플릿을 기반으로하는 프로덕션 환경에서 3 계층 웹 애플리케이션을 실행합니다. 인스턴스는 여러 가용 영역에 걸쳐 EC2 Auto Scaling 그룹에서 실행됩니다. 데이터는 읽기 전용 복제본이 있는 Amazon RDS 다중 AZ DB 인스턴스. Amazon Route 53은 애플리케이션의 퍼블릭 DNS 레코드를 관리합니다. DevOps 엔지니어는 새 애플리케이션 소프트웨어에 대한 소프트웨어 전환이 발생할 때 프로덕션 환경의 변경 사항을 롤백하여 실패한 소프트웨어 배포를 완화하는 워크 플로를 만들어야 합니다. 최소한의 다운 타임으로 이러한 요구 사항을 충족하기 위해 엔지니어는 어떤 단계를 수행해야합니까? A. CloudFormation을 사용하여 추가 스테이징 환경을 배포하고 가중치 기반 레코드로 Route 53 DNS를 구성합니다. 컷 오버 중에 Route 53 A 레코드 가중치를 변경하여 두 환경간에 균등 한 트래픽 분배를 달성하십시오. 새 환경에서 트래픽을 확인하고 테스트가 성공하면 즉시 이전 환경을 종료합니다. B. 단일 AWS Elastic Beanstalk 환경을 사용하여 스테이징 및 프로덕션 환경을 배포합니다. 새 애플리케이션 코드로 ZIP 파일을 업로드하여 환경을 업데이트하십시오. Elastic Beanstalk 환경 CNAME을 바꿉니다. 새 환경에서 트래픽을 확인하고 테스트가 성공하면 즉시 이전 환경을 종료합니다. C. 단일 AWS Elastic Beanstalk 환경과 AWS OpsWorks 환경을 사용하여 스테이징 및 프로덕션 환경을 배포합니다. 새 애플리케이션 코드가 포함 된 ZIP 파일을 OpsWorks 스택과 함께 배포 된 Elastic Beanstalk 환경에 업로드하여 환경을 업데이트합니다. 새 환경에서 트래픽을 확인하고 테스트가 성공하면 즉시 이전 환경을 종료합니다. D. AWS CloudFormation을 사용하여 추가 스테이징 환경을 배포하고 가중치 기반 레코드로 Route 53 DNS를 구성합니다. 컷 오버 중에 워크로드가 성공적으로 검증됨에 따라 더 많은 트래픽이 새 스테이징 환경으로 전달되도록 가중치 분배를 늘리십시오. 새 스테이징 환경이 모든 트래픽을 처리 할 때까지 이전 프로덕션 환경을 그대로 유지하십시오.

회사는 AWS로 전환하기 전에 기업 에코 시스템에서 Amazon Linux에서 실행되는 애플리케이션의 일관된 동작을 보장해야 합니다. 이 회사는 VMware를 사용하는 기존 자동 서버 구축 시스템을 보유하고 있습니다. 목표는 새 대상 운영 체제에서 응용 프로그램의 기능과 해당 전제 조건을 보여주는 것입니다. DevOps 엔지니어는 기존 회사 서버 파이프 라인과 가상화 소프트웨어를 사용하여 서버 이미지를 만들어 야합니다. 서버 이미지는 Amazon EC2의 빌드와 최대한 유사하게 온 프레미스에서 테스트됩니다. 어떻게 이룰 수 있습니까? A. CentOS 7의 최신 ISO를 다운로드 및 통합하고 결과 서버에서 애플리케이션 배포를 실행합니다. B. 온 프레미스 인프라에서 AWS OpsWorks 배포 에이전트를 사용하여 Amazon Linux AMI를 시작한 다음 애플리케이션 배포를 실행합니다. C. 최신 Amazon Linux 운영 체제로 EC2 인스턴스를 구축하고 AWS Import / Export 서비스를 사용하여 EC2 이미지를 Amazon S3의 VMware ISO로 내 보냅니다. 그런 다음 결과 ISO를 온 프레미스 시스템으로 가져옵니다. D. Amazon Linux 2의 최신 ISO를 다운로드 및 통합하고 결과 서버에서 애플리케이션 배포를 실행합니다. 운영 체제 테스트 결과가 EC2 운영 체제 동작과 일치하는지 확인합니다.

DevOps 엔지니어는 3 개의 가용 영역에 걸쳐 12 개의 Amazon EC2 인스턴스에 배포된 애플리케이션으로 작업하고 있습니다. AMI 이미지에서 새 인스턴스를 시작할 수 있습니다. 평일에 각 EC2 인스턴스는 업무 시간 동안 사용률이 30 %이고 업무 시간 후에 사용률이 10 %입니다. CPU 사용률은 업무 시간의 처음 몇 분 동안 즉시 급증합니다. CPU 사용률의 다른 증가는 점진적으로 증가합니다. 엔지니어는 동일하거나 더 높은 신뢰성을 유지하면서 비용을 줄 이도록 요청 받았습니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? A. 업무 시간 시작 및 종료 전후 일정이 있는 두 개의 Amazon CloudWatch Events 규칙을 생성합니다. 각 규칙에 의해 호출되는 AWS Lambda 함수 2 개를 생성합니다. 첫 번째 기능은 업무 시간이 종료된 후 9 개의 인스턴스를 중지해야 하고, 두 번째 기능은 영업일이 시작되기 전에 9 개의 인스턴스를 다시 시작해야합니다. B. 목표가 75 % 인 Auto Scaling 그룹의 CPU 사용률 평균을 기반으로 한 조정 작업으로 AMI 이미지를 사용하여 Amazon EC2 Auto Scaling 그룹을 생성합니다. 그룹의 최소 인스턴스 수를 업무 시간 종료 후 3 개로 조정하고 업무 시간 시작 전 6 개로 재설정하는 예약된 작업을 만듭니다. C. 업무 시간 시작 및 종료 전후 일정이 있는 두 개의 Amazon CloudWatch Events 규칙을 생성합니다. 인스턴스 수에 대한 파라미터를 사용하여 EC2 Auto Scaling 그룹을 생성하는 AWS CloudFormation 스택을 생성합니다. 각 규칙에서 스택을 호출하여 아침에 3 개, 저녁에 6 개의 매개 변수 값을 전달합니다. D. 목표가 75 % 인 Auto Scaling 그룹의 CPU 사용률 평균을 기반으로 한 조정 작업으로 AMI 이미지를 사용하여 EC2 Auto Scaling 그룹을 생성합니다. 업무 종료 후 매일 저녁 9 개의 인스턴스를 종료하는 예약된 작업을 만듭니다.

한 회사가 AWS에서 개인 식별 정보 (PII)가 포함된 파일을 저장하기위한 솔루션을 구축하고 있습니다. 요구 사항 상태 : ▶ 모든 데이터는 저장 및 전송 시 암호화되어야 합니다. ▶ 모든 데이터는 최소 500 마일 떨어진 최소 두 위치에서 복제되어야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? A. 최소 500 마일 떨어진 두 개의 별도 가용 영역에 기본 및 보조 Amazon S3 버킷을 생성합니다. 버킷 정책을 사용하여 HTTPS를 통해서만 버킷에 대한 액세스를 적용합니다. 버킷 정책을 사용하여 버킷에 업로드 된 모든 객체에 Amazon S3 SSE-C를 적용합니다. 두 버킷간에 교차 리전 복제를 구성합니다. B. 최소 500 마일 떨어진 두 개의 별도 AWS 리전에 기본 및 보조 Amazon S3 버킷을 생성합니다. 버킷 정책을 사용하여 HTTPS를 통해서만 버킷에 대한 액세스를 적용합니다. 버킷 정책을 사용하여 버킷에 업로드 된 모든 객체에 S3 관리 형 키 (SSE-S3)를 적용합니다. 두 버킷간에 교차 리전 복제를 구성합니다. C. 최소 500 마일 떨어진 두 개의 별도 AWS 리전에 기본 및 보조 Amazon S3 버킷을 생성합니다. IAM 역할을 사용하여 HTTPS를 통해서만 버킷에 대한 액세스를 적용합니다. 버킷 정책을 사용하여 버킷에 업로드 된 모든 객체에 Amazon S3 관리 형 키 (SSE-S3)를 적용합니다. 두 버킷간에 교차 리전 복제를 구성합니다. D. 최소 500 마일 떨어진 두 개의 별도 가용 영역에 기본 및 보조 Amazon S3 버킷을 생성합니다. 버킷 정책을 사용하여 HTTPS를 통해서만 버킷에 대한 액세스를 적용합니다. 버킷 정책을 사용하여 버킷에 업로드 된 모든 객체에 AWS KMS 암호화를 적용합니다. 두 버킷간에 교차 리전 복제를 구성합니다. 객체 암호화를 위해 기본 지역에 KMS 고객 마스터 키 (CMK)를 생성합니다.

See all study sets

Related study sets

Chapter 13 Fin 3060

BUSA 4900 - Exam II

English 10B Unit 3: Lessons 11-15

HSDF 183: Quiz 2.2: Income, Saving, and Expenses (Cash Flow Management)

exam 3

Chapter 9 - Medical Laboratory Technology, Turgeon - Laboratory Testing - Point of Care to Total Automation

Midterm 3

Training and Development Ch. 2 Cragun

Chemistry Stoichiometry

CTC CH.6 Learning

Data Structure Quiz 2

Sem 3 - Unit 4: Perfusion (HF, MI, Cardiac Dysrh, Fetal Monitoring) TB

Risk Management

Chapter 51: Assessment and Management of Patients With Diabetes

TEST 1

SALT Final, R1 M3, Chapter 1, Chapter 23: State and local taxes, ACCT 4400 - SALT #2 Apportionment, Multijurisdictional Tax Issues, Uses of Local/State Taxes, ACCT 570 - Ch 12: State & Local Taxes, 4400, Multi-Jurisdictional Tax, State and Local Taxa...