Exam DevOps

AWS CodeCommit을 사용하여 애플리케이션의 소스 코드를 관리하는 회사가 있습니다. 이 회사는 보안 자격 증명을 코드 리포지토리에 커밋하지 않으려고 합니다.

이를 실현할 수 있는 가장 좋은 방법은 무엇입니까? (1개 선택)

• 자격 증명 스캔을 위해 Lambda 함수를 트리거하는 Amazon CloudWatch Events 규칙을 생성한다. 리포지토리로 푸시가 성공한 후 스캔을 실행하고 자격 증명이 발견될 경우 DevOps 팀에게 알림을 보내는 Amazon SNS 알림을 트리거한다.

• git-secrets를 커밋 전 후크로 설정한다. 보안 자격 증명이 발견되면 커밋이 수행되지 않도록 차단한다.

• 보안 자격 증명을 찾도록 빌드 프로세스를 업데이트한다. AWS CodeBuild가 자격 증명을 발견하면 빌드 작업을 중지하고 조사가 시작될 수 있도록 DevOps 팀에 보고한다.

• AWS CloudTrail 로그를 스캔하도록 AWS Secrets Manager를 구성한다. AWS CodeBuild에 대한 API 호출 중 보안 자격 증명이 포함된 호출이 발견되면 전송을 차단한다.

월 청구 금액이 예상보다 높아진 후 전체 AWS 비용을 줄이라는 업무가 배정되었습니다. 부서에서 식별된 비용 영역 중 하나는 Jenkins에 지출되는 금액입니다.

빌드 환경의 소비 금액을 줄이려면 어떤 작업을 시작해야 합니까? (1개 선택)

• Jenkins 슬레이브를 Auto Scaling 그룹으로 마이그레이션한다. 각 빌드 작업의 상태가 포함된 사용자 지정 Amazon CloudWatch 지표를 생성한다. 작업이 완료되면 Auto Scaling 그룹에 해당 EC2 인스턴스를 다시 축소하라는 알림을 보낸다.

• EC2 플러그인을 Jenkins에 설치한다. 그러면 요청되는 빌드에 따라 EC2 인스턴스가 자동으로 시작되고 종료된다.

• Jenkins를 AWS CodePipeline에 통합한다. AWS CodePipeline은 변경 사항을 푸시하면서 Jenkins에 새 빌드 환경을 생성하고 더 이상 필요하지 않은 빌드 환경을 종료하라는 알림을 보낸다.

• 매일 업무 시작 시간에 새 Jenkins 슬레이브를 구동하는 AWS Lambda 함수를 생성한다. 작업이 완료되면 Jenkins 슬레이브를 종료하는 두 번째 AWS Lambda 함수를 예약한다.

AWS CloudFormation 스택의 리소스를 업데이트하라는 요청을 받았습니다. 업데이트를 시도하자 업데이트가 실패하고 변경 내용을 롤백하자 스택이 UPDATE_ROLLBACK_FAILED 상태로 전환됩니다.

롤백 실패의 가능한 원인은 무엇입니까? (1개 선택)

• 업데이트 과정에서 롤백할 수 없는 새로운 Auto Scaling 그룹이 생성되었습니다.

• 업데이트 과정에서 롤백할 수 없는 빈 Amazon S3 버킷이 생성되었다.

• 스택의 리소스가 AWS CloudFormation 외부에서 변경되었다.

• 스택의 리소스가 축소된 Auto Scaling 그룹의 일부이다.

최근 배포 이후 애플리케이션에서 급격하게 많은 404가 반환되는 문제가 발생했습니다. 이 현상은 고객이 지원 팀에 문제를 알린 후에야 인지되었습니다. 당신은 향후에 이 문제를 잡을 실시간 모니터링 솔루션을 구축하라는 업무를 맡았습니다.

솔루션을 구축하기 위해 취해야 할 단계는 무엇입니까? (3개 선택)

• Amazon CloudWatch Logs 에이전트를 설치하고 관련 로그를 대상으로 지정한다.

• 로그를 zip 파일로 압축한 후 Amazon S3 버킷에 전달하는 CLI 스크립트를 작성한다. 이 스크립트를 cron 작업으로 실행한다.

• Amazon S3에서 로그를 다운로드하고 404를 찾은 후 발견되면 Amazon CloudWatch에 보고하는 Lambda 함수를 생성한다.

• 로그 그룹에 404 오류를 찾는 필터를 생성한다.

