Browse AWS Certification Guides

DVA-C02 Security Guide

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.

Current weight in the exam guide

AWS currently weights Security at 26% of scored content.

What this domain is really testing

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:

  • user identity from workload identity
  • authentication from authorization
  • secrets storage from data encryption
  • tenant isolation from generic least privilege

Work this domain in order

Lesson Focus
2.1 Federated Access, IAM Roles & App Authorization Learn how applications authenticate users, assume roles, sign AWS calls, and enforce fine-grained authorization.
2.2 Encryption at Rest, In Transit & Key Management Learn how KMS, certificates, rotation, and cross-account encryption decisions change application behavior.
2.3 Secrets, Sensitive Data, Masking & Multi-Tenant Access Learn how to store secrets safely, sanitize or mask data, and separate tenant access paths correctly.

Fast routing inside this chapter

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

If you keep missing questions in this domain

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

What strong answers usually do

  • prefer temporary credentials and roles over embedded long-term secrets
  • keep authentication and authorization as separate questions
  • treat KMS policy, IAM policy, and resource policy as distinct control points
  • protect sensitive data in code, logs, and downstream data stores instead of only at the perimeter

Common DVA-C02 traps in this domain

  • assuming Cognito, IAM roles, and resource policies solve the same problem
  • choosing encryption when the real problem is secret retrieval, tenancy, or app-level authorization
  • treating KMS as a generic answer even when TLS, certificate choice, or service configuration is the real issue
  • forgetting that sensitive data can leak through logs, traces, caches, and debug output

Before you leave this domain

Make sure you can explain:

  1. who is calling the application
  2. what temporary credentials or tokens they should use
  3. where authorization is enforced
  4. where secrets live
  5. how sensitive data stays separated in logs, storage, and tenant paths

Then move to 3. Deployment, because AWS often turns secure app design into release-path questions about environment configuration, rollout safety, or rollback control.

In this section

Revised on Sunday, May 10, 2026
1. Dev
3. Deploy