In AZ-204, API Management and event services are the core of the integration domain. This covers how to securely expose APIs and build event-driven architectures.
Azure API Management (APIM)
APIM is like an information desk at a department store. Every visitor (client) passes through the desk regardless of which store (backend service) they want to visit — and the desk handles identity verification, guidance, and logging.
Through APIM, you can bundle multiple backend APIs into a single consistent gateway and expose them to the outside world.
| Feature | Description | |---------|-------------| | API publishing | Securely expose backend APIs to external consumers | | Protection | Authentication, rate limiting, IP filtering | | Transformation | Convert request/response formats, add/remove headers | | Monitoring | Call logs, analytics dashboard |
Products, Subscriptions, and Keys
| Concept | Description | Example | |---------|-------------|---------| | Product | A package that bundles one or more APIs | "Free Plan APIs", "Premium APIs" | | Subscription | An application to access a product | A developer subscribes to the "Free Plan" | | Subscription Key | The authentication token used when calling the API | Sent in the header |
Clients include the subscription key in an HTTP header or query parameter when making API calls.
APIM Policies
Policies are rules that intercept and process requests or responses at the APIM gateway. They are written in XML format.
The Policy Pipeline
Every request and response flows through four stages:
Inbound: Processes the incoming request from the client before it reaches the gateway Backend: Processes the request before forwarding it to the backend Outbound: Processes the backend response before sending it to the client On-Error: Handles any errors that occur
Common Policies Reference
| Policy | Placement | Description | |--------|-----------|-------------| | rate-limit | Inbound | Limit number of calls (returns 429 when exceeded) | | ip-filter | Inbound | Allow or block by IP address | | set-header | Inbound / Outbound | Add, modify, or delete headers | | rewrite-uri | Inbound | Transform the URL path sent to the backend | | mock-response | Inbound | Return a fake response without calling the real backend | | cache-lookup / cache-store | Inbound / Outbound | Cache responses |
Azure Event Grid
Event Grid is like a notification service at a post office. When someone (the event source) sends a letter, the post office (Event Grid) receives it and delivers it to the people who signed up to receive that kind of letter (subscribers).
Use it to build a reactive architecture that responds as soon as an event occurs. For example, when an image is uploaded to Blob Storage, you can automatically trigger an Azure Function to generate a thumbnail.
Core Components
| Component | Role | Example | |-----------|------|---------| | Event Source | The service that generates events | Blob Storage, Resource Group, custom app | | Topic | The channel events are delivered through | System topics (auto-created by Azure) / Custom topics | | Event Subscription | Defines which events go to which handler | Blob created event → Function App | | Event Handler | The service that receives and processes the event | Azure Function, Logic App, Webhook, Event Hubs |
CloudEvents format is supported as a standard.
Azure Event Hubs
Event Hubs is like the entry gates at a large concert venue. When tens of thousands of people arrive at the same time, they are split across multiple gates (partitions) for parallel processing, and the entry order is recorded so it can be reviewed later.
Use it for big-data streaming scenarios that need to handle millions of events per second.
Core Concepts
| Concept | Description | |---------|-------------| | Partition | A unit that divides events for parallel processing (default: 4) | | Consumer Group | A set of consumers that independently read the same event stream | | Capture | Automatically saves events to Blob Storage or Data Lake | | Retention | Default 1 day, up to 90 days |
Event Grid vs Event Hubs Comparison
| Aspect | Event Grid | Event Hubs | |--------|-----------|-----------| | Primary use | React immediately when an event occurs | Large-scale data stream processing | | Processing model | Delivers events one by one (push) | Ordered stream processing | | Scale | Up to thousands per second | Up to millions per second | | Retention | None (deleted after delivery) | Up to 90 days | | Typical scenario | File upload triggers processing | IoT sensor data, log streaming |
!Event Grid versus Event Hubs
Exam Key Points
"Consolidate multiple backend APIs into a single gateway" -- Azure API Management (APIM)
"Limit API calls to N per minute" -- rate-limit policy (inbound)
"Allow or block specific IP addresses from accessing the API" -- ip-filter policy
"Transform the URL path before forwarding to the backend" -- rewrite-uri policy
"Return a test response without a real backend" -- mock-response policy
"Order of policy execution" -- Inbound → Backend → Outbound → On-Error
"Automatically trigger a Function when an event occurs (reactive)" -- Azure Event Grid
"The key component that subscribes to Blob upload events" -- Event Subscription
"Handle millions of events per second for large-scale streaming" -- Azure Event Hubs
"Automatically save Event Hubs data to Blob Storage" -- Capture
"Multiple teams independently reading the same stream" -- Consumer Group