Redshift Streaming Ingestion with Materialized Views

Answer Correct answer: C — Create an external schema in Amazon Redshift to map the data from Kinesis Data Streams to an Amazon Redshift object. Create a materialized view to read data from the stream. Set the materialized view to auto refresh.

A company wants to implement real-time analytics capabilities. The company wants to use Amazon Kinesis Data Streams and Amazon Redshift to ingest and process streaming data at the rate of several gigabytes per second. The company wants to derive near real-time insights by using existing business intelligence (BI) and analytics tools. Which solution will meet these requirements with the LEAST operational overhead?

  1. Use Kinesis Data Streams to stage data in Amazon S3. Use the COPY command to load data from Amazon S3 directly into Amazon Redshift to make the data immediately available for real-time analysis.
  2. Access the data from Kinesis Data Streams by using SQL queries. Create materialized views directly on top of the stream. Refresh the materialized views regularly to query the most recent stream data.
  3. Create an external schema in Amazon Redshift to map the data from Kinesis Data Streams to an Amazon Redshift object. Create a materialized view to read data from the stream. Set the materialized view to auto refresh. Correct Answer
  4. Connect Kinesis Data Streams to Amazon Kinesis Data Firehose. Use Kinesis Data Firehose to stage the data in Amazon S3. Use the COPY command to load the data from Amazon S3 to a table in Amazon Redshift.

Community Votes

C
59%
D
41%

59% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The exam tests knowledge of Redshift's ability to ingest directly from Kinesis via external schemas and auto-refreshing materialized views, contrasting it with the higher latency and complexity of S3 staging.

This question evaluates the optimal architecture for near real-time analytics using Amazon Redshift and Kinesis Data Streams, focusing on minimizing operational overhead through native streaming ingestion features.

Many candidates choose Option D (Firehose to S3 to Redshift) because they associate 'least operational overhead' with fully managed batch services like Firehose, missing that direct streaming ingestion is more efficient for near real-time needs.

Community Discussion (29 comments)

