Connect to and consume Azure services and third-party services →mediumMultiple ChoiceObjective-mapped

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

Exhibit

Refer to the exhibit.
{
  "type": "Microsoft.ApiManagement/service/apis/operations/policies",
  "apiVersion": "2021-12-01-preview",
  "properties": {
    "value": "<policies>\n  <inbound>\n    <base />\n    <rate-limit calls=\"100\" renewal-period=\"60\" />\n  </inbound>\n</policies>"
  }
}

You deploy the above policy to an Azure API Management API. What is the effect?

⚠ Common exam trap

Watch out — candidates often confuse `rate-limit-by-key` (which resets every renewal period) with `quota-by-key` (which accumulates over a longer period), or they misidentify the counter-key as the client IP address instead of the subscription key.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Limits the API to 100 calls per 60 seconds per subscription key.

The policy shown is a rate-limit policy in Azure API Management that uses the `rate-limit-by-key` element with a `counter-key` attribute set to `@(context.Subscription.Key)`. This limits the number of calls per subscription key, not per IP or backend. The `calls` attribute is set to 100 and the `renewal-period` is 60 seconds, so it enforces 100 calls per 60 seconds per subscription key.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Limits the total bandwidth to 100 MB per 60 seconds.
Why it's wrong here
This statement is incorrect because the `rate-limit` policy in Azure API Management is designed to control the *number of requests* (calls) within a specified time window, not the total volume of data transferred or bandwidth. To manage bandwidth or total data consumption over a longer period, a different policy like `quota` would be more appropriate. The policy's configuration of `calls` and `renewal-period` explicitly targets request frequency.
✗
Limits the API to 100 calls per 60 seconds from the backend.
Why it's wrong here
This statement is incorrect because the policy, when deployed to an API Management API, is typically placed in the `inbound` section of the policy definition. Policies in the `inbound` section execute on requests *from the client* before they are forwarded to the backend service. Therefore, the `rate-limit` policy restricts client requests to API Management, not calls originating from API Management to the backend.
✓
Limits the API to 100 calls per 60 seconds per subscription key.
Why this is correct
This statement is correct. The `rate-limit` policy, when configured without a `by` attribute, defaults to applying the limit based on the subscription key provided in the client request. This means that each unique subscription key is independently allowed to make up to 100 calls within a 60-second period. This behavior ensures fair usage across different consumers of the API.
✗
Limits the API to 100 calls per 60 seconds per client IP address.
Why it's wrong here
This statement is incorrect because, by default, the `rate-limit` policy in Azure API Management applies its limits per subscription key, not per client IP address. While it is possible to configure the policy to limit by IP address by explicitly setting the `by` attribute to `context.Request.Ip`, this is not the default behavior. Without such explicit configuration, the client's IP address is not used for rate limiting.

Go deeper

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question