Amazon EventBridge Interview Questions and Answers

Learn Amazon EventBridge with production-ready interview questions covering event buses, rules, event patterns, targets, custom events, partner events, EventBridge Pipes, Scheduler, retries, dead-letter queues, archive and replay, schemas, security, monitoring, and best practices.

Previous: API Gateway QA | Parent: Serverless Learning Path | Next: Step Functions QA

Introduction

Amazon EventBridge is a managed serverless event-routing service used to build loosely coupled, event-driven applications.

It receives events from AWS services, custom applications, and supported software-as-a-service providers. It evaluates those events against configured rules and routes matching events to one or more targets.

EventBridge helps producers and consumers communicate without requiring the producer to know:

Which consumers exist
Where consumers are deployed
How consumers process events
How many consumers receive an event
Whether consumers are currently available

Amazon EventBridge provides several related capabilities:

Event buses
Rules and event patterns
Event targets
EventBridge Pipes
EventBridge Scheduler
API Destinations
Archive and replay
Schema Registry
Schema discovery
Global endpoints

It is commonly used for:

Microservice integration
Serverless applications
Business-event distribution
AWS resource automation
Security-event processing
Application integration
Cross-account event routing
Software-as-a-service integration
Scheduled jobs
Audit and compliance workflows

What Is Event-Driven Architecture?

Event-driven architecture is a design style in which systems communicate through events.

An event represents something that has already happened.

Examples include:

Customer registered
Order submitted
Payment completed
File uploaded
Account locked
EC2 instance stopped
Deployment failed
Fraud alert created

flowchart LR
    Producer[Event Producer] --> EventBus[Amazon EventBridge]
    EventBus --> ConsumerA[Consumer A]
    EventBus --> ConsumerB[Consumer B]
    EventBus --> ConsumerC[Consumer C]

The producer publishes the event without directly invoking every consumer.

What Is Amazon EventBridge?

Amazon EventBridge is a serverless event-routing platform that connects event producers to event consumers.

A typical flow is:

An application or AWS service generates an event.
The event is sent to an EventBridge event bus.
EventBridge compares the event with configured rules.
Matching rules route the event to their targets.
Targets process the event independently.
Delivery metrics and failures are monitored.

Basic EventBridge Architecture

flowchart LR
    AWS[AWS Services] --> Bus[EventBridge Event Bus]
    Custom[Custom Applications] --> Bus
    SaaS[SaaS Partners] --> Bus

    Bus --> RuleA[Rule A]
    Bus --> RuleB[Rule B]
    Bus --> RuleC[Rule C]

    RuleA --> Lambda[AWS Lambda]
    RuleB --> SQS[Amazon SQS]
    RuleB --> StepFunctions[AWS Step Functions]
    RuleC --> SNS[Amazon SNS]

Core EventBridge Components

Component	Description
Event	JSON document representing something that happened
Event source	System that produces the event
Event bus	Receives and routes events
Rule	Selects events and sends them to targets
Event pattern	JSON criteria used to match events
Target	AWS resource or endpoint receiving matched events
Pipe	Point-to-point connection between a source and target
Scheduler	Creates one-time or recurring scheduled invocations
Archive	Stores events received by an event bus
Replay	Sends archived events back to an event bus
Schema Registry	Stores and organizes event schemas
API Destination	Sends events to an external HTTPS endpoint

Event Structure

An EventBridge event is represented as JSON.

Example:

{
  "version": "0",
  "id": "a28d3f72-18ab-4ac8-b8dc-45c541c08e3a",
  "detail-type": "Order Created",
  "source": "com.codewithvenu.orders",
  "account": "123456789012",
  "time": "2026-07-18T14:30:00Z",
  "region": "us-east-1",
  "resources": [],
  "detail": {
    "orderId": "ORD-10025",
    "customerId": "CUS-7001",
    "amount": 249.99,
    "currency": "USD",
    "status": "CREATED"
  }
}

Standard Event Fields

Field	Description
`version`	Event format version
`id`	Unique event identifier
`detail-type`	Describes the type of event
`source`	Identifies the producer
`account`	AWS account associated with the event
`time`	Event creation time
`region`	AWS Region where the event originated
`resources`	Resources related to the event
`detail`	Application-specific event payload

The source, detail-type, and detail fields are commonly used in rule patterns.

Event Sources

EventBridge can receive events from several source categories.

AWS Service Events

AWS services can publish operational and resource events.

Examples include:

EC2 instance state changes
CodePipeline execution changes
ECS task state changes
GuardDuty findings
Systems Manager events
CloudFormation stack events

Custom Application Events

Applications can publish custom business events using the EventBridge API.

Examples include:

Order created
Payment authorized
Customer profile updated
Claim approved
Account limit exceeded

SaaS Partner Events

Supported software-as-a-service providers can send events through partner event sources.

Event Buses

An event bus receives events and routes them to rules.

EventBridge supports several event-bus types:

Default event bus
Custom event bus
Partner event bus

Default Event Bus

Every AWS account has a default event bus in each supported Region.

The default bus receives events from many AWS services.

flowchart LR
    EC2[Amazon EC2] --> DefaultBus[Default Event Bus]
    ECS[Amazon ECS] --> DefaultBus
    CloudFormation[CloudFormation] --> DefaultBus

    DefaultBus --> Rule[State Change Rule]
    Rule --> Lambda[Operations Lambda]

The default event bus is commonly used for infrastructure and AWS service events.

Custom Event Bus

A custom event bus is created for application or domain-specific events.

Examples include:

Order event bus
Payment event bus
Customer event bus
Security event bus
Enterprise integration event bus

flowchart LR
    OrderService[Order Service] --> OrderBus[Order Event Bus]
    PaymentService[Payment Service] --> OrderBus

    OrderBus --> InventoryRule[Inventory Rule]
    OrderBus --> NotificationRule[Notification Rule]
    OrderBus --> AuditRule[Audit Rule]

