Commonly Confused Services on DVA-C02

Deciding signal

User Pools handle user authentication: sign-up, sign-in, MFA, password policies, and JWT token issuance. They answer "who is this user?" Identity Pools (Federated Identities) exchange tokens — from User Pools, social providers, SAML IdPs, or guest access — for temporary AWS credentials via STS. They answer "what AWS resources can this user access?" When the scenario describes login flows, user directories, or OAuth/OIDC token issuance, User Pools. When the scenario describes giving authenticated or unauthenticated users direct access to AWS services like S3 or DynamoDB, Identity Pools.

Deciding signal

CodeBuild compiles source code, runs tests, and produces build artifacts — it is the CI build stage. CodeDeploy takes a deployable artifact and deploys it to EC2 instances, Lambda functions, or ECS services using configurable deployment strategies (blue/green, rolling, canary). CodePipeline is the orchestrator: it connects source, build, and deploy stages into an automated pipeline. A question asking "which service deploys code to EC2 with a rolling strategy" points to CodeDeploy. A question asking "which service automates the end-to-end release process from source to production" points to CodePipeline.

Deciding signal

REST APIs in API Gateway support the full feature set: request/response transformation, API keys, usage plans, per-stage caching, WAF integration, and edge-optimized endpoints with CloudFront. HTTP APIs are a simpler, lower-latency, and lower-cost option — up to 70% cheaper — that supports JWT authorizers, Lambda proxy, and private integrations, but not the full feature set. On DVA-C02, the exam tests whether candidates can identify that HTTP APIs are the correct answer when the scenario describes a simple proxy to Lambda or a backend HTTP endpoint without a requirement for features unique to REST APIs.

Deciding signal

An LSI must be created at table creation time and shares the same partition key as the base table — it only adds an alternate sort key. LSIs are limited to 10 GB per partition key value. A GSI can have a completely different partition key and sort key from the base table and can be created or deleted at any time. GSIs provide eventual consistency by default; LSIs can provide strongly consistent reads. When the scenario requires querying on a different partition key entirely, only a GSI works. When the scenario uses the same partition key but needs to sort or filter on a different attribute, an LSI is a valid option — but candidates often confuse which constraint applies.

Deciding signal

ElastiCache (Redis or Memcached) is a general-purpose in-memory cache that your application must explicitly check before querying the database. It works with any backend: RDS, DynamoDB, external APIs. DAX is a write-through cache designed specifically for DynamoDB that is API-compatible — your application points at DAX instead of DynamoDB and DAX handles cache misses transparently without code changes to your read path. When the scenario involves DynamoDB and the requirement is read latency reduction with minimal code change, DAX. When the scenario involves caching across multiple data sources or requires pub/sub and session features, ElastiCache.

Deciding signal

CloudWatch collects metrics (CPU, invocation count, error rate), ingests logs from services and applications, triggers alarms, and feeds dashboards. It is the right answer when the scenario involves thresholds, alerts, or log aggregation. X-Ray traces requests as they pass through distributed systems — it shows which service called which, how long each segment took, and where errors occurred across Lambda, API Gateway, EC2, and other services. X-Ray is specifically the right answer when the scenario describes debugging latency across multiple services, identifying which microservice is causing errors, or visualizing the request flow through a distributed application.

Deciding signal

DynamoDB Streams captures item-level changes (INSERT, MODIFY, REMOVE) on a DynamoDB table and makes them available as an ordered stream. Retention is 24 hours. It is tightly coupled to DynamoDB and is the right answer when the scenario involves reacting to DynamoDB table changes for replication, audit, or downstream processing. Kinesis Data Streams is a general-purpose streaming platform for any high-volume real-time data: application events, IoT telemetry, clickstreams. It supports configurable retention (1–365 days), multiple consumers, and replay. When the trigger is specifically a DynamoDB table write, use DynamoDB Streams. When the data originates from applications or external sources, use Kinesis Data Streams.

Deciding signal

Parameter Store stores configuration values and secrets in a hierarchical key-value store. Standard parameters are free; Advanced parameters add policies and larger sizes at a cost. It does not natively rotate values. Secrets Manager is designed for credentials that need automatic rotation: RDS passwords, API keys, OAuth tokens. It natively integrates with RDS, Redshift, and DocumentDB for rotation, and supports custom rotation Lambda functions for other services. When the scenario describes storing a database password and rotating it automatically on a schedule, Secrets Manager. When the scenario describes storing application configuration, feature flags, or non-rotating secrets at low cost, Parameter Store.

Deciding signal

Short polling queries a subset of SQS servers and returns immediately — even if no messages are available. This can result in empty responses and higher API call costs. Long polling waits up to 20 seconds for messages to arrive before returning an empty response, reducing empty responses and API costs. On DVA-C02, long polling is the answer when the scenario describes reducing the number of empty SQS API calls, reducing cost, or avoiding CPU-spinning consumer loops. The ReceiveMessageWaitTimeSeconds attribute on the queue controls this.

Deciding signal

Lambda Layers are ZIP archives that are extracted into /opt in the Lambda execution environment before the function code runs. They are for sharing libraries, dependencies, or custom runtimes across multiple functions — reducing package size and enabling dependency reuse. Lambda Extensions are processes that run alongside the Lambda function in the same execution environment, integrated into the Lambda lifecycle (init, invoke, shutdown). They are for integrating monitoring agents, secrets managers, or configuration providers that need to interact with the Lambda runtime lifecycle. When the scenario involves sharing code or libraries between functions, Layers. When the scenario involves running a sidecar process that hooks into Lambda initialization or shutdown events, Extensions.