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

cc

 

 

1. 애플리케이션 기능에 중요한 특정 프로세스를 실행하는 애플리케이션이 있고 상태 확인 프로세스를 Auto Scaling 그룹에 추가했습니다. 인스턴스가 정상으로 표시되지만 애플리케이션 자체가 제대로 작동하지 않습니다. 인스턴스가 여전히 정상으로 표시되기 때문에 상태 확인에 문제가 될 수 있는 것은 무엇입니까?
   • 상태 확인의 시간 범위가 올바르게 구성되지 않았습니다.
   • 상태 확인에서 애플리케이션과 관련된 프로세스를 모니터링할 수 없습니다.
   • 상태 확인이 제대로 구성되지 않았습니다.
   • health check에서 신청절차를 확인하지 않고 있습니다.
   설명:

   사용자 지정 상태 확인이 있는 경우 Auto Scaling에서 이 정보를 사용할 수 있도록 상태 확인의 정보를 Auto Scaling으로 보낼 수 있습니다. 예를 들어 인스턴스가 예상대로 작동하지 않는다고 판단되면 인스턴스의 상태를 비정상으로 설정할 수 있습니다. 다음에 Auto Scaling이 인스턴스에 대한 상태 확인을 수행할 때 인스턴스가 비정상임을 확인한 다음 대체 인스턴스를 시작합니다.
   
   

2. 최근에 ELB 뒤의 EC2 인스턴스에 애플리케이션을 배포했습니다. 몇 주 후 고객은 응용 프로그램에서 오류를 수신하는 것에 대해 불평하고 있습니다. 오류를 진단하고 ELB 액세스 로그에서 오류를 가져오려고 합니다. 그러나 ELB 액세스 로그는 비어 있습니다. 그 이유는 무엇입니까?
   • 로그에 액세스할 수 있는 적절한 권한이 없습니다.
   • CloudWatch 지표가 올바르게 구성되지 않았습니다.
   • ELB 액세스 로그는 최대 1주일 동안만 사용할 수 있습니다.
   • 액세스 로깅은 기본적으로 비활성화되는 Elastic Load Balancing의 선택적 기능입니다.
   설명:

   Clastic Load Balancing은 로드 밸런서로 전송된 요청에 대한 자세한 정보를 캡처하는 액세스 로그를 제공합니다. 캐시 로그에는 요청을 받은 시간, 클라이언트의 IP 주소, 대기 시간, 요청 경로 및 서버 응답과 같은 정보가 포함됩니다. 이러한 액세스 로그를 사용하여 트래픽 패턴을 분석하고 문제를 해결할 수 있습니다. 액세스 로깅은 기본적으로 비활성화되어 있는 Elastic Load Balancing의 선택적 기능입니다. 로드 밸런서에 대한 액세스 로깅을 활성화한 후. Clastic Load Balancing은 로그를 캡처하여 지정한 Amazon S3 버킷에 저장합니다. 언제든지 액세스 로깅을 비활성화할 수 있습니다.
   
   

3. Auto Scaling을 사용하여 새 인스턴스를 시작하는 애플리케이션을 AWS에 배포했습니다. 이제 새 인스턴스의 인스턴스 유형을 변경하려고 합니다. 다음 중 이 배포를 달성하기 위한 작업 항목 중 하나는 무엇입니까?
   • Elastic Beanstalk를 사용하여 새 인스턴스 유형으로 새 애플리케이션 배포
   • Cloudformation을 사용하여 새 인스턴스 유형으로 새 애플리케이션 배포
   • 새 인스턴스 유형으로 새 시작 구성 생성
   • 새 인스턴스 유형으로 새 EC2 인스턴스를 생성하고 Auto Scaling 그룹에 연결
   설명:

   이상적인 방법은 새 시작 구성을 생성하여 기존 Auto Scaling 그룹에 연결하고 실행 중인 인스턴스를 종료하는 것입니다. Classic Beanstalk는 요청 시 새 인스턴스를 시작할 수 없기 때문에 옵션 A가 유효하지 않습니다. 현재 시나리오에는 Auto Scaling이 필요하므로 이상적인 옵션이 아닙니다. Auto Scaling 그룹만 있기 때문에 유지 관리 오버헤드가 되기 때문에 옵션 B는 유효하지 않습니다. 이를 위해 전체 Cloudformation 템플릿을 생성할 필요가 없습니다. 옵션 D는 Auto Scaling Group이 이전 시작 구성으로 CC2 인스턴스를 계속 시작하기 때문에 유효하지 않습니다.
   
   

