Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 320 discussion

A: is the solution for the company's requirements. Publishing data to Amazon Kinesis Data Streams can support ingestion rates as high as 1 MB/s and provide real-time data processing. Kinesis Data Analytics can query the ingested data in real-time with low latency, and the solution can scale as needed to accommodate increases in ingestion rates or querying needs. This solution also ensures minimal data loss in the event of an EC2 instance reboot since Kinesis Data Streams has a persistent data store for up to 7 days by default.

The fact they specifically mention "near real-time" twice tells me the correct answer is KDF. On top of which its easier to setup and maintain. KDS is really only needed if you need real-time. Also using redshift will mean permanent data retention. The data in A could be lost after a year. Redshift queries are slow but you're still querying near real-time data

Also A because "The company’s data science team wants to query ingested data in near-real time" and kinesis data analytics is doing that. With option B we query the tada once is in the data lake.

Option a for me. I will assume that the EC2 instance is responsible for placing the data into the correct database. Therefore, we just need to wait for the instance to reboot. Since we can store the data in Kinesis Data Streams for up to 7 days, we are covered in that regard. For option B, we are forced to use Amazon Redshift, and the problem statement does not mention anything related to that. I would choose option A because it does not affect the original requirements, and it helps us avoid in-flight data loss as requested.

near-real time --> Kinesis Data Firehose And retention day of Kinesis Data Streams cannot be longer than 365 days

A: focus on performing complex data processing without in-flight data lost, not mention data persistence B: focus on data persist for later analysis

Instance store & ElasiCache are all temporary storages, which cannot address data loss. That rules out C & D. B: Kinesis Data Firehose is optimized for batch processing rather than real-time querying. It can indeed deliver data to S3 or Redshift, but there's a good chance the delay between ingestion and query availability cannot meet the "near-real-time" requirement.

https://aws.amazon.com/pm/kinesis/?gclid=CjwKCAjwvIWzBhAlEiwAHHWgvRQuJmBubZDnO2GasDWwc2iBapfVD6GBeIgj2JV6qkldm-K_CmMzmxoCdCwQAvD_BwE&trk=ee1218b7-7c10-4762-97df-274836a44566&sc_channel=ps&ef_id=CjwKCAjwvIWzBhAlEiwAHHWgvRQuJmBubZDnO2GasDWwc2iBapfVD6GBeIgj2JV6qkldm-K_CmMzmxoCdCwQAvD_BwE:G:s&s_kwcid=AL!4422!3!651510255264!p!!g!!kinesis%20stream!19836376690!149589222920

Option A is actually correct. The question ask for minimal data loss and that query of data should be near real time, not the ingestion. Kinesis data analytics is near real time. Recent changes to Redshift actually make B correct as well, but A is also correct.

Comparison to other options: B. Kinesis Data Firehose with Redshift: While Redshift is scalable, it doesn't offer real-time querying capabilities. Data needs to be loaded into Redshift from Firehose, introducing latency. C. EC2 instance store with Kinesis Data Firehose and S3: Storing data in an EC2 instance store is not persistent and data will be lost during reboots. EBS volumes are more appropriate for persistent storage, but the architecture becomes more complex. D. EBS volume with ElastiCache and Redis: While ElastiCache offers fast in-memory storage, it's not designed for high-volume data ingestion like 1 MB/s. It might struggle with scalability and persistence.

I don't understand why people are giving wrong information in the QUESTION its clearly mentioned near Real Time Kinesis Data Streams is for Real time Where are Kinesis Datafirehose is for Near real time there for answer is B only

Read the question: near real-time querying of data.... it is more about real-time data query once the data is ingested, It does not mention how long time the data needs to be stored. A is better option. B introduces delay of data buffer before it can be queried in redshift

A is not correct because Kinesis can only store data up to 1 year. The solution need to support querying ALL data instead of "recent" data.

A: is the solution for the company's requirements. Publishing data to Amazon Kinesis Data Streams can support ingestion rates as high as 1 MB/s and provide real-time data processing. Kinesis Data Analytics can query the ingested data in real-time with low latency, and the solution can scale as needed to accommodate increases in ingestion rates or querying needs. This solution also ensures minimal data loss in the event of an EC2 instance reboot since Kinesis Data Streams has a persistent data store for up to 7 days by default.

Publish data to Amazon Kinesis Data Streams, Use Kinesis Data Analytics to query the data

• Provide near-real-time data ingestion into Kinesis Data Streams with the ability to handle the 1 MB/s ingestion rate. Data would be stored redundantly across shards. • Enable near-real-time querying of the data using Kinesis Data Analytics. SQL queries can be run directly against the Kinesis data stream. • Minimize data loss since data is replicated across shards. If an EC2 instance is rebooted, the data stream is still accessible. • Scale seamlessly to handle varying ingestion and query rates.

Answer is A as it will provide a more streamlined solution. Using B (Firehose + Redshift) will involve sending the data to an S3 bucket first and then copying the data to Redshift which will take more time. https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html