This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for application platform services
      --> Implement security policies for back-end API protection by using API Management

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

APIs are a critical part of modern cloud applications. They allow web applications, mobile applications, business systems, AI applications, and other services to communicate with back-end resources.

However, exposing an API creates a significant security responsibility. Organizations must control:

• Who can call an API
• How callers authenticate
• What callers are authorized to do
• How frequently APIs can be called
• Where requests originate
• What traffic is allowed to reach back-end services
• How API credentials are protected
• How connections between API Management and back-end services are secured
• How potentially malicious or malformed requests are handled

Azure API Management (APIM) provides an API gateway that can enforce security policies between API consumers and back-end APIs.

The SC-500 exam specifically expects knowledge of securing back-end APIs with API Management, including subscription keys, JWT validation, OAuth 2.0, IP filtering, rate limiting, virtual network integration, and mutual TLS (mTLS).

A useful way to think about API Management security is:

                    API Consumer
                         |
                         v
              +---------------------+
              | Azure API Management|
              |       Gateway       |
              +---------------------+
                 |       |       |
          Authentication  |   Network
          Authorization   |   Controls
                 |        |
                 v        v
             Policies   Filtering
                 |
                 v
              Backend API

API Management policies execute in the gateway and can inspect, validate, transform, route, and control API requests and responses. Microsoft currently provides more than 75 built-in policies covering scenarios such as authentication, rate limiting, filtering, transformation, and validation.

1. Understanding the API Management Security Model

API Management sits between the API consumer and the back-end API.

Without API Management:

Client
   |
   v
Backend API

With API Management:

Client
   |
   v
Azure API Management
   |
   |-- Authenticate
   |-- Authorize
   |-- Validate
   |-- Rate limit
   |-- Filter IPs
   |-- Transform
   |-- Log/monitor
   |
   v
Backend API

This creates a centralized enforcement point.

Instead of implementing every security control independently inside every API, organizations can implement common controls at the API gateway.

Important distinction

API Management policies are runtime API policies.

They should not be confused with Azure Policy.

Microsoft specifically distinguishes API Management policies from Azure Policy: APIM policies execute in the gateway, while Azure Policy evaluates and enforces compliance for Azure resources.

2. API Management Policy Scopes

Policies can be applied at different levels.

Common scopes include:

• Global/API Management instance
• Product
• API
• Operation

This allows security controls to be applied broadly or narrowly.

For example:

API Management
      |
      +-- Global policy
      |
      +-- Product policy
      |
      +-- API policy
              |
              +-- Operation policy

Why scope matters

Suppose every API requires a particular security header.

A global policy may make sense.

Suppose only the /payments API requires a particular JWT claim.

An API-level policy may be more appropriate.

Suppose only POST /payments requires an additional validation rule.

An operation-level policy may be appropriate.

Best practice

Apply security controls at the narrowest practical scope when the requirement is specific to a particular API or operation, while using broader scopes for controls that should consistently apply across the environment.

3. Subscription Keys

Azure API Management supports subscription keys as a mechanism for controlling access to APIs.

A subscription represents a relationship between an API consumer and one or more APIs or products.

The consumer can provide a subscription key with an API request.

Conceptually:

Client
   |
   | Subscription key
   v
API Management
   |
   | Validate subscription
   v
Backend API

Subscription keys provide a way to identify and control API consumers.

They can also be useful for:

• Tracking API consumption
• Managing subscriptions
• Applying quotas or rate limits
• Controlling access to products/APIs

Important exam distinction

A subscription key should not automatically be considered equivalent to strong user authentication.

A subscription key primarily identifies an API subscription.

It does not inherently prove the identity of an individual user in the same way that a Microsoft Entra access token can.

For applications requiring user or workload identity, OAuth 2.0 and JWT validation may be more appropriate.

4. Subscription Keys and Products

API Management products provide an important organizational mechanism for grouping APIs and managing consumer access.

For example:

Product: Customer APIs
       |
       +-- Customer API
       +-- Orders API
       +-- Account API

A subscription can provide access to a product.

This makes it possible to manage access to groups of APIs rather than independently configuring every API consumer for every individual API.

Example

A company might create:

Internal APIs

• Employee API
• HR API
• Finance API