Custom buses improve organization, ownership, and policy isolation.

Partner Event Bus

A partner event bus receives events from a supported SaaS integration.

flowchart LR
    SaaS[SaaS Provider] --> PartnerSource[Partner Event Source]
    PartnerSource --> PartnerBus[Partner Event Bus]
    PartnerBus --> Rule[Event Rule]
    Rule --> Lambda[Integration Lambda]

This removes the need to continuously poll the SaaS provider for changes.

EventBridge Rules

A rule evaluates events arriving on an event bus.

A rule contains:

Event pattern
One or more targets
Target-specific configuration
Retry policy
Dead-letter queue configuration
Optional input transformation

flowchart LR
    Event[Incoming Event] --> Bus[Event Bus]
    Bus --> Pattern{Matches Rule Pattern?}
    Pattern -->|Yes| Target[Invoke Target]
    Pattern -->|No| Ignore[Ignore for This Rule]

Multiple rules can match the same event.

Event Pattern

An event pattern defines which events should match a rule.

Example:

{
  "source": ["com.codewithvenu.orders"],
  "detail-type": ["Order Created"],
  "detail": {
    "status": ["CREATED"],
    "currency": ["USD"]
  }
}

This pattern matches events where:

The source is com.codewithvenu.orders.
The detail type is Order Created.
The order status is CREATED.
The currency is USD.

Event Pattern Matching

EventBridge supports matching based on:

Exact values
Multiple allowed values
Prefixes
Suffixes
Numeric comparisons
Existence checks
Anything-but conditions
IP address ranges
Wildcard-style patterns where supported

Example numeric matching:

{
  "source": ["com.codewithvenu.orders"],
  "detail": {
    "amount": [
      {
        "numeric": [">=", 1000]
      }
    ]
  }
}

This rule selects high-value orders with an amount of at least 1,000.

Multiple Rules Matching One Event

One event may match several rules.

flowchart LR
    Event[Order Created Event] --> Bus[Order Event Bus]

    Bus --> FraudRule[Fraud Rule]
    Bus --> InventoryRule[Inventory Rule]
    Bus --> NotificationRule[Notification Rule]
    Bus --> AuditRule[Audit Rule]

    FraudRule --> Fraud[Fraud Function]
    InventoryRule --> Inventory[Inventory Function]
    NotificationRule --> Notify[Notification Function]
    AuditRule --> Audit[Audit Queue]

This provides event fan-out without adding direct dependencies to the producer.

EventBridge Targets

A target is a resource or endpoint invoked when an event matches a rule.

Common targets include:

AWS Lambda
Amazon SQS
Amazon SNS
AWS Step Functions
Amazon ECS tasks
AWS Batch
Amazon Kinesis Data Streams
Amazon API Gateway
Another EventBridge event bus
API Destinations
CloudWatch Logs
Systems Manager automation

Target Architecture

flowchart LR
    EventBus[Event Bus] --> Rule[Matching Rule]

    Rule --> Lambda[AWS Lambda]
    Rule --> SQS[Amazon SQS]
    Rule --> StepFunctions[Step Functions]
    Rule --> APIDestination[API Destination]

Each target can have its own configuration and permissions.

Input Transformation

A rule can transform an event before sending it to a target.

Input transformation can:

Select specific event fields
Rename fields
Create a target-specific payload
Remove unnecessary information
Add static text

Incoming event:

{
  "source": "com.codewithvenu.orders",
  "detail": {
    "orderId": "ORD-10025",
    "customerId": "CUS-7001",
    "amount": 249.99
  }
}

Transformed target payload:

{
  "id": "ORD-10025",
  "customer": "CUS-7001",
  "message": "A new order requires processing"
}

Transformations should handle routing concerns rather than complex business logic.

Publishing Custom Events

Applications can publish custom events using the PutEvents API.

Example Java code:

package com.codewithvenu.eventbridge;

import software.amazon.awssdk.services.eventbridge.EventBridgeClient;
import software.amazon.awssdk.services.eventbridge.model.PutEventsRequest;
import software.amazon.awssdk.services.eventbridge.model.PutEventsRequestEntry;
import software.amazon.awssdk.services.eventbridge.model.PutEventsResponse;

public class OrderEventPublisher {

    private final EventBridgeClient eventBridgeClient;
    private final String eventBusName;

    public OrderEventPublisher(
            EventBridgeClient eventBridgeClient,
            String eventBusName) {
        this.eventBridgeClient = eventBridgeClient;
        this.eventBusName = eventBusName;
    }

    public void publishOrderCreated(
            String orderId,
            String customerId,
            double amount) {

        String detail = """
                {
                  "orderId": "%s",
                  "customerId": "%s",
                  "amount": %.2f,
                  "status": "CREATED"
                }
                """.formatted(orderId, customerId, amount);

        PutEventsRequestEntry entry = PutEventsRequestEntry.builder()
                .eventBusName(eventBusName)
                .source("com.codewithvenu.orders")
                .detailType("Order Created")
                .detail(detail)
                .build();

        PutEventsResponse response = eventBridgeClient.putEvents(
                PutEventsRequest.builder()
                        .entries(entry)
                        .build()
        );

        if (response.failedEntryCount() != null
                && response.failedEntryCount() > 0) {
            throw new IllegalStateException(
                    "Failed to publish one or more EventBridge events"
            );
        }
    }
}

Applications should inspect individual result entries because a batch request may contain partial failures.

EventBridge vs Amazon SNS

