Chapter 2

Security

AWS Certified Developer – Associate (DVA-C03) Study GuideDomain 2 · 26% of the examBased on the official DVA-C03 exam objectives

Security is the second-largest domain on the DVA-C03 exam at 26% of the scored content. It tests whether you can build applications that authenticate users correctly, authorize access with least privilege, protect data with the right encryption and secrets tooling, and keep traffic off the public internet. DVA-C03 also reorganizes this domain: the older encryption and sensitive-data tasks are merged into a single task, and a new task - Task 2.3 - covers securing applications that integrate AI services such as Amazon Bedrock. That AI security material is covered in section 2.4 and is genuinely new, so give it more study time than its size suggests.

Everything in this chapter follows one principle you will see repeated in exam questions: grant the minimum access needed, for the minimum time needed, and protect data at every layer - in transit, at rest, and in your logs.

2.1 IAM for developers

AWS Identity and Access Management (IAM) is the foundation of every security question on this exam. As a developer you rarely administer IAM for a whole organization, but you constantly write policies, create roles for your code, and debug access-denied errors. The exam expects you to do all three fluently.

Principals, policies, and roles

A principal is the entity making a request: an IAM user, an IAM role session, a federated user, or an AWS service.

Requests are evaluated against policies, which are JSON documents containing statements with an effect (Allow or Deny), actions, resources, and optional conditions.

The policy types you must be able to distinguish are:

Two facts are tested relentlessly. First, boundaries and SCPs never grant permissions - they only cap them. A role with an administrator identity policy but a restrictive permissions boundary has only the boundary's permissions. Second, resource-based policies are the only way to grant cross-account access to a principal directly; an identity policy in account A cannot grant a user in account B anything unless the resource in account

B also trusts that principal (or the user assumes a role in account B).

How a request is evaluated

When a request arrives, IAM evaluates it in a defined order. You do not need to memorize the full flowchart, but you do need the decision logic:

1. Explicit Deny wins over everything. If any applicable policy contains a Deny for the action and resource, the request is denied, no matter what else allows it.

2. Organization SCPs and RCPs are evaluated next; if they do not allow the action, the request stops there.

3. Resource-based policies on the target resource are evaluated; for same-account access, an allow in a resource-based policy can be sufficient on its own.

4. A permissions boundary, if present, must allow the action.

5. A session policy, if present, must allow the action.

6. Finally, an identity-based policy must allow the action (for same-account resource-based access, step 3 may already have allowed it).

The practical debugging sequence mirrors this: when code gets an AccessDenied error, look first for an explicit deny, then check whether the identity policy actually allows the action on that exact resource ARN, and only then suspect boundaries or SCPs.

Roles and least privilege

Long-lived IAM users with embedded access keys are an anti-pattern the exam wants you to eliminate.

If a question says a user has an Allow policy but is still denied, the expected answer is almost always an explicit

Deny somewhere, a permissions boundary, or an SCP. IAM is eventually consistent - changes take a short time to replicate - but a lasting denial comes from policy evaluation, not propagation.

Applications running on AWS should use IAM roles:

• A Lambda execution role grants the function permissions to write logs and access services such as

DynamoDB, SQS, or S3. Attach the policy to the role, never embed credentials in function code or environment variables.

• An ECS task role grants the application code in a container its AWS permissions. This is separate from the

task execution role, which the ECS agent uses to pull images and write logs. Confusing these two roles is a classic exam trap: if the container starts but the application cannot call DynamoDB, the task role is wrong; if the container never starts, check the execution role.

• EC2 instance profiles deliver role credentials to applications on instances through the instance metadata

service. Prefer IMDSv2 (token-based) and note that applications retrieve temporary credentials automatically through the SDK.

Least privilege tooling the exam expects you to know:

• IAM Access Analyzer generates least-privilege policies based on a principal's actual CloudTrail activity, and

its unused access findings flag roles, users, and permissions that have not been used. External access findings show which of your resources are accessible from outside your account or organization.

• Policy validation with Access Analyzer catches syntax errors and warns about overly permissive grants

before you deploy.

• Condition keys such as aws:SourceVpce, aws:PrincipalTag, aws:RequestTag and service-specific keys

let you narrow a statement without creating more policies.

AWS STS and temporary credentials

The AWS Security Token Service (STS) issues short-lived credentials: an access key ID, a secret access key, and a session token. Every role assumption and every federated sign-in produces temporary credentials. Key operations and limits:

Details that appear in questions:

• Durations can be as short as 15 minutes. Shorter is safer; credentials expire automatically and cannot be

