DevOps 엔지니어는 비디오 제작 회사의 비디오 파일을 관리하는 애플리케이션을 관리합니다.애플리케이션은 ELB Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행됩니다.인스턴스는 여러 가용 영역의 Auto Scaling 그룹에서 실행됩니다.데이터는 Amazon RDS PostgreSQL 다중 AZ DB 인스턴스에 저장되고 비디오 파일은 Amazon S3 버킷에 저장됩니다.일반적인 날에는 50GB의 새 비디오가 S3 버킷에 추가됩니다.엔지니어는 데이터 손실이 최소화되고 복구 시간이 가장 짧은 다중 지역 재해 복구 계획을 구현해야 합니다.현재 애플리케이션 인프라는 이미 AWS CloudFormation을 사용하여 설명되어 있습니다.
엔지니어는 시스템의 가동 시간 및 복구 목표를 충족하기 위해 어떤 배치 옵션을 선택해야 합니까?
Auto Scaling 그룹의 용량을 1로 설정하는 두 번째 리전의 CloudFormation 템플릿에서 애플리케이션을 시작합니다. 두 번째 리전에서 Amazon RDS 읽기 전용 복제본을 생성합니다.두 번째 리전에서 원래 S3 버킷과 새 S3 버킷 간의 교차 리전 복제를 활성화합니다.장애 조치하려면 읽기 전용 복제본을 마스터로 승격합니다.CloudFormation 스택을 업데이트하고 Auto Scaling 그룹의 용량을 늘립니다.
Auto Scaling 그룹의 용량을 1로 설정하는 두 번째 리전의 CloudFormation 템플릿에서 애플리케이션을 시작합니다. 매일 Amazon RDS 교차 리전 스냅샷을 두 번째 리전으로 가져오는 예약 작업을 생성합니다.두 번째 리전에서 원본 S3 버킷과 Amazon Glacier 간의 교차 리전 복제를 활성화합니다.재해 발생 시 두 번째 리전에서 새 애플리케이션 스택을 시작하고 가장 최근 스냅샷에서 데이터베이스를 복원합니다.
Auto Scaling 그룹의 용량을 1로 설정하는 두 번째 리전의 CloudFormation 템플릿에서 애플리케이션을 시작합니다. Amazon CloudWatch Events를 사용하여 야간 작업을 예약하여 데이터베이스의 스냅샷을 만들고 스냅샷을 두 번째 리전에 복사합니다. 스냅샷에서 두 번째 리전의 DB 인스턴스를 교체합니다.두 번째 리전에서 원래 S3 버킷과 새 S3 버킷 간의 교차 리전 복제를 활성화합니다.장애 조치하려면 Auto Scaling 그룹의 용량을 늘리십시오.
Amazon CloudWatch Events를 사용하여 야간 작업을 예약하여 데이터베이스의 스냅샷을 만들고 스냅샷을 두 번째 리전에 복사합니다.S3 이벤트 알림에 대한 응답으로 두 번째 리전의 새 S3 버킷에 각 객체를 복사하는 AWS Lambda 함수를 생성합니다.두 번째 지역에서는 CloudFormation 템플릿에서 애플리케이션을 시작하고 가장 최근 스냅샷에서 데이터베이스를 복원합니다.
소셜 네트워킹 서비스는 파트너가 공개 게시물을 검색할 수 있도록 하는 웹 API를 실행합니다.게시물 데이터는 Amazon DynamoDB에 저장되고 AWS Lambda 함수로 인덱싱되며, Amazon ES 도메인은 인덱스를 저장하고 애플리케이션에 검색 기능을 제공합니다.
서비스는 배포 중에 전체 용량을 유지하고 실패한 배포로 인해 다운타임이나 용량 감소가 발생하거나 후속 배포를 방해하지 않도록 해야 합니다.
이러한 요구 사항을 어떻게 충족할 수 있습니까?(두 가지를 선택하세요.)
All at Once로 설정된 배포 정책을 사용하여 AWS Elastic Beanstalk에서 웹 애플리케이션을 실행합니다.AWS CloudFormation 템플릿을 사용하여 Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다.
AWS CloudFormation 템플릿에 웹 애플리케이션, Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다.AWS CodeDeploy 인플레이스 배포로 변경 사항을 배포합니다.
변경 불가능으로 설정된 배포 정책을 사용하여 AWS Elastic Beanstalk에서 웹 애플리케이션을 실행합니다.AWS CloudFormation 템플릿을 사용하여 Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다.
AWS CloudFormation 템플릿에 웹 애플리케이션, Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다.AWS CodeDeploy 블루/그린 배포로 변경 사항을 배포합니다.
롤링으로 설정된 배포 정책을 사용하여 AWS Elastic Beanstalk에서 웹 애플리케이션을 실행합니다.AWS CloudFormation 템플릿을 사용하여 Lambda 함수, DynamoDB 테이블 및 Amazon ES 도메인을 배포합니다.
미디어 고객은 AWS 계정에 수천 개의 Amazon EC2 인스턴스를 가지고 있습니다.고객은 팀 커뮤니케이션 및 중요한 업데이트를 위해 Slack 채널을 사용하고 있습니다.DevOps 엔지니어는 AWS에서 예약한 모든 EC2 유지 관리 알림을 회사 Slack 채널로 보내라는 지시를 받았습니다.
엔지니어는 이 프로세스를 최소한의 단계로 구현하기 위해 어떤 방법을 사용해야 합니까?
AWS Trusted Advisor를 AWS Config와 통합합니다.생성된 AWS Config 규칙에 따라 AWS Config 이벤트는 AWS Lambda 함수를 호출하여 Slack 채널에 알림을 보낼 수 있습니다.
AWS Personal Health Dashboard를 Amazon CloudWatch Events와 통합합니다.생성된 CloudWatch 이벤트에 따라 이벤트는 AWS Lambda 함수를 호출하여 Slack 채널에 알림을 보낼 수 있습니다.
EC2 이벤트를 Amazon CloudWatch 모니터링과 통합합니다.생성된 CloudWatch 경보에 따라 경보는 AWS Lambda 함수를 호출하여 EC2 유지 관리 알림을 Slack 채널로 보낼 수 있습니다.
AWS Support를 AWS CloudTrail과 통합합니다.생성된 CloudTrail 조회 이벤트를 기반으로 이벤트는 AWS Lambda 함수를 호출하여 EC2 유지 관리 알림을 Slack 채널에 전달할 수 있습니다.
재해 복구 연습을 수행한 후 Enterprise Architect는 데이터베이스 및 스토리지 관리자로 구성된 대규모 팀이 다른 AWS 리전에서 플래그십 애플리케이션의 데이터베이스를 작동시키는 데 7시간 이상의 수동 작업이 필요함을 발견했습니다.또한 Architect는 복구된 데이터베이스에서 최대 2시간의 데이터 트랜잭션이 누락되는 경우가 많다는 사실을 발견했습니다.
지역 간 장애 조치 시나리오에서 향상된 RTO 및 RPO를 제공하는 솔루션은 무엇입니까?
다중 지역 Amazon EFS에서 지원하는 Amazon RDS 다중 AZ 인스턴스를 배포합니다.지역 간 복구 및 지속적인 데이터 복제의 기본 자동화를 위해 다중 지역 가용성을 활성화하도록 RDS 옵션 그룹을 구성합니다.RDS 영향을 받는 이벤트를 구독하는 Amazon SNS 주제를 생성하여 단일 가용 영역에서 상당한 쿼리 지연 시간이 감지되면 데이터베이스 관리 팀에 이메일을 보냅니다.
Amazon SNS 주제를 사용하여 Amazon RDS 가용성 및 백업 이벤트에서 게시된 메시지를 수신합니다.Amazon RDS를 호출하여 데이터베이스 인스턴스를 스냅샷하고, 지역 간 스냅샷 사본을 생성하고, 스냅샷에서 인스턴스를 복원하는 세 가지 개별 기능에 AWS Lambda를 사용하십시오.RPO와 일치하는 빈도로 예약된 Amazon CloudWatch Events 규칙을 사용하여 Lambda 함수를 트리거하여 데이터베이스 인스턴스를 스냅샷합니다.백업 이벤트에 대한 SNS 주제가 새 메시지를 수신하면 교차 리전 스냅샷 복사본을 생성하도록 Lambda 함수를 트리거합니다.가용성 SNS 주제에 게시된 새 메시지 전송을 트리거하기 위해 스냅샷에서 인스턴스를 복원하도록 Lambda 함수를 구성합니다.
예약된 Amazon CloudWatch Events 규칙을 생성하여 Amazon RDS를 호출하여 데이터베이스 인스턴스에서 스냅샷을 생성하고 RPO와 일치하는 빈도를 지정합니다.AWS Step Functions 작업을 생성하여 Amazon RDS를 호출하여 교차 지역 스냅샷 복사를 장애 조치 지역으로 수행하고 RDS 스냅샷 생성 상태가 완료되면 작업을 실행하도록 상태 시스템을 구성합니다.RDS 가용성 이벤트를 구독하는 SNS 주제를 생성하고 이러한 메시지를 장애 조치 지역에 있는 Amazon SQS 대기열로 푸시합니다.Auto Scaling 작업자 노드 그룹을 구성하여 새 메시지에 대한 대기열을 폴링하고 지역 간 복사된 스냅샷의 체크섬이 유효하게 반환된 후 스냅샷에서 데이터베이스를 복원하도록 Amazon RDS를 호출합니다.
Amazon RDS 예약된 인스턴스 수명 주기 이벤트를 사용하여 스냅샷을 생성하고 RPO와 일치하는 빈도를 지정합니다.Amazon RDS 예약된 인스턴스 수명 주기 이벤트 구성을 사용하여 Snapshot Create Complete 이벤트 시 장애 조치 지역으로 교차 지역 스냅샷 복사를 수행합니다.데이터베이스 인스턴스에 대한 CloudWatch RDS 네임스페이스 CPUUtilization 지표가 0%로 떨어지면 경고하고 Amazon RDS를 호출하여 장애 조치 지역에서 데이터베이스 스냅샷을 복원하도록 Amazon CloudWatch를 구성합니다.
한 회사가 여러 응용 프로그램을 전 세계에 배포했습니다.최근 Security Auditors는 Amazon EBS 디스크 암호화 없이 시작된 Amazon EC2 인스턴스가 거의 없음을 발견했습니다.감사관은 여러 AWS 계정 및 지역에서 암호화되지 않은 모든 EBS 볼륨을 자세히 설명하는 보고서를 요청했습니다.또한 향후 이러한 일이 발생할 때마다 알림을 받기를 원합니다.
최소한의 운영 오버헤드로 어떻게 자동화할 수 있습니까?
모든 대상 계정에서 AWS Config 규칙을 설정하는 AWS Lambda 함수를 생성합니다. AWS Config 집계자를 사용하여 여러 계정 및 리전에서 데이터를 수집합니다. 집계된 보고서를 Amazon S3 버킷으로 내보내고 Amazon SNS를 사용하여 알림을 전달합니다.
모든 이벤트를 중앙 집중식 계정의 Amazon S3 버킷으로 전달하도록 AWS CloudTrail을 설정합니다.S3 이벤트 알림 기능을 사용하여 로그가 S3 버킷으로 전달될 때마다 AWS CloudTrail 로그를 구문 분석하는 AWS Lambda 함수를 호출합니다.동일한 Lambda 함수를 사용하여 출력을 Amazon SNS 주제에 게시합니다.
EBS 암호화를 위한 AWS Config 관리형 규칙을 추가하는 AWS CloudFormation 템플릿을 생성합니다. CloudFormation 스택 세트를 사용하여 모든 계정 및 지역에 템플릿을 배포합니다. 구성 규칙의 통합 평가 결과를 Amazon S3에 저장합니다. 규정을 준수하지 않는 리소스가 감지되면 Amazon SNS를 사용하여 알림을 보냅니다.
AWS CLI를 사용하여 JMESPATH 쿼리 필터로 aws ec2 describe-volumes 쿼리를 호출하는 스크립트를 주기적으로 실행합니다.그런 다음 출력을 Amazon S3 버킷에 씁니다.새 데이터가 S3 버킷에 기록될 때 Amazon SNS를 사용하여 이벤트를 보내도록 S3 이벤트 알림을 설정합니다.
DevOps 엔지니어에게는 배송 주문을 받고 재고를 추적하는 단일 Amazon DynamoDB 테이블이 있습니다.엔지니어에게는 해당 테이블의 DymamoDB 스트림에서 읽는 세 가지 AWS Lambda 함수가 있습니다.Lambda 함수는 항목 개수 수행, Amazon Kinesis Data Firehose로 항목 이동, 재고 수준 모니터링, 부품 부족 시 공급업체 주문 생성과 같은 다양한 기능을 수행합니다. 엔지니어는 로그를 검토하는 동안 부하가 증가하면 Lambda 함수가 가끔 실패하여 스트림 조절 오류가 발생한다는 사실을 알게 됩니다.
최소한의 운영 관리가 필요한 가장 비용 효율적인 솔루션은 무엇입니까?
AWS Glue 통합을 사용하여 DynamoDB 스트림을 수집한 다음 Lambda 코드를 AWS Fargate 작업으로 마이그레이션합니다.
DynamoDB 스트림 대신 Amazon Kinesis 스트림을 사용한 다음 Kinesis 분석을 사용하여 Lambda 함수를 트리거합니다.
네 번째 Lambda 함수를 생성하고 스트림에서 읽는 유일한 Lambda 함수가 되도록 구성합니다.그런 다음 이 Lambda 함수를 사용하여 다른 세 개의 Lambda 함수에 페이로드를 전달합니다.
Lambda 함수가 테이블을 직접 쿼리하고 DynamoDB 스트림을 비활성화하도록 합니다.그런 다음 Lambda 함수가 글로벌 보조 인덱스에서 쿼리하도록 합니다.
정부 기관은 암호화된 Amazon S3 버킷에 극비 파일을 저장하고 있습니다.에이전시는 페더레이션 액세스를 구성했으며 특정 온프레미스 Active Directory 사용자 그룹만 이 버킷에 액세스하도록 허용했습니다.
기관은 감사 기록을 유지하고 관리자가 이 제한된 페더레이션 액세스를 제공하는 데 사용되는 IAM 정책에 대한 우발적인 변경을 자동으로 감지하고 되돌리기를 원합니다.
다음 중 이러한 요구 사항을 충족하는 가장 빠른 방법을 제공하는 옵션은 무엇입니까?
변경 사항을 감지하고 되돌리는 AWS Lambda 함수를 트리거하기 위해 AWS CloudTrail API에서 Amazon CloudWatch Events 이벤트 버스를 구성합니다.
구성 변경을 감지하도록 AWS Config 규칙을 구성하고 AWS Lambda 함수를 실행하여 변경 사항을 되돌리십시오.
변경 사항을 감지하고 되돌리기 위해 연동 액세스 역할에 연결된 IAM 정책을 스캔하는 AWS Lambda 함수를 예약합니다.
온프레미스 Active Directory의 관리자가 IAM 정책을 변경하지 못하도록 제한합니다.
의료 제공자는 RedHat을 실행하는 120개의 온프레미스 VMware 서버와 Amazon Linux를 실행하는 50개의 Amazon EC2 인스턴스를 포함하는 하이브리드 아키텍처를 보유하고 있습니다.이 회사는 AWS로 전면 마이그레이션하는 중이며 데이터 분석을 위해 온프레미스 가상 머신 및 EC2 인스턴스에서 정보를 수집하는 솔루션을 구현하려고 합니다.정보에는 다음이 포함됩니다.
– 운영 체제 유형 및 버전 – 설치된 애플리케이션의 데이터 – MAC 및 IP 주소와 같은 네트워크 구성 정보 – Amazon EC2 인스턴스 AMI ID 및 IAM 프로필
최소한의 관리로 이러한 요구 사항을 어떻게 충족할 수 있습니까?
EC2 인스턴스에서 cron 작업으로 실행되는 셸 스크립트를 작성하여 데이터를 수집하고 Amazon S3에 푸시합니다.온프레미스 리소스의 경우 VMware vSphere를 사용하여 데이터를 수집하고 파일 게이트웨이에 기록하여 S3에 데이터를 저장합니다.마지막으로 분석을 위해 S3 버킷에서 Amazon Athena를 사용합니다.
온프레미스 가상 머신과 EC2 인스턴스에서 스크립트를 사용하여 데이터를 수집하고 Amazon S3로 푸시한 다음 Amazon Athena를 사용하여 분석합니다.
온프레미스 가상 머신과 EC2 인스턴스 모두에 AWS Systems Manager 에이전트를 설치합니다.인벤토리 수집을 활성화하고 Amazon S3 버킷에 대한 리소스 데이터 동기화를 구성하여 Amazon Athena로 데이터를 분석합니다.
VMware 환경에 Agentless Discovery Connector를 배포하려면 AWS Application Discovery Service를 사용하고 EC2 인스턴스에는 Discovery Agent를 배포하여 데이터를 수집하십시오.그런 다음 분석을 위해 AWS Migration Hub 대시보드를 사용하십시오.
회사는 AWS로 이동하기 전에 회사 에코시스템에서 Amazon Linux에서 실행되는 애플리케이션의 일관된 동작을 보장해야 합니다.이 회사는 VMware를 사용하는 기존 자동화 서버 구축 시스템을 보유하고 있습니다.목표는 새로운 대상 운영 체제에서 응용 프로그램의 기능과 전제 조건을 시연하는 것입니다.
DevOps 엔지니어는 기존 회사 서버 파이프라인 및 가상화 소프트웨어를 사용하여 서버 이미지를 생성해야 합니다. 서버 이미지는 Amazon EC2의 빌드와 최대한 유사하도록 온프레미스에서 테스트됩니다.
이것이 어떻게 이루어질 수 있습니까?
CentOS 7의 최신 ISO를 다운로드 및 통합하고 결과 서버에서 애플리케이션 배포를 실행합니다.
온프레미스 인프라에서 AWS OpsWorks 배포 에이전트를 사용하여 Amazon Linux AMI를 시작한 다음 애플리케이션 배포를 실행합니다.
최신 Amazon Linux 운영 체제로 EC2 인스턴스를 구축하고 AWS Import/Export 서비스를 사용하여 EC2 이미지를 Amazon S3의 VMware ISO로 내보냅니다.그런 다음 결과 ISO를 온프레미스 시스템으로 가져옵니다.
Amazon Linux 2의 최신 ISO를 다운로드 및 통합하고 결과 서버에서 애플리케이션 배포를 실행합니다.운영 체제 테스트 결과가 EC2 운영 체제 동작과 일치하는지 확인합니다.
개발 팀이 전자 상거래 애플리케이션에 새 국가를 추가하고 있습니다.이 추가 기능을 사용하려면 애플리케이션의 배송 구성 요소에 새 애플리케이션 기능을 추가해야 합니다.일부는 빌드하는 데 약 6주가 걸리므로 팀은 모든 새 기능을 추가해야 하는지 여부를 결정하지 않았습니다.배송 구성 요소 기능에 대한 최종 결정이 내려지는 동안 다른 팀 구성원은 애플리케이션의 다른 기능에 대해 계속 작업하고 있습니다.
이러한 상황에서 응용 프로그램 기능 배포를 어떻게 관리해야 합니까?
릴리스 분기에 대한 커밋으로 코드 업데이트를 추가합니다.팀은 모든 기능이 준비될 때까지 배포를 연기할 수 있습니다.
코드 업데이트를 기능 분기에 대한 커밋으로 추가합니다.기능이 준비되면 커밋을 릴리스 브랜치에 병합합니다.
기능이 준비되면 코드 업데이트를 단일 커밋으로 추가합니다.이 커밋에 "new-country" 태그를 지정합니다.
"new-country"라는 새 리포지토리를 만듭니다.모든 코드 변경 사항을 새 리포지토리에 커밋합니다.
DevOps 엔지니어는 다운타임 없이 웹 애플리케이션에 업데이트를 배포하기 위한 전략을 구현하라는 요청을 받습니다.애플리케이션 인프라는 AWS CloudFormation에서 정의되며 Amazon Route 53 레코드, Application Load Balancer, EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스 및 Amazon DynamoDB 테이블로 구성됩니다.가동 중지 시간을 방지하려면 항상 애플리케이션을 제공하는 활성 인스턴스가 있어야 합니다.
이를 수행하는 가장 비용 효율적인 방법은 무엇입니까?
CloudFormation 템플릿에서 AWS::AutoScaling::AutoscalingGroup 리소스를 수정하고 UpdatePolicy 속성을 추가하여 다운타임 없이 배포에 필요한 요소를 정의합니다.
CloudFormation 템플릿에서 AWS:: AutoScaling::DeploymentUpdates 리소스를 수정하고 UpdatePolicy 속성을 추가하여 다운타임 없이 배포에 필요한 요소를 정의합니다.
CloudFormation 템플릿에 새 Application Load Balancer 및 Auto Scaling 그룹을 추가합니다.비활성 Auto Scaling 그룹에 새로운 변경 사항을 배포합니다.활성 Application Load Balancer를 변경하려면 Route 53을 사용하십시오.
CloudFormation 템플릿에 새 Application Load Balancer 및 Auto Scaling 그룹을 추가합니다.AWS::AutoScaling::AutoScalingGroup 리소스를 수정하고 UpdatePolicy 속성을 추가하여 롤링 업데이트를 수행합니다.
CloudFormation 템플릿에서 CloudFormation 스택의 UpdatePolicy 속성을 수정하고 업데이트할 Auto Scaling 그룹을 지정합니다.다운타임 없이 배포가 이루어지도록 MinSuccessfulInstancesPercent 및 PauseTime을 구성합니다.
DevOps 엔지니어는 자동화된 방식으로 Linux AMI를 생성해야 합니다.새로 생성된 AMI ID는 다른 빌드 파이프라인이 프로그래밍 방식으로 새 ID에 액세스할 수 있는 위치에 저장해야 합니다.
이를 수행하는 가장 비용 효율적인 방법은 무엇입니까?
AWS CodePipeline에서 파이프라인을 구축하여 최신 운영 체제 OVF(Open Virtualization Format) 이미지를 다운로드하고 Amazon S3 버킷에 저장한 다음 guestfish 유틸리티를 사용하여 이미지를 사용자 지정합니다.가상 머신(VM) 가져오기 명령을 사용하여 OVF를 AMI로 변환하고 AMI 식별 출력을 AWS Systems Manager 파라미터로 저장합니다.
이미지 생성 방법을 지시하는 값을 사용하여 AWS Systems Manager 자동화 문서를 생성합니다. 그런 다음 AWS CodePipeline에서 파이프라인을 구축하여 자동화 문서를 실행하여 트리거 시 AMI를 구축합니다. AMI 식별 출력을 Systems Manager 매개변수로 저장합니다.
AWS CodePipeline에서 파이프라인을 구축하여 최신 버전의 애플리케이션을 실행하는 Amazon EC2 인스턴스의 스냅샷을 생성합니다.그런 다음 스냅샷에서 새 EC2 인스턴스를 시작하고 AWS Lambda 함수를 사용하여 실행 중인 인스턴스를 업데이트합니다.업데이트된 인스턴스의 스냅샷을 만든 다음 AMI로 변환합니다. Amazon DynamoDB 테이블에 AMI 식별 출력을 저장합니다.
Amazon EC2 인스턴스를 시작하고 Packer를 설치합니다. 그런 다음 이미지 생성 방법을 정의하는 값으로 Packer 빌드를 구성합니다. AMI를 빌드하도록 트리거될 때 Packer 빌드를 호출하는 Jenkins 파이프라인을 빌드합니다. Amazon DynamoDB 테이블에 AMI 식별 출력을 저장합니다.
애플리케이션은 각각 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 엔지니어는 최소한의 추가 리소스를 생성하면서 이전 스택에 들어오는 요청 문제를 해결하기 위해 어떤 단계를 수행해야 합니까?
Application Load Balancer 뒤에서 HAProxy를 실행하는 Amazon EC2 인스턴스 플릿을 생성합니다.HAProxy 인스턴스는 요청을 기존 Auto Scaling 그룹 중 하나로 프록시합니다.배포 후 HAProxy 인스턴스는 새로 배포된 Auto Scaling 그룹에 요청을 보내도록 업데이트됩니다.
애플리케이션을 하나의 Application Load Balancer로 줄입니다.Blue 및 Green이라는 두 개의 대상 그룹을 만듭니다.단일 대상 그룹을 가리키는 Application Load Balancer에서 규칙을 생성합니다.Application Load Balancer 규칙을 새로 배포된 Auto Scaling 그룹의 대상 그룹으로 업데이트하는 배포에 논리를 추가합니다.
애플리케이션을 두 가지 환경이 있는 AWS Elastic Beanstalk 애플리케이션으로 이동합니다.라이브가 아닌 환경에서 새 배포를 수행합니다.배포 후 Elastic Beanstalk CNAME 스왑을 수행하여 새로 배포된 환경을 라이브 환경으로 만듭니다.
Amazon CloudFront 배포를 생성합니다.두 개의 기존 Application Load Balancer를 배포의 원본으로 설정합니다.배포 후 CloudFront 배포 동작을 업데이트하여 새로 배포된 Auto Scaling 그룹에 요청을 보냅니다.
회사에는 Amazon DynamoDB에서 데이터를 읽는 AWS Lambda에서 실행되는 마이크로 서비스가 있습니다.Lambda 코드는 성공적인 테스트 후 개발자가 수동으로 배포합니다.이제 회사는 테스트 및 배포를 자동화하고 클라우드에서 실행해야 합니다.또한 각 마이크로 서비스의 새 버전에 대한 트래픽은 배포 후 시간이 지남에 따라 점진적으로 이동해야 합니다.
MOST 개발자 속도를 보장하는 모든 요구 사항을 충족하는 솔루션은 무엇입니까?
AWS CodePipeline 구성을 생성하고 커밋 후 후크를 설정하여 테스트 통과 후 파이프라인을 트리거합니다.AWS CodeDeploy를 사용하고 트래픽 비율과 간격을 지정하는 Canary 배포 구성을 생성합니다.
테스트 코드가 푸시될 때 트리거되는 AWS CodeBuild 구성을 생성합니다.AWS CloudFormation을 사용하여 새 Lambda 버전을 배포하고 트래픽 이동 비율 및 간격을 지정하는 AWS CodePipeline 구성을 트리거합니다.
AWS CodePipeline 구성을 생성하고 코드가 푸시될 때 트리거할 소스 코드 단계를 설정합니다.AWS CodeBuild를 사용하여 테스트를 실행하도록 빌드 단계를 설정합니다.배포할 AWS CodeDeploy 구성을 설정한 다음 CodeDeployDefault.LambdaLinear10PercentEvery3Minutes 옵션을 선택합니다.
AWS CLI를 사용하여 테스트를 통과한 후 Amazon S3 버킷에 코드를 업로드하는 커밋 후 후크를 설정합니다.새 버전을 배포하는 Lambda 함수를 실행하는 S3 이벤트 트리거를 설정합니다.Lambda 함수에서 간격을 사용하여 시간 경과에 따라 필요한 비율로 코드를 배포합니다.
회사에서 AWS CloudFormation 템플릿을 사용하여 웹 애플리케이션을 배포하고 있습니다.템플릿을 사용하려면 프로덕션, 스테이징 및 개발의 세 가지 주요 환경 각각에 대해 수동으로 변경해야 합니다.현재 스프린트에는 자동 배포를 위한 AWS CodePipeline의 새로운 구현 및 구성이 포함됩니다.
CloudFormation 템플릿을 여러 파이프라인에서 재사용할 수 있도록 DevOps 엔지니어는 어떤 변경을 수행해야 합니까?
CloudFormation 사용자 지정 리소스를 사용하여 CodePipeline의 상태를 쿼리하여 어떤 환경이 시작되는지 확인합니다.Amazon EC2 인스턴스의 시작 구성을 동적으로 변경합니다.
입력 매개변수를 사용하려면 각 환경에 대한 CodePipeline 파이프라인을 설정하십시오. CloudFormation 매핑을 사용하여 시작되는 환경과 일치하도록 Amazon EC2 인스턴스에 대한 연결된 UserData를 전환합니다.
각 개발 환경에 하나씩 여러 단계가 있는 CodePipeline 파이프라인을 설정합니다. AWS Lambda 함수를 사용하여 CloudFormation 배포를 트리거하여 각 환경에서 시작된 Amazon EC2 인스턴스의 UserData를 동적으로 변경합니다.
CloudFormation 입력 매개변수를 사용하여 CloudFormation 스택이 업데이트될 때마다 각 Amazon EC2 인스턴스의 LaunchConfiguration 및 UserData 섹션을 동적으로 변경하십시오.
애플리케이션은 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행됩니다.Amazon RDS MySQL은 백엔드에서 사용됩니다.인스턴스는 여러 가용 영역의 Auto Scaling 그룹에서 실행됩니다.Application Load Balancer 상태 확인은 웹 서버가 작동 중이고 읽기/쓰기 SQL 연결을 만들 수 있는지 확인합니다.Amazon Route 53은 Application Load Balancer를 가리키는 레코드와 함께 DNS 기능을 제공합니다.새 정책에는 RTO가 4시간이고 RPO가 15분인 지리적으로 격리된 재해 복구 사이트가 필요합니다.
애플리케이션 스택에 최소한의 변경만 필요한 재해 복구 전략은 무엇입니까?
다른 가용 영역에서 RDS를 제외한 모든 항목의 복제 스택을 시작합니다.새 가용 영역에서 RDS 읽기 전용 복제본을 생성하고 로컬 RDS 인스턴스를 가리키도록 새 스택을 구성합니다.장애 조치 라우팅 정책을 사용하여 새 스택을 Route 53 레코드 세트에 추가합니다.
다른 리전에서 RDS를 제외한 모든 항목의 복제 스택을 시작합니다.새 리전에서 RDS 읽기 전용 복제본을 생성하고 로컬 RDS 인스턴스를 가리키도록 새 스택을 구성합니다.지연 시간 라우팅 정책을 사용하여 새 스택을 Route 53 레코드 세트에 추가합니다.
다른 리전에서 RDS를 제외한 모든 항목의 복제 스택을 시작합니다.실패 시 기본 지역에서 재해 복구 지역으로 스냅샷을 복사합니다.재해 복구 지역의 Application Load Balancer를 가리키도록 Amazon Route 53 레코드 세트를 조정합니다.
다른 리전에서 RDS를 제외한 모든 항목의 복제 스택을 시작합니다.새 리전에서 RDS 읽기 전용 복제본을 생성하고 로컬 RDS 인스턴스를 가리키도록 새 스택을 구성합니다.장애 조치 라우팅 정책을 사용하여 Amazon Route 53 레코드 세트에 새 스택을 추가합니다.
회사에서 Amazon DynamoDB를 사용하여 포럼에서 메타데이터를 유지하려고 합니다.아래 이미지의 샘플 데이터 세트를 참조하십시오.DOP-C01 AWS DevOps 엔지니어 전문가 파트 02 Q17 003
DevOps 엔지니어는 파티션 키, 정렬 키, local secondary index, 예상 속성 및 인출 작업으로 테이블 스키마를 정의해야 합니다.스키마는 비용을 최소화하기 위해 최소 프로비저닝된 읽기 용량 단위를 사용하여 다음 예제 검색을 지원해야 합니다.
-제목이 'a'로 시작하는 항목에 대해 ForumName 내에서 검색합니다. -지정된 LastPostDateTime 시간 프레임 내에서 포럼을 검색합니다. - LastPostDateTime이 최근 3개월 이내인 스레드 값을 반환합니다.
어떤 스키마가 요구 사항을 충족합니까?
Subject를 기본 키로 사용하고 ForumName을 정렬 키로 사용합니다. LastPostDateTime이 있는 LSI를 정렬 키로 사용하고 스레드에 대한 가져오기 작업을 수행합니다.
ForumName을 기본 키로 사용하고 Subject를 정렬 키로 사용하십시오. LastPostDateTime을 정렬 키로 사용하는 LSI와 예상 속성 스레드를 사용합니다.
ForumName을 기본 키로 사용하고 Subject를 정렬 키로 사용하십시오.정렬 키로 Thread가 있는 LSI와 예상 속성 LastPostDateTime이 있습니다.
Subject를 기본 키로 사용하고 ForumName을 정렬 키로 사용합니다.LSI with Thread를 정렬 키로 사용하고 LastPostDateTime에 대한 가져오기 작업을 수행합니다.
한 회사에서 AWS CloudFormation을 사용하여 Amazon RDS MySQL 다중 AZ DB 인스턴스에 데이터를 저장하는 3계층 웹 애플리케이션을 배포했습니다.DevOps 엔지니어는 다운타임을 최소화하면서 RDS 인스턴스를 MySQL의 최신 메이저 버전으로 업그레이드해야 합니다.
다운타임을 최소화하면서 엔지니어는 어떻게 인스턴스를 업그레이드해야 합니까?
CloudFormation 템플릿에서 AWS::RDS::DBInstance 리소스 유형의 EngineVersion 속성을 원하는 최신 버전으로 업데이트합니다.두 번째 스택을 시작하고 새 RDS 인스턴스를 읽기 전용 복제본으로 만듭니다.
CloudFormation 템플릿에서 AWS:: RDS::DBInstance 리소스 유형의 DBEngineVersion 속성을 원하는 최신 버전으로 업데이트합니다.업데이트 스택 작업을 수행합니다.업그레이드할 인스턴스와 동일한 속성으로 새 RDS 읽기 전용 복제본 리소스를 생성합니다.두 번째 업데이트 스택 작업을 수행합니다.
CloudFormation 템플릿에서 AWS::RDS::DBInstance 리소스 유형의 DBEngineVersion 속성을 원하는 최신 버전으로 업데이트합니다.업그레이드할 인스턴스와 동일한 속성으로 새 RDS 읽기 전용 복제본 리소스를 생성합니다.업데이트 스택 작업을 수행합니다.
CloudFormation 템플릿에서 AWS::RDS::DBInstance 리소스 유형의 EngineVersion 속성을 최신 버전으로 업데이트하고 스택 업데이트 작업을 수행합니다.
소매 회사는 배포 관리를 위해 AWS OpsWorks를 채택했습니다.지난 3개월 동안 회사는 일부 프로덕션 인스턴스가 이유 없이 다시 시작되고 있음을 발견했습니다.AWS CloudTrail 로그를 검사한 DevOps 엔지니어는 해당 인스턴스가 OpsWorks에 의해 다시 시작되었음을 확인했습니다.이제 엔지니어는 인스턴스가 비정상으로 간주되거나 서비스 엔드포인트와 통신할 수 없을 때 OpsWorks가 인스턴스를 다시 시작할 때마다 자동화된 이메일 알림을 원합니다.
엔지니어는 이 요구 사항을 어떻게 충족할 수 있습니까?
OpsWorks 에이전트가 인스턴스 오류를 감지하는 경우 Amazon SES를 사용하여 팀에 이메일을 보내는 Amazon EC2 인스턴스 내에서 사용자 지정 스크립트를 실행하기 위해 cron을 배치하는 Chef 레시피를 생성합니다.
Amazon SNS 주제를 생성하고 대상 이메일 주소가 포함된 이 주제에 대한 구독을 생성합니다.Amazon CloudWatch 규칙 생성: aws.opsworks를 소스로 지정하고 started_by 세부 정보에서 자동 복구를 지정합니다.SNS 주제를 대상으로 사용합니다.
Amazon SNS 주제를 생성하고 대상 이메일 주소가 포함된 이 주제에 대한 구독을 생성합니다.Amazon CloudWatch 규칙 생성: aws.opsworks를 소스로 지정하고 started_by 세부 정보에서 instance-replacement를 지정합니다.SNS 주제를 대상으로 사용합니다.
이메일 주소가 포함된 이 주제에 대한 구독을 만듭니다.OpsWorks 계층 내에서 인스턴스 다시 시작 알림을 활성화하고 알림 대상 이메일 주소를 나타냅니다.
의료 서비스 회사는 환자 건강 모니터링을 위한 애플리케이션의 소프트웨어 라이선스 비용 증가에 대해 우려하고 있습니다.회사는 애플리케이션이 Amazon EC2 전용 호스트에서만 실행되고 있는지 확인하기 위해 감사 프로세스를 생성하려고 합니다.DevOps 엔지니어는 규정 준수를 보장하기 위해 애플리케이션을 감사하는 워크플로를 생성해야 합니다.
최소한의 관리 오버헤드로 이 요구 사항을 충족하려면 엔지니어가 어떤 조치를 취해야 합니까?
AWS Systems Manager 구성 규정 준수를 사용합니다.put-compliance-item API 작업에 대한 호출을 사용하여 호스트 배치 구성에 따라 비준수 EC2 인스턴스의 데이터베이스를 스캔하고 구축합니다.빠른 액세스를 위해 Amazon DynamoDB 테이블을 사용하여 이러한 인스턴스 ID를 저장합니다.list-compliance-summaries API 작업을 호출하여 Systems Manager를 통해 보고서를 생성합니다.
EC2 인스턴스에서 실행되는 사용자 지정 Java 코드를 사용합니다.확인할 인스턴스 수에 따라 인스턴스에 대한 EC2 Auto Scaling을 설정합니다.비준수 EC2 인스턴스 ID 목록을 Amazon SQS 대기열로 보냅니다.SQS 대기열에서 인스턴스 ID를 처리하고 Amazon DynamoDB에 쓰도록 다른 작업자 인스턴스를 설정합니다.AWS Lambda 함수를 사용하여 대기열에서 얻은 비준수 인스턴스 ID를 종료하고 배포를 위해 Amazon SNS 이메일 주제로 보냅니다.
AWS 구성을 사용합니다.리전의 모든 Amazon EC2 리소스에서 구성 기록을 활성화하여 감사할 모든 EC2 인스턴스를 식별합니다."config-rule-change-triggered" 청사진을 사용하여 AWS Lambda 함수를 트리거하는 사용자 지정 AWS Config 규칙을 생성합니다.인스턴스가 EC2 전용 호스트에서 실행되고 있지 않은 경우 NON_COMPLIANT 결과를 반환하도록 호스트 배치를 확인하도록 Lambda evaluateCompliance() 함수를 수정합니다.비준수 인스턴스를 해결하려면 AWS Config 보고서를 사용하십시오.
AWS CloudTrail을 사용합니다.EC2 RunCommand API 작업에 대한 모든 호출을 분석하여 감사할 모든 EC2 인스턴스를 식별합니다.인스턴스의 호스트 배치를 분석하는 AWS Lambda 함수를 호출합니다.비준수 리소스의 EC2 인스턴스 ID를 Amazon RDS MySQL DB 인스턴스에 저장합니다.RDS 인스턴스를 쿼리하고 쿼리 결과를 CSV 텍스트 파일로 내보내 보고서를 생성합니다.