4. 애플리케이션은 EC2 인스턴스에 연결된 EBS 볼륨에 중요한 정보를 저장합니다. 정보를 어떻게 보호할 수 있습니까? (두 가지를 선택하세요.)
   • EBS 볼륨을 마운트 해제하고 스냅샷을 만들고 스냅샷을 암호화합니다. Amazon EBS 볼륨을 다시 마운트합니다.
   • EBS 볼륨을 암호화하는 것은 불가능합니다. 암호화를 위해 데이터를 S3로 전송하려면 수명 주기 정책을 사용해야 합니다.
   • 암호화되지 않은 스냅샷을 복사하고 확인란을 선택하여 새 스냅샷을 암호화합니다. 이 암호화된 스냅샷에서 복원된 볼륨도 암호화됩니다.
   • 암호화된 새 Amazon EBS 볼륨을 생성하고 탑재합니다. 데이터를 새 볼륨으로 이동합니다. 이전 Amazon EBS 볼륨을 삭제합니다.
   설명:

   이러한 단계는 AWS 설명서에 나와 있습니다.
   암호화된 볼륨과 암호화되지 않은 볼륨 간에 데이터를 마이그레이션하려면
   1) 대상 볼륨을 생성합니다(필요에 따라 암호화 또는 암호화되지 않음).
   2) 마이그레이션할 데이터를 호스팅하는 인스턴스에 대상 볼륨을 연결합니다.
   3) Amazon EBS 볼륨을 사용 가능하게 만들기의 절차에 따라 대상 볼륨을 사용 가능하게 만듭니다. Linux 인스턴스의 경우 /mnt/destination에 마운트 지점을 생성하고 여기에 대상 볼륨을 마운트할 수 있습니다.
   4) 원본 디렉터리에서 대상 볼륨으로 데이터를 복사합니다. 이를 위해 대량 복사 유틸리티를 사용하는 것이 가장 편리할 수 있습니다.
   스냅샷 복사를 통해 볼륨의 데이터를 암호화하려면
   1) 암호화되지 않은 CBS 볼륨의 스냅샷을 생성합니다. 이 스냅샷도 암호화되지 않았습니다.
   2) 암호화 파라미터를 적용하면서 스냅샷을 복사합니다. 결과 대상 스냅샷은 암호화됩니다.
   3) 암호화된 스냅샷을 역시 암호화된 새 볼륨으로 복원합니다.
   
   

5. Auto Scaling 그룹에 계속 유지하면서 트래픽을 전송하기 전에 새 인스턴스를 테스트할 때 어떤 Auto Scaling 프로세스가 도움이 됩니까?
   • AZ 재조정 프로세스 일시 중단
   • 프로세스 상태 확인 일시 중지
   • 비정상 교체 프로세스 일시 중단
   • AddToLoadBalancer 프로세스를 일시 중단합니다.
   설명:

   로드 밸런서에 추가를 일시 중지하면 Auto Scaling에서 인스턴스를 시작하지만 로드 밸런서 또는 대상 그룹에 추가하지는 않습니다. AddTo Load Balancer 프로세스를 재개하는 경우. Auto Scaling은 시작 시 로드 밸런서 또는 대상 그룹에 인스턴스 추가를 재개합니다. 그러나 Auto Scaling은 이 프로세스가 일시 중지된 동안 시작된 인스턴스를 추가하지 않습니다. 해당 인스턴스를 수동으로 등록해야 합니다. 옵션 A는 리전의 가용 영역 전체에서 그룹의 CC2 인스턴스 수의 균형을 맞추기 때문에 유효하지 않습니다. 옵션 B는 인스턴스의 상태만 확인하기 때문에 유효하지 않습니다. Auto Scaling은 Amazon CC2 또는 Clastic Load Balancing이 Auto Scaling에 인스턴스가 비정상이라고 알려주는 경우 해당 인스턴스를 비정상으로 표시합니다.

    

6. EC2 인스턴스가 실행되는 AWS에 ELB 설정이 있습니다. ELB로 들어오는 연결을 모니터링하도록 요청받았습니다.
   
   다음 옵션 중 이 요구 사항을 충족할 수 있는 옵션은 무엇입니까?
   
   • 로드 밸런서에서 AWSCIoudTrail 사용
   • 로드 밸런서에서 액세스 로그 활성화
   • CloudWatch Logs 에이전트 사용
   • 로드 밸런서에서 사용자 지정 지표 CloudWatch 필터 생성
   설명:

   Clastic Load Balancing은 로드 밸런서로 전송된 요청에 대한 자세한 정보를 캡처하는 액세스 로그를 제공합니다. 캐시 로그에는 요청을 받은 시간, 클라이언트의 IP 주소, 대기 시간, 요청 경로 및 서버 응답과 같은 정보가 포함됩니다. 이러한 액세스 로그를 사용하여 트래픽 패턴을 분석하고 문제를 해결할 수 있습니다.
   이 서비스가 모든 AWS 서비스를 모니터링하므로 옵션 A는 유효하지 않습니다. 옵션 C와 D는 CLB가 이미 로깅 기능을 제공하므로 유효하지 않습니다.
   
   

7. DevOps 엔지니어는 3티어 웹 애플리케이션의 구성 요소를 배포하기 위한 도구를 추천해 달라는 요청을 받았습니다. 이 애플리케이션은 Amazon DynamoDB를 데이터베이스로 사용합니다. 운영 관리가 가장 적게 필요한 배포는 무엇입니까?
   • AWS CloudFormation을 사용하여 Classic Load Balancer 및 Auto Scaling 그룹을 생성합니다. AWS OpsWorks를 사용하여 애플리케이션 및 데이터베이스 리소스 생성 수명 주기 이벤트를 사용하여 OpsWorks로 애플리케이션 업데이트 배포
   • AWS OpsWorks를 사용하여 Classic Load Balancer, Auto Scaling 그룹 애플리케이션 및 데이터베이스 리소스 생성 OpsWorks 수명 주기 이벤트를 사용하여 애플리케이션 업데이트 배포
   • AWS OpsWorks를 사용하여 Classic Load Balancer Auto Scaling 및 애플리케이션 리소스 생성 AWS CloudFormation을 사용하여 데이터베이스 리소스 생성 CloudFormation 롤링 업데이트를 사용하여 애플리케이션 업데이트 배포
   • AWS CloudFormation을 사용하여 Classic Load Balancer, Auto Scaling 그룹 및 데이터베이스 리소스 생성 CloudFormation 롤링 업데이트를 사용하여 애플리케이션 업데이트 배포
