애플리케이션을 실행하기 위해 DevOps 엔지니어는 퍼블릭 서브넷의 퍼블릭 IP 주소로 Amazon EC2 인스턴스를 시작합니다.사용자 데이터 스크립트는 애플리케이션 아티팩트를 가져와 시작 시 인스턴스에 설치합니다.이제 애플리케이션의 보안 등급을 변경하려면 인터넷에 액세스하지 않고 인스턴스를 실행해야 합니다.인스턴스가 성공적으로 시작되고 정상으로 표시되는 동안 애플리케이션이 설치되지 않은 것 같습니다.
다음 중 새 규칙을 준수하면서 애플리케이션을 성공적으로 설치해야 하는 것은 무엇입니까?
탄력적 IP 주소가 연결된 퍼블릭 서브넷에서 인스턴스를 시작합니다.애플리케이션이 설치되고 실행되면 나중에 스크립트를 실행하여 탄력적 IP 주소 연결을 해제합니다.
애플리케이션 아티팩트를 Amazon S3 버킷에 게시하고 S3용 VPC 엔드포인트를 생성합니다.S3 버킷에서 애플리케이션 아티팩트를 읽을 수 있도록 EC2 인스턴스에 IAM 인스턴스 프로필을 할당합니다.
애플리케이션 인스턴스에 대한 보안 그룹을 생성하고 아티팩트 리포지토리에 대한 아웃바운드 트래픽만 화이트리스트에 추가합니다.설치가 완료되면 보안 그룹 규칙을 제거하십시오.
IT 부서는 온프레미스와 AWS 모두에서 Windows 및 Linux(Amazon 및 Red Hat Enterprise Linux) 서버로 포트폴리오를 관리합니다.감사 결과 OS 및 핵심 애플리케이션 패치를 업데이트하는 프로세스가 없으며 서버의 패치 수준이 일관되지 않은 것으로 나타났습니다.
다음 중 최신 OS 및 핵심 응용 프로그램 패치 수준에서 모든 서버를 업데이트하고 유지 관리하기 위한 가장 안정적이고 일관된 메커니즘을 제공하는 것은 무엇입니까?
모든 온프레미스 및 AWS 서버에 AWS Systems Manager 에이전트를 설치합니다. Systems Manager 리소스 그룹을 생성합니다. 사전 구성된 패치 기준과 함께 Systems Manager Patch Manager를 사용하여 유지 관리 기간 동안 예약된 패치 업데이트를 실행하십시오.
모든 온프레미스 및 AWS 서버에 AWS OpsWorks 에이전트를 설치합니다.각 운영 체제에 대해 별도의 레이어가 있는 OpsWorks 스택을 생성하고 Chef 슈퍼마켓에서 레시피를 가져와 유지 관리 기간 동안 각 레이어에 대한 패치 명령을 실행합니다.
셸 스크립트를 사용하여 yum을 사용하여 Linux 서버에 최신 OS 패치를 설치하고 cron을 사용하여 자동으로 실행되도록 예약합니다.Windows 업데이트를 사용하여 Windows 서버를 자동으로 패치합니다.
AWS Systems Manager Parameter Store를 사용하여 각 Linux 및 Windows 서버에 대한 자격 증명을 안전하게 저장합니다. Systems Manager 리소스 그룹을 생성합니다. Systems Manager Run Command를 사용하여 Systems Manager Parameter Store의 자격 증명을 사용하여 원격으로 패치 업데이트 배포
정리: 관리가 필요. --> AWS Systems Manager 에이전트, Systems Manager Patch Manager
한 회사가 AWS에서 중앙 집중식 로깅 솔루션을 설정하고 있으며 몇 가지 요구 사항이 있습니다.이 회사는 Amazon CloudWatch Logs 및 VPC 흐름 로그가 서로 다른 하위 계정에서 가져와 단일 감사 계정으로 전달되기를 원합니다.단, 서브 계정의 수는 계속 변경됩니다.또한 회사는 실행 가능한 통찰력을 수집하기 위해 감사 계정의 로그를 인덱싱해야 합니다.
DevOps 엔지니어는 회사의 모든 요구 사항을 충족하기 위해 솔루션을 어떻게 구현해야 합니까?
AWS Lambda를 사용하여 감사 계정의 Amazon ES에 로그를 씁니다.Amazon CloudWatch 구독 필터를 생성하고 하위 계정에서 Amazon Kinesis Data Streams를 사용하여 감사 계정에 배포된 Lambda 함수로 로그를 스트리밍합니다.
Amazon Kinesis Streams를 사용하여 감사 계정의 Amazon ES에 로그를 씁니다.CloudWatch 구독 필터를 생성하고 하위 계정의 Kinesis Data Streams를 사용하여 감사 계정의 Kinesis 스트림으로 로그를 스트리밍합니다.
Kinesis Data Streams와 함께 Amazon Kinesis Firehose를 사용하여 감사 계정의 Amazon ES에 로그를 기록합니다.CloudWatch 구독 필터를 생성하고 하위 계정에서 감사 계정의 Kinesis 스트림으로 로그를 스트리밍합니다.
AWS Lambda를 사용하여 감사 계정의 Amazon ES에 로그를 씁니다.CloudWatch 구독 필터를 생성하고 하위 계정에서 Lambda를 사용하여 감사 계정에 배포된 Lambda 함수로 로그를 스트리밍합니다.
설명: Kinesis Data Streams은 서버리스로 대량의 데이터를 스트림 처리할 수 있는 곳. Amazon Kinesis Firehose 데이터를 전달하기 전에 가공하는 곳. Kinesis Agent는 Kinesis Data Streams에 전송할 수 있는 Java 소프트웨어. CloudWatch 구독 필터를 통해 Kinesis Data Streams의 로그를 분석 그래서 관리형 스트림이라고 부름
회사에서 AWS 위에 있는 독점 엔터프라이즈 인 메모리 데이터 저장소에 그리드 시스템을 사용하려고 합니다.이 시스템은 모든 Linux 기반 배포판의 여러 서버 노드에서 실행할 수 있습니다.시스템은 노드가 추가되거나 제거될 때마다 전체 클러스터를 재구성할 수 있어야 합니다.노드를 추가하거나 제거할 때 /etc./cluster/nodes.해당 클러스터의 현재 노드 구성원의 IP 주소를 나열하는 구성 파일을 업데이트해야 합니다.
회사는 클러스터에 새 노드를 추가하는 작업을 자동화하려고 합니다.
DevOps 엔지니어는 이러한 요구 사항을 충족하기 위해 무엇을 할 수 있습니까?
AWS OpsWorks(구성 관리 서비스) Stacks를 사용하여 해당 클러스터의 서버 노드를 계층화합니다./etc/cluster/nodes의 내용을 채우는 Chef 레시피를 생성합니다.config 파일을 만들고 계층의 현재 구성원을 사용하여 서비스를 다시 시작합니다.해당 레시피를 수명 주기 구성 이벤트에 할당합니다.
파일 노드를 넣습니다.버전 관리에서 구성.클러스터 노드에 대한 Amazon EC2 태그 값을 기반으로 AWS CodeDeploy 배포 구성 및 배포 그룹을 생성합니다.클러스터에 새 노드를 추가할 때 태그가 지정된 모든 인스턴스로 파일을 업데이트하고 버전 제어에서 커밋합니다.새 파일을 배포하고 서비스를 다시 시작합니다.
Amazon S3 버킷을 생성하고 etc/cluster/nodes 버전을 업로드합니다.구성 파일.해당 S3 파일을 폴링하고 자주 다운로드하는 crontab 스크립트를 생성합니다.새 파일이 수정되었음을 감지하면 Monit 또는 systemd와 같은 프로세스 관리자를 사용하여 클러스터 서비스를 다시 시작하십시오.클러스터에 노드를 추가할 때 파일의 가장 최근 구성원을 편집하십시오.새 파일을 S3 버킷에 업로드합니다.
클러스터의 현재 보안 그룹의 모든 구성원을 나열하고 /etc/cluster/nodes를 자동으로 업데이트하는 사용자 데이터 스크립트를 생성합니다.새 인스턴스가 클러스터에 추가될 때마다 config 파일
정리: 시스템 구성 관리 -> AWS OpsWorks(구성 관리 서비스)
회사는 AWS에서 실행되는 인프라 리소스에 대한 태그 지정 및 구성 표준을 설정했습니다.DevOps 엔지니어는 위반 사항을 강조 표시하는 기능과 함께 규정 준수 상태에 대한 실시간에 가까운 대시보드를 제공할 디자인을 개발하고 있습니다.
명시된 요구 사항을 충족하는 접근 방식은 무엇입니까?
AWS Service Catalog에서 리소스 구성을 정의하고 Amazon CloudWatch에서 AWS Service Catalog 규정 준수 및 위반을 모니터링합니다.그런 다음 라이브 CloudWatch 대시보드를 설정하고 공유합니다.위반 및 수정에 대한 Amazon SNS 알림을 설정합니다.
AWS Config를 사용하여 구성 변경 사항을 기록하고 데이터를 Amazon S3 버킷으로 출력합니다.데이터 세트의 Amazon QuickSight 분석을 생성하고 대시보드 및 모바일 장치에서 정보를 사용합니다.
지정된 태그가 있는 리소스와 태그가 없는 리소스를 표시하는 리소스 그룹을 만듭니다.AWS Management 콘솔을 사용하여 준수 및 비준수 리소스를 확인하십시오.
Amazon Inspector에서 규정 준수 및 태깅 요구 사항을 정의합니다.결과를 Amazon CloudWatch Logs로 출력합니다.측정치 필터를 구축하여 관심 있는 모니터링 요소를 분리하고 CloudWatch 대시보드에 데이터를 표시합니다.
프로덕션 계정에는 수동으로 로그인한 모든 Amazon EC2 인스턴스가 24시간 이내에 종료되어야 한다는 요구 사항이 있습니다.프로덕션 계정의 모든 애플리케이션은 Amazon CloudWatch Logs 에이전트가 구성된 Auto Scaling 그룹을 사용하고 있습니다.
이 프로세스를 어떻게 자동화할 수 있습니까?
AWS Step Functions 애플리케이션에 대한 CloudWatch Logs 구독을 생성합니다.로그인 이벤트를 생성한 EC2 인스턴스에 태그를 추가하고 폐기할 인스턴스를 표시하도록 기능을 구성합니다.그런 다음 하루에 한 번 이 태그가 있는 모든 인스턴스를 종료하는 두 번째 AWS Lambda 함수를 트리거하는 CloudWatch 이벤트 규칙을 생성합니다.
로그인 이벤트에서 트리거할 CloudWatch 경보를 생성합니다.운영팀이 구독하고 있는 Amazon SNS 주제로 알림을 보내고 24시간 이내에 EC2 인스턴스를 종료하도록 합니다.
로그인 이벤트에서 트리거할 CloudWatch 경보를 생성합니다.Amazon SQS 대기열로 보내도록 경보를 구성합니다.작업자 인스턴스 그룹을 사용하여 대기열의 메시지를 처리한 다음 트리거할 Amazon CloudWatch Events 규칙을 예약합니다.
AWS Lambda 함수에서 CloudWatch Logs 구독을 생성합니다.로그인 이벤트를 생성한 EC2 인스턴스에 태그를 추가하고 폐기할 인스턴스를 표시하도록 기능을 구성합니다.이 태그가 있는 모든 인스턴스를 종료하는 일일 Lambda 함수를 트리거하는 CloudWatch 이벤트 규칙을 생성합니다.
정리: 요구사항을 어떻게 자동조정할 것인가? 실행과정 포인트 정리 CloudWatch 이벤트 규칙( Job스케쥴 생성) -> Lambda 실행 -> CloudWatch Logs 구독 -> 요구 사항 기능 구현
DevOps 엔지니어는 AWS에서 애플리케이션을 카나리아 테스트하기 위한 메커니즘을 구현하고 있습니다.응용 프로그램은 최근 수정되었으며 보안, 단위 및 기능 테스트를 거쳤습니다.애플리케이션은 AutoScaling 그룹에 배포되어야 하며 Classic Load Balancer를 사용해야 합니다.
카나리아 테스트 요구 사항을 충족하는 디자인은 무엇입니까?
블루/그린 환경을 위한 다른 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다.Amazon Route 53을 사용하고 Classic Load Balancer에서 가중 A 레코드를 생성합니다.
블루/그린 환경을 위한 단일 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다.Amazon Route 53을 사용하고 Classic Load Balancer IP에 대한 A 레코드를 생성합니다.A 레코드를 사용하여 트래픽을 조정합니다.
블루/그린 환경을 위한 단일 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다.Classic Load Balancer를 오리진으로 사용하여 Amazon CloudFront 배포를 생성합니다.CloudFront를 사용하여 트래픽을 조정합니다.
블루/그린 환경을 위한 다른 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다.Classic Load Balancer를 위한 별도의 단계로 Amazon API Gateway를 생성합니다.이 단계에 가중치를 부여하여 트래픽을 조정합니다.
미국에 기반을 둔 한 온라인 소매 회사는 향후 6개월 내에 유럽과 아시아로 사업을 확장할 계획입니다.이 제품은 현재 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행됩니다.인스턴스는 여러 가용 영역에 걸쳐 Amazon EC2 Auto Scaling 그룹에서 실행됩니다.모든 데이터는 Amazon Aurora 데이터베이스 인스턴스에 저장됩니다.
제품이 여러 지역에 배포되는 경우 회사는 모든 지역에 걸쳐 단일 제품 카탈로그를 원하지만 규정 준수를 위해 고객 정보 및 구매를 각 지역에 보관해야 합니다.
회사는 최소한의 애플리케이션 변경으로 이러한 요구 사항을 어떻게 충족해야 합니까?
제품 카탈로그에는 Amazon Redshift를 사용하고 고객 정보 및 구매에는 Amazon DynamoDB 테이블을 사용하십시오.
제품 카탈로그에는 Amazon DynamoDB 글로벌 테이블을 사용하고 고객 정보 및 구매에는 지역 테이블을 사용하십시오.
제품 카탈로그용 읽기 복제본과 함께 Aurora를 사용하고 고객 정보 및 구매를 위해 각 지역의 추가 로컬 Aurora 인스턴스를 사용하십시오.
제품 카탈로그에는 Aurora를 사용하고 고객 정보 및 구매에는 Amazon DynamoDB 글로벌 테이블을 사용하십시오.
한 회사에 여러 AWS 계정이 있습니다.계정은 주로 Amazon EC2 인스턴스에 대해 전 세계 여러 팀에서 공유 및 사용됩니다.각 EC2 인스턴스에는 정확한 비용 할당을 보장하기 위해 팀, 환경 및 비용 센터에 대한 태그가 있습니다.
DevOps 엔지니어는 팀이 비용을 감사하고 여러 공유 환경 및 계정에서 인프라 비용 최적화를 자동화하도록 어떻게 도와야 합니까?
EC2 인스턴스에서 예약된 스크립트를 설정하여 사용률을 보고하고 인스턴스를 Amazon DynamoDB 테이블에 저장합니다.활용률이 낮은 인스턴스를 찾기 위해 소스 데이터로 DynamoDB를 사용하여 Amazon QuickSight에서 대시보드를 생성합니다.활용률이 낮은 인스턴스를 줄이기 위해 AWS Lambda에서 Amazon QuickSight의 트리거를 설정합니다.
비용 센터, 환경 및 팀을 기반으로 EC2 인스턴스 태그에 대한 별도의 Amazon CloudWatch 대시보드를 생성하고 각 팀의 고유한 링크를 사용하여 인스턴스 태그를 게시합니다.각 팀에 대해 CloudWatch 대시보드를 소스로 사용하여 CloudWatch 이벤트 규칙을 설정하고 활용률이 낮은 인스턴스를 줄이기 위해 AWS Lambda 함수를 시작하는 트리거를 설정합니다.
사용률이 낮은 EC2 인스턴스의 소스로 AWS Trusted Advisor를 사용하여 Amazon CloudWatch Events 규칙을 생성합니다.각 팀, 환경 및 비용 센터에 대한 태그를 기반으로 보고된 데이터를 필터링하는 AWS Lambda 함수를 트리거하고 Amazon S3에 Lambda 함수를 저장합니다.활용률이 낮은 인스턴스를 줄이기 위해 Lambda 함수를 시작하는 두 번째 트리거를 설정합니다.
AWS Systems Manager를 사용하여 인스턴스 사용률을 추적하고 사용률이 낮은 인스턴스를 Amazon CloudWatch에 보고합니다.팀, 환경 및 비용 센터에 대한 태그를 기반으로 CloudWatch의 데이터를 필터링합니다.활용률이 낮은 인스턴스를 줄이기 위해 CloudWatch에서 AWS Lambda로 트리거 설정
회사에는 일부 레거시 시스템이 온프레미스에 남아 있고 특정 서버 클러스터가 AWS로 이동되는 하이브리드 아키텍처 솔루션이 있습니다.회사는 레거시 시스템을 재구성할 수 없으므로 클러스터 노드에는 클러스터의 일부인 각 서버에 대한 고정 호스트 이름과 로컬 IP 주소가 있어야 합니다.DevOps 엔지니어는 3개의 가용 영역(AZ)에서 고가용성으로 6노드 클러스터의 구성을 자동화하여 각 AZ의 특정 서브넷에 2개의 탄력적 네트워크 인터페이스를 배치해야 합니다.각 노드의 호스트 이름과 로컬 IP 주소는 재부팅이나 인스턴스 장애 간에 동일하게 유지되어야 합니다.
이 작업을 자동화하는 데 가장 적은 노력이 필요한 솔루션은 무엇입니까?
클러스터의 각 서버에 대한 AWS Elastic Beanstalk 애플리케이션 및 특정 환경을 생성합니다.각 환경에 대해 호스트 이름, 탄력적 네트워크 인터페이스 및 AZ를 입력 매개변수로 제공합니다.로컬 상태 에이전트를 사용하여 인스턴스 이름을 지정하고 현재 환경을 기반으로 특정 탄력적 네트워크 인터페이스를 연결합니다.
재사용 가능한 AWS CloudFormation 템플릿을 생성하여 최소 크기 1 및 최대 크기 1로 Amazon EC2 Auto Scaling 그룹을 관리합니다. 호스트 이름, 탄력적 네트워크 인터페이스 및 AZ를 스택 매개변수로 제공합니다.해당 매개변수를 사용하여 EC2 Auto Scaling 및 사용자 데이터 스크립트로 EC2 인스턴스를 설정하여 특정 탄력적 네트워크 인터페이스에 연결할 수 있습니다.CloudFormation 중첩 스택을 사용하여 클러스터에 필요한 총 6개의 노드에 대해 템플릿을 6번 중첩하고 마스터 템플릿을 사용하여 배포합니다.
사용할 호스트 이름, 서브넷 및 탄력적 네트워크 인터페이스 목록으로 Amazon DynamoDB 테이블을 생성합니다.단일 AWS CloudFormation 템플릿을 생성하여 최소 크기 6 및 최대 크기 6인 Auto Scaling 그룹을 관리합니다. 각 호스트 이름 및 로컬 IP 주소의 할당을 잠그거나 해제하는 각 인스턴스에 설치되는 프로그래밍 방식 솔루션을 생성합니다. 새 인스턴스가 시작될 서브넷에 따라 다릅니다.
재사용 가능한 AWS CLI 스크립트를 생성하여 각 인스턴스를 개별적으로 시작합니다. 그러면 인스턴스 이름이 지정되고 특정 AZ에 배치되며 특정 탄력적 네트워크 인터페이스가 연결됩니다.인스턴스를 모니터링하고 실패할 경우 스크립트를 다시 실행하여 누락된 인스턴스를 수동으로 교체합니다.
교육 회사에는 Amazon ECS 클러스터의 여러 Amazon EC2 인스턴스에서 실행되는 Docker 기반 애플리케이션이 있습니다.새 버전의 애플리케이션을 배포할 때 개발자는 새 이미지를 개인 Docker 컨테이너 레지스트리에 푸시한 다음 모든 작업을 중지하고 시작하여 모든 작업이 최신 버전의 애플리케이션을 갖도록 합니다.개발자는 가끔 새 작업이 이전 이미지로 실행되고 있음을 발견합니다.
이 문제를 어떻게 방지할 수 있습니까?
새 이미지를 푸시한 후 ECS 에이전트를 다시 시작한 다음 작업을 시작합니다.
작업 정의에서 Docker 이미지 태그에 "최신"을 사용합니다.
새 이미지를 푸시할 때 작업 정의의 다이제스트를 업데이트합니다.
Docker 컨테이너 레지스트리에 Amazon ECR을 사용합니다.
설명:
새 작업이 시작되면 Amazon ECS 컨테이너 에이전트는 컨테이너가 사용할 태그와 지정된 이미지의 최신 버전을 가져옵니다.그러나 리포지토리 이미지에 대한 후속 업데이트는 이미 전파되지 않습니다.
금융 기관은 애플리케이션 팀이 배포에 사용할 수 있도록 보안이 강화된 Red Hat Enterprise Linux 7.4 및 Windows Server 2016 AMI를 제공합니다.DevOps 엔지니어는 최신 CVE를 모니터링하기 위해 각 AMI의 자동 일일 확인을 구현해야 합니다.
엔지니어는 Amazon Inspector를 사용하여 이러한 검사를 어떻게 구현해야 합니까?
각 AMI에 Amazon Inspector 에이전트를 설치합니다.강화된 AMI에서 각 운영 체제에 대한 Amazon EC2 인스턴스를 시작하도록 AWS Step Functions를 구성하고 SecurityCheck: True로 인스턴스에 태그를 지정합니다.EC2 인스턴스가 부팅되면 Step Functions는 SecurityCheck: True 태그가 있는 모든 인스턴스에 대해 Amazon Inspector 평가를 트리거합니다.매일 한 번 Step Functions를 트리거하는 예약된 Amazon CloudWatch Events 규칙을 구현합니다.
SecurityCheck: True로 각 AMI에 태그를 지정합니다.SecurityCheck: True 태그가 있는 모든 AMI에 대해 먼저 Amazon Inspector 평가 템플릿을 구성하고 Amazon Inspector API 작업 StartAssessmentRun을 호출하도록 AWS Step Functions를 구성합니다.매일 한 번 Step Functions를 트리거하는 예약된 Amazon CloudWatch Events 규칙을 구현합니다.
SecurityCheck: True로 각 AMI에 태그를 지정합니다.SecurityCheck: True 태그가 있는 모든 AMI에 대해 매일 한 번 실행하도록 예약된 Amazon Inspector 평가를 구현합니다.Amazon Inspector는 각 AMI에 대해 Amazon EC2 인스턴스를 자동으로 시작하고 보안 평가를 수행해야 합니다.
SecurityCheck: True로 각 인스턴스에 태그를 지정합니다.SecurityCheck: True 태그가 있는 모든 인스턴스에 대해 매일 한 번 실행하도록 예약된 Amazon Inspector 평가를 구현합니다.Amazon Inspector는 각 AMI에 대해 내부 보안 평가를 자동으로 수행해야 합니다.
개발 팀은 소스 코드 제어를 위해 AWS CodeCommit을 사용합니다.개발자는 변경 사항을 다양한 기능 분기에 적용하고 풀 요청을 생성하여 프로덕션 준비가 되면 해당 변경 사항을 마스터 분기로 이동합니다.마스터 분기에 대한 직접 푸시는 허용되지 않아야 합니다.팀은 AWS 관리 정책 AWSCodeCommitPowerUser를 개발자의 IAM Rote에 적용했지만 이제 구성원은 AWS 계정의 모든 리포지토리에서 직접 마스터 브랜치에 푸시할 수 있습니다.
이를 제한하기 위해 어떤 조치를 취해야 합니까?
codecommit:GitPush 작업에 대한 거부 규칙을 포함하는 추가 정책을 생성하고 마스터 참조에 대한 조건과 함께 리소스 설명에 특정 리포지토리에 대한 제한을 포함합니다.
IAM 정책을 제거하고 AWSCodeCommitReadOnly 정책을 추가합니다.마스터 참조에 대한 조건과 함께 리소스 설명의 특정 리포지토리에 대한 codecommit:GitPush 작업에 대한 허용 규칙을 추가합니다.
IAM 정책을 수정하고 마스터 참조에 대한 조건과 함께 리소스 설명의 특정 리포지토리에 대한 codecommit:GitPush 작업에 대한 거부 규칙을 포함합니다.
codecommit:GitPush 작업에 대한 허용 규칙을 포함하고 기능 분기 참조에 대한 조건과 함께 리소스 설명에 특정 리포지토리에 대한 제한을 포함하는 추가 정책을 생성합니다.
개발자는 AWS에서 소스 코드 승격 프로세스를 용이하게 하기 위해 새로운 개발 팀을 위한 지속적인 배포 워크플로를 설계하고 있습니다.개발자는 배포가 실패할 경우 해당 배포를 롤백할 수 있는 기능을 유지하면서 개발에서 프로덕션으로 배포할 코드를 저장하고 승격하고자 합니다.
가동 중지 시간이 가장 적게 발생하는 설계는 무엇입니까?
AWS CodeCommit에서 하나의 리포지토리를 생성합니다.병합된 변경 사항을 보관할 개발 브랜치를 만듭니다.AWS CodeBuild를 사용하여 새 커밋에서 트리거된 개발 브랜치에 저장된 코드를 빌드하고 테스트합니다.블루/그린 배포를 위해 AWS CodeDeploy를 사용하여 마스터에 병합하고 프로덕션에 배포합니다.
AWS CodeCommit의 각 개발자에 대해 하나의 리포지토리와 프로덕션 코드를 보관할 또 다른 리포지토리를 생성합니다.AWS CodeBuild를 사용하여 개발 및 프로덕션 리포지토리를 병합하고 블루/그린 배포를 위해 AWS CodeDeploy를 사용하여 프로덕션에 배포합니다.
AWS CodeCommit에서 개발 코드용 리포지토리 하나와 프로덕션 코드를 보관할 또 다른 리포지토리를 생성합니다.AWS CodeBuild를 사용하여 개발 및 프로덕션 리포지토리를 병합하고 블루/그린 배포를 위해 AWS CodeDeploy를 사용하여 프로덕션에 배포합니다.
개발 팀이 코드를 저장할 공유 Amazon S3 버킷을 생성합니다.블루/그린 배포를 위해 AWS CodeDeploy를 사용하여 프로덕션에 코드를 배포하는 AWS Lambda 함수를 트리거하도록 Amazon CloudWatch Events 규칙을 설정합니다.
DevOps 엔지니어는 웹 사이트의 페이지 로드 시간이 갑자기 급증한 것을 발견하고 최근 배포가 발생했음을 발견했습니다.관련 커밋의 간단한 차이점은 외부 API 호출에 대한 URL이 변경되었고 연결 포트가 80에서 443으로 변경되었음을 보여줍니다. 외부 API는 확인되었으며 애플리케이션 외부에서 작동합니다.응용 프로그램 로그에 현재 연결 시간이 초과되어 여러 번의 재시도와 결국 통화 실패가 발생했음이 표시됩니다.
웹 Auto Scaling 그룹의 일부인 Amazon EC2 인스턴스에서 발생한 거부를 찾는 VPC 흐름 로그를 확인하십시오.VPC에 대한 수신 보안 그룹 규칙 및 라우팅 규칙을 확인하십시오.
VPC에 대한 기존 송신 보안 그룹 규칙 및 네트워크 ACL을 확인하십시오.또한 디버그 정보를 위해 Amazon CloudWatch Logs에 기록되는 애플리케이션 로그를 확인하십시오.
VPC에 대한 송신 보안 그룹 규칙 및 네트워크 ACL을 확인하십시오.또한 웹 Auto Scaling 그룹에서 시작된 수락을 찾는 VPC 흐름 로그를 확인하십시오.
디버그 정보는 Amazon CloudWatch Logs에 기록되는 애플리케이션 로그를 확인하십시오.VPC에 대한 수신 보안 그룹 규칙 및 라우팅 규칙을 확인하십시오.
엔지니어링 팀은 Node.js 전자 상거래 애플리케이션을 관리합니다.현재 환경은 다음 구성 요소로 구성됩니다. • 콘텐츠 저장을 위한 Amazon S3 버킷 • 프런트 엔드 웹 서버를 위한 Amazon EC2 • 이미지 처리 실행을 위한 AWS Lambda • 세션 관련 데이터 저장을 위한 Amazon DynamoDB
팀은 사이트 트래픽이 크게 증가할 것으로 예상합니다.애플리케이션은 중단 없이 추가 로드를 처리해야 합니다.팀은 더 큰 로드를 처리하기 위해 EC2 프런트 엔드에 새 서버를 추가하여 초기 테스트를 실행했지만 인스턴스가 완전히 구성되는 데 최대 20분이 걸렸습니다.팀은 이 구성 시간을 줄이고자 합니다. 예상되는 수요 증가를 충족하면서 가장 탄력적이고 가용성이 높은 솔루션을 만들기 위해 엔지니어링 팀이 구현해야 하는 변경 사항은 무엇입니까?
AWS OpsWorks를 사용하여 새로운 각 EC2 인스턴스가 시작될 때 자동으로 구성하십시오.여러 가용 영역에서 Application Load Balancer 뒤에 Auto Scaling 그룹을 사용하여 EC2 인스턴스를 구성합니다.Amazon DynamoDB Auto Scaling을 구현합니다.Amazon Route 53을 사용하여 애플리케이션 DNS 레코드가 Application Load Balancer를 가리키도록 합니다.
EC2 인스턴스 플릿을 배포하여 현재 용량을 두 배로 늘리고 이를 Application Load Balancer 뒤에 배치합니다.Amazon DynamoDB 읽기 및 쓰기 용량 단위를 늘립니다.애플리케이션을 가리키는 기존 Amazon Route 53 DNS 레코드에 Application Load Balancer 엔드포인트가 포함된 별칭 레코드를 추가합니다.
Amazon CloudFront를 구성하고 원본이 Amazon S3를 가리키도록 하여 웹 애플리케이션을 호스팅합니다.Amazon DynamoDB Auto Scaling을 구현합니다.Amazon Route 53을 사용하여 애플리케이션 DNS 레코드가 CloudFront DNS 이름을 가리키도록 합니다.
모든 웹 구성 요소를 포함하는 사용자 지정 AMI와 함께 AWS Elastic Beanstalk를 사용합니다.여러 가용 영역에서 Application Load Balancer 뒤에 있는 Auto Scaling 그룹을 사용하여 플랫폼을 배포합니다.Amazon DynamoDB Auto Scaling을 구현합니다.Amazon Route 53을 사용하여 애플리케이션 DNS 레코드가 Elastic Beanstalk 로드 밸런서를 가리키도록 합니다.
DevOps 엔지니어가 Amazon Linux에서 호스팅되고 보안 검토에 실패한 프로젝트에서 작업하고 있습니다.DevOps 관리자는 AWS CodeBuild 프로젝트에 대한 회사 buildspec.yaml 파일을 검토하고 권장 사항을 제공하라는 요청을 받았습니다.buildspec.yaml 파일은 다음과 같이 구성됩니다.
DOP-C01 AWS DevOps 엔지니어 전문가 파트 01 Q17 001AWS 보안 모범 사례를 준수하기 위해 어떤 변경을 권장해야 합니까?(3개를 선택하세요.)
다른 CodeBuild 사용자가 볼 수 없도록 종료 전에 컨테이너에서 임시 파일을 제거하는 빌드 후 명령을 추가합니다.
필요한 권한으로 CodeBuild 프로젝트 역할을 업데이트한 다음 환경 변수에서 AWS 자격 증명을 제거합니다.
DB_PASSWORD를 AWS Systems Manager Parameter Store에 SecureString 값으로 저장한 다음 환경 변수에서 DB_PASSWORD를 제거합니다.
환경 변수를 'db-deploy-bucket' Amazon S3 버킷으로 이동하고 다운로드할 사전 빌드 단계를 추가한 다음 변수를 내보냅니다.
AWS Systems Manager 실행 명령과 scp 및 ssh 명령을 인스턴스에 직접 사용하십시오.
XOR 다음에 Base64를 사용하여 환경 변수를 스크램블하고 설치할 섹션을 추가한 다음 빌드 단계에 XOR 및 Base64를 실행합니다.
개발 팀은 40개 이상의 애플리케이션을 구축하고 있습니다.각 앱은 ELB Application Load Balancer, Amazon EC2 및 Amazon RDS를 기반으로 하는 3계층 웹 애플리케이션입니다.애플리케이션이 내부적으로 사용되기 때문에 보안 팀은 회사 네트워크에서만 40개의 애플리케이션에 대한 액세스를 허용하고 외부 IP 주소의 액세스를 차단하려고 합니다.회사 네트워크는 프록시 서버를 통해 인터넷에 도달합니다.프록시 서버에는 한 달에 한두 번 변경되는 12개의 프록시 IP 주소가 있습니다.네트워크 인프라 팀은 프록시 서버를 관리합니다.최신 프록시 IP 주소가 포함된 파일을 Amazon S3 버킷에 업로드합니다.DevOps 엔지니어는 기업 네트워크에서 애플리케이션에 액세스할 수 있도록 솔루션을 구축해야 합니다.
어떤 솔루션이 애플리케이션 개발에 미치는 영향을 최소화하고 운영 노력을 최소화하며 인프라 비용을 가장 적게 들이면서 이러한 요구 사항을 충족합니까?
S3 객체에서 프록시 IP 주소 목록을 읽고 지정된 IP 주소에서만 HTTPS를 허용하도록 ELB 보안 그룹을 업데이트하는 AWS Lambda 함수를 구현합니다.객체가 업데이트될 때 Lambda 함수를 호출하도록 S3 버킷을 구성합니다.IP 주소 목록이 변경되면 S3 버킷에 저장합니다.
모든 애플리케이션이 동일한 Virtual Private Cloud(VPC)에서 호스팅되는지 확인합니다.그렇지 않으면 애플리케이션을 단일 VPC로 통합합니다.활성/대기 구성으로 AWS Direct Connect 연결을 설정합니다.회사 네트워크 IP 주소로부터의 인바운드 HTTPS 연결만 허용하도록 ELB 보안 그룹을 변경하십시오.
Python용 AWS SDK(Boto)를 사용하여 Python 스크립트를 구현합니다. 이 스크립트는 프록시 IP 주소가 포함된 S3 객체를 다운로드하고, ELB 보안 그룹을 스캔하고, 지정된 IP 주소에서 HTTPS 인바운드만 허용하도록 업데이트합니다.EC2 인스턴스를 시작하고 인스턴스에 스크립트를 저장합니다.cron 작업을 사용하여 스크립트를 매일 실행합니다.
인터넷에서 HTTPS 인바운드 액세스를 허용하려면 ELB 보안 그룹을 활성화하십시오.Amazon Cognito를 사용하여 회사의 Active Directory를 자격 증명 공급자로 통합합니다.회사 직원만 애플리케이션에 로그인할 수 있도록 40개의 애플리케이션을 Amazon Cognito와 통합하도록 변경합니다.사용자 액세스 활동을 기록하기 위해 사용자 액세스 로그를 Amazon CloudWatch Logs에 저장
한 회사에서 테스트 프로세스를 자동화하기 위해 AWS CodePipeline을 구현하고 있습니다.회사는 실행 상태가 실패하고 Amazon CloudWatch에서 다음 사용자 지정 이벤트 패턴을 사용할 때 알림을 받기를 원합니다.
DOP-C01 AWS DevOps 엔지니어 전문가 파트 01 Q19 002이 이벤트 패턴과 일치하는 이벤트 유형은 무엇입니까?
모든 파이프라인에서 실패한 배포 및 빌드 작업.
모든 파이프라인에서 거부되거나 실패한 모든 승인 작업.
모든 파이프라인의 모든 이벤트.
모든 파이프라인에서 승인 조치.
한 회사에서 코드형 인프라를 배포하기 위해 여러 AWS CloudFormation 템플릿을 사용하고 있습니다.대부분의 배포에서 회사는 Amazon EC2 Auto Scaling 그룹을 사용합니다.최신 AMI를 사용할 수 있는 경우 DevOps 엔지니어는 템플릿에서 Auto Scaling 그룹에 대한 AMI를 업데이트해야 합니다.
이러한 요구 사항을 어떻게 충족할 수 있습니까?
CloudFormation 템플릿에서 AMI 매핑을 관리합니다.새 AMI를 감지하고 템플릿에서 매핑을 업데이트하려면 Amazon CloudWatch Events를 사용하십시오.시작 구성 리소스 블록에서 맵을 참조하십시오.
AWS CloudFormation 템플릿의 조건을 사용하여 새 AMI를 사용할 수 있는지 확인하고 AMI ID를 반환합니다.시작 구성 리소스 블록에서 반환된 AMI ID를 참조하십시오.
템플릿에서 AWS Lambda 지원 사용자 지정 리소스를 사용하여 AMI ID를 가져옵니다. 시작 구성 리소스 블록에서 반환된 AMI ID를 참조하십시오.
Amazon EC2 m4.small 인스턴스를 시작하고 여기에서 스크립트를 실행하여 새 AMI를 확인합니다. 새 AMI를 사용할 수 있는 경우 스크립트는 시작 구성 리소스 블록을 새 AMI ID로 업데이트해야 합니다.