revoked individually before expiry (you can deny sessions created before a point in time using the

aws:TokenIssueTime condition on the role's trust or attached policies).

• A role's maximum session duration (1-12 hours) caps what any caller can request, whatever the caller

asks for.

• Role chaining - assuming a second role from a role session - is limited to a 1-hour maximum session.
• Cross-account access follows a fixed pattern: the trusting account creates a role whose trust policy names

the other account; a principal in the trusted account needs an identity policy allowing sts:AssumeRole on that role's ARN. Both sides are required.

Common trap: A trust policy alone does not grant anyone access. It only says who may assume the role. The caller's own account must also allow the sts:AssumeRole call.

2.2 Amazon Cognito and API authorization

User pools vs identity pools

Amazon Cognito has two components with confusingly similar names and completely different jobs. Getting this distinction right is worth several questions by itself.

A standard exam architecture uses both: the app authenticates against a user pool, sends the resulting ID token to the identity pool, and receives temporary credentials scoped to an IAM role - for example, permissions to read only the user's own prefix in an S3 bucket, enforced with a policy variable such as

${cognito-identity.amazonaws.com:sub}.

User pool facts to know precisely:

• The ID token carries identity claims (username, email, groups) and proves who the user is; the access

token carries scopes and is used to authorize calls to APIs and to the user pool itself; the refresh token obtains new ID and access tokens without a new sign-in.

• Token validity is configurable: access and ID tokens from 5 minutes to 1 day (default 1 hour); refresh tokens

from 1 hour to 10 years (default 30 days).

• Groups in a user pool can be mapped to IAM roles through the identity pool, and group claims in the ID

token can drive authorization logic in your API.

• Lambda triggers hook the authentication lifecycle - pre sign-up validation, custom authentication

challenges, pre token generation (to add claims), post authentication logging, and custom messages for verification codes.

• MFA options include SMS, email, and time-based one-time passwords (TOTP). Adaptive authentication and

compromised-credential checks are part of Cognito's advanced security features.

• The hosted UI provides a ready-made sign-in/sign-up flow and handles OAuth 2.0 authorization code and

implicit grants, plus logout.

Authorizing API Gateway APIs

REST APIs in Amazon API Gateway support several authorization mechanisms, and the exam tests whether you can pick the right one for a stated caller type.

Numbered walkthrough - how a Lambda authorizer request flows:

1. The client calls the API with a token (typically in the Authorization header).

2. API Gateway invokes your authorizer function with the token (TOKEN type) or the full request context

(REQUEST type).

3. Your function validates the token - signature, issuer, expiry, claims - and builds an IAM policy document allowing or denying API methods.

4. API Gateway evaluates the returned policy and either forwards the request to the integration or returns

401/403.

5. Results are cached by token (default TTL 300 seconds, configurable up to 3,600) so the function is not invoked on every call. A consequence: a revoked token may still work until the cache entry expires.

Key traps and details:

• A Lambda authorizer must return a policy document whose resource ARNs match the methods being

authorized; a policy that allows only one method will deny others even with a valid token. Returning a policy covering the whole API stage (execute-api:/stage/*/*) is the usual pattern when caching is enabled.

• HTTP APIs use JWT authorizers (any OIDC issuer, including user pools) and Lambda authorizers, but not

the Cognito-specific authorizer type or IAM in exactly the same way as REST APIs - when a question specifies HTTP API plus a user pool, "JWT authorizer" is the expected term.

• API keys identify a client application for usage plans and throttling; they are not an authorization

mechanism and should never be the answer to "how do you secure this API."

• Mutual TLS (mTLS) on custom domains authenticates clients by certificate and is the answer when a

question requires certificate-based client identity.

2.3 Encryption and sensitive data

In DVA-C03, encryption and sensitive-data protection are one merged task. The exam expects you to choose the right key type, the right store for each kind of secret, and the right S3 encryption option - and to explain the trade-offs when a question imposes a constraint such as "the compliance team must be able to audit every key use" or "rotate this credential automatically."

AWS KMS and envelope encryption

AWS Key Management Service (KMS) creates and controls encryption keys. The data keys and key material concepts are heavily tested.

Key ownership types:

Non-negotiable KMS facts:

• Every KMS key must have a key policy, and the default key policy gives the account root user full access,

which is what makes IAM policies able to delegate key permissions. If a key policy does not enable IAM delegation and grants no one access, the key becomes unmanageable.

• Callers need permission from both sides when IAM is involved: an identity policy allowing the KMS action

and a key policy that does not deny it. Cross-account use always requires the key policy in the key's account to allow the external principal.

• Grants are an alternative authorization mechanism, used by AWS services (for example, EBS or RDS) to

delegate limited key use to a grantee principal for a bounded set of operations; grants can be retired or revoked and are how services act on your behalf without key policy edits.

• Deleting a customer managed key requires a mandatory waiting period of 7 to 30 days, during which

deletion can be cancelled. The safer alternative for "stop using this key now" scenarios is disabling the key, which takes effect immediately and is reversible.

• Multi-Region keys are customer managed keys replicated to other Regions with the same key ID and

material, so data encrypted in one Region can be decrypted in another without re-encryption - the exam frames this around disaster recovery and global applications.

• KMS keys never leave their Region (or partition) unless they are Multi-Region keys; a key created in

eu-west-1 cannot be used in us-east-1.

Envelope encryption is the pattern behind almost every encryption question. KMS itself only encrypts small amounts of data directly (the Encrypt API accepts at most 4 KB of plaintext), so services encrypt bulk data as follows:

1. The application or service calls GenerateDataKey, naming a KMS key.

2. KMS returns a plaintext data key and the same data key encrypted under the KMS key.

3. The application encrypts its data locally with the plaintext data key (for example, AES-256-GCM), then

Automatic key rotation is available for customer managed symmetric keys: when enabled, KMS rotates the backing key material on a schedule you set - 365 days by default, configurable from 90 to 2,560 days - and on demand. Old material is kept to decrypt older ciphertext, and rotation never changes the key ID or ARN.

Asymmetric and HMAC keys cannot be rotated automatically; AWS managed keys rotate annually.

discards the plaintext key from memory.

4. The encrypted data key is stored alongside the ciphertext.

5. To decrypt, the application sends the encrypted data key to KMS (Decrypt), receives the plaintext data key, and decrypts the data locally.

Data itself never passes through KMS. This is why KMS request quotas are rarely the bottleneck in a well-designed system, and why caching a data key briefly (as the AWS Encryption SDK does with its cryptographic materials cache) reduces KMS calls - at the cost of reusing a key for more than one object. One encryption-context detail worth knowing: the encryption context is a set of key-value pairs cryptographically bound to the ciphertext and written to CloudTrail logs, making it the standard way to add audit context to KMS calls.

TLS and data in transit

• AWS services communicate over TLS; API calls are HTTPS and signed with Signature Version 4.
• AWS Certificate Manager (ACM) issues and automatically renews public and private TLS certificates and

deploys them to integrated services such as Elastic Load Balancers, CloudFront, and API Gateway custom

• For S3, enforce encryption in transit with a bucket policy condition on aws:SecureTransport set to false

=> deny.

• Load balancer and CloudFront security policies define the minimum TLS version and cipher suites; a

question demanding "TLS 1.3 only" or "disable TLS 1.0" is answered by selecting a newer security policy, not by code changes.

domains. ACM public certificates issued since June 2025 are exportable (private key included, passphrase-protected); earlier ones are not. Private CA offers more flexibility, at higher cost.

S3 encryption options

Since January 2023, S3 automatically applies SSE-S3 to new objects by default. The four options differ in who holds the keys and what you can audit:

The deciding qualifiers in exam stems are auditability (choose SSE-KMS with a CMK), mandated dual-layer encryption (DSSE-KMS), and "the customer must retain exclusive control of keys and AWS must never store them" (SSE-C). Related controls that appear alongside: default encryption on the bucket (applies when the uploader specifies none), Block Public Access (account- and bucket-level), and Object Lock for retention/WORM requirements.

Secrets Manager vs Parameter Store

Both services store configuration and secrets, and the merged DVA-C03 task tests the boundary between them directly.

How Secrets Manager rotation works, step by step:

1. On the schedule you configure - as often as every four hours, expressed as a rate() or cron() expression with an optional window duration - Secrets Manager invokes the rotation Lambda function.

2. createSecret: the function generates a new credential and stores it as a new version labelled

AWSPENDING.

3. setSecret: the function updates the target system (for example, the database user password or the third-party service).

4. testSecret: the function verifies the pending credential actually works.

5. finishSecret: the AWSCURRENT label moves to the new version; the old version becomes AWSPREVIOUS.

Applications that read the secret normally - without naming a version - always get AWSCURRENT, so they pick up rotated credentials automatically on their next retrieval. Because rotation can happen while old credentials are cached, applications should retrieve secrets at runtime (with short-lived caching, for example the Secrets

Manager client-side caching libraries or the Lambda parameters-and-secrets extension) and retry on authentication failures rather than loading a password once at deploy time.

Choose Parameter Store when the value is configuration (feature settings, AMI IDs, environment URLs), when you need a free tier hierarchy of values organized by path (/prod/app/db-host), or when other SSM features

(parameter policies for expiration and change notification, advanced tier only) matter. Choose Secrets Manager the moment a question mentions rotating a credential, generating a random password, or managing a database or third-party API credential lifecycle.

Common trap: Parameter Store SecureString values are encrypted, so "the value must be encrypted at rest" is not a reason to pick Secrets Manager. Rotation and credential lifecycle management are.

2.4 AI security - the new Task 2.3

DVA-C03 adds a dedicated AI security task to Domain 2. It covers five skill areas: access management for AI services, data privacy controls, content filtering and prompt-injection protection, securing AI agent interactions, and keeping sensitive content out of monitoring logs. It does not cover designing prompts, designing retrieval

(RAG) architectures, choosing models, or AI governance frameworks - those are explicitly out of scope, so if a question drifts toward them, it is testing something else.

Access management for AI services

Calling Amazon Bedrock is an IAM-governed API call like any other, and the exam expects standard IAM discipline applied to it:

• Model invocation uses actions such as bedrock:InvokeModel and

bedrock:InvokeModelWithResponseStream (the Converse API is authorized through the same invoke

actions). Scope the Resource element to the specific foundation model or inference profile ARNs your application needs. Allowing bedrock:InvokeModel on * is the AI equivalent of s3:* on * and will be the wrong answer whenever least privilege is the qualifier.

• Invoke models from an IAM role attached to your compute (Lambda execution role, ECS task role), never

from embedded user keys.

• Separate duties with policy boundaries: developers may have broad Bedrock access in a sandbox account

while production roles permit only the approved models in the production account. SCPs can deny Bedrock actions entirely in accounts that should not use AI services.

• IAM policies can require that inference calls pass through a specific guardrail by conditioning on the

guardrail identifier, which turns "the team configured a guardrail" into "no caller can bypass it."

Data privacy controls

Amazon Bedrock's data protection model, as documented by AWS, is the single most testable fact set in this task:

• Your inputs and outputs are not used to train the base foundation models, are not shared with model

providers, and are not used to improve models for other customers. Model providers have no access to your prompts or completions.

• Data sent to Bedrock is encrypted in transit (TLS) and you can use customer managed KMS keys for

Bedrock assets that are stored, such as model customization jobs and their training data.

• Private connectivity: Bedrock supports interface VPC endpoints (AWS PrivateLink) for its runtime and

control APIs, so a Lambda function or container in a private subnet can invoke models without traffic crossing the public internet. Combine the endpoint with an endpoint policy and aws:SourceVpce conditions in identity or resource policies to require that calls come through your endpoint.

• Cross-Region inference routes requests to other Regions for capacity. From a privacy standpoint that is a

data-residency decision: if a scenario requires prompts to stay in one Region, the answer involves disabling cross-Region inference or pinning an inference profile that stays in-Region - not "Bedrock always keeps data in-Region," which is not guaranteed once cross-Region inference is enabled.

• For other AWS AI services that can use content to improve the service, AWS Organizations AI services

opt-out policies let administrators opt accounts out centrally. This is the mechanism behind "opt out of

CloudTrail records Bedrock control-plane and invocation activity, so "who invoked which model" is auditable - but note the logging caveat under "Keeping sensitive content out of logs" later in this section:

CloudTrail records that a call happened, not the prompt content.

training/improvement" answers for services such as Amazon Q Developer. For Bedrock itself, the no-training guarantee above applies regardless - knowing which statement belongs to which service is exactly what the exam probes.

Amazon Bedrock Guardrails: content filtering and prompt-injection protection

Guardrails are Bedrock's configurable safeguard layer, evaluated on both the input prompt and the model response when you attach a guardrail (by ID and version) to an invocation, or applied to arbitrary text through the standalone ApplyGuardrail API - useful for screening content that never reaches a model, such as user-generated text from another source.

A guardrail combines up to six policy types:

Operational details the exam can test:

• Prompt Attack filtering is an input-side control. It detects prompt injections and jailbreak attempts in

user input; its output strength is set to None because there is nothing to detect in the model's own output.

This asymmetry is a favourite distractor.

• PII handling is a per-entity choice: block card numbers outright, but mask emails so the conversation can

continue without the model ever seeing the real value. Masking on input means the model processes only the placeholder.

• Guardrails are versioned: you edit a working draft and publish numbered versions, and applications

reference a specific version, so a policy change does not silently alter production behaviour.

• A guardrail is not a substitute for IAM: Guardrails inspect content; IAM controls who may invoke what. A

well-secured application uses both, and can use IAM to require that invocations carry the approved guardrail.

Securing AI agent interactions

Agents act: they call tools, query databases, and trigger workflows, so a compromised or manipulated agent can do real damage with real credentials. DVA-C03 expects you to apply least privilege to agents using Amazon

Bedrock AgentCore, the managed runtime and tooling layer for agents.

AgentCore building blocks with a security job:

Principles to state in an answer:

• Tool-use authorization: an agent should be able to call only the tools its job requires, and high-impact

parameters should be bounded by policy at the Gateway, not by hoping the model behaves. Per-user identity should propagate through the call chain (AgentCore Identity brokers token exchange) so downstream services see the real user, not a shared super-powered service identity.

• Session isolation: one user's session must never see another user's data, memory, or credentials.

AgentCore Runtime's per-session microVMs provide this below the application layer - the exam answer when a scenario involves multi-tenant agents leaking context between users.

• Human-in-the-loop approvals: for consequential or irreversible actions, execution should pause for a

person. AgentCore Gateway supports elicitation - the tool pauses mid-execution and requests user input or approval (for example through a form or a URL-based approval/consent flow) before proceeding. Design pattern for questions: read-only actions proceed automatically; writes, payments, deletions, and anything above a policy threshold require elicitation and approval first, and the approval is recorded for audit.

• Apply a guardrail to the agent's model calls as well - agent traffic is still model traffic, and tool outputs

returned to the model are untrusted content that can carry indirect prompt injections.

Keeping sensitive content out of logs

A model application can leak data through its observability pipeline even when everything else is locked down.

Task 2.3 tests whether you know where prompts travel once you log them:

• Bedrock model invocation logging is disabled by default. When you enable it (to CloudWatch Logs, S3,

or both) for debugging or audit, it can capture the full request and response payloads - meaning complete prompts and completions, including whatever PII your users pasted in. Treat the destination bucket or log group as sensitive data: encrypt it, restrict its policy, and set retention deliberately. Never enable full payload logging in production "just in case."

• Your own application logs are the bigger leak. Code that logs the prompt for debugging writes user

data, tokens, and secrets to CloudWatch Logs. Log metadata instead: token counts, latency, model ID, guardrail outcomes, and a correlation ID.

• Route content through a guardrail with PII masking before anything is written anywhere persistent, so

stored text carries placeholders rather than values.

• CloudWatch Logs data protection policies can detect and mask sensitive data (using managed data

identifiers for common PII types) in log groups at ingestion - a useful safety net when you cannot guarantee every developer's logging discipline.

• CloudTrail data events and invocation logs answer "who called what, when"; they should not become a

second copy of your users' conversations.

Common trap: "Enable model invocation logging to improve security" is only half right - it improves auditability while creating a sensitive-data store. The complete answer pairs enabling it with encrypting and restricting the destination, or keeps content logging off and relies on metadata-level logging.

2.5 Secure network access: VPC endpoints and PrivateLink

Applications in private subnets still need to reach AWS services. VPC endpoints keep that traffic on the AWS network instead of hair-pinning through a NAT gateway and the public internet.

Exam-relevant behaviour:

• Both endpoint types support endpoint policies; the effective permission is the intersection of the endpoint

policy and the caller's IAM permissions. A deny or missing allow in either blocks the call.

• Without an endpoint, a private subnet reaches AWS APIs only through a NAT gateway (public path) or not

at all - "the Lambda function in a private subnet cannot reach Secrets Manager" resolves to an interface endpoint for Secrets Manager, a NAT gateway, or moving the function, and the most secure/least exposure qualifier picks the endpoint.

• Use aws:SourceVpce (or aws:SourceVpc) conditions in resource and key policies to require that requests

arrive through your endpoint - the standard pattern for "only allow KMS decrypt calls from inside the VPC."

• S3 gateway endpoints combined with bucket policies that deny any request not arriving via the endpoint

give you private-only buckets reachable from on-premises through the same endpoint model when extended with PrivateLink patterns.

• Interface endpoints also let other VPCs and on-premises networks consume a service privately (endpoint

services), which is how Bedrock and third-party SaaS integrations stay off the internet.

End-of-Chapter Test