8. 회사에서 AWS CodePipeline을 사용하여 인프라를 코드로 관리하고 배포합니다. 인프라는 AWS CloudFormation 템플릿에서 정의되며 주로 여러 Amazon EC2 인스턴스 및 Amazon RDS 데이터베이스로 구성됩니다. 보안 팀은 소스 CIDR이 0 0 0 0/0인 인바운드 보안 그룹 규칙을 생성하는 많은 운영자를 관찰했으며 개방형 CIDR이 있는 규칙의 배포를 사전에 중지하고자 합니다. DevOps 엔지니어는 파이프라인이 처리하기 전에 CloudFormation 템플릿. 규칙에 "보안 승인 참조 XXXXX(여기서 XXXXX는 미리 할당된 참조)"라는 설명이 있는 경우 이 검사는 소스 CIDR이 0.0.0.0/0인 인바운드 보안 그룹 규칙만 허용해야 합니다. 이 조건이 충족되지 않으면 파이프라인 단계가 실패하고 배포가 차단되어야 합니다.
   • AWS Organizations에서 SCP를 활성화합니다. 규칙이 보안 승인을 참조하는 설명 없이 0.0.0.0/0을 지정하는 경우 정책은 API 호출 Create Security GroupRule에 대한 액세스를 거부해야 합니다.
   • Security Check라는 CodePipeline에 초기 단계를 추가합니다. 이 단계는 CloudFormation 템플릿을 스캔하고 보안 승인을 참조하는 설명 없이 보안 그룹에서 0.0.0.0/0을 찾으면 파이프라인에 실패하는 AWS Lambda 함수를 호출해야 합니다.
   • 리소스 유형 EC2 SecurityGroup의 생성 또는 편집 시 트리거되는 AWS Config 규칙을 생성합니다. 보안 그룹에 보안 승인을 참조하는 설명 없이 소스 CIDR이 0.0.0.0/0인 규칙이 있는 경우 이 규칙은 AWS Lambda 함수를 호출하여 실패 알림을 보내야 합니다.
   • CodePipeline에서 사용하는 IAM 역할을 수정합니다. IAM 정책은 액세스를 거부해야 합니다.
9. 회사에서 태깅을 사용하여 AWS 비용을 할당하고 있습니다. 회사에는 Auto Scaling 그룹에서 실행되는 Amazon EC2 인스턴스가 있습니다. EC2 인스턴스에 연결된 Amazon Elastic Block Store(Amazon EBS) 볼륨이 적절한 비용 센터 태그 없이 생성되고 있습니다. DevOps 엔지니어는 새 EBS 볼륨에 적절하게 태그가 지정되었는지 확인해야 합니다.
   
   이 요구 사항을 충족하는 가장 효율적인 솔루션은 무엇입니까?
   
   • 비용 센터 태그를 EBS 볼륨에 연결하는 autoscaling:EC2_INSTANCE_TERMINATING 인스턴스 상태에서 수명 주기 후크를 생성합니다.
   • EBS 볼륨에 대한 비용 센터 태그를 포함하도록 Auto Scaling 그룹 시작 템플릿을 업데이트합니다.
   • 비용 센터 태그를 포함하도록 Auto Scaling 그룹을 업데이트합니다. PropagateAILaunch 속성을 true로 설정합니다.
   • 태그 편집기를 사용하여 태그가 누락된 EBS 볼륨을 검색하고 비용 센터 태그를 볼륨에 추가합니다.
     
     
