AWS Certified Developer Associate (DVA-C02)
Learn the responsibility first, then choose the AWS feature that satisfies it. This guide connects theory → service decisions → payloads → practice. Service tiles open one reference containing its role, key features, comparison, example and AWS links.
Checked: 29 October 2026. The official DVA-C02 guide defines exam scope. Use the study roadmap to plan your next topics.
1. Understand the application
Trace three connected flows: developer delivery → deployed application → user requests and background work. Provisioning creates resources and permissions; release promotion changes which version receives traffic. Production evidence guides recovery and the next change. Select a box to study its responsibility, or trace a situation across lanes.
Developers build, test, provision and release the application. Users invoke the deployed version; background workers finish asynchronous work. Identity, protection, resilience and observability apply across all three flows. Production evidence feeds recovery and the next revision.
Follow the arrowheads between boxes. Provisioning and release affect Application code; background work commits into State/cache. Feedback connects production evidence to Verify/recover and the next revision. Select a box to inspect its responsibility and handoffs.
A release changes what runs. A request uses it. An acknowledgement is separate from the business result.
Requirements
Define what correct behavior and a safe change mean before choosing a service.
Owns: Latency, allowed downtime/capacity loss, permissions, data lifetime and acceptable recovery.
Handoff: Acceptance criteria become code/tests, release gates and production health checks.
Boundary: Developer Associate focuses on implementing, testing and debugging applications; this map is a learning model, not a requirement to design an entire platform.
Example: Eight instances must keep serving during a batched rollout. “Some availability” is weaker than “full baseline capacity”.
Evidence: Write the baseline, temporary-capacity budget and health/rollback criteria before picking a deployment policy.
Source / revision
Create an identifiable revision of the application, dependencies and infrastructure definition.
Owns: Source revision and the trigger that starts an existing delivery workflow.
Handoff: CodePipeline coordinates actions; a build action receives source and emits artifacts.
Boundary: The pipeline is the coordinator. It does not itself replace the build environment or runtime application.
Example: A source commit exists, but there is no release execution. Inspect the source connection/trigger and execution revision.
Evidence: Compare commit ID, source action result, trigger filters and pipeline execution history.
Build / test
Turn a revision into a tested artifact that the chosen runtime can execute.
Owns: Buildspec commands, dependency packaging, unit/integration tests and immutable artifact identity.
Handoff: A versioned ZIP/image/template goes to deployment. The runtime later executes that artifact; CodeBuild is not the production server.
Boundary: Generated code/tests need review. Passing a build does not prove deployed IAM, integration behavior or production routing.
Example: The handler imports locally but fails after deployment. Check packaged files, runtime/architecture and dependency layout.
Evidence: Build/test reports, artifact contents/digest and runtime import errors should refer to the same revision.
Provision / configure
Create or update the resources and configuration that a running application depends on.
Owns: Declared resources, permissions, environment-specific values and resource lifecycle. Dynamic configuration has its own rollout.
Handoff: The runtime receives resources/roles/settings; release promotion selects the application revision and traffic route.
Boundary: CloudFormation can deploy application resources/code too. CodeDeploy adds specialized rollout behavior; they are complementary, not an absolute infrastructure/code split.
Example: The code is correct but a stack update changed the table/role configuration. Inspect stack events and resolved values.
Evidence: Change set, stack events/outputs, runtime configuration and deployment-role permissions locate a provisioning failure.
Release / promote
Make an approved revision receive traffic using a controlled deployment strategy.
Owns: Candidate version, deployment target, routing percentage, validation hooks and compatible rollback target.
Handoff: A Lambda alias, API stage or fleet route makes a particular artifact serve user requests.
Boundary: A published version is not automatically serving production. A canary routes a percentage; a parallel environment/fleet is a different isolation decision.
Example: The new package built successfully but users still see old behavior. Inspect the active alias/stage/fleet target.
Evidence: Compare artifact/version with the actual endpoint route, deployment record and request-correlated version logs.
Verify / recover
Confirm that the deployed release works in its real environment, then recover or promote using evidence.
Owns: Post-deploy business/health checks, alarms, release validation and rollback execution.
Handoff: Production telemetry informs a rollback or the next code/configuration revision; it closes the application lifecycle loop.
Boundary: A successful deployment job is not evidence of business correctness. Check compatibility of database/configuration changes during rollback.
Example: The canary passes a basic health URL but order creation fails. Validate the real integration before expanding traffic.
Evidence: Deployment logs, critical-path tests, alarms, target health and the revision actually handling requests.
Client / caller
Make a request using the credential contract expected by the target.
Owns: Request payload, client-visible timeout, correlation/request ID and user/machine identity.
Handoff: The front door validates the caller; the backend later uses its own role to call AWS services.
Boundary: A Cognito JWT is for a supported token-verifying target. Direct AWS SDK access generally needs temporary AWS credentials and a signed request.
Example: A mobile user signs in but a direct S3 call fails. Decide whether the client needs identity-pool credentials or should call the application API.
Evidence: Inspect the actual target, token/credential type and issuer/audience/scope binding without logging secret values.
Trusted entry
Accept the request through a configured route and enforce the relevant entry controls.
Owns: API stage/integration, request transformation, token validation or IAM authorization and traffic controls.
Handoff: An authorized API invocation reaches the backend. Application code still checks business/record entitlement.
Boundary: REST and HTTP API features differ. An API key for a usage plan is not user authentication; an ALB route is not an IAM grant.
Example: A request never reaches the Lambda handler. Check authorizer/access logs, stage deployment and integration permissions.
Evidence: Distinguish entry 401/403, integration errors and backend errors before changing compute capacity.
Application code
Execute business logic against authorized data and downstream services.
Owns: Input/business validation, tenant entitlement, AWS SDK calls, error handling and request-scoped context.
Handoff: Read/write authoritative state, optionally publish background work, then construct the correct immediate response.
Boundary: The caller and execution role are different principals. A runtime role can access a table while the app user is still forbidden from a particular record.
Example: The API authenticates correctly but the backend receives AccessDenied from DynamoDB. Inspect the backend role and target policies.
Evidence: Correlate handler logs, role session, AWS action/resource and applicable policy denies; do not replace the caller token blindly.
State / cache
Persist authoritative data or reuse an appropriate cached copy.
Owns: Access keys/indexes or SQL endpoints, consistency, projection, cache scope and lifetime.
Handoff: Return data to the request path; background workers can update the same permitted state.
Boundary: A replica/index/cache has a distinct consistency contract. TTL cleanup is asynchronous; a cache key must separate users/tenants where required.
Example: A user sees stale or another tenant’s cached result. Check authoritative state, cache key and invalidation before adding capacity.
Evidence: Query/index or replica endpoint, projected fields, timestamps, cache hit/miss and tenant-scoped keys.
Response / outcome
Report what actually happened at the boundary the client is waiting for.
Owns: Response schema/status, truthful operation state and a way to correlate or poll asynchronous work.
Handoff: The caller receives success/failure or an accepted job ID. Telemetry records the request outcome.
Boundary: A 202/accepted response or successfully published event does not prove the background business operation committed.
Example: The API accepts an order, but fulfillment runs later. Return a job/order identifier and expose actual status separately.
Evidence: Match response semantics to the authoritative result record and trace/request ID.
Route / fan out
Deliver a publication to matching or subscribed consumers when routing/fanout is needed.
Owns: Event schema, target selection, subscription/rule filters and publication/delivery errors.
Handoff: Targets can be queues, functions or workflows. An application can also send directly to SQS/Kinesis without this routing stage.
Boundary: Routing does not retain business-step progress. EventBridge bus types differ; select the exact feature contract rather than assuming identical guarantees.
Example: One publication must reach fulfillment and analytics independently. Fan out to separately authorized targets/queues.
Evidence: Inspect publish results, rule/filter matches, target permissions and delivery/DLQ evidence.
Buffer / retain
Decouple producer and consumer capacity with a queue, or retain stream records for consumption/replay.
Owns: Queue backlog/visibility/retention or stream partitioning/capacity and per-record ingestion outcomes.
Handoff: A worker receives a job or stream record; successful receipt is not completed processing.
Boundary: SQS and Kinesis are alternatives for different access/delivery needs. Inspect partial batch results and expect retries/duplicate side effects.
Example: PutRecords returns HTTP 200 with a failed entry. Retry that entry with backoff and investigate hot partition keys/capacity.
Evidence: FailedRecordCount and result positions for Kinesis; queue age/backlog, visibility and DLQ for SQS.
Worker / workflow
Perform background work, using a state machine only when multi-step coordination is required.
Owns: Task execution, workflow progress when used, bounded retries/catches and downstream failure handling.
Handoff: Persist a recoverable business result before acknowledging the source; carry the request/event ID through every step.
Boundary: A queue owns pending delivery; Step Functions owns workflow progress; Lambda/ECS executes code. CodePipeline belongs to software delivery.
Example: A payment call times out. Check the authoritative outcome before retrying, then recover using an idempotency key/result ledger.
Evidence: Worker logs, workflow execution history, receive count and downstream request/operation identifiers.
Commit / acknowledge
Keep duplicate delivery from turning into duplicate business effects and report completion accurately.
Owns: Atomic request claim, recorded result/status, recovery for abandoned work and acknowledgement ordering.
Handoff: Committed state becomes visible to permitted readers; only then acknowledge according to the source/integration contract.
Boundary: A conditional claim alone does not make an external payment exactly once. SQS deletion is not a database commit; Lambda event-source acknowledgements have their own contract.
Example: Two workers receive the same order. Use a conditional claim and persisted outcome; avoid a racing read-before-write check.
Evidence: Request ledger, condition failure, business result and acknowledgement timing show whether work is duplicated or lost.
Identity / authorization
Apply separate identity and access decisions to delivery, users and machine workloads.
Owns: Developer/deployment roles, API token trust, backend/worker roles and application-level entitlements.
Handoff: Each trust boundary validates the correct principal/credential and permits only its intended action and data.
Boundary: The deployment role does not become the end user. Boundaries/SCPs restrict applicable grants; a valid JWT is not automatically an AWS permission.
Example: The front door accepts a token but the app leaks another tenant’s record. Enforce record entitlement at the application/data access boundary.
Evidence: Token claims, route scopes, execution-role action/resource and tenant-filter decisions are distinct evidence.
Secrets / protection
Protect configuration, credentials and data without confusing protection with permission.
Owns: Secret rotation/retrieval, encryption keys, TLS/private paths and sensitive-data handling.
Handoff: Delivery configures references and policies; authorized runtime code retrieves values and uses protected resources.
Boundary: Encrypted data is not automatically authorized data. A security group permits a network path, not an IAM action or a business operation.
Example: The application keeps using a rotated password. Check runtime secret retrieval/cache behavior and the database integration.
Evidence: Secret version/rotation status, retrieval errors, KMS access and connection evidence; sanitize diagnostic logs.
Resilience / performance
Keep failures bounded and match capacity to the measured bottleneck.
Owns: Timeout budgets, backoff/jitter, idempotency, concurrency, worker scaling and safe caching.
Handoff: Pressure/failure signals guide application/configuration changes and subsequent release validation.
Boundary: More capacity does not repair a policy deny or invalid request. Retries increase pressure unless paired with limits and idempotency.
Example: Queue depth grows while workers are busy. Compare backlog per worker and processing time; investigate downstream throttling before scaling blindly.
Evidence: Queue age, backlog per worker, duration/concurrency/throttles and downstream capacity reveal the limiting stage.
Observability / feedback
Gather enough evidence to locate the first failed boundary and validate a change.
Owns: Structured logs, correlated requests/versions, metrics/alarms, traces and AWS API-change evidence.
Handoff: Production outcomes feed Verify/recover and the next code/configuration change; this closes the lifecycle loop.
Boundary: Metrics show trends, access logs show requests, traces locate stages and CloudTrail shows covered AWS API activity. Configure the evidence before an incident.
Example: Latency rises after release. Compare versions and a correlated trace before changing memory, replicas or queue capacity.
Evidence: Use the symptom’s metric to find the window, then request logs/spans, then relevant deployment/configuration events.
2. Read the deciding constraint
Before choosing a service, name the principal, operation, state, failure mode and evidence. Then explain why the closest alternative fails.
| Theory | Ask in the scenario | Typical boundary |
|---|---|---|
| Availability vs capacity | Must some requests succeed, or must the full baseline keep serving? | Rolling can preserve availability while reducing capacity. |
| Immutable vs mutable | Are old instances changed, or does a new fleet/version coexist? | A replacement fleet and an additional batch have different isolation/cost. |
| Authentication vs authorization | Is this identity trusted, and may it perform this action on this data? | JWT validation, AWS IAM access and record entitlement are separate checks. |
| State vs acceleration | Is this the authoritative value, a replica or a cached copy? | Replication lag and cache staleness affect correctness. |
| Delivery vs completion | Was work accepted, processed, committed and acknowledged? | A retry can repeat a side effect; use idempotency and recorded outcomes. |
| Signal vs evidence | Do you need a trend, one request, a slow stage or an administrative change? | Metrics, access logs, traces and CloudTrail answer different questions. |
Use least overhead only after hard constraints are met. Prefer supported capabilities; measure the actual bottleneck before adding capacity or changing platforms.
3. Connect theory to services
The chooser rules stay visible. Open a tile for details and a sample contract. Examples are deliberately small; configuration excerpts and pseudocode are labelled where they omit deployment context.
3.1 Release & infrastructure
Source → template → artifact/version → test → traffic shift → rollback
Define the application, then run it. SAM and CDK describe infrastructure; their deployed resources do the work. CDK can define serverless applications, and SAM can include ordinary CloudFormation resources.
| Responsibility | Service/tool | Deciding difference |
|---|---|---|
| Define serverless infrastructure | SAM | YAML shorthand + transform + local development tools |
| Define infrastructure in code | CDK | Programming-language constructs → CloudFormation |
| Provision the declared stack | CloudFormation | Creates/updates the actual AWS resources |
| Execute functions | Lambda | Managed function execution |
| Run a virtual machine | EC2 | OS/instance control |
| Orchestrate containers | ECS | Schedules tasks/services on chosen capacity |
| Supply managed container compute | Fargate | Runs supported containers without managing EC2 hosts |
What must stay safe during deployment?
-
Downtime acceptable; speed first
All at once
Elastic Beanstalk
-
No extra instances; reduced capacity acceptable
RollingElastic Beanstalk
-
Keep baseline capacity; update in batches
Rolling with additional batchElastic Beanstalk
-
Keep old fleet intact during validation
ImmutableElastic Beanstalk
-
Test a percentage on a new fleet
Traffic splitting (ALB)Elastic Beanstalk
-
Route a stable function name across versions
Weighted alias
Lambda
Blue/green uses separate environments. Keep persistent data outside disposable application environments.
What are you trying to express?
-
Declarative resources, dependencies and exports
CloudFormation
CloudFormation
-
Reusable infrastructure in a programming language
CDK → CloudFormation
CDK
-
Compact serverless template + local tools
SAM → CloudFormationSAM
- Deploy a reusable serverless application
-
Same template across accounts/Regions
StackSetsCloudFormation
A template, a deployed stack and an application version are different objects.
What must this stage actually do?
-
Orchestrate the delivery stages
CodePipeline
CodePipeline
-
Compile, test and package
CodeBuild
CodeBuild
-
Provision/update declared resources
CloudFormation / CDK / SAMCloudFormation
CDK
SAM
-
Release code / shift traffic / run hooks
CodeDeploy or platform-native deployment
CodeDeploy
Elastic Beanstalk
-
Roll out runtime flags/configuration
AppConfig
AppConfig
These tools can cooperate. The deployer role, runtime role and end-user identity remain separate.
Implementation notes
CodePipeline coordinates delivery; CodeBuild builds/tests; CloudFormation/CDK/SAM manage declared resources; CodeDeploy or platform-native deployment promotes the application revision. These can cooperate. AppConfig rolls out runtime configuration separately. Keep the database lifecycle independent of a disposable environment and retain a compatible rollback target.
Eight existing instances; batches of two. Compare a representative deployment phase after any extra instances pass health checks.
Rolling: six instances serve while two update. Rolling with an additional batch keeps eight serving by temporarily adding two. Immutable and traffic splitting launch a full replacement fleet.
Illustrative capacity, not an animation of every Beanstalk phase. Healthy, provisioned and traffic-receiving instances are different counts. Candidate health, quotas and deployment configuration still matter.
3.2 Request & compute
Client → front door → healthy execution → data → response
Amazon API Gateway
Application Load Balancer
AWS Lambda
Amazon EC2
EC2 Auto Scaling
Amazon ECS
AWS Fargate
Which responsibility is required?
-
OS/host control
EC2 (+ ASG capacity)EC2
EC2 Auto Scaling
-
Event-triggered function
LambdaLambda
- Manage container tasks/services
- Container process + shared persistent files
-
HTTP API features, identity or transformation
API Gateway; check REST vs HTTPAPI Gateway
-
Route HTTP to healthy private targets
ALB; ASG adds instancesApplication Load Balancer
EC2 Auto Scaling
Configure the health-check contract separately from user routes. Network reachability and authorization are separate checks.
Implementation notes
Use a separate REST API stage for incompatible testing; stage variables supply environment configuration. Apply a canary when testing a percentage of live production traffic. Choose REST when its usage plans, managed cache or VTL body templates are required. Use scoped cache keys and verify REST vs HTTP support.
For compute, distinguish routing, provisioning, scaling and storage. Lambda layers package dependencies; memory affects conventional function CPU. An ASG adds EC2 instances; ALB sends requests to healthy targets. EFS keeps supported container tasks on shared persistent files, while task-local storage is disposable.
3.3 State & data access
Access pattern → key/index or SQL endpoint → consistency → cache/lifetime
Which access pattern is the deciding clue?
-
Known partition/key lookup; flexible item fields
DynamoDB; add GSI for another query key
DynamoDB
-
Relational read load
RDS read replica; route reads explicitly
RDS
-
Relational failover
RDS Multi-AZ; know instance vs clusterRDS
-
Repeated reusable result
ElastiCache + expiry/invalidation
ElastiCache
-
Asynchronous cleanup of expired items
DynamoDB TTLDynamoDB
A cache is not a SQL endpoint. An eventually consistent replica/index is not an immediate-read guarantee.
Implementation notes
For the game catalogue, GameName + Version identifies a version; GameName queries versions; Category + GameName on a GSI lists by category. Project the fields that the index must return. A GSI is eventually consistent. TTL removes expired items asynchronously; enforce application expiry even while an item still exists.
Route read-heavy SQL to a read replica when lag is acceptable. A traditional Multi-AZ standby supports failover; a Multi-AZ DB cluster can also serve reads. Cache-aside adds a separate lookup and invalidation path; it does not replace the relational endpoint.
3.4 Asynchronous work
Producer → queue/stream → worker → durable result → acknowledgement
What is the delivery requirement?
-
Independent workers consume pending jobs
SQS; acknowledge after success
SQS
-
Replay stream records; ordered per shard
Kinesis Data Streams
Kinesis Data Streams
-
HTTP 200 with failed batch entries
Inspect results; retry failed records onlyKinesis Data Streams
-
Duplicate business operation
Atomic claim + persisted resultDynamoDB
-
Workers fall behind
Target backlog per worker, not raw depthSQS
EC2 Auto Scaling
Backoff with jitter handles transient pressure. It does not repair invalid requests or authorize denied calls.
What state does the service own?
-
Where does this publication go?
EventBridge routing / SNS fanout
EventBridge & SNS
-
Which jobs are waiting for a worker?
SQS backlogSQS
-
Which records can a consumer replay?
Kinesis streamKinesis Data Streams
-
Which business step comes next?
Step Functions state machine
Step Functions
A producer can publish directly to a queue or stream. Use only the routing, buffering and coordination the application needs.
Implementation notes
On SQS, finish and record the outcome before deleting the message. Set visibility for processing time and extend it when appropriate; visibility does not remove the need for idempotency. Use an atomic conditional claim and recoverable result/status rather than read-before-write. For Kinesis batches, match per-entry results to input records and retry only failures with backoff and jitter.
A queue of 1,000 jobs means different pressure with five workers versus fifty. Each worker here processes one message at a time.
1,000 / 10 = 100 messages per worker. A 60-second wait budget / 2-second processing time gives a target of 30 messages per worker.
A steady-state sizing estimate, not an exact latency guarantee or deployable scaling policy. Startup time, in-flight work, bursts and per-worker concurrency affect real capacity. An ECS policy uses running task capacity; an EC2 ASG uses InService instances. Configure a scale-from-zero signal.
3.5 Identity, protection & evidence
Identity → trust/token validation → action/data authorization → protected access → evidence
What does the caller need?
-
App sign-in / federation
User pool → JWT → protected app/API
Cognito
API Gateway
-
App user calls AWS directly
Identity pool → temporary role credentialsCognito
IAM, STS & Access Analyzer
-
Lambda code calls another AWS service
Execution role + temporary credentialsLambda
IAM, STS & Access Analyzer
-
Custom API token/rule validation
Lambda authorizerAPI Gateway
-
Hardware/network isolation
Tenancy or network controls, alongside IAMEC2
Security groups & NACLs
A trusted token proves a supported identity; IAM permissions and application entitlements still need explicit enforcement.
What must the control do?
-
Require explicit S3 upload encryption mode
Bucket policy on PutObject headers
S3 encryption
-
Encrypt large application data
Envelope encryption with a data key
KMS
-
Automatically rotate DB credentials
Secrets Manager integration/workflow
Secrets Manager & Parameter Store
-
Store named static config or SecureString
Parameter StoreSecrets Manager & Parameter Store
-
Request detail vs aggregate vs admin change
Access logs vs metrics vs CloudTrail
CloudWatch, CloudTrail & tracing
Encryption, authorization and observability operate at different boundaries; choose each for its own obligation.
Implementation notes
Separate the caller of your API from the role your code uses to call AWS. A role trust policy controls who can assume it; permission policies control subsequent actions. Boundaries and SCPs limit applicable permissions without granting them. Security groups and NACLs filter network traffic; encryption protects data. Neither grants application entitlement.
Start with the principal and target. User sign-in and backend AWS access can be parts of the same request.
Trust boundary: Public client → trusted identity issuer → API → application data
- User pool / external IdP1. Authenticate the app user
- Access JWT2. Bearer token for this API
- API authorizer3. Validate claims + required scope
- Application authorization4. Check tenant / record entitlement
Trust check: The API validates the trusted issuer, signature, expected client/audience binding, token type and expiry.
Permission check: The API must allow the requested scope/route; the application still checks the requested record or tenant.
Authorization: Bearer <access-token-JWT>Trust boundary: Public client → identity federation → AWS IAM resource boundary
- User pool / supported IdP1. Authenticate; obtain identity token
- Cognito identity pool2. Validate identity + select trusted role
- Temporary AWS credentials3. Access key + secret + session token
- S3 / AWS API4. SigV4 request + IAM evaluation
Trust check: The identity pool accepts this provider/token; the role trust policy permits the intended federation path.
Permission check: Role/resource/key policies allow the exact operation and resource; applicable boundaries and organizational controls permit it.
AccessKeyId + SecretKey / SecretAccessKey + SessionToken + ExpirationTrust boundary: Trusted AWS service → function execution role → target AWS resource
- Lambda service1. Run the function
- Execution-role trust2. Trust lambda.amazonaws.com
- Runtime credentials3. SDK credential provider obtains temporary credentials
- DynamoDB / S34. Signed request; evaluate role + resource policy
Trust check: The execution-role trust policy allows the Lambda service to assume it.
Permission check: The role and applicable resource/key policies allow the action; guardrails permit it. The app separately enforces its user’s entitlement.
SDK default credential chain → temporary role credentials → SigV4A simplified learning model. It does not implement IAM evaluation; resource policies, key policies, session policies, boundaries and organizational controls can change the result. Permission does not make an untrusted token valid.
Continue with the broader identity decision tree and JWT, OAuth, OIDC and SAML.
Store rotating credentials in Secrets Manager and static named configuration in Parameter Store as appropriate. For S3, distinguish resulting default encryption from a policy requiring explicit upload headers: AES256 means SSE-S3; aws:kms means SSE-KMS. For large client-encrypted data, envelope encryption uses a data key protected by a KMS key.
Find the right evidence
| Investigation | Start with | Then verify |
|---|---|---|
| How much traffic, latency or error rate? | CloudWatch metrics | Time window, dimensions, ALB vs target errors. |
| Which client/path/status/timing? | ALB access logs | Logging enabled, target/path and request correlation. |
| Where did request time go? | Correlated application logs + distributed trace | Downstream instrumentation and matching trace IDs. |
| Who changed an AWS setting? | CloudTrail | Relevant event type/coverage; application requests use their own access logs. |
| Why is a target unhealthy? | Target health reason + configuration | Security groups, NACLs, port, health path and success matcher. |
See the AWS security/audit comparison for Config, Audit Manager, Artifact and findings services.
4. Practise the boundary
Choose a scenario and answer once. Explain the deciding constraint, reject the nearest alternative and name a change that would reverse your choice.
Original learning exercises: choose an answer to see the deciding clue and what would change it.
5. Exam scope and next topics
The exam weights are Development 32% · Security 26% · Deployment 24% · Troubleshooting and Optimization 18%. The official guide emphasizes implementing, testing, deploying and debugging applications; designing networking or an entire CI/CD platform is outside the stated target role.
Scope verified 29 October 2026: AWS still lists DVA-C02. The current revision notes include Amazon Q Developer assistance/testing, EventBridge, application-level authorization, structured logging and runtime configuration. Use the in-scope service list alongside the four domain descriptions. The map organizes responsibilities; its lanes are not separate exam domains.
| Domain | Covered here | Topics to expand |
|---|---|---|
| Development — 32% | API integration, Lambda, stores, queues/streams, routing/workflows, idempotency. | SDK pagination/error handling, Query vs Scan, read consistency, Lambda invocation/error lifecycles, concurrency and hands-on Q Developer-assisted development. |
| Security — 26% | Cognito, IAM, encryption, secrets, network filtering. | Cross-account roles/key permissions, TLS/certificates, token scopes, tenant-level authorization, sanitization and sensitive logging. |
| Deployment — 24% | Beanstalk, versions/aliases, stages, IaC, CodePipeline/CodeBuild/CodeDeploy and AppConfig boundaries. | Exercise artifact packaging, local/integration tests, hooks, alarms and rollback in an existing delivery workflow. |
| Troubleshooting — 18% | Health checks, evidence, CPU tuning, throttling/backlog. | Instrumentation, tracing, custom metrics, log queries, service quotas and concurrency bottlenecks; validate with before/after measurements. |
SAM remains explicit in the Deployment domain: staging deployments, test events and IaC template updates. The service list is non-exhaustive; a missing name there does not mean the skill is excluded.
Explore the architecture
Explore scope, placement and communication on one map. The 25 scenarios and comparison mode connect the same resources; each arrow has an explicit meaning. Use the existing service cards for deeper examples and current AWS references.
One logical environment, with alternative architectures highlighted on the same canvas. Boundaries describe scope and placement; they are not extra network hops. This local simulator makes no AWS calls.
Drag blank canvas to pan · + / − to zoom · select an icon to inspect · boundary + / − collapses its contents. Connections shown by default belong to the selected scenario or service.
AWS references: Official DVA-C02 guide · VPC private-subnet / NAT example · Lambda VPC placement · Lambda stream consumption · RDS Multi-AZ models · EBS AZ attachment · EFS regional mount targets. Service panels also link to their specific documentation. These scenarios explain mechanisms; the exam guide defines scope.
Open a reference for details, a sample contract and AWS documentation.
AWS Elastic Beanstalk
Deploy an application; let Beanstalk coordinate its infrastructure.
- Standard environments manage EC2, load balancing, scaling, deployment and health.
- Use .ebextensions/<name>.config (YAML/JSON) for environment options, instance customization and extra CloudFormation resources.
- Environment-created resources normally share its lifecycle; keep durable RDS outside it. A disposable session cache can be recreated.
Decision boundary. Rolling can reduce serving capacity and leave mixed versions after failure. Immutable/traffic splitting replace the fleet and lose accumulated CPU burst credits. Blue/green uses separate environments and a CNAME swap.
These are configuration files, not an extension marketplace. Put YAML/JSON .config files in your source bundle's .ebextensions/ folder. They configure Beanstalk Standard environments.
| Key | What it defines | Example |
|---|---|---|
option_settings | Beanstalk options in namespaces | Environment variables, instance/scaling settings, health checks, deployment policy |
packages | Install instance software | jq, OS libraries; documented handlers include yum, rpm, rubygems and python, subject to platform support |
sources | Download and unpack archives | Extract a helper bundle into an instance directory |
files | Write/download files with ownership and permissions | Create an application configuration file |
users / groups | Local OS accounts and groups | A system user for a helper process |
commands | Root commands before the application archive is extracted | Prepare OS directories/tools |
container_commands | Commands in application staging, before deployment | Compile assets; leader_only selects one instance for a deployment task |
services | Configure supported OS services | Enable/start a daemon; this does not provision an AWS managed service |
Resources | Any CloudFormation-supported resource type | ElastiCache, SQS, SNS, alarms, IAM roles or RDS; creation needs appropriate permissions |
Install ≠ provision. packages installs software on the EC2 instances. Resources → AWS::ElastiCache::CacheCluster creates a separate managed cache in the environment's CloudFormation stack.
Lifecycle. A stack-owned cache normally disappears when the environment is terminated. CloudFormation DeletionPolicy: Retain or supported snapshot policies can change cleanup. Referencing an external cache/database does not transfer ownership; resources created separately by a script are not automatically tracked by the stack. Keep durable/shared data in a separate stack.
Modern Linux. Use application manifests such as requirements.txt / package.json for runtime dependencies, and platform hooks (.platform/hooks/prebuild, predeploy, postdeploy) for custom scripts. Match packages and service management to the OS/runtime. container_commands refers to app staging; it does not require Docker.
| Strategy | Extra instances | Serving capacity / deciding clue |
|---|---|---|
| All at once | None | May drop to zero; quickest rollout |
| Rolling | None | Reduced by the batch being updated |
| Rolling + additional batch | One temporary batch | Maintains baseline capacity |
| Immutable | Replacement fleet | Keep old fleet intact while validating new |
| Traffic splitting | Replacement fleet | Canary percentage; requires ALB |
option_settings:
aws:elasticbeanstalk:command:
DeploymentPolicy: RollingWithAdditionalBatch
BatchSizeType: Fixed
BatchSize: 2
# Install a tool on the environment's EC2 instances.
packages:
yum:
jq: []
# Provision a managed cache in the environment stack.
Resources:
SessionCache:
Type: AWS::ElastiCache::CacheCluster
Properties:
Engine: memcached
CacheNodeType: cache.t3.micro
NumCacheNodes: 1
CacheSubnetGroupName: example-cache-subnets
VpcSecurityGroupIds:
- sg-0123456789abcdef0Replace the cache subnet group/security group placeholders with compatible existing VPC resources and allow application access to the cache. This excerpt omits network setup; it has no retention policy, so the cache follows environment deletion. On a failed rolling deployment, replacement instances use the last successful app version; redeploy to restore consistency.
AWS reference: Deployment policies · .ebextensions · External RDS lifecycle · Instance customization keys · Extra CloudFormation resources · Platform hooks · Retention policies
Amazon EC2
A virtual machine with OS and instance-level control.
- Linux user-data shell scripts run as root, normally on the first launch boot only. Configure cloud-init explicitly for later boots.
- Stop an EBS-backed instance before changing its user-data attribute; changing it does not itself rerun the script.
- T-family instances spend CPU credits on bursts; sustained CPU demand needs an appropriate family or credit configuration.
Decision boundary. Hardware isolation alone points to Dedicated Instances; physical host placement or socket/core licensing points to Dedicated Hosts.
Checked 29 October 2026. The “t2.micro free for your first 12 months” wording describes the legacy offer used in older learning material.
Scroll the table horizontally to compare columns.| Limit / rule | Legacy: account created before 15 July 2025 | Current: account created on/after 15 July 2025 |
|---|---|---|
| Compute allowance | 750 eligible instance-hours/month, subject to the applicable OS offer; not 750 hours per instance | USD $100 at signup + up to $100 earned credits, shared across eligible AWS services; no blanket 750-hour EC2 allowance |
| Duration | First 12 months after account creation, not after launching the instance | Free plan ends after 6 months or credit exhaustion, whichever is first. On a Paid plan, remaining credits apply until expiry, no later than 12 months after signup. |
| Eligible instance types | t2.micro / t3.micro, subject to offer/Region and eligible AMI | Currently marked eligible: t3.micro, t3.small, t4g.micro, t4g.small, c7i-flex.large, m7i-flex.large; use a compatible eligible AMI |
| EBS (separate from compute hours) | 30 GB storage, 2 million eligible I/Os and 1 GB snapshot storage under the legacy EBS offer | Eligible EBS usage consumes the shared credits; selecting an eligible instance does not make its disks unlimited |
| Public IPv4 | 750 in-use address-hours/month during the 12-month offer | Eligible address charges consume credits; check your account's offer rather than assuming legacy IP hours |
| Beyond the allowance | Standard charges for excess usage or after the 12-month period | Free plan closes when it expires unless upgraded. Paid plan bills usage beyond credits or outside credit eligibility. |
Legacy example. One eligible Linux instance × 24 h × 31 days = 744 instance-hours. Two under the same offer = 1,488 hours. Add usage across instances and Regions within that offer; the allowance is not per server or Region.
Free cost ≠ billing granularity. “0 seconds” is not EC2's general minimum billing duration. Eligible per-second billing has a 60-second minimum; an applicable allowance or credit can cover the charge. Check Billing → Free Tier / Credits for your actual eligibility, balance and expiry.
| Tenancy | Control | Typical clue |
|---|---|---|
| Shared/default | Virtual instance on shared hardware | Normal application compute |
| Dedicated Instance | Dedicated customer hardware; no host placement | Hardware isolation |
| Dedicated Host | Physical host visibility and placement | Host-bound licensing |
#!/bin/bash
# Amazon Linux example; first-boot setup, not a recurring job.
dnf install -y nginx
systemctl enable --now nginxAWS reference: User data · Dedicated tenancy · Current vs legacy EC2 Free Tier · Legacy 750 hours & new credits · Free vs Paid plan · EBS allowances · Legacy public IPv4 allowance · Per-second billing minimum
EC2 Auto Scaling
Maintain fleet capacity across AZs; pair with ELB to route traffic.
- One ASG belongs to one Region and uses subnets in one or more AZs. It normally attempts to balance instances across enabled AZs.
- The group replaces unhealthy instances and scales instance count in/out. Changing instance size is a separate vertical-scaling operation.
- ELB distributes requests across registered targets. Its cross-zone setting controls whether an LB node can route outside its own AZ; it does not rebalance the instance fleet.
Decision boundary. Cross-zone ≠ cross-Region. An ASG and a regional load balancer stay within one Region. Use separate regional stacks plus Route 53 or Global Accelerator for global traffic routing.
ASG balances instance capacity; ELB balances requests. This is an uneven snapshot of 10 healthy, equal-weight targets. Assume 100 requests/s, split equally between two load balancer nodes, with uniform routing and no stickiness.
100 requests/s → LB node A (50) + LB node B (50)
Each LB node can send its share to all 10 targets across both AZs.
20% total · 20 requests/s
80% total · 80 requests/s
Cross-zone ON: 100% ÷ 10 = 10% per target. AZ A receives 20%; AZ B receives 80%.
Why 2 + 8? ASG normally tries to balance instances across enabled AZs; this could be a temporary imbalance. Changing ELB cross-zone routing does not move instances or change the ASG desired capacity.
Defaults. ALB enables cross-zone at the load balancer; a target group can disable it. NLB disables it by default. Actual shares depend on routing, health, weights and connections; the percentages above are an educational model.
Across Regions? Route 53 routing policies or Global Accelerator → separate regional load balancers → separate regional ASGs. Cross-zone means AZs within one Region; one ASG does not span Regions.
{
"MinSize": 2,
"DesiredCapacity": 10,
"MaxSize": 20,
"VPCZoneIdentifier": "subnet-az-a,subnet-az-b"
}DesiredCapacity=10 sets the fleet total, not a 2/8 AZ allocation. A launch template supplies AMI, instance type, security groups and bootstrap configuration. Scale against the measured bottleneck.
AWS reference: ASG responsibilities · Cross-zone: 2 vs 8 example · Route 53 routing policies · Global Accelerator endpoints
Application Load Balancer
Route HTTP requests to healthy targets.
- An internet-facing ALB routes HTTP requests to healthy targets, including targets with private IP addresses.
- Health checks have their own path, port, matcher and network reachability; direct access can work while a target is unhealthy.
- With cross-zone balancing and equal healthy target weights, 2 targets in AZ A + 8 in AZ B means about 10% per target.
Decision boundary. ALB access logs describe requests. CloudWatch metrics aggregate measurements. CloudTrail describes AWS API/account activity.
Client → ALB → private target → response. An access log records request-level evidence, including some requests that never reach a target. Logging must be enabled; delivery is best effort.
# Synthetic legacy-format entry; first 13 fields only.
# Wrapped for reading; a real entry is one line with more fields.
https 2026-10-29T01:00:00.200000Z app/orders/abc123
203.0.113.10:51500 10.0.2.15:8080
0.001 0.180 0.002 200 200 120 450
"GET https://api.example.com:443/GetOrder?orderId=o-42 HTTP/1.1"| Field | Example → meaning |
|---|---|
client:port / target:port | 203.0.113.10:51500 called target 10.0.2.15:8080. With an upstream proxy, the client field can be that proxy. |
request_processing_time | 0.001 seconds from ALB receipt to dispatch toward the target |
target_processing_time | 0.180 seconds until target response headers start; inspect backend work first |
response_processing_time | 0.002 seconds from target headers reaching ALB until ALB starts sending the response |
elb_status_code / target_status_code | 200 / 200: target replied and ALB returned success. 503 / - can indicate ALB had no usable target; check target health and routing. |
request_line | HTTP method, URL/path/query and protocol; later fields include user agent, TLS details, actions and trace ID |
Timing caveat. These fields describe different boundaries, not a full browser stopwatch. Upload/WAF behavior affects attribution; -1 can mean a processing phase could not complete. A trace ID helps correlate evidence but does not create downstream spans.
Delivery. Traditional access logging writes compressed files to S3 (disabled by default). Use a same-Region bucket and the required log-delivery bucket policy. AWS also supports the newer CloudWatch Logs integration, with destinations including CloudWatch Logs, Firehose and S3. Choose the delivery path deliberately; CloudWatch metrics are a separate signal.
| Question | Evidence | What it tells you |
|---|---|---|
| Which client, URL, status and target timing? | ALB access logs | Request details; not the application body or a complete audit ledger |
| Is traffic/latency/error rate rising? | CloudWatch metrics | RequestCount, TargetResponseTime, HTTPCode_ELB_5XX_Count vs HTTPCode_Target_5XX_Count |
| Who changed a listener or security setting? | CloudTrail | Administrative AWS API activity; not each HTTP request |
| Why is this target unhealthy? | Target health reason + health-check/application logs | Check path, port, matcher, security groups and NACLs |
{
"HealthCheckProtocol": "HTTP",
"HealthCheckPort": "traffic-port",
"HealthCheckPath": "/health",
"Matcher": {"HttpCode": "200"}
}Request tracing supplies an X-Amzn-Trace-Id for correlation; instrumentation is still needed for downstream spans. The 10% example assumes request-count routing, not differing target weights, stickiness or connection behaviour.
AWS reference: Access log fields · Target health checks · Enable S3 access logging · CloudWatch Logs integration · CloudWatch metrics
Amazon API Gateway
Expose an API with routing, integration and access controls.
- A stage is a named environment pointing to an API deployment snapshot. A canary tests a newer deployment on the same stage URL.
- Stage variables configure integrations; VTL mapping templates transform payloads. A proxy integration instead passes its standard event to the backend.
- Authorizers establish caller access. Usage plans meter API-key consumers; caching can avoid repeated backend work.
Decision boundary. API keys are not authentication. Usage-plan quotas/throttles are best effort, not hard spend limits. Verify the API type before selecting a feature.
Two stages of one REST API. The URL chooses the stage; the API key identifies the consuming application. This is a local illustration, not a live AWS call.
GET https://a1b2c3d4e5.execute-api.ap-southeast-2.amazonaws.com/prod/GetOrder?orderId=o-42
Authorization: <Cognito access JWT>
x-api-key: <PartnerApp API key>200 OK · prod → deployment d1 → orders:prod (version 1)
- URL → stage → deployment
/prod selects prod, pointing to API deployment d1. /GetOrder is the resource; GET is the method.
- Who is calling?
The Cognito authorizer validates the access token and required orders/read scope. The API key separately identifies PartnerApp for its usage plan.
- Validate input & apply usage limits
Require orderId and an API key on this method. PartnerDemo targets 10 requests/s, burst 20, and 1,000/day per key across prod + beta.
- Cache → mapping → integration
On a cache miss, a non-proxy VTL mapping creates the Lambda JSON below. The integration uses stage variable functionAlias=prod to invoke orders:prod.
- Backend → response
Lambda checks that user-42 may read order o-42, loads the order, and returns 200. Integration/method response settings expose that result to the caller.
{
"orderId": "o-42",
"environment": "prod",
"callerSub": "user-42"
}HTTP 200
{
"orderId": "o-42",
"status": "READY",
"apiVersion": "v1"
}prod: GET caching enabled, TTL 60 s, cache keys = Authorization + orderId. beta: cache disabled. A cache hit skips Lambda; it must never cross user/tenant boundaries.
Developer control plane. Deploy an API snapshot; point a stage to it; configure its variables, cache and logs. Here the integration target is orders:${stageVariables.functionAlias} (shorthand). prod → Lambda alias prod/v1; beta → alias beta/v2. Grant API Gateway permission to invoke those aliases. A stage, API deployment, and Lambda version are separate objects; stages do not automatically isolate code or data.
Custom domain. https://api.example.com/orders/GetOrder can map orders → this API's prod stage. The mapping selects the stage even when its name is absent from the public URL.
Evidence. Stage access/execution logs, CloudWatch metrics and enabled traces explain requests. CloudTrail records API configuration changes. The numbered checkpoints explain responsibilities, not a guaranteed internal execution order.
| Feature | REST API | HTTP API |
|---|---|---|
| Stages / deployments | Yes | Yes; optional auto-deploy |
| Usage plans / API keys | Yes | No |
| Managed API cache / canary | Yes | No |
| VTL body mapping | Yes | No; parameter mapping available |
| Native JWT authorizer | Cognito authorizer or Lambda | Yes, including Cognito tokens |
| IAM / Lambda authorizer | Yes | Yes |
{
"name": "PartnerDemo",
"apiStages": [
{
"apiId": "a1b2c3d4e5",
"stage": "prod"
},
{
"apiId": "a1b2c3d4e5",
"stage": "beta"
}
],
"throttle": {
"rateLimit": 10,
"burstLimit": 20
},
"quota": {
"limit": 1000,
"period": "DAY"
}
}Create or import PartnerApp’s API key, then attach it to this plan separately. Mark GET /GetOrder as API Key Required. Both stages share this example’s per-key limits; the key does not route traffic. Quotas/throttles are best effort. Cache only safely scoped responses, with TTL/invalidation appropriate for changes in data and entitlements.
AWS reference: Stages & invocation URL · Usage plans · Stage variables · Mappings · Cache · Canary · REST vs HTTP
AWS Lambda
Execute event-driven code without operating a conventional server fleet.
- For conventional Lambda compute, memory is 128–10,240 MB; CPU grows with memory, with about one vCPU at 1,769 MB.
- Layers share code/dependencies and custom runtime content; they do not allocate extra CPU.
- Published versions are immutable. $LATEST is unpublished. An alias points to a published version and can weight a second version.
Decision boundary. Call the alias to use its routing policy. An alias cannot point to another alias. A new version alone does not create a canary.
| Control | Purpose | Does not mean |
|---|---|---|
| Memory | Memory + proportional CPU | Independent CPU selector for this compute mode |
| Reserved concurrency | Reserve and cap function concurrency | Warm execution environments |
| Provisioned concurrency | Pre-initialize environments for a version/alias | A newer deployed version |
| Weighted alias | Probabilistic split across two versions | Exactly 10 of every 100 calls |
{
"FunctionName": "orders",
"Name": "prod",
"FunctionVersion": "1",
"RoutingConfig": {"AdditionalVersionWeights": {"2": 0.1}}
}Rollback: remove additional weights and route prod to v1. Measure duration and cost together. Lambda Managed Instances has different compute configuration; do not generalize this memory-only rule to every Lambda offering.
AWS reference: Memory and CPU · Aliases · Newer managed-instance compute
AWS CloudFormation
Provision related resources as a versioned stack.
- Resources is required. Parameters, Mappings, Conditions, Outputs and Transform are optional sections.
- DependsOn is a resource attribute; there is no top-level Dependencies section. Ref/GetAtt also create implicit dependencies.
- Conditions gate resources/outputs or property values through Fn::If. Parameters supply inputs; a Condition cannot be attached to a parameter.
Decision boundary. Export names are unique per account/Region. Standard Fn::ImportValue references stay in that account/Region; an active import prevents changing/deleting the exported value.
| Expression | Meaning |
|---|---|
| !Ref | Parameter value or resource-specific return value |
| !GetAtt | Resource attribute |
| !Sub | String substitution |
| !FindInMap [Map, TopKey, SecondKey] | Mapping lookup, e.g. Region → AMI |
| !If [Condition, Yes, No] | Conditional value |
| AWS::NoValue | Remove a property through Fn::If |
| AWS::AccountId / AWS::Region / AWS::StackName | Context pseudo parameters |
AWSTemplateFormatVersion: '2010-09-09'
Parameters:
Environment:
Type: String
AllowedValues: [dev, prod]
Conditions:
IsProd: !Equals [!Ref Environment, prod]
Resources:
Orders:
Type: AWS::SQS::Queue
Properties:
MessageRetentionPeriod: !If [IsProd, 1209600, 345600]
Outputs:
QueueArn:
Value: !GetAtt Orders.Arn
Export:
Name: !Sub '${AWS::StackName}-QueueArn'StackSets deploy a template across selected accounts/Regions with parameters and permissions. This is different from a same-Region export/import dependency. Consult current docs for newer cross-Region output-reference features.
AWS reference: Template sections · Exports and imports · StackSets
AWS CDK
Define AWS infrastructure using programming-language constructs.
- Compose constructs into stacks/apps using TypeScript, JavaScript, Python, Java, C#/.NET or Go.
- cdk synth produces CloudFormation templates; cdk deploy uses CloudFormation to create or update the stack.
- Covers serverless and other infrastructure: Lambda, APIs, VPCs, EC2, ECS, databases and more. Reusable constructs can generate many resources.
Decision boundary. CDK is not a runtime and is not limited to servers. SAM and CDK both describe infrastructure; choose serverless YAML shorthand/local tooling versus general programming-language composition.
| Step | Responsibility |
|---|---|
| Construct | Reusable infrastructure component in code |
| Stack | Deployment unit that maps to a CloudFormation stack |
| cdk synth | Generate CloudFormation; does not start a production application |
| cdk deploy | Provision/update the stack through CloudFormation |
from aws_cdk import Stack, aws_lambda as lambda_
from constructs import Construct
class OrdersStack(Stack):
def __init__(self, scope: Construct, construct_id: str, **kwargs):
super().__init__(scope, construct_id, **kwargs)
lambda_.Function(self, "Orders",
runtime=lambda_.Runtime.PYTHON_3_13,
handler="app.handler",
code=lambda_.Code.from_asset("src"))cdk init → write constructs → build if needed → cdk synth → cdk deploy. SAM can also declare ordinary CloudFormation resources; serverless scope versus broad infrastructure is a preference, not an absolute capability boundary.
AWS reference: CDK concepts · CDK synthesis
AWS SAM
Define, build, test and deploy a serverless application.
- The SAM template extends CloudFormation; Transform: AWS::Serverless-2016-10-31 expands shorthand into deployable resources.
- The SAM CLI builds/packages code, invokes supported functions locally, emulates supported API routes and deploys through CloudFormation.
- Mix AWS::Serverless::* shorthand with standard AWS::* resources in the same template. The resulting Lambda functions/API/database run in AWS.
Decision boundary. SAM is infrastructure and development tooling, not compute. AWS::Serverless::UserPool is invalid; use AWS::Cognito::UserPool. Local testing does not reproduce every cloud behavior.
| Common shorthand resource | What it defines |
|---|---|
| AWS::Serverless::Function | Lambda function + supported events, permissions and deployment settings |
| AWS::Serverless::Api | API Gateway REST API |
| AWS::Serverless::HttpApi | API Gateway HTTP API |
| AWS::Serverless::SimpleTable | A DynamoDB table with simplified configuration |
| AWS::Serverless::StateMachine | Step Functions state machine |
| AWS::Serverless::LayerVersion | Lambda layer version |
| AWS::Serverless::Application | Nested/reusable serverless application, including SAR applications |
Transform: AWS::Serverless-2016-10-31
Resources:
Handler:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.13
Handler: app.handler
CodeUri: src/
Events:
GetOrder:
Type: HttpApi
Properties:
Path: /GetOrder
Method: GET
Users:
Type: AWS::Cognito::UserPoolsam init → sam build → sam local invoke / sam local start-api → sam deploy --guided. The table lists common types; the current reference includes additional shorthand resources. SAM remains explicit in exam skills 3.2.4, 3.3.1, 3.3.4 and 3.4.3.
AWS reference: SAM overview · Current resource types · Function contract · DVA-C02 Deployment scope
AWS Serverless Application Repository
Find, share and deploy versioned reusable serverless applications.
- Applications package a SAM template with deployment artifacts; choose an application version and supply its parameters.
- Publish privately for a team/organization or publicly, subject to sharing permissions.
- AWS::Serverless::Application can reference a repository application; deployment creates the underlying application resources.
Decision boundary. SAR is an application repository, not compute. Service Catalog governs approved products; AWS Marketplace distributes third-party software/services.
| Need | Choose |
|---|---|
| Reuse a deployable serverless application | SAR |
| Govern approved IT products | Service Catalog |
| Acquire third-party software/services | Marketplace |
Transform: AWS::Serverless-2016-10-31
Resources:
SharedApplication:
Type: AWS::Serverless::Application
Properties:
Location:
ApplicationId: arn:aws:serverlessrepo:us-east-1:123456789012:applications/example-app
SemanticVersion: 1.0.0Replace the application ARN/version, grant required access and provide the application’s required parameters. Inspect the template and permissions before deployment.
AWS reference: SAR overview · SAM nested application
Amazon DynamoDB
Key-value/document storage organized around key-based access.
- GameName + Version identifies a game version; querying GameName returns its versions. Category + GameName on a GSI supports category lookup.
- A GSI only returns projected attributes; use ALL when the index must return every game attribute. GSI reads are eventually consistent.
- TTL is a Number containing Unix seconds. Expiration is asynchronous cleanup; TTL deletions can appear in Streams. Filter expired data when required.
Decision boundary. Read-then-write can race. Use an atomic conditional write for a request ID, then coordinate status/results with business side effects.
| Capacity | Best starting clue | Watch |
|---|---|---|
| On-demand | Variable / uncertain request volume | Hot keys and service quotas still apply |
| Provisioned | Predictable load; set read/write capacity | Throttle if capacity is insufficient; consider Auto Scaling |
{
"TableName": "RequestLedger",
"Item": {
"RequestId": {"S": "req-42"},
"Status": {"S": "IN_PROGRESS"},
"ExpiresAt": {"N": "1793318400"}
},
"ConditionExpression": "attribute_not_exists(RequestId)"
}The key schema must make RequestId the primary key in this separate ledger. A successful claim does not prove the payment/write completed; persist outcomes and recover abandoned work. A String Version sorts lexically; use Number or suitable encoding for numeric ordering.
AWS reference: Global secondary indexes · TTL · Conditional expressions
Amazon SQS
Buffer work so consumers can process it independently.
- Receive hides a message; DeleteMessage acknowledges success. Default visibility is 30 seconds, maximum 12 hours; duplicates still require idempotency.
- PurgeQueue removes messages and keeps the queue. DeleteQueue removes both. RemovePermission edits queue-policy permission.
- Choose queue type at creation; it cannot be converted later. Source and DLQ types must match. Queue tags are case-sensitive.
Decision boundary. VisibilityTimeout hides received work; DelaySeconds postpones initial availability; MessageRetentionPeriod limits retention. They are different clocks.
| Type | Delivery / order | Use when |
|---|---|---|
| Standard | At least once; best-effort order | High throughput, order not required |
| FIFO | Ordered within a message group; producer deduplication | Ordering/deduplication required; consumers remain idempotent |
{
"QueueUrl": "https://sqs.ap-southeast-2.amazonaws.com/123456789012/orders",
"MaxNumberOfMessages": 10,
"WaitTimeSeconds": 20,
"VisibilityTimeout": 60
}Backlog per worker = ApproximateNumberOfMessagesVisible / running workers. Target backlog = acceptable wait / average processing time. Apply target tracking to ECS with an appropriate task-count metric and a scale-from-zero strategy.
AWS reference: Visibility and acknowledgement · Queue attributes · Queue-based scaling
Kinesis Data Streams
Retain continuous events in shard lanes for independent, replayable reads.
- A stream contains shards; shards contain records. Partition keys map records to a shard, where Kinesis assigns sequence numbers.
- PutRecords batches records. HTTP 200 can include partial failures: inspect FailedRecordCount and each result; retry only failed entries with backoff and jitter.
- ProvisionedThroughputExceededException indicates capacity/hot-key pressure; InternalFailure is a service-side record error. Preserve an application event ID for deduplication.
Decision boundary. Spreading partition keys can fix a hot shard. Increasing provisioned shards can add capacity; merging shards or sending more requests does not fix producer throttling.
A record is one event: a data blob + partition key, assigned a sequence number when accepted. A shard is an ordered lane of records with its own throughput capacity. A stream contains those lanes. A record belongs to one shard; the shard is not a batch sent to the consumer.
Example. Devices send readings continuously. Each record totals 4 KiB = 4,096 bytes, including its partition key, before base64 encoding. The sample below illustrates sustained provisioned capacity, without producer aggregation or burst allowances.
↓ Partition-key hash → shard hash range
Many keys are assumed evenly distributed in this model. With one shard, all records still enter that lane.
↓ Read records from each shard; track progress per shard
300 records/s exceed one shard's sustained byte budget. Some writes can be throttled; retry failed records with backoff and jitter.
Per shard: min(1,000 records/s, 1,024 KiB/s ÷ 4 KiB) = 256 records/s. At 300 records/s, at least 2 evenly loaded shards are needed before headroom.
Two limits, one lane. Each shard supports sustained writes up to 1 MiB/s and 1,000 records/s; whichever is reached first limits you. At 4 KiB, bytes win. With 512-byte records, the record-count limit would win. These are rates, not the shard's total storage size.
Reading is independent. Shared-throughput consumers share up to 2 MiB/s per shard; enhanced fan-out provides up to 2 MiB/s per shard per registered consumer. Reading does not delete records. Retention controls replay; there is no global order across shards. PutRecords retries can also change producer event order.
Capacity ≠ retention. The lane continues accepting records over time; it does not fill at 1 MiB and move to the next shard. Control-plane scaling changes the shard layout; data-plane calls write/read records. On-demand manages capacity for you, but a hot partition key still needs attention.
| Capacity mode | Who manages capacity | Watch |
|---|---|---|
| Provisioned | You set shard count | Per-shard throughput / hot partition keys |
| On-demand | Service scales stream capacity | Scaling boundaries, hot keys and quotas still apply |
{
"FailedRecordCount": 1,
"Records": [
{"SequenceNumber": "101", "ShardId": "shardId-000000000000"},
{"ErrorCode": "ProvisionedThroughputExceededException",
"ErrorMessage": "Rate exceeded"}
]
}Results align with request order. PutRecords does not guarantee ordering across successful and retried records. Reducing readers does not directly fix producer-side write throttling.
AWS reference: Producer API and partial failures · Streams, records & shards · Sustained shard capacity · Current quotas & large-record limits · Enhanced fan-out
Amazon ECS
Orchestrate container tasks and services; choose their compute separately.
- ECS schedules tasks/services. A task definition is the container blueprint; a service maintains the desired tasks. EC2 and Fargate are distinct capacity choices.
- Task-local ephemeral/bind-mount data is suitable for temporary files. EC2 host volumes depend on host lifecycle.
- EFS provides persistent shared network files for supported ECS/Fargate tasks across AZs. Configure mount targets, NFS access and file permissions.
Decision boundary. A local volume is not a shared cross-AZ filesystem. Fargate EFS support requires a supported Linux platform; do not assume every OS/launch mode supports it.
| Need | Choose | Lifecycle |
|---|---|---|
| Temporary task files | Ephemeral storage / supported bind mount | Task/host dependent |
| Shared persistent files | EFS | Independent of task replacement |
| Host configuration control | ECS on EC2 | You manage host capacity |
| Managed container compute | Fargate | Task CPU/memory allocation |
{
"volumes": [{
"name": "shared",
"efsVolumeConfiguration": {
"fileSystemId": "fs-example",
"transitEncryption": "ENABLED"
}
}],
"containerDefinitions": [{
"name": "worker", "image": "example/worker:1",
"mountPoints": [{"sourceVolume": "shared", "containerPath": "/data"}]
}]
}The excerpt omits task roles, CPU/memory, networking and other required task settings. Add an EFS access point/IAM authorization where needed; a mount declaration alone does not grant access.
AWS reference: ECS concepts and capacity · EFS with ECS / Fargate
AWS Fargate
Supply managed compute capacity for containers without managing EC2 hosts.
- For ECS, define the image, task CPU/memory, networking and roles; Fargate supplies isolated task compute.
- ECS still schedules tasks/services. You continue to own the container, IAM permissions, security groups and application behavior.
- Task-local storage is ephemeral. Use supported EFS integration when tasks need shared persistent files.
Decision boundary. Fargate is container compute; ECS is orchestration. Fargate does not build images or define infrastructure templates. Choose self-managed EC2 capacity when host-level requirements demand it.
| Capacity choice | Trade-off |
|---|---|
| Fargate | Managed task compute; supported CPU/memory/platform combinations |
| Fargate Spot | Discounted interruptible capacity; design interruption-tolerant work |
| ECS on EC2 | Host control and host-capacity responsibilities |
{
"family": "orders-worker",
"requiresCompatibilities": ["FARGATE"],
"networkMode": "awsvpc",
"cpu": "256",
"memory": "512",
"containerDefinitions": [{
"name": "worker",
"image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/orders:1",
"essential": true
}]
}Add task execution/application roles and the network configuration when launching tasks. The task execution role covers supported agent actions such as image pulls; the task role grants permissions to application code.
AWS reference: Fargate with ECS
Amazon RDS
Managed relational databases with SQL and transactions.
- Read replicas asynchronously copy data; the application must send reads to replica endpoints. Expect possible replication lag.
- A traditional Multi-AZ DB instance has a standby for failover, not reads.
- A Multi-AZ DB cluster has readable standby DB instances; engine/configuration support matters.
Decision boundary. Read load points to replicas; failover points to Multi-AZ; repeated reusable results may point to a cache. These choices can coexist.
| Option | Main purpose | Readable secondary? |
|---|---|---|
| Read replica | Scale reads | Yes; async replication lag |
| Multi-AZ DB instance | Availability / failover | No |
| Multi-AZ DB cluster | Availability + read capacity | Yes, supported cluster engines |
# Application routing, not an AWS API payload
write_connection = connect(primary_endpoint)
report_connection = connect(read_replica_endpoint)
# Use the primary for reads that require the latest committed value.AWS reference: Multi-AZ instance vs cluster · Read replica operation
Amazon ElastiCache
Keep frequently reused data in memory.
- Valkey, Redis OSS and Memcached support low-latency cached access; choose engine capabilities deliberately.
- A cache hit can reduce database work. A miss still needs a source-of-truth lookup.
- Use expiry and invalidation to manage staleness. Memcached is not a durable primary database.
Decision boundary. A cache endpoint does not execute relational SQL in place of RDS. Cache-aside requires application logic and a key design.
| Deployment | Operational choice | Pricing shape |
|---|---|---|
| Serverless | Service manages cache capacity | Data storage + request/compute usage |
| Node-based | Select node types/count/topology | Provisioned nodes; reservation options where supported |
key = f"game:{name}:{version}"
value = cache.get(key)
if value is None:
value = database.load_game(name, version)
cache.set(key, serialize(value), ttl=60)
return deserialize_if_needed(value)AWS reference: Engine and deployment options
IAM, STS & Access Analyzer
Establish AWS trust and evaluate permissions.
- Identity policies grant actions; supported resource policies grant access to resources. A role trust policy says who may assume it; STS issues temporary credentials.
- Permissions boundaries and SCPs limit applicable permissions; they do not grant actions. An explicit applicable deny overrides an allow.
- Access Analyzer finds supported external/unused access and validates policies. Policy variables can scope reusable access, e.g. an IAM user’s own S3 prefix.
Decision boundary. Trusting an identity does not authorize every resource. ${aws:username} is for IAM users and is not generally present for role sessions; use suitable principal tags/identity variables.
IAM-user prefix policy (illustrative){
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow", "Action": "s3:GetObject",
"Resource": "arn:aws:s3:::study-home/${aws:username}/*"
}]
}Billing-console access can require the account root user to Activate IAM Access plus appropriate IAM permissions. SCPs govern member-account principals within their documented scope; they are not a universal policy attached to every possible caller.
AWS reference: Policy evaluation · Access Analyzer · Policy variables · Billing console activation
Security groups & NACLs
Filter network traffic at two different boundaries.
- Security groups attach to network interfaces and are stateful: allowed traffic automatically permits its response.
- NACLs operate at subnet boundaries and are stateless: allow the required request and return traffic, including ephemeral ports.
- Check routes, security groups, NACLs, listener and target health separately when diagnosing connectivity.
Decision boundary. Network reachability does not authenticate a user or grant an IAM action. Security groups use allow rules only; NACLs support allow and deny.
| Control | Scope | Rules | Response traffic |
|---|---|---|---|
| Security group | Network interface | Allow only | Stateful |
| NACL | Subnet boundary | Allow + deny; rule order | Stateless; explicit return rules |
client --HTTPS 443--> public ALB
ALB security group --app port--> private target security group
subnet NACL: allow request + return-port traffic both waysAWS reference: VPC security controls · Security group / NACL comparison
Amazon S3 encryption
Store objects; enforce the encryption contract at upload.
- New S3 uploads are encrypted by default. SSE-S3 uses AES256; SSE-KMS uses aws:kms in the encryption request header.
- Default bucket encryption chooses storage encryption even when the client omits a header.
- A bucket policy can require an explicit mode/key. Missing-header checks and incorrect-value checks express different requirements.
Decision boundary. Requiring a request header rejects clients that rely on bucket defaults. Requiring aws:kms alone does not pin a particular KMS key; validate its key ID/ARN when required.
| Mode | Header value | Keys / costs |
|---|---|---|
| SSE-S3 | AES256 | S3 manages keys; baseline encryption |
| SSE-KMS | aws:kms | KMS policy/use permissions; KMS charges may apply |
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyMissingEncryptionHeader",
"Effect": "Deny", "Principal": "*",
"Action": "s3:PutObject", "Resource": "arn:aws:s3:::study-bucket/*",
"Condition": {"Null": {"s3:x-amz-server-side-encryption": "true"}}
}, {
"Sid": "DenyWrongEncryptionMode",
"Effect": "Deny", "Principal": "*",
"Action": "s3:PutObject", "Resource": "arn:aws:s3:::study-bucket/*",
"Condition": {"StringNotEquals": {"s3:x-amz-server-side-encryption": "aws:kms"}}
}]
}Illustrative bucket name. This narrow policy shows request enforcement, not complete bucket access. KMS upload/download permissions and bucket policies must also allow the intended principal.
AWS reference: SSE-KMS and enforcement
AWS KMS
Control cryptographic keys and cryptographic operations.
- Use a KMS key directly for supported small payloads; use envelope encryption for larger application data.
- GenerateDataKey returns plaintext and encrypted copies of a data key. Encrypt data locally, discard plaintext key, store the encrypted key with ciphertext.
- Normal crypto calls do not return the underlying KMS key material. Rotation support depends on key type/origin; rotating key material is not recreating a key per request.
Decision boundary. Encryption does not replace authorization. A principal needs the relevant service access and KMS key-use authorization; cross-account use requires compatible policies.
Large-payload encryption pseudocode# Envelope encryption, conceptual flow
plain_key, encrypted_key = kms.generate_data_key(key_id, key_spec="AES_256")
ciphertext = authenticated_encrypt(plain_key, document)
securely_discard(plain_key)
store(ciphertext, encrypted_key)
# Later: KMS Decrypt(encrypted_key) → data key → decrypt document.AWS reference: Envelope encryption · Data keys · Key rotation
Amazon Cognito
Authenticate application users; federate them into AWS access when needed.
- User pools provide a user directory/federation and issue ID/access JWTs plus refresh tokens.
- Identity pools exchange supported identities for temporary AWS credentials, including narrowly scoped guest access when enabled.
- API Gateway can authorize with Cognito tokens; a Lambda authorizer supports custom token validation/rules. HTTP APIs have native JWT authorizers.
Decision boundary. A user-pool JWT is not an access key. A browser may call your API with a bearer token, while the backend calls AWS with its own role credentials.
| Requirement | Choose | What comes out |
|---|---|---|
| Sign in app users | User pool (+ external IdP if needed) | ID/access JWT + refresh token |
| Direct AWS resource access | Identity pool + IAM role | Temporary access key/secret/session token |
| Custom API rules | Lambda authorizer | API authorization result |
| AWS API invocation | Authorized IAM principal + SigV4 | Signed request |
# Authenticated application → protected API
Authorization: Bearer <access-token-JWT>
# Direct AWS SDK access uses temporary credentials instead
{"AccessKeyId":"<temporary-id>",
"SecretKey":"<temporary-secret>",
"SessionToken":"<session-token>",
"Expiration":"<expiry>"}Validate token signature, issuer, audience/client binding, token_use and expiry; apply required scopes and record/tenant rules. User and identity pools can be combined. Never place a secret credential in a public client bundle.
AWS reference: User pools · Identity pools and AWS credentials · API authorizer choices
Secrets Manager & Parameter Store
Separate credentials from application configuration.
- Secrets Manager stores secrets and supports automatic rotation through service-managed integrations or Lambda workflows, depending on secret type.
- Parameter Store stores named configuration, versions and encrypted SecureString values; it has no equivalent native database-password rotation workflow.
- Grant runtime roles narrow read/decrypt access. Retrieve and cache values appropriately; do not embed secrets in code or logs.
Decision boundary. Rotating RDS credentials points to Secrets Manager. An expiration notification/parameter policy is not a password-rotation implementation.
| Option | Use | Pricing / lifecycle |
|---|---|---|
| Secrets Manager | Credentials + rotation | Per secret + API use; integration-specific rotation |
| Parameter Store Standard | Small static config | Standard storage free; throughput options may bill |
| Parameter Store Advanced | Larger values, policies, more scale | Per advanced parameter + API/throughput charges |
| AppConfig | Validated configuration / feature rollout | Separate controlled deployment capability |
# AWS CLI; never print this result in application logs
aws secretsmanager get-secret-value --secret-id prod/orders/db
aws ssm get-parameter --name /prod/orders/endpoint
aws ssm get-parameter --name /prod/orders/token --with-decryptionSecureString needs appropriate KMS permissions. Parameter Store can reference a Secrets Manager secret as a pass-through; the rotation capability still belongs to Secrets Manager.
AWS reference: Parameter Store comparison · Secrets rotation
CloudWatch, CloudTrail & tracing
Choose evidence that can actually answer the question.
- CloudWatch metrics show aggregate demand/latency/errors; Logs hold application events when configured.
- ALB access logs show client IP, path, timing and status. CloudTrail shows supported AWS API/account events, not every HTTP request.
- Trace IDs correlate requests; distributed tracing reveals downstream latency when the application/services are instrumented.
Decision boundary. Check target health settings and reachability before scaling an unhealthy target. Adding capacity does not fix a wrong health-check path or denied request.
Investigation sequencesymptom: HTTP 5xx increased after deployment
1. CloudWatch: when, how many, ALB or target errors?
2. ALB access logs: which path / target / status / timing?
3. Trace + app log: which dependency failed?
4. CloudTrail: who changed the configuration?CloudTrail data events are service/operation-specific and often require explicit enablement. They do not replace application access logs. Avoid sensitive credentials/payloads in diagnostic logs.
AWS reference: ALB request evidence · CloudTrail event types · CloudWatch concepts
AWS CodePipeline
Coordinate the stages that turn a source revision into a release.
- Source, build/test, approval and deploy actions form an orchestrated delivery workflow.
- CodePipeline passes artifacts and invokes action providers. CodeBuild runs build commands; CloudFormation and CodeDeploy perform their respective deployment actions.
- A pipeline service role and action-specific permissions authorize delivery. They are separate from the runtime application role.
Decision boundary. A successful pipeline action proves that action succeeded; verify which artifact, configuration and route are actually serving production.
| Type | Choice | Cost comparison |
|---|---|---|
| V1 | Standard pipeline/stage/action structure | Compare active-pipeline pricing |
| V2 | Adds release-safety and trigger configuration | Compare action-execution pricing; see current rates |
{
"name": "BuildAndTest",
"actions": [{
"name": "Build",
"actionTypeId": {
"category": "Build", "owner": "AWS",
"provider": "CodeBuild", "version": "1"
},
"configuration": {"ProjectName": "orders-build"},
"inputArtifacts": [{"name": "SourceOutput"}],
"outputArtifacts": [{"name": "BuildOutput"}]
}]
}This is one stage, not a complete CreatePipeline request. Source connection, roles, artifact storage and deploy actions are configured elsewhere.
AWS reference: Pipeline responsibility · Pipeline types · Current pricing
AWS CodeBuild
Run build/test commands and produce a deployable artifact.
- The buildspec defines phases, commands and artifact output. A managed build environment runs those commands.
- Package Lambda ZIPs or container images for the target runtime. S3 stores build artifacts; ECR stores container images; CodeArtifact stores software packages.
- Run unit/integration tests and inspect their results. Amazon Q Developer can assist with code and tests; developers still review and validate the result.
Decision boundary. Compiling code is not deploying it. A passing unit test does not prove the production integration, IAM permissions or active route are correct.
| Compute choice | Starting clue | Watch |
|---|---|---|
| EC2 on-demand | Flexible build environment without a standing fleet | Image, architecture and resource requirements |
| EC2 reserved capacity | Manage a fleet for predictable build demand | Capacity commitment and utilization |
| Lambda compute | Fast startup for supported builds | Supported runtimes, features and duration limits |
version: 0.2
phases:
install:
commands:
- pip install -r requirements.txt -t package/
build:
commands:
- python -m pytest tests/
- cp app.py package/
- cd package && zip -r ../function.zip .
artifacts:
files:
- function.zipThe example assumes a suitable Linux build image with pytest and zip available, and the named project files. Pin dependencies and select compute from measured build requirements.
AWS reference: CodeBuild role · Compute modes · Buildspec contract · Q Developer in exam scope
AWS CodeDeploy
Roll out an application revision using a platform-specific deployment contract.
- Supports EC2/on-premises, Lambda and ECS deployment platforms.
- The AppSpec describes target resources and lifecycle hooks. Deployment configuration controls rollout; configured alarms/hooks support validation and recovery.
- Lambda traffic shifting moves an alias between published versions. ECS blue/green shifts service traffic; EC2 deployments can update in place or use replacements.
Decision boundary. CloudFormation manages declared resources and can deploy application resources/code. CodeDeploy specializes in rollout, hooks and traffic shifting; it does not build the artifact.
| Target | Release unit | Key distinction |
|---|---|---|
| Lambda | Published versions + alias | Canary/linear/all-at-once traffic configuration |
| ECS | Task definition + target service | Blue/green task sets and traffic routing |
| EC2/on-premises | Application revision + hooks | In-place or supported blue/green deployment |
version: 0.0
Resources:
- OrdersFunction:
Type: AWS::Lambda::Function
Properties:
Name: orders
Alias: prod
CurrentVersion: '1'
TargetVersion: '2'The deployment group, service role, traffic policy, alarms and optional hooks are configured separately. Verify the actual alias/target and business health before considering a release complete.
AWS reference: Platforms and rollout · AppSpec examples
EventBridge & SNS
Route events or fan a publication out to independent consumers.
- EventBridge connects event sources to matching targets; bus and feature selection determine supported routing/replay behavior.
- SNS publishes to topics and pushes to subscribed endpoints. An SNS-to-SQS fanout gives consumers independent queues.
- A consumer needs its own authorization, retry and idempotency handling. An accepted publication does not prove the business work completed.
Decision boundary. A router or topic does not retain the progress of a multi-step business workflow. A queue buffers pending work; a state machine coordinates steps.
| Need | Starting choice |
|---|---|
| Route by event content / source | EventBridge bus and matching target configuration |
| Publish once to multiple subscribers | SNS topic; optional subscription filters |
| Independent backlogs per consumer | SNS/EventBridge delivery to separate SQS queues |
| Durable progress across ordered steps | Step Functions workflow |
{
"Entries": [{
"Source": "com.example.orders",
"DetailType": "OrderAccepted",
"Detail": "{\"orderId\":\"o-42\",\"requestId\":\"r-42\"}",
"EventBusName": "orders"
}]
}This illustrates the JSON PutEvents contract for a compatible configured bus. Check per-entry publication results and the exact bus mode; current EventBridge bus types have different feature contracts.
AWS reference: EventBridge capabilities · SNS fanout
AWS Step Functions
Coordinate application steps with explicit state and failure handling.
- A state machine expresses service calls, branching and supported waits/retries/catches.
- Lambda or ECS executes task code; Step Functions retains workflow progress. The workflow execution role needs target-service permissions.
- Choose workflow type from duration, integration and execution-semantics requirements; make external side effects idempotent.
Decision boundary. CodePipeline coordinates software delivery; Step Functions coordinates application/business work. A workflow is optional when one handler or independent consumers suffice.
| Type | Primary boundary | Billing shape |
|---|---|---|
| Standard | Durable execution, up to one year; supported callback/job integrations | State transitions |
| Express | Short high-volume execution, up to five minutes; integration differences | Executions + duration/memory |
{
"StartAt": "RecordOrder",
"States": {
"RecordOrder": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Parameters": {"FunctionName": "orders", "Payload.$": "$"},
"End": true
}
}
}The sample omits retries and business error handling. Workflow execution semantics do not make an external payment exactly once; plan for uncertain task outcomes and replay.
AWS reference: Workflow types · Lambda integration
AWS AppConfig
Validate and gradually deploy application configuration or feature flags.
- Separate configuration data from the code artifact so supported behavior can change without rebuilding code.
- Validators check configuration; deployment strategies control rollout. Configured monitoring can trigger recovery.
- Applications retrieve configuration through supported agents/APIs. Parameter Store and Secrets Manager have different storage/rotation responsibilities.
Decision boundary. Creating a configuration version does not make every running process use it. Verify deployment, environment and application retrieval/cache behavior.
StartDeployment: illustrative identifiers{
"ApplicationId": "a1b2c3d",
"EnvironmentId": "e1f2g3h",
"ConfigurationProfileId": "p1q2r3s",
"ConfigurationVersion": "7",
"DeploymentStrategyId": "d1e2f3g"
}The application, environment, profile, validators, deployment strategy and monitoring must already be configured. Current pricing depends on retrieval/deployment usage; check AWS rates for the chosen retrieval pattern.
AWS reference: Configuration rollout · StartDeployment contract