Secrets and sensitive data: DVA-C03 study notes and practice questions
What to know about Secrets and sensitive data 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.
These questions give you a secret, a log, or a data set with personal information, then ask where the value should live, how it should be read, or how it should be hidden. Decide first whether the value needs rotation and whether it must be kept out of logs.
Secrets Manager or Parameter Store
Secrets Manager stores credentials and other secrets. It can rotate database and API credentials on a schedule with a rotation function, and it keeps earlier versions so an application can use the previous value during a switch. Use it when rotation is needed or when the secret is a credential for a database or service.
Systems Manager Parameter Store stores configuration. A SecureString parameter is encrypted with a KMS key. Use it for values that change between environments, such as endpoints and keys, and that do not need automatic rotation. Large values may need the advanced tier.
Rotation writes the new value under the AWSPENDING staging label, tests it, then moves AWSCURRENT to it and keeps the old one as AWSPREVIOUS; reads without a label get AWSCURRENT. The alternating users strategy avoids the short window where single user rotation can refuse logins. Amazon RDS can also manage a master user password in Secrets Manager and rotate it with no rotation function to write.
A SecureString is returned encrypted unless the request asks for decryption (WithDecryption), and the caller needs kms:Decrypt. The standard tier allows values up to 4 KB; the advanced tier allows 8 KB and parameter policies, for a charge.
Both services encrypt with KMS. Share a secret across accounts with a resource policy and a customer managed key whose key policy allows the reader; the AWS managed aws/secretsmanager key cannot be used across accounts. In ECS, secrets named in the task definition are read with the task execution role, not the task role.
Reading secrets safely
Read secrets at run time from the SDK, not from source code or build files.
Cache the value briefly and refresh it on rotation. In Lambda, the AWS Parameters and Secrets Lambda Extension caches secrets and parameters for the function.
Environment variables on Lambda are encrypted at rest, but anyone who can read the function’s configuration can see the plain value in the console. Put a secret there only if that visibility is acceptable, or encrypt the value with a customer managed key before you set it.
Identifying and masking PII and PHI
Personal data such as names, email addresses, card numbers and health record numbers must be found before it can be protected. For application logs in CloudWatch Logs, a data protection policy on a log group can audit and mask sensitive data. Managed data identifiers detect common types, and custom identifiers can match your own formats. A policy can audit (report findings to a log stream) and mask (replace the value in the log view). Masked values show as asterisks. Only users with the unmask permission can see the original text.
Amazon Macie finds PII in S3 buckets, and Amazon Comprehend detects and redacts PII in free text.
Masking does not stop a value being written first, so the safest design is not to log it.
How to choose
Scenario wording
Answer
Database password must rotate every few days
Secrets Manager with a rotation function
Endpoint URLs and a key that differ by environment
Parameter Store, with SecureString for the key
Share a secret with a Lambda in another account
Resource policy and a KMS key policy that allow the reader
PII appears in CloudWatch Logs
Log group data protection policy that masks it
Find PII in S3 buckets
Amazon Macie
Redact PII from free text
Amazon Comprehend PII detection
Common traps
Storing a secret in a Lambda environment variable and assuming console users cannot see it.
Using Parameter Store for a credential that must rotate automatically.
Writing a rotation schedule with the app still reading an old cached value.
Expecting masking to change what was written before the policy existed.
Choosing a scanner script for PII in S3 when Macie does the job.
A Lambda function connects to an Amazon RDS for PostgreSQL database using a password that is hard-coded in its source.
The security team wants the password out of the code, rotated automatically every 30 days, and picked up by the function without a redeployment. The team wants the LEAST operational overhead.
What should the developer do?
Choose one answer.
AA. Keep the password in a Systems Manager Parameter Store SecureString and rotate it with a scheduled Lambda function that the team writes.
BB. Put the password in a KMS-encrypted Lambda environment variable and have the CI/CD pipeline change it every month.
CC. Store the password in AWS Secrets Manager with a 30-day rotation schedule, and have the function call GetSecretValue at run time.
DD. Keep the password in an encrypted S3 object that a scheduled job replaces every 30 days, read by the function on each call.
Show the answer and explanation
Answer: C
A. Wrong: Parameter Store has no built-in rotation, so the team would write, test and operate the rotation function itself. It would also need to change the database password in step. Secrets Manager provides this rotation as a feature. Learn more: Rotating secrets (opens in a new tab)
B. Wrong: Environment variables are fixed when a version is configured, so each change means a new configuration and a pipeline job to run. This is more effort and not automatic rotation.
C. Right: Correct. Secrets Manager supports automatic rotation on a schedule and updates both the secret and the database. Because the function reads the secret when it runs, it gets the new password without a redeployment. Learn more: What is AWS Secrets Manager? (opens in a new tab)
D. Wrong: S3 can hold an encrypted file, but nothing changes the database password in step with the file. The team would build the schedule, the job and the coordination with the database.
Explanation
Secrets Manager rotates credentials on a schedule, updating both the secret and the database, and applications that fetch the secret at run time pick up each new value without a redeployment. Parameter Store, environment variables and S3 files all leave the team building and running the rotation.
A deployment script on an Amazon EC2 instance reads a SecureString parameter from AWS Systems Manager Parameter Store by running aws ssm get-parameter --name /prod/payments/api-key.
The command succeeds, but the Value in the output is a long unreadable string instead of the key. The instance role already allows ssm:GetParameter and kms:Decrypt on the parameter's KMS key.
What should the developer change?
Choose one answer.
AA. Add the --with-decryption option to the command so that Parameter Store decrypts the value before it returns it.
BB. Recreate the parameter with the String type so that Parameter Store stops encrypting the value.
CC. Add kms:Encrypt on the parameter's KMS key to the instance role so the value can be read back.
DD. Read the parameter with get-parameters-by-path --recursive on /prod/payments instead of get-parameter.
Show the answer and explanation
Answer: A
A. Right: Correct. SecureString values are returned as ciphertext unless decryption is requested. In the API this is the WithDecryption parameter, and the caller needs kms:Decrypt on the key, which the role already has. Learn more: SecureString parameters (opens in a new tab)
B. Wrong: This would expose the key in plain text to everyone who can read the parameter, which weakens the design. The fix is to request decryption when reading, not to remove encryption.
C. Wrong: Reading a SecureString needs kms:Decrypt, which the role already has. kms:Encrypt would be needed only when writing the value, and it would not change what a plain read returns. Learn more: SecureString parameters (opens in a new tab)
D. Wrong: A path query returns the same ciphertext unless decryption is requested there as well. The option that matters is decryption, not how the parameter is looked up.
Explanation
By default Parameter Store returns a SecureString value as ciphertext. Asking for decryption (--with-decryption in the CLI, WithDecryption in the API) returns the plain value, as long as the caller has kms:Decrypt on the key. Changing the type, adding Encrypt permission or using a path query does not request decryption.
A user edits the app so that it calls GetItem for a note stored under another user's partition key.
What is the result, and why?
Choose one answer.
AA. The request succeeds for reads but is denied for writes, because the condition applies only to PutItem and UpdateItem.
BB. The request is denied, because the condition limits each caller to items whose partition key equals the caller's own identity ID.
CC. The request succeeds, because DynamoDB applies the condition only to attributes named in a projection expression.
DD. The request is denied, because the condition restricts which attributes of an item the caller may read or write.
Show the answer and explanation
Answer: B
A. Wrong: The condition sits on the one statement that allows all four actions, so it applies to reads as well as writes. Reads of another user's partition key do not match and are not allowed. Learn more: IAM conditions for DynamoDB (opens in a new tab)
B. Right: Correct. The dynamodb:LeadingKeys key holds the partition key values a request touches. The policy variable resolves to the caller's identity ID, so only that user's partition is allowed. Learn more: Item-level access by Cognito ID (opens in a new tab)
C. Wrong: Attribute-level limits use a different key, dynamodb:Attributes. LeadingKeys is checked against the partition key values that the request targets, whether or not a projection is used. Learn more: IAM conditions for DynamoDB (opens in a new tab)
D. Wrong: The result is a denial, but the reason is wrong. Controlling which attributes can be accessed is done with dynamodb:Attributes, whereas LeadingKeys limits the partition key values. Learn more: IAM conditions for DynamoDB (opens in a new tab)
Explanation
dynamodb:LeadingKeys matches the partition key values in a request, and ${cognito-identity.amazonaws.com:sub} becomes the caller's own identity ID when the policy is evaluated. A request for another user's partition key therefore falls outside what the statement allows and is denied, whichever of the four actions is used. Attribute limits are a separate condition key.
Want more on Secrets and sensitive data? The 5 full-length practice sets have 15 more Secrets and sensitive data questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →