Security
Sensitive Data, Managed Secrets, Sanitization, and Tenant Isolation
CoreClassify and protect sensitive data in code with the correct configuration, secret, masking, sanitization, and multi-tenant access boundary.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
Sensitive-data failures often occur after encryption is enabled: a secret is committed, a token appears in logs, untrusted input reaches a dangerous sink, or one tenant can construct another tenant’s key. Developers must protect the whole data path.
Must Know
- Classify data such as PII and PHI according to its meaning and handling requirements, then apply storage, transport, access, logging, and retention controls consistently.
- Lambda encrypts environment variables at rest, and a customer managed KMS key can control access, but a rotating credential is better retrieved from a managed secret service than embedded as configuration.
- AWS Secrets Manager centralizes secret storage, access control, retrieval, and supported rotation workflows. Application code retrieves the current value under its workload role.
- Secret caching can reduce repeated retrieval, but the cache lifetime and refresh behavior must allow rotated values to take effect.
- Sanitization validates, rejects, escapes, removes, or transforms unsafe input before it reaches a log, output, query, command, or downstream service.
- Masking or redaction limits what a user or log consumer can see; it is not a replacement for encryption of stored or transmitted data.
- Multi-tenant access must derive tenant context from a trusted identity and enforce it in authorization, data keys, queries, and cache keys.
- Never rely on a client-supplied tenant ID, a UI restriction, or a response-time filter as the sole isolation boundary.
Compare and Distinguish
- Managed secret vs encrypted environment variable: Secrets Manager supplies retrieval and rotation lifecycle; an environment variable is runtime configuration protected at rest.
- Masking vs sanitization vs encryption: masking limits exposure, sanitization handles unsafe content, and encryption cryptographically protects data.
- Classification vs protection: classification identifies handling requirements; it does not itself enforce them.
- Tenant-aware key vs result filtering: a trusted tenant dimension in the authorized access path prevents cross-tenant retrieval; filtering after broad access can leak data.
- KMS rotation vs secret rotation: key-material rotation preserves KMS cryptographic history; secret rotation updates the credential in both the secret and its target.
Scenario examples
- Scenario: A database password changes regularly. Store it in Secrets Manager, authorize the workload role, configure supported rotation, and refresh cached values appropriately.
- Scenario: Logs need a correlation ID and last four identifier characters. Emit structured safe fields and mask the classified identifier before logging.
- Scenario: A user supplies a string that will reach a command or query boundary. Validate against the accepted form and use the destination’s safe parameterization or escaping mechanism.
- Scenario: One DynamoDB table stores multiple tenants. Derive tenant identity from validated claims and make it part of the authorized key and cache path.
Exam traps
- Encrypting a secret in source control does not create managed rotation or safe key distribution.
- KMS encryption of an environment variable does not eliminate the need to restrict who can read it at runtime.
- Hashing or encryption is not input sanitization.
- Logging a raw sensitive value and deleting it later is still an exposure.
- Authentication alone does not prove the caller owns the requested tenant or record.
- A shared cache key can bypass otherwise correct tenant-aware database access.
Key takeaways
- Let data classification drive protection and logging rules.
- Choose managed secrets for credentials that need controlled retrieval and rotation.
- Sanitize before unsafe use and mask before display or emission.
- Enforce tenant boundaries from trusted identity through authorization, storage, and caching.
- Keep least privilege and observability without exposing the protected data.
How it works
- The application classifies incoming and stored fields and accepts only valid input forms.
- The workload role retrieves managed secrets and KMS protects configured encrypted values as required.
- Trusted identity context constrains application authorization, data-store keys, queries, and cache entries.
- Outputs and telemetry are masked or redacted before leaving the application boundary.
When to use it
- Use Secrets Manager for credentials and other secrets that need centralized access and supported rotation.
- Use protected environment configuration for sensitive values whose lifecycle fits deployment/runtime configuration and does not need secret-management features.
- Use masking when limited display is allowed, and sanitization when content must be made safe for its destination.
- Use tenant-aware access paths for every multi-tenant read, write, cache, and search operation.
Security and governance implications
- Grant secret and KMS access only to the workload that needs the value.
- Do not expose secrets through environment dumps, traces, exception messages, test fixtures, or deployment output.
- Validate tenant claims from a trusted issuer and prevent callers from overriding them.
- Rotate, revoke, and audit credentials according to their real target-service lifecycle.
Failure signals and diagnosis
- For authentication failure after rotation, inspect secret version staging, target credential state, and application cache refresh.
- For a KMS error on an environment value, inspect function role access and the selected customer managed key.
- For unsafe logs, identify the emission point and redact before ingestion rather than relying on later deletion.
- For tenant leakage, inspect claims, authorization, constructed keys, secondary indexes, and cache key scope end to end.
More detail
- A developer implements the minimum controls required by classification; the exam does not require designing an organization-wide compliance program.
- Secret retrieval failures and target-authentication failures are separate: the application may read a stale secret even though IAM access succeeds.
- Structured logs should preserve useful context such as action, outcome, timestamp, and correlation while removing protected values.
- Tenant isolation is an authorization and data-access property, not only a database schema property.
Ready for the quiz?
- When is an encrypted environment variable insufficient for a credential?
- What changes during Secrets Manager rotation?
- How do masking and sanitization differ?
- Why must a tenant cache key include trusted tenant context?
- Which fields should a structured security-safe log retain?
Related objectives
- D2.3 — Manage sensitive data in application code
- 2.3.1 — Describe data classification (for example, personally identifiable information [PII], protected health information [PHI])
- 2.3.2 — Encrypt environment variables that contain sensitive data
- 2.3.3 — Use secret management services to secure sensitive data
- 2.3.4 — Sanitize sensitive data
- 2.3.5 — Implement application-level data masking and sanitization
- 2.3.6 — Implement data access patterns for multi-tenant applications