Design and manage APIs with API Manager and policies
The exam tests how API Manager enforces runtime behavior: API instances, autodiscovery, policy ordering, SLA tiers, and the distinction between similar-looking policies.
Mechanics
An API instance in API Manager is created from an Exchange asset and linked to a running application through autodiscovery using the API ID. Policies are applied to the instance, not to Design Center projects, and execute in order. SLA tiers define client application limits and are consumed by policies such as rate limiting. Client ID enforcement identifies the app; OAuth 2.0 token enforcement validates tokens; JWT validation checks signature, issuer, audience, and expiry. Other common policies include CORS, IP allowlist, message logging, and JSON or XML threat protection.
Policy behavior
Rate limiting caps requests in a window; throttling smooths traffic; spike control absorbs bursts. Authentication should generally run before rate limiting so unauthorized calls do not consume quota. Message logging can expose PII, so scope it carefully.
Worked example
A partner API must allow 100 requests per minute per client with OAuth. Apply OAuth 2.0 token enforcement, then an SLA tier of 100 requests per minute, then threat protection, and disable payload logging. Reasoning: identity first, quota second, and sensitive data last. The tier is attached to the client application, so limits are per consumer.
Traps
Confusing rate limiting with throttling; forgetting autodiscovery so policies never apply; configuring policies in Design Center; assuming an API is protected because it is published; sharing client credentials across partners; leaving message logging on for PII.