• 이러한 데이터 포인트를 바탕으로 상승률을 찾는 Amazon CloudWatch 경보를 생성한다.

개인 건강 정보(PHI)가 포함된 애플리케이션을 설계하는 중입니다. 애플리케이션에 대한 보안 및 규정 준수 요구 사항에 따라 애플리케이션의 모든 보호되는 의료 정보에는 저장 및 전송 시 암호화가 사용되어야 합니다. 이 애플리케이션은 데이터가 로드 밸런서를 통해 이동하고 EBS 볼륨에 저장되어 처리된 후 AWS SDK를 사용하여 Amazon S3에 저장되는 3계층 아키텍처를 사용합니다.

다음 중 보안 요구 사항을 충족하는 두 가지 옵션은 무엇입니까?

(2개 선택)

• 로드 밸런서에 SSL 종료를 사용하고, EC2 인스턴스에 Amazon EBS 암호화를 사용하고, Amazon S3에 서버 측 암호화를 사용한다.

• 로드 밸런서에 SSL 종료와 함께 SAN SSL 인증서를 사용하고, 모든 Amazon EBS 볼륨이 포함된 EC2에 Amazon EBS 암호화를 사용하고, Amazon S3에 고객 관리형 키를 통한 서버 측 암호화를 사용한다.

• 로드 밸런서에 TCP 로드 밸런싱을 사용하고, EC2 인스턴스에 SSL 종료를 사용하고, Amazon EBS 볼륨에 OS 수준 디스크 암호화를 사용하고, Amazon S3에 서버 측 암호화를 사용한다.

• 로드 밸런서에 TCP 로드 밸런싱을 사용하고, EC2 인스턴스에 SSL 종료를 사용하고, Amazon S3에 서버 측 암호화를 사용한다.

• 로드 밸런서에 SSL 종료를 사용하고, EC2 인스턴스에 SSL 수신기를 사용하고, PHI가 포함된 EBS 볼륨에 Amazon EBS 암호화를 사용하고, Amazon S3에 서버 측 암호화를 사용한다.

AWS 계정 관리자가 오늘 퇴사를 했습니다. 관리자에게는 루트 사용자와 개인 IAM 관리자 계정에 액세스할 수 있는 권한이 있었습니다. 관리자는 이러한 계정을 사용하여 다른 IAM 사용자와 키를 생성했습니다.

AWS 인프라를 보호하기 위해 지금 당장 해야 할 일은 무엇입니까?

(3개 선택)

• 암호를 변경하고 루트 사용자에게 MFA를 추가한다.

• 루트 사용자 로그인 시 IP에 제한을 둡니다.

• 키를 교체하고 IAM 사용자의 암호를 변경합니다.

• 모든 IAM 사용자를 삭제한다.

• 관리자의 IAM 사용자를 삭제한다.

당신은 회사의 모든 Amazon EC2 인스턴스에 이후 감사를 위한 태깅 구조를 적용하는 일을 맡았습니다.

회사 전체의 태깅 정책을 준수하지 않는 Amazon EC2 인스턴스를 가능한 빨리 종료하려면 어떤 방법을 사용하는 것이 가장 적합합니까?  (1개 선택)

• EC2 인스턴스에서 규정 미준수 태깅 구조를 확인하는 스크립트를 작성한다. 발견되면 해당 인스턴스를 종료한다. 이 스크립트를 계정 내부의 인스턴스에서 한 시간에 한 번 실행되는 cron 작업으로 예약한다.

• 인프라를 확인하고 규정 미준수 인스턴스를 찾는 AWS Lambda 함수를 생성한다. 정책을 위반한 것으로 밝혀진 인스턴스는 Amazon DynamoDB 테이블에 기록된다. 다른 AWS Lambda 함수를 사용하여 이 Amazon DynamoDB 테이블을 구독하고 여기서 발견되는 인스턴스를 종료한다.

• 규정 미준수 EC2 인스턴스를 찾는 규칙을 AWS Config 안에 구성한다. 발견되면 CloudWatch 이벤트를 사용하여 해당 리소스를 종료하는 사용자 지정 Lambda 함수를 실행한다.

• 필요한 태그로 EC2 인스턴스를 생성할 수 있는 권한만 있는 IAM 사용자를 생성한다. 회사 내부에서 이 계정에만 인스턴스 생성 권한을 부여하는 정책을 시행한다. EC2 인스턴스를 생성하려는 경우 항상 이 계정을 활용한다.

