AWS Security for the Developer Associate (DVA-C02): IAM, Cognito, KMS, Secrets Manager & Encryption

Introduction

The Security domain is the second-largest section of the AWS Certified Developer – Associate (DVA-C02) exam, worth 26% of your score — more than Deployment and more than Troubleshooting. Yet it’s the domain most developers under-prepare for, because security feels like “the platform team’s problem.” On the exam, it is squarely your problem: how does your Lambda function read a database password without hard-coding it? How does your app authenticate end users? How do you encrypt an object in S3 with a key you control?

These aren’t abstract governance questions. They’re concrete, code-adjacent decisions the DVA-C02 tests through scenario questions like: “A Lambda function needs to read a secret that rotates every 30 days. Which service should store it?” or “An application must let users sign in with Google and then call DynamoDB. Which Cognito component issues the temporary AWS credentials?” Answer those correctly and the Security domain becomes some of the most reliable points on the exam.

This guide covers the Security domain the way the DVA-C02 frames it: identity and access with IAM and STS, encryption with KMS, secret storage with Secrets Manager and Parameter Store, and end-user authentication with Cognito. Each section focuses on the decisions and distinctions the exam actually tests. Pair it with the full DVA-C02 exam topics breakdown to see where security sits in the overall blueprint.

Why Security Is 26% of the Exam

The DVA-C02 is built for people who write applications that run on AWS, and modern AWS applications are assembled from managed services that all need to authenticate and authorize each other. A typical request path — API Gateway → Lambda → DynamoDB → S3 → KMS — crosses an identity boundary at every hop. The exam wants to know that you can wire those boundaries correctly without resorting to long-lived access keys pasted into your code.

Three principles run through every security question:

Never embed long-lived credentials in code. Use IAM roles and temporary credentials instead of access keys.
Grant least privilege. Scope every policy to the specific actions and resources needed.
Encrypt by default. Know the difference between server-side and client-side encryption, and how KMS manages the keys.

If a multiple-choice answer involves hard-coding an access key, storing a password in an environment variable in plaintext, or attaching AdministratorAccess to a Lambda, it’s almost always wrong. The exam rewards the secure, least-privilege option even when a lazier one would technically work.

IAM: Users, Roles, and Policies

IAM (Identity and Access Management) is the foundation. You must be fluent in its core objects:

Object	What it is	When to use
User	A long-lived identity for a human or legacy app	Real people; avoid for applications
Group	A collection of users sharing permissions	Organizing human users by team/role
Role	An identity assumed temporarily, no permanent credentials	Applications, EC2, Lambda, cross-account access
Policy	A JSON document granting/denying permissions	Attached to users, groups, or roles

The single most important exam concept: applications use roles, not users. When a Lambda function, EC2 instance, or ECS task needs to call AWS, it assumes an IAM role and receives temporary credentials automatically — no access keys in your code, no secrets to rotate. An EC2 instance gets this through an instance profile; Lambda gets it through its execution role.

A policy is JSON with a few key elements:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOneBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

Memorize the structure: Effect (Allow/Deny), Action (the API calls), Resource (the ARNs), and optionally Condition. Two evaluation rules the exam loves:

An explicit Deny always wins over any Allow, no matter where it appears.
Everything is implicitly denied by default; you must explicitly Allow what you want.

Know the difference between identity-based policies (attached to a user/role/group) and resource-based policies (attached to the resource itself — like an S3 bucket policy or an SQS queue policy). Resource-based policies are how you grant cross-account access and how services like S3 or Lambda permit other principals to act on them.

STS and Temporary Credentials

AWS STS (Security Token Service) is the engine behind roles. When a principal assumes a role, STS issues short-lived credentials (an access key, secret key, and session token) that expire automatically — typically in 15 minutes to a few hours. This is the mechanism the exam wants you to reach for instead of permanent keys.

The core API is AssumeRole. Key scenarios:

Cross-account access: a role in account B trusts a principal in account A; the app in A calls AssumeRole to get temporary access to B.
Identity federation: external identities (corporate SSO, Google, Facebook) are exchanged for AWS credentials via AssumeRoleWithWebIdentity or AssumeRoleWithSAML.
Privilege separation: a base role assumes a more privileged role only when needed.

The takeaway for the exam: temporary credentials from STS are always preferred over long-lived IAM user access keys. If a question describes credentials that expire, or “assuming a role,” STS is involved.

Encryption: Server-Side vs Client-Side

Encryption questions hinge on where the encryption happens:

Server-side encryption (SSE): data is encrypted by the AWS service after it receives it and decrypted before it returns it. The service handles the crypto; you just pick the key. Examples: SSE-S3, SSE-KMS, SSE-C.
Client-side encryption: you encrypt data in your application before sending it to AWS. AWS never sees the plaintext. You manage the keys and the crypto.

For S3 specifically, know the three server-side flavors:

Option	Who manages the key	When to use
SSE-S3	AWS, fully managed (AES-256)	Simple encryption at rest, no key control needed
SSE-KMS	AWS KMS, you control the CMK	Audit trail, key rotation, fine-grained access
SSE-C	You provide the key on each request	You want to hold the keys but let S3 do the crypto

SSE-KMS is the exam’s favorite because it gives you an audit trail (every decrypt is logged in CloudTrail) and access control via key policies. Also remember: encryption in transit is handled by TLS/HTTPS — a separate concern from encryption at rest.

KMS Deep Dive

AWS KMS (Key Management Service) manages encryption keys. The DVA-C02 expects real understanding here, not just name recognition.

A KMS key (formerly “customer master key” / CMK) never leaves KMS unencrypted. You don’t use it to encrypt large data directly — KMS only encrypts payloads up to 4 KB. For anything larger, you use envelope encryption:

Your app calls GenerateDataKey. KMS returns a data key in two forms: plaintext and encrypted-under-the-KMS-key.
Your app uses the plaintext data key to encrypt the actual data locally.
Your app stores the encrypted data key alongside the ciphertext and discards the plaintext data key from memory.
To decrypt, your app sends the encrypted data key to KMS Decrypt, gets the plaintext data key back, and decrypts the data.

This pattern — encrypt the data with a data key, encrypt the data key with the KMS key — is envelope encryption, and it’s one of the most heavily tested KMS concepts. The whole point: the small KMS key protects the data keys, and the data keys protect the bulk data.

Other KMS details the exam tests:

Key types: AWS-managed keys (created and rotated by AWS for a service), customer-managed keys (you control policy and rotation), and AWS-owned keys (invisible, shared).
Key rotation: customer-managed keys support automatic annual rotation; the old key material is retained so existing ciphertext still decrypts.
Access control: governed by a key policy (resource-based, on the key itself) combined with IAM policies. A principal needs permission in both unless the key policy delegates to IAM.
Grants: a flexible, temporary way to delegate KMS permissions to a principal for specific operations — useful for services acting on your behalf.

If a question mentions encrypting “a 1 GB file” or “a large object” with KMS, the answer involves GenerateDataKey and envelope encryption — not encrypting the object directly with the KMS key.

Storing Secrets: Secrets Manager vs Parameter Store

Applications need passwords, API keys, and connection strings. The exam tests two services, and the distinction matters:

Feature	Secrets Manager	SSM Parameter Store
Primary purpose	Storing and rotating secrets	Config + secrets storage
Automatic rotation	Yes, built-in (with Lambda)	No native rotation
Cost	Per secret + per API call	Standard tier is free
Encryption	KMS, always	KMS for `SecureString` type
Cross-account sharing	Yes (resource policy)	Advanced tier
Best for	DB credentials that rotate	App config, feature flags, simple secrets

The decision rule: need automatic rotation or RDS-integrated credential management → Secrets Manager. Need cheap or free config and simple secrets → Parameter Store with the SecureString type. A question that emphasizes “rotates every 30 days” or “automatically rotates the database password” is pointing at Secrets Manager. A question that emphasizes “cost-effective” or “store configuration values” is pointing at Parameter Store.

In both cases, your Lambda or app reads the secret at runtime via the SDK, using its IAM role for access — never bake the secret into an environment variable or the deployment package. This connects to the DVA-C02 serverless guide: a Lambda’s execution role grants it permission to call secretsmanager:GetSecretValue or ssm:GetParameter.

Amazon Cognito: Authenticating End Users

IAM secures your AWS resources and your team. Cognito secures your application’s end users — the people signing up and logging into your mobile or web app. The exam’s central distinction is between its two components:

User Pools = authentication (who you are). A user pool is a managed user directory: sign-up, sign-in, password policies, MFA, and federation with social or SAML providers. On successful login, it issues JWT tokens (ID, access, refresh). Think “the login screen and user database.”
Identity Pools (Federated Identities) = authorization to AWS (what you can touch). An identity pool exchanges a token (from a user pool or an external provider like Google) for temporary AWS credentials via STS, so the user’s app can call AWS services like S3 or DynamoDB directly.

