AZ-305 - Design an API Integration Strategy
Azure API Management Overview
Azure API Management (APIM) is a fully managed service that enables organizations to publish, secure, transform, maintain, and monitor APIs. It acts as a facade for backend services, providing a consistent and modern API gateway for both internal and external consumers.
APIM Core Components
API Gateway
The API Gateway is the endpoint that accepts API calls and routes them to appropriate backends. It verifies API keys and other credentials, enforces usage quotas and rate limits, transforms requests and responses based on policy statements, caches responses to improve latency, and emits logs and metrics for monitoring.
Management Plane
The Management Plane is the administrative interface used to configure the APIM service. Through the Azure portal, REST APIs, PowerShell, or Azure CLI, administrators define API schemas, package APIs into products, set up policies, manage users and groups, and view analytics dashboards.
Developer Portal
The Developer Portal is an auto-generated, fully customizable website where API consumers can discover APIs, read documentation, try APIs through an interactive console, obtain subscription keys, and view usage analytics. It supports both managed and self-hosted deployment models.
APIM Tiers
| Tier | Use Case | Key Features |
|---|---|---|
| Consumption | Lightweight, serverless API proxying | Pay-per-execution, auto-scaling, no infrastructure management, limited features |
| Developer | Non-production evaluation and testing | No SLA, full feature set for development and testing purposes |
| Basic | Entry-level production workloads | SLA-backed, limited scale units, no VNet integration |
| Standard | Medium production workloads | Higher throughput, more scale units, no VNet integration |
| Premium | Enterprise production workloads | Multi-region deployment, VNet integration, multiple custom domains, higher limits |
API Policies
Policies in Azure API Management are a powerful mechanism that allows the publisher to change the behavior of APIs through configuration. Policies are a collection of XML statements that are executed sequentially on the request or response of an API.
Policy Sections
Policy Processing Pipeline
Inbound: Policies applied to the incoming request before it is forwarded to the backend service. Common inbound policies include authentication validation, rate limiting, request transformation, and IP filtering.
Backend: Policies applied before the request is forwarded to the backend and after the response is received. Used for setting backend URL, retry logic, and forward-request configuration.
Outbound: Policies applied to the outgoing response before it is returned to the caller. Common outbound policies include response transformation, header manipulation, and caching.
On-error: Policies applied when an error occurs during processing. Used for error logging, returning custom error responses, and retry logic.
Policy Example Structure
<inbound>
<rate-limit calls="20" renewal-period="90" />
<set-header name="X-Custom-Header" exists-action="override">
<value>custom-value</value>
</set-header>
</inbound>
<backend>
<forward-request />
</backend>
<outbound>
<set-header name="X-Powered-By" exists-action="delete" />
</outbound>
<on-error>
<set-body>An error occurred.</set-body>
</on-error>
</policies>
Rate Limiting and Throttling
Rate limiting and throttling protect backend services from being overwhelmed by excessive API calls. Azure APIM provides two primary policies for controlling call rates.
Rate Limit vs. Quota
rate-limit Policy
The rate-limit policy prevents API usage spikes by limiting the call rate to a specified number per a defined time period. When the rate limit is exceeded, the caller receives a 429 Too Many Requests response. This policy uses a sliding window approach and is applied per subscription key.
quota Policy
The quota policy enforces a renewable call volume or bandwidth limit over a longer period (days, weeks, or months). Unlike rate-limit which prevents short bursts, quota limits the total usage volume. When the quota is exceeded, the caller receives a 403 Forbidden response.
rate-limit-by-key Policy
The rate-limit-by-key policy provides more granular rate limiting by allowing you to define the counter key using any request attribute such as the caller IP address, a custom header value, or a user identity claim. This enables per-caller or per-endpoint throttling independent of subscription keys.
API Versioning and Revisions
Managing change in APIs is essential for maintaining backward compatibility while enabling evolution. APIM distinguishes between versions and revisions.
Versioning
API Versions
Versions allow you to present groups of related APIs to developers and represent breaking changes. APIM supports three versioning schemes:
Path-based: The version identifier is part of the URL path (e.g., /api/v1/products).
Header-based: The version is specified in a custom HTTP header.
Query string-based: The version is specified as a query parameter (e.g., /api/products?api-version=v1).
Revisions
Revisions allow you to make non-breaking changes to an API safely. Changes are made in a separate revision that does not affect current consumers. Once testing is complete, the revision can be made current. A changelog entry describes what changed, which is visible in the Developer Portal.
Securing APIs
Securing APIs in APIM involves multiple layers including authentication, authorization, transport security, and network isolation.
OAuth 2.0 and OpenID Connect
OAuth 2.0 Integration
APIM can validate JWT tokens issued by an OAuth 2.0 authorization server (such as Microsoft Entra ID). The validate-jwt inbound policy checks the token signature, expiration, issuer, audience, and specific claims. This enables APIM to act as a zero-trust gateway that rejects unauthenticated or unauthorized requests before they reach the backend.
Subscription Keys
APIM uses subscription keys as a simple mechanism for API access control. Consumers must include a valid subscription key in the request header (Ocp-Apim-Subscription-Key) or as a query parameter. Keys are associated with products and can be primary or secondary to enable key rotation without downtime.
API Products and Subscriptions
Products are the mechanism through which APIs are surfaced to developers. A product contains one or more APIs and is configured with a title, description, terms of use, and access policies. Products can be Open (accessible without a subscription) or Protected (requiring a subscription key). Developers subscribe to products to obtain access keys.
| Security Layer | Mechanism | Purpose |
|---|---|---|
| Transport | TLS/SSL | Encrypt data in transit |
| Authentication | OAuth 2.0 / JWT validation | Verify caller identity |
| Authorization | Claims-based policies | Enforce access permissions |
| Access Control | Subscription keys | Control API access through products |
| Network | VNet integration (Premium tier) | Restrict network-level access |
Key Terms
| Term | Definition |
|---|---|
| API Gateway | The runtime component of APIM that processes API calls, applies policies, and routes requests to backend services. |
| APIM Policy | An XML-based configuration statement that modifies the behavior of API request and response processing in APIM. |
| Subscription Key | A unique key associated with an APIM product subscription, used to authenticate API consumers. |
| API Product | A packaging mechanism in APIM that groups one or more APIs with usage policies and access controls for developer consumption. |
| validate-jwt | An APIM inbound policy that validates JSON Web Tokens for authenticity, expiration, issuer, and audience claims. |
| API Revision | A mechanism for making non-breaking changes to an API in APIM without affecting current consumers, enabling safe testing before publishing. |
| Developer Portal | A customizable website auto-generated by APIM where developers discover APIs, view documentation, test endpoints, and manage subscription keys. |
| Rate Limiting | A policy mechanism that restricts the number of API calls a consumer can make within a defined time window to protect backend services. |
Exam Tips
- Know APIM tiers: Only the Premium tier supports VNet integration and multi-region deployment. The Consumption tier is serverless with pay-per-execution pricing. Developer tier has no SLA.
- Policy sections order matters: Inbound policies run first, then backend, then outbound. On-error policies trigger only when exceptions occur. Understand which policies belong in which section.
- Versions vs. Revisions: Versions represent breaking changes visible to consumers. Revisions are non-breaking changes that can be tested privately before publishing. The exam tests this distinction.
- rate-limit vs. quota: Rate-limit prevents short bursts (returns 429). Quota limits total usage over longer periods (returns 403). Know the difference and when to use each.
- validate-jwt is key: For securing APIs with OAuth 2.0, the validate-jwt policy is applied in the inbound section. It can check issuer, audience, expiration, and custom claims.
- Products control access: APIs are exposed to developers through products. Protected products require subscription keys. Open products do not require keys.
Practice Questions
Question 1
Your organization needs to deploy Azure API Management with virtual network integration and multi-region support. Which APIM tier should you choose?
A. Consumption
B. Standard
C. Basic
D. Premium
Answer: D
Explanation: Only the Premium tier of Azure API Management supports VNet integration and multi-region deployment. The Consumption, Basic, and Standard tiers do not offer VNet integration capabilities.
Question 2
You need to ensure that API consumers cannot make more than 100 calls per minute to a specific API. Which APIM policy should you apply?
A. quota policy in the inbound section
B. rate-limit policy in the inbound section
C. rate-limit policy in the outbound section
D. ip-filter policy in the inbound section
Answer: B
Explanation: The rate-limit policy controls the call rate within a short time window and should be placed in the inbound section. It prevents API usage spikes by returning a 429 Too Many Requests response when the limit is exceeded. The quota policy is for longer-term volume limits, not per-minute rate control.
Question 3
You are publishing a new version of an API that introduces breaking changes to the response schema. Existing consumers must not be affected. How should you handle this in APIM?
A. Create a new API revision
B. Create a new API version
C. Update the existing API and notify consumers
D. Use a policy to transform the response for old consumers
Answer: B
Explanation: API versions in APIM are used to represent breaking changes. Creating a new version (e.g., v2) allows the old version to remain active and accessible to existing consumers while the new version is available for new consumers. Revisions are for non-breaking changes.
Question 4
You need to validate OAuth 2.0 bearer tokens at the API Management gateway before requests reach the backend service. Which APIM policy should you use?
A. authentication-basic
B. check-header
C. validate-jwt
D. set-backend-service
Answer: C
Explanation: The validate-jwt policy validates JSON Web Tokens in the inbound pipeline. It checks the token signature, expiration, issuer, audience, and custom claims. This is the standard approach for validating OAuth 2.0 bearer tokens at the APIM gateway level.
Question 5
A development team wants to make changes to an existing API to test internally before publishing to consumers. The current API consumers must not see any changes until the team is satisfied with the updates. What should the team use?
A. A new API version with path-based versioning
B. An API revision
C. A new API Management instance
D. A separate API product
Answer: B
Explanation: API revisions allow non-breaking changes to be made and tested privately without affecting current consumers. The team can work on a new revision, test it, and then make it the current revision when ready. Versions are for breaking changes, and creating a separate instance or product is unnecessary overhead.
AZ-305 Designing Azure Infrastructure Solutions - Table of Contents
Master all exam topics with comprehensive study guides and practice questions.