Exams / AIP-C01 / Study guide / Event-driven integration with enterprise systems (EventBridge, API Gateway, Lambda)
Event-driven integration with enterprise systems (EventBridge, API Gateway, Lambda): AIP-C01 study notes and practice questions
What to know about Event-driven integration with enterprise systems (EventBridge, API Gateway, Lambda) for the AIP-C01 exam, from the Implementation and Integration domain (26% of the exam guide), then 1 free question to test it. Part of the AIP-C01 study guide.
AIP-C01 asks how to connect a generative AI feature to systems the company already runs. The best answer usually leaves the existing system unchanged and adds an event or integration layer around it.
Event-driven triggers
Amazon EventBridge routes events from AWS services and SaaS partners to targets such as Lambda, Step Functions or SQS, based on rule patterns. Use it when the trigger is a business event (“case closed”, “order shipped”) and more than one consumer may react. EventBridge retries failed deliveries and can send undeliverable events to a dead-letter queue.
When a SaaS application pushes webhooks, put API Gateway or a Lambda function URL in front. The function validates the signature, acknowledges quickly, and publishes the event to EventBridge or SQS. The model call happens afterward, so the SaaS provider never waits for it.
Decoupling with queues
Place Amazon SQS between the legacy application and the model. The producer writes a message and returns at once. A Lambda function or container consumer calls the model at its own pace, and bursts wait in the queue instead of failing. Standard queues handle high throughput but can deliver duplicates and out-of-order messages. FIFO queues preserve order and deduplicate, at lower throughput.
Moving data for retrieval
For RAG, land data in Amazon S3 and let a knowledge base sync from there. Amazon AppFlow runs scheduled or event-triggered flows that copy data from SaaS applications such as Salesforce into S3 with field mapping, so you avoid building a custom connector. For an on-premises database, a managed transfer or scheduled extract writes changed records to S3, and an incremental sync updates the index.
Legacy facade
Legacy systems often expose SOAP, flat files or batch jobs. Put an API facade in front, using API Gateway with a Lambda integration, that translates requests and publishes a stable OpenAPI contract. The new feature calls the facade, so the legacy system needs no changes. Remember that the REST API integration timeout is 29 seconds by default, so long model calls need an asynchronous pattern.
How to choose
Scenario wording
Choose
“A CRM record changes and several systems should react”
EventBridge rule to Lambda or Step Functions
“A SaaS app sends webhooks”
API Gateway or function URL, then EventBridge or SQS
“Bursty producer, model is rate limited”
SQS between producer and model consumer
“Copy SaaS data into S3 without custom code”
Amazon AppFlow
“Old system must not change, new API needed”
API facade over the legacy system
“Failed events must not be lost”
Dead-letter queue on the rule or queue
Common traps
Changing the legacy application to call Bedrock directly, when an event or facade keeps the change outside it.
Synchronous API Gateway calls for long summaries, which hit the 29-second integration timeout. Raising the Lambda timeout does not help, because API Gateway still closes the request.
Polling a database table for new records, instead of using event rules or a queue.
Building a custom connector when AppFlow offers a managed one for the SaaS application.
No dead-letter queue, so failed events disappear after retries.
A B2B software company keeps its customer accounts in a sales CRM. The CRM publishes events when an opportunity moves to the Negotiation stage, when a support case is closed and when a contract is renewed. Sales representatives need an AI-written account summary within one minute after an opportunity moves to Negotiation.
The CRM team should not need to know which summarization service consumes its events. Only the three event types above may start a summary, and a summary for one event must never be generated twice, even if the event is delivered more than once. The security team requires that the CRM publisher can only send events and cannot read or invoke anything else in the company's AWS account.
Which THREE actions meet these requirements? (Choose three.)
Choose three answers.
AA. Have the CRM call a summarization Lambda function through Amazon API Gateway for every record change, and filter out the events it does not need inside that function.
BB. Publish CRM events to a custom EventBridge event bus, with a rule whose pattern matches only the three event types and targets the summarization workflow.
CC. Run an EventBridge scheduled rule every hour that summarizes every account whose record changed during the past hour, so that summaries are generated in batches.
DD. Make the summarization step idempotent with a DynamoDB conditional write keyed on the CRM event ID, so that a redelivered event is skipped.
EE. Give the CRM integration role an IAM policy that allows only events:PutEvents on the custom event bus, with no other actions in the account.
FF. Set the summarization function's EventBridge target to match all events on the default event bus, and have the function ignore any event type that is not one of the three.
Show the answer and explanation
Answers: B, D, E
A. Wrong: The CRM would know about the summarizer and send every change, so it is tightly coupled and the filtering happens after each invocation. It breaks the decoupling rule and triggers the function for events that should never start a summary.
B. Right: The publisher sends to the bus without knowing the consumer, and the event pattern limits which events start a summary. Adding a new consumer later needs only a new rule on the same bus. Learn more: EventBridge rules (opens in a new tab)
C. Wrong: A rule that runs hourly delivers summaries long after the one-minute target, and it summarizes events that were never in scope. Batching is efficient, but it does not meet the timing requirement.
D. Right: Redelivered events carry the same event ID, so the conditional write rejects a second summary for that event. This prevents duplicate summaries even when EventBridge delivers an event more than once.
E. Right: The publisher can send events to the bus and nothing else, which meets the least-privilege requirement. The security team gets a clear boundary, and the summarizer's permissions stay separate from the publisher's.
F. Wrong: Matching every event starts the function for every change, even though only three types should trigger a summary. Checking types in code still incurs invocations and cost for each unwanted event.
Explanation
An EventBridge custom bus with a precise event pattern decouples the CRM from the summarizer and starts work only for the three event types. Idempotent handling by event ID prevents duplicate summaries, and an IAM policy limited to PutEvents keeps the publisher's access narrow. A direct API call, an hourly batch and an all-events rule each miss a stated requirement.
Want more on Event-driven integration with enterprise systems (EventBridge, API Gateway, Lambda)? The 5 full-length practice sets have 5 more Event-driven integration with enterprise systems (EventBridge, API Gateway, Lambda) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Event-driven integration with enterprise systems (EventBridge, API Gateway, Lambda)