Storing and Retrieving Bicycle Location Data via REST API
A bicycle sharing company is developing a multi-tier architecture to track the location of its bicycles during peak operating hours. The company wants to use these data points in its existing analytics platform. A solutions architect must determine the most viable multi-tier option to support this architecture. The data points must be accessible from the REST API. Which action meets these requirements for storing and retrieving location data?
Community Insight
The question tests whether you can identify a multi-tier pattern that provides REST API access while also handling data storage and processing — the trap is assuming Kinesis Data Analytics can be directly wired to API Gateway, when it actually requires Kinesis Data Streams as an input source.
This SAA-C03 scenario requires a multi-tier serverless architecture where bicycle location data is stored and exposed through a REST API for consumption by an existing analytics platform. Amazon API Gateway combined with AWS Lambda satisfies both the REST API access requirement and the data processing/storage need, making option B the correct choice.
Many learners select D (API Gateway with Kinesis Data Analytics) because Kinesis seems more suited to high-volume telemetry, but Kinesis Data Analytics cannot accept API Gateway as a direct input — it requires Kinesis Data Streams or Firehose as the ingestion layer, which is not mentioned in the option.
Community Discussion (173 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option B (Amazon API Gateway with AWS Lambda) is the correct answer because it directly satisfies all stated requirements in a single, cohesive multi-tier pattern. API Gateway provides the REST API endpoint that the question explicitly requires for data access. AWS Lambda sits behind API Gateway, processes incoming location data points, and persists them to a data store (e.g., Amazon DynamoDB) or forwards them into the company's existing analytics platform. This forms a classic serverless multi-tier architecture: API Gateway (presentation tier) → Lambda (application tier) → DynamoDB/existing analytics (data tier). The scalability of both API Gateway and Lambda handles peak-hour traffic bursts without provisioning infrastructure.
Why the Other Options Are Wrong
Option D (API Gateway with Kinesis Data Analytics) fails because Kinesis Data Analytics requires a Kinesis Data Streams or Kinesis Data Firehose as its input source — it cannot be directly connected to API Gateway. The option does not include a Kinesis Data Streams component, so the ingestion path from API Gateway is architecturally incomplete. As rvca231 correctly pointed out, "Kinesis Data Analytics requires a Kinesis Data Streams or Kinesis Data Firehose as input streams, so you cannot directly connect it to API Gateway."
Option A (Athena with S3) provides storage and query capabilities but has no REST API component; the question explicitly states "The data points must be accessible from the REST API," which Athena+S3 alone cannot satisfy. Option C (QuickSight with Redshift) is a BI/dashboard and data warehousing combination designed for analytical querying, not for real-time REST API access to location data, and similarly lacks an API Gateway component.
Community Comment Notes
The community is split between B and D. ArielSchivo correctly argues that since "the company wants to use these data points in its existing analytics platform," there is no need to introduce Kinesis, leaving B as the answer. Six_Fingered_Jose pushes back on B, questioning "how are you going to store data with just lambda?" — but Lambda can write to DynamoDB or any downstream store, so this objection doesn't hold. Tsige argues Lambda "isn't storing the data themselves" and that the setup "doesn't efficiently handle continuous real-time data streaming," favoring D — however, the question doesn't require Kinesis Streams ingestion, and KDA can't be directly wired to API Gateway. rvca231 makes the decisive technical argument that Kinesis Data Analytics cannot be connected directly to API Gateway, which rules out D entirely.
Official Reference
Exam Strategy
When a question explicitly states that data must be accessible from a REST API, immediately look for Amazon API Gateway among the options — its presence or absence often eliminates half the choices. Then verify that the second service in the pairing can both process and persist data in a way that completes the multi-tier pattern.
Frequently Asked Questions
Why can't Amazon API Gateway connect directly to Amazon Kinesis Data Analytics?
Kinesis Data Analytics requires a Kinesis Data Streams or Kinesis Data Firehose as its input source. API Gateway cannot serve as a direct input to Kinesis Data Analytics, so the ingestion path in option D is architecturally incomplete.
How does AWS Lambda store data if it is a compute service?
Lambda does not store data itself, but it can write incoming location data to Amazon DynamoDB, Amazon S3, or directly into the company's existing analytics platform as part of its execution logic behind API Gateway.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →