AWS - Certified Solutions Architect Data Encryption with KMS Questions and Answers 1 — Questions and Answers
Question 1: An application needs to encrypt large objects (greater than 10 GB) on the client side before uploading them to Amazon S3. The solution must use AWS KMS to manage the root keys. What is the most secure and efficient method to accomplish this?
- Send the entire 10 GB object to the KMS Encrypt API to be encrypted directly by the KMS key.
- Use the KMS GenerateDataKey API to create a data key, use it to encrypt the object locally, and store the encrypted data key alongside the encrypted object in S3. (Correct answer)
- Create a new unique customer managed KMS key for each 10 GB object to ensure strong encryption boundaries.
- Configure S3 server-side encryption with KMS-managed keys (SSE-KMS) and let S3 handle all encryption automatically upon upload.
Correct answer: Use the KMS GenerateDataKey API to create a data key, use it to encrypt the object locally, and store the encrypted data key alongside the encrypted object in S3.
This process is known as envelope encryption. The KMS `Encrypt` API has a 4KB data limit, making it unsuitable for large files. The correct and standard pattern is to use KMS to generate a data key (`GenerateDataKey`), which returns both a plaintext key and an encrypted version of that key. The application uses the plaintext key to encrypt the large object locally. The encrypted object and the encrypted data key are then stored in S3.
Question 2: A solutions architect is troubleshooting an issue where an IAM role, which has an IAM policy granting `kms:Decrypt` permissions, is unable to decrypt an object from an S3 bucket encrypted with a customer managed KMS key. What is the most likely reason for this failure?
- The IAM policy must be attached to the EC2 instance profile, not the role itself.
- The S3 bucket policy is explicitly denying the `s3:GetObject` action for the role.
- The KMS key policy does not grant the IAM role (or its AWS account) permissions to use the key. (Correct answer)
- The IAM role and the KMS key must be in the same AWS Region.
Correct answer: The KMS key policy does not grant the IAM role (or its AWS account) permissions to use the key.
For customer managed keys, access is determined by a combination of the KMS key policy and IAM policies. The key policy is the primary control document and must explicitly grant permissions to an IAM principal or its parent account. If the key policy does not grant access, no amount of permissions in an IAM policy will be effective.
Question 3: Which of the following statements accurately describes a key difference between an AWS managed KMS key and a customer managed KMS key?
- Only customer managed keys support envelope encryption.
- Customer managed keys offer full control over the key policy and key rotation schedule, whereas these are managed by AWS for AWS managed keys. (Correct answer)
- AWS managed keys are provided free of charge, while customer managed keys incur a monthly fee.
- AWS managed keys cannot be shared across different AWS accounts.
Correct answer: Customer managed keys offer full control over the key policy and key rotation schedule, whereas these are managed by AWS for AWS managed keys.
Customer managed keys give you full control over the key's lifecycle, including defining the key policy and deciding whether to enable automatic annual key rotation. For AWS managed keys, AWS creates and manages the key policy (which you can view but not edit) and enforces automatic annual key rotation.
Question 4: A security team in Account A manages a central customer managed KMS key. A development team in Account B needs to launch EC2 instances with encrypted EBS volumes using this central key. What combination of policies is required to grant this cross-account access?
- An IAM policy in Account B allowing `kms:CreateGrant` on the key's ARN, and no changes needed in Account A.
- An S3 bucket policy in Account A that delegates KMS permissions to Account B.
- A key policy in Account A that grants usage permissions to Account B, and an IAM policy in Account B that allows the relevant IAM principals to use the key. (Correct answer)
- A Service Control Policy (SCP) applied to the organization that allows `kms:*` between the two accounts.
Correct answer: A key policy in Account A that grants usage permissions to Account B, and an IAM policy in Account B that allows the relevant IAM principals to use the key.
Cross-account access to a KMS key requires a two-sided permission model. First, the key policy in the owning account (Account A) must be modified to grant permissions to the external account (Account B). Second, an IAM policy must be attached to the principal (user or role) in the external account (Account B) that explicitly allows it to perform the required KMS actions on the specified key's ARN.
Question 5: An administrator wants to permanently remove a customer managed KMS key that is no longer in use. What is the correct procedure for deleting a KMS key to prevent accidental data loss?
- The administrator must first disable the key, which triggers an automatic deletion after 30 days.
- The administrator can immediately and irrevocably delete the key using the AWS CLI with the `--force` flag.
- The administrator must open a high-priority support case with AWS to request the key's deletion.
- The administrator must schedule the key for deletion, which enforces a mandatory waiting period of 7 to 30 days before the key is permanently removed. (Correct answer)
Correct answer: The administrator must schedule the key for deletion, which enforces a mandatory waiting period of 7 to 30 days before the key is permanently removed.
To prevent accidental deletion of a key that is still protecting data, AWS KMS requires you to schedule the key for deletion. This action places the key in a `PendingDeletion` state for a configurable waiting period (7-30 days, default 30). During this time, the key cannot be used, but the deletion can be canceled. After the waiting period, the key is permanently deleted.
Question 6: In the context of envelope encryption with AWS KMS, what is the primary role of the customer managed key?
- To directly encrypt and decrypt large volumes of application data.
- To generate a digital signature for the encrypted data to ensure its integrity.
- To encrypt and decrypt the data encryption key (DEK) that is used to encrypt the application data. (Correct answer)
- To be stored in the same S3 bucket as the encrypted data for easy retrieval.
Correct answer: To encrypt and decrypt the data encryption key (DEK) that is used to encrypt the application data.
In envelope encryption, the KMS key (the 'master key') is not used to encrypt the bulk data directly. Instead, it is used to encrypt a unique data encryption key (DEK). This DEK is then used to encrypt the actual application data. The encrypted DEK is stored alongside the encrypted data. This method is efficient and enhances security by limiting the exposure of the master key.
An application needs to encrypt large objects (greater than 10 GB) on the client side before uploading them to Amazon S3.
The solution must use AWS KMS to manage the root keys.
What is the most secure and efficient method to accomplish this?