10. 회사에서 AWS 개발 도구를 사용하여 현재 bash 배포 스크립트를 대체하려고 합니다. 이 회사는 현재 ALB(Application Load Balancer) 뒤의 Amazon EC2 인스턴스 그룹에 LAMP 애플리케이션을 배포하고 있습니다. 배포하는 동안 회사 단위는 커밋된 애플리케이션을 테스트하고, 서비스를 중지 및 시작하고, 로드 밸런서에 인스턴스를 등록 취소 및 재등록하고, 파일 권한을 업데이트합니다. 회사는 AWS 서비스 사용으로의 전환을 통해 동일한 배포 기능을 유지하려고 합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    
    • AWS CodeBuild를 사용하여 애플리케이션을 테스트합니다. AWS CodeDeploy의 appspec.yml 파일에서 호출한 bash 스크립트를 사용하여 서비스를 다시 시작하고 ALB에 인스턴스를 등록 취소 및 등록합니다. 사용자 정의 스크립트 없이 파일 권한을 업데이트하려면 appspec.yml 파일을 사용하십시오.
    • AWS CodePipeline을 사용하여 AWS CodeCommit 리포지토리에서 AWS CodeDeploy로 애플리케이션을 이동합니다. CodeDeploy의 배포 그룹을 사용하여 애플리케이션을 테스트하고 ALB에 인스턴스를 등록 취소 및 재등록하고 서비스를 다시 시작합니다. 사용자 정의 스크립트 없이 권한을 업데이트하려면 appspec.yml 파일을 사용하십시오.
    • AWS CodePipeline을 사용하여 AWS CodeCommit 리포지토리에서 AWS CodeDeploy로 애플리케이션 소스 코드를 이동합니다. CodeDeploy를 사용하여 애플리케이션을 테스트합니다. CodeDeploy의 appspec.yml 파일을 사용하여 사용자 지정 스크립트 없이 서비스를 다시 시작하고 권한을 업데이트합니다. AWS CodeBuild를 사용하여 ALB에 인스턴스를 등록 취소하고 다시 등록하십시오.
    • AWS CodePipeline을 사용하여 AWS CodeBuild를 트리거하여 애플리케이션을 테스트합니다. AWS CodeDeploy의 appspec.yml 파일에서 호출한 bash 스크립트를 사용하여 서비스를 다시 시작합니다. ALB를 사용하여 AWS CodeDeploy 배포 그룹의 인스턴스를 등록 취소하고 다시 등록합니다. 사용자 정의 스크립트 없이 파일 권한을 업데이트하려면 appspec.yml 파일을 업데이트하십시오.
      
      
11. 회사에서 일관성 없는 트래픽이 발생하는 상태 비저장 웹 애플리케이션을 유지 관리합니다. 이 회사는 AWS CloudFormation을 사용하여 애플리케이션을 배포합니다. 애플리케이션은 ALB(Application Load Balancer) 뒤의 Amazon EC2 온디맨드 인스턴스에서 실행됩니다. 인스턴스는 여러 가용 영역에서 실행됩니다.
    
    회사는 애플리케이션의 가용성을 높게 유지하기 위해 적은 수의 온디맨드 인스턴스를 계속 사용하면서 스팟 인스턴스 사용을 포함하려고 합니다.
    
    이러한 요구 사항을 충족하는 가장 비용 효율적인 솔루션은 무엇입니까?
    • AWS CloudFormation 템플릿에 스팟 블록 리소스를 추가합니다. ALB 이면의 단계적 확장과 함께 다양한 할당 전략을 사용합니다.
    • AWS CloudFormation 템플릿에 스팟 블록 리소스를 추가합니다. ALB 뒤의 대상 추적 확장과 함께 최저 가격 할당 전략을 사용합니다.
    • AWS CloudFormation 템플릿에 Spot Fleet 리소스를 추가합니다. ALB 이면의 단계적 확장과 함께 용량 최적화 할당 전략을 사용합니다.
    • AWS CloudFormation 템플릿에 Spot Fleet 리소스를 추가합니다. ALB 뒤에 예정된 확장과 함께 다양한 할당 전략을 사용합니다.
12. 회사는 Amazon CloudWatch Logs에 로그를 저장하는 애플리케이션을 관리합니다. 회사는 로그를 Amazon S3에 보관하려고 합니다. 로그는 90일 이후에는 거의 액세스하지 않으며 10년 동안 보관해야 합니다.
    
    이러한 요구 사항을 충족하기 위해 DevOps 엔지니어가 수행해야 하는 단계 조합은 무엇입니까? (두 가지를 선택하세요.)
    
    • AWS Glue를 사용하여 모든 로그를 S3 버킷으로 전송하도록 CloudWatch Logs 구독 필터를 구성합니다.
    • Amazon Kinesis Data Firehose를 사용하여 모든 로그를 S3 버킷으로 스트리밍하도록 CloudWatch Logs 구독 필터를 구성합니다.
    • 모든 로그를 S3 버킷으로 스트리밍하도록 CloudWatch Logs 구독 필터를 구성합니다.
    • 90일 후에 로그를 S3 Glacier로 전환하고 3.650일 후에 로그를 만료하도록 S3 버킷 수명 주기 정책을 구성합니다.
    • 90일 후에 로그를 감소된 중복으로 전환하고 3.650일 후에 로그를 만료하도록 S3 버킷 수명 주기 정책을 구성합니다.
