[DOP-C01] AWS DevOps Engineer Professional : Part 08

 

DOP-C01 : AWS DevOps Engineer Professional : All Parts
DOP-C01 Part 01	DOP-C01 Part 08	DOP-C01 Part 15	DOP-C01 Part 22
DOP-C01 Part 02	DOP-C01 Part 09	DOP-C01 Part 16	DOP-C01 Part 23
DOP-C01 Part 03	DOP-C01 Part 10	DOP-C01 Part 17	DOP-C01 Part 24
DOP-C01 Part 04	DOP-C01 Part 11	DOP-C01 Part 18	DOP-C01 Part 25
DOP-C01 Part 05	DOP-C01 Part 12	DOP-C01 Part 19	DOP-C01 Part 26
DOP-C01 Part 06	DOP-C01 Part 13	DOP-C01 Part 20	DOP-C01 Part 27
DOP-C01 Part 07	DOP-C01 Part 14	DOP-C01 Part 21

 

1. DevOps 엔지니어가 Auto Scaling 그룹에서 Amazon EC2 인스턴스를 사용하는 시스템을 검토하고 있습니다. 이 시스템은 각 EC2 인스턴스에서 로컬로 실행되는 구성 관리 도구를 사용합니다. 애플리케이션 로드의 변동성으로 인해 새 인스턴스는 실행 상태에 들어간 후 3분 이내에 완전히 작동해야 합니다. 현재 설정 작업에는 다음이 포함됩니다.
   
   – 구성 관리 에이전트 설치 – 2분
   – 애플리케이션 프레임워크 설치 – 15분
   – Amazon S3에서 구성 데이터 복사 – 2분
   – 구성 관리 에이전트를 실행하여 인스턴스 구성 – 1분
   – Amazon S3에서 애플리케이션 코드 배포 – 2분
   
   엔지니어는 시작 시간 요구 사항을 충족하도록 시스템을 어떻게 설정해야 합니까?
   • 새 EC2 인스턴스가 시작될 때 Amazon CloudWatch Events 규칙에서 AWS Lambda 함수를 트리거합니다. 함수가 구성 관리 에이전트와 애플리케이션 프레임워크를 설치하고, Amazon S3에서 구성 데이터를 가져오고, 에이전트를 실행하여 인스턴스를 구성하고, S3에서 애플리케이션을 배포하도록 합니다.
   • 부트스트랩 스크립트를 작성하여 구성 관리 에이전트를 설치하고, 애플리케이션 프레임워크를 설치하고, Amazon S3에서 구성 데이터를 가져오고, 에이전트를 실행하여 인스턴스를 구성하고, S3에서 애플리케이션을 배포합니다.
   • 구성 관리 에이전트 및 애플리케이션 프레임워크를 포함하는 사용자 지정 AMI를 구축합니다. 부트스트랩 스크립트를 작성하여 Amazon S3에서 구성 데이터를 가져오고, 에이전트를 실행하여 인스턴스를 구성하고, S3에서 애플리케이션을 배포합니다.
   • 구성 관리 에이전트, 애플리케이션 프레임워크 및 구성 데이터를 포함하는 사용자 지정 AMI를 구축합니다. 부트스트랩 스크립트를 작성하여 에이전트를 실행하여 인스턴스를 구성하고 Amazon S3에서 애플리케이션을 배포합니다.
     
     설명: 사용자 지정 AMI(Amazon Machine Image) 사용
     사용자 지정 AMI는 표준 AMI에 포함되어 있지 않은 여러 소프트웨어를 설치해야 할 경우 환경에서 인스턴스를 시작할 때 프로비저닝 시간을 향상할 수 있습니다.
     구성 파일(.ebextensions)의 사용은 빠르고 지속적으로 환경을 구성 및 사용자 지정하는 데 유용합니다. 그러나 구성을 적용하게 되면 환경이 생성되고 업데이트되는 데 시간이 오래 걸릴 수 있습니다. 구성 파일에서 여러 서버 구성을 처리해야 하는 경우, 이미 필요한 소프트웨어와 구성이 갖춰진 사용자 지정 AMI를 만들어서 시간을 단축할 수 있습니다.
     
     사용자 지정 AMI를 통해 구성 파일에 적용하기까지 시간이 오래 걸리거나 구현하기 까다로운 하위 수준 구성 요소(예: Linux 커널)를 변경할 수 있습니다. 사용자 지정 AMI를 생성하려면 Amazon EC2에 Elastic Beanstalk 플랫폼 AMI를 시작하고 필요에 따라 소프트웨어와 구성을 사용자 지정한 후 인스턴스를 중지하고 AMI를 저장합니다.
     
     
2. 업무상 중요한 3계층 웹 애플리케이션의 리소스는 일련의 AWS CloudFormation 템플릿으로 표현됩니다. 애플리케이션은 데이터에 Amazon RDS를 사용하고 세션 상태에 Amazon ElastiCache를 사용합니다. 사용자가 애플리케이션의 성능 저하를 보고했습니다. DevOps 엔지니어는 T2 인스턴스 유형이 애플리케이션 계층에 사용되고 있고 CPU 사용량이 Amazon CloudWatch에서 100%임을 확인했습니다.
   
   엔지니어는 최종 사용자에게 최소한의 중단으로 작업을 복원하기 위해 어떤 프로세스를 따라야 합니까?
   
   • 환경에 Amazon CloudFront를 포함하도록 새 CloudFormation 템플릿을 작성하고, 스택을 시작하고, Amazon Route 53 A 레코드를 업데이트합니다.
   • M4 인스턴스 유형을 사용하여 애플리케이션 계층에 대한 새 CloudFormation 스택을 시작하고, 새 스택에 대한 승인 테스트를 실행하고, Amazon Route 53 A 레코드를 업데이트합니다.
   • T2 Unlimited 옵션을 사용하여 애플리케이션 계층에 대한 CloudFormation 스택 업데이트, 새 스택에 대한 승인 테스트 실행, Amazon Route 53 A 레코드 업데이트
   • 다른 리전에서 애플리케이션의 모든 계층에 대해 새 CloudFormation 스택을 시작하고, 새 스택에 대한 승인 테스트를 실행하고, Amazon Route 53 A 레코드를 업데이트합니다.
3. 한 회사에서 API를 통해 받은 주문을 처리하는 AWS Lambda 함수를 개발했습니다. 이 회사는 AWS CodeDeploy를 사용하여 CI/CD 파이프라인의 최종 단계로 Lambda 함수를 배포하고 있습니다.
   
   DevOps 엔지니어는 배포 후 몇 초 동안 주문 API에 간헐적인 오류가 있음을 확인했습니다. 일부 조사 후 DevOps 엔지니어는 실패가 Lambda 함수 실행이 시작되기 전에 완전히 전파되지 않은 데이터베이스 변경 사항 때문이라고 생각합니다.
   
   DevOps 엔지니어는 이를 어떻게 극복해야 합니까?
   • 트래픽이 새 버전의 Lambda 함수로 흐르기 전에 필요한 데이터베이스 변경을 테스트하고 기다리는 AppSpec 파일에 BeforeAllowTraffic 후크를 추가합니다.
   • 새 버전의 Lambda 함수가 응답하도록 허용하기 전에 트래픽이 보류 중인 데이터베이스 변경을 기다리도록 강제하는 AppSpec file에 AfterAllowTraffic 후크를 추가합니다.
   • 새 버전의 Lambda 함수를 배포하기 전에 필요한 데이터베이스 변경을 테스트하고 기다리는 AppSpec 파일에 BeforeInstall 후크를 추가합니다.
   • 들어오는 트래픽을 검사하고 데이터베이스와 같은 종속 서비스가 아직 준비되지 않은 경우 페이로드를 거부하는 ValidateService 후크를 AppSpec 파일에 추가합니다.
     
     설명: AWS Lambda 배포를 위한 수명 주기 이벤트 후크 목록
     AWS Lambda 후크는 수명 주기 이벤트의 이름 뒤에 있는 새로운 줄에서 문자열로 지정된 Lambda 함수 중 하나입니다. 각 후크는 배포별로 한 번 실행됩니다. 다음은 AppSpec 파일에서 사용할 수 있는 후크에 대한 설명입니다.
     
     • BeforeAllowTraffic – 배포된 Lambda 함수 버전으로 트래픽을 전환하기 전에 작업을 실행하려면 이 항목을 사용
     • AfterAllowTraffic – 배포된 Lambda 함수 버전으로 모든 트래픽이 전환된 후에 작업을 실행하려면 이 항목을 사용
4. 8개의 Amazon EC2 인스턴스에서 실행되는 모바일 애플리케이션은 타사 API 엔드포인트에 의존합니다. 타사 서비스는 제한된 용량으로 인해 실패율이 높으며 몇 주 안에 해결될 것으로 예상됩니다.
   
   그동안 모바일 애플리케이션 개발자는 재시도 메커니즘을 추가했으며 실패한 API 요청을 기록하고 있습니다. DevOps 엔지니어는 애플리케이션 로그 모니터링을 자동화하고 특정 오류 메시지를 계산해야 합니다. 1분 내에 오류가 10개 이상 있으면 시스템에서 경고를 발행해야 합니다.
   
   최소한의 관리 오버헤드로 요구 사항을 어떻게 충족할 수 있습니까?
   • 모든 인스턴스에 Amazon CloudWatch Logs 에이전트를 설치하여 애플리케이션 로그를 CloudWatch Logs로 푸시합니다. 지표 필터를 사용하여 매분 오류 메시지를 계산하고 오류 수가 10개를 초과하면 CloudWatch 경보를 트리거합니다.
   • 모든 인스턴스에 Amazon CloudWatch Logs 에이전트를 설치하여 CloudWatch Logs에 액세스 로그를 푸시합니다. 1분마다 오류 메시지를 계산하고 오류 수가 10개를 초과하면 CloudWatch 경보를 트리거하는 CloudWatch 이벤트 규칙을 생성합니다.
   • 모든 인스턴스에 Amazon CloudWatch Logs 에이전트를 설치하여 애플리케이션 로그를 CloudWatch Logs로 푸시합니다. 지표 필터를 사용하여 실패 횟수를 기록하고 사용자 지정 지표가 1분 동안 10개의 오류에 도달하면 CloudWatch 경보를 트리거하는 사용자 지정 CloudWatch 지표를 생성합니다.
   • cron 작업에서 정기적으로 애플리케이션 로그를 확인하려면 모든 인스턴스에 사용자 지정 스크립트를 배포합니다. 매분 오류 메시지 수를 세고 데이터 포인트를 사용자 지정 CloudWatch 지표로 푸시합니다. 사용자 지정 지표가 1분 동안 10개의 오류에 도달하면 CloudWatch 경보를 트리거합니다.
     
     설명: Amazon CloudWatch > 필터를 사용하여 로그 이벤트에서 지표 생성
     지표 필터를 한 개 이상 생성하여 CloudWatch Logs로 들어오는 로그 데이터를 검색하고 필터링할 수 있습니다. 지표 필터는 CloudWatch Logs 로그로 전송될 때 로그 데이터에서 검색할 단어와 패턴을 정의합니다. CloudWatch Logs는 이러한 지표 필터를 사용하여 로그 데이터를 그래프로 나타내거나 경보를 설정할 수 있는 숫자 CloudWatch 지표로 전환합니다.
     
     
