DVA-C03 security domain explained
Security is 26% of DVA-C03, the same share as on the outgoing DVA-C02, and it is where AWS has added a new task, Task 2.3, on AI security. For a developer, the domain is about securing application code and data: which identity a workload runs as, who may call what, how data is encrypted and where secrets live. The AWS exam guide has three tasks here: authentication and authorisation (2.1), encryption and sensitive data (2.2) and AI security (2.3).
What the domain is about
| Area | What to reason about |
|---|---|
| Identity for workloads | IAM roles for Lambda, ECS tasks and EC2, temporary credentials from STS, least privilege (see AWS IAM basics) |
| Policy evaluation | Identity-based and resource-based policies, explicit deny, cross-account access |
| Encryption | KMS keys and key policies, envelope encryption, encryption at rest and in transit (see cryptography basics) |
| Secrets and configuration | Secrets Manager, Systems Manager Parameter Store |
| User authentication | Cognito user pools and identity pools, API Gateway authorisers |
| Federation and tokens | Identity federation, security tokens, MFA, programmatic access, assuming a role (Task 2.1) |
| Presigned URLs | Time-limited access to S3 objects, and CloudFront signed access; listed by AWS as added content in Task 2.1 |
| Certificates | AWS Certificate Manager and AWS Private CA; generating certificates and SSH keys for development (Task 2.2) |
| Sensitive data | Identifying, masking and limiting access to PII and PHI with AWS services, and using secret management services (Task 2.2) |
| AI security (Task 2.3) | Requesting and managing access to AI services, data privacy with VPC endpoints and no training on your inputs and outputs, filtering model inputs and outputs (content filtering, sensitive information detection, PII/PHI redaction, denied topics, prompt injection protection), AI agent interactions (tool-use authorisation, session isolation, human approval for sensitive actions), sensitive content in monitoring logs |
The guide consolidates the encryption and sensitive-data skills from 13 skills across 2 tasks into 7 skills in 1 task (Task 2.2). Expect questions that combine, say, a key policy with a role rather than separate topics. The guide lists administering IAM users and groups as out of scope: you apply roles and policies, not run identity administration.
How to think about it
Evaluate policies the way AWS does. Everything is denied by default; an explicit deny in any applicable policy beats any allow; and within one account an identity-based or a resource-based allow can be enough, while cross-account access needs the allow on both sides. A workload should never carry access keys: Lambda execution roles, ECS task roles and instance profiles hand out temporary credentials.
For encryption, remember that the KMS Encrypt operation handles only small payloads (up to 4 KB). Larger data uses envelope encryption: GenerateDataKey returns a plaintext data key and an encrypted copy, the application encrypts the data locally, discards the plaintext key and stores the encrypted key beside the data. Key policies are the primary access control for a KMS key, so a role needs both IAM permission and a key policy that permits it (directly or by delegating to IAM).
Secrets Manager and Parameter Store both hold sensitive values. Secrets Manager adds managed rotation for supported secret types; Parameter Store SecureString parameters are encrypted with KMS and suit configuration and simple secrets.
Cognito has two halves. A user pool authenticates users and issues tokens (JWTs). An identity pool exchanges those tokens, or other identity providers, for temporary AWS credentials mapped to an IAM role.
The AI security task applies the same ideas to AI features. The guide’s examples are tool-use authorisation, session isolation and human approval flows for AI agents, VPC endpoints so traffic to AI services stays private (AWS PrivateLink is in scope), ensuring inputs and outputs are not used to train models, content filtering and prompt injection protection, and keeping sensitive content out of monitoring logs. AWS puts selecting foundation models, engineering prompts, designing AI safety frameworks and AI governance out of scope, so the questions are about using and securing AI services from application code, with Amazon Bedrock and Amazon Bedrock AgentCore among the in-scope services.
Worked mini-scenario
A Lambda function must read a database password and write encrypted reports to S3. The password must rotate every 30 days without redeploying code, and reports must use a customer managed KMS key.
Reasoning: store the password in Secrets Manager with rotation enabled, and have the function fetch it at runtime (caching it between invocations). Give the execution role secretsmanager:GetSecretValue on that one secret. For the reports, use SSE-KMS with the customer managed key, and grant the role kms:GenerateDataKey and kms:Decrypt in IAM while the key policy allows the role or delegates to IAM. No access keys, no environment-variable secrets, no wildcard resource.
Easy-to-confuse pairs
| Pair | Distinction |
|---|---|
| Cognito user pool versus identity pool | Pool of users and tokens versus a broker for AWS credentials |
| Secrets Manager versus Parameter Store | Managed rotation and per-secret pricing versus simple hierarchical configuration |
| IAM role versus IAM user | Temporary credentials for workloads versus long-lived credentials for people or legacy tools |
| Key policy versus IAM policy | The key policy is required for KMS access; IAM policies only work if the key policy allows it |
| AWS managed key versus customer managed key | Customer managed keys give control of policy, rotation and audit |
| Identity-based versus resource-based policy | Attached to the caller versus attached to the resource, such as a bucket |
An exam-style pitfall
A scenario shows a role that clearly allows an action, yet the call fails. Candidates add more allows. The better reading checks for an explicit deny, such as a bucket policy condition or a missing key policy grant, before changing the role. Another trap is picking a customer managed key or a custom solution when the question asks for the least operational effort and an AWS managed option meets the requirement.
Own scenario questions
Question 1. A mobile app signs users in and must let each user upload to their own S3 prefix with temporary AWS credentials. Which design fits?
- A. A Cognito user pool only, using its tokens to call S3 directly
- B. A Cognito user pool for sign-in plus an identity pool that maps users to a scoped IAM role
- C. An IAM user access key embedded in the app
- D. A Secrets Manager secret shared by all users
Show answer
Answer: B
A Cognito user pool authenticates users and an identity pool exchanges the resulting token for temporary credentials tied to an IAM role, which can be scoped to the user prefix. A user pool alone does not issue AWS credentials, and embedded IAM user keys are long-lived.
Want more questions like this? Full DVA-C03 practice tests →
Question 2. A Lambda function needs a database password that must rotate automatically every 30 days with the least effort and no code redeployment. Where should the password be stored?
- A. In an encrypted Lambda environment variable
- B. In the deployment package
- C. In a Parameter Store standard parameter, since it rotates values by itself
- D. In AWS Secrets Manager with rotation enabled
Show answer
Answer: D
Secrets Manager supports managed rotation and the function retrieves the current value at runtime. Hard-coding or environment variables require redeploying on each change, and a plain Parameter Store parameter does not rotate by itself.
Want more questions like this? Full DVA-C03 practice tests →
Question 3. A role has an identity policy that allows s3:GetObject on a bucket, but requests fail with AccessDenied. The bucket policy contains a Deny statement whose condition matches these requests. Which statement is correct?
- A. The explicit deny overrides the allow, so the bucket policy or the request must change
- B. The identity policy allow wins because the role is in the same account
- C. The allow must be duplicated in the bucket policy to take effect
- D. A larger set of managed policies on the role will override the deny
Show answer
Answer: A
An explicit deny in any applicable policy overrides every allow. The fix is to change the bucket policy or the request context, not to add more allows to the role. Same-account allows do not beat an explicit deny.
Want more questions like this? Full DVA-C03 practice tests →
Where to go next
Domain 3 turns secured code into running releases: testing and deployment explained. The sample questions mix all four domains.