Partner APIs

• Orders API
• Inventory API
• Shipping API

Different consumers can receive different subscriptions and access different products.

5. JWT-Based Authentication

JSON Web Tokens, or JWTs, are commonly used to authenticate API callers.

A JWT can contain claims about:

• The caller
• The issuer
• The intended audience
• Expiration
• Permissions or scopes
• Other identity information

A typical flow is:

Client
   |
   | Authorization: Bearer <JWT>
   v
API Management
   |
   | Validate JWT
   |
   +---- Invalid ----> Reject
   |
   +---- Valid ------> Backend API

API Management provides a validate-jwt policy that can validate JWT tokens. The policy can verify aspects such as token issuer, audience, signature, expiration, and claims depending on its configuration.

6. Validate JWT Policy

The validate-jwt policy is one of the most important policies for SC-500.

A simplified policy looks conceptually like:

<validate-jwt header-name="Authorization"
              require-scheme="Bearer">
    ...
</validate-jwt>

The actual configuration must specify the appropriate issuer/signing keys/audience and other requirements for the identity provider and API.

The policy can validate that:

• A token exists
• The token is properly signed
• The token was issued by an expected issuer
• The token is intended for the expected audience
• The token has not expired
• Required claims are present

Why audience matters

Consider a token issued for:

Audience = API-A

An attacker attempts to use that token against:

API-B

If API-B validates the audience correctly, it can reject the token.

This is an important security control.

7. Microsoft Entra ID and JWT Validation

Microsoft Entra ID is frequently used as the identity provider for API authentication.

The flow can look like:

User/Application
       |
       | Authenticate
       v
Microsoft Entra ID
       |
       | Access token
       v
API Management
       |
       | Validate JWT
       v
Backend API

API Management can validate Microsoft Entra-issued tokens using JWT validation policies. Current API Management policy support includes a dedicated validate Microsoft Entra token policy as well as the general JWT validation policy.

Exam concept

If the question asks:

“How can API Management verify that an incoming request contains a valid Microsoft Entra access token?”

Think:

JWT/token validation policy.

8. Claims-Based Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

JWT claims can help API Management enforce authorization requirements.

For example, an API may require:

scope = Orders.Read

A more privileged API may require:

scope = Orders.Write

API Management can inspect token claims and reject requests that do not satisfy the required conditions.

This allows security decisions to occur before the request reaches the backend.

9. OAuth 2.0

OAuth 2.0 provides a standardized framework for delegated authorization.

A simplified flow is:

Client
   |
   | Request authorization
   v
Identity Provider
   |
   | Access token
   v
Client
   |
   | Bearer token
   v
API Management
   |
   | Validate
   v
Backend API

API Management can be configured to work with OAuth 2.0 authorization servers, including Microsoft Entra ID. Microsoft currently recommends the Microsoft identity platform v2 endpoint for OAuth scenarios where applicable.

OAuth vs subscription key

10. OAuth 2.0 for Backend APIs

API Management can also help manage credentials and authorization for calls from API Management to backend services.

This is an important distinction.

There are potentially two authentication relationships:

Consumer
   |
   | Authenticate
   v
API Management
   |
   | Authenticate
   v
Backend API

The authentication method used by the consumer does not necessarily have to be the same authentication method used by API Management when it calls the backend.

API Management’s current credential manager can manage OAuth 2.0 connections to backend APIs and can acquire, cache, and refresh tokens for supported scenarios.

11. Managed Identity for Backend Authentication

API Management can authenticate to supported backend services using a managed identity.

This can reduce the need to store credentials such as:

• Client secrets
• Passwords
• Long-lived access tokens

Conceptually:

API Management
       |
       | Managed identity
       v
Azure Resource / Backend

The API Management policy reference currently includes an authenticate with managed identity policy for authenticating to backend services.

Why this is important

Managed identity follows the principle:

Don’t store a secret when Azure can provide an identity.

It is therefore generally preferable to hard-coded credentials.

12. IP Filtering

API Management can restrict API access based on the caller’s IP address.

For example:

Corporate network
10.20.0.0/16
       |
       v
API Management
       |
       +---- Allow

And:

Unknown source
203.0.113.0/24
       |
       v
