DVA-C02 - Security (26% of the exam) - Section 2.8

Handle sensitive data in application code through data classification, sanitisation and secure credential handling to protect PII and PHI.

Classify data by sensitivity level - distinguishing personally identifiable information and protected health information from general application data - and apply sanitisation before storing or logging it. Handle credentials in application code by reading them from secure stores at runtime rather than embedding them in source or config files.

Data classificationPersonally identifiable informationCredential handlingData sanitisation

Practice question for this objective

Free sampleSecuritymedium

An application logs the full request body to Amazon CloudWatch Logs to help with debugging. The bodies sometimes contain personally identifiable information such as email addresses and national identity numbers. A developer must stop this sensitive data from being readable in the logs while keeping the surrounding log entries useful. What is the most appropriate approach in application code and logging configuration?

ALeave the logging as it is but restrict the log group with an IAM policy so only administrators can read it, since access control alone satisfies the requirement to protect the PII.
BEncrypt the entire log group with a customer managed KMS key, because encryption at rest renders the personally identifiable information unreadable to anyone who later queries the logs.
CSanitise the request body in code before logging by removing or masking the PII fields, and enable a CloudWatch Logs data protection policy to mask sensitive patterns at rest. Correct
DLower the application log level to error so the verbose request bodies are dropped, which prevents any personally identifiable information from ever reaching the log group.

Sanitise PII in application code before logging and apply a CloudWatch Logs data protection policy to mask sensitive data at rest. Removing or masking PII fields in code stops the sensitive values from being written, and a CloudWatch Logs data protection policy detects and masks known sensitive data types in any entries that slip through, so the logs keep useful context while the personally identifiable information stays unreadable.

Why A is wrong: Tight access control is useful but the PII is still stored in clear text, so anyone with read access sees it and the data remains exposed, which does not meet the requirement to make it unreadable.

Why B is wrong: KMS encryption protects logs at rest but authorised readers see fully decrypted entries including the PII, so encryption alone does not redact or mask the sensitive fields in query results.

Why C is correct: Redacting PII in code before it is written plus a CloudWatch Logs data protection policy that masks known sensitive data types gives defence in depth, keeping non sensitive context while hiding PII.

Why D is wrong: Raising the log level reduces volume but error entries can still carry request bodies with PII, so it neither reliably removes the sensitive fields nor preserves useful debugging context.

See more DVA-C02 practice questions, answers explained.

Exam traps in Security

Answers that look right on this material and are not. Each one is a distractor from a different question in the DVA-C02 bank for this domain.

Store the identifier base64-encoded in the application table so it is not human-readable in casual database browsing.
Why it is wrong: Base64 is reversible encoding, not protection, so the plaintext PHI is trivially recovered and still sits in the primary store.
Raise the log level to ERROR so the request body is only written when an exception occurs, which reduces how often the sensitive fields appear in CloudWatch Logs.
Why it is wrong: Lowering log frequency still writes the raw PII whenever an error fires, so the sensitive data remains readable and the leak is not removed.
Configure AWS Config rules to evaluate each S3 object and flag the ones whose contents include passport or credit card numbers as non-compliant resources.
Why it is wrong: AWS Config evaluates resource configuration and compliance state, not the contents of objects, so it cannot detect PII inside the files.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.