Encryption with AWS KMS: DVA-C03 study notes and practice questions
What to know about Encryption with AWS KMS for the DVA-C03 exam, from the Security domain (26% of the exam guide), then 3 free questions to test it. Part of the DVA-C03 study guide.
KMS questions usually fail on one of three points: the key policy does not allow the caller, the key type cannot do the job, or the permission is needed for longer than it should be.
Key types
A symmetric key encrypts and decrypts with the same key, and the key never leaves KMS. Use it for most data encryption. An asymmetric key has a public and a private part. Use it when someone outside AWS must verify a signature offline, because the public key can be downloaded with GetPublicKey and the private key stays in KMS. Asymmetric keys can sign and verify, or encrypt and decrypt, but GenerateDataKey needs a symmetric key.
Envelope encryption
KMS can encrypt only a small amount of data directly, up to 4 KB. For larger data, call GenerateDataKey. KMS returns a plaintext data key, which encrypts your data locally, and an encrypted copy of that data key, which you store next to the ciphertext. To read the data, decrypt the stored data key with KMS and use it to decrypt the data. The AWS Encryption SDK does this for you.
Who can use a key
The key policy is the main control. For a customer managed key, IAM policies work only when the key policy allows the account to delegate to IAM. Cross-account use needs both sides: the key policy in the key’s account must name the external principal, and the caller’s own account must allow the action in an IAM policy.
Grants give a principal permission to use a key for a set of operations, without editing the key policy. A grant can be created, used and retired. Use a grant when a permission is needed only for a short period, such as during one job.
The kms:ViaService condition limits a key’s use to requests that come through a specific AWS service, for example S3.
Rotation, deletion and Regions
Automatic rotation is available for symmetric encryption customer managed keys. It is off until you turn it on, and then runs every 365 days by default; you can set a period from 90 to 2,560 days, or rotate on demand. AWS managed keys rotate every year. Older key material stays available to decrypt existing data. Deleting a key has a waiting period of 7 to 30 days, and you can disable a key first to see what breaks. A multi-Region key has the same key material and ID in more than one Region, so ciphertext made in one Region can be decrypted in another during a Regional outage.
How to choose
Scenario wording
Answer
Encrypt a large file or object in your app
Envelope encryption with GenerateDataKey
Customers verify signatures outside AWS
Asymmetric key, Sign and GetPublicKey
Another account’s Lambda must decrypt
Key policy grants the external principal, plus IAM in that account
A permission is needed only while a job runs
Grant, retired at the end
Decrypt in a second Region after a failover
Multi-Region key
Use the key only through S3
kms:ViaService condition
Common traps
Using an AWS managed key for cross-account sharing. You cannot change its key policy.
Writing an IAM policy and expecting it to work without the key policy allowing it.
Using an asymmetric key for GenerateDataKey.
Calling KMS to encrypt a whole large object instead of using a data key.
Scheduling a key deletion with no waiting period to test. Disable it first.
A media company archives 200 MB video files, and a client-side process must encrypt each one with a customer managed AWS KMS key before it is stored.
Passing a whole file to the KMS Encrypt API fails because the file is too large. The company wants the fewest KMS API calls per file, and the key material of the KMS key must never leave KMS.
Which approach meets these requirements?
Choose one answer.
AA. Split each file into 4 KB pieces and call the KMS Encrypt API once for every piece, so that each call stays within its size limit.
BB. Create an asymmetric RSA KMS key and call Encrypt on the whole file, because RSA keys are meant for large inputs.
CC. Call GenerateDataKey, encrypt each file locally with the plaintext data key, and store the encrypted data key with the file.
DD. Call GenerateDataKeyWithoutPlaintext and use the encrypted data key that it returns to encrypt each file locally.
Show the answer and explanation
Answer: C
A. Wrong: Encrypt accepts at most 4,096 bytes of plaintext, so pieces of that size are accepted. But a 200 MB file would need about 50,000 calls, which is the opposite of keeping KMS calls to a minimum and invites throttling. Envelope encryption needs one call per file. Learn more: Encrypt API (opens in a new tab)
B. Wrong: RSA keys accept far less plaintext than symmetric keys: at most a few hundred bytes per call, depending on key size. The file would still be rejected, and a symmetric key with data keys is the right design. Learn more: Encrypt API (opens in a new tab)
C. Right: Correct. This is envelope encryption: KMS protects a small data key under the KMS key, and the large file is encrypted locally. The client keeps the encrypted data key with the file, discards the plaintext key and calls Decrypt on the data key when reading. Learn more: GenerateDataKey API (opens in a new tab)
D. Wrong: This operation returns only the encrypted copy of a data key, which is useless for local encryption until it is decrypted. An extra Decrypt call would then be needed for every file, so GenerateDataKey is the direct choice. Learn more: GenerateDataKey API (opens in a new tab)
Explanation
KMS Encrypt handles at most 4,096 bytes, so large files use envelope encryption. GenerateDataKey returns a plaintext data key for local encryption and an encrypted copy to store with the file, and the KMS key itself never leaves KMS. Chunking, RSA keys and the without-plaintext variant either multiply calls or still cannot encrypt the file.
One KMS call per file. To read the file later, send the stored encrypted data key to KMS Decrypt.
Account 111111111111 owns a symmetric customer managed AWS KMS key.
A Lambda function in account 222222222222 must call kms:Decrypt on data keys that were encrypted under this key, but the call is denied. The key's policy currently allows only principals in account 111111111111, and the security team wants to avoid long-term credentials.
Which TWO actions are required? (Choose two.)
Choose two answers.
AA. Add a key policy statement in account 111111111111 that allows account 222222222222 to use kms:Decrypt.
BB. Add account 222222222222 as a key administrator in the key policy so that its IAM policies can use the key.
CC. Allow kms:Decrypt on the key's full ARN in the IAM policy of the function's execution role in account 222222222222.
DD. Turn on automatic key rotation so that KMS creates a copy of the key material in account 222222222222.
EE. Create an IAM user in account 111111111111 with kms:Decrypt and store its access key in the function's environment variables.
Show the answer and explanation
Answers: A, C
A. Right: Correct. The key policy is the main control over a KMS key, so another account is allowed to use the key only if the policy names it. The policy decides who can be given access; it does not yet give any role in the other account access. Learn more: Allowing users in other accounts to use a KMS key (opens in a new tab)
B. Wrong: Key administrators can manage a key, for example change its policy, but the default policy does not let them use it for cryptographic operations. Administrator status is not how another account is given use of a key. Learn more: Default key policy (opens in a new tab)
C. Right: Correct. For cross-account use, the key policy and an IAM policy in the calling account must both allow the action. The IAM policy is what gives this particular role access, and it must use the full key ARN because a key ID is assumed to be in the caller's own account. Learn more: Allowing users in other accounts to use a KMS key (opens in a new tab)
D. Wrong: Rotation replaces the key material of a key in its own account on a schedule. It never copies the key or shares it with another account.
E. Wrong: This would work technically, but it relies on a long-term access key stored in the function's configuration. Cross-account use of the key is normally granted through the key policy and the caller's own IAM role.
Explanation
Cross-account KMS access needs two permissions: the key policy in the key's account must allow the other account, and an IAM policy in the calling account must allow the action on the full key ARN. Neither alone is enough. Key administrators, key rotation and stored access keys are not how a Lambda role in another account gets use of the key.
A Lambda function in the same account as an S3 bucket uploads reports and later downloads them.
The bucket's default encryption is SSE-KMS with a customer managed key whose key policy lets IAM policies grant access. The function's execution role allows s3:PutObject and s3:GetObject on the bucket, yet both operations fail with AccessDenied.
Which TWO KMS permissions should be added to the role, scoped to that key, to fix this with least privilege? (Choose two.)
Choose two answers.
AA. kms:Encrypt, so S3 can encrypt each uploaded object directly with the KMS key.
BB. kms:GenerateDataKey, so S3 can obtain a data key to encrypt each uploaded object.
CC. kms:Decrypt, so S3 can decrypt the stored data key when an object is downloaded.
DD. kms:ReEncrypt*, so S3 can switch each object's data key to a different KMS key on download.
EE. kms:DescribeKey, so S3 can check that the key is enabled before each upload.
Show the answer and explanation
Answers: B, C
A. Wrong: S3 does not send object data to KMS. It asks KMS for a data key and encrypts the object itself, so kms:Encrypt is not what an SSE-KMS upload needs. Learn more: Using SSE-KMS (opens in a new tab)
B. Right: Correct. Uploading an object with SSE-KMS requires kms:GenerateDataKey on the key, because S3 encrypts each object with a data key that KMS generates under the KMS key. Learn more: Using SSE-KMS (opens in a new tab)
C. Right: Correct. Downloading an SSE-KMS object requires kms:Decrypt on the key, so S3 can recover the object's data key. Multipart uploads need both kms:GenerateDataKey and kms:Decrypt. Learn more: Using SSE-KMS (opens in a new tab)
D. Wrong: ReEncrypt is used to move ciphertext from one KMS key to another, which neither a plain upload nor a download does. It would also be broader than the task requires.
E. Wrong: The S3 documentation lists kms:GenerateDataKey for uploads and kms:Decrypt for downloads. DescribeKey reads key metadata and would not fix the AccessDenied errors.
Explanation
With SSE-KMS, S3 asks KMS for a data key to encrypt each uploaded object and later asks KMS to decrypt that data key on download. The caller therefore needs kms:GenerateDataKey for uploads and kms:Decrypt for downloads, and both for multipart uploads. Permissions such as Encrypt, ReEncrypt* and DescribeKey are not what these operations use.
Want more on Encryption with AWS KMS? The 5 full-length practice sets have 16 more Encryption with AWS KMS questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →