Task 5.3: Design and implement controls to protect confidential data, credentials, secrets, and cryptographic key materials

• ASwitch to the alternating users rotation strategy

  Correct

  Alternating users keeps two valid users and updates one at a time, so cached credentials stay valid; the superuser secret is used to clone the user.

• BRotate the secret every four hours so that caches stay recent

  Incorrect

  More frequent rotation creates more rotation windows and more of the same failures.

• CMove the credentials to Parameter Store SecureString parameters

  Incorrect

  Parameter Store does not rotate database credentials for you, so the team loses rotation instead of fixing it.

• DKeep single user rotation and turn off caching in the application

  Incorrect

  With single user rotation, there is still a window in which the old password no longer works and new connections can be denied.

Single user rotation is simple but has a brief window of denied connections; alternating users is the strategy for high availability.

• AA KMS key with AWS-generated key material and automatic rotation every year

  Incorrect

  The key material would be generated by AWS KMS, not in the company's HSM, so the company would not hold the original.

• BA KMS key in an external key store that uses the on-premises HSM through a proxy

  Incorrect

  External key store keys are used in the external key manager, so encryption stops whenever the on-premises HSM is unreachable.

• CA KMS key with imported key material, rotated on demand by importing new material

  Correct

  Imported material can be deleted at once and reimported, and keys with imported material support on-demand rotation by importing new key material.

• DA standard KMS key that is scheduled for deletion whenever it must become unusable

  Incorrect

  Deletion needs a 7 to 30 day waiting period and cannot be undone after it completes.

Imported key material is the option for "we generate it, we keep the original, we can pull it now and bring it back", while AWS KMS still holds a working copy for availability.

• AA data protection policy on each existing log group, with logs:Unmask for the fraud team

  Incorrect

  Log group policies would leave log groups created later unprotected.

• BAn account-level data protection policy, with logs:Unmask granted only to the fraud team

  Correct

  An account-level policy applies to existing and future log groups, masks matches at all egress points, and only principals with logs:Unmask see the original data.

• CAn Amazon Macie sensitive data discovery job on log exports in S3

  Incorrect

  Macie reports sensitive data that it finds in S3. It does not mask what users see in CloudWatch Logs.

• DA subscription filter on each log group to a Lambda function that writes redacted copies

  Incorrect

  The original log groups would still show the numbers, and the team would maintain custom code.

Masking starts when the policy exists: events ingested before it are not masked, so create the policy before sensitive data arrives.

• AUse the us-east-1 key from eu-west-1 by specifying its full key ARN

  Incorrect

  That makes a cross-Region call to AWS KMS in us-east-1, which fails when that Region is unavailable.

• BCreate a key in eu-west-1 and give it the same alias as the us-east-1 key

  Incorrect

  An alias is only a name. Two single-Region keys have different key material, so one cannot decrypt the other's ciphertext.

• CTurn on the multi-Region property of the existing us-east-1 key

  Incorrect

  An existing single-Region key cannot be converted to a multi-Region key.

• DCreate a multi-Region primary key in us-east-1 and a replica in eu-west-1

  Correct

  Related multi-Region keys share key material and key ID, so data encrypted in one Region can be decrypted in the other without a cross-Region call.

Multi-Region keys exist for client-side encryption across Regions. Data already encrypted under a single-Region key must be re-encrypted to use them.

• AEncrypt the source file in the repository

  Incorrect

  The password stays in the code and in its history.

• BMove it to an environment variable in the code

  Incorrect

  The secret still travels with the application configuration.

• CRotate it and store it in Secrets Manager

  Correct

  For plaintext secrets in code, AWS recommends rotating them and storing them in Secrets Manager, where the code retrieves them.

• DRestrict who can read the repository

  Incorrect

  Fewer readers do not remove the secret from the code.

Rotate first, because the exposed value must be treated as compromised.

• AA password typed into the console and kept in a wiki

  Incorrect

  Manual handling is neither automatic nor secure.

• BLet RDS manage the password in Secrets Manager

  Correct

  RDS generates the credentials, stores them in Secrets Manager and rotates them regularly without application changes.

• CA SecureString parameter updated by a cron job

  Incorrect

  That needs custom code and scheduling.

• DIAM database authentication for the master user only

  Incorrect

  The master user password still has to be managed.

Applications read the current password from the secret at connection time.

• AAn allow list containing the employee ID format

  Incorrect

  Allow lists tell Macie what to ignore, not what to find.

• BA suppression rule for employee ID findings

  Incorrect

  Suppression hides findings instead of detecting new data types.

• CAn S3 Inventory report that is filtered on file names

  Incorrect

  Inventory lists objects; it does not inspect their contents.

• DA custom data identifier with a regex and a keyword

  Correct

  Custom data identifiers use a regular expression plus optional keywords and a proximity rule to detect sensitive data.

Test the regex on sample data before running it across large buckets.

• ASplit each file into 4 KB parts and call Encrypt for each

  Incorrect

  Thousands of KMS calls per file are slow and costly; data keys exist for this.

• BUse an asymmetric KMS key, which has no size limit

  Incorrect

  All KMS keys are limited in the data they encrypt directly.

• CUse GenerateDataKey and encrypt locally with the data key

  Correct

  KMS Encrypt takes up to 4,096 bytes; data keys are returned for use outside KMS, with an encrypted copy stored next to the data.

• DAsk AWS Support to raise the Encrypt size quota

  Incorrect

  The 4,096-byte limit is part of the operation, not a quota.

This is envelope encryption; the AWS Encryption SDK implements it for you.

• AA separate KMS key alias for every request

  Incorrect

  Aliases name keys; they do not bind data to a tenant.

• BA secret tenant ID inside the encryption context

  Incorrect

  The encryption context is not secret; it is logged in plaintext.

• CAn encryption context with the tenant ID

  Correct

  The encryption context is bound to the ciphertext as authenticated data and appears in plaintext in CloudTrail.

• DA tag on the KMS key with the tenant ID

  Incorrect

  Key tags describe the key, not each piece of data it encrypts.

The same encryption context must be supplied to decrypt, which also blocks swapping ciphertexts between tenants.