5. DevOps 엔지니어는 모두 서로 다른 로그 형식을 생성하는 여러 레거시 애플리케이션을 보유하고 있습니다. 엔지니어는 쿼리 및 분석을 위해 Amazon S3에 쓰기 전에 형식을 표준화해야 합니다.
   
   최저 비용으로 이 요구 사항을 어떻게 충족할 수 있습니까?
   
   • 애플리케이션이 로그를 Amazon EMR 클러스터로 보내고 Amazon S3로 보내기 전에 로그를 정규화하도록 합니다.
   • 애플리케이션이 로그를 Amazon QuickSight로 전송하도록 한 다음 Amazon QuickSight SPICE 엔진을 사용하여 로그를 정규화합니다. Amazon QuickSight에서 직접 분석 수행
   • 로그를 Amazon S3에 보관하고 Amazon Redshift Spectrum을 사용하여 로그를 정규화합니다.
   • 각 서버에서 Amazon Kinesis 에이전트를 사용하여 로그를 업로드하고 Amazon Kinesis Data Firehose가 AWS Lambda 함수를 사용하여 로그를 Amazon S3에 쓰기 전에 정규화하도록 합니다.
     
     설명: Amazon Kinesis Data Streams > Kinesis 에이전트를 사용하여 Amazon Kinesis Data Streams
     Kinesis Agent는 간편하게 데이터를 Kinesis Data Streams로 전송할 수 있는 독립형 Java 소프트웨어 애플리케이션입니다. 에이전트가 파일 집합을 지속적으로 모니터링하고 새로운 데이터를 스트림에 보냅니다. 
     
     Amazon Kinesis Data Firehose Firehose는 무엇인가요?
     Kinesis Data Firehose로 데이터를 전송하도록 데이터 생산자를 구성하면 지정한 대상으로 데이터가 자동으로 전송됩니다. 데이터를 전송하기 전에 변환하도록 Kinesis Data Firehose Firehose를 구성할 수도 있습니다.
     
     
6. 회사는 Amazon S3를 사용하여 독점 정보를 저장합니다. 개발팀은 매일 새 프로젝트에 대한 버킷을 생성합니다. 보안 팀은 모든 기존 및 향후 버킷에 암호화, 로깅 및 버전 관리가 활성화되어 있는지 확인하려고 합니다. 또한 어떤 버킷도 공개적으로 읽거나 쓸 수 없어야 합니다.
   
   DevOps 엔지니어는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?
   
   • AWS CloudTrail을 활성화하고 AWS Lambda를 사용하여 자동 수정을 구성합니다.
   • AWS Config 규칙을 활성화하고 AWS Systems Manager 문서를 사용하여 자동 수정을 구성합니다.
   • AWS Trusted Advisor를 활성화하고 Amazon CloudWatch Events를 사용하여 자동 수정을 구성합니다.
   • AWS Systems Manager를 활성화하고 Systems Manager 문서를 사용하여 자동 수정을 구성합니다.
     
     설명:
     AWS Config는 사용자의 계정에서 AWS 리소스의 구성을 상세하게 볼 수 있도록 합니다. 
     AWS Systems Manager Manager는 AWS에서 인프라를 확인하고 제어할 수 있도록 도와줍니다.
     AWS Trusted Advisor는 AWS 모범 사례를 따르는 데 도움이 되는 권장 사항을 제공합니다.
     
     
7. DevOps 엔지니어는 AWS에서 이미지 일괄 처리 클러스터를 구현하는 가장 저렴한 방법을 연구하고 있습니다. 애플리케이션은 Docker 컨테이너에서 실행할 수 없으며 Amazon EC2에서 실행해야 합니다. 배치 작업은 체크포인트 데이터를 NFS(네트워크 파일 시스템)에 저장하고 중단을 허용할 수 있습니다. 일반 EC2 Linux 이미지에서 클러스터 소프트웨어를 구성하는 데 30분이 걸립니다.
   
   가장 비용 효율적인 솔루션은 무엇입니까?
   
   • 체크포인트 데이터에 Amazon EFS를 사용합니다. 작업을 완료하려면 EC2 Auto Scaling 그룹과 온디맨드 요금 모델을 사용하여 EC2 인스턴스를 임시로 프로비저닝합니다.
   • 체크포인트 데이터를 위해 EC2 인스턴스에서 GlusterFS를 사용합니다. 배치 작업을 실행하려면 EC2 인스턴스를 수동으로 구성하십시오. 작업이 완료되면 인스턴스를 수동으로 종료합니다.
   • 체크포인트 데이터에 Amazon EFS를 사용합니다. EC2 Fleet을 사용하여 EC2 스팟 인스턴스를 시작하고 사용자 데이터를 사용하여 시작 시 EC2 Linux 인스턴스를 구성합니다.
   • 체크포인트 데이터에 Amazon EFS를 사용합니다. EC2 Fleet을 사용하여 EC2 스팟 인스턴스를 시작합니다. 표준 클러스터 AMI를 생성하고 인스턴스를 생성할 때 최신 AMI를 사용합니다.
8. 회사에서 AWS CodeDeploy를 사용하여 애플리케이션 배포를 관리하고 있습니다. 최근에 개발팀은 버전 제어를 위해 GitHub를 사용하기로 결정했으며 팀은 GitHub 리포지토리를 CodeDeploy와 통합하는 방법을 찾고 있습니다. 또한 팀은 해당 리포지토리에 새 커밋이 있을 때마다 배포를 자동화하는 방법을 개발해야 합니다.
   
   가장 효율적인 방법으로 통합을 달성하려면 어떻게 해야 합니까?
   
   • 리포지토리를 AWS CodeCommit에 복제하는 GitHub 웹후크를 생성합니다. CodeCommit을 소스 공급자로 사용하고 AWS CodeDeploy를 배포 공급자로 사용하는 AWS CodePipeline 파이프라인을 생성합니다. 구성된 후에는 GitHub 리포지토리에 대한 변경 사항을 커밋하여 첫 번째 배포를 시작합니다.
   • GitHub를 소스 공급자로 사용하고 AWS CodeDeploy를 배포 공급자로 사용하는 AWS CodePipeline 파이프라인을 생성합니다. 이 새 파이프라인을 GitHub 계정과 연결하고 CodePipeline이 GitHub에서 웹후크를 사용하여 변경이 발생할 때 파이프라인을 자동으로 시작하도록 지시합니다.
   • GitHub 리포지토리 내에 새 커밋이 있는지 주기적으로 확인하는 AWS Lambda 함수를 생성합니다. 새 커밋이 발견되면 AWS CodeDeploy에 대한 CreateDeployment API 호출을 트리거하여 배포 그룹 내의 마지막 커밋 ID를 기반으로 새 배포를 시작합니다.
   • AWS CodeDeploy 사용자 지정 배포 구성을 생성하여 GitHub 리포지토리를 배포 그룹과 연결합니다. 연결 프로세스 중에 GitHub로 배포 그룹을 인증하여 GitHub 보안 인증 토큰을 얻습니다. 새 커밋이 발견되면 자동으로 배포하도록 배포 그룹 옵션을 구성합니다. GitHub 리포지토리에 대한 새 커밋을 수행하여 첫 번째 배포를 트리거합니다.
9. DevOps 엔지니어는 Amazon EC2 및 Amazon RDS MySQL에서 실행되는 워크로드에 대한 모니터링을 구현해야 합니다. 모니터링에는 다음이 포함되어야 합니다.
   – Amazon EC2 인스턴스에 대한 애플리케이션 로그 및 운영 체제 지표
   – Amazon RDS 데이터베이스에 대한 데이터베이스 로그 및 운영 체제 지표
   
   엔지니어는 어떤 조치를 취해야 합니까?
   • EC2 및 RDS 인스턴스에 Amazon CloudWatch 에이전트를 설치합니다. 운영 체제 지표와 애플리케이션 및 데이터베이스 로그를 CloudWatch로 보내도록 에이전트를 구성합니다.
   • EC2 인스턴스에 Amazon CloudWatch 에이전트를 설치하고 애플리케이션 로그 및 운영 체제 지표를 CloudWatch로 보내도록 에이전트를 구성합니다. RDS Enhanced Monitoring을 활성화하고 RDS 인스턴스를 수정하여 CloudWatch Logs에 데이터베이스 로그를 게시합니다.
   • EC2 인스턴스에 Amazon CloudWatch Logs 에이전트를 설치하고 애플리케이션 로그를 CloudWatch로 보내도록 구성합니다.
   • EC2 및 RDS 인스턴스에서 예약된 작업을 설정하여 운영 체제 지표와 애플리케이션 및 데이터베이스 로그를 Amazon S3 버킷에 넣습니다. 객체를 버킷에 넣을 때마다 오류를 모니터링하는 AWS Lambda 함수를 호출하도록 버킷에서 이벤트를 설정합니다.
     
     설명: Amazon Relational Database Service (RDS) > Enhanced Monitoring 개요
     Amazon RDS는 DB 인스턴스가 실행되는 운영 체제(OS)에 대한 측정치를 실시간으로 제공합니다. 콘솔에서 RDS DB 인스턴스에 대한 모든 시스템 지표 및 프로세스 정보를 볼 수 있습니다. 각 인스턴스에 대해 모니터링할 지표를 관리하고 요구 사항에 따라 대시보드를 사용자 지정할 수 있습니다. 향상된 모니터링 지표 설명은 향상된 모니터링의 OS 지표 섹션을 참조하세요.
      RDS는 지표를 확장 모니터링에서 Amazon CloudWatch Logs 계정으로 전달합니다. CloudWatch Logs에서 CloudWatch에서 지표 필터를 생성하고 CloudWatch 대시보드에 그래프를 표시할 수 있습니다. 
10. 회사는 회사의 AWS 계정에서 실행되는 모든 항목에 대해 모든 로그를 캡처해야 합니다. 계정에는 Amazon EC2 인스턴스, Application Load Balancer, Amazon RDS MySQL 데이터베이스 및 구성된 AWS WAF 규칙이 포함된 여러 VPC가 있습니다. 로그는 삭제되지 않도록 보호해야 합니다. 회사는 또한 전날의 이상 로그를 매일 시각적으로 분석해야 합니다.
    
    이러한 요구 사항을 충족하기 위해 DevOps 엔지니어는 어떤 작업 조합을 수행해야 합니까? (3개를 선택하세요.)
    
    • 모든 Amazon CloudWatch 로그를 Amazon S3 버킷으로 보내도록 AWS Lambda 함수를 구성합니다. Amazon QuickSight에서 대시보드 보고서를 생성합니다.
    • 모든 로그를 Amazon Inspector로 보내도록 AWS CloudTrail을 구성합니다. Amazon QuickSight에서 대시보드 보고서를 생성합니다.
    • 로깅 S3 버킷에서 Amazon S3 MFA 삭제를 구성합니다.
    • 로깅 S3 버킷에 대한 Amazon S3 객체 잠금 법적 보류를 구성합니다.
    • 모든 로그를 로깅 Amazon S3 버킷으로 보내도록 AWS Artifact를 구성합니다. Amazon QuickSight에서 대시보드 보고서를 생성합니다.
    • 모든 EC2 인스턴스에 Amazon CloudWatch 에이전트를 배포합니다.
      
      
      설명: Amazon QuickSight >  Amazon QuickSight 작동 방식
      Amazon QuickSight를 사용하면 데이터에 액세스하고 보고에 사용할 데이터를 준비할 수 있습니다. 준비된 데이터를 SPICE 메모리 또는 직접 쿼리로 저장합니다. 분석을 위해 다양한 데이터 소스를 사용할 수 있습니다. 분석을 생성할 때 일반적인 워크플로우는 다음과 같습니다.
      
      1. 새 분석을 만듭니다.
      2. 신규 또는 기존 데이터세트를 추가합니다.
      3. 필드를 선택하여 첫 번째 차트를 만듭니다. QuickSight는 최상의 시각화를 자동으로 제안합니다.
      4. 분석에 더 많은 차트, 표 또는 통찰력을 추가합니다. 하나 이상의 시트에서 크기를 조정하고 재정렬하십시오. 확장 기능을 사용하여 변수, 사용자 지정 컨트롤, 색상, 추가 페이지(시트라고 함) 등을 추가합니다.
      5. 다른 사람과 공유할 수 있도록 분석을 대시보드로 게시합니다.
      
      게시 대시보드
      QuickSight. 동일한 분석에서 나온 대화형 시트와 페이지별 보고서의 모든 조합을 포함하는 대시보드를 게시할 수 있습니다.
      
