Ultimate access to all questions.
Answer-first summary for fast verification
Answer: Enable EBS encryption by default in the AWS Region where the EKS cluster will be created. Select the customer managed key as the default key., Create the EKS cluster. Create an IAM role that has a policy that grants permission to the customer managed key. Associate the role with the EKS cluster.
## Explanation To meet the requirement of encrypting all data at rest using a customer managed key with the LEAST operational overhead: **C. Enable EBS encryption by default in the AWS Region where the EKS cluster will be created. Select the customer managed key as the default key.** - This ensures that all new EBS volumes created in that region (including those for the EKS managed node group) will automatically be encrypted with the customer managed key. - This is a one-time configuration that applies to all future EBS volumes, minimizing operational overhead. **D. Create the EKS cluster. Create an IAM role that has a policy that grants permission to the customer managed key. Associate the role with the EKS cluster.** - The EKS cluster needs permissions to use the KMS key for encryption operations. - By creating an IAM role with the appropriate KMS permissions and associating it with the EKS cluster, the managed node group's EC2 instances will have the necessary permissions to use the customer managed key. **Why other options are incorrect:** **A. Use a Kubernetes plugin that uses the customer managed key to perform data encryption.** - This adds operational overhead as it requires managing Kubernetes plugins and configurations. **B. After creation of the EKS cluster, locate the EBS volumes. Enable encryption by using the customer managed key.** - This requires manual intervention for each EBS volume, which increases operational overhead. - EBS volumes cannot be encrypted after creation; they would need to be recreated or snapshots would need to be taken and restored with encryption. **E. Store the customer managed key as a Kubernetes secret in the EKS cluster. Use the customer managed key to encrypt the EBS volumes.** - This is not secure and not recommended. KMS keys should not be stored as Kubernetes secrets. - This approach doesn't actually enable EBS encryption at the infrastructure level. **Key AWS Concepts:** 1. **EBS Default Encryption**: When enabled at the region level, all new EBS volumes are automatically encrypted with the specified KMS key. 2. **EKS IAM Integration**: EKS managed node groups need IAM permissions to access KMS keys for encryption operations. 3. **Customer Managed Keys**: Provide more control over key rotation policies and permissions compared to AWS managed keys.
Author: LeetQuiz Editorial Team
No comments yet.
A company needs to create an Amazon Elastic Kubernetes Service (Amazon EKS) cluster to host a digital media streaming application. The EKS cluster will use a managed node group that is backed by Amazon Elastic Block Store (Amazon EBS) volumes for storage. The company must encrypt all data at rest by using a customer managed key that is stored in AWS Key Management Service (AWS KMS).
Which combination of actions will meet this requirement with the LEAST operational overhead? (Choose two.)
A
Use a Kubernetes plugin that uses the customer managed key to perform data encryption.
B
After creation of the EKS cluster, locate the EBS volumes. Enable encryption by using the customer managed key.
C
Enable EBS encryption by default in the AWS Region where the EKS cluster will be created. Select the customer managed key as the default key.
D
Create the EKS cluster. Create an IAM role that has a policy that grants permission to the customer managed key. Associate the role with the EKS cluster.
E
Store the customer managed key as a Kubernetes secret in the EKS cluster. Use the customer managed key to encrypt the EBS volumes.