AppSync with DynamoDB (GraphQL) - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this GraphQL query with DynamoDB resolver?

Given a DynamoDB table Books with items having id and title, and this GraphQL query:

{ getBook(id: "123") { id title } }

Assuming the item with id = "123" exists with title "Learn GraphQL", what is the expected output?

A {"data": {"getBook": null}}

B {"data": {"getBook": {"id": "123", "title": "Learn GraphQL"}}}

C {"errors": [{"message": "Item not found"}]}

D {"data": {"getBook": {"id": "123"}}}

💡 Hint

Think about what the resolver returns when the item exists.

The resolver fetches the item by id and returns all requested fields. Since the item exists, the data is returned with id and title.

📝 Syntax

intermediate

Which VTL snippet correctly retrieves an item by id in DynamoDB resolver?

In an AppSync DynamoDB resolver, you want to get an item by id from the Books table. Which Velocity Template Language (VTL) snippet is syntactically correct?

A

{
  "version": "2018-05-29",
  "operation": "GetItem",
  "key": {
    "id": { "S": "$ctx.args.id" }
  }
}

B

{
  "version": "2018-05-29",
  "operation": "GetItem",
  "key": {
    "id": "$ctx.args.id"
  }
}

C

{
  "version": "2018-05-29",
  "operation": "Query",
  "key": {
    "id": { "S": "$ctx.args.id" }
  }
}

D

{
  "version": "2018-05-29",
  "operation": "GetItem",
  "key": {
    "id": { "N": "$ctx.args.id" }
  }
}

💡 Hint

Remember DynamoDB expects attribute types in the key.

Option A correctly specifies the operation as GetItem and the key with attribute type S (string) for id. Option A misses the attribute type, C uses Query instead of GetItem, and A uses N (number) which is incorrect if id is a string.

❓ optimization

advanced

How to optimize a DynamoDB resolver for filtering items by a non-key attribute?

You want to filter Books by author attribute, which is not a key. Which approach optimizes performance in AppSync with DynamoDB?

A Use BatchGetItem operation with <code>author</code> values.

B Use a Scan operation with a filter expression on <code>author</code>.

C Create a Global Secondary Index (GSI) on <code>author</code> and use Query operation on the GSI.

D Use GetItem operation with <code>author</code> as key.

💡 Hint

Think about how DynamoDB handles queries on non-key attributes efficiently.

Scan reads the entire table and is slow. GetItem requires key attributes, which author is not. BatchGetItem requires keys too. Creating a GSI on author allows efficient Query operations.

🔧 Debug

advanced

Why does this AppSync resolver return null for an existing item?

Given this VTL request mapping template:

{
  "version": "2018-05-29",
  "operation": "GetItem",
  "key": {
    "id": { "S": "$ctx.args.bookId" }
  }
}

And the GraphQL query:

{ getBook(id: "abc123") { id title } }

The item with id = "abc123" exists, but the response is null. What is the likely cause?

A The request mapping uses <code>$ctx.args.bookId</code> but the query argument is <code>id</code>.

B The DynamoDB table does not have an item with <code>id = "abc123"</code>.

C The response mapping template is missing.

D The operation should be Query instead of GetItem.

💡 Hint

Check if the argument names match between query and resolver.

The resolver expects bookId argument but the query provides id. This mismatch causes the key to be empty, so DynamoDB returns no item, resulting in null.

🧠 Conceptual

expert

What is a key benefit of using DynamoDB with AppSync for real-time GraphQL APIs?

Choose the best explanation of why DynamoDB is a good choice for AppSync real-time GraphQL APIs.

A DynamoDB stores data in XML format which AppSync parses efficiently for real-time APIs.

B DynamoDB supports flexible relational joins which AppSync uses for real-time updates.

C DynamoDB automatically generates GraphQL schemas for AppSync without configuration.

D DynamoDB's single-digit millisecond latency and seamless integration with AppSync enable fast real-time data access.

💡 Hint

Think about performance and integration benefits.

DynamoDB offers very low latency and integrates natively with AppSync, making it ideal for real-time GraphQL APIs. It does not support relational joins or automatic schema generation, nor does it store XML data.

Practice

1. What is the main benefit of using AWS AppSync with DynamoDB in an application?

easy

A. It allows apps to request only the data they need using GraphQL.

B. It automatically creates SQL tables for data storage.

C. It requires manual scaling of the database.

D. It replaces the need for any backend code.

Solution

1. Step 1: Understand AppSync's role

   AppSync uses GraphQL to let apps ask for exactly the data they need, avoiding over-fetching.

2. Step 2: Understand DynamoDB's role

   DynamoDB stores data quickly and scales automatically, but does not create SQL tables or replace backend code entirely.

3. Final Answer:

   It allows apps to request only the data they need using GraphQL. -> Option A

4. Quick Check:

   AppSync + GraphQL = precise data requests [OK]

Hint: Remember: AppSync uses GraphQL for precise data fetching [OK]

Common Mistakes:

• Thinking DynamoDB creates SQL tables
• Believing manual scaling is needed
• Assuming AppSync removes all backend code

2. Which of the following is the correct way to define a DynamoDB data source in an AWS AppSync GraphQL schema?

easy

A. type Query { getItem(id: ID!): Item @aws_dynamodb(tableName: MyTable) }

B. type Query { getItem(id: ID!): Item @aws_lambda(functionName: "MyFunction") }

C. type Query { getItem(id: ID!): Item @aws_dynamodb(tableName: "MyTable", region: "us-east-1") }

D. type Query { getItem(id: ID!): Item @aws_s3(bucketName: "MyBucket") }

Solution

1. Step 1: Identify the correct directive for DynamoDB

   The @aws_dynamodb directive is used to link a DynamoDB table as a data source in AppSync.

2. Step 2: Check syntax correctness

   type Query { getItem(id: ID!): Item @aws_dynamodb(tableName: "MyTable", region: "us-east-1") } correctly includes the tableName and region parameters, which are valid for specifying the DynamoDB data source.

3. Final Answer:

   type Query { getItem(id: ID!): Item @aws_dynamodb(tableName: "MyTable", region: "us-east-1") } -> Option C

4. Quick Check:

   @aws_dynamodb with tableName and region is correct syntax [OK]

Hint: Look for @aws_dynamodb with tableName and region parameters [OK]

Common Mistakes:

• Using @aws_lambda instead of @aws_dynamodb for DynamoDB
• Forgetting quotes around tableName value
• Using @aws_s3 which is unrelated to DynamoDB

3. Given this GraphQL query in AppSync linked to DynamoDB:

query GetBook { getBook(id: "123") { id title author } }

And the DynamoDB table has an item:

{"id": "123", "title": "Learn DynamoDB", "author": "Jane"}

What will be the output of this query?

medium

A. {"data": {"getBook": {"id": "123", "title": "Learn DynamoDB", "author": "Jane"}}}

B. {"data": {"getBook": null}}

C. {"errors": [{"message": "Item not found"}]}

D. {"data": {"getBook": {"id": "123", "title": null, "author": null}}}

Solution

1. Step 1: Understand the query and data

   The query requests the item with id "123" and fields id, title, author. The table has this exact item.

2. Step 2: Predict the query result

   Since the item exists, the query returns all requested fields with their values.

3. Final Answer:

   {"data": {"getBook": {"id": "123", "title": "Learn DynamoDB", "author": "Jane"}}} -> Option A

4. Quick Check:

   Existing item returns full data [OK]

Hint: If item exists, query returns requested fields with values [OK]

Common Mistakes:

• Assuming null fields if item exists
• Expecting errors when item is present
• Confusing null result with missing item

4. You wrote this resolver mapping template for a DynamoDB getItem operation in AppSync:

{
  "version": "2017-02-28",
  "operation": "GetItem",
  "key": {
    "id": $util.dynamodb.toDynamoDBJson($ctx.args.id)
  }
}

But your query always returns null. What is the likely mistake?

medium

A. The $util.dynamodb.toDynamoDBJson function is not needed.

B. The operation should be "Query" instead of "GetItem".

C. The version "2017-02-28" is outdated and causes errors.

D. The key attribute name "id" does not match the DynamoDB table's primary key name.

Solution

1. Step 1: Check key attribute name

   The key attribute name in the resolver must exactly match the DynamoDB table's primary key name.

2. Step 2: Understand why null is returned

   If the key name is wrong, DynamoDB cannot find the item, so it returns null.

3. Final Answer:

   The key attribute name "id" does not match the DynamoDB table's primary key name. -> Option D

4. Quick Check:

   Key name mismatch causes null result [OK]

Hint: Match key names exactly between resolver and table [OK]

Common Mistakes:

• Using wrong operation type for getItem
• Ignoring key name case sensitivity
• Removing $util.dynamodb.toDynamoDBJson causing syntax errors

5. You want to create a real-time chat app using AppSync and DynamoDB. Which approach best ensures that clients receive new messages instantly without polling?

hard

A. Have clients poll DynamoDB every few seconds for new messages.

B. Use AppSync subscriptions linked to DynamoDB streams to push updates to clients.

C. Use a Lambda function to write messages to DynamoDB and notify clients via email.

D. Store messages in DynamoDB and refresh the UI only when the app restarts.

Solution

1. Step 1: Understand real-time updates in AppSync

   AppSync supports GraphQL subscriptions that can push data to clients when data changes.

2. Step 2: Connect DynamoDB streams to subscriptions

   DynamoDB streams capture table changes and can trigger AppSync subscriptions to notify clients instantly.

3. Step 3: Evaluate other options

   Polling wastes resources, email notifications are slow and unrelated, and UI refresh on restart is not real-time.

4. Final Answer:

   Use AppSync subscriptions linked to DynamoDB streams to push updates to clients. -> Option B

5. Quick Check:

   Subscriptions + DynamoDB streams = instant updates [OK]

Hint: Use subscriptions with DynamoDB streams for real-time data [OK]

Common Mistakes:

• Relying on polling instead of subscriptions
• Using email for real-time notifications
• Ignoring DynamoDB streams integration