13. 회사는 직원에게 AWS에 대한 제한된 권한을 부여합니다. DevOps 엔지니어는 관리자 역할을 맡을 수 있습니다. 추적을 위해 보안 팀은 관리자 역할을 맡을 때 거의 실시간으로 알림을 받기를 원합니다.
    
    이것은 어떻게 달성되어야 하는가?
    
    • Amazon S3 버킷에 로그를 게시하도록 AWS Config를 구성합니다. Amazon Athena를 사용하여 로그를 쿼리하고 관리자 역할이 수임되면 보안 팀에 알림을 보냅니다.
    • 관리자 역할이 수임되는 시기를 모니터링하고 보안 팀에 알림을 보내도록 Amazon GuardDuty를 구성합니다.
    • 관리자 역할이 가정된 경우 Amazon SNS 주제에 메시지를 게시하는 AWS Management Console 로그인 이벤트 이벤트 패턴을 사용하여 Amazon EventBridge(Amazon CloudWatch Events) 이벤트 규칙을 생성합니다.
    • 관리자 역할이 수임된 경우 Amazon SNS 주제에 메시지를 게시하는 AWS Lambda 함수를 트리거하기 위해 AWS CloudTrail 이벤트 패턴을 사용하는 AWS API 호출을 사용하여 Amazon EventBridge(Amazon CloudWatch Events) 이벤트 규칙을 생성합니다.
14. 개발 팀은 AWS CodeDeploy 블루/그린 배포를 사용하여 웹 사이트 배포를 관리합니다. 애플리케이션이 Auto Scaling 그룹의 Application Load Balancer 뒤에 있는 Amazon EC2 인스턴스에서 실행 중입니다.
    
    새 버전을 배포할 때 팀은 배포가 결국 실패하지만 실패하는 데 오랜 시간이 걸린다는 사실을 알게 됩니다. 추가 검사 후 팀은 AllowTraffic 수명 주기 이벤트가 한 시간 동안 실행되었고 결국 다른 정보를 제공하지 않고 실패했음을 발견했습니다. 팀은 오류 발생 시에도 애플리케이션 가용성을 유지하면서 오류 알림이 더 빨리 전달되도록 하기를 원합니다.
    
    이러한 요구 사항을 충족하려면 어떤 조합의 조치를 취해야 합니까? (두 가지를 선택하세요.)
    • 모든 인스턴스에 동시에 배포하여 배포 프로세스 속도를 높이려면 배포 구성을 CodeDeployDefault.AllAtOnce로 변경하십시오.
    • 배포 실패 이벤트에 대한 CodeDeploy 트리거를 생성하고 단일 상태 확인 실패가 감지되는 즉시 배포가 실패하도록 합니다.
    • 애플리케이션이 비정상으로 간주되는 데 걸리는 시간을 줄이려면 대상 그룹 상태 확인 내에서 HealthCheckIntervalSeconds 및 UnhealthyThresholdCount 값을 줄입니다.
    • Appspec.yml 파일을 사용하여 AllowTraffic 후크에서 스크립트를 실행하여 CodeDeploy가 대상 그룹 상태 확인이 통과할 때까지 기다리게 하는 대신 애플리케이션에서 더 가벼운 상태 확인을 수행합니다.
    • appspec,yml 파일을 사용하여 BeforeAllowTraffic 후크에서 스크립트를 실행하여 애플리케이션에서 hearth 검사를 수행하고 스크립트에서 수행한 상태 검사가 성공하지 못한 경우 배포에 실패합니다.
15. 한 회사에서 AWS Lambda 권한 부여자를 사용하여 액세스를 제어하는 ​​여러 인터넷 연결 API를 실행하고 있습니다. 보안 팀은 많은 수의 요청이 인증에 실패할 때 알림을 받기를 원합니다. 이는 API 남용을 나타낼 수 있기 때문입니다. API 요청의 규모를 고려할 때 팀은 HTTP 403 Forbidden 응답 수가 전체 API 호출의 2%를 초과하는 경우에만 경고를 받기를 원합니다.
    
    어떤 솔루션이 이를 달성할까요?
    
    • Amazon CloudWatch로 전송된 기본 Amazon API Gateway 403Error 및 Count 지표를 사용하고 지표 수학을 사용하여 CloudWatch 경보를 생성합니다. 알람을 정의할 때 (403Error/Count)*100 수식을 사용하십시오. 알람 임계값을 2보다 크게 설정합니다.
    • Amazon CloudWatch로 전송된 기본 Amazon API Gateway 403Error 및 Count 지표를 가져오는 Lambda 함수를 작성하고 오류 비율을 계산한 다음 Custon403Percent라는 CloudWatch에 사용자 지정 지표를 푸시합니다. 이 사용자 지정 지표를 기반으로 CloudWatch 경보를 생성합니다. 알람 임계값을 2보다 크게 설정합니다.
    • 사용자 지정 액세스 로그를 Amazon CloudWatch Logs로 보내도록 Amazon API Gateway를 구성합니다. Custom403Error라는 HTTP 403 응답 코드에 대한 사용자 지정 메트릭을 생성하는 로그 필터를 만듭니다. 이 사용자 지정 지표와 CloudWatch로 전송된 기본 API 게이트웨이 수 지표를 사용하고 지표 일치를 사용하여 CloudWatch 경보를 생성합니다. 알람을 정의할 때 (Custom403Error/Count)*100 수식을 사용하십시오. 알람 임계값을 2보다 크게 설정합니다.
    • 사용자 지정 Amazon CloudWatch 지표를 활성화하고 ALL_STATUS_CODE 옵션을 활성화하고 APICustom 접두사를 정의하도록 Amazon API Gateway를 구성합니다. CloudWatch 지표 수학을 사용하여 CloudWatch 경보를 생성합니다. 경보를 정의할 때 (APICustom403Error/Count)*100 수식을 사용하십시오. 알람 임계값을 2보다 크게 설정합니다.
16. 회사는 AWS Organizations를 사용하여 여러 계정을 관리합니다. 정보 보안 정책에 따라 암호화되지 않은 모든 Amazon EBS 볼륨은 비준수로 표시되어야 합니다. DevOps 엔지니어는 솔루션을 자동으로 배포하고 이 규정 준수 검사가 항상 존재하는지 확인해야 합니다.
    솔루션을 사용하면 이 작업을 수행할 수 있습니까?
    
    • EBS 암호화가 활성화되었는지 확인하기 위해 AWS Inspector 규칙을 정의하는 AWS CloudFormation 템플릿을 생성합니다. 회사 내 모든 계정과 공유된 Amazon S3 버킷에 템플릿을 저장합니다. Amazon S3의 CloudFormation 템플릿을 가리키는 계정 생성 스크립트를 업데이트합니다.
    • AWS Config 조직 규칙을 생성하여 EBS 암호화가 활성화되었는지 확인하고 AWS CLI를 사용하여 규칙을 배포합니다. 조직 전체에서 AWS Config 중지 및 삭제를 금지하는 SCP를 생성하고 적용합니다.
    • 조직에서 SCP를 만듭니다. 조건식을 사용하여 EBS 볼륨에서 암호화 없이 Amazon EC2 인스턴스를 시작하지 못하도록 정책을 설정합니다. SCP를 모든 AWS 계정에 적용합니다. Amazon Athena를 사용하여 AWS CloudTrail 출력을 분석하고 ec2:RunInstances 작업을 거부하는 이벤트를 찾습니다.
    • 신뢰할 수 있는 단일 계정의 모든 계정에 IAM 역할을 배포합니다. IAM 역할을 맡을 AWS Lambda의 단계가 있는 AWS CodePipeline으로 파이프라인을 구축하고 계정의 모든 EBS 볼륨을 나열합니다. Amazon S3에 보고서를 게시합니다.
