Data APIs and source connections: DEA-C01 study notes and practice questions
What to know about Data APIs and source connections for the DEA-C01 exam, from the Data Ingestion and Transformation domain (34% of the exam guide), then 1 free question to test it. Part of the DEA-C01 study guide.
These questions ask how to accept data from applications or partners, and how to reach databases and services from pipeline code.
Accepting data through an API
API Gateway with an AWS service integration can call Kinesis PutRecord (or SQS, or Firehose) directly, with no Lambda in between. Add authorization (IAM, Cognito or Lambda authorizers), throttling and usage plans with API keys.
API Gateway + Lambda when each request needs custom validation or enrichment.
AWS AppSync for GraphQL APIs.
Amazon AppFlow for pulling from SaaS APIs on a schedule.
Reaching data from code
Need
Approach
Query Redshift from Lambda or apps without managing connections or drivers
Redshift Data API (asynchronous, IAM authentication)
Query RDS/Aurora without connections
RDS Data API (Aurora)
Run Athena queries from code
Athena API (StartQueryExecution, results in S3)
Connect Glue or EMR to a database
JDBC connection with network access and credentials from Secrets Manager
BI tools to Redshift or Athena
JDBC/ODBC drivers
Programming concepts the exam expects
Idempotency: re-running a step shouldn’t duplicate data (use upserts, unique keys or write-then-rename).
Pagination and rate limits when calling APIs; retries with backoff.
A weather-data company collects readings from 40 partner organizations, which push JSON records over HTTPS. The records must land in an existing Amazon Kinesis Data Streams stream that several consumers already read.
Partners must call one HTTPS endpoint and must not hold AWS credentials. The company does not want to run servers or write code to receive the requests, and each partner must be throttled to its own request rate.
Which solution meets these requirements?
Choose one answer.
AA. Create an IAM user for each partner with kinesis:PutRecord on the stream, and have the partners call the Kinesis API directly with access keys.
BB. Run a small web service on Amazon EC2 instances behind an Application Load Balancer that writes each request to the stream.
CC. Create a Lambda function URL whose function writes each request to the stream, and set reserved concurrency to cap the total request rate.
DD. Create an API Gateway REST API with an AWS service integration that calls Kinesis PutRecord through an IAM role, and a usage plan per partner.
Show the answer and explanation
Answer: D
A. Wrong: Each partner would hold long-term AWS credentials, which the company has ruled out. Kinesis also has no per-caller rate limit, so one partner could still use most of the stream's write capacity.
B. Wrong: This works, but the company would run and patch servers and write the receiving code. Per-partner throttling would also have to be built into the service.
D. Right: Correct. An AWS service integration lets API Gateway call PutRecord itself with an execution role, so there is no code or server and partners never see AWS credentials. Usage plans with an API key per partner apply throttling and quotas per key; pair them with an authorizer, because API keys are not meant for authentication. Learn more: Create a REST API as an Amazon Kinesis proxy (opens in a new tab)
Explanation
API Gateway can act as a managed front door for a data stream: an AWS service integration calls Kinesis PutRecord directly through an IAM role, with no function or server in between. Usage plans and API keys throttle each partner separately. Direct IAM access, a web service on EC2 and a Lambda function URL each add credentials, servers, code or a single shared limit.
Want more on Data APIs and source connections? The 5 full-length practice sets have 5 more Data APIs and source connections questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →