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

 

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. 빠르게 성장하는 회사는 AWS 개발 환경에 대한 개발자 수요에 맞게 확장하려고 합니다. 개발 환경은 AWS Management Console에서 수동으로 생성됩니다. 네트워킹 팀은 AWS CloudFormation을 사용하여 네트워킹 인프라를 관리하고 Amazon VPC 및 모든 서브넷에 대한 스택 출력 값을 내보냅니다. 개발 환경에는 Application Load Balancer, Amazon EC2 Auto Scaling 그룹, 보안 그룹 및 Amazon DynamoDB 테이블과 같은 공통 표준이 있습니다.
   
   수요에 부응하기 위해 DevOps 엔지니어는 개발 환경 생성을 자동화하려고 합니다. 애플리케이션을 지원하는 데 필요한 인프라가 증가할 것으로 예상되기 때문에 배포된 인프라를 쉽게 업데이트할 수 있는 방법이 있어야 합니다. CloudFormation은 개발 환경용 템플릿을 생성하는 데 사용됩니다.
   
   이러한 요구 사항을 충족하고 개발자에게 일관된 AWS 환경을 신속하게 제공하는 접근 방식은 무엇입니까?
   • 템플릿의 리소스 섹션에서 Fn:ImportValue 내장 함수를 사용하여 Virtual Private Cloud(VPC) 및 서브넷 값을 검색합니다. Count 입력 매개 변수를 사용하여 필요한 환경 수를 나타내는 CloudFormation StackSets를 개발 환경에 사용하십시오. UpdateStackSet 명령을 사용하여 기존 개발 환경을 업데이트합니다.
   • 중첩 스택을 사용하여 공통 인프라 구성 요소를 정의합니다. 내보낸 값에 액세스하려면 TemplateURL을 사용하여 네트워킹 팀의 템플릿을 참조하십시오. Virtual Private Cloud(VPC) 및 서브넷 값을 검색하려면 마스터 템플릿의 매개변수 섹션에서 Fn::ImportValue 내장 함수를 사용하십시오. CreateChangeSet 및 ExecuteChangeSet 명령을 사용하여 기존 개발 환경을 업데이트합니다.
   • 중첩 스택을 사용하여 공통 인프라 구성 요소를 정의합니다. Fn::ImportValue 내장 함수를 중첩 스택의 리소스와 함께 사용하여 Virtual Private Cloud(VPC) 및 서브넷 값을 검색합니다. CreateChangeSet 및 ExecuteChangeSet 명령을 사용하여 기존 개발 환경을 업데이트합니다.
   • 마스터 템플릿의 매개변수 섹션에서 Fn:ImportValue 내장 함수를 사용하여 Virtual Private Cloud(VPC) 및 서브넷 값을 검색합니다. CloudFormation 중첩 스택에서 생성해야 하는 순서대로 개발 리소스를 정의합니다. CreateChangeSet 및 ExecuteChangeSet 명령을 사용하여 기존 개발 환경을 업데이트합니다.
2. 회사는 AWS Elastic Beanstalk 로드 밸런싱 및 자동 조정 환경에 웹사이트를 가지고 있습니다. 이 환경에는 데이터베이스 리소스로 구성된 Amazon RDS MySQL 인스턴스가 있습니다. 트래픽이 갑자기 증가한 후 웹 사이트에서 트래픽이 감소하기 시작했습니다. 관리자가 메모리 부족 오류로 인해 일부 인스턴스의 애플리케이션이 응답하지 않는 것을 발견했습니다. Classic Load Balancer는 해당 인스턴스를 서비스 중단으로 표시했으며 Elastic Beanstalk 향상된 상태 보고의 상태가 저하되었습니다. 그러나 Elastic Beanstalk는 이러한 인스턴스를 대체하지 않았습니다. Classic Load Balancer 이면의 용량 감소로 인해 고객의 애플리케이션 응답 시간이 느려집니다.
   
   이 문제를 영구적으로 해결하는 조치는 무엇입니까?
   
   • Elastic Beanstalk 환경을 복제합니다. 새 환경이 가동되면 CNAME을 교체하고 이전 환경을 종료합니다.
   • 그룹이 더 많은 트래픽을 지원할 수 있도록 Auto Scaling 그룹의 최대 인스턴스 수를 일시적으로 변경합니다.
   • Auto Scaling 그룹 상태 확인에 대한 설정을 Amazon EC2에서 Elastic Load Balancing으로 변경하고 그룹의 용량을 늘립니다.
   • 메모리가 가득 찼을 때 웹 서버 프로세스를 다시 시작하기 위한 cron 스크립트를 작성하고 AWS Systems Manager로 배포합니다.
3. DevOps 엔지니어는 Amazon Route 53, Application Load Balancer, Auto Scaling 및 Amazon DynamoDB를 사용하여 인프라에 배포될 새로운 애플리케이션을 출시하고 있습니다. 이번 출시의 주요 요구 사항 중 하나는 애플리케이션이 로드 증가에 맞게 확장될 수 있어야 한다는 것입니다. 사용량이 적은 기간에는 인프라 구성 요소를 축소하여 비용을 최적화해야 합니다.
   
   DevOps 엔지니어는 요구 사항을 충족하기 위해 어떤 단계를 수행할 수 있습니까? (두 가지를 선택하세요.)
   
   • AWS Trusted Advisor를 사용하여 인프라에서 사용할 Amazon EC2 인스턴스에 대한 제한 증가 요청을 제출하십시오.
   • AWS Trusted Advisor를 활용하여 어느 Amazon EC2 인스턴스 제한을 늘려야 하는지 결정하고 AWS Support에 요청을 제출하여 해당 제한을 늘립니다.
   • 애플리케이션에서 사용하는 DynamoDB 테이블에 대해 Auto Scaling을 활성화합니다.
   • 현재 로드를 기반으로 대상 그룹을 자동으로 조정하도록 Application Load Balancer를 구성합니다.
   • Auto Scaling 그룹의 현재 사용을 추적하기 위해 5분마다 실행되는 Amazon CloudWatch Events 예약 규칙을 생성합니다. 사용량이 변경된 경우 확장 이벤트를 트리거하여 용량을 조정합니다. DynamoDB 읽기 및 쓰기 용량에 대해서도 동일한 작업을 수행합니다.
4. 회사는 AWS Elastic Beanstalk를 사용하여 Python 기반 애플리케이션의 일부를 호스팅합니다. Elastic Beanstalk CLI는 환경을 생성하고 업데이트하는 데 사용되고 있습니다. 운영 팀은 Elastic Beanstalk 환경 중 하나에서 밤새 다운타임을 야기한 요청 증가를 감지했습니다. 팀은 AWS Auto Scaling에 사용되는 정책이 NetworkOut이라는 점에 주목했습니다. 부하 테스트 지표를 기반으로 팀은 애플리케이션이 환경의 복원력을 개선하기 위해 CPU 사용률을 확장해야 한다고 결정했습니다. 팀은 모든 환경에서 이를 자동으로 구현하려고 합니다.
   
   AWS 권장 사항에 따라 이 자동화를 어떻게 구현해야 합니까?
   
   • ebextensions를 사용하여 container_commands 키 내에 명령을 배치하여 API 호출을 수행하여 Auto Scaling 구성에 대한 조정 지표를 CPUUtilization으로 수정합니다. leader_only를 사용하여 환경 내에서 시작된 첫 번째 인스턴스에서만 이 명령을 실행합니다.
   • ebextensions를 사용하여 AWSEBAutoScalingScaleUpPolicy 및 AWSEBAutoScalingScaleDownPolicy 리소스를 수정하는 사용자 지정 리소스를 생성하여 CPUUtilization을 지표로 사용하여 Auto Scaling 그룹에 맞게 조정합니다.
   • ebextensions를 사용하여 aws:autoscaling:trigger 네임스페이스 내에서 MeasureName 옵션 설정을 CPUUtilization으로 구성합니다.
   • ebextensions를 사용하여 파일 키 내에 스크립트를 배치하고 /opt/elasticbeanstalk/hooks/appdeploy/pre에 배치하여 API 호출을 수행하여 Auto Scaling 구성에 대한 CPUUtilization에 대한 조정 지표를 수정합니다. leader_only를 사용하여 환경 내에서 시작된 첫 번째 인스턴스에만 이 스크립트를 배치합니다.
5. DevOps 팀은 AWS Elastic Beanstalk와 함께 배포된 여러 Amazon EC2 인스턴스를 실행하는 애플리케이션에서 생성된 애플리케이션 로그의 정보를 쿼리해야 합니다.
   
   Elastic Beanstalk에서 Amazon CloudWatch Logs로의 인스턴스 로그 스트리밍이 활성화되었습니다.
   
   가장 비용 효율적인 방법은 무엇입니까?
   • CloudWatch Logs 구독을 사용하여 AWS Lambda 함수를 트리거하여 Amazon S3 버킷 대상이 있는 Amazon Kinesis Data Firehose 스트림으로 로그 데이터를 보냅니다. Amazon Athena를 사용하여 버킷에서 로그 데이터를 쿼리합니다.
   • CloudWatch Logs 구독을 사용하여 AWS Lambda 함수를 트리거하여 Amazon S3 버킷 대상이 있는 Amazon Kinesis Data Firehose 스트림으로 로그 데이터를 보냅니다. 새로운 Amazon Redshift 클러스터와 Amazon Redshift Spectrum을 사용하여 버킷에서 로그 데이터를 쿼리합니다.
   • CloudWatch Logs 구독을 사용하여 Amazon S3 버킷 대상이 있는 Amazon Kinesis Data Firehose 스트림으로 로그 데이터를 보냅니다. Amazon Athena를 사용하여 버킷에서 로그 데이터를 쿼리합니다.
   • CloudWatch Logs 구독을 사용하여 Amazon S3 버킷 대상이 있는 Amazon Kinesis Data Firehose 스트림으로 로그 데이터를 보냅니다. 새로운 Amazon Redshift 클러스터와 Amazon Redshift Spectrum을 사용하여 버킷에서 로그 데이터를 쿼리합니다.
    
6. 회사의 웹 애플리케이션이 AWS로 마이그레이션됩니다. 애플리케이션은 서버측 코드가 필요하지 않도록 설계되었습니다. 마이그레이션의 일환으로 회사는 OWASP(Open Web Application Security Project) 보안 헤더 권장 사항에 따라 HTTP 응답 헤더를 추가하여 애플리케이션의 보안을 개선하려고 합니다.
   
   모범 사례를 사용하여 보안 요구 사항을 충족하기 위해 이 솔루션을 구현하는 방법은 무엇입니까?
   
   • 웹 사이트 호스팅용으로 구성된 Amazon S3 버킷을 사용한 다음 S3 버킷에 대한 서버 액세스 로깅을 설정하여 사용자 활동을 추적합니다. 그런 다음 정적 웹 사이트 호스팅을 구성하고 예약된 AWS Lambda 함수를 실행하여 확인하고 누락된 경우 메타데이터에 보안 헤더를 추가합니다.
   • 웹 사이트 호스팅용으로 구성된 Amazon S3 버킷을 사용한 다음 S3 버킷에 대한 서버 액세스 로깅을 설정하여 사용자 활동을 추적합니다. 필수 보안 헤더를 반환하도록 정적 웹사이트 호스팅을 구성합니다.
   • 웹 사이트 호스팅용으로 구성된 Amazon S3 버킷을 사용합니다. 보안 헤더에 추가할 Lambda@Edge Node.js 함수를 트리거하도록 설정된 원본 응답 이벤트와 함께 이 S3 버킷을 참조하는 Amazon CloudFront 배포를 생성합니다.
   • 웹 사이트 호스팅용으로 구성된 Amazon S3 버킷을 사용합니다. 이 S3 버킷을 참조하는 Amazon CloudFront 배포를 생성합니다. "Cache Based on Selected Request Headers"를 "Whitelist"로 설정하고 보안 헤더를 화이트리스트에 추가합니다.
     
     설명: OWASP는 소프트웨어의 보안을 향상시키기 위한 비영리 재단입니다.
     
     Lambda@Edge 및 Amazon CloudFront를 사용하여 HTTP 보안 헤더 추가
     웹 사이트로 이동할 때마다 브라우저가 웹 페이지를 요청하고 서버는 HTTP 헤더와 함께 내용으로 응답합니다.캐시 제어 등의 헤더는 브라우저에 의해 콘텐츠를 캐시하는 기간을 결정하기 위해 사용되며, content-type 등의 헤더는 리소스의 미디어 유형을 나타내므로 이러한 리소스를 해석하는 방법을 나타냅니다.이 투고에서는 뷰어와 콘텐츠 프로바이더의 보안과 프라이버시를 향상시키기 위한 응답 헤더를 추가하는 방법에 대해 설명합니다.또한 Lambda@Edge 및아마존 CloudFront를 사용하여 이러한 헤더를 웹 사이트에 추가하는 방법도 보여 줍니다.
     
     
7. 전자상거래 회사는 AWS Elastic Beanstalk 환경에서 웹 애플리케이션을 실행하고 있습니다. 최근 몇 개월 동안 더 많은 트래픽을 처리하기 위해 Amazon EC2 인스턴스의 평균 로드가 증가했습니다.
   회사는 환경의 확장성과 탄력성을 개선하고자 합니다. 개발 팀은 작업을 비동기식으로 실행할 수 있는 경우 환경에서 장기 실행 작업을 분리하라는 요청을 받았습니다. 이러한 작업의 예로는 사용자가 플랫폼에 등록할 때 확인 이메일을 보내고 이미지 또는 비디오를 처리하는 것이 있습니다. 또한 현재 웹 서버 내에서 실행 중인 일부 주기적 작업을 오프로드해야 합니다.
   
   이를 달성하기 위한 가장 시간 효율적이고 통합된 방법은 무엇입니까?
   
   • Amazon SQS 대기열을 생성하고 Elastic Beanstalk 웹 서버 환경에서 분리해야 하는 작업을 SQS 대기열로 보냅니다. Auto Scaling 그룹 아래에 EC2 인스턴스 플릿을 생성합니다. 애플리케이션이 포함된 AMI를 사용하여 비동기 작업을 처리하고, SQS 대기열 내에서 메시지를 수신하도록 애플리케이션을 구성하고, 이러한 작업을 운영 체제의 cron에 배치하여 주기적 작업을 생성합니다. SQS 대기열 엔드포인트를 가리키는 값을 사용하여 Elastic Beanstalk 환경 내에서 환경 변수를 생성합니다.
   • 두 번째 Elastic Beanstalk 작업자 계층 환경을 생성하고 애플리케이션을 배포하여 그곳에서 비동기 작업을 처리합니다. 원래 Elastic Beanstalk 웹 서버 환경에서 분리해야 하는 작업을 Elastic Beanstalk 작업자 환경에서 자동 생성된 Amazon SQS 대기열로 보냅니다. 주기적인 작업을 위해 작업자 환경에 대한 애플리케이션 소스 번들의 루트 내에 cron.yaml 파일을 배치합니다. 환경 링크를 사용하여 웹 서버 환경과 작업자 환경을 연결합니다.
   • 두 번째 Elastic Beanstalk 웹 서버 티어 환경을 생성하고 애플리케이션을 배포하여 비동기 작업을 처리합니다. 원래 Elastic Beanstalk 웹 서버에서 분리해야 하는 작업을 두 번째 Elastic Beanstalk 웹 서버 티어 환경에서 자동 생성된 Amazon SQS 대기열로 보냅니다. 필요한 주기적 작업이 있는 두 번째 웹 서버 계층 환경에 대한 애플리케이션 소스 번들의 루트 내에 cron.yaml 파일을 배치합니다. 환경 링크를 사용하여 두 웹 서버 환경을 연결하십시오.
   • Amazon SQS 대기열을 생성하고 Elastic Beanstalk 웹 서버 환경에서 분리해야 하는 작업을 SQS 대기열로 보냅니다. Auto Scaling 그룹 아래에 EC2 인스턴스 플릿을 생성합니다. UserData의 SQS 대기열 내 메시지를 수신하도록 애플리케이션을 설치 및 구성하고 이를 운영 체제의 cron에 배치하여 주기적 작업을 생성합니다. SQS 대기열 엔드포인트를 가리키는 값을 사용하여 Elastic Beanstalk 웹 서버 환경 내에서 환경 변수를 생성합니다.
8. 프로덕션에서 결함이 발견되었으며 핫픽스 배포를 위해 새 스프린트 항목이 생성되었습니다. 그러나 모든 코드 변경은 생산에 들어가기 전에 다음 단계를 거쳐야 합니다.
   
   – 암호 및 액세스 키 유출과 같은 보안 위반이 있는지 코드를 스캔합니다.
   – 광범위하고 오래 실행되는 단위 테스트를 통해 코드를 실행합니다.
   
   이 프로세스를 완료하기 위해 DevOps 엔지니어가 AWS CodePipeline과 함께 사용해야 하는 소스 제어 전략은 무엇입니까?
   • 마스터 브랜치의 마지막 커밋에 핫픽스 태그를 만듭니다. 핫픽스 태그에서 개발 파이프라인을 트리거합니다. Amazon ECS와 함께 AWS CodeDeploy를 사용하여 콘텐츠 스캔을 수행하고 단위 테스트를 실행하십시오. 핫픽스 태그를 마스터 분기에 병합하는 수동 승인 단계를 추가합니다.
   • 마스터 분기에서 핫픽스 분기를 만듭니다. 핫픽스 분기에서 개발 파이프라인을 트리거합니다. AWS CodeBuild를 사용하여 콘텐츠 스캔을 수행하고 단위 테스트를 실행하십시오. 핫픽스 분기를 마스터 분기에 병합하는 수동 승인 단계를 추가합니다.
   • 마스터 분기에서 핫픽스 분기를 만듭니다. 핫픽스 분기에서 개발 파이프라인을 트리거합니다. AWS Lambda를 사용하여 콘텐츠 스캔을 수행하고 단위 테스트를 실행합니다. 핫픽스 분기를 마스터 분기에 병합하는 수동 승인 단계를 추가합니다.
   • 마스터 분기에서 핫픽스 분기를 만듭니다. 프로덕션 파이프라인에서 핫픽스 분기에 대한 별도의 소스 단계를 만듭니다. 핫픽스 분기에서 파이프라인을 트리거합니다. AWS Lambda를 사용하여 콘텐츠 스캔을 수행하고 AWS CodeBuild를 사용하여 단위 테스트를 실행합니다. 핫픽스 분기를 마스터 분기에 병합하는 수동 승인 단계를 추가합니다.
9. 대규모 온프레미스 OpenStack 환경을 보유한 회사의 관리 팀은 비프로덕션 워크로드를 AWS로 이전하려고 합니다. 환경을 연결하도록 AWS Direct Connect 연결이 프로비저닝 및 구성되었습니다. 계약상의 의무로 인해 프로덕션 워크로드는 온프레미스에 남아 있어야 하며 다음 계약 협상 후 AWS로 이전됩니다. 회사는 이미지 강화를 위해 CIS(Center for Internet Security) 표준을 따릅니다. 이 구성은 회사의 구성 관리 시스템을 사용하여 개발되었습니다.
   
   상당한 오버헤드 없이 AWS 환경에서 동일한 이미지를 자동으로 생성하는 솔루션은 무엇입니까?
   
   • Amazon EC2 인스턴스를 생성할 AWS CloudFormation 템플릿을 작성합니다. cloud-unit을 사용하여 구성 관리 에이전트를 설치하고, cfn-wait를 사용하여 구성 관리가 성공적으로 적용되기를 기다리고, AWS Lambda 지원 사용자 지정 리소스를 사용하여 AMI를 생성합니다.
   • 콘솔에 로그인하고 Amazon EC2 인스턴스를 시작한 다음 구성 관리 에이전트를 설치합니다. 구성 관리 시스템을 통해 변경 사항이 적용되면 콘솔에 로그인하여 인스턴스에서 새 AMI를 생성합니다.
   • 새 AWS OpsWorks 계층을 생성하고 이미지 강화 표준을 미러링합니다. 이 계층을 모든 AWS 워크로드의 기준으로 사용하십시오.
   • 구성 관리 시스템이 변경되면 VM Import 명령을 사용하여 Amazon VPC에서 Amazon EC2 인스턴스를 생성하도록 Jenkins의 작업이 트리거됩니다. 수명 주기 후크를 사용하여 AWS Lambda 함수를 시작하여 AMI를 생성합니다.
10. DevOps 엔지니어는 ELB Application Load Balancer 뒤에 있는 프라이빗 서브넷의 Amazon EC2 인스턴스에서 실행될 웹 서비스를 지원하기 위해 AWS CloudFormation 템플릿을 작성하고 있습니다. 엔지니어는 서비스가 IPv6 주소가 있는 클라이언트의 요청을 수락할 수 있는지 확인해야 합니다.
    
    IPv6 클라이언트가 웹 서비스에 액세스할 수 있도록 하려면 엔지니어가 CloudFormation 템플릿에 통합해야 하는 구성 항목은 무엇입니까?
    
    • IPv6 CIDR 블록을 EC2 인스턴스가 상주할 Amazon VPC 및 서브넷과 연결합니다. IPv6 네트워크에 대한 라우팅 테이블 항목을 생성하고, IPv6를 지원하는 EC2 인스턴스 유형을 사용하고, 각 EC2 인스턴스에 IPv6 주소를 할당합니다.
    • Application Load Balancer를 Network Load Balancer로 교체하십시오. IPv6 CIDR 블록을 Virtual Private Cloud(VPC) 및 Network Load Balancer가 있는 서브넷과 연결하고 Network Load Balancer에 IPv6 탄력적 IP 주소를 할당합니다.
    • 각 EC2 인스턴스에 IPv6 탄력적 IP 주소를 할당합니다. 대상 그룹을 생성하고 EC2 인스턴스를 대상으로 추가합니다. Application Load Balancer의 포트 443에서 리스너를 생성하고 새로 생성된 대상 그룹을 기본 대상 그룹으로 연결합니다.
    • 대상 그룹을 생성하고 EC2 인스턴스를 대상으로 추가합니다. Application Load Balancer의 포트 443에서 리스너를 생성합니다. 새로 생성된 대상 그룹을 기본 대상 그룹으로 연결합니다. 이중 스택 IP 주소를 선택하고 보안 그룹에서 모든 위치로부터의 인바운드 트래픽을 허용하는 규칙을 생성합니다.
11. 보안 팀은 개발자가 실수로 탄력적 IP 주소를 생산 중인 Amazon EC2 인스턴스에 연결할 수 있다고 우려합니다. 어떤 개발자도 탄력적 IP 주소를 인스턴스에 연결할 수 없습니다. 프로덕션 서버에 탄력적 IP 주소가 있는 경우 언제든지 보안 팀에 알려야 합니다.
    
    이 작업을 어떻게 자동화할 수 있습니까?
    
    • Amazon Athena를 사용하여 AWS CloudTrail 로그를 쿼리하여 연결 주소 시도를 확인합니다. 탄력적 IP 주소를 인스턴스에서 분리하고 보안 팀에 알리는 AWS Lambda 함수를 생성합니다.
    • Associate-address 권한을 거부하려면 개발자의 IAM 그룹에 IAM 정책을 연결합니다. 사용자 지정 AWS Config 규칙을 생성하여 탄력적 IP 주소가 프로덕션으로 태그가 지정된 인스턴스와 연결되어 있는지 확인하고 보안 팀에 알립니다.
    • 모든 IAM 그룹이 개발자와 연결되어 있는지 확인하십시오. 주소 연결 권한이 없습니다. 예약된 AWS Lambda 함수를 생성하여 탄력적 IP 주소가 프로덕션으로 태그가 지정된 인스턴스와 연결되어 있는지 확인하고 인스턴스에 연결된 탄력적 IP 주소가 있는 경우 보안 팀에 알립니다.
    • AWS Config 규칙을 생성하여 모든 프로덕션 인스턴스에 거부 연결 주소 권한이 포함된 EC2 IAM 역할이 있는지 확인합니다. 인스턴스와 연결된 탄력적 IP 주소가 있는지 확인하고 인스턴스에 연결된 탄력적 IP 주소가 있는 경우 보안 팀에 알립니다.
      
      설명: AWS Config 사용 방법
      - 리소스 관리
        리소스 구성을 보다 효과적으로 관리하고 리소스 구성 오류를 발견하려면, 존재하는 리소스 및 이러한 리소스의 구성 방식을 언제든 세부적으로 파악할 수 있어야 합니다. AWS Config를 사용하여 각 리소스에 대한 호출을 폴링함으로써 리소스가 생성, 수정 또는 삭제될 때마다 모니터링할 필요 없이 이러한 변경 사항에 대한 알림을 받을 수 있습니다.
      - 감사, 보안 및 규정 준수
      - 구성 변경 관리 및 문제 해결
      - 보안 분석
      
      
12. 회사에서 시계열 데이터를 저장하고 검색하는 REST 서비스를 제공하는 Node.js 웹 애플리케이션을 개발했습니다. 웹 애플리케이션은 개발 팀이 회사 랩톱에서 구축하고 로컬에서 테스트한 다음 로컬 MySQL 데이터베이스에 액세스하는 단일 온프레미스 서버에 수동으로 배포합니다. 이 회사는 2주 후에 평가판을 시작할 예정이며, 이 기간 동안 고객 피드백을 기반으로 응용 프로그램이 자주 업데이트됩니다. 다음 요구 사항을 충족해야 합니다.
    – 팀은 다운타임이나 성능 저하 없이 매일 새로운 업데이트를 안정적으로 빌드, 테스트 및 배포할 수 있어야 합니다.
    – 응용 프로그램은 평가 기간 동안 예측할 수 없는 동시 사용자 수를 충족하도록 확장할 수 있어야 합니다.
    
    팀이 이러한 목표를 신속하게 달성할 수 있는 조치는 무엇입니까?
    
    • Node.js용 Amazon Lightsail 가상 프라이빗 서버 2개를 생성합니다. 하나는 테스트용이고 다른 하나는 생산용입니다. 기존 프로세스를 사용하여 Node.js 애플리케이션을 빌드하고 AWS CLI를 사용하여 새 Lightsail 테스트 서버에 업로드합니다. 애플리케이션을 테스트하고 모든 테스트를 통과하면 프로덕션 서버에 업로드합니다. 평가 기간 동안 프로덕션 서버 사용량을 모니터링하고 필요한 경우 인스턴스 유형을 업그레이드하여 성능을 높입니다.
    • AWS CloudFormation 템플릿을 개발하여 롤링 업데이트가 활성화된 Auto Scaling 그룹에서 Amazon EBS(SSD) 볼륨이 있는 Amazon EC2 인스턴스 2개와 Application Load Balancer를 생성합니다. AWS CodeBuild를 사용하여 Node.js 애플리케이션을 빌드 및 테스트하고 Amazon S3 버킷에 저장합니다. 사용자 데이터 스크립트를 사용하여 각 EC2 인스턴스에 애플리케이션과 MySQL 데이터베이스를 설치합니다. 스택을 업데이트하여 새 애플리케이션 버전을 배포합니다.
    • AWS CodeBuild를 사용하여 애플리케이션을 자동으로 빌드하고 Auto Scaling을 지원하도록 구성된 테스트 환경에 배포하도록 AWS Elastic Beanstalk를 구성합니다. 프로덕션을 위한 두 번째 Elastic Beanstalk 환경을 생성합니다. Amazon RDS를 사용하여 데이터를 저장합니다. 애플리케이션의 새 버전이 모든 테스트를 통과하면 Elastic Beanstalk 'swap cname'을 사용하여 테스트 환경을 프로덕션으로 승격합니다.
    • 로컬 MySQL 데이터베이스 대신 Amazon DynamoDB를 사용하도록 애플리케이션을 수정합니다. AWS OpsWorks를 사용하여 DynamoDB 계층, Application Load Balancer 계층 및 Amazon EC2 인스턴스 계층이 있는 애플리케이션용 스택을 생성합니다. Chef 레시피를 사용하여 애플리케이션을 빌드하고 Chef 레시피를 사용하여 애플리케이션을 EC2 인스턴스 계층에 배포합니다. 사용자 지정 상태 확인을 사용하여 실패 시 롤백과 함께 각 인스턴스에서 단위 테스트를 실행합니다.
      
      설명: Elastic Beanstalk를 사용한 블루/그린 배포
      사용자가 애플리케이션 버전을 업데이트할 때 AWS Elastic Beanstalk는 현재 위치 업데이트를 수행하므로 사용자는 잠시 애플리케이션을 사용하지 못할 수도 있습니다. 이를 방지하려면 블루/그린 배포를 수행합니다. 블루/그린 배포에서는 새 버전을 별도의 환경에 배포한 후 두 환경의 CNAME을 바꿔 트래픽을 새 버전으로 즉시 리디렉션합니다.
