DVA-C02 Study Notes in Questions: Development with AWS Services
Development with AWS Services is a recurring theme in the AWS Developer – Associate (DVA-C02) exam. It makes up about 32% of the exam. The 5 questions below come with a full explanation of why each option is right or wrong.
AWS Developer – Associate (DVA-C02) · Development with AWS Services · 5 questions with answers and explanations
🧭 How Development with AWS Services is tested
Most items put a developer in front of a concrete coding or integration task (expose a function over HTTPS, write an item, read a date range, reject a bad request) and ask which feature or API call does it. Several options name real features of the same service, so the deciding factor is what each feature is actually for: routing traffic, managing versions, metering clients or shaping data.
Watch for these while you work
• For DynamoDB reads, start from what the key schema already gives you. A known partition key plus a range on the sort key calls for a different operation than reading the whole table.
• Know how the two kinds of DynamoDB secondary index differ: when each one can be created, which keys it may use, and what read consistency it offers.
• When an API must refuse bad input, look for an API Gateway feature that inspects the request itself. Features that split, route or meter traffic never check what a request contains.
📊 Set profile
Exam: DVA-C02 · 65 questions · 130 minutes · passing score 720 · the largest of 4 domains
This set: 4 applied, 1 advanced · 4 scenario, 1 troubleshooting · 1 with more than one answer
Topics: AWS Lambda, Amazon DynamoDB, Amazon API Gateway
Question 1 of 5
A developer wants a simple HTTPS endpoint for a Lambda function without configuring API Gateway. Which feature fits?
Show answer
✅ Answer: D
Difficulty: applied · Topic: AWS Lambda
Lambda function URLs
A function URL is a dedicated HTTPS endpoint built into Lambda itself. You enable it on a function (or on an alias) and Lambda gives you an address like https://<url-id>.lambda-url.<region>.on.aws.
• Auth type is either AWS_IAM (callers sign requests with SigV4) or NONE (public, you check auth in code).
• CORS settings can be configured on the URL, and responses can be streamed.
• There are no routes, stages, usage plans or request validation: every request goes to the one function.
When to pick it over API Gateway
Example: a webhook receiver that only needs "POST here, run my code". A function URL is one setting and costs nothing extra beyond the Lambda invocation. When you need many routes, API keys, throttling per client, caching or request transformation, API Gateway is still the better fit.
Why each option works or fails
• ✗ A. Lambda alias: an alias is just a named pointer to a function version (for example prod pointing at version 7). It does not expose anything over HTTPS by itself, although a function URL can be attached to an alias.
• ✗ B. Lambda destination: destinations send the result of an asynchronous invocation to SQS, SNS, EventBridge or another function (and failed events also to S3). They handle output routing, not incoming HTTP requests.
• ✗ C. Lambda layer ARN: a layer is a zip archive of libraries or runtime files shared across functions. Its ARN identifies packaged code, not a network endpoint anyone can call.
• ✓ D. Lambda function URL (correct): it gives the function its own HTTPS endpoint directly from Lambda, with optional IAM auth and CORS, and nothing to configure in API Gateway.
🎯 Key idea: For "one simple HTTPS endpoint for one function", use a function URL; aliases, layers and destinations manage versions, code and results, not inbound traffic.
Question 2 of 5
A Lambda function using the low-level DynamoDB API attempts to write an item and receives a validation error because a numeric application value was passed as a plain JSON number rather than being wrapped correctly for DynamoDB's attribute format. What is the correct way to represent a numeric attribute using the DynamoDB low-level API JSON format?
Show answer
✅ Answer: C
Difficulty: applied · Topic: Amazon DynamoDB
DynamoDB attribute value format
In the low-level API (and in raw JSON such as CLI input files) every value is an object with one key, the type descriptor, and the value:
• S string: {"S": "hello"}
• N number: {"N": "42"}, the number written as a string
• B binary (base64), BOOL boolean, NULL
• M map, L list, and the sets SS, NS, BS
Numbers are passed as strings so that DynamoDB can store up to 38 digits of precision without the rounding that a JSON floating-point number would cause. DynamoDB still treats them as numbers: they sort numerically and work in arithmetic update expressions.
Example: "quantity": {"N": "3"} then UpdateExpression: "SET quantity = quantity + :one" with ":one": {"N": "1"}.
Why each option works or fails
• ✗ A. Bare JSON number: the low-level API requires a type descriptor around every value; a plain 42 is not a valid AttributeValue and causes a validation error.
• ✗ B. S descriptor: {"S": "42"} is accepted, but it stores a string, so the value sorts as text and cannot be used in numeric expressions.
• ✓ C. The N descriptor with a string (correct): {"N": "42"} marks the attribute as a number and passes the value as a string, which is the required low-level representation.
• ✗ D. Number key: Number is not one of DynamoDB's type descriptors, and the value must be a string even with the correct N descriptor.
🎯 Key idea: Low-level DynamoDB numbers are {"N": "value"}: a type descriptor plus the number as a string.
Question 3 of 5
Which TWO statements about DynamoDB secondary indexes are correct? (Select TWO)
Show answer
✅ Answer: A, E
Difficulty: applied · Topic: Amazon DynamoDB
Two kinds of secondary index in DynamoDB
A secondary index lets you query a table by attributes other than its primary key. DynamoDB offers two kinds, and they differ in keys, timing and consistency.
• A local secondary index (LSI) keeps the table's partition key and adds a different sort key. It lives in the same partitions as the base table, so it can serve strongly consistent reads. You can define LSIs only in CreateTable; they cannot be added or removed later, and a table allows at most five.
• A global secondary index (GSI) can use a completely different partition key and optional sort key. It is stored separately and updated asynchronously from the table, so reads from it are always eventually consistent. GSIs can be added or deleted at any time with UpdateTable.
Example
An Orders table keyed on CustomerId + OrderDate can have an LSI on CustomerId + Total (same partition key, created with the table) and a GSI on Status + OrderDate (new partition key, added later).
Why each option works or fails
• ✓ A. GSIs are eventually consistent only (correct): a GSI is replicated asynchronously from the base table, so a Query on it with ConsistentRead=true is rejected.
• ✗ B. Strong reads on every GSI: no GSI supports strongly consistent reads; only the base table and its LSIs do.
• ✗ C. GSI shares the sort key: a GSI can choose any partition key and sort key (or none), which is exactly what makes it "global".
• ✗ D. LSI with a different partition key: an LSI must reuse the table's partition key and only varies the sort key; a different partition key requires a GSI.
• ✓ E. LSIs are defined at creation (correct): LSIs must be declared when the table is created and cannot be added to an existing table.
🎯 Key idea: LSI = same partition key, created with the table, strong reads possible; GSI = any keys, add anytime, eventually consistent reads only.
Question 4 of 5
An API Gateway REST API should reject requests with missing required parameters before invoking the backend. Which feature fits?
Show answer
✅ Answer: A
Difficulty: applied · Topic: Amazon API Gateway
Request validation in API Gateway REST APIs
A REST API method can have a request validator attached. It runs before the integration is called and can check:
• Parameters: required query string parameters and headers are present.
• Body: the JSON body matches a model, which is a JSON Schema you define (required fields, types, patterns).
If validation fails, API Gateway returns 400 Bad Request itself, and the backend is never invoked.
Why do it at the API layer
Example: POST /orders requires the header X-Customer-Id and a body with productId and quantity. A validator rejects malformed calls up front, so your Lambda function or backend is not billed or loaded by requests it would reject anyway, and its code has less boilerplate checking.
Validators come in three flavors: body only, parameters only, or both.
Why each option works or fails
• ✓ A. Request validators with models (correct): they check required parameters and the request body against a JSON Schema model and reject bad requests with a 400 before the backend is invoked.
• ✗ B. Stage variables: stage variables are name-value pairs per stage (for example which Lambda alias or backend URL prod uses). They configure where requests go, not whether requests are valid.
• ✗ C. Canary release settings: a canary sends a percentage of stage traffic to a new deployment to test it. It splits traffic; it never inspects or rejects individual requests.
• ✗ D. Usage plans with API keys: usage plans apply throttling and quotas per API key. They limit how often a client calls, not whether a request contains the required parameters.
🎯 Key idea: To reject malformed requests before the backend runs, attach a request validator (with a model for the body); stage variables, canaries and usage plans route or meter traffic.
Question 5 of 5
A developer must retrieve all orders for a customer between two dates. The table has partition key CustomerId and sort key OrderDate. Which operation fits?
Show answer
✅ Answer: B
Difficulty: advanced · Topic: Amazon DynamoDB
Query vs Scan vs GetItem
In a table with a composite key, all items with the same partition key are stored together and sorted by the sort key. That makes range lookups efficient.
• Query requires an equality condition on the partition key and can add one condition on the sort key: =, <, >, BETWEEN or begins_with. It reads only the matching items.
• Scan reads every item in the table and applies filters afterward.
• GetItem returns exactly one item and needs the full primary key.
Example: KeyConditionExpression = "CustomerId = :c AND OrderDate BETWEEN :from AND :to" with :c = "C-42", :from = "2026-01-01", :to = "2026-03-31" returns only that customer's orders for Q1. ISO 8601 date strings sort correctly as text.
Why each option works or fails
• ✗ A. BatchWriteItem: this operation puts or deletes up to 25 items per call. It cannot read data and does not support condition expressions.
• ✓ B. Query with a key condition and BETWEEN (correct): it goes straight to the customer's partition and reads just the sort key range between the two dates, so it consumes capacity only for the orders returned.
• ✗ C. Scan with a filter: a Scan reads the entire table and charges for all of it; the filter only removes non-matching items after they are read, so it is slow and costly on a large table.
• ✗ D. GetItem with only CustomerId: GetItem needs both the partition key and the sort key for this table and returns a single item, so it cannot fetch a date range.
🎯 Key idea: When the partition key is known and you need a range of sort key values, use Query with a key condition, not Scan or GetItem.
🔗 Related practice sets
• All DVA-C02 practice sets
• Every exam on this blog
📚 More DVA-C02 practice
More DVA-C02 questions: https://hyunhp.github.io/cert-bank/#exam=DVA-C02
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=DVA-C02
These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.
Original practice questions written for this blog, not exam dumps.
Comments
Post a Comment