11. DevOps 엔지니어는 개발자가 AWS CodeCommit에서 회사의 마스터 브랜치로 업데이트를 직접 푸시하지 못하도록 막고자 합니다. 이러한 업데이트는 병합되기 전에 승인되어야 합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    
    • 참조가 마스터일 때 CodeCommit에 대한 액세스 권한과 쓰기 작업에 대한 명시적 거부가 있는 개발자에 대한 IAM 역할을 구성합니다. 개발자가 feature branche를 사용하고 feature이 완료되면 끌어오기 요청을 만들 수 있습니다. 승인자가 CodeCommit을 사용하여 변경 사항을 보고 풀 요청을 승인하도록 허용합니다.
    • 개발자가 feature 분기를 사용하고 feature이 완료되면 풀 요청을 생성하도록 IAM 역할을 구성합니다. CodeCommit이 feature 분기의 모든 코드를 테스트하도록 허용하고 feature 분기를 마스터에 병합할 수 있도록 IAM 역할을 동적으로 수정합니다. 승인자가 CodeCommit을 사용하여 변경 사항을 보고 풀 요청을 승인하도록 허용합니다.
    • 개발자가 feature 분기를 사용하고 feature이 완료되면 풀 요청을 생성하도록 IAM 역할을 구성합니다. CodeCommit이 feature 분기의 모든 코드를 테스트하도록 허용하고 일회성 API 호출로 feature 분기를 마스터에 병합할 수 있는 새로운 AWS STS(Security Token Service) 토큰을 발급합니다. 승인자가 CodeCommit을 사용하여 변경 사항을 보고 풀 요청을 승인하도록 허용합니다.
    • CodeCommit에 대한 액세스 권한이 있는 개발자에 대한 IAM 역할을 구성하고 참조가 마스터일 때 개발자 역할 액세스를 거부하는 액세스 정책을 CodeCommit 리포지토리에 연결합니다. 개발자가 feature 분기를 사용하고 feature이 완료되면 끌어오기 요청을 만들 수 있습니다. 승인자가 CodeCommit을 사용하여 변경 사항을 보고 풀 요청을 승인하도록 허용합니다.
12. 회사에서 AWS Organizations를 사용하여 각 부서에 대해 별도의 AWS 계정을 생성하고 있습니다. 다음 작업을 자동화해야 합니다.
    – 정기적으로 새 패치로 Linux AMI 업데이트 및 골든 이미지 생성
    – 가능한 경우 골든 이미지에 새 버전의 Chef 에이전트 설치
    – 부서 계정에서 새로 생성된 골든 AMI 사용 강제
    
    최소 관리 오버헤드가 필요한 옵션은 무엇입니까?
    • 이전 골든 AMI에서 Amazon EC2 인스턴스를 시작하는 스크립트를 작성하고, 패치 업데이트를 적용하고, Chef 에이전트의 새 버전을 설치하고, 새 골든 AMI를 생성한 다음 새 이미지만 부서와 공유하도록 AMI 권한을 수정합니다. ' 계정.
    • 먼저 AWS Systems Manager Run Command를 사용하여 Chef 에이전트를 업데이트하고 Amazon EC2 Systems Manager Automation을 사용하여 업데이트된 AMI를 생성한 다음 IAM 역할을 맡아 새 골든 AMI를 부서 계정에 복사합니다.
    • AWS Systems Manager Automation을 사용하여 이전 이미지를 사용하여 Linux AMI를 업데이트하고 Chef 에이전트를 업데이트할 스크립트의 URL을 제공한 다음 AWS Organizations를 사용하여 이전 골든 AMI를 부서 계정으로 교체합니다.
    • AWS Systems Manager Automation을 사용하여 이전 골든 이미지에서 Linux AMI를 업데이트하고 Chef 에이전트를 업데이트할 스크립트의 URL을 제공한 다음 새로 생성된 AMI만 부서의 계정과 공유합니다.
      
      설명: AWS Organizations란 무엇인가요?
      AWS Organizations은 생성한 여러 AWS 계정을 조직에 통합하고 중앙에서 관리할 수 있는 계정 관리 서비스입니다.
      
      