EventBridge	Amazon SNS
Advanced content-based filtering	Basic subscription filtering
Uses event buses and rules	Uses topics and subscriptions
Supports AWS, custom, and SaaS events	Primarily publish-subscribe messaging
Supports schema registry	No built-in event schema registry
Supports archive and replay	No native topic archive and replay
Routes to many AWS targets	Strong fan-out to queues, Lambda, HTTP, email, and SMS
Best for application event routing	Best for notifications and simple fan-out

EventBridge vs Amazon SQS

EventBridge	Amazon SQS
Routes events	Stores messages
Supports many-to-many integration	Supports queue-based consumption
Consumers do not poll the event bus	Consumers poll or receive from the queue
Does not replace durable work queues	Provides message buffering
Supports event patterns	Preserves messages until processed or expired
Useful for event distribution	Useful for workload decoupling and backpressure

EventBridge and SQS are often used together.

flowchart LR
    Producer --> EventBridge[EventBridge]
    EventBridge --> Rule[Order Rule]
    Rule --> SQS[Order Processing Queue]
    SQS --> Lambda[Worker Lambda]

EventBridge handles routing, while SQS provides buffering and controlled consumption.

EventBridge vs Kafka

EventBridge	Apache Kafka
Managed event-routing service	Distributed event-streaming platform
Rule-based push routing	Partitioned append-only log
Consumer does not manage offsets	Consumers manage offsets
Supports AWS and SaaS integrations	Supports high-throughput stream processing
Archive and replay are optional features	Replay is native through offsets
Simple operational model	Greater streaming control and complexity
Best for cloud-event integration	Best for event streaming and durable event logs

EventBridge is not a direct replacement for Kafka in every use case.

Kafka is generally stronger for:

High-volume ordered streams
Long-term log retention
Consumer-controlled replay
Stream processing
Partition-based ordering

EventBridge Pipes

Amazon EventBridge Pipes creates a point-to-point connection between a supported source and target.

A pipe can include:

Source
Optional filter
Optional input transformation
Optional enrichment
Target

flowchart LR
    Source[SQS or Stream Source] --> Filter[Optional Filter]
    Filter --> Enrichment[Optional Enrichment]
    Enrichment --> Target[Target Service]

Pipes reduce the need for custom integration code.

Common Pipe Sources

Common EventBridge Pipes sources include:

Amazon SQS
Amazon Kinesis Data Streams
DynamoDB Streams
Amazon Managed Streaming for Apache Kafka
Self-managed Apache Kafka
Amazon MQ

Common Pipe Targets

Common targets include:

AWS Lambda
AWS Step Functions
Amazon EventBridge event buses
Amazon ECS
Amazon API Gateway
Amazon SNS
Amazon SQS
Kinesis
API Destinations

Pipe Enrichment

Enrichment allows a pipe to call another service before invoking the final target.

flowchart LR
    Queue[SQS Order Queue] --> Pipe[EventBridge Pipe]
    Pipe --> Filter[Filter Valid Orders]
    Filter --> Enrichment[Customer Enrichment Lambda]
    Enrichment --> Workflow[Step Functions Workflow]

Enrichment can be used to:

Add customer information
Validate event data
Look up configuration
Convert identifiers
Add authorization context

Enrichment should remain focused and should not create unnecessary latency or coupling.

EventBridge Pipes vs Event Bus

EventBridge Pipes	Event Bus
Point-to-point integration	Many-to-many event routing
One configured source	Many producers can publish
One target per pipe	Rules can route to multiple targets
Supports filtering and enrichment	Supports rule-based event matching
Useful for queues and streams	Useful for business-event distribution
Reduces connector code	Decouples many producers and consumers

Pipes and event buses are often combined.

flowchart LR
    DynamoDB[DynamoDB Stream] --> Pipe[EventBridge Pipe]
    Pipe --> Bus[Domain Event Bus]

    Bus --> RuleA[Rule A]
    Bus --> RuleB[Rule B]

    RuleA --> Lambda[AWS Lambda]
    RuleB --> Queue[Amazon SQS]

EventBridge Scheduler

Amazon EventBridge Scheduler is a managed scheduling service for one-time and recurring invocations.

It supports:

One-time schedules
Rate-based schedules
Cron-based schedules
Time-zone-aware schedules
Flexible delivery windows
Retry policies
Dead-letter queues
Large numbers of independent schedules

flowchart LR
    Scheduler[EventBridge Scheduler] --> Lambda[AWS Lambda]
    Scheduler --> SQS[Amazon SQS]
    Scheduler --> StepFunctions[Step Functions]
    Scheduler --> ECS[Amazon ECS Task]

Scheduler Use Cases

EventBridge Scheduler is useful for:

Sending appointment reminders
Running nightly jobs
Expiring temporary access
Starting workflows
Triggering delayed processing
Invoking periodic reconciliation
Scheduling millions of independent customer tasks

One-Time Schedule

A one-time schedule invokes a target once at a specified date and time.

Example use case:

flowchart LR
    Order[Order Created] --> Schedule[Create Delivery Reminder Schedule]
    Schedule -->|Scheduled Time| Notification[Notification Lambda]

After the schedule is no longer needed, it should be deleted automatically or through cleanup logic where appropriate.

Recurring Schedule

A recurring schedule invokes a target repeatedly.

Examples:

Every five minutes
Every hour
Every weekday
Every month
At midnight in a selected time zone

Scheduled processing should be idempotent because delivery retries may occur.

Flexible Time Window

A flexible time window allows Scheduler to invoke a target within a configured period instead of at one exact second.

This can help:

Distribute a large number of scheduled invocations
Reduce sudden traffic spikes
Protect downstream systems
Smooth workload demand

Use exact scheduling only when the business requirement truly requires exact invocation timing.

Scheduler vs Scheduled EventBridge Rules

EventBridge Scheduler	Scheduled Rule
Dedicated scheduling service	Rule attached to an event bus
Supports one-time schedules	Primarily recurring rate or cron schedules
Supports time zones	More limited scheduling model
Supports flexible time windows	No equivalent flexible delivery window
Designed for large-scale scheduling	Suitable for simpler legacy schedules
Broad target API support	Rule-target integration
Recommended for new schedules	Existing scheduled rules remain supported

API Destinations

API Destinations allow EventBridge to invoke external HTTPS endpoints.

flowchart LR
    Event[Business Event] --> Bus[EventBridge Bus]
    Bus --> Rule[Matching Rule]
    Rule --> Destination[API Destination]
    Destination --> PartnerAPI[External Partner API]

API Destinations use connections to manage authentication information.

Supported authentication patterns include:

API key
Basic authentication
OAuth client credentials

Secrets associated with connections should be managed securely.

API Destination Use Cases

Send events to a SaaS application
Invoke a partner API
Integrate with an external ticketing system
Send operational events to an external platform
Trigger a third-party workflow

Rate limits and target availability should be considered carefully.

Cross-Account Event Routing

EventBridge can route events between AWS accounts.

flowchart LR
    Producer[Application in Account A] --> BusA[Event Bus Account A]
    BusA --> Rule[Cross-Account Rule]
    Rule --> BusB[Event Bus Account B]
    BusB --> Consumer[Consumer in Account B]

Cross-account routing is useful for:

Centralized security events
Centralized audit processing
Shared integration platforms
Multi-account organizations
Domain-based ownership

The receiving event bus requires a resource-based policy that permits the sending account or organization.

Centralized Enterprise Event Bus

flowchart TB
    AccountA[Application Account A] --> CentralBus[Central Event Bus]
    AccountB[Application Account B] --> CentralBus
    AccountC[Security Account] --> CentralBus

    CentralBus --> Analytics[Analytics Account]
    CentralBus --> Audit[Audit Account]
    CentralBus --> Operations[Operations Account]

A centralized model improves governance but should avoid becoming an organizational bottleneck.

Domain-oriented event buses may provide better ownership in large environments.

Cross-Region Event Routing

Events can be routed to an event bus in another Region.

Use cases include:

Disaster recovery
Centralized monitoring
Regional aggregation
Multi-Region applications

flowchart LR
    RegionA[Event Bus Region A] --> Rule[Cross-Region Rule]
    Rule --> RegionB[Event Bus Region B]
    RegionB --> Consumer[Regional Consumer]

Cross-Region design must account for:

Latency
Permissions
Regional availability
Data residency
Cost
Duplicate processing

Global Endpoints

EventBridge global endpoints can support regional failover for event ingestion.

flowchart LR
    Producer[Event Producer] --> Endpoint[EventBridge Global Endpoint]

    Endpoint --> Primary[Primary Region Event Bus]
    Endpoint -. Failover .-> Secondary[Secondary Region Event Bus]

    Primary --> ConsumerA[Primary Consumers]
    Secondary --> ConsumerB[Secondary Consumers]

Applications must still design consumer state, data replication, and idempotency for regional recovery.

Event Delivery

EventBridge attempts to deliver matched events to rule targets.

Delivery can fail due to:

Missing permissions
Target throttling
Target unavailability
Invalid target configuration
Network issues
Resource deletion
Invocation errors

A production design should include:

Retry policy
Dead-letter queue
Monitoring alarms
Replay procedures
Idempotent consumers

Retry Policy

A retry policy controls how EventBridge retries failed target delivery.

flowchart TD
    Event[Matched Event] --> Target[Invoke Target]
    Target --> Result{Delivered?}
    Result -->|Yes| Complete[Complete]
    Result -->|No| Retry[Retry with Backoff]
    Retry --> Limit{Retry Policy Exhausted?}
    Limit -->|No| Target
    Limit -->|Yes| DLQ[Dead-Letter Queue]

Retry settings should be selected based on:

Business processing window
Target recovery time
Duplicate-processing impact
Event usefulness over time
Downstream capacity

Retriable vs Non-Retriable Errors

Retriable Errors

Transient failures may be retried.

Examples include:

Target temporarily unavailable
Throttling
Service timeout
Temporary service failure

Non-Retriable Errors

Some failures require configuration or permission changes.

Examples include:

Missing target permission
Invalid target resource
Resource not found
Incorrect configuration

Monitoring should distinguish temporary delivery problems from permanent configuration failures.

Dead-Letter Queue

A dead-letter queue stores events that EventBridge could not deliver to a target.

EventBridge uses an Amazon SQS standard queue as a rule-target DLQ.

flowchart LR
    EventBridge[EventBridge Rule] --> Target[Target Service]
    Target -->|Delivery Failure| Retry[Retry Policy]
    Retry -->|Exhausted| DLQ[SQS Dead-Letter Queue]
    DLQ --> Investigation[Investigation and Replay]

A DLQ supports:

Failure inspection
Root-cause analysis
Alerting
Manual replay
Automated redrive processing

Rule DLQ vs Target Service DLQ

EventBridge Rule DLQ	Target Service DLQ
Captures target-delivery failures	Captures failures inside target processing
EventBridge could not invoke the target	Target received but could not process the event
Configured on the EventBridge target	Configured by Lambda, SQS, or another service
Useful for routing and permission failures	Useful for application-processing failures

Both may be required.

Event Delivery Failure Example

flowchart LR
    Event[Order Event] --> Rule[Order Rule]
    Rule --> Lambda[Order Lambda]

    Lambda -->|Invocation Failed| RuleDLQ[EventBridge Target DLQ]
    Lambda -->|Processing Failed After Invocation| LambdaDLQ[Lambda Failure Destination]

The exact failure path depends on whether EventBridge successfully delivered the event.

Idempotency

EventBridge uses at-least-once event-delivery behavior in scenarios where retries or duplicate delivery can occur.

Consumers should be idempotent.