The canonical flow: a user signs in through a user pool, receives a JWT, hands that JWT to an identity pool, and gets back temporary AWS credentials scoped by an IAM role. The mnemonic that saves you on exam day:

User Pool = who you are. Identity Pool = what you can do (in AWS).

If a question is about logging users in, MFA, or social sign-in, it’s a user pool. If it’s about giving those logged-in users temporary AWS credentials to access S3/DynamoDB directly, it’s an identity pool.

Securing Your Application Layer

A few application-layer security topics round out the domain:

API Gateway authorization: protect an API with IAM (SigV4-signed requests), a Cognito user pool authorizer (validate the JWT), or a Lambda authorizer (custom token logic). Match the method to the scenario — Cognito authorizer for app users, IAM for service-to-service.
Lambda execution role: every Lambda runs with an IAM role granting exactly the permissions it needs. Least privilege here is constantly tested.
Environment variable encryption: Lambda environment variables can be encrypted with KMS — but secrets that rotate still belong in Secrets Manager, not env vars.
CloudTrail vs CloudWatch: CloudTrail records who did what (API calls, auditing); CloudWatch records metrics and logs (performance, application output). Security questions about “who deleted this resource” point to CloudTrail.

Common Exam Traps

Trap	Reality
Hard-coding access keys in Lambda	Use the execution role — never embed keys
Using SSE-KMS to encrypt a 1 GB file directly	KMS only does ≤4 KB; use envelope encryption (`GenerateDataKey`)
Storing a rotating DB password in Parameter Store	Use Secrets Manager for automatic rotation
User pool issues AWS credentials	No — identity pools issue AWS credentials; user pools issue JWTs
`AdministratorAccess` on an app role	Always least privilege — scope to specific actions/resources
Allow + Deny on the same action = allowed	Explicit Deny always wins

Frequently Asked Questions

How much of the DVA-C02 is security?

The Security domain is 26% of the exam — the second-largest domain after “Development with AWS Services” (32%). Roughly one in four questions touches IAM, KMS, encryption, secrets, or Cognito, so it’s worth deliberate study rather than hoping your day-job knowledge covers it.

What’s the difference between Cognito user pools and identity pools?

User pools handle authentication — they’re a managed user directory that signs users in and issues JWT tokens. Identity pools handle authorization to AWS — they exchange a token for temporary AWS credentials via STS so users can call AWS services directly. User pool = who you are; identity pool = what AWS resources you can access.

When should I use Secrets Manager instead of Parameter Store?

Use Secrets Manager when you need automatic rotation (especially for RDS database credentials) or cross-account secret sharing. Use Parameter Store (SecureString) when you want a free or low-cost place to keep configuration and simple secrets that don’t rotate. The exam signals Secrets Manager with the word “rotate” and Parameter Store with “cost-effective.”

What is envelope encryption in KMS?

Because a KMS key can only encrypt payloads up to 4 KB, you encrypt large data with a data key generated by GenerateDataKey, then encrypt that data key with the KMS key and store it alongside the ciphertext. The KMS key protects the data key; the data key protects the bulk data. This two-layer pattern is envelope encryption, and it’s heavily tested.

Should applications use IAM users or roles?

Always roles. Applications, Lambda functions, EC2 instances, and ECS tasks should assume an IAM role and receive temporary credentials automatically — no long-lived access keys to embed or rotate. IAM users with access keys are a red flag in almost every exam scenario involving application code.

Does the DVA-C02 require writing IAM policies by hand?

You won’t write full policies from scratch, but you must read them fluently — identify the Effect, Action, and Resource, spot an overly broad permission, and apply the rules that explicit Deny wins and everything is denied by default. Practicing with real policy JSON is the fastest way to get comfortable.

Conclusion

The Security domain is 26% of the DVA-C02 and rewards a handful of clear distinctions: roles over users, temporary credentials over access keys, envelope encryption for anything over 4 KB, Secrets Manager when rotation matters, and the user-pool-versus-identity-pool split in Cognito. Internalize the decision rules and the traps table above, and security shifts from your weakest domain to a dependable source of points.

From here, connect security to the rest of the blueprint: see how execution roles and secret retrieval work in the DVA-C02 serverless guide, review the full exam topics breakdown, and sequence everything with the DVA-C02 study plan. Then pressure-test your knowledge against realistic, scenario-driven questions in the AWS Developer Associate Mock Exam Bundle — every question comes with a detailed explanation, so you don’t just learn that identity pools issue AWS credentials, you learn why — which is exactly what the exam rewards.