Study DVA-C02 Security: key concepts, common traps, and exam decision cues.
Security on DVA-C02 stays in the developer lane. AWS is not asking you to run enterprise-wide identity governance. It is asking whether your application authenticates correctly, authorizes narrowly, encrypts data properly, and avoids leaking secrets or tenant data through bad code decisions.
I verified the current DVA-C02 Domain 2 task statements on May 11, 2026. AWS currently expresses this domain as three task statements:
AWS currently weights Security at 26% of scored content.
Most misses here happen because candidates collapse different security layers into one vague idea of “secure enough.” This domain is really asking whether you can separate:
| Lesson | AWS task fit | Why it matters |
|---|---|---|
| 2.1 Federated Access, IAM Roles & App Authorization | Task 2.1 | This is the identity lane: user auth, federated access, bearer tokens, runtime roles, signed AWS requests, and app-level authorization. |
| 2.2 Encryption at Rest, In Transit & Key Management | Task 2.2 | This is the encryption lane: at rest versus in transit, KMS usage, certificate handling, and service access versus decrypt rights. |
| 2.3 Secrets, Sensitive Data, Masking & Multi-Tenant Access | Task 2.3 | This is the sensitive-data lane: secret retrieval, masking, log hygiene, and tenant-safe data access in application code. |
| If the question is really about… | Go first to… |
|---|---|
| tokens, Cognito, IAM roles, signed requests, or app-level permissions | 2.1 Federated Access, IAM Roles & App Authorization |
| KMS keys, TLS or certificates, client-side versus server-side encryption, or key rotation | 2.2 Encryption at Rest, In Transit & Key Management |
| Secrets Manager, Parameter Store, PII handling, sanitization, or tenant-isolation mistakes | 2.3 Secrets, Sensitive Data, Masking & Multi-Tenant Access |
| Symptom | What is usually going wrong | Fix first |
|---|---|---|
| IAM stems feel too abstract | you are mixing user sign-in, AWS API credentials, and app permissions together | rework 2.1 and classify the caller first |
| every encryption answer sounds right | you are not separating at-rest, in-transit, and key-governance requirements | rework 2.2 and map each control to the exact problem it solves |
| secrets and masking blur together | you are treating every sensitive-data problem as a storage problem | rework 2.3 and separate credentials, confidential payloads, logs, and tenant boundaries |
| you keep choosing broad permissions | you are optimizing for convenience instead of blast-radius reduction | prefer temporary credentials, narrow scope, and explicit isolation boundaries |
Make sure you can explain:
Then move to 3. Deployment, because AWS often turns secure app design into release-path questions about environment configuration, rollout safety, or rollback control.