flowchart LR
    Event[Event with Unique ID] --> Consumer[Event Consumer]
    Consumer --> Check{Event Already Processed?}
    Check -->|Yes| Return[Return Existing Result]
    Check -->|No| Process[Process Event]
    Process --> Store[Store Event ID and Result]

Common techniques include:

Event ID tracking
Business transaction identifiers
DynamoDB conditional writes
Database uniqueness constraints
Idempotency tables
State-transition validation

Event Ordering

EventBridge should not be used when strict global ordering is required.

Events may arrive:

At different times
More than once
Out of order

Consumers should avoid assuming that:

Event publication order equals processing order
Events are delivered exactly once
One event always completes before another

When strict ordering is required, evaluate:

Amazon SQS FIFO queues
Kafka partitions
Kinesis Data Streams
Explicit sequence numbers
Version-based state checks

Archive and Replay

An EventBridge archive stores events received by an event bus.

A replay sends archived events back to the same event bus for reprocessing.

flowchart LR
    Producer --> Bus[Event Bus]
    Bus --> Archive[Event Archive]
    Bus --> Rule[Rules and Targets]

    Archive --> Replay[Replay Operation]
    Replay --> Bus

Archive Use Cases

Recover from consumer failures
Reprocess events after a bug fix
Test new event consumers
Restore missed downstream processing
Investigate historical events
Support operational recovery

Archive retention and event-selection patterns should be configured according to business requirements.

Replay Considerations

Replayed events can trigger existing rules and targets again.

Before replaying:

Confirm consumer idempotency.
Select the correct time range.
Review current rule configuration.
Estimate downstream load.
Protect external systems.
Monitor errors and throttling.
Avoid duplicate financial or customer actions.

Replay is a recovery tool, not a replacement for correct failure handling.

Schema Registry

The EventBridge Schema Registry stores event schemas.

It helps developers understand:

Available event types
Event structures
Field names
Data types
Schema versions

flowchart LR
    EventBus[Event Bus] --> Discovery[Schema Discovery]
    Discovery --> Registry[Schema Registry]
    Registry --> Developer[Application Developer]
    Registry --> Bindings[Generated Code Bindings]

Schema Discovery

Schema discovery can inspect events on an event bus and infer their schemas.

When event structures change, new schema versions may be created.

Schema discovery should be evaluated carefully when events contain sensitive data because discovery processes event structures.

Schema Versioning

Events evolve over time.

Safe schema evolution commonly includes:

Adding optional fields
Preserving existing field meanings
Avoiding unannounced field removal
Avoiding incompatible data-type changes
Publishing schema versions
Supporting old consumers during migration

Example:

{
  "schemaVersion": "2.0",
  "orderId": "ORD-10025",
  "customerId": "CUS-7001",
  "amount": 249.99,
  "currency": "USD",
  "salesChannel": "MOBILE"
}

Event Contract Design

A strong event contract should include:

Event identifier
Event type
Event timestamp
Event source
Schema version
Business entity identifier
Correlation identifier
Causation identifier
Business payload
Non-sensitive metadata

Example:

{
  "eventId": "evt-5e03180f",
  "eventType": "payment.completed",
  "eventTime": "2026-07-18T14:30:00Z",
  "eventSource": "payment-service",
  "schemaVersion": "1.0",
  "correlationId": "corr-981235",
  "causationId": "evt-order-725",
  "data": {
    "paymentId": "PAY-9021",
    "orderId": "ORD-10025",
    "status": "COMPLETED"
  }
}

Event Notification vs Event-Carried State Transfer

Event Notification

The event contains minimal information.

{
  "eventType": "customer.updated",
  "customerId": "CUS-7001"
}

The consumer retrieves additional data from the source service.

Event-Carried State Transfer

The event contains the data consumers need.

{
  "eventType": "customer.updated",
  "customerId": "CUS-7001",
  "name": "Venu",
  "status": "ACTIVE"
}

Notification	Event-Carried State
Smaller events	Richer events
Consumer calls source service	Fewer source-service calls
Stronger runtime coupling	Greater schema coupling
Easier data ownership	Possible data duplication

The choice depends on data sensitivity, coupling, latency, and consistency requirements.

Transactional Outbox Pattern

A common challenge occurs when an application must update a database and publish an event atomically.

Without coordination:

Database update succeeds.
Event publication fails.
Downstream consumers never receive the event.

The transactional outbox pattern solves this by storing the business change and event record in one database transaction.

flowchart LR
    Service[Order Service] --> Transaction[Database Transaction]
    Transaction --> OrderTable[(Order Table)]
    Transaction --> Outbox[(Outbox Table)]

    Outbox --> Publisher[Outbox Publisher]
    Publisher --> EventBridge[Amazon EventBridge]

The publisher later reads unpublished outbox records and sends them to EventBridge.

EventBridge and DynamoDB Streams Outbox

flowchart LR
    Application[Application] --> DynamoDB[(DynamoDB Table)]
    DynamoDB --> Stream[DynamoDB Stream]
    Stream --> Pipe[EventBridge Pipe]
    Pipe --> EventBus[Domain Event Bus]
    EventBus --> Consumers[Event Consumers]

This design can reduce custom polling logic while preserving reliable change capture.

Event Choreography

Event choreography allows services to react independently to events.

flowchart LR
    Order[Order Service] -->|Order Created| EventBridge[EventBridge]

    EventBridge --> Payment[Payment Service]
    EventBridge --> Inventory[Inventory Service]
    EventBridge --> Notification[Notification Service]

Advantages include:

Loose coupling
Independent deployment
Easy consumer addition
Natural fan-out

Challenges include:

Distributed debugging
Eventual consistency
Complex failure recovery
Harder end-to-end visibility
Potential event cycles

For complex business workflows, orchestration through Step Functions may be easier to understand.

EventBridge and Step Functions

EventBridge and Step Functions solve different problems.

EventBridge	Step Functions
Routes events	Orchestrates workflows
Decouples producers and consumers	Controls step-by-step execution
Supports choreography	Supports orchestration
Does not maintain business workflow state	Maintains workflow execution state
Best for event fan-out	Best for coordinated multi-step processes

They are often used together.

flowchart LR
    Event[Order Created] --> EventBridge[EventBridge]
    EventBridge --> Rule[High-Value Order Rule]
    Rule --> Workflow[Step Functions Workflow]

Security Model

EventBridge security can involve:

IAM identity policies
Event-bus resource policies
Target execution roles
AWS KMS encryption
Cross-account permissions
CloudTrail audit logging
VPC and endpoint controls where applicable

IAM Permissions

Producers may require permission to:

Publish events
Create or manage rules
Configure targets
Create pipes
Create schedules
Start replays

Consumers or EventBridge roles may require permission to:

Invoke Lambda
Send messages to SQS
Publish to SNS
Start Step Functions executions
Invoke API destinations
Run ECS tasks

Least-privilege permissions should be applied.

Resource-Based Policies

Event buses can use resource policies to control who may:

Publish events
Create rules
Manage targets
Send cross-account events

flowchart LR
    AccountA[Producer Account] --> Policy[Event Bus Resource Policy]
    Policy --> Bus[Central Event Bus]
    Bus --> Consumer[Authorized Consumer]

AWS Organizations conditions can simplify organization-wide event access.

Target Permissions

EventBridge must have permission to invoke the configured target.

Depending on the target, authorization may use:

Resource-based policy
IAM execution role
Service-linked permissions

Missing permissions are a common cause of failed event delivery.

Encryption

EventBridge events are encrypted in transit.

Encryption at rest may use:

AWS-owned keys
Customer-managed AWS KMS keys where supported

Customer-managed keys provide additional control but require correct key policies and operational management.

Disabling or deleting a required key can interrupt event processing.

Protecting Sensitive Data

Avoid placing highly sensitive information in events unless it is necessary.

Do not publish:

Passwords
Private keys
Full payment-card numbers
Access tokens
Unnecessary personal data
Confidential secrets

Event payloads may be:

Routed to multiple consumers
Logged during troubleshooting
Archived
Replayed
Included in DLQs
Discovered by schema tools

Publish only the minimum data required.

Monitoring EventBridge

Amazon CloudWatch provides EventBridge metrics.

Important signals include:

Metric	Purpose
Matched events	Shows how many events matched rules
Invocation attempts	Measures attempts to invoke targets
Successful invocations	Measures successful target delivery
Failed invocations	Detects delivery failures
Retry attempts	Shows repeated delivery attempts
Throttled rules	Detects throttling
Dead-letter invocations	Detects events sent to a DLQ
PutEvents failures	Detects custom-event publishing failures
Pipe execution failures	Detects pipe-processing errors
Scheduler target errors	Detects schedule invocation failures

Monitoring Architecture

flowchart LR
    EventBridge[Amazon EventBridge] --> Metrics[CloudWatch Metrics]
    EventBridge --> Logs[CloudTrail and Application Logs]
    Metrics --> Alarm[CloudWatch Alarm]
    Alarm --> SNS[Amazon SNS]
    SNS --> Operations[Operations Team]

Recommended Alerts

Create alerts for:

Failed target invocations
DLQ message count
PutEvents failed entries
Target throttling
Unusual event-volume drops
Unexpected event-volume spikes
Pipe failure states
Scheduler invocation failures
Archive or replay failures
Cross-Region delivery problems

A zero-event condition may be as important as an error spike for critical business events.

CloudTrail

AWS CloudTrail records EventBridge API activity such as:

Rule creation
Rule updates
Target changes
Event-bus policy changes
Pipe creation
Schedule management
Archive and replay operations

CloudTrail supports:

Security investigations
Change auditing
Compliance
Unauthorized-action detection

Distributed Tracing

Event-driven processing crosses asynchronous service boundaries.

Useful identifiers include:

Event ID
Correlation ID
Trace ID
Causation ID
Business transaction ID

flowchart LR
    API[Order API] --> Event[Order Event]
    Event --> EventBridge[EventBridge]
    EventBridge --> Payment[Payment Function]
    EventBridge --> Inventory[Inventory Function]

    API --> Trace[Trace and Correlation Context]
    Payment --> Trace
    Inventory --> Trace

Consumers should propagate identifiers to logs, downstream events, queues, and workflow executions.

Production Architecture

flowchart TB
    Client[Web or Mobile Client] --> API[API Gateway]
    API --> OrderLambda[Order Lambda]
    OrderLambda --> Orders[(DynamoDB Orders Table)]

    OrderLambda --> EventBridge[Order Event Bus]

    EventBridge --> PaymentRule[Payment Rule]
    EventBridge --> InventoryRule[Inventory Rule]
    EventBridge --> NotificationRule[Notification Rule]
    EventBridge --> AuditRule[Audit Rule]

    PaymentRule --> PaymentWorkflow[Step Functions Payment Workflow]
    InventoryRule --> InventoryQueue[SQS Inventory Queue]
    NotificationRule --> NotificationLambda[Notification Lambda]
    AuditRule --> AuditQueue[SQS Audit Queue]

    InventoryQueue --> InventoryLambda[Inventory Lambda]

    PaymentWorkflow --> PaymentAPI[Payment Provider]
    NotificationLambda --> SNS[Amazon SNS]

    PaymentRule --> PaymentDLQ[SQS Rule DLQ]
    InventoryRule --> InventoryDLQ[SQS Rule DLQ]

    EventBridge --> Archive[Event Archive]
    EventBridge --> Monitoring[CloudWatch Metrics]

Production Use Case: Order Processing

Consider an e-commerce platform where multiple systems must react when an order is created.

Processing Flow

The customer submits an order.
API Gateway invokes the order Lambda.
The function validates and stores the order.
The order service publishes an Order Created event.
EventBridge evaluates the event against several rules.
The payment rule starts a Step Functions workflow.
The inventory rule sends the event to an SQS queue.
The notification rule invokes a notification function.
The audit rule sends the event to an audit queue.
Delivery failures are retried.
Undelivered events are sent to rule DLQs.
Events are archived for operational replay.
CloudWatch monitors delivery health.

Interview Questions and Answers

1. What is Amazon EventBridge?

Answer

Amazon EventBridge is a managed serverless event-routing service used to connect event producers and consumers.

It receives events from:

AWS services
Custom applications
SaaS partners

It evaluates those events against rule patterns and sends matching events to configured targets.

EventBridge supports loosely coupled, event-driven applications without requiring producers to directly invoke consumers.

2. What is an EventBridge event bus?

Answer

An event bus is a logical channel that receives events and evaluates them against rules.

The main types are:

Default event bus for AWS service events
Custom event bus for application events
Partner event bus for supported SaaS providers

Custom event buses are commonly created for business domains, environments, or integration boundaries.

3. How do EventBridge rules work?

Answer

A rule contains an event pattern and one or more targets.

When an event arrives:

EventBridge compares the event with the rule pattern.
If the event matches, EventBridge invokes the configured targets.
If it does not match, the rule takes no action.
Other rules independently evaluate the same event.

One event can therefore trigger multiple independent consumers.

4. What is the difference between EventBridge and SNS?

Answer

Both services support event fan-out, but EventBridge provides more advanced event-routing capabilities.

EventBridge provides:

Event buses
Content-based rules
AWS and SaaS event integration
Archive and replay
Schema Registry
API Destinations
Cross-account routing

SNS is commonly used for:

Notifications
Simple publish-subscribe fan-out
Email and SMS delivery
Queue and Lambda fan-out

EventBridge is generally preferred for complex application-event routing, while SNS is strong for notification delivery and simpler fan-out.

5. What is the difference between EventBridge and SQS?

Answer

EventBridge routes events, while SQS stores messages until consumers process them.

EventBridge is useful for:

Event filtering
Fan-out
Many-to-many integration
Event routing

SQS is useful for:

Buffering
Backpressure
Controlled processing
Durable work queues
Consumer decoupling

A common design routes an EventBridge event to SQS and allows a worker to process it at a controlled rate.

6. What are EventBridge Pipes?

Answer

EventBridge Pipes provides point-to-point integration between a supported event source and one target.

A pipe may include:

Source
Filtering
Input transformation
Enrichment
Target

Pipes reduce custom integration code for connecting services such as SQS, Kinesis, DynamoDB Streams, Kafka, Lambda, Step Functions, and event buses.

7. What is EventBridge Scheduler?

Answer

EventBridge Scheduler is a managed service for creating one-time and recurring schedules.

It supports:

One-time schedules
Cron expressions
Rate expressions
Time zones
Flexible delivery windows
Retry policies
Dead-letter queues
Many AWS service targets

It is preferred for new scheduling requirements over legacy scheduled event-bus rules.

8. How does EventBridge handle target failures?

Answer

When EventBridge cannot deliver an event to a target, it can retry according to the target retry policy.

After retries are exhausted, the event may be sent to an SQS dead-letter queue if one is configured.

Production systems should configure:

Appropriate event age
Retry limits
Dead-letter queues
CloudWatch alarms
Replay procedures
Idempotent consumers

Without a DLQ, events may be lost after delivery retries are exhausted.

9. What are archive and replay?

Answer

An archive stores events received by an EventBridge event bus.

Replay sends selected archived events back to the event bus.

Archive and replay are useful for:

Recovering from consumer outages
Reprocessing events after a bug fix
Testing new consumers
Restoring missed processing

Consumers must be idempotent because replayed events may repeat completed business actions.

10. How do you secure Amazon EventBridge?

Answer

Recommended security controls include:

Least-privilege IAM policies
Dedicated producer and target roles
Event-bus resource policies
Restricted cross-account access
AWS KMS encryption where required
CloudTrail auditing
Sensitive-data minimization
DLQ access controls
Schema-discovery review
Organization-based policy conditions
Permission monitoring

Producers should only publish to authorized buses, and EventBridge should only invoke approved targets.

Common Interview Follow-Up Questions

What is an EventBridge event pattern?
What is the default event bus?
What is a custom event bus?
Can one event match multiple rules?
What is input transformation?
How do EventBridge retries work?
What is an EventBridge rule DLQ?
What is the difference between a rule DLQ and a Lambda DLQ?
What are EventBridge API Destinations?
How does cross-account routing work?
What is schema discovery?
What is archive and replay?
How do EventBridge Pipes differ from an event bus?
How does EventBridge compare with Kafka?
How do you guarantee reliable event publication?

Common Mistakes

Assuming Exactly-Once Delivery

Consumers must handle retries and duplicate events.

Assuming Event Ordering

EventBridge does not provide strict global event ordering.

Missing Dead-Letter Queues

Undelivered events require a recovery destination.

Ignoring Partial `PutEvents` Failures

A batch request may succeed partially. Every response entry should be checked.

Publishing Sensitive Data

Events may be routed, archived, replayed, logged, or stored in DLQs.

Using Broad Event Patterns

Overly broad patterns can invoke unintended targets and increase cost.

Missing Target Permissions

EventBridge cannot invoke a target without the required resource policy or execution role.

Using EventBridge as a Work Queue

SQS is generally better for buffering and controlled message processing.

Replaying Without Idempotency

Replay can repeat completed financial, notification, or customer operations.

Creating Event Cycles

A consumer that republishes a matching event can create an infinite loop.

