This chapter covers Azure API Management backends and certificates, which are essential for securely routing API requests to backend services. On the AZ-204 exam, this topic typically appears in about 5-10% of questions, often integrated into scenarios involving API management, security, and backend integration. You'll need to understand how to configure backends, manage certificates for mutual TLS (mTLS) and client authentication, and handle backend health monitoring and circuit breaker patterns. Mastering these concepts will help you design resilient and secure API gateways.
Jump to a section
Imagine a large shipping company that manages deliveries for thousands of clients. The company has a central dispatch office (API Management) that receives packages (API requests) from various senders (client applications). Behind the scenes, the company uses multiple warehouses (backend services) to store and process packages. Each warehouse has its own loading dock (backend endpoint) with specific rules about how packages should be delivered (protocol, authentication). The dispatch office doesn't deliver packages directly to the warehouse's internal storage; instead, it uses a standardized shipping form (backend configuration) that specifies the warehouse address (URL), the required authorization (certificate or credential), and any special handling (rate limiting, circuit breaker). When a package arrives, the dispatch office checks the form, attaches any necessary stamps (certificates), and sends it to the correct dock. If a warehouse is overloaded, the dispatch office holds packages (circuit breaker) or reroutes them to a backup warehouse (load balancing). The dispatch office also keeps a log of all deliveries (diagnostics). In this analogy, the warehouses are the backend services, the shipping forms are the backend configurations, and the stamps are the certificates that prove the dispatch office is authorized to deliver packages. Just as a shipping company must update its forms when a warehouse changes its dock address, API Management must update backend configurations when a service endpoint changes. This ensures that packages always reach the right warehouse securely and efficiently.
What Are API Management Backends?
In Azure API Management, a backend is a configuration that defines the target service (HTTP or HTTPS endpoint) to which API requests are forwarded. Instead of hardcoding backend URLs in each API operation, you define a backend entity that centralizes the endpoint URL, authentication credentials (including certificates), and other settings like rate limiting and circuit breaker policies. This decoupling allows you to change the backend service URL without modifying the API definition.
Why Use Backends?
Backends provide several benefits: - Centralized configuration: Change the backend URL in one place, affecting all APIs that reference it. - Authentication: Store credentials (certificates, client secrets) securely and reuse them across multiple APIs. - Resilience: Implement circuit breaker patterns to handle backend failures gracefully. - Diagnostics: Enable logging and tracing for backend requests.
How Backends Work Internally
When an API request arrives at the API Management gateway, the gateway processes the request through policies (inbound, backend, outbound). The set-backend-service policy is used to route the request to a specific backend. The backend lookup occurs as follows:
The gateway receives a request and evaluates inbound policies.
If a set-backend-service policy is present, it reads the backend-id attribute.
The gateway retrieves the backend configuration from its internal store.
It applies any authentication settings (e.g., client certificate) defined in the backend.
The request is forwarded to the backend URL with the specified headers and credentials.
The backend response is processed by outbound policies before being sent to the client.
Key Components of a Backend
A backend entity in API Management includes:
- Title: A friendly name.
- Description: Optional description.
- Resource URL: The URL of the backend service (e.g., https://myapp.azurewebsites.net/api/).
- Protocol: HTTP or HTTPS.
- TLS/SSL settings: For HTTPS, you can specify whether to validate the backend certificate.
- Authentication methods: Basic, API Key, Client Certificate, Managed Identity, or OAuth 2.0.
- Circuit breaker: Configuration for opening the circuit when the backend is unhealthy.
- Load balancing: If multiple backend URLs are defined, you can configure load balancing (round-robin or weighted).
Configuring Backends via Azure Portal
To create a backend via the portal: 1. Navigate to your API Management instance. 2. Under APIs, select Backends. 3. Click + Add. 4. Provide a name, description, and the target URL. 5. Configure authentication (e.g., upload a client certificate). 6. Optionally, configure circuit breaker and load balancing. 7. Click Create.
Configuring Backends via ARM Template or CLI
You can create a backend using the Azure CLI:
az apim backend create --service-name myapim --resource-group myrg --backend-id mybackend --url "https://myapp.azurewebsites.net/api/" --protocol https --tls-validate-certificate trueTo attach a client certificate to the backend:
az apim backend update --service-name myapim --resource-group myrg --backend-id mybackend --set credentials.certificate.id=/subscriptions/.../resourceGroups/.../providers/Microsoft.ApiManagement/service/myapim/certificates/mycertUsing Backends in Policies
The set-backend-service policy is used to route requests to a backend. Example:
<policies>
<inbound>
<base />
<set-backend-service backend-id="mybackend" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>You can also override the backend URL dynamically using context variables:
<set-backend-service backend-id="@(context.Variables.GetValueOrDefault<string>("backendId", "default"))" />Certificates in API Management
API Management uses certificates for two primary purposes: - Client authentication: API Management presents a client certificate to the backend service (mTLS). - Backend TLS validation: API Management validates the backend service's certificate to ensure it's trusted.
Managing Certificates
Certificates are stored in API Management's certificate store. They can be uploaded as PFX files (with password) or referenced from Azure Key Vault. Key Vault integration allows automatic rotation and centralized management.
To upload a certificate via Azure CLI:
az apim certificate create --service-name myapim --resource-group myrg --certificate-id mycert --data "path/to/cert.pfx" --password "mypassword"To reference a Key Vault secret:
az apim certificate create --service-name myapim --resource-group myrg --certificate-id mycert --key-vault-secret-identifier "https://myvault.vault.azure.net/secrets/mycert/abc123"Client Certificate Authentication in Backends
When a backend requires a client certificate, you configure the backend to use the certificate stored in API Management. During request forwarding, API Management attaches the certificate to the TLS handshake. The backend must be configured to trust the API Management instance's CA or the specific certificate.
Backend Circuit Breaker
The circuit breaker pattern prevents cascading failures by stopping requests to an unhealthy backend. Configuration includes: - Number of requests: The minimum number of requests before evaluating failure conditions (default: 10). - Failure condition: The percentage of failed requests that triggers the circuit to open (default: 50%). - Trip duration: How long the circuit stays open before allowing a trial request (default: 60 seconds). - Half-open state: After the trip duration, a single request is allowed; if it succeeds, the circuit closes.
Backend Load Balancing
You can define multiple URLs for a backend and configure load balancing: - Round-robin: Distributes requests evenly. - Weighted: Distributes based on assigned weights (e.g., 80% to primary, 20% to secondary).
Interaction with Other Services
Backends can integrate with: - Azure Functions: Use the function's URL as the backend URL. - Logic Apps: Route to logic app endpoints. - Service Fabric: Use Service Fabric service endpoints. - Azure App Service: Point to web apps. - On-premises services: Via Azure Relay or VPN.
Diagnostics and Monitoring
Enable diagnostics to log backend requests and responses. Use Application Insights or Azure Monitor to track backend health and performance. You can also configure alerts based on backend failures.
Best Practices
Always use HTTPS for backend communication.
Validate backend certificates to prevent man-in-the-middle attacks.
Use Key Vault for certificate management to enable rotation.
Implement circuit breakers for critical backends.
Use load balancing for high availability.
Test backend connectivity using the Test tab in the portal.
Common Pitfalls
Incorrect backend URL: Ensure the URL is reachable from the API Management gateway.
Certificate mismatch: The backend must trust the client certificate's CA.
Circuit breaker misconfiguration: Setting the trip duration too short may cause flapping.
Overlooking TLS validation: Disabling validation may expose you to security risks.
Verification Commands
To test backend connectivity:
az apim backend show --service-name myapim --resource-group myrg --backend-id mybackendTo list all backends:
az apim backend list --service-name myapim --resource-group myrgTo delete a backend:
az apim backend delete --service-name myapim --resource-group myrg --backend-id mybackendCreate a Backend Entity
First, define a backend in API Management. This involves specifying the target URL, protocol, and any authentication settings. Use the Azure portal, ARM template, or CLI. For example, using CLI: `az apim backend create --service-name myapim --resource-group myrg --backend-id mybackend --url https://myapp.azurewebsites.net/api/ --protocol https --tls-validate-certificate true`. This creates a backend named 'mybackend' that points to the specified URL. The `tls-validate-certificate` flag ensures the gateway validates the backend's SSL certificate. Without this, the gateway might accept self-signed certificates, which is a security risk. The backend ID must be unique within the API Management instance.
Attach a Client Certificate
If the backend requires mutual TLS (mTLS), upload a client certificate to API Management and associate it with the backend. First, upload the certificate: `az apim certificate create --service-name myapim --resource-group myrg --certificate-id mycert --data path/to/cert.pfx --password pwd`. Then, update the backend to reference the certificate: `az apim backend update --service-name myapim --resource-group myrg --backend-id mybackend --set credentials.certificate.id=/subscriptions/.../certificates/mycert`. The certificate ID is the full ARM resource ID. During request forwarding, API Management attaches this certificate during the TLS handshake. The backend must trust the CA that issued the certificate. If using a self-signed certificate, the backend needs to have the certificate added to its trusted store.
Configure Circuit Breaker
To protect against backend failures, enable the circuit breaker. In the backend configuration, set the number of requests before evaluation (e.g., 10), failure threshold (e.g., 50%), and trip duration (e.g., 60 seconds). This can be done via portal or ARM. When the circuit is open, requests fail immediately without reaching the backend. After the trip duration, a single trial request is allowed; if it succeeds, the circuit closes. This pattern prevents overwhelming a failing backend. The default values are reasonable for most scenarios, but you can adjust based on your backend's behavior. For example, a high-traffic service might need a larger request count to avoid false positives.
Set Backend in API Policy
In the API's policy editor, add the `set-backend-service` policy to route requests to the backend. For example: `<set-backend-service backend-id="mybackend" />`. This policy can be placed in the inbound section. You can also conditionally set the backend using expressions: `<set-backend-service backend-id="@(context.Request.Headers.GetValueOrDefault("X-Backend-Id", "default"))" />`. After adding the policy, test the API by sending a request. The gateway will forward the request to the backend URL defined in the backend entity. If the backend requires authentication, the gateway will automatically include the configured credentials (e.g., client certificate).
Monitor and Diagnose
Enable diagnostics to log backend requests and responses. In API Management, under APIs > your API > Diagnostics, turn on logging to Application Insights or Azure Monitor. You can view traces to see the backend URL, headers, and status code. Also, use the 'Test' tab in the portal to manually test the API and see the backend response. If the circuit breaker is enabled, check the backend's health status in the portal under Backends > your backend > Health. This shows the current circuit state (open/closed). For production, set up alerts on backend failures using Azure Monitor metrics like 'Backend Failure Count'.
Enterprise Scenario: E-Commerce Platform
An e-commerce company uses Azure API Management as the gateway for its microservices. The product catalog service is hosted on Azure App Service, and the order service runs on AKS. Both backends require client certificate authentication for secure inter-service communication. The company configures backends for each service, uploading client certificates issued by their internal CA. They enable circuit breakers with a 50% failure threshold and 60-second trip duration to handle transient failures. During a Black Friday sale, the order service becomes overwhelmed; the circuit breaker opens after 10 requests (default) and prevents further requests, allowing the service to recover. Without the circuit breaker, the gateway would continue sending requests, exacerbating the overload. The company also uses load balancing with two instances of the product catalog service for high availability.
Enterprise Scenario: Hybrid Cloud Integration
A financial institution extends its on-premises payment processing system to the cloud via Azure Relay. The on-premises service is exposed as an HTTPS endpoint through a relay. In API Management, they create a backend pointing to the relay endpoint. They upload a client certificate signed by their enterprise CA and configure the backend to use it. The circuit breaker is set with a longer trip duration (120 seconds) because the on-premises service may take longer to recover from failures. They also disable TLS validation for the backend because the relay uses a self-signed certificate internally (not recommended but sometimes necessary). To mitigate risk, they use Azure Monitor to alert on any backend failures. Misconfiguration here could lead to security vulnerabilities or service disruptions.
Common Misconfiguration Issues
Certificate not trusted: The backend rejects the client certificate because the CA is not trusted. Check the backend's trust store.
Circuit breaker too sensitive: Setting the failure threshold too low (e.g., 10%) causes the circuit to open on minor glitches. Adjust based on normal failure rates.
Incorrect backend URL: A typo in the URL leads to 404 errors. Always test with a simple GET request.
TLS validation disabled: Disabling validation may expose data to man-in-the-middle attacks. Only disable in controlled environments.
Load balancing weights misconfigured: Unbalanced weights can cause one backend to receive all traffic. Verify weight distribution.
What AZ-204 Tests on This Topic
The exam objective 'Integrate' (5.1) includes configuring backends and certificates in Azure API Management. Questions may ask you to:
Choose the correct method to authenticate API Management to a backend (client certificate, managed identity, etc.).
Identify the correct policy to set the backend service (set-backend-service).
Configure circuit breaker settings.
Understand the difference between client certificate authentication and TLS validation.
Know how to reference a certificate from Key Vault.
Common Wrong Answers and Why
Using `authentication-managed-identity` policy instead of backend configuration: Candidates often think they need to add a policy for authentication, but for backends, you configure authentication in the backend entity itself. The policy authentication-managed-identity is for outbound calls from policies, not for backend authentication.
Confusing client certificate with TLS validation: TLS validation is about verifying the backend's certificate; client certificate is about API Management presenting a certificate to the backend. The exam may ask which certificate to use for mTLS; the answer is client certificate.
Setting circuit breaker in policy instead of backend: Circuit breaker is configured at the backend level, not in policies. Some candidates try to implement it using retry or cache policies, which is incorrect.
Choosing `set-backend-service` with URL parameter instead of `backend-id`: The policy can use either a direct URL or a backend ID. The exam may test that using backend-id is the recommended way for centralized management.
Specific Numbers and Terms
Default circuit breaker request count: 10
Default failure threshold: 50%
Default trip duration: 60 seconds
Backend authentication methods: Basic, API Key, Client Certificate, Managed Identity, OAuth 2.0
Certificate source: Uploaded PFX or Key Vault secret
Policy element: <set-backend-service backend-id="..." />
Edge Cases and Exceptions
When using Key Vault, the certificate must be a secret (not a certificate) because API Management reads it as a secret. The secret must contain the PFX in base64 format.
Circuit breaker only works for HTTP backends, not for logic apps or functions via the built-in connector.
If the backend URL changes, you must update the backend entity; the API policy remains unchanged.
Client certificate authentication requires the backend to be configured to accept client certificates (e.g., in IIS, set sslFlags=32).
How to Eliminate Wrong Answers
If a question mentions 'secure communication with backend requiring certificate', look for client certificate authentication.
If a question says 'change backend URL without modifying API', the answer is to use a backend entity with set-backend-service.
If a question asks about 'preventing overload of backend', think circuit breaker.
If a question involves 'automatically rotate certificate', choose Key Vault integration.
Backends centralize backend configuration, allowing URL changes without modifying API policies.
Client certificate authentication is configured in the backend entity, not via a policy.
Circuit breaker default values: 10 requests, 50% failure threshold, 60-second trip duration.
Certificates can be stored in API Management or referenced from Azure Key Vault as secrets.
The `set-backend-service` policy uses `backend-id` attribute to route requests to a backend.
TLS validation (tls-validate-certificate) is separate from client certificate authentication.
Load balancing supports round-robin and weighted distribution for multiple backend URLs.
These come up on the exam all the time. Here's how to tell them apart.
Backend Configuration with Client Certificate
Requires uploading or referencing a client certificate.
Certificate must be trusted by the backend.
Good for mTLS scenarios.
Certificate rotation requires manual update or Key Vault integration.
Works with any backend that supports client certificate authentication.
Backend Configuration with Managed Identity
Uses Azure AD managed identity; no certificate management.
Backend must support OAuth 2.0 or Azure AD authentication.
Simpler for Azure services that support managed identity (e.g., Azure Functions, App Service).
Automatic credential rotation by Azure AD.
Not suitable for on-premises backends that don't support Azure AD.
Mistake
Client certificate and TLS validation are the same thing.
Correct
Client certificate is used for API Management to authenticate to the backend; TLS validation is the backend's certificate being validated by API Management. They are separate settings. Client certificate is configured in the backend's credentials; TLS validation is a boolean flag (`tls-validate-certificate`).
Mistake
You must add a policy to attach a client certificate to backend requests.
Correct
No, the client certificate is attached automatically by the gateway when the backend is configured with a certificate ID. No additional policy is needed. The policy `authentication-certificate` is used for inline certificate attachment, but for backends, it's handled by the backend configuration.
Mistake
Circuit breaker can be configured using a policy.
Correct
Circuit breaker is a property of the backend entity, not a policy. You set it in the backend's `circuitBreaker` configuration (via portal, ARM, or CLI). There is no `circuit-breaker` policy.
Mistake
You can only upload certificates as PFX files.
Correct
Certificates can be uploaded as PFX files or referenced from Azure Key Vault. Key Vault integration is preferred for automatic rotation and centralized management. The certificate must be stored as a secret in Key Vault.
Mistake
The backend URL must be hardcoded in the API policy.
Correct
You can use a backend entity to centralize the URL. The policy uses `backend-id` to reference the backend, not the URL. This allows you to change the URL in one place without modifying the API definition.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, upload the client certificate to API Management via portal or CLI (`az apim certificate create`). Then, update the backend entity to reference the certificate using its ARM ID in the `credentials.certificate.id` property. The gateway will automatically include this certificate in the TLS handshake when forwarding requests to that backend. Ensure the backend trusts the CA that issued the certificate.
A backend is a configuration entity that defines the target URL, authentication, circuit breaker, and load balancing settings. A policy is a set of rules executed on incoming/outgoing requests. The `set-backend-service` policy references a backend by ID to route requests. Backends centralize configuration; policies are for request/response transformation.
Yes. When creating a certificate in API Management, you can specify a Key Vault secret identifier. The certificate must be stored as a secret (not a certificate) in Key Vault. API Management will fetch the secret and use it as the client certificate. This enables automatic rotation when the secret is updated.
The circuit breaker monitors backend health. It counts requests and failures. When the failure percentage exceeds the threshold (default 50%) after the minimum request count (default 10), the circuit opens. For the trip duration (default 60 seconds), all requests fail fast. After that, a single trial request is allowed; if it succeeds, the circuit closes. This prevents cascading failures.
The default is `true` when you create a backend via CLI or portal. This means API Management validates the backend's SSL certificate. You can set it to `false` to accept self-signed certificates, but this is not recommended for production.
If you have used a backend entity with `set-backend-service` policy referencing the backend ID, you can update the backend's URL via portal, CLI, or ARM. The API policy remains unchanged. For example: `az apim backend update --backend-id mybackend --set url='https://newurl.com/api'`.
Yes. When creating or updating a backend, you can specify multiple URLs under the `url` property as an array. You can also configure load balancing type (round-robin or weighted) and weights. Requests are distributed among the URLs according to the configuration.
You've just covered API Management Backends and Certificates — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?