Data Protection practice questions

Configure a bucket policy that denies s3:PutObject with s3:x-amz-server-side-encryption-aws:kms.

Why it fails: A bucket policy that denies s3:PutObject when the condition key s3:x-amz-server-side-encryption-aws:kms equals "aws:kms" only blocks uploads that explicitly request SSE-KMS; it does not require SSE-S3, because requests with no encryption header or with AES256 would not match the condition and would be permitted. Existing SSE-KMS objects remain readable, so this does not enforce a uniform encryption standard and can even allow unencrypted PUTs if no default encryption is set.

Use an S3 Lifecycle policy to transition existing SSE-KMS objects to SSE-S3.

Why it fails: S3 Lifecycle policies only transition the storage class of an object (for example, from S3 Standard to S3 Glacier Deep Archive) and never rewrite or replace the object's encryption settings. To change existing objects from SSE-KMS to SSE-S3, you must programmatically copy each object to itself or to a new key while specifying the desired server-side encryption, then delete the original — a lifecycle rule cannot perform that operation.

Disable SSE-KMS in the AWS KMS key policy to prevent its use.

Why it fails: Disabling the AWS KMS key in its key policy (or via the console) makes the key unusable, which means S3 cannot decrypt any existing objects that were encrypted with that customer-managed key, causing GET calls to fail with an AccessDenied error. This also prevents all new uses of the key, including non-S3 services, and does nothing to require AES256 encryption; instead you would need to re-encrypt objects with a new key or use bucket policy to enforce SSE-S3.

Use AWS KMS with a customer master key (CMK) and import key material from the on-premises HSM.

Why it fails: KMS does not allow direct use of an external HSM for key management; imported key material is still inside KMS.

Store the encryption keys in AWS Secrets Manager and use them to encrypt the database.

Why it fails: Secrets Manager is not designed for database encryption at rest; it's for application secrets.

Use AWS KMS with a custom key store backed by AWS CloudHSM.

Why it fails: This uses CloudHSM but the key management is still through KMS, and you don't directly control the HSM.

Enable encryption at rest on the EC2 instances.

Why it fails: Encryption at rest does not affect encryption in transit.

Use a network load balancer instead of an ALB.

Why it fails: NLB supports TLS termination but the question specifies ALB.

Assign a certificate from ACM to the ALB listener.

Why it fails: While necessary, this alone doesn't enforce encryption in transit. The target group protocol is also needed.

Enable default encryption on the bucket using SSE-S3

Why it fails: SSE-S3 does not use KMS keys.

Use an SCP to deny s3:PutObject without encryption

Why it fails: SCPs are not effective at resource level.

Set a bucket policy to require the x-amz-server-side-encryption header

Why it fails: Default encryption does not enforce encryption header.

Create an IAM role that requires the ec2:RunInstances action to include the kms:KeyId condition

Why it fails: An IAM role merely defines a set of permissions that a principal can assume; it does not globally enforce encryption key selection. While you can attach an IAM policy to a role that uses a kms:KeyId condition on ec2:RunInstances, that policy only affects the role's own permissions and can be bypassed by any user or service that does not assume the role or that has an alternative allow. Moreover, the proposed approach conflates roles with policies—the condition belongs on an IAM policy, not on the role itself, and it still would not cover all launch paths such as EC2 launch templates or the console.

Configure the KMS key policy to allow only the specific key for EBS encryption

Why it fails: A KMS key policy determines which principals can use that specific key for cryptographic operations, but it cannot control which key a caller chooses when launching an EC2 instance. The condition in a key policy only applies to requests that target that key; it has no authority over requests that use a different key or the default EBS key. To enforce a specific key, you need a policy that is evaluated at the EC2 RunInstances action, such as an SCP, not a key policy attached to the key itself.

Enable encryption by default for EBS volumes in the account

Why it fails: EBS encryption by default causes all new volumes to be encrypted, but it uses the service default key (aws/ebs) unless a different key is explicitly specified in the launch request. The requirement is to force a particular customer managed key, which default encryption does not do—an instance can still be launched with the default key or another valid key. Default encryption is a baseline data-at-rest control, not an enforcement mechanism for a specific key choice; an SCP with a kms:KeyId condition is needed to constrain that choice.

Create a lifecycle policy to transition objects to a new storage class

Why it fails: A lifecycle policy is designed to transition objects between storage classes or expire them, not to alter their server-side encryption attributes. When S3 transitions an object, it copies or moves it using the existing encryption settings—if the object is SSE-KMS it stays encrypted with the original KMS key, and if it's SSE-S3 it remains SSE-S3. Lifecycle actions do not accept a new KMS key or re-encrypt content, so they are irrelevant to changing the encryption method.

Use the AWS CLI s3 sync command with the --sse aws:kms option

Why it fails: The AWS CLI s3 sync command only uploads objects that are new or changed based on size and last-modified time, so objects that already exist are skipped entirely, and existing versions are never rewritten. Even with --sse aws:kms, the key is only applied to newly uploaded files, not to any current or historical versions in a versioned bucket. Sync would create a new version only if the local file is different, but it cannot enumerate and re-encrypt every existing version.

Manually re-upload the objects via the S3 console

Why it fails: Manually re-uploading via the S3 console cannot replace an existing object version in place; uploading to the same key creates a new version ID, leaving the original version with its old SSE-KMS key intact. For a versioned bucket, you would need to delete and re-upload every historical version, which also loses metadata like object tags and cannot guarantee consistent application of the new KMS key. It is also operationally unscalable if there are many objects.

Enable versioning on the bucket

Why it fails: Enabling versioning preserves every version of an object, including overwrites and deletions, which can aid in recovery and audit, but it does not alter how the object's plaintext bytes are stored in S3. Versioning is a data protection control for accidental/malicious deletion or corruption, not a confidentiality control. Since S3 still stores all versions in the same underlying encrypted-or-unencrypted form, enabling versioning alone leaves data at risk of being readable if the bucket is not encrypted.

Enable MFA Delete on the bucket

Why it fails: MFA Delete adds an extra authentication requirement for permanently deleting object versions or suspending versioning on a versioned bucket, which protects against accidental or unauthorized destructive actions. It has no effect on how object data is encrypted or stored; enabling MFA Delete does not encrypt the object contents at rest, nor does it alter the physical storage representation. Thus, while valuable for integrity and availability, it is not a solution for the confidentiality requirement of protecting data at rest.

Configure a lifecycle policy to transition objects to Glacier

Why it fails: Lifecycle policies transition objects to Amazon S3 Glacier or Glacier Deep Archive based on age or other rules, which can reduce storage costs and provide another copy, but Glacier itself stores the objects in the same unencrypted-or-pre-existing-encryption state. The transition action does not apply any encryption; if the source object was SSE-S3-encrypted it remains encrypted, but if it was uploaded as plaintext it stays plaintext in Glacier unless you also configure bucket default encryption. Lifecycle management is about storage lifecycle and cost optimization, not encryption at rest.

x-amz-server-side-encryption: AES256

Why it fails: The x-amz-server-side-encryption: AES256 header selects SSE-S3, where AWS owns and manages the encryption keys, not the caller. In an SSE-C request, the algorithm must be declared with x-amz-server-side-encryption-customer-algorithm, and this standard AES256 header does not trigger customer-key validation. It encrypts objects with S3-managed keys, so it cannot satisfy a requirement for customer-provided key material.

x-amz-server-side-encryption-customer-key: <key>

Why it fails: The x-amz-server-side-encryption-customer-key header is mandatory for SSE-C, but it is incomplete on its own because S3 requires it to be accompanied by x-amz-server-side-encryption-customer-algorithm: AES256. If you send only a key without an algorithm, Amazon S3 rejects the request with an error because a customer-supplied key without a declared cipher is ambiguous. The key value must also be base64-encoded, and optional x-amz-server-side-encryption-customer-key-MD5 can be used for integrity verification, so this header alone is not a valid SSE-C request.

x-amz-server-side-encryption: aws:kms

Why it fails: The x-amz-server-side-encryption: aws:kms header selects SSE-KMS, where a KMS key performs envelope encryption and manages the key hierarchy on AWS's side. It does not accept a customer-supplied key in the request, so it cannot be used for SSE-C scenarios. Using this header also introduces KMS API costs and requires appropriate IAM permissions and key policies, meaning the encryption key is owned and operated by AWS rather than exclusively by the company.

AWS Secrets Manager

Why it fails: AWS Secrets Manager is a service for securely storing and rotating credentials, not a general-purpose encryption engine. When it encrypts secret values, it does so by calling AWS KMS with a customer-managed key, meaning it inherits KMS's shared HSM backing rather than providing its own dedicated, Level 3-certified HSM. It therefore cannot satisfy a requirement for dedicated hardware security modules. For that, you need CloudHSM.

AWS Key Management Service (KMS)

Why it fails: AWS KMS uses FIPS 140-2 Level 3 validated HSMs, but those HSMs are shared across multiple AWS customers in a multi-tenant region. Even with a customer-managed key (CMK), you do not get exclusive use of a physical HSM; AWS manages and operates the underlying hardware. The shared nature fails a compliance mandate that calls for dedicated HSMs. CloudHSM provides a single-tenant, dedicated HSM partition instead.

Amazon S3 default encryption with SSE-C

Why it fails: Amazon S3 default encryption with SSE-C lets you supply your own encryption keys for each S3 PUT/GET request, and S3 applies AES-256 using those keys. The customer-provided keys are not stored by AWS at all, and they never reside in an AWS HSM—S3 keeps them only in memory during the operation and then discards them. This requires you to manage key delivery and defeats the goal of using a dedicated, hardware-backed key vault. The compliance requirement asks for all data encrypted with keys stored in an HSM, which SSE-C does not do.

Deny s3:PutObject unless the request includes x-amz-server-side-encryption: AES256.

Why it fails: This does not deny requests with other encryption headers.

Deny s3:PutObject for all principals.

Why it fails: This blocks all uploads.

Allow s3:PutObject only when x-amz-server-side-encryption: AES256 is present.

Why it fails: This allows but does not deny unencrypted; unencrypted requests would be allowed by default.

Use S3 Object Lock with retention mode.

Why it fails: Object Lock prevents overwrites/deletes only during retention period.

Enable cross-region replication to another bucket.

Why it fails: Replication does not prevent deletion; it replicates deletion markers.

Configure an S3 bucket policy that denies s3:DeleteObject for all principals.

Why it fails: Would block deletion entirely, but may not be practical.

Disable automatic key rotation to maintain control over the key material.

Why it fails: Disabling automatic key rotation does not give you more control over the key material—it actually leaves the same backing key in use indefinitely, increasing the window of exposure if that key material is ever compromised, and it prevents you from rotating to a fresh backing key after a suspected breach. Additionally, for AWS KMS keys the backing keys are still managed by AWS on your behalf, so disabling rotation merely removes the annual cryptographic hygiene that helps limit damage. Thus it is a security anti-pattern, not a control you gain.

Share the KMS key across multiple AWS accounts using cross-account access.

Why it fails: Sharing a KMS key across AWS accounts requires adding the external account's principals to the key policy and granting them IAM permissions in their own account, which expands the trust boundary and makes audit and least-privilege enforcement more difficult. Every new principal granted access increases the attack surface and the potential for unauthorized decryption, especially if those accounts are compromised; cross-account sharing should be limited to specific, justified scenarios with strict monitoring. Therefore it is not a best practice for protecting S3 data.

Key 2345bcde-23bc-45de-67fg-2345678901bc.

Why it fails: Key 2345bcde-23bc-45de-67fg-2345678901bc is an AWS managed key (such as aws/s3 or aws/ebs). AWS rotates these keys on a fixed annual schedule, but the customer cannot enable, disable, or otherwise manage rotation settings on them. Since the goal is a key whose automatic rotation can be enabled and controlled by the security engineer, this key does not meet the requirement; its rotation lifecycle is entirely AWS-controlled.

Neither key supports envelope encryption with automatic rotation.

Why it fails: This option claims that neither key can be used for envelope encryption with automatic rotation. That is false because Key 1234abcd is a customer-managed key with automatic rotation enabled, which means it can generate data keys and automatically use new backing key material each year while still decrypting older data keys. Any statement that excludes this key contradicts the capabilities of customer-managed KMS keys.

Both keys support envelope encryption with automatic rotation.

Why it fails: This option wrongly states that both keys support envelope encryption with automatic rotation. While Key 1234abcd supports it as a customer-managed key, Key 2345bcde is an AWS managed key whose rotation is preset and not customer-configurable. Therefore it cannot be treated as a key for which the engineer can enable or modify automatic rotation, even though AWS performs rotation internally.

kms:ViaService

Why it fails: kms:ViaService is a KMS key policy condition key that restricts the AWS service making the KMS API call to a specific service principal, such as s3.amazonaws.com. It only validates which service can use the key on your behalf, not the encryption context attached to the request. Since it never inspects the encryption context, it cannot require the presence of a specific encryption context key on S3 PUT requests.

s3:x-amz-server-side-encryption

Why it fails: s3:x-amz-server-side-encryption is a valid S3 bucket policy condition key that checks the value of the x-amz-server-side-encryption header, enforcing that objects are uploaded with either AES256 or aws:kms. However, it only controls whether server-side encryption is used and which encryption algorithm is selected; it does not examine or constrain the KMS encryption context. Requiring aws:kms via this condition does not mandate that any specific encryption context key be present.

s3:PutObjectEncryption

Why it fails: s3:PutObjectEncryption is not a defined condition key in the S3 service namespace. AWS documentation and the IAM condition key reference list only recognized S3 condition keys such as s3:x-amz-server-side-encryption and s3:x-amz-server-side-encryption-aws-kms-key-id. Using an invalid condition key in a bucket policy would make the policy statement syntactically invalid or cause it to fail at evaluation time, so it cannot enforce encryption context requirements.

The bucket policy does not allow SSE-KMS.

Why it fails: A bucket policy is an IAM-based authorization mechanism; it does not enable or disable SSE-KMS. SSE-KMS is activated either by the x-amz-server-side-encryption header on a PutObject request or by the bucket's default encryption configuration. A bucket policy can require or deny encryption, but simply 'not allowing' SSE-KMS is not a valid state—absence of a policy statement does not block encryption. If the policy were the cause, you'd see an AccessDenied from a deny statement, not a KMS encryption failure.

The KMS key has expired.

Why it fails: KMS customer master keys do not expire. The only way a managed key becomes unusable is by scheduled deletion, which enforces a waiting period (7–30 days), and even then the key is marked 'Pending Deletion' before removal. Because no expiration mechanism exists, an 'expired' key cannot be the reason for a failure to encrypt or decrypt S3 objects.

The KMS key does not have automatic rotation enabled.

Why it fails: Automatic rotation is a security best practice that periodically creates new backing key material for the same CMK, but it is not a prerequisite for using the key. Encryption and decryption continue to work without rotation, and KMS even keeps the original material available to decrypt old objects. Therefore the absence of automatic rotation would never cause an S3 SSE-KMS encryption failure—the key remains active and usable.

Enable automatic encryption of EBS snapshots by default.

Why it fails: Snapshots are not automatically encrypted; encryption is done during copy.

Use an instance type that supports encryption at rest.