Troubleshooting EventBridge

Rule Is Not Matching Events

Check:

Event source
Detail type
Event pattern syntax
Field capitalization
Nested detail structure
Event bus
Rule enabled status
Region

Target Is Not Invoked

Check:

Target permission
IAM role
Resource policy
Target ARN
Rule state
Failed invocation metrics
DLQ messages
Target throttling

Custom Events Are Not Published

Check:

PutEvents response entries
Event bus name
IAM permission
Region
Payload format
Event size
Source and detail type

Duplicate Processing Occurs

Check:

Retry behavior
Consumer idempotency
Unique event IDs
Database constraints
Processing timeout
Replay activity

DLQ Contains Events

Check:

Error code
Target permissions
Target existence
Throttling
Target availability
Retry configuration
KMS permissions

Pipe Is Not Processing Records

Check:

Pipe state
Source permissions
Target permissions
Filter criteria
Enrichment errors
Source backlog
Pipe failure logs and metrics

EventBridge Best Practices

Create domain-oriented custom event buses.
Use clear event source names.
Use meaningful detail types.
Include schema versions.
Include correlation and causation identifiers.
Keep event contracts stable.
Add optional fields rather than breaking existing fields.
Apply least-privilege IAM.
Use resource policies for cross-account buses.
Configure target retry policies.
Configure SQS dead-letter queues.
Monitor failed and retried invocations.
Make consumers idempotent.
Do not assume event ordering.
Use SQS when buffering is required.
Use Pipes for point-to-point integration.
Use event buses for many-to-many routing.
Use Scheduler for one-time and recurring schedules.
Use Step Functions for coordinated workflows.
Use archive and replay for controlled recovery.
Test replay procedures before incidents.
Avoid publishing unnecessary sensitive data.
Inspect partial failures from PutEvents.
Use a transactional outbox for reliable publication.
Prevent recursive event loops.
Review service quotas and architecture cost.

Quick Revision

Topic	Key Point
EventBridge	Managed serverless event-routing service
Event	JSON representation of something that happened
Event bus	Receives events and evaluates rules
Default bus	Receives many AWS service events
Custom bus	Receives application or domain events
Partner bus	Receives SaaS partner events
Rule	Matches events and invokes targets
Event pattern	JSON criteria used for event matching
Target	Destination for a matched event
Input transformer	Changes payload before delivery
Pipes	Point-to-point event integration
Scheduler	One-time and recurring scheduling
API Destination	External HTTPS target
Retry policy	Controls repeated delivery attempts
DLQ	Stores undelivered events
Archive	Stores event-bus events
Replay	Resends archived events
Schema Registry	Stores event schemas
Idempotency	Prevents duplicate business outcomes
Outbox pattern	Reliably connects database updates and events

Key Takeaways

Amazon EventBridge provides serverless event routing for AWS services, custom applications, and SaaS providers.
Event buses receive events, rules select matching events, and targets process them.
Custom event buses help organize events around business domains and ownership boundaries.
One event can match multiple rules and trigger multiple independent consumers.
EventBridge Pipes is designed for point-to-point integration with filtering, transformation, and enrichment.
EventBridge Scheduler is designed for one-time and recurring scheduled invocations.
SQS should be added when durable buffering, backpressure, or controlled processing is required.
Target retries and dead-letter queues are essential for reliable delivery.
Archive and replay support recovery but require idempotent consumers.
EventBridge does not guarantee exactly-once processing or strict global ordering.
IAM roles, event-bus policies, encryption, auditing, and data minimization protect event-driven systems.
Transactional outbox patterns help prevent database updates and event publication from becoming inconsistent.
CloudWatch metrics, DLQ alerts, trace identifiers, and CloudTrail records provide production observability.

Amazon EventBridge Interview Questions and Answers

Module Navigation

Introduction

What Is Event-Driven Architecture?

What Is Amazon EventBridge?

Basic EventBridge Architecture

Core EventBridge Components

Event Structure

Standard Event Fields

Event Sources

AWS Service Events

Custom Application Events

SaaS Partner Events

Event Buses

Default Event Bus

Custom Event Bus

Partner Event Bus

EventBridge Rules

Event Pattern

Event Pattern Matching

Multiple Rules Matching One Event

EventBridge Targets

Target Architecture

Input Transformation

Publishing Custom Events

EventBridge vs Amazon SNS

EventBridge vs Amazon SQS

EventBridge vs Kafka

EventBridge Pipes

Common Pipe Sources

Common Pipe Targets

Pipe Enrichment

EventBridge Pipes vs Event Bus

EventBridge Scheduler

Scheduler Use Cases

One-Time Schedule

Recurring Schedule

Flexible Time Window

Scheduler vs Scheduled EventBridge Rules

API Destinations

API Destination Use Cases

Cross-Account Event Routing

Centralized Enterprise Event Bus

Cross-Region Event Routing

Global Endpoints

Event Delivery

Retry Policy

Retriable vs Non-Retriable Errors

Retriable Errors

Non-Retriable Errors

Dead-Letter Queue

Rule DLQ vs Target Service DLQ

Event Delivery Failure Example

Idempotency

Event Ordering

Archive and Replay

Archive Use Cases

Replay Considerations

Schema Registry

Schema Discovery

Schema Versioning

Event Contract Design

Event Notification vs Event-Carried State Transfer

Event Notification

Event-Carried State Transfer

Transactional Outbox Pattern

EventBridge and DynamoDB Streams Outbox

Event Choreography

EventBridge and Step Functions

Security Model

IAM Permissions

Resource-Based Policies

Target Permissions

Encryption

Protecting Sensitive Data

Monitoring EventBridge

Monitoring Architecture

Recommended Alerts

CloudTrail

Distributed Tracing

Ignoring Partial `PutEvents` Failures