A company has implemented a data ingestion pipeline for sales transactions from its ecommerce website. The company uses Amazon Data Firehose to ingest data into Amazon OpenSearch Service. The buffer…

Question

Options

• AUse zero buffering in the Firehose stream. Tune the batch size that is used in the
• BReplace the Firehose stream with an AWS DataSync task. Configure the task with enhanced fan-
• CIncrease the buffer interval of the Firehose stream from 60 seconds to 120 seconds.
• DReplace the Firehose stream with an Amazon Simple Queue Service (Amazon SQS) queue.

• A
  77% (36)
• B
  4% (2)
• C
  13% (6)
• D
  6% (3)

Explanation

Option A is correct because Amazon Data Firehose's zero buffering feature (buffer size of 0 MB) bypasses the standard buffering window entirely and streams records to OpenSearch as fast as they arrive - enabling sub-second latency rather than waiting 60 seconds before flushing. Tuning the batch size complements this by controlling how many records are sent per OpenSearch bulk request, preventing overload while maintaining speed.

Option B is wrong because AWS DataSync is designed for bulk file/object transfers between storage systems (S3, NFS, EFS), not for low-latency streaming of transactional event data - it has no concept of real-time ingestion.

Option C is the opposite of what's needed: increasing the buffer interval to 120 seconds would make latency worse, not better.

Option D is wrong because SQS is a message queue, not a direct streaming ingestion path to OpenSearch - you'd still need a consumer to poll and write to OpenSearch, adding complexity without solving the sub-second latency requirement. Firehose has a native OpenSearch destination; SQS does not.

Memory tip: Think of Firehose buffering as a "waiting room" - zero buffering means no waiting room, records go straight in. Any answer that adds time (bigger buffer) or wrong tool (DataSync for file sync, SQS for decoupling) fails the sub-second test.

No community discussion yet for this question.