DVA-C02 Secrets, Sensitive Data, Masking and Multi-Tenant Access Guide

This lesson is about the mistakes developers create when sensitive-data handling is treated as an afterthought. DVA-C02 wants you to know where secrets belong, how to avoid leaking sensitive information into logs or code, and how tenant-aware access patterns differ from simple authenticated reads.

Secret management service: Managed store for credentials, tokens, or other sensitive configuration that should not live directly in source code or plain-text config.

Data masking: Technique that hides or transforms sensitive values so they are not fully exposed to users, logs, or downstream systems.

What AWS is really testing here

AWS wants you to recognize:

• hard-coded secrets versus managed secret retrieval
• encrypted environment variables versus plain-text config leakage
• data classification and masking requirements
• multi-tenant access control as an application design problem, not only an identity problem
• sanitization as a code-path responsibility, not just a logging option

Choose the right sensitive-data control

Secrets and masking solve different problems

    flowchart TD
	    A["Sensitive value or data"] --> B{"What kind of problem is it?"}
	    B -->|"Credential or token storage"| C["Use managed secret retrieval"]
	    B -->|"Visible in output or logs"| D["Mask or sanitize the value"]
	    B -->|"Wrong tenant can see it"| E["Enforce tenant-scoped authorization and filtering"]
	    B -->|"Runtime setting contains secret"| F["Encrypt and control access to env config"]

Strong answers usually separate:

• where the secret is stored
• who can retrieve it
• what should be shown back to users
• which records a tenant is allowed to access

Managed retrieval beats embedded secrets

Current Domain 2 explicitly includes sensitive-data handling inside application code. That means the exam cares about the code path, not just the control plane.

Simple Python example:

1import boto3
2
3client = boto3.client("secretsmanager")
4
5def get_db_password(secret_name: str) -> str:
6    response = client.get_secret_value(SecretId=secret_name)
7    return response["SecretString"]

The lesson is straightforward: retrieve secrets through a managed path at runtime instead of hard-coding them into source, config files, or container images.

Log hygiene and output masking

Sensitive data often leaks through:

• debug logging
• traces and structured logs
• error responses
• support dashboards
• exported CSV or JSON payloads

If the requirement is “show only the last four digits” or “avoid exposing the full identifier,” the answer lane is usually masking or sanitization, not KMS or IAM alone.

Multi-tenant mistakes are usually authorization mistakes

If the question says users are authenticated but can still reach the wrong tenant’s data, the stronger answer is usually not “rotate the key” or “add TLS.” The real problem is that the application has not enforced tenant-aware authorization or filtered access paths correctly.

In practical terms, the backend should derive tenant scope from trusted identity context, not from a caller-supplied field that can be changed in the request.

Common traps

Decision order that usually wins

1. Separate secret storage, data masking, and tenant authorization.
2. If credentials sit in source or config, move them to a managed secrets path first.
3. If sensitive values should be partially shown, think masking or sanitization, not IAM alone.
4. If a user can pivot into another tenant’s data, stay in the tenant-scoped authorization lane.
5. Keep these controls distinct because DVA-C02 uses one sensitive-data problem to distract from another.

Quiz