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

 

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. 회사의 보안 팀이 IAM 액세스 키가 공개 코드 리포지토리에 노출되었음을 발견했습니다. 앞으로 DevOps 팀은 손상된 것으로 의심되는 모든 키를 자동으로 비활성화하고 보안 팀에 알리는 솔루션을 구현하려고 합니다.
   
   어떤 솔루션이 이를 달성할까요?
   
   • Amazon Macie에 대한 Amazon CloudWatch Events 이벤트를 생성합니다. 두 개의 구독이 포함된 Amazon SNS 주제를 생성합니다. 하나는 보안 팀에 알리고 다른 하나는 액세스 키를 비활성화하는 AWS Lambda 함수를 트리거합니다.
   • Amazon GuardDuty를 활성화하고 GuardDuty에 대한 Amazon CloudWatch Events 규칙 이벤트를 설정합니다. 이벤트가 손상된 키와 관련이 있는지 확인하기 위해 AWS Lambda 함수를 트리거합니다. 그렇다면 보안 팀에 알림을 보내고 액세스 키를 비활성화하십시오.
   • 5분마다 AWS CloudWatch Events 규칙을 실행하여 액세스 키에 대한 손상된 태그가 true로 설정되어 있는지 확인하는 AWS Lambda 함수를 호출합니다. 그렇다면 보안 팀에 알리고 액세스 키를 비활성화하십시오.
   • AWS Config를 설정하고 AWS Config에 대한 AWS CloudTrail 이벤트를 생성합니다. 두 개의 구독이 포함된 Amazon SNS 주제를 생성합니다. 하나는 보안 팀에 알리고 다른 하나는 액세스 키를 비활성화하는 AWS Lambda 함수를 트리거합니다.
     
     주의: 이 문제는 이해가 잘 되지 않아서 답만 기억하고 넘겼음. 액세스 키에 대한 손상된 태그는 없음.
     examtopics 링크
     
     
2. 회사에서 글로벌 유휴 암호화 정책을 의무화했습니다. DevOps 엔지니어는 새로운 Amazon S3 버킷과 기존 Amazon S3 버킷 모두에 업로드된 새 데이터가 회사의 AWS Organizations 조직 전체에서 유휴 상태에서 암호화되도록 하는 임무를 받았습니다. Amazon S3를 사용하고 유휴 상태에서 암호화된 데이터를 저장하지 않는 AWS에 배포된 여러 레거시 애플리케이션이 있습니다. 이러한 애플리케이션은 계속 작동해야 합니다. 엔지니어는 애플리케이션 코드를 변경할 필요 없이 조직 전체에서 미사용 S3 암호화를 보장해야 합니다.
   
   최소한의 노력으로 어떻게 달성해야 합니까?
   
   • 지정된 계정의 모든 Amazon S3 버킷을 나열하고 기본 암호화를 활성화하지 않은 모든 S3 버킷 또는 서버 없이 put-object 요청을 명시적으로 거부하지 않는 S3 버킷 정책이 있는 버킷에 기본 암호화를 적용하는 AWS Lambda 함수를 개발합니다. 측면 암호화. AWS CloudFormation StackSets와 함께 Amazon EventBridge(Amazon CloudWatch Events) 예약 규칙과 함께 Lambda 함수를 조직 내의 모든 계정에 배포합니다.
   • S3 기본 암호화가 활성화되지 않은 S3 버킷 또는 서버 없이 put-object 요청을 명시적으로 거부하지 않는 S3 버킷 정책이 있는 버킷을 확인하는 AWS Config s3-bucket-server-side-encryption-enabled 관리형 규칙을 활성화합니다. 측면 암호화. 준수하지 않는 모든 S3 버킷에서 기본 암호화를 활성화하려면 AWS-EnabledS3BucketEncryption 수정 조치를 AWS Config 규칙에 추가하십시오. AWS Config 조직 통합을 사용하여 조직의 모든 계정에 규칙을 배포합니다.
   • x-amz-server-side-encryption S3 조건이 AES 256 값 또는 x-amz-server로 충족되지 않는 한 s3:PutObject에 대한 액세스를 거부하는 버킷 정책이 없는 S3 버킷을 확인하는 AWS Config 사용자 지정 규칙을 활성화합니다. -측 암호화가 없습니다. S3 버킷이 비준수인 경우 버킷 정책을 적용할 AWS Config 규칙에 사용자 지정 교정 작업을 추가합니다. AWS Config 조직 통합을 사용하여 조직의 모든 계정에 규칙을 배포합니다.
   • x-amz-server-side-encryption S3 조건이 AES 256 값과 일치하거나 x-amz-server-side-encryption이 존재하지 않는 한 s3:PutObject에 대한 액세스를 거부하는 SCP를 작성합니다. 조직의 루트에 SCP를 적용하여 조직 전체에 정책을 시행합니다.
     
     설명: AWS Config > s3-bucket-server-side-encryption-enabled
     S3 기본 암호화가 활성화되지 않은 S3 버킷 또는 서버 없이 put-object 요청을 명시적으로 거부하지 않는 S3 버킷 정책이 있는 버킷을 확인하는 AWS Config s3-bucket-server-side-encryption-enabled 관리형 규칙을 활성화합니다.
     
     정리: 서버에서는 무조건 암호화 해야한다. server side encryption enabled 관리형 규칙
3. DevOps 엔지니어가 새 애플리케이션을 위한 다중 지역 재해 복구 솔루션을 지원하고 있습니다. 이 애플리케이션은 Auto Scaling 그룹에서 실행되는 Amazon EC2 인스턴스와 Amazon Aurora MySQL DB 클러스터로 구성됩니다. RTO 120분 및 RPO 60분으로 애플리케이션을 사용할 수 있어야 합니다.
   
   이러한 요구 사항을 충족하는 가장 비용 효율적인 방법은 무엇입니까?
   
   • 다른 리전에서 Aurora DB 클러스터를 Aurora 복제본으로 시작합니다. 모든 컴퓨팅 리소스에 대한 AWS CloudFormation 템플릿을 생성하고 두 리전에 스택을 생성합니다. 장애 발생 시 Aurora 복제본을 기본 인스턴스로 승격하는 스크립트를 작성합니다.
   • 다른 리전에서 Aurora DB 클러스터를 Aurora 복제본으로 시작하고 자동 교차 리전 장애 조치를 구성합니다. Auto Scaling 그룹을 포함하는 AWS CloudFormation 템플릿을 생성하고 두 리전에서 스택을 생성합니다. 인스턴스 수를 늘리기 위해 재해 복구 지역에서 CloudFormation 스택을 업데이트하는 스크립트를 작성합니다.
   • AWS Lambda를 사용하여 Aurora DB 클러스터의 스냅샷을 생성하고 매시간 대상 리전에 복사합니다. Auto Scaling 그룹을 포함하는 AWS CloudFormation 템플릿을 생성하고 두 리전에서 스택을 생성합니다. 스냅샷에서 Aurora DB 클러스터를 복원하고 Auto Scaling 그룹을 업데이트하여 인스턴스 시작을 시작합니다.
   • Amazon DynamoDB 교차 리전 복제를 구성합니다. Auto Scaling 그룹을 포함하는 AWS CloudFormation 템플릿을 생성하고 두 리전에서 스택을 생성합니다. 재해 복구 리전에서 CloudFormation 스택을 업데이트하고 장애 발생 시 DynamoDB 복제본을 기본 인스턴스로 승격하는 스크립트를 작성합니다.
     
     설명: AWS RDS > Amazon Aurora 글로벌 데이터베이스에서 장애 조치 사용
     Aurora 전역 데이터베이스는 Aurora기본 DB 클러스터에서 제공하는 장애 조치보다 더 포괄적인 장애 조치 기능을 제공합니다. Aurora 전역 데이터베이스를 사용하면 재해를 대비히고 신속하게 복구할 수 있습니다. 재해 복구는 일반적으로 RTO 및 RPO 값을 사용하여 측정됩니다.
     
      - RTO(복구 시간 목표, Recovery Time Objective) – 재해 발생 후 시스템이 정상 작동 상태로 돌아가는 데 걸리는 시간입니다. 즉, RTO는 가동 중지 시간을 측정합니다. Aurora 전역 데이터베이스의 경우, RTO는 분 단위가 될 수 있습니다.
     
      - RPO(복구 시점 목표, Recovery Point Objective) – 손실될 수 있는 데이터의 양(시간으로 측정)입니다. Aurora 전역 데이터베이스의 경우, RPO는 일반적으로 초 단위로 측정됩니다. Aurora PostgreSQL–기반 전역 데이터베이스를 사용하면, rds.global_db_rpo 파라미터를 사용하여 RPO에 대한 상한선을 설정하고 추적할 수 있지만, 이렇게 하면 기본 클러스터 라이터 노드에서의 트랜잭션 처리에 영향을 줄 수 있습니다. 자세한 내용은 Aurora PostgreSQL–기반 전역 데이터베이스에 대한 RPO 관리 섹션을 참조하세요.
     
     정리 RTO가 2시간이면 스냅 이야기 나오구 승격이 아닌 복원을 하는구나. 뭐가 비용절감인지 모르겠네.... 장애면 이미 매출 마이너스 아닌가?
      
4. AWS에서 많은 워크로드를 실행하는 회사는 Amazon EBS 지출이 시간이 지남에 따라 증가했습니다. DevOps 팀은 연결되지 않은 EBS 볼륨이 많이 있음을 확인했습니다. 볼륨이 분리된 워크로드가 있지만 14일이 지난 볼륨은 오래되어 더 이상 필요하지 않습니다. DevOps 엔지니어는 14일 동안 연결되지 않은 연결되지 않은 EBS 볼륨을 삭제하는 자동화를 생성하는 임무를 받았습니다.
   
   어떤 솔루션이 이를 달성할까요?
   
   • 구성 변경 트리거 유형 및 Amazon EC2 볼륨 리소스 대상을 사용하여 AWS Config ec2-volume-inuse-check 관리형 규칙을 구성합니다. 지정된 EBS 볼륨을 삭제하기 위해 14일 내에 AWS Lambda 함수를 실행하도록 예약된 새 Amazon CloudWatch Events 규칙을 생성합니다.
   • Amazon EC2 및 Amazon Data Lifecycle Manager를 사용하여 볼륨 수명 주기 정책을 구성합니다. 연결되지 않은 EBS 볼륨의 간격을 14일로 설정하고 보관 규칙을 삭제하도록 설정합니다. 정책 대상 볼륨을 *로 설정합니다.
   • 매일 AWS Lambda 함수를 실행하는 Amazon CloudWatch Events 규칙을 생성합니다. Lambda 함수는 연결되지 않은 EBS 볼륨을 찾아 현재 날짜로 태그를 지정하고 14일 이상 된 날짜가 있는 태그가 있는 연결되지 않은 볼륨을 삭제해야 합니다.
   • AWS Trusted Advisor(비용 절감, 성능 향상 및 보안 강화)를 사용하여 14일 이상 분리된 EBS 볼륨을 감지합니다. 스냅샷을 생성한 다음 EBS 볼륨을 삭제하는 AWS Lambda 함수를 실행합니다.
     
     설명: AWS Trusted Advisor은 검사만 한다. 삭제 실행은 AWS Lambda 함수를 이용해야함.
     스케줄(이벤트) -> Lambda(실행 및 처리)
     ====> 배치작업 생성이네.
5. DevOps 엔지니어가 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 실행되는 새 애플리케이션에 대한 배포 문제를 해결하고 있습니다. 인스턴스는 여러 가용 영역에 걸쳐 EC2 Auto Scaling 그룹에서 실행됩니다. 때때로 인스턴스가 준비되기 전에 온라인 상태가 되어 사용자 간의 오류율이 증가합니다. 현재 상태 확인 구성은 인스턴스에 60초의 유예 기간을 제공하고 배포 프로세스 중에 간헐적으로 응답할 수 있는 페이지인 /index.php의 200 응답 코드 2개 후에 인스턴스가 정상이라고 간주합니다. 개발 팀은 인스턴스가 가능한 한 빨리 온라인 상태가 되기를 원합니다.
   
   이 문제를 해결하는 전략은 무엇입니까?
   
   • 인스턴스 유예 기간을 60초에서 180초로 늘리고 연속 상태 확인 요구 사항을 2에서 3으로 늘립니다.
   • 인스턴스 유예 기간을 60초에서 120초로 늘리고 응답 코드 요구 사항을 200에서 204로 변경합니다.
   • 배포가 시작될 때 /health-check.php 파일을 생성하도록 배포 스크립트를 수정한 다음 해당 파일을 가리키도록 상태 확인 경로를 수정합니다.
   • 모든 작업이 완료되면 배포 스크립트를 수정하여 /health-check.php 파일을 생성한 다음 해당 파일을 가리키도록 상태 확인 경로를 수정합니다.
     
     설명: Elastic Load Balancing > 상태 확인 설정
     다음 설정을 사용하여 대상 그룹의 대상에 대한 활성 상태 확인을 구성합니다. 상태 확인이 UnhealthyThresholdCount 연속 실패를 초과하면 로드 밸런서는 대상을 서비스에서 제외합니다. 상태 확인이 HealthyThresholdCount 연속 성공을 초과하면 로드 밸런서는 대상을 다시 서비스 상태로 전환합니다.
     
     정리: 헬스체크를 잘하자는 이야기!! 402로도 헬스체크 가능하지. 정하기 나름이니. 인증이 안되어지만, 대답은 하잖아.
     
     
6. DevOps 팀은 Amazon API Gateway 엔드포인트의 백엔드 역할을 하는 온프레미스에서 실행되는 API를 관리합니다. 고객은 높은 응답 지연 시간에 대해 불평해 왔으며 개발 팀은 Amazon CloudWatch의 API 게이트웨이 지연 시간 지표를 사용하여 이를 확인했습니다. 원인을 파악하기 위해 팀은 추가 대기 시간 없이 관련 데이터를 수집해야 합니다.
   
   이를 달성하기 위해 어떤 조치를 취해야 합니까? (두 가지를 선택하세요.)
   
   • CloudWatch 에이전트 서버 측을 설치하고 관련 로그를 CloudWatch에 업로드하도록 에이전트를 구성합니다.
   • API Gateway에서 AWS X-Ray 추적을 활성화하고, 요청 세그먼트를 캡처하도록 애플리케이션을 수정하고, 각 요청 중에 해당 세그먼트를 X-Ray에 업로드합니다.
   • API Gateway에서 AWS X-Ray 추적을 활성화하고, 요청 세그먼트를 캡처하도록 애플리케이션을 수정하고, X-Ray 데몬을 사용하여 X-Ray에 세그먼트를 업로드합니다.
   • 요청이 있을 때마다 로그 정보를 API Gateway로 다시 보내도록 온프레미스 애플리케이션을 수정합니다.
   • API 서비스 요청과 관련된 통계 데이터를 계산하고 CloudWatch 지표에 업로드하도록 온프레미스 애플리케이션을 수정합니다.
     
     설명: 
     지연률을 체크하고, 관련된 로그분석을 위해 CloudWatch 에이전트를 활용하여 로그수집을 해야한다.
     
     AWS X-Ray > AWSX-Ray를 사용하여 REST API에 대한 사용자 요청 추적
     X-Ray는 전체 요청에 대한 종단 간 보기를 제공하므로 API 및 해당 백엔드 서비스의 지연 시간을 분석할 수 있습니다. X-Ray 서비스 맵을 사용하여 전체 요청의 지연 시간과 X-Ray와 통합된 다운스트림 서비스의 지연 시간을 볼 수 있습니다. 또한 지정한 기준에 따라 기록할 요청과 샘플링 속도를 X-Ray에 알리도록 샘플링 규칙을 구성할 수도 있습니다.
     
     AWS X-Ray > AWS X-Ray로 추적 데이터 전송
     {
       "name" : "Scorekeep",
       "id" : "70de5b6f19ff9a0a",
       "start_time" : 1.478293361271E9,
       "trace_id" : "1-581cf771-a006649127e371903a2de979",
       "end_time" : 1.478293361449E9
     }
     요청이 수신되면 요청이 완료될 때까지 진행률 세그먼트를 자리 표시자로 전송할 수 있습니다.
     
     정리: 지연 시간 지표를 어떻게 얻을 것인가? 
     CloudWatch 에이전트 설치, AWS X-Ray로 추적 지표를 얻는다.
     
7. 데브옵스 팀은 AWS CloudFormation을 사용하여 인프라를 구축합니다. 보안 팀은 비밀번호와 같은 민감한 매개변수가 노출되는 것을 우려하고 있습니다.
   
   AWS CloudFormation의 보안을 강화하는 단계 조합은 무엇입니까? (3개를 선택하세요.)
   
   • AWS KMS로 보안 문자열을 생성하고 KMS 암호화 키를 선택합니다. 보안 문자열의 ARN을 참조하고 암호 해독을 위해 AWS CloudFormation에 KMS 키에 대한 권한을 부여합니다.
   • AWS Secrets Manager AWS::SecretsManager::Secret 리소스 유형을 사용하여 암호를 생성합니다. Amazon RDS 데이터베이스와 같이 암호가 필요한 리소스에서 비밀 리소스 반환 속성을 참조하십시오.
   • 민감한 정적 데이터를 AWS Systems Manager Parameter Store에 안전한 문자열로 저장하십시오. 데이터에 액세스해야 하는 리소스에서 동적 참조를 사용합니다.
   • AWS Systems Manager Parameter Store에 민감한 정적 데이터를 문자열로 저장합니다. Systems Manager 매개변수 유형을 사용하여 저장된 값을 참조하십시오.
   • AWS KMS를 사용하여 CloudFormation 템플릿을 암호화합니다.
   • CloudFormation NoEcho 매개변수 속성을 사용하여 매개변수 값을 마스킹합니다.
     설명: NoEcho
     매개변수 값이 콘솔, 명령줄 도구 또는 API에 표시되지 않도록 마스크할지 여부입니다. NoEcho 속성을 로  설정하면  trueCloudFormation은 아래 지정된 위치에 저장된 정보를 제외하고 스택 또는 스택 이벤트를 설명하는 모든 호출에 대해 별표(*****)로 마스킹된 매개변수 값을 반환합니다.
     
     정리: 비번은 암호화하고, 중요한 것은 따로 안전하게 보관하고, 보이더라도 마스킹해야함
     
     
8. 회사는 EC2 인스턴스가 안전한지 확인하려고 합니다. 인스턴스에서 새로운 취약점이 발견되면 알림을 받고 인스턴스의 모든 로그인 활동에 대한 감사 추적도 원합니다.
   
   이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
   
   • AWS Systems Manager를 사용하여 EC2 인스턴스의 취약성을 감지합니다. Amazon Kinesis 에이전트를 설치하여 시스템 로그를 캡처하고 Amazon S3에 전달하십시오.
   • AWS Systems Manager를 사용하여 EC2 인스턴스의 취약성을 감지합니다. CloudTrail 콘솔에서 시스템 로그를 캡처하고 로그인 활동을 보려면 Systems Manager Agent를 설치하십시오.
   • EC2 인스턴스의 취약성을 감지하도록 Amazon CloudWatch를 구성합니다. 시스템 로그를 캡처하고 AWS Config 콘솔에서 보려면 AWS Config 데몬을 설치하십시오.
   • EC2 인스턴스의 취약성을 감지하도록 Amazon Inspector를 구성합니다. Amazon CloudWatch 에이전트를 설치하여 시스템 로그를 캡처하고 Amazon CloudWatch Logs를 통해 기록하십시오.
     
     설명: Amazon Inspector == 지속적인 자동 취약성 관리
      - AWS 워크로드에서 소프트웨어 취약성과 의도하지 않은 네트워크 노출을 즉시 발견하고 스캔한다.
      - Amazon EC2, AWS Lambda 함수 및 Amazon ECR의 컨테이너 이미지에 대한 취약성 관리 솔루션을 하나의 완전관리형 서비스로 통합한다.
      - Inspector 위험 점수를 사용하여 문제 해결의 우선순위를 지정할 수 있다.
     
     정리: 취약점은 inspector(조사관)이 추적한다. 
     
     
9. 개발 팀은 AWS CodeCommit을 사용하여 애플리케이션 코드의 버전을 제어하고 AWS CodePipeline을 사용하여 소프트웨어 배포를 조정하고 있습니다. 팀은 원격 마스터 분기를 파이프라인의 트리거로 사용하여 코드 변경 사항을 통합하기로 결정했습니다. 개발자가 CodeCommit 리포지토리에 코드 변경 사항을 푸시했지만 파이프라인이 10분 후에도 반응이 없음을 확인했습니다.
   
   이 문제를 해결하려면 다음 중 어떤 조치를 취해야 합니까?
   
   • 마스터 브랜치가 파이프라인을 트리거하도록 Amazon CloudWatch Events 규칙이 생성되었는지 확인합니다.
   • CodePipeline 서비스 역할에 CodeCommit 리포지토리에 액세스할 수 있는 권한이 있는지 확인하십시오.
   • 개발자의 IAM 역할에 CodeCommit 리포지토리에 푸시할 수 있는 권한이 있는지 확인하십시오.
   • Amazon CloudWatch Logs의 CodeCommit 오류로 인해 파이프라인이 시작되지 않았는지 확인하십시오.
     
     설명: 권한이 없는 경우 Auth관련 오류 발생한다. 반응이 없는 경우는 이벤트의 연결을 의심해야한다.
     Amazon CloudWatch Logs를 사용하여 로그 파일을 모니터링, 저장 및 액세스할 수 있습니다. CloudTrail 및 기타 소스의 데이터가 포함됩니다. CloudWatch 로그는 로그 파일의 정보를 모니터링하고 특정 임계값에 도달하면 사용자에게 알릴 수 있습니다. Amazon CloudWatch Logs과 CodeCommit은 연관성이 없다.
     CloudWatch Events는 변경 사항을 설명하는 시스템 이벤트의 스트림을 거의 실시간으로 제공합니다.
     
     정리: 스캐줄이 안걸렸네.
10. 회사에는 하나의 AWS 계정을 공유하는 여러 개발 팀이 있습니다. 개발 팀의 관리자는 리소스가 유휴 상태이고 프로덕션 리소스로 태그가 지정되지 않은 경우 Amazon EC2 인스턴스를 자동으로 중지하고 알림을 받을 수 있기를 원합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    
    • 예약된 Amazon CloudWatch Events 규칙을 사용하여 Amazon EC2 인스턴스 상태 확인을 필터링하고 유휴 EC2 인스턴스를 식별합니다. CloudWatch 이벤트 규칙을 사용하여 AWS Lambda 함수를 대상으로 지정하여 비프로덕션 인스턴스를 중지하고 알림을 보냅니다.
    • 예약된 Amazon CloudWatch Events 규칙을 사용하여 AWS Systems Manager 이벤트를 필터링하고 유휴 EC2 인스턴스 및 리소스를 식별합니다. CloudWatch 이벤트 규칙을 사용하여 AWS Lambda 함수를 대상으로 지정하여 비프로덕션 인스턴스를 중지하고 알림을 보냅니다.
    • 예약된 Amazon CloudWatch Events 규칙을 사용하여 AWS Trusted Advisor(비용 절감, 성능 향상 및 보안 강화) 검사를 실행하는 사용자 지정 AWS Lambda 함수를 대상으로 지정합니다. 유휴 비프로덕션 인스턴스를 중지하고 알림을 보내는 Lambda 함수를 트리거하기 위해 Trusted Advisor의 이벤트를 필터링하는 두 번째 CloudWatch 이벤트 규칙을 생성합니다.
    • 예약된 Amazon CloudWatch Events 규칙을 사용하여 유휴 EC2 인스턴스에 대한 Amazon Inspector 이벤트를 대상으로 지정합니다. CloudWatch 이벤트 규칙을 사용하여 AWS Lambda 함수를 대상으로 지정하여 비프로덕션 인스턴스를 중지하고 알림을 보냅니다.
      
      설명: AWS Trusted Advisor는 AWS 환경을 검사한 다음 비용을 절감하거나 시스템 가용성 및 성능을 개선하거나 보안 격차를 해소할 수 있는 기회가 있을 때 권장 사항을 제시합니다.
      
      정리: 꽁으로 돌고 있는 자원은 다 돈이니, 비용절감을 위해서 Trusted Advisor(믿을 만한 조언자)에게 도움받아야함.
      
      
11. 회사에서 공개용 소프트웨어를 AWS로 마이그레이션하고 있습니다. 이 회사는 Amazon EC2를 사용하여 애플리케이션 코드를 실행하고 Amazon RDS를 사용하여 모든 애플리케이션 데이터를 저장할 계획입니다. 이 회사는 트래픽을 라우팅하기 위해 보조 리전 및 Amazon Route 53에 대한 장애 조치 기능이 있는 한 리전을 주로 사용하려고 합니다. RPO는 2시간이고 RTO는 4시간입니다.
    
    비용을 최소화하면서 이러한 요구 사항을 충족하려면 어떤 단계 조합을 사용해야 합니까? (3개를 선택하세요.)
    
    • 단일 리전에서 애플리케이션 서버 및 데이터베이스 인스턴스를 프로비저닝할 AWS CloudFormation 템플릿을 생성합니다.
    • 애플리케이션의 애플리케이션 계층과 다중 리전 데이터베이스 인스턴스를 프로비저닝할 AWS CloudFormation 템플릿을 생성합니다.
    • 매시간 실행되도록 Amazon CloudWatch Events 규칙을 구성합니다. AWS Lambda 함수를 트리거하여 RDS 스냅샷을 생성하고 보조 리전에 복사합니다.
    • 3시간마다 실행되도록 Amazon CloudWatch Events 규칙을 구성합니다. AWS Lambda 함수를 트리거하여 RDS 스냅샷을 생성하고 보조 리전에 복사합니다.
    • 장애 발생 시 새 AWS CloudFormation 스택을 보조 리전에 배포하여 복사된 스냅샷과 Route 53 장애 조치 라우팅 정책을 사용하여 애플리케이션 리소스와 새 RDS 인스턴스를 프로비저닝합니다.
    • 장애가 발생한 경우 새 AWS CloudFormation 스택을 보조 리전에 배포하여 복사된 스냅샷과 Route 53 지연 시간 기반 라우팅 정책을 사용하여 애플리케이션 리소스와 RDS 데이터베이스의 복제본을 프로비저닝합니다.
      
      정리: AWS CloudFormation 템플릿 => 다른 리전에도 똑같이 만들기 위해 필요.
      RPO는 2시간을 위해 스케줄(이벤트) 구성 필요.
      RTO는 4시간인 장애가 발생하면 스냅샷으로 복원함.
      
      
12. DevOps 엔지니어는 온프레미스에서 AWS로 애플리케이션을 마이그레이션하기 위한 솔루션을 찾고자 합니다. 애플리케이션이 Linux에서 실행 중이며 제대로 작동하려면 특정 버전의 Apache Tomcat, HAProxy 및 Varnish Cache에서 실행해야 합니다. 애플리케이션의 운영 체제 수준 매개변수는 조정이 필요합니다. 솔루션에는 새 애플리케이션 버전의 배포를 자동화하는 방법이 포함되어야 합니다. 인프라는 확장 가능해야 하며 결함이 있는 서버는 자동으로 교체되어야 합니다.
    
    DevOps 엔지니어는 어떤 솔루션을 사용해야 합니까? 
    • 필요한 모든 소프트웨어가 포함된 Docker 이미지로 애플리케이션을 Amazon ECR에 업로드합니다. AWS Fargate 시작 유형 및 Auto Scaling 그룹을 사용하여 Amazon ECS 클러스터를 생성합니다. Amazon ECR을 소스로 사용하고 Amazon ECS를 배포 공급자로 사용하는 AWS CodePipeline 파이프라인을 생성합니다.
    • 애플리케이션 코드를 저장된 구성 파일과 함께 AWS CodeCommit 리포지토리에 업로드하여 소프트웨어를 구성하고 설치합니다. AWS Elastic Beanstalk 웹 서버 티어와 Tomcat 솔루션 스택을 사용하는 부하 분산형 환경을 생성합니다. CodeCommit을 소스로 사용하고 Elastic Beanstalk를 배포 공급자로 사용하는 AWS CodePipeline 파이프라인을 생성합니다.
    • .ebextensions 파일 세트와 함께 애플리케이션 코드를 AWS CodeCommit 리포지토리에 업로드하여 소프트웨어를 구성 및 설치합니다. Tomcat 솔루션 스택을 사용하는 AWS Elastic Beanstalk 작업자 계층 환경을 생성합니다. CodeCommit을 소스로 사용하고 Elastic Beanstalk를 배포 공급자로 사용하는 AWS CodePipeline 파이프라인을 생성합니다.
    • 애플리케이션 코드를 appspec.yml 파일과 함께 AWS CodeCommit 리포지토리에 업로드하여 필요한 소프트웨어를 구성하고 설치합니다. Amazon EC2 Auto Scaling 그룹과 연결된 AWS CodeDeploy 배포 그룹을 생성합니다. CodeCommit을 소스로 사용하고 CodeDeploy를 배포 공급자로 사용하는 AWS CodePipeline 파이프라인을 생성합니다.
      
      설명: Amazon ECR > Docker 이미지 푸시
      특증 솔루션을 사용하기 위해서는 이를 적용한 docker 이미지를 생성하고 docker push 명령을 사용하여 컨테이너 이미지를 Amazon ECR 리포지토리로 푸시해야 한다.
      
      정리: 최신은 보통 기본 이미지에 저장되니, 개별적인 것은 개별적으로 Docker 이미지 만들어야 함.
      
      
13. 회사에서 인프라 배포를 위해 AWS CloudFormation을 사용하려고 합니다. 이 회사는 엄격한 태깅 및 리소스 요구 사항이 있으며 배포를 두 지역으로 제한하려고 합니다. 개발자는 동일한 애플리케이션의 여러 버전을 배포해야 합니다.
    
    회사 정책에 따라 리소스가 배포되도록 보장하는 솔루션은 무엇입니까?
    
    • 승인되지 않은 CloudFormation StackSets를 찾아 수정하는 AWS Trusted Advisor 검사를 생성합니다.
    • CloudFormation 드리프트 감지 작업을 생성하여 승인되지 않은 CloudFormation StackSets를 찾아 수정합니다.
    • 승인된 CloudFormation 템플릿으로 CloudFormation StackSets를 생성합니다.
    • 승인된 CloudFormation 템플릿을 사용하여 AWS Service Catalog 제품을 생성합니다.
      
      설명:  AWS CloudFormation > AWS CloudFormation StackSets
      스택 세트를 사용하면 단일 CloudFormation 템플릿을 사용하여 여러 리전에 대해 AWS 계정에서 스택을 생성할 수 있습니다. 스택 세트의 CloudFormation 템플릿은 각 스택의 모든 리소스를 정의합니다. 스택 세트를 생성할 때 템플릿에 필요한 파라미터 및 기능에 더해 사용할 템플릿을 지정합니다.
      
      스택 세트를 정의하면 지정한 대상 계정과 AWS 리전에서 스택을 생성, 업데이트 또는 삭제할 수 있습니다. 스택을 생성, 업데이트 또는 삭제할 때 작업 기본 설정을 지정할 수도 있습니다. 예를 들어 작업을 수행하려는 리전의 순서, 스택 작업이 중지되기 전의 내결함성 임계값, 스택 작업을 동시에 수행하는 계정 수를 포함시킵니다.
      
      스택 세트는 리전 리소스입니다. 한 AWS 리전에서 스택 세트를 생성하면 해당 리전을 볼 때만 보거나 스택 세트를 변경할 수 있습니다.
      
      
14. 회사에서 Amazon EC2 인스턴스를 사용하는 새 애플리케이션을 배포하고 있습니다. 회사는 애플리케이션 로그 및 AWS 계정 API 활동을 쿼리하기 위한 솔루션이 필요합니다.
    
    이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    
    • Amazon CloudWatch 에이전트를 사용하여 EC2 인스턴스에서 Amazon CloudWatch Logs로 로그를 전송합니다. API 로그를 Amazon S3에 전달하도록 AWS CloudTrail을 구성합니다. CloudWatch를 사용하여 두 로그 세트를 모두 쿼리합니다.
    • Amazon CloudWatch 에이전트를 사용하여 EC2 인스턴스에서 Amazon CloudWatch Logs로 로그를 전송합니다.
      CloudWatch Logs에 API 로그를 전달하도록 AWS CloudTrail을 구성합니다. CloudWatch Logs Insights를 사용하여 두 로그 세트를 쿼리합니다.
    • Amazon CloudWatch 에이전트를 사용하여 EC2 인스턴스에서 Amazon Kinesis로 로그를 전송합니다. Kinesis에 API 로그를 전달하도록 AWS CloudTrail을 구성합니다. Kinesis를 사용하여 데이터를 Amazon Redshift로 로드합니다. Amazon Redshift를 사용하여 두 로그 세트를 쿼리합니다.
    • Amazon CloudWatch 에이전트를 사용하여 EC2 인스턴스에서 Amazon S3로 로그를 보냅니다. AWS CloudTrail을 사용하여 API 로그를 Amazon S3 Amazon S3에 전달합니다. Amazon Athena를 사용하여 Amazon S3에서 두 로그 세트를 모두 쿼리합니다.
      
      설명: CloudWatch와 CloudTrail의 차이점
      이 문제의 핵심은 "AWS에서 누가 무엇을 했습니까?"와 "AWS에서 무슨 일이 일어나고 있습니까?"에 대한 모니터링 방법을 구분하는 것이다.
      
      CloudWatch는 AWS 서비스 및 리소스의 활동에 중점을 두고 상태 및 성능을 보고합니다.
      AWS CloudWatch는 AWS 클라우드 리소스 및 AWS에서 실행하는 애플리케이션에 대한 모니터링 서비스입니다. Amazon CloudWatch를 사용하여 지표를 수집 및 추적하고, 로그 파일을 수집 및 모니터링하고, 경보를 설정하고, AWS 리소스의 변경 사항에 자동으로 대응할 수 있습니다.
      과정정리: EC2에 log Agent 설치 -> CloudWatch Logs -> CloudWatch Metrics -> CloudWatch Alarm -> SNS
      
      CloudTrail은 AWS 환경 내에서 발생한 모든 작업의 ​​로그입니다.
      WS CloudTrail은 AWS 계정의 거버넌스, 규정 준수, 운영 감사 및 위험 감사를 지원하는 서비스입니다. CloudTrail을 사용하면 AWS 인프라 전체에서 작업과 관련된 계정 활동을 기록하고 지속적으로 모니터링하고 유지할 수 있습니다. CloudTrail은 AWS Management Console, AWS SDK, 명령줄 도구 및 기타 AWS 서비스를 통해 수행된 작업을 포함하여 AWS 계정 활동의 이벤트 기록을 제공합니다. 이 이벤트 기록은 보안 분석, 리소스 변경 추적 및 문제 해결을 단순화합니다.
      
      AWS CloudTrail을 사용하여 Amazon EC2, Amazon EBS 및 Amazon VPC API 호출 로깅
       CloudTrail은 콘솔의 호출과 API에 대한 코드 호출을 포함하여 Amazon EC2, Amazon EBS 및 Amazon VPC에 대한 모든 API 호출을 이벤트로 캡처합니다. 추적을 생성하면 Amazon EC2, Amazon EBS 및 Amazon VPC에 대한 이벤트를 포함하여 CloudTrail 이벤트를 Amazon S3 버킷으로 지속적으로 전달할 수 있습니다.
      
      CloudTrail 이벤트 기록에서 이벤트 보기를 통해 AWS 계정 API 활동을 확인할 수 있다.
      CloudTrail 콘솔에서 Event history(이벤트 기록)를 확인하여 운영 및 보안 인시던트 문제를 해결할 수 있습니다. Event history(이벤트 기록)는 AWS 리전에서 지난 90일간 기록된 API 활동(관리 이벤트)에 대한 읽기 전용 보기를 제공합니다.
      
      
15. 회사는 내부용 웹 애플리케이션의 가용성이 높아야 합니다. 이 아키텍처는 하나의 Amazon EC2 웹 서버 인스턴스와 업데이트 및 공개 데이터 액세스를 위한 아웃바운드 인터넷 액세스를 제공하는 하나의 NAT 인스턴스로 구성됩니다.
    
    고가용성을 달성하기 위해 회사에서 구현해야 하는 아키텍처 조정 조합은 무엇입니까? (두 가지를 선택하세요.)
    
    • 여러 가용 영역에 걸쳐 있는 EC2 Auto Scaling 그룹에 NAT 인스턴스를 추가합니다. 경로 테이블을 업데이트합니다.
    • 여러 가용 영역에 걸쳐 있는 추가 EC2 인스턴스를 생성합니다. Application Load Balancer를 추가하여 로드를 분할합니다.
    • EC2 인스턴스 앞에 Application Load Balancer를 구성합니다. 호스트 장애 시 EC2 인스턴스를 복구하도록 Amazon CloudWatch 경보를 구성합니다.
    • 각 가용 영역에서 NAT 인스턴스를 NAT 게이트웨이로 교체합니다. 경로 테이블을 업데이트합니다.
    • NAT 인스턴스를 여러 가용 영역에 걸쳐 있는 NAT 게이트웨이로 교체합니다. 경로 테이블을 업데이트합니다.
      
      설명: Amazon VPC > NAT 게이트웨이 및 NAT 인스턴스 비교
      NAT 게이트웨이는 더 나은 가용성과 대역폭을 제공하고 관리에 소요되는 작업이 줄어들기 때문에 권장합니다. 고가용성을 추구하며, 각 가용 영역의 NAT 게이트웨이는 중복적으로 구현됩니다. 각 가용 영역에 하나의 NAT 게이트웨이를 만들어 아키텍처가 영역에 종속되지 않도록 합니다.
      
      
16. 회사는 개인 정보 보호 계약에 대한 사용자 동의를 수집해야 합니다. 이 회사는 6개의 AWS 리전(북미 2개 리전, 유럽 2개 리전, 아시아 2개 리전)에 애플리케이션을 배포합니다. 이 애플리케이션은 2천만에서 3천만 명의 사용자 기반을 가지고 있습니다.
    
    회사는 각 사용자의 응답과 관련된 데이터를 읽고 써야 합니다. 회사는 또한 응답이 6개 지역 모두에서 사용 가능한지 확인해야 합니다.
    
    가장 낮은 읽기 및 쓰기 대기 시간으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
    • 6개 리전 각각에 Amazon Elasticsearch Service(Amazon ES)를 구현합니다.
    • 6개 리전 각각에서 Amazon DocumentDB(MongoDB와 호환)를 구현합니다.
    • 6개 리전 각각에 Amazon DynamoDB 전역 테이블을 구현합니다.
    • 6개 리전 각각에서 Redis용 Amazon ElastiCache 복제 그룹을 구현합니다.
      
      설명: RDS는 기본 리전에 종속되어 있습니다. 이를 극복할 수 있는 솔루션은 전역테이블 - DynamoDB용 다중 리전 복제이다.
      Amazon DynamoDB 글로벌 테이블은 대규모 글로벌 애플리케이션을 위해 빠르고 현지화된 읽기 및 쓰기 성능을 제공하는 완전관리형 다중 리전 다중 활성 데이터베이스 옵션입니다. 전역 테이블은 자체 복제 솔루션을 구축 및 유지 관리할 필요 없이 다중 리전, 다중 활성 데이터베이스를 배포하기 위한 완전 관리형 솔루션을 제공하여 DynamoDB는 진행 중인 데이터 변경 사항을 모든 리전으로 전파합니다.
      
      
17. 한 회사에서 중요한 비즈니스 애플리케이션에 대한 AWS CloudFormation 템플릿을 업데이트했습니다. 업데이트된 템플릿의 오류로 인해 스택 업데이트 프로세스가 실패했으며 AWS CloudFormation이 자동으로 스택 롤백 프로세스를 시작했습니다. 나중에 DevOps 엔지니어는 애플리케이션을 여전히 사용할 수 없고 스택이 UPDATE_ROLLBACK_FAILED 상태에 있음을 발견했습니다.
    
    스택 롤백이 성공적으로 완료될 수 있도록 DevOps 엔지니어가 수행해야 하는 작업 조합은 무엇입니까? (두 가지를 선택하세요.)
    
    • AWSCloudFormationFullAccess IAM 정책을 AWS CloudFormation 역할에 연결합니다.
    • AWS CloudFormation 드리프트 감지를 사용하여 스택 리소스를 자동으로 복구합니다.
    • AWS CloudFormation 콘솔 또는 AWS CLI에서 ContinueUpdateRollback 명령을 실행합니다.
    • 스택의 기대치에 맞게 리소스를 수동으로 조정합니다.
    • 원본 템플릿을 사용하여 기존 AWS CloudFormation 스택을 업데이트합니다.
      
      설명: AWS CloudFormation > ContinueUpdateRollback
      AWS CloudFormation이 스택 업데이트 실패 후 모든 변경 사항을 롤백할 수 없는 경우 스택이 UPDATE_ROLLBACK_FAILED 상태가 됩니다. 예를 들어 AWS CloudFormation 외부에서 삭제된 이전 데이터베이스 인스턴스로 롤백되는 스택이 있을 수 있습니다. AWS CloudFormation은 데이터베이스가 삭제된 것을 모르기 때문에 데이터베이스 인스턴스가 여전히 존재한다고 가정하고 롤백을 시도하여 업데이트 롤백이 실패합니다.
      
      UPDATE_ROLLBACK_FAILED 상태 에 있는 지정된 스택의 경우 UPDATE_ROLLBACK_COMPLETE상태로 계속 롤백합니다. 실패 원인에 따라 수동으로 오류를 수정 하고 롤백을 계속할 수 있습니다. 롤백을 계속하면 스택을 작동 상태(상태 UPDATE_ROLLBACK_COMPLETE)로 되돌린 다음 스택 업데이트를 다시 시도할 수 있습니다.
      
      
18. 회사에는 AWS Organizations의 조직에 속하는 여러 하위 계정이 있습니다. 보안 팀은 모든 Amazon EC2 보안 그룹과 해당 인바운드 및 아웃바운드 규칙을 검토해야 합니다. 보안 팀은 조직의 마스터 계정에서 AWS Lambda 함수를 사용하여 하위 계정에서 프로그래밍 방식으로 이 정보를 검색하려고 합니다.
    
    이러한 요구 사항을 충족하는 액세스 변경 조합은 무엇입니까? (3개를 선택하세요.)
    
    • 하위 계정의 사용자가 마스터 계정 IAM 역할을 맡을 수 있도록 신뢰 관계를 만듭니다.
    • 마스터 계정의 사용자가 하위 계정의 IAM 역할을 맡을 수 있도록 신뢰 관계를 생성합니다.
    • AmazonEC2ReadOnlyAccess 관리형 정책에 대한 액세스 권한이 있는 각 하위 계정에서 IAM 역할을 생성합니다.
    • 각 하위 계정에서 IAM 역할을 생성하여 마스터 계정 IAM 역할의 ARN에 대해 sts:AssumeRole 작업을 허용합니다.
    • 하위 계정 IAM 역할의 ARN에 대해 sts:AssumeRole 작업을 허용하는 마스터 계정에서 IAM 역할을 생성합니다.
    • AmazonEC2ReadOnlyAccess 관리형 정책에 대한 액세스 권한이 있는 마스터 계정에서 IAM 역할을 생성합니다.
      
      설명: AWS Organizations란 무엇인가요?
      AWS Organizations은 생성한 여러 AWS 계정을 조직에 통합하고 중앙에서 관리할 수 있는 계정 관리 서비스입니다.
      
      AWS Identity and Access Management > IAM 역할
      IAM 역할은 계정에 생성할 수 있는, 특정 권한을 지닌 IAM 자격 증명입니다.
      
      AWS Security Token Service > AssumeRole
      AWS 리소스에 액세스하는 데 사용할 수 있는 임시 보안 자격 증명 세트를 반환합니다.
      
19. DevOps 엔지니어는 Auto Scaling 그룹의 Application Load Balancer 뒤에서 실행되는 모든 Amazon EC2 인스턴스가 사용자 요청에 응답하지 못하는 것을 확인했습니다. EC2 인스턴스도 대상 그룹 HTTP 상태 확인에 실패합니다.
    
    검사 결과 엔지니어는 애플리케이션 프로세스가 어떤 EC2 인스턴스에서도 실행되고 있지 않았음을 확인했습니다. 시스템 로그에 상당한 수의 메모리 부족 메시지가 있습니다. 엔지니어는 잠재적인 애플리케이션 메모리 누수에 대처하기 위해 애플리케이션의 복원력을 개선해야 합니다. 문제가 있을 때 경고하도록 모니터링 및 알림을 활성화해야 합니다.
    
    이러한 요구 사항을 충족하는 작업 조합은 무엇입니까? (두 가지를 선택하세요.)
    • 로드 밸런서의 상태 확인에 실패하면 인스턴스를 교체하도록 Auto Scaling 구성을 변경하십시오.
    • 대상 그룹 상태 확인 HealthCheckIntervalSeconds 매개변수를 변경하여 상태 확인 간격을 줄이십시오.
    • 대상 그룹 상태 확인을 HTTP에서 TCP로 변경하여 애플리케이션이 수신 대기 중인 포트에 연결할 수 있는지 확인합니다.
    • 전체 Auto Scaling 그룹에 대해 Amazon CloudWatch 대시보드 내에서 사용 가능한 메모리 소비 지표를 활성화합니다. 메모리 사용률이 높을 때 경보를 생성합니다. Amazon SNS 주제를 경보에 연결하여 경보가 울릴 때 알림을 받습니다.
    • Amazon CloudWatch 에이전트를 사용하여 Auto Scaling 그룹에 있는 EC2 인스턴스의 메모리 사용률을 수집합니다. 메모리 사용률이 높을 때 경보를 생성하고 Amazon SNS 주제를 연결하여 알림을 받습니다.
      
      정리: 에이전트를 이용해서 프로세스 메모리 지표를 수집해야 함. OOME되면 인스턴스 메모리는 널널해져버림.
20. 개발자는 사용자가 Amazon S3 버킷에 이미지를 업로드할 수 있도록 허용해야 하는 애플리케이션을 구축하고 있습니다. 이미지를 업로드하려면 사용자가 Facebook을 사용하여 애플리케이션에 로그인할 수 있어야 합니다.
    
    이러한 요구 사항을 어떻게 충족할 수 있습니까?
    
    • 사용자의 Facebook 사용자 이름과 암호를 Amazon DymanoDB 테이블에 저장합니다. 다음에 사용자가 로그인을 시도할 때 해당 자격 증명에 대해 인증합니다.
    • Facebook을 자격 증명 공급자로 사용하여 Amazon Cognito 자격 증명 풀을 생성합니다. 사용자가 Amazon S3에 액세스할 수 있도록 임시 AWS 자격 증명을 얻습니다.
    • 여러 AWS IAM 사용자를 만듭니다. 이메일과 비밀번호를 각 사용자의 Facebook 로그인 자격 증명과 동일하게 설정합니다.
    • 새 Facebook 계정을 생성하고 로그인 자격 증명을 S3 버킷에 저장합니다. 해당 S3 버킷을 사용자와 공유하십시오. 사용자는 검색된 자격 증명을 사용하여 애플리케이션에 로그인합니다.
      
      설명: Amazon Cognito란 무엇입니까?
      Amazon Cognito는 웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리를 제공합니다. 사용자는 사용자 이름과 암호를 사용하여 직접 로그인하거나 Facebook, Amazon, Google 또는 Apple 같은 타사를 통해 로그인할 수 있습니다. 앱 사용자는 AWS 자격 증명을 사용하여 Amazon S3, DynamoDB 등 다른 AWS 서비스에 액세스할 수 있습니다.

 

정답

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