13. 회사는 회사의 품질 보증(QA) 파이프라인의 일부로 AWS CloudFormation을 사용하여 인프라를 자동으로 재생성하려고 합니다. 각 QA 실행에 대해 단일 계정에 새 VPC를 생성하고 VPC에 리소스를 배포해야 하며 이 새 인프라에 대해 테스트를 실행해야 합니다. 회사 정책에 따르면 중앙 집중식 로깅을 허용하려면 모든 VPC가 중앙 관리 VPC와 피어링되어야 합니다. 회사에는 VPC 및 관련 리소스를 배포하기 위한 기존 CloudFormation 템플릿이 있습니다.
    
    자동화되고 반복 가능한 방식으로 목표를 달성할 단계 조합은 무엇입니까? (두 가지를 선택하세요.) 
    • CreateVpcPeeringConnection API 호출이 이루어질 때 Amazon CloudWatch Events 규칙에 의해 호출되는 AWS Lambda 함수를 생성합니다. Lambda 함수는 피어링 요청의 소스를 확인하고, 요청을 수락하고, 트래픽이 피어링 연결을 통과할 수 있도록 관리 VPC에 대한 라우팅 테이블을 업데이트해야 합니다.
    • CloudFormation 템플릿에서:
      – 사용자 지정 리소스를 호출하여 VPC 및 서브넷에 대한 고유한 VPC CIDR 범위를 생성합니다.
      – 관리 VPC에 대한 피어링 연결을 생성합니다.
      – 관리 VPC에 대한 트래픽을 허용하도록 라우팅 테이블을 업데이트합니다.
    • CloudFormation 템플릿에서:
      – Fn::Cidr 함수를 사용하여 VPC 및 서브넷에 사용되지 않는 CIDR 범위를 할당합니다.
      – 관리 VPC에 대한 피어링 연결을 생성합니다.
      – 관리 VPC에 대한 트래픽을 허용하도록 라우팅 테이블을 업데이트합니다.
    • 스택이 배포될 각 계정에 대한 /16 CIDR 범위 목록을 포함하는 매핑 개체를 포함하도록 CloudFormation 템플릿을 수정합니다.
    • CloudFormation StackSets를 사용하여 고유한 CIDR 범위를 할당하는 사용자 지정 리소스를 사용하여 VPC 및 관련 리소스를 여러 AWS 계정에 배포합니다. 각 VPC에서 중앙 관리 VPC로의 피어링 연결을 생성하고 관리 VPC에서 해당 연결을 수락합니다.
      
      설명: Amazon EC2 > CreateVpcPeeringConnection
      두 VPC(귀하가 소유한 요청자 VPC와 연결을 생성할 수락자 VPC) 간의 VPC 피어링 연결을 요청합니다. 수락자 VPC는 ​​다른 AWS 계정에 속할 수 있으며 요청자 VPC와 다른 리전에 있을 수 있습니다. 요청자 VPC와 수락자 VPC는 ​​겹치는 CIDR 블록을 가질 수 없습니다. 요청자 VPC와 수락자 VPC는 ​​겹치는 CIDR 블록을 가질 수 없습니다.
      
      
14. 회사에는 단일 공유 AWS 계정에서 작업하는 여러 개발 그룹이 있습니다. 그룹의 선임 관리자는 리소스 생성이 계정의 서비스 제한에 도달할 때 타사 API 호출을 통해 경고를 받기를 원합니다.
    
    최소한의 개발 노력으로 이를 달성할 수 있는 솔루션은 무엇입니까?
    
    • 주기적으로 실행되고 AWS Lambda 함수를 대상으로 하는 Amazon CloudWatch Event 규칙을 생성합니다. Lambda 함수 내에서 AWS 환경의 현재 상태를 평가하고 배포된 리소스 값을 계정의 리소스 제한과 비교합니다. 계정이 서비스 한도에 근접하면 선임 관리자에게 알립니다.
    • AWS Trusted Advisor 검사를 refresh하는 AWS Lambda 함수를 배포하고 Lambda 함수를 주기적으로 실행하도록 Amazon CloudWatch Events 규칙을 구성합니다. Trusted Advisor 이벤트 및 대상 Lambda 함수와 일치하는 이벤트 패턴으로 또 다른 CloudWatch 이벤트 규칙을 생성합니다. 대상 Lambda 함수에서 선임 관리자에게 알립니다.
    • AWS Personal Health Dashboard 검사를 새로 고치는 AWS Lambda 함수를 배포하고 Lambda 함수를 주기적으로 실행하도록 Amazon CloudWatch Events 규칙을 구성합니다. Personal Health Dashboard 이벤트 및 대상 Lambda 함수와 일치하는 이벤트 패턴으로 또 다른 CloudWatch 이벤트 규칙을 생성합니다. 대상 Lambda 함수에서 선임 관리자에게 알립니다.
    • 주기적으로 실행되고 AWS 서비스 제한 상태를 확인하며 알림을 Amazon SNS 주제로 스트리밍하는 AWS Config 사용자 지정 규칙을 추가합니다. Senior Manager에게 알리는 AWS Lambda 함수를 배포하고 SNS 주제에 Lambda 함수를 구독합니다.
15. 엄격한 규제를 받는 회사에는 DevOps 엔지니어가 긴급 상황을 제외하고 Amazon EC2 인스턴스에 로그인해서는 안 된다는 정책이 있습니다. DevOps 엔지니어가 로그인하면 발생 후 15분 이내에 보안 팀에 알려야 합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    
    • 각 EC2 인스턴스에 Amazon Inspector 에이전트를 설치합니다. Amazon CloudWatch Events 알림을 구독하십시오. 메시지가 사용자 로그인에 관한 것인지 확인하기 위해 AWS Lambda 함수를 트리거합니다. 그렇다면 Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다.
    • 각 EC2 인스턴스에 Amazon CloudWatch 에이전트를 설치합니다. 모든 로그를 Amazon CloudWatch Logs로 푸시하도록 에이전트를 구성하고 사용자 로그인을 검색하는 CloudWatch 지표 필터를 설정합니다. 로그인이 발견되면 Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다.
    • Amazon CloudWatch Logs로 AWS CloudTrail을 설정합니다. Amazon Kinesis에 CloudWatch Logs를 구독합니다. Kinesis에 AWS Lambda를 연결하여 로그에 사용자 로그인이 포함되어 있는지 구문 분석하고 확인합니다. 그렇다면 Amazon SNS를 사용하여 보안 팀에 알림을 보냅니다.
    • 각 Amazon EC2 인스턴스에서 스크립트를 설정하여 모든 로그를 Amazon S3로 푸시합니다. 실행할 Amazon Athena 쿼리를 트리거하는 AWS Lambda 함수를 트리거하도록 S3 이벤트를 설정합니다. Athena 쿼리는 로그인을 확인하고 Amazon SNS를 사용하여 보안 팀에 출력을 보냅니다.