API Management
       |
       +---- Deny

API Management provides a policy to restrict callers by IP address or IP address range.

When IP filtering is useful

It can be appropriate for:

• Internal APIs
• Partner APIs
• Administrative APIs
• Known integration platforms
• Restricted enterprise networks

Important limitation

IP filtering should not be treated as a replacement for authentication.

An IP address identifies a network source, not necessarily an individual user.

13. Rate Limiting

An API can become unavailable or expensive when clients send excessive requests.

API Management can apply rate limiting policies.

For example:

Client
  |
  | 100 requests
  |-------------------->
  |
API Management
  |
  | Threshold = 50
  |
  +---- Additional requests rejected

Rate limiting can protect:

• Application capacity
• Backend systems
• APIs with expensive operations
• Shared services
• APIs susceptible to abuse

API Management policies include rate-limiting capabilities for controlling incoming calls.

14. Rate Limiting vs Quotas

Rate limiting and quotas are related but different concepts.

Rate limiting

Controls how many requests can occur during a relatively short period.

Example:

No more than 100 calls per minute.

Quota

Controls consumption over a longer period.

Example:

No more than 100,000 calls per month.

Conceptually:

Rate limit:
100 calls / minute
Quota:
100,000 calls / month

Exam tip

If the scenario describes burst/excessive requests over a short period, think rate limiting.

If it describes total consumption over a longer period, think quota.

15. IP Filtering + Rate Limiting

Security policies can be combined.

For example:

Incoming request
       |
       v
IP filter
       |
       +---- Unauthorized source --> Reject
       |
       v
JWT validation
       |
       +---- Invalid token -------> Reject
       |
       v
Rate limit
       |
       +---- Too many requests ---> Reject
       |
       v
Backend API

This is an example of defense in depth.

No single policy has to solve every security problem.

16. Request and Response Validation

API Management can validate request and response content.

The validate-content policy can validate the size and/or content of request or response bodies against supported schemas, including JSON and XML.

This can help prevent unexpected or malformed content from reaching an API.

For example:

Client
   |
   | JSON request
   v
API Management
   |
   | Validate schema
   |
   +---- Invalid --> Reject
   |
   v
Backend API

This is particularly useful for APIs with strict data contracts.

17. Mutual TLS (mTLS)

Mutual TLS, or mTLS, provides certificate-based authentication between communicating parties.

With normal TLS:

Client  <---- TLS ---->  Server

The server proves its identity to the client.

With mTLS:

Client  <---- Mutual TLS ---->  Server
   |                            |
   +-- Client certificate       |
                                |
                    Server certificate

Both sides authenticate using certificates.

API Management supports policies for validating client certificates and authenticating to backend services using client certificates.

18. mTLS for Backend APIs

One particularly important use case is securing the connection between API Management and a backend API.

For example:

API Consumer
      |
      | HTTPS
      v
API Management
      |
      | mTLS
      v
Secure Backend API

The backend can require API Management to present a client certificate.

API Management supports an authentication-certificate policy for authenticating with a backend service using a client certificate.

When to use mTLS

mTLS is particularly appropriate when:

• A backend requires certificate-based client authentication.
• Strong machine-to-machine authentication is required.
• An organization operates partner APIs requiring certificates.
• Traditional API keys are insufficient.
• The environment has established PKI infrastructure.

19. Network Security for API Management

API-level policies are only one layer of security.

API Management can also be integrated with Azure networking capabilities.

Current API Management networking options include:

• Virtual network injection
• Virtual network integration
• Inbound private endpoints
• Private Link
• Network security controls

The exact capabilities depend on the API Management tier.

20. Virtual Network Integration

Virtual network integration can allow API Management to make outbound requests to APIs hosted in a connected virtual network.

For example:

                    Azure VNet
             +----------------------+
             |                      |
API Management -----> Private API   |
             |                      |
             +----------------------+

For current Standard v2 and Premium v2 configurations, virtual network integration supports outbound connectivity to APIs isolated in a connected or peered virtual network. However, this configuration does not by itself make the API Management gateway private; the gateway and developer portal remain publicly accessible unless additional controls are configured.

Exam trap

Do not assume:

VNet integration = private inbound API Management endpoint.