Amazon SQS 대기열의 메시지를 처리하는 인스턴스로 구성된 Auto Scaling 그룹이 있습니다. 이 그룹은 대기열 깊이에 따라 조정됩니다. 처리 작업에는 CPU 사용량이 많고 오래 실행되지만 작은 작업으로 분해하기가 쉽지 않은 작업이 포함됩니다. 그룹을 확장하면 인스턴스가 처리 중에 종료되는 현상이 발생합니다.

완료되지 않은 프로세스 시도의 수를 줄이기 위해 사용할 수 있는 경제적인 솔루션은 무엇입니까? (1개 선택)

• Auto Scaling 그룹의 최소 및 최대 크기를 늘린다. 덜 적극적으로 축소하는 조정 정책으로 변경한다.

• 대기열 깊이에 따라 조정되는 새 Auto Scaling 그룹을 생성한다. 첫 번째 그룹에 메시지가 수신되면 해당 메시지를 두 번째 그룹에 게시하여 처리되도록 한다.

• 인스턴스에서 메시지를 처리하는 동안 EC2 종료를 방지하는 기능을 활성화하고 처리가 완료되면 비활성화한다.

• 메시지를 처리하는 동안 인스턴스를 Auto Scaling Standby 상태로 전환하고 처리가 완료되면 InService 상태로 되돌리도록 애플리케이션을 조정한다.

로드 밸런서 뒤의 Amazon EC2 인스턴스에서 실행되는 웹 서버로 구성된 애플리케이션이 있고, Amazon RDS를 사용 중인 경우

자가 복구 기능이 있는 경제적인 아키텍처를 구현할 때 사용해야 하는 방법은 무엇입니까? (1개 선택)

• UDP ping을 로드 밸런서로 자주 전송하여 비정상 EC2 인스턴스를 확인하고 교체하는 스크립트를 각 EC2 인스턴스에 설정한다.

• Auto Scaling이 적용된 EC2 인스턴스 클러스터에 타사 모니터링 솔루션을 설정하여 사용자 지정 CloudWatch 지표를 바탕으로 비정상 EC2 인스턴스의 종료 및 교체를 트리거한다.

• 웹 서버 계층에 대한 Auto Scaling 시작 구성을 설정하고 이와 함께 Amazon RDS DB CPU 사용률 CloudWatch 지표를 사용하여 EC2 인스턴스를 조정하는 Auto Scaling 정책을 설정한다.

• EC2 인스턴스의 웹 서버 계층에 대한 Auto Scaling 그룹을 설정하고 이와 함께 EC2 CPU 사용률 CloudWatch 지표를 사용하여 인스턴스를 조정하는 Auto Scaling 정책을 설정한다.

• 웹 서버 계층에 더 큰 EC2 인스턴스 유형을 사용하고 데이터 스토리지 계층에 더 큰 DB 인스턴스 유형을 사용하여 비정상 상태가 되는 것을 방지한다.

EC2 리소스와 2개의 S3 버킷이 포함된 Auto Scaling 그룹으로 구성된 애플리케이션이 있습니다. EC2 인스턴스에서는 사용자가 생생한 이미지를 한 S3 버킷에서 다운로드하고 워터마크를 적용한 후 다른 S3 버킷에 사진을 업로드하는 작업이 수행됩니다. Auto Scaling 그룹의 최소 크기는 25이고 최대 크기는 50입니다. 이전 트래픽 패턴을 고려하면 40개 인스턴스를 초과하는 범위로 조정할 수 없습니다. 현재 Auto Scaling 그룹에는 50개의 인스턴스가 있지만 처리되는 이미지의 수는 매우 작습니다. 

이 문제의 근본 원인을 식별하려면 어떻게 해야 합니까? (1개 선택)

• 현재 EC2 아키텍처에 할당되는 역할에 권한 문제가 있는지 꼼꼼히 확인한다. 최근의 IAM 정책 변경이 이 문제의 원인일 수 있다.

• Auto Scaling 그룹 크기를 100으로 늘린다. 이미지가 처리된 후 크기를 다시 50으로 줄인다.

• 애플리케이션 로그를 분석하여 가능한 실패 원인을 찾는다.

• 기존 인스턴스를 종료하고 새 AMI에서 Auto Scaling 그룹을 다시 구축한다.

• CloudTrail을 검토하여 Auto Scaling에서 이미지를 처리하는 데 충분한 리소스를 온라인으로 가져오지 못하게 한 조정 실패가 최근에 있었는지 확인한다.