Which Bedrock support design handles clarification and encrypted history?

AIP-C01 By islever Editorial Last updated

Implement application integration patterns and development tools. Implement data security and privacy controls.

Short answer

B Use Step Functions Standard with wait-for-callback, store encrypted conversation history in DynamoDB on-demand, and invoke Bedrock from the workflow.

Question

A company is developing a generative AI (GenAI)-powered customer support application that uses Amazon Bedrock foundation models (FMs). The application must maintain conversational context across multiple interactions with the same user. The application must run clarification workflows to handle ambiguous user queries. The company must store encrypted records of each user conversation to use for personalization. The application must be able to handle thousands of concurrent users while responding to each user quickly.
Which solution will meet these requirements?
  1. Use an AWS Step Functions Express workflow to orchestrate conversation flow. Invoke AWS Lambda functions to run clarification logic. Store conversation history in Amazon RDS and use session IDs as the primary key.
  2. Use an AWS Step Functions Standard workflow to orchestrate clarification workflows. Include Wait for a Callback patterns to manage the workflows. Store conversation history in Amazon DynamoDPurchase on-demand capacity and configure server-side encryption. Correct Answer
  3. Deploy the application by using an Amazon API Gateway REST API to route user requests to an AWS Lambda function to update and retrieve conversation context. Store conversation history in Amazon S3 and configure server-side encryption. Save each interaction as a separate JSON file.
  4. Use AWS Lambda functions to call Amazon Bedrock inference APIs. Use Amazon SQS queues to orchestrate clarification steps. Store conversation history in an Amazon ElastiCache (Redis OSS) cluster. Configure encryption at rest.

Key Takeaways

The exam tests matching durable clarification workflows to Step Functions Standard callbacks while using DynamoDB for encrypted conversation records; the trap is choosing Express workflows or S3/ElastiCache for durable history.

This question tests how to orchestrate a Bedrock customer support assistant that needs durable clarification callbacks, encrypted conversation storage, and high concurrency. The correct design uses Step Functions Standard workflows with wait-for-callback, DynamoDB on-demand, and server-side encryption.

Common mistake: A common mistake is selecting Step Functions Express because it scales for high concurrency, but Express workflows cannot use .waitForTaskToken callbacks required for clarification.

Expert Analysis

Why the Answer Is Correct

Option B best matches all requirements: Step Functions Standard workflows support durable wait-for-callback patterns for clarification, DynamoDB on-demand scales with variable concurrent traffic, and server-side encryption protects stored conversation records. Conversation history keyed by session can be retrieved and updated quickly for personalization, while the workflow can pause for an ambiguous query without losing state. Although Standard workflows are not the Express high-volume option, they provide the callback semantics that the clarification requirement demands, and DynamoDB on-demand absorbs the concurrent user load.

Why the Other Options Are Wrong

Option A uses Step Functions Express, which cannot implement.waitForTaskToken callback integrations, so it cannot pause durably for clarification. Option C stores each interaction as a separate S3 JSON file, which is not a low-latency, session-keyed conversation store and lacks a clarification orchestration mechanism. Option D uses SQS queues to orchestrate clarification steps, but SQS is not a durable callback pattern for waiting on a user response, and ElastiCache is an in-memory cache rather than the durable encrypted conversation record store needed for personalization.

Community Comment Notes

The thread is split: GiorgioGss and QuinnGT favor B, with QuinnGT emphasizing that "Standard workflows support durable callback patterns" for clarification. Kraftzman argues for A based on Express high concurrency, but nebulane counters that Express "can't wait for callbacks," which is the decisive limitation here. 67bdb19 prefers D, yet SQS and ElastiCache do not provide the durable, encrypted conversation history and callback orchestration described.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a question mentions waiting for a user or external callback, immediately rule out Express workflows and SQS-based orchestration; look for Standard workflows with waitForTaskToken. Then verify the history store is durable, encrypted, and keyed for session access—DynamoDB fits better than S3 or a cache.

Frequently Asked Questions

Why can't Step Functions Express workflows handle the clarification callback?

Express workflows do not support .waitForTaskToken callback integrations, so they cannot pause durably for an ambiguous query to be resolved.

Why is ElastiCache Redis not the best choice for encrypted conversation records?

ElastiCache is an in-memory cache with optional persistence, not the durable system of record needed for personalization; DynamoDB on-demand provides durable, encrypted storage.

More AIP-C01 FAQ →

Discussion 7 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 7

  1. GiorgioGss 👍 4 Answered B
    standard workflow fits the purpose
  2. Kraftzman 👍 2 Answered A
    . Express vs. Standard Workflows The requirement to handle thousands of concurrent users and respond quickly is the deciding factor between Step Functions types. Express Workflows: Designed for high-volume, short-duration (up to 5 minutes) events. They can handle over 100,000 events per second, making them ideal for a busy customer support API. Standard Workflows (Option B): These are intended for long-running, auditable processes (up to a year). They have much lower throughput limits and higher costs per execution, which would struggle with the "thousands of concurrent users" and "responding quickly" requirements.
  3. nebulane 👍 2
    actual answer is B since step function express can't wait for callbacks
  4. QuinnGT 👍 1 Answered B
    B: Step Functions Standard workflows support durable callback patterns for clarification that can wait for a user's next action. DynamoDB on-demand capacity scales with variable concurrent traffic, and server-side encryption protects stored conversation records. Express workflows do not support ".waitForTaskToken" callback integrations, so A cannot implement the described asynchronous clarification pattern in the same way.
  5. 67bdb19 👍 1 Answered D
    Well, [Option A] and [Option C] are definitely wrong. Between the other two, D is the better fit.
Show 2 more comments
  1. nebulane 👍 1 Answered A
    B isn't correct since Higher latency Not suited for real-time chat
  2. de1612d 👍 1 Answered B
    Gemini answer is B

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How Can AgentCore Query Cross-Account DynamoDB While Preserving User Identity?

S-grade

Which API Gateway setup streams Bedrock responses with least operational overhead?

S-grade

Resilient Retry and Streaming Strategies for Amazon Bedrock

S-grade

Bedrock Prompt Management & Guardrails Detection

S-grade

Practice All AIP-C01 Questions

Access 110 questions with complete answers and detailed explanations.

View Full AIP-C01 Practice Test →

← Back to AIP-C01 Study Guide