Design infrastructure solutions · Topic 4 of 10
API Integration, Caching and Configuration
AZ-305 application services: Azure API Management tiers and policies, Azure Managed Redis caching patterns, and App Configuration with feature flags.
- 6 min
- APIM tiers: Consumption (serverless), Developer (no SLA), Basic and Standard, Premium (multi region and zones), plus v2 tiers. Multi region is classic Premium only.
- A self hosted gateway runs APIM's gateway on premises or elsewhere, managed from Azure.
- Azure Managed Redis replaces Azure Cache for Redis, which retires in 2028 (Enterprise in 2027).
What it is
Three supporting services appear in most application designs. Azure API Management (APIM) publishes, secures and governs APIs. A cache such as Azure Managed Redis stores hot data in memory to cut latency and database load. Azure App Configuration holds settings and feature flags outside the code, so you can change behaviour without redeploying.
How it works
Azure API Management
APIM is a gateway, management plane and developer portal. It applies policies (authentication, rate limits, transformation, caching, validation) between clients and backends such as App Service, Functions, Logic Apps and on premises APIs.
| Tier family | Notes |
|---|---|
| Consumption | Serverless, pay per call, no fixed cost. Cannot move to or from other tiers. Smaller policy size limit |
| Developer | Non production. No SLA and cannot scale |
| Basic, Standard | Classic production tiers. No availability zones |
| Premium | Enterprise: multi region deployment, availability zones, VNet injection for private backends, many self hosted gateways |
| Basic v2, Standard v2, Premium v2 | Newer tiers. Standard v2 supports network isolated backends, Premium v2 adds full network isolation and zones. Multi region is still classic Premium only, and v2 is for new instances |
Key capabilities:
- Policies:
rate-limitandquotafor throttling,validate-jwtfor Entra token validation,set-headerandrewrite-urifor transformation,cache-lookupandcache-storefor response caching,validate-contentfor schema checks. - Products and subscriptions control who can call which APIs, with subscription keys and OAuth.
- Developer portal for documentation and self service sign up.
- Self hosted gateway: a container that runs the gateway on premises or in other clouds while being managed from Azure. It needs outbound HTTPS to Azure. Premium allows many gateways. Some policies are not supported on it, and rate limit counts sync only among its own instances.
- Backend protection: place Application Gateway with WAF in front, restrict backends to accept traffic only from APIM, and use managed identity to call backends.
- Versions and revisions manage API change safely.
Choose APIM when the requirement is a single, governed entry point for many APIs with throttling, authentication and analytics. Choose a simple gateway (App Gateway or Front Door) when you only need load balancing and WAF.
Caching
Caching speeds reads and protects databases.
| Option | Use |
|---|---|
| Azure Managed Redis | The recommended managed Redis on Redis Enterprise software: memory optimised, balanced and compute optimised SKUs, clustering, zone redundancy on by default, active geo replication, persistence and modules, Redis 7.4 |
| Azure Cache for Redis (Basic, Standard, Premium) | The older service. Retiring September 30, 2028 (Enterprise tiers March 31, 2027). New customers cannot create Basic, Standard or Premium caches. Move to Managed Redis |
| Azure Front Door and CDN | Cache static and cacheable web content at the edge |
| APIM response cache | Cache API responses with policies |
| Output and in memory caches in the app | Local, per instance |
Common patterns: cache aside (the app checks the cache, loads from the database on a miss and stores the result), session state in Redis for stateless web tiers, leaderboards and counters with Redis data structures, and Pub/Sub messaging. Set sensible time to live (TTL) and eviction. Managed Redis differs from the older service: it has no virtual network injection (use Private Link), no keyspace notifications or Entra RBAC at launch, and uses TLS or non TLS chosen at creation. Size up to allow for overhead, and migrate with a dual write approach.
App Configuration and feature flags
Azure App Configuration is a managed store for key values and feature flags.
| Capability | Detail |
|---|---|
| Central settings | One place for settings shared across services, with labels per environment, snapshots and point in time history |
| Feature flags | Turn features on or off, or roll them out gradually without a deployment. Built in time window and targeting filters, plus variants for experiments |
| Dynamic refresh | Apps poll for changes (default about 30 seconds), so settings update without restarts |
| Secrets | Store Key Vault references, not secret values |
| Security | Entra ID and managed identities are recommended over connection strings, private endpoints, customer managed keys |
| Geo replication | Replicas for availability and read latency |
Rules of thumb: put secrets in Key Vault and settings and flags in App Configuration. Use feature flags for canary releases, kill switches and A/B tests. Each feature flag is limited in size, so use groups for target audiences. Standard and Premium tiers have request quotas, so tune the refresh interval.
Choosing quickly
| Requirement | Answer |
|---|---|
| Publish many APIs with throttling, JWT validation and a developer portal | Azure API Management |
| Keep APIM reachable to partners but backends private | Premium or Standard v2 with network isolation, backends restricted to APIM |
| Manage APIs running on premises from Azure | An APIM self hosted gateway |
| Reduce database reads for hot data | Azure Managed Redis with cache aside |
| Roll out a feature to 10 percent of users, no redeploy | App Configuration feature flag with a targeting filter |
| Store a database password | Key Vault (not App Configuration) |
A worked scenario
A fintech exposes 30 microservice APIs to partners and mobile apps. The architect fronts them with API Management (Premium) in two regions across zones, applying validate-jwt, rate-limit per subscription and response caching. Hot account data sits in Azure Managed Redis using cache aside. Settings and feature flags live in App Configuration, with a targeting filter for a 10 percent canary of a new payments screen, and secrets referenced from Key Vault.
What to remember for the exam
- APIM tiers: Consumption (serverless), Developer (no SLA), Basic and Standard, Premium (multi region and zones), plus v2 tiers. Multi region is classic Premium only.
- A self hosted gateway runs APIM's gateway on premises or elsewhere, managed from Azure.
- Azure Managed Redis replaces Azure Cache for Redis, which retires in 2028 (Enterprise in 2027).
- Cache aside is the standard caching pattern. Choose a TTL.
- App Configuration holds settings and feature flags. Secrets belong in Key Vault.
A phrase like "change behaviour without redeploying" is a feature flag. "Throttle and authenticate APIs centrally" is API Management.
How the exam asks about this
- "Apply rate limits and validate tokens for all APIs." API Management policies.
- "Run the gateway close to on premises APIs." A self hosted gateway.
- "Speed up reads of rarely changing data." A Redis cache using cache aside.
- "Turn a feature on for a subset of users with no deployment." An App Configuration feature flag.
Common mistakes
Using the retiring Redis tiers for new designs. Use Managed Redis.
Storing secrets in App Configuration. Use Key Vault.
Expecting multi region APIM on v2 tiers.
No TTL on cached data.
Check yourself
Which APIM tier supports multi region deployment?
Classic Premium.
What replaces Azure Cache for Redis?
Azure Managed Redis.
Where should secrets be stored, not App Configuration?
Azure Key Vault.
Topic 4 of 10 in Design infrastructure solutions
Test yourself on Design infrastructure solutions
The full Microsoft AZ-305 question bank has 755 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.