한 조직에서 단일 리전의 AWS Organizations를 사용하고 있습니다. 관리 계정은 management-01입니다. AWS Config는 모든 계정에서 활성화되어 있으며, security-01은 AWS Config의 위임된 관리자입니다. 모든 계정은 AWS Config 어그리게이터를 통해 위임된 관리자 계정에 규정 준수 상태를 보고합니다. 계정 관리자는 자체 AWS Config 규칙을 관리할 수 있습니다. 보안 엔지니어는 조직의 모든 현재 및 향후 계정에 10개의 표준 AWS Config 규칙 세트를 자동으로 배포하고, 새 계정에 AWS Config가 자동으로 활성화되도록 해야 합니다. 이러한 요구 사항을 충족하는 단계 조합은 무엇입니까? (두 가지 선택)

주어진 시나리오에서 두 가지 주요 요구 사항은 모든 계정에 AWS Config 규칙을 배포하고, 새 계정에 AWS Config를 자동으로 활성화하는 것입니다. 첫 번째 요구 사항인 AWS Config 규칙 배포의 경우, 컨포먼스 팩은 여러 AWS Config 규칙 및 수정 조치를 단일 엔터티로 묶어 조직 전체에 배포하고 관리하는 데 가장 적합한 방법입니다. security-01 계정은 AWS Config의 위임된 관리자이므로, 이 계정에서 컨포먼스 팩을 배포하여 조직의 모든 계정에 규칙을 적용할 수 있습니다. 두 번째 요구 사항인 새 계정에 AWS Config 자동 활성화의 경우, AWS CloudFormation StackSets는 AWS Organizations의 여러 계정 및 리전에 걸쳐 스택을 배포하는 데 사용됩니다. 관리 계정(management-01)은 조직의 모든 계정을 관리하는 중앙 지점이므로, 이 계정에서 AWS Config를 활성화하는 CloudFormation 템플릿을 StackSets를 통해 배포하면 현재 및 향후 모든 계정에 AWS Config가 자동으로 활성화됩니다. 다른 옵션들은 다음과 같은 이유로 올바르지 않습니다. CloudFormation 템플릿으로 개별 Config 규칙을 배포하는 것은 컨포먼스 팩보다 관리 오버헤드가 큽니다. management-01 계정에서 컨포먼스 팩을 배포하는 것은 가능하지만, security-01이 위임된 관리자이므로 해당 계정에서 규칙을 관리하는 것이 모범 사례입니다. security-01 계정에서 AWS Config 활성화 StackSets를 배포하는 것은 가능하지만, 조직 전체의 계정 프로비저닝 및 기본 서비스 활성화는 일반적으로 관리 계정에서 수행하는 것이 더 적절합니다.