An online retail company with millions of users around the globe wants to improve its ecommerce analytics capabilities. Currently, clickstream data is uploaded directly to Amazon S3 as compressed…

Question

Options

• AUse Amazon Kinesis Data Firehose to upload compressed and batched clickstream records to
• BUpload clickstream records to Amazon S3 as compressed files.
• CUse Amazon Elasticsearch Service deployed on Amazon EC2 to aggregate, filter, and process
• DUse Kibana to aggregate, filter, and visualize the data stored in Amazon Elasticsearch Service.
• EUpload clickstream records from Amazon S3 to Amazon Kinesis Data Streams and use a Kinesis

• A
  56% (24)
• B
  12% (5)
• C
  26% (11)
• E
  7% (3)

Explanation

The goal is to make clickstream data available to editors and marketers in minutes (near-real-time) rather than via batch uploads. (A) Replacing direct S3 compressed file uploads with Amazon Kinesis Data Firehose streams clickstream records continuously, enabling data to flow into a backend (like Amazon Elasticsearch Service) within seconds to minutes instead of waiting for batch uploads. (D) Kibana is the native visualization layer for Amazon Elasticsearch Service, providing real-time dashboards, filtering, and aggregation - exactly what editors and marketers need. Together, the architecture becomes: clickstream events → Kinesis Firehose → Amazon Elasticsearch Service → Kibana dashboards. Option B keeps the slow batch-upload pattern. Option C uses Elasticsearch on EC2 (self-managed, more overhead) instead of the managed Amazon Elasticsearch Service. Option E introduces unnecessary complexity by going through S3 first.

No community discussion yet for this question.