Why it fails: Instance type does not determine EBS encryption.

Configure the operating system to use encrypted file systems.

Why it fails: This is a client-side measure, not an AWS-native one for data at rest.

Delete the KMS key immediately when it is no longer needed.

Why it fails: Deletion should be scheduled to avoid data loss.

Export the KMS key material and store it in a secure S3 bucket.

Why it fails: Exporting key material removes it from KMS's FIPS 140-2 validated boundary, so KMS can no longer enforce rotation, audit via CloudTrail, or guarantee deletion — defeating the managed-service model. It is tempting for hybrid or multi-cloud workloads requiring cryptographic material outside AWS, where customer-managed external keys are genuinely needed.

The root user does not have permission to use the key.

Why it fails: The root user in an AWS account is represented by the account-level principal in a KMS key policy, and the exhibit's policy explicitly lists the root user with 'kms:*' actions, so the account root already has permission to call kms:Decrypt. Because the key policy is not restricting the root user and there is no explicit IAM deny, absent authorization cannot be the root cause. A failed decrypt while using root credentials must therefore be explained by something other than missing permissions, such as the key's disabled state.

The key administrator has not granted the AppRole permission to use the key.

Why it fails: A KMS 'key administrator' is a set of IAM principals allowed to manage key lifecycle tasks such as enabling, disabling, and rotating the key, but they are not involved in scoping who can use the key for cryptographic operations. The AppRole is a direct principal in the key policy, and that policy explicitly gives AppRole the kms:Decrypt action, so any assertion that the administrator failed to grant it is factually incorrect. The only way the administrator's action would matter here is if they had not yet enabled the key after creating it, and that is already covered by the key-state issue.

The kms:Decrypt permission is not granted to the AppRole.

Why it fails: The key policy in the exhibit includes an explicit statement granting the AppRole principal the kms:Decrypt action on the key, so the application role is not missing the required action. In IAM and KMS authorization, a missing action would typically produce an AccessDenied error, but here the action is present and the most likely cause is the key's disabled state. Therefore, adding kms:Decrypt again, or adjusting the key administrator's permissions, would not resolve the decryption failure.

Encrypt the data with a client-side tool before copying to Snowball Edge.

Why it fails: Client-side encryption is not required; Snowball Edge encrypts data automatically.

Set up a VPN connection to AWS and transfer data over the VPN.

Why it fails: A VPN connection is not used with Snowball Edge; the device uses its own secure transfer method.

Use AWS KMS to generate a key and apply it to the Snowball Edge device.

Why it fails: AWS KMS is not directly applied to Snowball Edge devices; the device generates and manages its own encryption keys.

S3 Lifecycle policies

Why it fails: S3 Lifecycle policies define time-based rules to automatically transition objects to lower-cost storage classes or expire them; they do not track, back up, or restore user-initiated deletions. In fact, an expired object is permanently removed, and a misconfigured lifecycle rule can accelerate data loss rather than prevent it. Lifecycle management is useful for cost optimization and data retention, but it provides no ability to undo an accidental deletion or recover a previous object version.

S3 MFA Delete

Why it fails: S3 MFA Delete adds a required multi-factor authentication step before permanently deleting object versions or suspending versioning on a bucket, but it only works after versioning has been enabled. Whereas versioning alone lets you restore a deleted object by removing the delete marker, MFA Delete merely prevents irreversible version deletion; it does not on its own maintain or restore copies. It is a complementary control that can reduce the risk of permanent loss, but it is not the core mechanism for recovering from an accidental deletion.

S3 Block Public Access

Why it fails: S3 Block Public Access is a security control that denies public read/write access to buckets or objects by overriding any public ACLs or bucket policies, but it has no bearing on actions taken by authenticated IAM users or roles inside the account. Accidental deletion or overwrite by an internal user or application is still possible, and Block Public Access offers no version history or rollback to recover lost data. It protects against unintended data exposure, not against unintended data loss.