13. DevOps 엔지니어는 기능이 일반 가용성에 대해 완전히 승인되기 전에 데이터 기반 결정을 허용하는 배포 전략을 개발하고 있습니다. 현재 배포 프로세스는 AWS CloudFormation 및 블루/그린 스타일 배포를 사용합니다. 개발팀은 고객을 정해진 비율을 사용하는 대신 무작위로 그룹에 할당하고 리디렉션을 피해야 한다고 결정했습니다.
    
    새로운 배포 전략을 구현하려면 어떤 프로세스를 따라야 합니까?
    
    • 트래픽의 50%가 각 스택으로 라우팅되도록 구성된 블루 및 그린 스택에 대한 Amazon Route 53 가중 레코드를 구성합니다.
    • CloudFront가 요청을 수신할 때 쿠키를 설정하도록 AWS Lambda@Edge 함수로 Amazon CloudFront를 구성합니다. 사용자를 버전 A 또는 B에 할당하고 버전 A 또는 B로 리디렉션하도록 웹 서버를 구성합니다.
    • CloudFront가 요청을 수신할 때 쿠키를 설정하도록 AWS Lambda@Edge 함수로 Amazon CloudFront를 구성합니다. 사용자를 버전 A 또는 B에 할당한 다음 해당 버전을 뷰어에 반환합니다.
    • Amazon CloudFront가 요청을 수신할 때 쿠키를 설정하도록 AWS Lambda 함수로 Amazon Route 53을 구성합니다. 사용자를 버전 A 또는 B에 할당한 다음 해당 버전을 뷰어에 반환합니다.
      
      설명: Lambda@Edge 예제 함수 > 예: A/B 테스트
      Lambda@Edge 트리거는 CloudFront 배포, 캐시 동작, 그리고 함수 실행을 유도하는 이벤트를 하나로 조합한 것입니다. 함수를 실행시키는 CloudFront 트리거를 하나 이상 지정할 수 있습니다. 예를 들어, 최종 사용자가 해당 배포에 설정된 특정 캐시 동작을 CloudFront에 요청하면 함수가 실행되도록 하는 트리거를 생성할 수 있습니다.
        다음 예제를 사용하여 리디렉션을 만들거나 URL을 변경하지 않고 두 가지 다른 버전의 이미지를 테스트할 수 있습니다. 이 예제는 최종 사용자 요청의 쿠키를 읽고 그에 따라 요청 URL을 수정합니다. 최종 사용자가 예상 값 중 하나와 함께 쿠키를 보내지 않는 경우, 이 예제에서는 최종 사용자를 URL 중 하나에 임의로 할당합니다.
      
14. 한 회사에서 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행되는 웹 애플리케이션을 테스트하고 있습니다. 인스턴스는 여러 가용 영역의 Auto Scaling 그룹에서 실행됩니다. 이 회사는 새 소프트웨어를 배포할 때 변경 불가능한 인스턴스와 함께 블루/그린 배포 프로세스를 사용합니다.
    
    테스트하는 동안 사용자는 임의의 시간에 애플리케이션에서 자동으로 로그아웃됩니다. 테스터는 또한 애플리케이션의 새 버전이 배포되면 모든 사용자가 로그아웃된다고 보고합니다. 개발 팀은 확장 이벤트 및 애플리케이션 배포에서 사용자가 로그인 상태를 유지하도록 보장하는 솔루션이 필요합니다. 
    
    사용자가 로그인 상태를 유지하도록 하는 가장 효율적인 방법은 무엇입니까?
    • 로드 밸런서에서 스마트 세션을 활성화하고 애플리케이션을 수정하여 기존 세션을 확인합니다.
    • 로드 밸런서에서 세션 공유를 활성화하고 세션 저장소에서 읽도록 애플리케이션을 수정합니다.
    • Amazon S3 버킷에 사용자 세션 정보를 저장하고 버킷에서 세션 정보를 읽도록 애플리케이션을 수정합니다.
    • Amazon ElastiCache 클러스터에 사용자 세션 정보를 저장하도록 애플리케이션을 수정합니다.
      
      설명: 온라인 응용 프로그램용 고속 세션 스토어 구축
      Amazon ElastiCache for Redis를 세션 관리의 분산 캐시로 사용할 수 있습니다. 또, ElastiCache 노드를 구성하는 베스트 프랙티스와 애플리케이션의 세션 처리 방법에 대해서도 설명합니다.
15. 회사에서 IAM 정책을 검토하고 있습니다. DevOps 엔지니어가 작성한 한 정책은 너무 관대한 것으로 표시되었습니다. 이 정책은 주말 동안 Environment: NonProduction 태그가 지정된 Amazon EC2 인스턴스에 중지 명령을 내리는 AWS Lambda 함수에서 사용됩니다. 현재 정책은 다음과 같습니다.

    

    DOP-C01 AWS DevOps 엔지니어 전문가 파트 06 Q15 004

    
    최소 권한 정책을 달성하기 위해 엔지니어는 어떤 변경을 수행해야 합니까? (3개를 선택하세요.)

    • 

      DOP-C01 AWS DevOps 엔지니어 전문가 파트 06 Q15 005

    • 

      DOP-C01 AWS DevOps 엔지니어 전문가 파트 06 Q15 006

    • 

      DOP-C01 AWS DevOps 엔지니어 전문가 파트 06 Q15 007

    • 

      DOP-C01 AWS DevOps 엔지니어 전문가 파트 06 Q15 008

      

      DOP-C01 AWS DevOps 엔지니어 전문가 파트 06 Q15 009

    • 

      DOP-C01 AWS DevOps 엔지니어 전문가 파트 06 Q15 010

16. 의료 서비스용 웹 애플리케이션은 ELB Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행됩니다. 인스턴스는 여러 가용 영역에 걸쳐 Amazon EC2 Auto Scaling 그룹에서 실행됩니다. DevOps 엔지니어는 시스템 로그에서 문제를 분석하여 웹 계층의 문제를 신속하게 해결할 수 있도록 EC2 인스턴스를 생산에서 제외할 수 있는 메커니즘을 만들어야 합니다.
    
    엔지니어는 가용성을 보장하고 다운타임을 최소화하면서 이 작업을 어떻게 수행할 수 있습니까?
    
    • EC2 Auto Scaling 그룹 휴지 기간을 구현합니다. EC2 인스턴스 메타데이터를 사용하여 인스턴스 상태를 확인하고 AWS Lambda 함수를 사용하여 Amazon EBS 볼륨을 스냅샷하여 시스템 로그를 보존합니다.
    • Amazon CloudWatch Events 규칙을 구현합니다. 인스턴스 종료에 대응할 수 있는 AWS Lambda 함수를 생성하여 CloudWatch Logs 에이전트를 배포하여 시스템을 업로드하고 분석을 위해 Amazon S3에 로그에 액세스합니다.
    • EC2 인스턴스를 수동으로 종료합니다. Auto Scaling 서비스는 인스턴스 종료 전에 분석을 위해 모든 로그 정보를 CloudWatch Logs에 업로드합니다.
    • 수명 주기 후크로 EC2 Auto Scaling 그룹을 구현합니다. EC2 인스턴스 수명 주기 후크를 대기 상태로 수정하고, 원격 스크립트 실행을 통해 인스턴스에서 로그를 추출하고, 분석을 위해 Amazon S3 버킷에 배치할 수 있는 AWS Lambda 함수를 생성합니다.
      
      설명: Amazon EC2 Auto Scaling 수명 주기 후크 
      Amazon EC2 Auto Scaling은 오토 스케일링에 수명 주기 후크를 추가할 수 있는 기능을 제공합니다. 이러한 후크를 사용하면 Auto Scaling 인스턴스 수명 주기의 이벤트를 인식하는 솔루션을 생성한 다음 해당 수명 주기 이벤트가 발생할 때 인스턴스에 대한 사용자 정의 작업을 수행할 수 있습니다. 
      
      
17. 개발 팀이 AWS CodeBuild에서 빌드 프로젝트를 생성합니다. 빌드 프로젝트는 AWS 서비스에 액세스하는 모듈의 자동화된 테스트를 호출합니다.
    
    다음 중 MOST를 안전하게 실행하기 위한 테스트는 무엇입니까?
    
    • AWS 서비스에 대한 작업을 허용하는 정책이 연결된 IAM 사용자의 자격 증명을 생성합니다. 빌드 프로젝트의 암호화된 환경 변수로 자격 증명을 저장합니다. 빌드 스크립트의 일부로 통합 테스트를 실행하기 위한 자격 증명을 얻습니다.
    • CodeBuild가 Jenkins 서버에서 빌드 작업으로 통합 테스트만 실행하도록 합니다. AWS 서비스에 대한 작업을 허용하는 정책이 연결된 역할을 생성합니다. 역할을 수임할 수 있는 IAM 사용자의 자격 증명을 생성합니다. Jenkins에서 자격 증명을 비밀로 구성하고 빌드 작업에서 이를 사용하여 통합 테스트를 실행하도록 허용합니다.
    • AWS 서비스에 대한 작업을 허용하도록 연결된 정책을 사용하여 CodeBuild가 맡을 IAM에서 서비스 역할을 생성합니다. 생성된 역할을 사용하도록 빌드 프로젝트를 구성합니다.
    • AWS 관리 자격 증명을 사용합니다. AWS KMS로 자격 증명을 암호화합니다. 빌드 스크립트의 일부로 AWS KMS로 암호를 해독하고 이러한 자격 증명을 사용하여 통합 테스트를 실행합니다.
      
      설명: AWS CodeBuild Report를 통한 UnitTest 및 Code Coverage 시각화
      유닛테스트는 모듈의 기능을 테스트 할 수 있는 작은 단위의 효과적인 테스트입니다. 하나의 소프트웨어는 여러개의 모듈로 이루어져있으며 유닛테스트는 이런 각각의 모듈이 정상적으로 기능을 수행하는지 시험할 수 있는 최소 수준의 시험단위를 뜻합니다. AWS CodeBuild에서는 유닛테스트와 코드 커버리지의 결과를 시각화하여 리포트로 받아볼 수 있습니다. 덕분에 CI/CD 파이프라인의 일부로서 CodeBuild 를 보다 효과적으로 활용할 수 있게 되었습니다.
      
      
18. 소매 회사는 AWS Elastic Beanstalk를 사용하여 Java에서 실행되는 온라인 판매 웹 사이트를 호스팅하려고 합니다. 이것은 생산 웹 사이트가 될 것이므로 CTO는 배포 전략에 대해 다음과 같은 요구 사항을 갖습니다.
    
    – 중단 시간이 없습니다. 배포가 진행되는 동안 서비스 중인 현재 Amazon EC2 인스턴스는 서비스 상태를 유지해야 합니다. 프로덕션 트래픽을 제공하기 때문에 EC2 인스턴스에서 배포 또는 기타 작업을 수행해서는 안 됩니다.
    – 새 애플리케이션 버전을 배포하려면 새 인스턴스 플릿을 프로비저닝해야 합니다.
    – 새 애플리케이션 버전이 새 인스턴스 플릿에 성공적으로 배포되면 새 인스턴스를 서비스에 배치하고 이전 인스턴스를 제거해야 합니다.
    – 롤백은 가능한 한 쉬워야 합니다. 새 인스턴스 플릿이 새 애플리케이션 버전을 배포하는 데 실패하면 인스턴스를 종료하고 현재 인스턴스가 계속 정상적으로 트래픽을 처리해야 합니다.
    – 환경 내의 리소스(EC2 Auto Scaling 그룹, Elastic Load Balancing, Elastic Beanstalk DNS CNAME)는 동일하게 유지되어야 하며 DNS 변경이 없어야 합니다.
    
    요구 사항을 충족하는 배포 전략은 무엇입니까?
    
    • 한 번에 한 인스턴스씩 고정된 양의 롤링 배포를 사용하고 정상 임계값을 OK로 설정합니다.
    • 한 번에 한 인스턴스씩 고정된 양의 추가 배치와 함께 롤링 배포를 사용하고 정상 임계값을 OK로 설정합니다.
    • 새 환경을 시작하고 거기에 새 애플리케이션 버전을 배포한 다음 환경 간에 CNAME 스왑을 수행합니다.
    • 변경할 수 없는 환경 업데이트를 사용하여 필요한 모든 요구 사항을 충족합니다.
      
      설명: AWS Elastic Beanstalk >  변경이 불가능한 환경 업데이트
      변경 불가능한 환경 업데이트는 롤링 업데이트의 대안입니다. 변경 불가능한 환경 업데이트를 통해 인스턴스 교체가 필요한 구성 변경이 효율적이고 안전하게 적용됩니다. 변경이 불가능한 환경 업데이트에 실패하면 롤백 프로세스는 Auto Scaling 그룹만 종료하면 됩니다. 반면에 롤링 업데이트에 실패하면 롤백 업데이트를 추가로 수행하여 변경 사항을 롤백해야 합니다.
      
      Elastic Beanstalk는 변경이 불가능한 환경 업데이트를 수행하기 위해 환경의 로드 밸런서 뒤에 새 인스턴스를 포함할 두 번째 임시 Auto Scaling 그룹을 생성합니다. 먼저 Elastic Beanstalk는 새로운 그룹에서 새로운 구성으로 단일 인스턴스를 시작합니다. 이 인스턴스는 이전 구성을 실행 중인 원래 Auto Scaling 그룹의 모든 인스턴스와 함께 트래픽을 처리합니다.
      
      첫 번째 인스턴스가 상태 확인을 통과하면 Elastic Beanstalk는 원래 Auto Scaling 그룹에서 실행 중인 인스턴스 수와 일치하는 새로운 구성으로 추가 인스턴스를 시작합니다. 모든 새 인스턴스가 상태 확인을 통과하면 Elastic Beanstalk는 이를 원래 Auto Scaling 그룹으로 전송하고 임시 Auto Scaling 그룹 및 이전 인스턴스를 종료합니다.
      
19. 한 회사에서 AWS CodeBuild, AWS CodeDeploy 및 AWS CodePipeline을 사용하여 애플리케이션을 Amazon EC2 인스턴스에 자동으로 배포하고 있습니다. DevOps 엔지니어는 환경에 배포된 모든 애플리케이션에서 운영 체제의 보안 평가 스캔을 수행해야 합니다.
    
    이것을 어떻게 자동화해야 합니까?
    
    • Amazon CloudWatch Events를 사용하여 새 인스턴스의 Auto Scaling 이벤트 알림을 모니터링하고 Amazon Inspector 스캔을 트리거하도록 CloudWatch Events를 구성합니다.
    • Amazon CloudWatch Events를 사용하여 성공적인 코드 배포에 대한 AWS CodeDeploy 알림을 모니터링하고 Amazon Inspector 스캔을 트리거하도록 CloudWatch Events를 구성합니다.
    • Amazon CloudWatch Events를 사용하여 성공적인 코드 배포에 대한 CodePipeline 알림을 모니터링하고 AWS X-Ray 스캔을 트리거하도록 CloudWatch Events를 구성하십시오.
    • CodeDeploy를 성공적으로 사용한 후 Amazon Inspector를 CodePipeline 작업으로 사용하여 코드를 시스템에 배포합니다.
      
      설명: 자동화된 소프트웨어 취약성 관리 Amazon Inspector
      Amazon Inspector는 지속적으로 스캔하는 취약성 관리 서비스입니다.AWS취약성을 위한 워크로드 Amazon Inspector는 Amazon ECR (Amazon 엘라스틱 컨테이너 레지스트리) 에 있는 Amazon EC2 인스턴스와 컨테이너 이미지를 자동으로 검색하여 소프트웨어 취약성과 의도하지 않은 네트워크 노출이 있는지 검사합니다.
20. 전자 건강 기록을 사용하는 회사는 Amazon Linux 운영 체제에서 Amazon EC2 인스턴스 플릿을 실행하고 있습니다. 환자 개인 정보 보호 요구 사항의 일환으로 회사는 EC2 인스턴스에서 실행되는 운영 체제 및 애플리케이션의 패치에 대한 지속적인 규정 준수를 보장해야 합니다.
    
    기본 및 사용자 지정 리포지토리를 사용하여 운영 체제 및 애플리케이션 패치의 배포를 어떻게 자동화할 수 있습니까?
    
    • AWS Systems Manager를 사용하여 사용자 지정 리포지토리를 포함하는 새 패치 기준을 생성합니다. run 명령을 사용하여 AWS-RunPatchBaseline 문서를 실행하여 패치를 확인하고 설치합니다.
    • AWS Direct Connect를 사용하여 회사 리포지토리를 통합하고 Amazon CloudWatch 예약 이벤트를 사용하여 패치를 배포한 다음 CloudWatch 대시보드를 사용하여 보고서를 생성합니다.
    • yum-config-manager는 /etc/yum.repos.d 아래에 사용자 지정 리포지토리를 추가하고 yum-config-manager-enable을 실행하여 리포지토리를 활성화합니다.
    • AWS Systems Manager를 사용하여 회사 리포지토리를 포함하는 새 패치 기준을 생성합니다. 실행 명령을 사용하여 AWS-AmazonLinuxDefaultPatchBaseline 문서를 실행하여 패치를 확인하고 설치합니다.
      
      
      설명: AWS-RunPatchBaseline  SSM 문서 정보
      AWS Systems Manager는 AWS-RunPatchBaselineAWS Systems Manager의 기능인 Patch Manager용 Systems Manager 문서(SSM 문서)를 지원합니다. 이 SSM 문서는 보안 관련 및 기타 유형의 업데이트 모두에 대해 관리 노드에서 패치 작업을 수행합니다.