blackgamer 👍 8 Selected: C
The answer is C. It can provide near real-time insight analysis. Refer the article from AWS - https://aws.amazon.com/blogs/big-data/real-time-analytics-with-amazon-redshift-streaming-ingestion/
helpaws 👍 7 Selected: C
Key word here is near real-time. If it's involve S3 and COPY, it's not gonna be near real-time
melligeri 👍 1 Selected: C
https://aws.amazon.com/blogs/big-data/real-time-analytics-with-amazon-redshift-streaming-ingestion/#:~:text=Before%20the%20launch,the%20data%20stream.
Rpathak4 👍 2 Selected: D
✅ Use Kinesis Data Firehose to load data into Redshift via S3 for the simplest and most scalable solution. ✅ Firehose automatically batches, transforms, and loads data with no manual intervention required. ✅ Achieves near real-time analytics with minimal operational effort.
MephiboshethGumani 👍 1 Selected: D
Creating an external schema and using materialized views directly on top of Kinesis Data Streams is also not an ideal choice because this approach can add complexity and doesn't leverage fully managed solutions like Kinesis Data Firehose. The manual management of data refresh rates adds operational overhead.
Eltanany 👍 1 Selected: C
Refer to the article from AWS - https://aws.amazon.com/blogs/big-data/real-time-analytics-with-amazon-redshift-streaming-ingestion/
jesusmoh 👍 1 Selected: D
option D provides a streamlined, efficient, and low-overhead approach to achieving real-time analytics with the specified technologies.
plutonash 👍 2 Selected: D
A: Kinesis Data Streams to stage data in Amazon S3. not really easy, B: sql directly to Kinesis Data Streams : functionality not exist C : external schema from redshift to Kinesis Data Streams : functionality not exist D : near real-time = Kinesis Data Firehose
subbie 👍 1 Selected: C
https://aws.amazon.com/blogs/big-data/real-time-analytics-with-amazon-redshift-streaming-ingestion/
subbie 👍 1 Selected: B
https://aws.amazon.com/blogs/big-data/real-time-analytics-with-amazon-redshift-streaming-ingestion/
haby 👍 1 Selected: A
A for me C - Redshift does not natively support direct mapping to Kinesis Data Streams. Some extra configs are needed. D - There will be a 60s latency when using Firehose, so it's "Near" real time not real time.
HagarTheHorrible 👍 1 Selected: D
Redshift does not natively support direct mapping to Kinesis Data Streams. Materialized views cannot directly query streaming data from Kinesis.
altonh 👍 1 Selected: C
See https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-streaming-ingestion-getting-started.html
Asen_Cat 👍 2 Selected: D
D could be the most standard way to handle this case. How to use C to implement it is questionable for me.
heavenlypearl 👍 1 Selected: C
Amazon Redshift can automatically refresh materialized views with up-to-date data from its base tables when materialized views are created with or altered to have the autorefresh option. Amazon Redshift autorefreshes materialized views as soon as possible after base tables changes. https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-refresh.html
royalrum 👍 1
Firehose is Near-Real time, you can set your buffer size and stream to either Redshift or S3 directly. Since Redshift is not in the option, use s3...
Shatheesh 👍 1 Selected: D
Kinesis Data Streams , option D using Kinesis Data Firehose is a fully managed service that automatically handles the ingestion of data
markill123 👍 4 Selected: D
Here’s why D is the best choice: Kinesis Data Firehose is a fully managed service that automatically handles the ingestion of data from Kinesis Data Streams and stages it in S3, which significantly reduces operational overhead compared to managing custom data ingestion pipelines. S3 as a staging area: Using Amazon S3 as a staging location allows for flexible data management, high durability, and direct loading into Redshift without needing to manage complex buffering or data handling processes. COPY command: The COPY command in Amazon Redshift is highly optimized for loading large datasets efficiently, making it a common and effective method to load bulk data from S3 into Redshift for near real-time analysis. Firehose to Redshift: Firehose can automatically buffer, batch, and transform data before loading it into Redshift, reducing manual intervention and ensuring data is readily available for real-time analytics.
shammous 👍 2 Selected: D
Option C has an issue: Redshift does not natively support direct querying or mapping of Kinesis Data Streams. D is the only correct option.
V0811 👍 2 Selected: D
Option D
bakarys 👍 1 Selected: A
Option A (using Kinesis Data Streams to stage data in Amazon S3 and loading it directly into Amazon Redshift) is the most straightforward and efficient approach. It minimizes operational overhead and ensures immediate availability of data for analysis. Options B and C introduce additional complexity and may not provide the same level of efficiency
d8945a1 👍 2 Selected: C
MVs in Redshift with auto refresh is the best option for near real time.
Christina666 👍 3 Selected: C
Using materialized views with auto-refresh directly on a Redshift external schema of Kinesis Data Stream offers the most streamlined and efficient approach for near real-time insights using existing BI tools.
fceb2c1 👍 5 Selected: C
https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-streaming-ingestion-getting-started.html C is correct. (KDS -> Redshift) D is wrong as it has more operational overhead (KDS -> KDF -> S3 -> Redshift)
certplan 👍 2
1. Amazon Kinesis Data Firehose: It's designed to reliably load streaming data into data lakes and data stores with minimal configuration and management overhead. It handles tasks like buffering, scaling, and delivering data to destinations like Amazon S3 and Amazon Redshift automatically. 2. Amazon S3 as a staging area: Storing data in Amazon S3 provides a scalable and durable solution for data storage without needing to manage infrastructure. It also allows for easy integration with other AWS services and existing BI and analytics tools. 3. Amazon Redshift: While Redshift requires some setup and management, loading data from Amazon S3 using the COPY command is a straightforward process. Once data is loaded into Redshift, existing BI and analytics tools can query the data directly, enabling near real-time insights. 4. Minimal operational overhead: This solution minimizes operational overhead because much of the management tasks, such as scaling, buffering, and delivery of data, are handled by Amazon Kinesis Data Firehose. Additionally, using Amazon S3 as a staging area simplifies data storage and integration with other services.
certplan 👍 1
By considering the characteristics and capabilities of each AWS service and approach, along with insights from AWS documentation, it becomes evident that option D offers the most streamlined and operationally efficient solution for the scenario described. This idea/concept is also straight out of the Amazon Solutions Architect course material.
certplan 👍 1
Point: "Which solution will meet these requirements with the LEAST operational overhead?" C. - This approach involves creating an external schema in Amazon Redshift to map data from Kinesis Data Streams, which adds complexity compared to directly loading data from Amazon S3 using Amazon Kinesis Data Firehose. - While materialized views with auto-refresh can provide near real-time insights, managing them and ensuring proper synchronization with the streaming data source may require more operational effort. - AWS documentation for Amazon Redshift primarily focuses on traditional data loading methods and querying, with limited guidance on integrating with real-time data sources like Kinesis Data Streams.
GiorgioGss 👍 3 Selected: D
I think D. It could be C but because of "LEAST operational overhead" I will go with D.
Aesthet 👍 1
Both ChatGPT and I are thinking D is correct (100%)

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Option C is correct because Amazon Redshift supports Streaming Ingestion from Kinesis Data Streams. This feature allows you to create an external schema pointing to a Kinesis stream and define a materialized view that automatically refreshes at configurable intervals (as low as every few seconds). This provides true near-real-time insights without the need for custom code or intermediate staging layers, directly satisfying the 'least operational overhead' requirement for real-time analytics.

Why the Other Options Are Wrong

Option A and Option D both rely on Amazon S3 as a staging area. While S3 is durable and cost-effective, data landing in S3 typically involves eventual consistency and requires explicit COPY commands or Lambda triggers to load into Redshift, introducing latency that violates the 'near real-time' requirement. Option B suggests querying Kinesis directly with SQL; however, Redshift cannot execute standard SQL queries against a live Kinesis stream without the specific External Schema/Materialized View mechanism described in C. Additionally, 'refreshing regularly' implies manual or scheduled logic, whereas auto-refresh is a managed feature.

Community Comment Notes

The community was split between C and D. Users supporting C cited AWS documentation on 'real-time analytics with Amazon Redshift streaming ingestion,' emphasizing that S3-based approaches are not truly near real-time. Users supporting D argued that Firehose is more 'operational' friendly due to its fully managed nature. However, experts note that while Firehose is managed, the architectural pattern of S3 staging adds latency and complexity compared to Redshift's native streaming integration, making C the technically superior answer for the specific 'near real-time' constraint.

Official Reference

Exam Strategy

When a question specifies 'near real-time' and 'least operational overhead' involving Redshift and streaming data, look for Redshift's native streaming ingestion capabilities (External Schema + Materialized View) before defaulting to S3/Firehose batch patterns. Batch patterns are rarely 'real-time.'

Frequently Asked Questions

Why is Option D not the least operational overhead?

While Firehose is managed, moving data to S3 first introduces latency and requires additional steps (COPY command) to make it available in Redshift, failing the 'near real-time' requirement.

Can Redshift query Kinesis streams directly?

Yes, via Streaming Ingestion. You create an External Schema for the Kinesis stream and then query it using a Materialized View with auto-refresh enabled.

More DEA-C01 FAQ →

Related Analysis

Practice All DEA-C01 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DEA-C01 Practice Test →

← Back to DEA-C01 Study Guide