AWS DVA-C02 Questions Feel Ambiguous? Here’s How to Decide Between Correct-Seeming Answers

You’re reading a Lambda and SQS integration question, and three answers seem defensible. One describes asynchronous processing with visibility timeout, another mentions event source mappings, a third talks about batch size configuration. You stare at your screen for two minutes, unable to commit to an answer. This moment—where multiple answers feel simultaneously correct—is the #1 reason candidates plateau at 68-72% on the AWS Certified Developer Associate exam.

Direct Answer

The AWS Certified Developer Associate (DVA-C02) exam doesn’t actually present equally valid answers. What feels ambiguous is your application of AWS’s priority hierarchy for service design decisions. AWS exam questions reward answers that match the vendor’s architectural preference framework: least privilege (IAM), service-native solutions over custom code, and operational simplicity as a tiebreaker. When you see multiple correct-seeming answers, one aligns with this framework and the others represent incomplete or over-engineered approaches. Learning to identify which answer satisfies AWS’s decision logic—not just technical accuracy—eliminates ambiguity and closes your scoring gap.

Why This Happens to AWS Certified Developer Associate Candidates

This isn’t a knowledge gap. You understand Lambda cold starts, you know DynamoDB throughput modes, you can recite IAM policy evaluation logic. The problem is deeper: you’re evaluating answers against technical correctness alone, not against how AWS prioritizes between correct options.

Consider a typical scenario: you’re asked about securing API Gateway endpoints. Four answers are technically valid:

• Resource-based policies on the API
• IAM roles on the caller
• Lambda authorizers with custom logic
• API keys with usage plans

All four work. But AWS’s testing logic rewards the answer that combines least privilege (IAM roles), native AWS service controls (not custom Lambda authorizers unless authorization logic is complex), and minimal operational overhead. Candidates who miss this framework waste 60+ seconds per ambiguous question, accumulating decision paralysis across 65 questions.

The same pattern appears with storage decisions (S3 vs. EBS vs. DynamoDB), compute choices (Lambda vs. EC2), and messaging architecture (SQS vs. SNS vs. event source mappings). AWS has published preferences embedded in service design, documentation, and exam weighting. Candidates who don’t internalize this framework treat every question as a feature comparison exercise rather than a decision problem.

The Root Cause: Not Applying the Exam Vendor Decision Framework Correctly

AWS doesn’t test “which services exist” or “what features do they have.” AWS tests decision-making under service constraints. Every exam question implicitly asks: “Given these requirements, what’s the AWS-preferred way to solve this?”

This preference hierarchy exists because AWS designs services with opinionated assumptions:

Layer 1: Use managed services, not custom code. If Lambda can solve it natively, don’t build a custom solution. If DynamoDB’s built-in features cover the requirement, don’t add application-layer logic. This eliminates answers that reinvent wheels.

Layer 2: Apply least privilege by default. Between an IAM role-based solution and an open resource policy, AWS rewards the IAM answer. Between a public S3 bucket and a private bucket with CloudFront, the private bucket wins. This eliminates permissive answers.

Layer 3: Choose service-native features over configuration complexity. SQS visibility timeout is better than custom message tracking. DynamoDB TTL is better than Lambda jobs deleting old items. CloudFormation parameter types are better than validation in deployment scripts. This eliminates over-engineered answers.

Layer 4: Optimize for operational simplicity. If two answers deliver identical functionality, the one requiring fewer manual steps, fewer custom scripts, and less monitoring wins. Event source mappings (managed by Lambda) beat manual SQS polling (custom code).

Candidates who don’t consciously apply this framework second-guess themselves on every ambiguous question. They flip between answers because they’re weighing them against different criteria each time. The fix is mechanical: learn the framework, apply it systematically, and ambiguity collapses.

How the AWS Certified Developer Associate Exam Actually Tests This

The DVA-C02 exam measures whether you can make architectural decisions the way AWS’s solutions architects make them. This means:

1. Identifying which service is in scope. Does this question require knowledge of Lambda internals, or is it really about IAM? Does it depend on DynamoDB behavior, or API Gateway behavior?

2. Recognizing the decision context. Are we optimizing for cost, security, throughput, latency, or operational simplicity? The requirement statement always implies a priority.

3. Eliminating answers that violate AWS conventions. If an answer requires custom code when a managed service solves it, it’s wrong. If an answer grants excessive permissions when a least-privilege option exists, it’s wrong.

4. Choosing the simplest sufficient answer. Between “configure DynamoDB auto-scaling” and “write a Lambda function to monitor and adjust capacity,” the first wins. Between “add an authorizer Lambda” and “attach an IAM policy,” the second wins (unless authorization logic is genuinely complex).

The exam tests this across every core service: Lambda (execution role design, event source handling), DynamoDB (provisioning modes, streams, TTL), IAM (role structure, policy evaluation), SQS and SNS (async patterns, message routing), API Gateway (authorization, request transformation), CloudFormation (parameter design, outputs), S3 (bucket policies, encryption), EC2 (security groups, IAM instance roles), and VPC (routing, security, endpoint design).

Example scenario:

Your application needs to process images uploaded to an S3 bucket. Processing takes 2-5 seconds per image. The team currently uses a cron job running on an EC2 instance that polls S3 every minute for new objects. You’ve been asked to migrate this to a more scalable approach. Which solution should you recommend?

A) Configure S3 event notifications to trigger a Lambda function directly. Use Lambda to process the image and write results to DynamoDB. Attach an IAM execution role with permissions to S3 and DynamoDB only.

B) Configure S3 event notifications to publish to an SNS topic. Create an SQS queue subscribed to the SNS topic. Run a Lambda function that polls the SQS queue manually using a scheduled CloudWatch event every 30 seconds.

C) Set up an S3 event notification that triggers an EC2 instance to wake up and process the image. Use an IAM instance role to grant EC2 permissions to S3 and DynamoDB.

D) Create an API Gateway endpoint that accepts image uploads directly. Store images in S3 through the API. Use Lambda to process and write results to DynamoDB. Apply an IAM authorizer to the API endpoint.

Why the wrong answers seem right:

• Option B seems right because it uses SQS, which is correct for decoupling. But it reintroduces polling (the problem you’re solving) and adds SNS unnecessarily. The decision framework eliminates it.

• Option C seems right because EC2 is powerful and can run complex processing. But it violates the framework: use managed services (Lambda), not persistent instances for event-driven work.

• Option D seems right because it’s scalable and uses modern services. But it adds API Gateway and manual authorization when the requirement is internal image processing, not external API exposure. Over-engineered.

• Option A is correct because it uses the managed service (Lambda) triggered natively by S3, applies least-privilege IAM (execution role), and eliminates polling and unnecessary intermediaries. It matches the framework exactly.

Candidates stuck between B and A spend two minutes because they’re thinking “both use Lambda, so which is better?” But the framework makes it instant: direct S3 → Lambda is simpler than S3 → SNS → SQS → Lambda (Layer 4: operational simplicity).

How to Fix This Before Your Next Attempt

1. Map the AWS decision framework to each core service.

Create a one-page reference for Lambda, DynamoDB, IAM, SQS, SNS, API Gateway, CloudFormation, S3, EC2, and VPC. For each, write:

• “When do I use this service?” (the problem it solves)
• “What’s AWS’s preferred way to configure it?” (least privilege, managed features, native integration)
• “What’s an anti-pattern?” (custom code replacements, over-permissioning, manual orchestration)

For example, Lambda:

• Use for: Event-driven processing, async work, scheduled tasks, API endpoints
• **AWS preference