VNet integration in these v2 scenarios primarily provides outbound connectivity.

21. Inbound Private Endpoint

An inbound private endpoint provides private connectivity to the API Management instance.

Conceptually:

Private Client
      |
      v
Private Endpoint
      |
      v
Azure API Management
      |
      v
Backend API

The private endpoint receives an IP address from the virtual network.

Traffic can then travel through Azure Private Link rather than being exposed through the public internet.

Microsoft’s current documentation states that the inbound private endpoint is for inbound traffic and that public network access can be disabled after configuring a private endpoint.

Important distinction

This distinction is highly relevant for exam questions.

22. Virtual Network Injection

Some API Management tiers support virtual network injection.

In this architecture, the API Management instance can be deployed into a delegated subnet.

For supported configurations, this can provide stronger network isolation for the API Management gateway and its backend connectivity.

The current Premium v2 documentation describes virtual network injection as providing both inbound and outbound network connectivity through the virtual network and is intended for scenarios where both the API Management instance and backend APIs need isolation.

Exam concept

When a scenario emphasizes:

“Isolate the API Management instance itself inside a private network.”

Think about virtual network injection/private networking, depending on the APIM tier and architecture.

23. Securing the Backend

Securing API Management does not automatically secure the backend API.

Consider:

Internet
   |
   v
API Management
   |
   v
Backend API

The backend should also be protected.

Potential controls include:

• Private networking
• Authentication
• Managed identity
• mTLS
• IP restrictions
• Network security groups where applicable
• Firewall controls
• Private endpoints
• Network security perimeter capabilities where appropriate

The objective should be to ensure that the backend accepts traffic from legitimate API Management paths rather than becoming an independent publicly exposed API.

24. API Management as a Security Gateway

A mature architecture often uses APIM as the central policy enforcement point.

For example:

                       Clients
                          |
             +------------+------------+
             |            |            |
          Web App      Mobile App    Partner
             |            |            |
             +------------+------------+
                          |
                          v
               +---------------------+
               | Azure API Management|
               |                     |
               | Subscription keys   |
               | JWT validation      |
               | OAuth 2.0           |
               | IP filtering        |
               | Rate limiting       |
               | Content validation  |
               | mTLS                |
               +---------------------+
                          |
                          v
                 Private Backend APIs

This architecture centralizes common security requirements.

25. AI APIs and API Management

API Management can also be used as a security and governance layer for AI model endpoints.

This is increasingly important because AI applications often expose APIs to:

• Language models
• AI agents
• AI applications
• Retrieval systems
• External consumers
• Internal applications

The current SC-500 learning module explicitly includes AI Gateway capabilities for securing and governing AI model endpoints.

This extends the API gateway concept beyond traditional REST APIs.

An AI gateway can help organizations apply centralized policies to AI traffic, such as:

• Authentication
• Authorization
• Rate limiting
• Content controls
• Usage governance
• Monitoring

26. AI Gateway and Content Safety

API Management’s current policy framework includes AI-specific capabilities, including enforcing content-safety checks on LLM requests by sending prompts to Azure AI Content Safety before they are sent to the backend LLM.

Conceptually:

AI Application
      |
      v
API Management AI Gateway
      |
      +---- Authentication
      |
      +---- Rate limiting
      |
      +---- Content safety
      |
      +---- Governance
      |
      v
LLM / AI Backend

This is particularly relevant to the evolving SC-500 emphasis on securing cloud and AI workloads.

27. A Layered API Security Model

A useful way to remember the complete approach is to divide security into layers.

No single control is sufficient for every API.

28. Example: Secure a Partner API

Consider a company exposing an Orders API to a business partner.

Requirements:

• Only the partner can access the API.
• Requests must contain valid Microsoft Entra tokens.
• The partner’s network has known IP ranges.
• Excessive API requests must be limited.
• The backend must not be publicly exposed.
• API Management must authenticate to the backend.

A possible design is:

Partner
   |
   | Microsoft Entra token
   v
API Management
   |
   +-- Validate JWT
   |
   +-- IP filtering
   |
   +-- Rate limiting
   |
   +-- Subscription management
   |
   v
Private Backend
   ^
   |
Managed Identity

This provides multiple independent controls.

