I believe AE makes the most sense

yeah AE makes sense, only E is working with S3 here and questions wants them to be in S3

C and D = too much overhead B = incorrect because Athena is used for one time queries. That leaves A and E

A is a given due to Athena and QuickSight option. Between C and E, the AWS Lake Formation is a more managed solution so it should have less operational overhead that writing Custom AWS Lambda. AE should be preferred over AC.

The reasons are: AWS Lake Formation and Glue provide automated data lake creation with minimal coding. Glue crawlers identify sources and ETL jobs load to S3. Athena allows ad-hoc queries directly on S3 data with no infrastructure to manage. QuickSight provides easy cloud BI for dashboards. Options C and D require significant custom coding for ETL and queries. Redshift and OpenSearch would require additional setup and management overhead.

It combines data from database and stream data, so data lake needs to be used. And it wants to do one time query, so Athena is better.

@Golcha once the data comes from different sources then you use GLUE

Less Overhead with option AC .No need to manage

No specific use case for GLUE

The Apache Parquet format is a performance-oriented, column-based data format designed for storage and retrieval. It is generally faster for reads than writes because of its columnar storage layout and a pre-computed schema that is written with the data into the files. AWS Glue’s Parquet writer offers fast write performance and flexibility to handle evolving datasets. You can use AWS Glue to read Parquet files from Amazon S3 and from streaming sources as well as write Parquet files to Amazon S3. When using AWS Glue to build a data lake foundation, it automatically crawls your Amazon S3 data, identifies data formats, and then suggests schemas for use with other AWS analytic services[1][2][3][4].

ANSWER - AE:Amazon Athena is the best choice for running one-time queries on streaming data. Although Amazon Kinesis Data Analytics provides an easy and familiar standard SQL language to analyze streaming data in real-time, it is designed for continuous queries rather than one-time queries[1]. On the other hand, Amazon Athena is a serverless interactive query service that allows querying data in Amazon S3 using SQL. It is optimized for ad-hoc querying and is ideal for running one-time queries on streaming data[2].AWS Lake Formation uses as a central place to have all your data for analytics purposes (E). Athena integrate perfect with S3 and can makes queries (A).

AWS Lake Formation uses as a central place to have all your data for analytics purposes (E). Athena integrate perfect with S3 and can makes queries (A).

Can anyone please explain me why B cannot be an answer?

can anyone help me in below question 36. A company has a Java application that uses Amazon Simple Queue Service (Amazon SOS) to parse messages. The application cannot parse messages that are large on 256KB size. The company wants to implement a solution to give the application the ability to parse messages as large as 50 MB. Which solution will meet these requirements with the FEWEST changes to the code? a) Use the Amazon SOS Extended Client Library for Java to host messages that are larger than 256 KB in Amazon S3. b) Use Amazon EventBridge to post large messages from the application instead of Aaron SOS c) Change the limit in Amazon SQS to handle messages that are larger than 256 KB d) Store messages that are larger than 256 KB in Amazon Elastic File System (Amazon EFS) Configure Amazon SQS to reference this location in the messages.

I believe DE makes the most sense

stored in s3 -> data lake -> athena (process the SQL parquet format)-> quicksight visualize

While Amazon Athena is a fully managed service that makes it easy to analyze data stored in Amazon S3 using SQL, it is primarily designed for running ad-hoc queries on data stored in Amazon S3. It may not be the best choice for running one-time queries on streaming data, as it is not designed to process data in real-time. Additionally, using Amazon Athena for one-time queries on streaming data could potentially lead to higher operational overhead, as you would need to set up and maintain the necessary infrastructure to stream the data into Amazon S3, and then query the data using Athena. Using Amazon Kinesis Data Analytics, as mentioned in option B, would be a better choice for running one-time queries on streaming data, as it is specifically designed to process data in real-time and can automatically scale to match the incoming data rate.