16. DevOps 엔지니어는 ALB(Application Load Balancer) 뒤의 Amazon EC2 인스턴스에서 실행되는 웹 애플리케이션을 관리합니다. 인스턴스는 여러 가용 영역에 걸쳐 EC2 Auto Scaling 그룹에서 실행됩니다. 엔지니어는 다음과 같은 배포 전략을 구현해야 합니다.
    – 원래 fleet과 동일한 용량으로 인스턴스의 두 번째 fleet을 시작합니다.
    – 두 번째 fleet가 시작되는 동안 원래 함대를 변경하지 않고 유지합니다.
    – 두 번째 fleet이 완전히 배포되면 트래픽을 두 번째 fleet으로 전환합니다.
    – 전환 후 1시간이 지나면 원래 fleet을 자동으로 종료합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    • ALB에 대한 보존 정책이 1시간으로 설정된 AWS CloudFormation 템플릿을 사용합니다. 새 ALB를 반영하도록 Amazon Route 53 레코드를 업데이트합니다.
    • 두 개의 AWS Elastic Beanstalk 환경을 사용하여 원래 환경에서 새 환경으로 블루/그린 배포를 수행합니다. 1시간 안에 원래 환경을 종료하는 애플리케이션 버전 수명 주기 정책을 만듭니다.
    • 블루/그린 배포 구성으로 구성된 배포 그룹과 함께 AWS CodeDeploy를 사용합니다. 대기 기간이 1시간인 배포 그룹의 원본 인스턴스 종료 옵션을 선택합니다.
    • 변경 불가능으로 설정된 구성으로 AWS Elastic Beanstalk를 사용합니다. ALB의 삭제 정책을 1시간으로 설정하는 리소스 키를 사용하여 .ebextension을 생성하고 애플리케이션을 배포합니다.
17. 회사에서 애플리케이션 배포를 위해 Docker 컨테이너를 사용하고 있으며 애플리케이션을 AWS로 이동하려고 합니다. 회사는 현재 이러한 컨테이너의 배포를 관리하기 위해 온프레미스에서 자체 클러스터를 관리합니다. 애플리케이션을 AWS의 관리형 서비스에 배포하고 배포 프로세스의 전체 흐름을 자동화하기를 원합니다. 또한 회사는 다음과 같은 요구 사항이 있습니다.
    – 먼저 개발 워크로드에 집중하십시오.
    – 환경은 관리하기 쉬워야 합니다.
    – 배포는 새로운 환경에서 반복 가능하고 재사용 가능해야 합니다.
    – GitHub 리포지토리에 코드를 저장합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    • Amazon ECS 환경을 설정합니다. AWS CodePipeline을 사용하여 GitHub 리포지토리에 대한 커밋에서 트리거되는 파이프라인을 생성합니다. AWS CodeBuild를 사용하여 컨테이너 이미지를 생성하고 AWS CodeDeploy를 사용하여 컨테이너 이미지를 ECS 환경에 게시합니다.
    • GitHub 리포지토리의 커밋에서 트리거되는 AWS CodePipeline을 사용하고, AWS CodeBuild로 컨테이너 이미지를 빌드하고, 컨테이너 이미지를 Amazon ECR에 게시합니다. 마지막 단계에서 AWS CloudFormation을 사용하여 ECR 리포지토리에서 컨테이너 이미지를 가져오는 Amazon ECS 환경을 생성합니다.
    • Amazon EC2에서 Kubernetes 클러스터를 생성합니다. AWS CodePipeline을 사용하여 코드가 리포지토리에 커밋될 때 트리거되는 파이프라인을 생성합니다. EC2에서 Jenkins 서버로 컨테이너 이미지를 생성하고 Docker Hub에 저장합니다. 파이프라인에서 AWS Lambda를 사용하여 Kubernetes 클러스터에 대한 배포를 트리거합니다.
    • Amazon ECS 환경을 설정합니다. AWS CodePipeline을 사용하여 GitHub 리포지토리에 대한 커밋에서 트리거되는 파이프라인을 생성합니다. AWS CodeBuild를 사용하여 컨테이너를 생성하고 Docker Hub에 저장합니다. AWS Lambda 함수를 사용하여 배포를 트리거하고 Docker Hub에서 새 컨테이너 이미지를 가져옵니다.
18. 회사에서 컨테이너 기반 애플리케이션을 Amazon EKS로 마이그레이션했으며 자동화된 이메일 알림을 설정하려고 합니다. 각 이메일 주소로 전송되는 알림은 EKS 구성 요소와 관련된 특정 활동에 대한 것입니다. 이 솔루션에는 들어오는 로그 이벤트를 평가하고 올바른 SNS 주제에 메시지를 게시하는 Amazon SNS 주제와 AWS Lambda 함수가 포함됩니다.
    
    이러한 요구 사항을 지원하는 로깅 솔루션은 무엇입니까?
    
    • Amazon CloudWatch Logs를 활성화하여 EKS 구성 요소를 기록합니다. Lambda를 구독 피드 대상으로 사용하여 각 구성 요소에 대한 CloudWatch 구독 필터를 생성합니다.
    • Amazon CloudWatch Logs를 활성화하여 EKS 구성 요소를 기록합니다. Lambda를 트리거하는 Amazon CloudWatch Events 이벤트에 연결된 CloudWatch Logs Insights 쿼리를 생성합니다.
    • EKS 구성 요소에 대한 Amazon S3 로깅을 활성화합니다. Lambda를 구독 피드 대상으로 사용하여 각 구성 요소에 대해 Amazon CloudWatch 구독 필터를 구성합니다.
    • EKS 구성 요소에 대한 Amazon S3 로깅을 활성화합니다. AWS Lambda를 대상으로 S3 PUT 객체 이벤트 알림을 구성합니다.
      
      설명: Amazon CloudWatch > CloudWatch Logs Insights를 사용한 로그 분석
      CloudWatch Logs Insights를 사용하면 Amazon CloudWatch Logs 내 로그 데이터를 대화식으로 검색해 분석할 수 있습니다. 운영상의 문제에 보다 효율적이고 효과적으로 대처할 수 있도록 쿼리를 수행할 수 있습니다. 문제가 발생하면 CloudWatch Logs Insights를 사용해 잠재적인 원인을 식별하고 배포된 수정 사항을 확인할 수 있습니다.
      
      CloudWatch Logs Insights에는 몇 가지 간단하지만 강력한 명령과 함께 특별히 구축된 쿼리 언어가 포함되어 있습니다. CloudWatch Logs Insights에서는 시작하는 데 도움이 되는 샘플 쿼리, 명령 설명, 쿼리 자동 완성 및 로그 필드 검색을 제공합니다. 여러 가지 유형의 AWS 서비스 로그에 대한 샘플 쿼리가 포함되어 있습니다.
