The DVA-C02 exam rarely tests a single service in isolation. Most scored items describe a business requirement in prose and ask you to assemble three to six services into the right shape — then, frequently, to defend that shape against a plausible-sounding but wrong alternative. This module walks five architectures that recur constantly across the exam blueprint, stage by stage, explaining not just what connects to what, but why that specific service was the correct choice at that specific stage over its nearest competitor.
This guide assumes you already understand each individual service reasonably well. Its job isn't to re-teach ECS or Cognito — it's to show how they combine, and to drill the specific exam skill of choosing the correct service at each stage of a described architecture rather than recalling isolated facts. If a stage below feels unfamiliar, follow its link back to the relevant service guide before continuing.
Every architecture uses the same three-part treatment: a step-by-step .vflow diagram (what happens at each stage, and why that AWS service — not an alternative — was chosen there), supporting prose that goes deeper on the trickiest decisions, and a closing comparison card that names the runner-up services and explains why they lost.
| # | Architecture | Core Service Chain | Primary Exam Theme |
|---|---|---|---|
| 1 | Containerised Application | ECR → ECS/Fargate → ALB → CloudWatch/X-Ray | Least-ops container hosting; awsvpc networking; task role vs execution role |
| 2 | Serverless API | API Gateway (HTTP API) → Cognito authorizer → Lambda → DynamoDB → X-Ray | REST vs HTTP API; proxy integration; serverless-to-serverless pairing |
| 3 | CI/CD Deployment Pipeline | Source → CodePipeline → CodeBuild → ECR/S3 → CodeDeploy blue/green → target | Build vs deploy service split; artifact handoff; blue/green mechanics |
| 4 | Enterprise Application Deployment | CloudFormation/CDK → VPC + Beanstalk/ECS → per-stage config → Auto Scaling + ALB | IaC tool choice; PaaS vs container control; environment isolation |
| 5 | Secure Application (Auth + Observability) | Cognito → API Gateway authorizer → Lambda/ECS → X-Ray → CloudWatch | User Pools vs Identity Pools; token validation placement; end-to-end tracing |
Read the requirement and identify the workload shape — is it request/response (API), long-running/containerised, a release process, a multi-environment rollout, or auth-gated?
Match the shape to one of the five patterns above. Most DVA-C02 scenario questions are a variation of one of these five, sometimes with only one stage swapped.
Scan for the phrase "least operational overhead" or "without managing servers/infrastructure." This single phrase eliminates any option that involves patching, capacity planning, or self-managed clusters — it is the single highest-value keyword on this exam.
For every remaining option, ask "what does this service NOT do?" — most distractors are services that are close but solve an adjacent problem (a build tool offered where a deploy tool is needed, a REST API offered where cost/latency call for HTTP API, an IAM role offered where an STS session is the actual mechanism).
Pick the option that satisfies every explicit constraint in the stem — not just the most "modern-sounding" service. A correct answer that ignores one stated constraint is still wrong.
Exam appearance probability: HIGH
ECR → ECS/Fargate → ALB → CloudWatch/X-Ray, with an optional API Gateway front door.
A developer commits application code; a CI process (Architecture 3) builds a Docker image from a Dockerfile. Containerising packages the app plus its runtime and dependencies identically across dev/test/prod, removing "it works on my machine" drift.
The image is pushed to a private ECR repository, tagged with the commit SHA, and scanned on push. Why ECR: it's an IAM-authenticated registry natively integrated with ECS/Fargate task definitions, encrypted at rest by default, with lifecycle policies to prune old images automatically — chosen over Docker Hub or a self-hosted registry specifically because of that direct IAM + ECS integration.
A task definition references the ECR image URI and declares a task role (permissions the running application needs, e.g. read from S3) separately from the task execution role (permissions ECS itself needs to pull the image and write logs). Fargate is chosen over the EC2 launch type because the requirement is "run containers without managing the underlying instances" — no AMI patching, no capacity planning, no cluster-instance scaling to reason about. This is the default least-operational-overhead answer unless the scenario calls out GPU instances, custom AMIs, or Spot-driven cost optimisation at very large scale, in which case EC2 launch type re-enters the conversation.
awsvpc network mode gives each task its own elastic network interface and its own security group — mandatory for Fargate (there is no shared host networking to fall back to), and it also lets you scope security groups per task instead of sharing one instance-level security group across many unrelated tasks.
The ECS service registers tasks with an ALB target group using target type ip (not instance) — required because Fargate tasks aren't EC2 instances with a fixed instance ID to register by. The ALB is chosen over a Network Load Balancer because this is HTTP(S)-level traffic needing path/host-based routing rules, and because the ECS service controller natively drains and re-registers targets against an ALB target group during rolling deployments.
Added in front of the ALB only when the app needs API keys/usage plans, request throttling, or a single entry point shared with other backend services (including serverless ones from Architecture 2). For a single standalone container app, the ALB alone is sufficient — API Gateway earns its place when the same access-control/rate-limiting layer must span multiple backends.
CloudWatch Container Insights surfaces cluster/service/task-level CPU, memory, and network metrics with zero extra instrumentation. Distributed tracing needs an X-Ray daemon sidecar container (or the ADOT collector) inside the task, because Fargate has no host to install a daemon onto — this is the one place "agentless" doesn't apply, and it's a common trap: candidates assume X-Ray "just works" on Fargate the way GuardDuty's foundational detection does, but tracing requires an explicit sidecar.
The ECS service defaults to a rolling deployment (replace tasks in batches, respecting minimumHealthyPercent/maximumPercent), but a zero-downtime, instantly-reversible release uses CodeDeploy blue/green — a second, temporary "green" target group and listener validate the new task set before traffic shifts, with the "blue" set kept warm for instant rollback. This is the same CodeDeploy mechanism detailed in Architecture 3.
This is one of the most frequently tested ECS traps. The task execution role is what ECS itself assumes to pull the container image from ECR and push logs to CloudWatch Logs — it never touches your application code. The task role is what your running application code assumes to call other AWS services (S3, DynamoDB, etc.) via the container's credentials. Granting S3 access on the execution role instead of the task role is a guaranteed wrong answer on this exam.
EKS is justified when the team already has Kubernetes tooling, portability requirements across clouds, or complex custom-controller needs. For a straightforward containerised web app with no existing Kubernetes investment, EKS adds a control-plane and add-on management burden ECS doesn't have — over-engineering for this scenario.
EC2 launch type is right when you need GPU/specialised instance types, want to run many small tasks tightly packed onto instances you already reserved, or want deep control over the host. Without one of those explicit needs, choosing EC2 over Fargate reintroduces patching and capacity-planning overhead the requirement didn't ask for.
For task definition mechanics, the full task-role-vs-execution-role breakdown, and ECS-vs-EKS-vs-Fargate comparisons, see 01 — Containers, ECS, ECR, Fargate & EKS. For CodeDeploy blue/green mechanics, see 02 — CI/CD. For X-Ray sidecar tracing, see 05 — X-Ray. For the optional API Gateway front door, see 06 — API Gateway.
API Gateway (HTTP API) → Cognito authorizer → Lambda → DynamoDB, with X-Ray tracing end-to-end.
A web or mobile client calls an HTTPS endpoint carrying a bearer token in the Authorization header.
An HTTP API is chosen over a REST API because the requirement is a straightforward public/mobile JSON API needing the lowest cost and lowest latency, and the app doesn't need REST API's extra machinery — usage plans, API keys, request-validation schemas, response caching, or VTL mapping templates. HTTP API can be up to ~70% cheaper and measurably lower-latency than REST API for this exact shape of workload.
Attached directly to the protected routes, the authorizer validates the JWT's signature, expiry, and audience before API Gateway ever invokes Lambda — unauthenticated or expired requests never reach application code or incur a Lambda invocation. Cognito is chosen over a custom auth Lambda because it's a fully managed user directory with hosted UI, MFA, and token issuance/refresh already built and secured.
Lambda proxy integration passes the entire request (headers, path parameters, query string, body) straight to the function and expects a structured response back — chosen over non-proxy integration because it needs no VTL mapping-template maintenance, and the requirement is "arbitrary business logic per request," not a fixed pass-through to one downstream action.
Single-digit-millisecond reads/writes that scale automatically alongside Lambda's concurrency model — a relational database behind a connection pool would risk connection exhaustion under Lambda's bursty, highly concurrent invocation pattern. DynamoDB is the natural pairing for a fully serverless backend with simple access patterns and unpredictable traffic.
Tracing is enabled on both the API Gateway stage and the Lambda function, propagating one trace ID through to the DynamoDB call. The resulting service map shows exactly how much latency each hop (API Gateway → authorizer → Lambda → DynamoDB) contributed — essential once "which layer is slow" becomes a support question instead of a guess.
REST API becomes the right answer the moment the scenario introduces API keys for partner billing, per-client usage plans/throttling tiers, response caching, private (VPC-only) API endpoints, or rich request-body validation — features HTTP API doesn't offer. Absent those, REST API is simply the more expensive, higher-latency option for no added benefit.
This workload is small, request-shaped, and traffic is spiky/unpredictable — Lambda's per-invocation billing and instant scale-to-zero beat a continuously-running Fargate service on both cost and operational simplicity. ECS/Fargate becomes preferable only once the workload is steady-state, long-running, or resource-heavy (large in-memory state, GPU, sustained CPU) — see Architecture 1.
The Cognito authorizer on API Gateway expects the access token, not the ID token. The ID token proves who the user is to your own client application; the access token authorises calls to protected resources/APIs. Sending the wrong token is a common cause of a working sign-in but a failing API call.
For HTTP API vs REST API mechanics and proxy integration detail, see 06 — API Gateway. For User Pool token types and the authorizer flow, see 07 — Cognito. For annotations vs metadata in traced requests, see 05 — X-Ray.
Source → CodePipeline → CodeBuild → ECR/S3 artifact → CodeDeploy blue/green → target (ECS/Lambda/EC2).
A developer pushes code to a source repository. In current real-world practice this is GitHub, GitLab, or Bitbucket connected via CodeConnections (formerly CodeStar Connections). AWS CodeCommit stopped onboarding new customers in July 2024, and AWS CodeStar was deprecated earlier still — the exam may still reference CodeCommit as a legacy pipeline source action, but neither should be presented as a current recommendation. See the exam-vs-reality note below.
Orchestrates Source → Build → Deploy as explicit stages, with each stage's action producing an artifact passed to the next stage via an S3 artifact bucket. Chosen over a self-built Jenkins-style pipeline because it needs zero server management, supports manual approval gates, and triggers natively via EventBridge on a source change rather than polling.
Runs the buildspec.yml phases — install (dependencies), pre_build (e.g. ECR login, run unit tests), build (compile, docker build, or sam build), post_build (push image / package artifact). CodeBuild's entire job is "produce a build output" — it has no concept of a deployment target. Choosing CodeBuild to perform a deployment, or CodeDeploy to run a build, is a guaranteed wrong pairing.
The pipeline branches here based on target type: a containerised deployment pushes the built image to Amazon ECR with a build-specific tag; a serverless or EC2 deployment zips the build output to an S3 artifact bucket (often as a packaged CloudFormation/SAM template). The artifact format is dictated entirely by what the downstream deploy service expects to consume.
Reads appspec.yml and lifecycle hooks to perform the actual deployment. For ECS: provisions a new "green" task set behind a second (test) ALB listener, runs any validation lifecycle hooks, shifts production traffic once healthy, and keeps "blue" briefly available for instant rollback. For Lambda: shifts traffic between function versions via a weighted alias using linear or canary traffic-shifting. CodeDeploy — not CodePipeline itself — is the service that knows how to orchestrate this shift and tie automatic rollback to CloudWatch alarms.
The ECS service, Lambda function/alias, or EC2 Auto Scaling Group now runs the new version, with all traffic shifted — or automatically rolled back if a bound CloudWatch alarm breaches during the shift.
CodeCommit is closed to new customers as of July 2024, and CodeStar was deprecated even earlier. A real-world answer for the "Source" stage today is GitHub/Bitbucket/GitLab via CodeConnections. If an exam question describes an existing environment already using CodeCommit, treat it at face value for that question — but never select CodeCommit as the recommended solution for a net-new pipeline design.
| Comparison | Distinction |
|---|---|
| CodeBuild vs CodeDeploy | CodeBuild compiles/tests/packages — it produces an artifact and has no deployment-target concept. CodeDeploy takes a built artifact and rolls it out to a live target (in-place or blue/green) with rollback logic. |
| In-place vs Blue/Green | In-place updates the existing target directly (EC2/ASG only) — simpler but momentarily reduces capacity and offers no traffic-shifting safety net. Blue/green stands up a parallel environment/target set and shifts traffic only once validated — supported for EC2/ASG, ECS, and Lambda, and the standard answer whenever "zero downtime" or "instant rollback" appears in the stem. |
For deployment group configuration, appspec.yml lifecycle hooks, and the full CodeCommit/CodeStar deprecation detail, see 02 — CI/CD. For how this pipeline's ECS target maps to Architecture 1, see 01 — Containers. For how it deploys a CDK/SAM-defined stack, see 03 — IaC.
CloudFormation/CDK-provisioned VPC + Elastic Beanstalk (or ECS), per-stage environment configuration, Auto Scaling + ALB.
The platform team defines the environment in AWS CloudFormation templates, or a CDK app (TypeScript/Python/etc.) that synthesizes to CloudFormation — a VPC with public/private subnets across two or more Availability Zones, NAT gateways, and route tables. IaC is chosen over manual console provisioning because it's repeatable, version-controlled, peer-reviewable, shows exactly what will change via change sets before it changes, and supports drift detection to catch out-of-band console edits.
CDK is chosen when the platform team wants to define this VPC + environment pattern once as a reusable construct and stamp it out across dev/test/prod and multiple product teams using a real programming language — loops, conditionals, and unit tests on the infrastructure code itself. Plain CloudFormation is chosen when the org wants the simplest, most portable, build-step-free template, or when governance requires reviewing the literal deployed template rather than CDK's generated output.
Elastic Beanstalk is chosen when the team wants to upload an application bundle and let AWS provision and manage the EC2 instances, load balancer, and Auto Scaling group for them — a PaaS-convenience answer that still allows infrastructure customisation via .ebextensions when needed. ECS is chosen when the org has already standardised on containers and wants tighter control over deployment mechanics (custom task definitions, custom scaling policies) than Beanstalk exposes.
Separate CloudFormation parameter files (or CDK stages/context values) — and for Beanstalk, separate saved configurations — define distinct instance sizes, Auto Scaling min/max, and domain/certificate settings per dev/test/prod stage. This isolation prevents a test-stage change from silently reaching production and lets each stage's cost profile match its actual load.
Every stage's environment includes an Auto Scaling group (EC2-based, whether provisioned directly or via Beanstalk) fronted by an ALB with target-tracking scaling policies (e.g. average CPU or request count per target). This is the exam's default answer for "handle variable load with high availability" whenever the scenario doesn't specifically call for full containerisation or serverless.
The CI/CD pipeline from Architecture 3 deploys the same versioned artifact through dev → test → prod, with each stage's IaC stack staying structurally identical — same template, different parameters — so what was validated in test is exactly what runs in prod.
Once an environment exists, Beanstalk offers rolling, rolling with additional batch, immutable, and blue/green (via environment/CNAME swap) deployment policies — the same "how much capacity/risk am I willing to trade for deployment speed" spectrum as CodeDeploy's in-place vs blue/green choice in Architecture 3, just expressed inside a single Beanstalk environment.
When a scenario wants low operational overhead but the team also needs some infrastructure-level customisation (custom AMI tweaks, specific instance types, OS-level config) that pure Lambda or a black-box PaaS can't offer, Elastic Beanstalk is usually the intended answer — it sits between "fully managed, zero control" (Lambda) and "fully manual" (hand-built EC2 + ASG + ALB).
For the full deployment-policy breakdown and Beanstalk vs ECS/Fargate vs Lambda comparison, see 04 — Elastic Beanstalk. For CloudFormation/SAM/CDK intrinsic functions and the three-way tool comparison, see 03 — IaC. For the container-based alternative to this compute layer, see 01 — Containers.
Cognito (User Pools + optional Identity Pools) → API Gateway authorizer → Lambda/ECS → X-Ray → CloudWatch.
The client signs up/signs in via Cognito's hosted UI or an SDK; on success, the User Pool issues an ID token, an access token, and a refresh token (all JWTs). User Pools are chosen because they're a fully managed user directory — no self-built password storage, MFA, or social/enterprise federation (SAML/OIDC) to secure and maintain.
Added only when the client itself needs to call AWS services directly — e.g. a mobile app uploading straight to S3 without routing through the backend API. The User Pool's ID token is exchanged via the Identity Pool for temporary AWS credentials (STS) mapped to an IAM role. If all AWS access happens server-side behind the API, this stage is skipped entirely — a common exam distractor is including Identity Pools when the scenario never actually needs client-side AWS SDK calls.
Every request to a protected route must carry a valid access token (not the ID token) in the Authorization header. API Gateway validates the JWT's signature and expiry itself, before invoking any backend compute — unauthenticated/expired requests never reach Lambda or ECS, and application code never has to implement token validation.
The same reasoning as Architectures 1 and 2 applies here: Lambda for unpredictable, spiky, stateless request logic; ECS/Fargate behind a VPC Link for steady-state, longer-running, or resource-heavy business logic, or when integrating with an existing containerised service. The authenticated request now carries verified identity claims the backend can trust without re-validating them.
Tracing spans the full chain: API Gateway stage → authorizer invocation → Lambda/ECS → any downstream DynamoDB/RDS call, all correlated under one trace ID. With authentication now an extra hop in the request path, X-Ray is what distinguishes "the authorizer is slow" from "the business logic is slow" from "the database is slow" — three very different fixes.
Dashboards aggregate API Gateway 4XX/5XX rates, Lambda duration/error/throttle metrics, and custom application metrics. Alarms fire on elevated authorizer-failure rates (a leading indicator of credential-stuffing) or elevated latency. CloudWatch is the last stage because it turns every prior stage's logs and traces into actionable, threshold-based operational visibility.
The ID token proves identity to your own client app; the access token authorises calls to your API/resources. Sending an ID token where an access token is expected produces a confusing "authenticated but still unauthorized" failure — a favourite exam distractor.
Any identity/role claim must be validated server-side by the authorizer, not read unverified from a client-controlled field. A design that trusts a header the client sets itself, instead of the token API Gateway already validated, is a security anti-pattern regardless of how convenient it looks.
For User Pools vs Identity Pools and JWT structure in full depth, see 07 — Cognito. For authorizer types (Cognito, IAM/SigV4, Lambda) on API Gateway, see 06 — API Gateway. For end-to-end trace correlation and annotations vs metadata, see 05 — X-Ray.
Every major topic across files 01–07, prioritised, plus the recommended order to study them in and why.
| Topic | Priority | Why |
|---|---|---|
| Task role vs task execution role | MUST | The single most common ECS IAM trap on the exam |
| ECS clusters, services, tasks, task definitions | MUST | Foundational vocabulary every scenario question assumes you know |
awsvpc networking + ALB target type ip | MUST | Fargate-specific networking requirement, tested directly and indirectly |
| ECS vs EKS vs Fargate launch type comparisons | MUST | Classic "which is the least-ops / most appropriate" comparison set |
| ECR repositories & lifecycle policies | SHOULD | Regularly appears as a supporting detail, rarely the crux of a question |
| Service Auto Scaling (target tracking) | SHOULD | Elasticity pattern reused across container and Beanstalk scenarios |
| Blue/green ECS deployment via CodeDeploy | SHOULD | Overlaps heavily with the CI/CD guide — study once, applies twice |
| Service discovery via Cloud Map | NICE | Appears occasionally in service-to-service scenarios, rarely central |
| EKS deep internals (control plane, node groups) | NICE | DVA-C02 tests EKS mostly at the comparison level, not implementation depth |
| Topic | Priority | Why |
|---|---|---|
| Source → Build → Deploy stage roles & the build/deploy tool split | MUST | CodeBuild-vs-CodeDeploy confusion is a recurring wrong-answer trap |
| buildspec.yml phases (install/pre_build/build/post_build) | MUST | Directly tested and underpins every container/serverless build stage |
| appspec.yml, lifecycle hooks, deployment groups | MUST | Core CodeDeploy mechanics for both ECS and Lambda targets |
| In-place vs blue/green deployment (and by target type) | MUST | The "zero downtime / instant rollback" keyword maps straight to this |
| Artifacts passed via S3 between stages | SHOULD | Useful mental model, occasionally tested directly |
| EventBridge-triggered pipelines vs polling | SHOULD | Tests understanding of how CodePipeline detects a new commit |
| CodeCommit / CodeStar deprecation awareness | SHOULD | Legacy questions may reference them; know they're not current best practice |
| IAM service roles per pipeline stage | NICE | Conceptually important but rarely the crux of a scored question |
| Topic | Priority | Why |
|---|---|---|
| CloudFormation stacks, change sets, intrinsic functions | MUST | Foundational — SAM and CDK both ultimately produce this |
| CloudFormation vs SAM vs CDK — when to use each | MUST | One of the most frequently tested three-way comparisons on DVA-C02 |
SAM CLI workflow (sam build/deploy/local invoke) | MUST | Heavily tested for serverless deployment scenarios specifically |
| Stack update/rollback behaviour | SHOULD | Important operationally, moderate exam frequency |
CDK constructs (L1/L2/L3), cdk synth/deploy | SHOULD | Conceptual understanding tested more than syntax |
| Drift detection | SHOULD | Recognisable keyword-to-feature mapping question |
| Nested stacks | NICE | Occasionally tested, low standalone weight |
| Topic | Priority | Why |
|---|---|---|
| Deployment policies (rolling / rolling+batch / immutable / blue-green) | MUST | Directly tested risk/speed tradeoff scenarios |
| Beanstalk vs ECS/Fargate vs Lambda comparison | MUST | The core "least ops but still need infra control" decision |
| .ebextensions and environment configuration | SHOULD | Customisation escape hatch, moderately tested |
| Enhanced health reporting / health dashboard | NICE | Operational detail, low standalone exam weight |
| Topic | Priority | Why |
|---|---|---|
| Annotations vs metadata (indexed/searchable vs not) | MUST | One of the most reliable single-fact traps on the exam |
| Traces, segments, subsegments, service maps | MUST | Core vocabulary for "identify the slow downstream service" questions |
| Sampling rules (fixed rate + reservoir) | SHOULD | Cost/coverage tradeoff, moderately tested |
| SDK/daemon instrumentation, Lambda auto-instrumentation | SHOULD | Practical setup knowledge, tested at a conceptual level |
| Topic | Priority | Why |
|---|---|---|
| REST API vs HTTP API | MUST | Major, extremely frequently tested cost/feature comparison |
| Lambda proxy vs non-proxy integration | MUST | Classic trap around mapping templates and full-request pass-through |
| Authorizers — Cognito, IAM/SigV4, Lambda (token vs request) | MUST | Core to Architectures 2 and 5; tested from multiple angles |
| CORS configuration and the backend-header trap | MUST | A very commonly misdiagnosed real-world and exam scenario |
| Usage plans, API keys, throttling (burst vs rate) | SHOULD | REST-API-specific, tested when partner/tiered access appears |
| Stages and deployments | SHOULD | Operational vocabulary, regularly assumed knowledge |
| Request/response mapping templates (VTL) | NICE | Low frequency now that HTTP API + proxy integration dominate scenarios |
| Topic | Priority | Why |
|---|---|---|
| User Pools vs Identity Pools | MUST | The defining Cognito comparison — authentication vs authorization |
| JWT structure — ID token vs access token vs refresh token | MUST | Frequent trap, directly relevant to Architectures 2 and 5 |
| API Gateway integration (User Pool authorizer) | MUST | The mechanical link between Cognito and every secured API scenario |
| Federated identity providers (social, SAML/OIDC) | SHOULD | Regularly appears as a feature-recognition question |
| Lambda triggers (pre-signup, post-confirmation, etc.) | NICE | Customisation hooks, low standalone exam weight |
This order follows real dependencies: containers pull in IaC and CI/CD concepts before those guides formally introduce them, so seeing containers first gives the later guides something concrete to attach to.
Containers (01) — establishes ECS/ECR/Fargate vocabulary that CI/CD, IaC, and this file all assume.
CI/CD (02) — builds directly on the container target from step 1; introduces the build/deploy service split.
IaC (03) — now that you've deployed something manually and via a pipeline, IaC's value (repeatable, reviewable) is concrete rather than abstract.
Elastic Beanstalk (04) — a natural contrast point immediately after IaC + containers: same outcome, different operational model.
API Gateway (06) — shifts focus from compute/deploy to the request-facing layer; needed before Cognito makes full sense.
Cognito (07) — layers directly onto API Gateway's authorizer concept just learned in step 5.
X-Ray (05) — studied last among the service guides because it threads through every architecture already covered — most useful once you have real request chains in mind to trace.
Cross-Service Architectures (this file, 08) — synthesises all seven guides into the five patterns the exam actually tests.
Hands-On Lab (09) — closes the loop by building a real version of these architectures in the console, cementing what was so far conceptual.
DVA-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.