If an attacker obtains an IP address within an allowed range but lacks a valid token, JWT validation can reject the request.

If a legitimate partner begins sending excessive traffic, rate limiting can protect the backend.

If the backend is private, network controls can prevent direct public access.

29. Example: Secure a Machine-to-Machine API

Suppose an enterprise application calls a sensitive internal API.

Requirements:

• No interactive user sign-in
• Strong workload identity
• Private network connectivity
• Certificate-based backend authentication

A suitable architecture could use:

Enterprise Application
        |
        | Token / approved authentication
        v
API Management
        |
        | Private network
        |
        | mTLS
        v
Internal Backend

The exact combination depends on the identity architecture, but the key concept is that machine identity, network isolation, and certificate authentication solve different security problems.

30. Common API Management Security Mistakes

Mistake 1: Treating a subscription key as complete authentication

A subscription key identifies API subscription access but should not automatically be treated as equivalent to strong user or workload identity.

Better: Use OAuth 2.0/JWT validation when identity and claims-based authorization are required.

Mistake 2: Using IP filtering instead of authentication

An IP address does not establish who the caller is.

Better: Combine IP filtering with strong authentication where appropriate.

Mistake 3: Confusing VNet integration with a private inbound gateway

In current v2 configurations, VNet integration primarily enables outbound connectivity to private backends while the gateway remains publicly accessible.

Better: Use the appropriate private endpoint or VNet injection architecture when private inbound access is required.

Mistake 4: Exposing the backend publicly

Putting API Management in front of an API does not automatically make the backend private.

Better: Restrict backend access and use private networking where appropriate.

Mistake 5: Hard-coding backend secrets

Storing long-lived credentials in application configuration increases security risk.

Better: Prefer managed identity or appropriate secure credential-management mechanisms.

Mistake 6: Applying rate limiting only inside application code

Application-level rate limiting may require every API to independently implement and maintain the same logic.

Better: Use API Management policies for centralized API traffic controls.

Mistake 7: Using broad policies when narrow policies are sufficient

A global security rule can unintentionally affect APIs that do not require it.

Better: Choose the appropriate policy scope.

31. API Management Security Decision Matrix

32. SC-500 Exam-Focused Comparison

Several capabilities can look similar in scenario questions.

33. Key Takeaways

For SC-500, remember these principles:

1. API Management is a centralized API gateway and policy enforcement point.
2. Subscription keys provide subscription-based API access and identification.
3. JWT validation verifies access tokens and their claims.
4. OAuth 2.0 provides a standardized authorization framework.
5. Microsoft Entra ID can be used as the identity provider for OAuth/JWT scenarios.
6. IP filtering controls where API requests originate.
7. Rate limiting controls excessive short-term request activity.
8. Quotas control longer-term API consumption.
9. Managed identity can authenticate API Management to supported backend resources without storing credentials.
10. mTLS provides certificate-based authentication between communicating parties.
11. Content validation can reject requests or responses that do not conform to expected schemas or size requirements.
12. VNet integration and private endpoints solve different networking problems.
13. An inbound private endpoint provides private access to the API Management gateway.
14. VNet integration in current v2 tiers primarily enables outbound access to private backends; it does not automatically make the gateway private.
15. AI Gateway extends API Management security and governance to AI model endpoints.
16. Security controls should be layered rather than relying on one mechanism.

Practice Exam Questions

Question 1

A company exposes several APIs through Azure API Management. The company wants to identify API consumers and control which APIs they can access through an API subscription.

Which capability should the security engineer configure?

A. Azure Private Endpoint

B. Subscription keys

C. Client certificates

D. IP filtering

Answer: B

Explanation

Subscription keys are designed to provide subscription-based access to APIs and identify API consumers within the API Management subscription model.

Private endpoints address network connectivity, client certificates provide certificate-based authentication, and IP filtering restricts traffic based on source IP addresses.

Question 2

An organization exposes a sensitive API through API Management. The API should accept requests only when the caller presents a valid Microsoft Entra access token intended for the API and containing the required claims.

Which capability should be implemented?

A. Rate limiting

B. Subscription key validation only

C. IP filtering

D. JWT/token validation

Answer: D

Explanation

A JWT validation policy can validate the access token’s signature, issuer, audience, expiration, and required claims according to the configured policy.

A subscription key alone does not provide equivalent identity and claims-based authorization.

Question 3

An API Management instance must call an Azure backend service. The security team does not want to store a client secret or password in the API configuration.

Which authentication mechanism is most appropriate?

A. Managed identity

B. IP filtering

C. Subscription key

D. Anonymous access

Answer: A

Explanation

A managed identity allows API Management to authenticate to supported Azure resources without storing a long-lived credential in the application or API policy.

This supports a secretless authentication model and aligns with least-credential principles.

Question 4

A public API is being abused by a client that sends thousands of requests within a short period. The organization wants API Management to automatically restrict the number of requests the client can make during a defined interval.

Which capability should be used?

A. OAuth 2.0

B. mTLS

C. Rate limiting

D. Private endpoint

Answer: C

Explanation

Rate limiting is designed to control the number of calls received during a defined period.

OAuth 2.0 addresses authorization, mTLS provides certificate-based authentication, and private endpoints address network connectivity.

Question 5

An organization has API Management integrated with a virtual network. The API Management instance must call an API hosted on a private subnet. However, the security team also wants API consumers to continue reaching the API Management gateway through its public endpoint.

Which capability best satisfies the networking requirement?

A. Disable all public access to API Management

B. Configure outbound virtual network integration

C. Configure an API subscription key

D. Configure JWT validation

Answer: B

Explanation

Current Standard v2 and Premium v2 API Management configurations support virtual network integration for outbound requests to APIs isolated within a connected or peered virtual network.

Importantly, this does not by itself make the API Management gateway private; its gateway and developer portal can remain publicly accessible.

Question 6

A company wants only clients from a set of known corporate IP ranges to call a particular API through API Management.

Which policy should the security engineer use?

A. IP filtering

B. JWT validation

C. Content validation

D. Managed identity

Answer: A

Explanation

The API Management IP filtering capability can allow or deny calls based on specific IP addresses or address ranges.

However, IP filtering should generally complement rather than replace strong authentication.

Question 7

A company requires API Management to authenticate to a highly sensitive partner backend using a client certificate. The partner will reject requests unless API Management presents the expected certificate.

Which capability should be configured?

A. Subscription key

B. Rate limiting

C. OAuth authorization code

D. Client certificate authentication/mTLS

Answer: D

Explanation

mTLS/client certificate authentication is appropriate when a backend requires certificate-based authentication from API Management.

API Management provides an authentication-certificate policy for authenticating with a backend using a client certificate.

Question 8

A security engineer wants API Management to reject requests whose JSON body does not conform to the API’s expected schema.

Which capability should be used?

A. IP filtering

B. Subscription key validation

C. Content validation

D. Private endpoint

Answer: C

Explanation

The validate-content policy can validate the size and/or content of request or response bodies against supported schemas, including JSON and XML.

The other options address identity, network access, or subscription management.

Question 9

A company wants clients inside its private Azure network to connect to an API Management gateway without exposing the gateway through the public internet. The organization also wants to disable public network access to the API Management instance.

Which solution is most appropriate?

A. Inbound private endpoint

B. Rate limiting

C. Subscription key

D. JWT validation

Answer: A

Explanation

An inbound private endpoint provides private connectivity to the API Management instance using Azure Private Link and a private IP address from the virtual network.

Current API Management documentation states that public network access can be disabled after configuring an inbound private endpoint.

Question 10

A company is building an AI application that accesses an LLM through Azure API Management. The security team wants a centralized gateway that can apply authentication, traffic controls, and AI-specific protections before requests reach the model endpoint.

Which capability is most appropriate?

A. Azure Bastion

B. AI Gateway capabilities in API Management

C. Azure Network Security Group only

D. Azure Private DNS

Answer: B

Explanation

API Management’s AI Gateway capabilities extend gateway security and governance to AI model endpoints. Current policy capabilities include AI-specific controls such as content-safety checks for LLM requests, in addition to traditional API controls such as authentication and rate limiting.

Azure Bastion is designed for secure VM administration, NSGs provide network-level filtering, and Private DNS provides name resolution rather than centralized AI API governance.

Go to the SC-500 Exam Prep Hub main page