19. n 계층 애플리케이션은 배포할 때마다 Amazon RDS MySQL DB 인스턴스의 테이블을 삭제하고 다시 채워야 합니다. 이 프로세스는 몇 분이 걸릴 수 있으며 프로세스가 완료될 때까지 웹 계층이 온라인 상태가 될 수 없습니다. 현재 웹 계층은 Amazon EC2 Auto Scaling 그룹에 구성되어 있으며 배포할 때마다 인스턴스가 종료되고 교체됩니다. MySQL 테이블은 AWS CodeBuild 작업을 통해 SQL 쿼리를 실행하여 채워집니다.
    
    데이터베이스가 완전히 구성되기 전에 웹 계층이 온라인 상태가 되지 않도록 하려면 어떻게 해야 합니까?
    
    • Amazon Aurora를 RDS MySQL의 드롭인 대체품으로 사용하십시오. 스냅샷을 사용하여 올바른 데이터로 테이블을 채웁니다.
    • 사용자 데이터 실행을 600초 동안 일시 중지하여 테이블을 채울 수 있도록 Auto Scaling 그룹의 시작 구성을 수정합니다.
    • AWS Step Functions를 사용하여 데이터 채우기 상태를 모니터링하고 유지합니다. 배포를 계속하기 전에 서비스 중인 데이터베이스를 표시하십시오.
    • EC2 Auto Scaling 수명 주기 후크를 사용하여 테이블이 채워질 때까지 웹 계층 구성을 일시 중지합니다.
      
      설명: Amazon EC2 Auto Scaling > Amazon EC2 Auto Scaling 수명 주기 후크
      Amazon EC2 Auto Scaling은 오토 스케일링에 수명 주기 후크를 추가할 수 있는 기능을 제공합니다. 이러한 후크를 사용하면 Auto Scaling 인스턴스 수명 주기의 이벤트를 인식하는 솔루션을 생성한 다음 해당 수명 주기 이벤트가 발생할 때 인스턴스에 대한 사용자 정의 작업을 수행할 수 있습니다. 수명 주기 후크는 인스턴스가 다음 상태로 전환되기 전에 작업이 완료될 때까지 대기할 지정된 시간(기본적으로 1시간)을 제공합니다.
      
20. 여러 서비스가 포함된 웹 애플리케이션은 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행됩니다. 애플리케이션은 Amazon RDS 다중 AZ DB 인스턴스에 데이터를 저장합니다. 로드 밸런서에서 사용하는 인스턴스 상태 확인은 인스턴스에서 하나 이상의 서비스가 실행 중인 경우 PASS를 반환합니다.
    
    이 회사는 AWS CodeBuild 및 AWS CodeDeploy 단계와 함께 AWS CodePipeline을 사용하여 테스트 및 프로덕션 환경에 코드를 배포합니다. 최근에 새 버전이 테스트 환경에서 데이터베이스 서버에 연결할 수 없었습니다. 하나의 프로세스가 실행 중이었기 때문에 상태 검사에서 정상으로 보고되었고 애플리케이션이 프로덕션으로 승격되어 프로덕션 중단이 발생했습니다. 회사는 프로덕션으로 승격되기 전에 테스트 빌드가 완전히 작동하는지 확인하려고 합니다.
    
    DevOps 엔지니어는 테스트 및 배포 프로세스에서 어떤 변경을 수행해야 합니까? (두 가지를 선택하세요.)
    • 견고한 테스트 사례가 수행되도록 자동화된 feature 테스트를 파이프라인에 추가합니다.
    • 테스트 엔지니어가 테스트 환경을 검증해야 하는 CodeDeploy 배포 파이프라인에 수동 승인 작업을 추가합니다.
    • 실제 애플리케이션 기능을 더 잘 검증하기 위해 Elastic Load Balancer가 확인하는 상태 확인 엔드포인트를 리팩터링합니다.
    • Elastic Load Balancer가 확인하는 상태 확인 엔드포인트를 리팩터링하여 텍스트 기반 상태 결과를 반환하고 유효한 응답을 확인하도록 로드 밸런서를 구성합니다.
    • 호환성을 보장하기 위해 기존 테스트 프레임워크에 종속성 검사 단계를 추가합니다.
      
      설명: AWS CodePipeline > CodePipeline 의 파이프라인에 수동 승인 작업 추가
      파이프라인을 중지하려는 시점에 CodePipeline 파이프라인의 단계에 승인 작업을 추가하면 다른 사람이 해당 작업을 수동으로 승인하거나 거부할 수 있습니다.
      
      
      

 

정답

D B A A D B D B B A,D,F A D A,B B B C B B D B,C