5.1 - Encryption in transit (ACM, TLS, mTLS, VPN)

1. A KMS key was created with the key usage SIGN_VERIFY. An application calls Encrypt with it and receives an error. Why?

• Because the key policy has to list the Encrypt action explicitly before any principal in the account is allowed to invoke it on that key
• Because signing keys must first be enabled for encryption through a separate key rotation request submitted to AWS Support
• Because a key usage is fixed at creation and a signing key cannot encrypt (correct answer)
• Because the caller did not supply an encryption context, which is mandatory for every asymmetric operation performed by the service

KeyUsage is chosen once, at creation, and is either ENCRYPT_DECRYPT or SIGN_VERIFY, never both. No policy statement, support request or encryption context can widen it: the only fix is to create a second key with the right usage. Encryption context is optional and applies to symmetric encryption anyway.

2. An operator updates a KMS alias so that it now points to a brand new key. What happens to the objects already encrypted through the old key?

• They still decrypt with the old key, which must stay enabled (correct answer)
• They become unreadable at once, because the alias is the only identifier stored in the ciphertext header of each object
• They are re encrypted in the background by KMS, which walks every ciphertext ever produced under the previous key material
• They keep working only until the old key reaches the end of its automatic rotation period, after which decryption starts failing

A ciphertext records the key ARN, not the alias, so KMS routes the Decrypt call to the original key whatever the alias now points to. Repointing an alias only changes which key new Encrypt calls use; it triggers no background re encryption and it does not invalidate anything. Use ReEncrypt if you really want to move existing ciphertext to the new key.

3. A large set of ciphertext blobs must move from one KMS key to another without the plaintext ever appearing in the application. Which API call does this?

• UpdateKeyDescription, which rewrites the metadata of the key and carries the associated ciphertext across to the replacement key
• GenerateDataKeyWithoutPlaintext followed by a client side loop that decrypts and encrypts each blob in the memory of the application
• ScheduleKeyDeletion on the source key, which migrates the ciphertext to the account default key before the deletion window opens
• ReEncrypt (correct answer)

ReEncrypt decrypts and re encrypts entirely inside the KMS service boundary, so the caller never handles plaintext and only needs Decrypt on the source key plus Encrypt on the destination. UpdateKeyDescription touches metadata only, scheduling a deletion migrates nothing, and the client side loop is exactly the plaintext exposure the requirement forbids.

4. An encrypted EBS snapshot cannot be shared with a partner account. The snapshot was encrypted with the default aws/ebs key. What is the cause?

• Snapshot sharing requires the two accounts to sit in the same AWS Organization and to share a common service control policy baseline
• An AWS managed key cannot be shared, so the snapshot must be copied under a customer managed key (correct answer)
• Sharing is blocked while the source volume remains attached to a running instance in the account that owns the snapshot
• The partner account has not yet created a volume of exactly the same size and type to receive the restored snapshot data

The key policy of an AWS managed key cannot be edited, so no external account can ever be granted Decrypt on it, which makes such a snapshot unshareable. The fix is a copy encrypted with a customer managed key whose policy and grants name the partner. Organization membership, volume attachment and the recipient's volume layout play no part in this restriction.

5. An SNS topic is configured with server side encryption using a customer managed key, and CloudWatch alarms can no longer publish to it. What is missing?

• A subscription filter policy on the topic allowing the alarm message attributes to pass through the encrypted delivery pipeline
• An IAM role attached to the CloudWatch alarm itself, since alarms authenticate to encrypted topics with temporary session credentials
• A key policy statement letting the cloudwatch service principal call GenerateDataKey and Decrypt (correct answer)
• A dead letter queue on the topic, without which encrypted publications from AWS services are silently discarded by the service

When a topic is encrypted, the publishing service principal needs cryptographic permissions on the key, so the key policy must allow cloudwatch.amazonaws.com to call GenerateDataKey and Decrypt. Filter policies only select which messages reach subscribers, alarms have no IAM role of their own, and a dead letter queue affects delivery to subscribers rather than publication.

6. A bank must keep the key material for its KMS keys inside a CloudHSM cluster it owns, while applications keep calling the standard KMS APIs. Which feature fits?

• A KMS custom key store backed by CloudHSM (correct answer)
• A KMS multi-Region key whose replicas are all created inside the same availability zone as the CloudHSM cluster of the bank
• An asymmetric KMS key whose private part is exported to the cluster and re imported after every automatic rotation of the material
• A CloudHSM client daemon installed on each application host so that the KMS SDK calls are proxied through the cluster transparently

A custom key store links a KMS key to a CloudHSM cluster: the API surface stays KMS while every cryptographic operation happens in the customer owned HSMs. Multi-Region keys concern geography, KMS private key material is never exportable, and there is no client daemon that proxies KMS calls into a cluster.