Staff need typo-tolerant full-text search across free-text complaint narratives, not just exact DynamoDB key lookups. Which service fits that access pattern?
Select an answer to reveal the explanation.
Short Explanation
Key-value lookup finds an ID; hunting phrases with typos needs a search engine. Index the narratives in OpenSearch and search there.
Full Explanation
Typo-tolerant full-text search across free-text complaint narratives is a search-engine problem, not a DynamoDB primary-key lookup problem. Amazon OpenSearch Service, indexed from the complaint store via DynamoDB Streams, ingestion pipelines, or batch sync, supports full-text, fuzzy, and relevance-ranked queries that clerks need when citizens misspell street names, parcel IDs, or issue types in narrative fields.
A DynamoDB Query with begins_with on the entire narrative string as the sort key only helps for deliberate prefix matches on a designed key—it does not deliver fuzzy search across free-form text. Amazon Athena CTAS into a new DynamoDB table per search term is an analytics workaround, not an interactive search API for staff triage. Amazon Macie runs sensitive-data discovery jobs; it is not a municipal complaint search service.
Exam caveat: OpenSearch indexes are eventually consistent with the source system unless you design near-real-time indexing SLAs; keep DynamoDB (or the system of record) authoritative for the complaint entity and treat search hits as a discovery path to the ID. Operational check: index a narrative containing a deliberate near-miss spelling, run a fuzzy query that finds it, open the complaint by ID from the source store, and confirm the authoritative record matches what clerks expect.