17. 회사의 애플리케이션이 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행 중입니다. DevOps 엔지니어는 항상 최소 4개의 애플리케이션 서버가 실행되고 있는지 확인해야 합니다. 애플리케이션을 업데이트해야 할 때마다 엔지니어는 업데이트된 구성으로 새 AMI를 생성하고 새 AMI ID로 AWS CloudFormation 템플릿을 업데이트합니다. 스택이 완료되면 엔지니어는 이전 인스턴스를 하나씩 수동으로 종료하고 진행하기 전에 새 인스턴스가 작동하는지 확인합니다. 엔지니어는 이 프로세스를 자동화해야 합니다.
    
    다음 중 최소 수의 수동 단계를 허용하는 조치는 무엇입니까?
    
    • AutoScalingRollingUpdate 정책과 함께 UpdatePolicy 속성을 포함하도록 CloudFormation 템플릿을 업데이트합니다.
    • AutoScalingReplacingUpdate 정책과 함께 UpdatePolicy 속성을 포함하도록 CloudFormation 템플릿을 업데이트합니다.
    • DevOps 엔지니어가 선택한 인스턴스가 종료되도록 허용하기 전에 Auto Scaling 수명 주기 후크를 사용하여 이전 인스턴스가 작동하는지 확인합니다.
    • Auto Scaling 수명 주기 후크를 사용하여 DevOps 엔지니어가 선택한 인스턴스가 종료되도록 허용하기 전에 최소 4개의 실행 중인 인스턴스가 있는지 확인하십시오.
      
      
18. 한 회사가 AWS Organizations를 사용 중이며 다음 요구 사항으로 거버넌스 전략을 구현하려고 합니다.
    – AWS 리소스 액세스는 모든 계정에 대해 동일한 두 리전으로 제한됩니다.
    – AWS 서비스는 모든 계정에 대해 승인된 특정 서비스 그룹으로 제한됩니다.
    – 인증은 Active Directory에서 제공합니다.
    – 액세스 권한은 직무별로 구성되며 각 계정에서 동일합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    • 리전 및 승인된 서비스를 제한하기 위해 마스터 계정에서 그룹 정책으로 조직 단위(OU)를 설정합니다. AWS CloudFormation StackSets를 사용하여 각 계정의 IAM 자격 증명 공급자 인증을 위한 IAM 신뢰 정책을 포함하여 각 직무에 대한 권한이 있는 역할을 프로비저닝합니다.
    • 마스터 계정에서 권한 경계를 설정하여 리전 및 승인된 서비스를 제한합니다. AWS CloudFormation StackSet를 사용하여 각 계정의 IAM 자격 증명 공급자 인증을 위한 IAM 신뢰 정책을 포함하여 각 직무에 대한 권한이 있는 역할을 프로비저닝합니다.
    • 마스터 계정에서 서비스 제어를 설정하여 리전 및 승인된 서비스를 제한합니다. AWS Resource Access Manager를 사용하여 각 계정의 인증을 위한 AWS SSO를 포함하여 각 직무에 대한 권한이 있는 마스터 계정 역할을 공유합니다.
    • 마스터 계정에서 서비스 제어를 설정하여 리전 및 승인된 서비스를 제한합니다. CloudFormation StackSet를 사용하여 각 계정의 IAM 자격 증명 공급자 인증을 위한 IAM 신뢰 정책을 포함하여 각 직무에 대한 권한이 있는 역할을 프로비저닝합니다.