Task 5.2: Design and implement controls for data at rest

• AObject Lock in governance mode with seven-year default retention, plus legal holds

  Incorrect

  In governance mode, users with s3:BypassGovernanceRetention can remove the protection, so the records are not safe from everyone.

• BS3 Versioning with MFA delete turned on by the root user

  Incorrect

  MFA delete adds a step for deleting versions, but a user with the MFA device and permissions can still delete them.

• CAmazon Glacier Vault Lock with a seven-year policy for the bucket

  Incorrect

  Vault Lock policies apply to vaults in the standalone Amazon Glacier service, which no longer accepts new customers, not to objects in S3 buckets.

• DObject Lock in compliance mode with seven-year default retention, plus legal holds

  Correct

  Compliance mode stops anyone, including the root user, from deleting or overwriting a version during retention; a legal hold has no expiry until removed.

Compliance mode makes retention unbreakable, and legal holds extend protection for as long as needed. Object Lock requires versioning on the bucket.

• ACustomer managed KMS keys in the standard AWS KMS key store

  Incorrect

  These keys are protected by FIPS 140-3 Level 3 validated HSMs, but the HSMs are managed by AWS KMS, not a single-tenant cluster the company controls.

• BKMS keys in an AWS CloudHSM key store backed by the company's CloudHSM cluster

  Correct

  The key material is generated and used in the company's own CloudHSM cluster, the keys work with integrated services, and disconnecting the key store stops their use.

• CA CloudHSM cluster used directly by the applications for client-side encryption

  Incorrect

  Client-side encryption in the application bypasses the EBS and S3 integrations with AWS KMS that the company must use.

• DCustomer managed KMS keys with imported key material

  Incorrect

  Imported material is stored and used in AWS KMS HSMs, and it cannot be imported into keys in a custom key store.

Standard KMS already meets FIPS 140-3 Level 3. The deciding words are "single-tenant cluster the company controls" plus "service integration", which point to a CloudHSM key store.

• ALock the backup vault with AWS Backup Vault Lock in governance mode

  Incorrect

  A governance mode lock can be removed by users with sufficient IAM permissions, so a compromised administrator could remove it.

• BLock the backup vault with AWS Backup Vault Lock in compliance mode

  Correct

  After the grace time, a compliance mode lock cannot be changed or removed by any user, including the root user, or by AWS.

• CTurn on continuous backup for point-in-time recovery of the resources

  Incorrect

  Continuous backup improves the recovery point, but it does not stop an administrator from deleting the backups.

• DCreate AWS Backup Audit Manager frameworks that report on backup compliance

  Incorrect

  Backup Audit Manager reports whether backups meet controls. It does not prevent deletion.

• ECopy recovery points to a vault in a separate backup account

  Correct

  Cross-account copies keep restorable backups outside the workload account, so losing that account does not lose the backups.

Immutability and isolation answer different threats: a compliance lock stops deletion, and a copy in another account survives the loss of the first. AWS also offers logically air-gapped vaults that combine both ideas.

• ARe-encrypt copies with a customer managed key, share the key, then share the copies

  Correct

  Snapshots encrypted with the default AWS managed key cannot be shared. Re-encrypted copies under a customer managed key can be, together with the key.

• BEdit the key policy of the aws/ebs key to allow the DR account to use it

  Incorrect

  Key policies of AWS managed keys cannot be changed, so this key cannot be shared.

• CMake the snapshots public for a few minutes and copy them from the DR account

  Incorrect

  Only unencrypted snapshots can be shared publicly, and doing so would expose the data.

• DTurn off EBS encryption by default in the Region, then take and share new snapshots

  Incorrect

  Unencrypted snapshots would break the encryption requirement and do not fix the existing snapshots.

Anything you want to share across accounts must be encrypted with a key you control. Use customer managed keys from the start for data that may need to be shared.

• AEncrypted with SSE-S3 by default

  Correct

  Amazon S3 applies server-side encryption with S3 managed keys as the base level of encryption for every bucket.

• BUnencrypted, until default encryption is set

  Incorrect

  S3 applies SSE-S3 to every bucket as the base level.

• CEncrypted with the account's aws/s3 KMS key

  Incorrect

  SSE-KMS is used only when it is configured or requested.

• DEncrypted with a key the developer must provide

  Incorrect

  The uploader does not have to supply any key; with no encryption request, S3 applies its base level of encryption on its own.

Choose SSE-KMS when you need control over the key and key-usage logs.

• AMFA delete, turned on by any IAM administrator

  Incorrect

  Only the bucket owner's root account can turn on MFA delete.

• BMFA delete, turned on by the owner's root account

  Correct

  MFA delete requires two forms of authentication for these actions, and only the bucket owner (root account) can enable it.

• CAn IAM policy condition requiring MFA for s3:PutObject

  Incorrect

  Uploads are not the concern; deletions of versions are.

• DS3 Object Lock in governance mode with no retention

  Incorrect

  Governance mode needs a retention period and is not MFA delete.

For retention that no one can shorten, consider Object Lock in compliance mode instead.

• AA legal hold on the object versions

  Correct

  A legal hold gives the same protection as a retention period but has no expiration date; it stays until removed.

• BA retention period in compliance mode for ten years

  Incorrect

  A fixed period cannot be shortened in compliance mode and does not match an unknown end date.

• CA lifecycle rule that expires the objects later

  Incorrect

  Lifecycle rules delete or transition objects; they do not protect them.

• DA bucket policy that denies GetObject

  Incorrect

  Denying reads does not protect against deletion.

An object version can have both a retention period and a legal hold.

• AThe same KMS key ARN as the source in us-east-1

  Incorrect

  KMS keys are Regional; the replica uses a key in its own Region.

• BNo key, because cross-Region replicas are never encrypted

  Incorrect

  Encrypted cross-Region replicas are supported for encrypted sources.

• CA KMS key in the destination Region, eu-west-1

  Correct

  For an encrypted replica in another Region, you choose the identifier of a KMS key in the destination Region.

• DAny key, as long as it is an AWS owned key

  Incorrect

  The replica is encrypted with a KMS key you choose in the destination Region.

Multi-Region keys can simplify this, but a separate key per Region also works.

• AOnly the data files are encrypted, not its backups or logs

  Incorrect

  Logs, automated backups, read replicas and snapshots are encrypted too.

• BApplications must call KMS to read each row

  Incorrect

  Encryption is transparent; client applications need no changes.

• CSnapshots of the instance are stored unencrypted

  Incorrect

  Snapshots of an encrypted instance are encrypted.

• DIts logs, backups, replicas and snapshots are encrypted

  Correct

  For an encrypted DB instance, logs, backups, read replicas and snapshots are encrypted as well.

Encryption is chosen at creation; an existing unencrypted instance needs an encrypted snapshot copy and a restore.