Mule-Dev-202 · Domain 6 of 8

Mule-Dev-202 Domain 6: Use Anypoint Platform to monitor hyperautomation API endpoints

This small section covers how API Manager governs endpoints with basic or proxy configurations and policies, and how Anypoint Monitoring shows the health of applications and APIs in a hyperautomation solution.

Exam weight estimate
7%
Official objectives estimate
2
Estimated questions estimate
~4
Suggested study time estimate
4–6 hrs

About 11 min read Reviewed October 2026

Overview

Once APIs are deployed, they need to be governed and watched. In API Manager, each managed API instance has an endpoint configuration. With a basic endpoint, the Mule application implementing the API is linked to the API instance through API autodiscovery, and the Mule runtime enforces policies directly. With a proxy endpoint, API Manager deploys a separate proxy application in front of the implementation; policies are enforced on the proxy, which suits implementations that are not Mule applications or cannot be changed. Flex Gateway is MuleSoft's newer gateway for the same goal.

Policies then control access and traffic: client ID enforcement, rate limiting, SLA-based rate limiting, spike control, IP allowlists, JWT validation, OAuth 2.0 token enforcement and header policies. Anypoint Monitoring provides built-in dashboards for application and API metrics such as request volume, response time and errors, custom dashboards, alerts and log search. Together they let a hyperautomation team see when an API that a flow, a Composer flow or a bot depends on is slow or failing.

How it's tested

Questions give an API, its implementation and a governance or visibility requirement, then ask whether to use a basic or proxy endpoint, which policy to apply, or where to look for performance data. The best answer applies governance in API Manager without changing application code unless the scenario requires it.

  • Basic or proxy

    The implementation type and whether it can be modified decide whether to manage it directly or through a proxy.

  • Which policy

    A security or traffic requirement such as identifying consumers or capping calls is given, and you pick the policy.

  • Where is the problem

    An API slows or errors, and you choose the Anypoint Monitoring view, alert or log search that reveals it.

Reasoning it through

A partner's legacy REST service written in Java must be protected with client ID enforcement and rate limiting, and the team cannot change its code. A basic endpoint depends on autodiscovery inside a Mule application, which this service is not. A proxy endpoint deploys a proxy in front of the service, and both policies are applied to the proxy in API Manager without touching the Java code.

Objectives 2

Official objectives from the Salesforce outline, in outline order.

6.1 Using hyperautomation best practices to determine how to manage APIs using basic endpoint configurations, proxy endpoint configurations, and policies.Choosing endpoint configuration and applying API Manager policies.
What it means
API Manager creates an API instance for each managed API. A basic endpoint configuration manages a Mule application directly: the app includes autodiscovery referencing the API instance ID, and the runtime enforces policies. A proxy endpoint configuration places a generated proxy application, deployed through API Manager, between consumers and the implementation, and policies run on the proxy.
What to understand
Choose basic endpoints for Mule implementations you control, since there is no extra hop. Choose a proxy when the implementation is not a Mule app, cannot be modified, or must be shielded behind a separate layer. Policies are applied without code changes and can be combined, for example client ID enforcement with SLA-based rate limiting tiers that give different consumers different quotas.
How it shows up
An implementation type and requirements are described, and you choose the endpoint configuration and the policies.
Common confusion
Rate limiting caps calls per time window for an API; spike control smooths bursts by queuing or rejecting requests above a short-term threshold.
6.2 Describe Anypoint Monitoring for applications and APIs.Dashboards, alerts and logs for deployed applications and APIs.
What it means
Anypoint Monitoring collects metrics from Mule applications and managed APIs and shows them in built-in dashboards covering requests, response times, failures and resource usage. Teams can build custom dashboards, set alerts on thresholds, and search logs to investigate failures, with some advanced features depending on subscription level.
What to understand
Use built-in dashboards for a quick health view, alerts to be notified when response times or error rates cross a threshold, and log search to trace an individual failure. In a hyperautomation chain, monitoring the APIs that flows, Composer and bots call lets the team spot which link is failing before users report it.
How it shows up
Operations needs to be told when an API's error rate rises, and you choose an Anypoint Monitoring alert.
Common confusion
Runtime Manager shows deployment status and basic application details; Anypoint Monitoring provides the detailed metrics, dashboards and alerts.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • API instance

    The managed representation of an API in API Manager, tied to an environment and endpoint configuration.

    Remember
    Policies and contracts attach to API instances.
    Tested as
    Governance scenarios.
    Trap
    Applying policies to the application instead.

  • Basic endpoint

    API Manager manages a Mule implementation directly through autodiscovery.

    Remember
    No extra proxy hop; the app must reference the API instance ID.
    Tested as
    Basic vs. proxy questions.
    Trap
    Choosing it for non-Mule implementations.

  • Proxy endpoint

    API Manager deploys a proxy application in front of the implementation.

    Remember
    Fits non-Mule or unmodifiable backends.
    Tested as
    Basic vs. proxy questions.
    Trap
    Forgetting the proxy must be deployed and maintained.

  • API autodiscovery

    Configuration in a Mule app that links it to an API instance so policies apply.

    Remember
    Without it, a basic endpoint is not enforced.
    Tested as
    Troubleshooting policies that do nothing.
    Trap
    Expecting policies to apply to an app with no autodiscovery.

  • Client ID enforcement

    Requires consumers to send valid client ID and secret from an approved contract.

    Remember
    Identifies who is calling the API.
    Tested as
    Access control scenarios.
    Trap
    Treating it as user authentication.

  • Rate limiting and SLA tiers

    Caps request counts per time window, optionally with tiers per consumer contract.

    Remember
    SLA-based limits need client identification.
    Tested as
    Quota scenarios.
    Trap
    Using spike control for quotas.

  • Spike control

    Protects the backend from short bursts by limiting requests over a small window.

    Remember
    Smooths bursts rather than enforcing long-term quotas.
    Tested as
    Backend protection scenarios.
    Trap
    Using it to bill or meter consumers.

  • IP allowlist and JWT or OAuth policies

    Restrict callers by address or require valid tokens.

    Remember
    Combine with client ID enforcement when needed.
    Tested as
    Security questions.
    Trap
    Relying on network rules alone.

  • Anypoint Monitoring dashboards

    Built-in and custom views of application and API metrics.

    Remember
    First stop for performance trends.
    Tested as
    Visibility questions.
    Trap
    Looking only at Runtime Manager status.

  • Alerts and log search

    Threshold-based notifications and searchable application logs.

    Remember
    Alerts notify proactively; logs explain individual failures.
    Tested as
    Operations scenarios.
    Trap
    Waiting for users to report problems.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Basic endpoint vs. proxy endpoint

ConceptMeaningKey differenceCommon trap
Basic endpoint Manage a Mule app directly Autodiscovery in the app; no extra hop Using it for non-Mule backends
Proxy endpoint Generated proxy in front of the API Works for any HTTP backend without code changes Ignoring the extra deployment to manage

Traffic and access policies

ConceptMeaningKey differenceCommon trap
Client ID enforcement Require registered client credentials Identifies the consuming application Confusing with end-user login
Rate limiting Cap requests per window Same quota for all callers Expecting per-consumer tiers
SLA-based rate limiting Quotas per contract tier Different limits per consumer Applying without client ID
Spike control Absorb short bursts Protects backend capacity Using it as a quota

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Change the code to secure it

    What candidates pick
    Add security logic inside the implementation to check client credentials.
    Why it looks right
    Developers control the code.
    Why it's wrong
    API Manager policies enforce access and traffic rules without code changes and keep governance consistent.

    Clue to watch for The question mentions applying governance quickly or consistently.

  2. Basic endpoint for anything

    What candidates pick
    Manage a third-party Java service with a basic endpoint.
    Why it looks right
    It avoids a proxy hop.
    Why it's wrong
    Basic endpoints rely on autodiscovery in a Mule runtime, which a non-Mule service does not have.

    Clue to watch for The implementation is not a Mule application or cannot be changed.

  3. Spike control as quota

    What candidates pick
    Use spike control to give gold-tier partners more calls per day.
    Why it looks right
    It limits traffic.
    Why it's wrong
    Per-consumer quotas need SLA-based rate limiting with client identification.

    Clue to watch for Different consumers need different limits.

  4. Status page as monitoring

    What candidates pick
    Check that the application shows as started in Runtime Manager.
    Why it looks right
    A running app looks healthy.
    Why it's wrong
    An app can be running while responding slowly or with errors; metrics and alerts reveal that.

    Clue to watch for Users report slow or failing calls while the app is up.

  5. Policy with no effect

    What candidates pick
    Reapply the policy when it is not enforced on a basic endpoint.
    Why it looks right
    It seems like the policy failed to save.
    Why it's wrong
    The usual cause is missing or wrong autodiscovery configuration in the Mule app.

    Clue to watch for The policy is applied but requests still pass unchecked.

Answer framework

Decide governance and visibility in this order when an endpoint question appears.

  1. Check whether the implementation is a Mule application you can modify or another backend you cannot change, such as a legacy service or third-party API.
  2. Use a basic endpoint with autodiscovery for controllable Mule apps and a proxy endpoint for everything else.
  3. Translate the requirement into a policy: client ID enforcement to identify callers, rate limiting to cap usage, SLA tiers for plans, spike control for bursts or OAuth token validation.
  4. Set up Anypoint Monitoring dashboards and alerts on response time and error rate for each API in the chain, so you can see which layer slows or fails first.
  5. Use log search on failing requests to locate the cause before changing configuration or code.

Practice question

A hyperautomation team exposes a Mule application as an API used by Composer flows and RPA bots. Partners must be identified, and each partner tier needs a different daily request limit. What should the team configure in API Manager?

Want more like this? The Mule-Dev-202 practice test has questions for every domain.

Checklist

0 of 10

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

This section is small but precise, so aim for complete recall of a few facts rather than broad reading. In an Anypoint trial, deploy a simple Mule app, create an API instance with a basic endpoint, add autodiscovery, and apply client ID enforcement and rate limiting; call the API with and without credentials to see the policies work. Then create a second instance with a proxy endpoint pointing at a public test API and apply the same policies.

High-priority topics are basic versus proxy, autodiscovery, and the purpose of each common policy. Underestimated areas are the difference between rate limiting and spike control and the role of SLA tiers, which depend on client identification.

For Anypoint Monitoring, open the built-in dashboards for your test app, create one alert and run a log search. Afterwards, write a one-line rule for each policy describing the requirement it answers. That list will answer most questions here in seconds and leave more time for the larger sections.

FAQ

How much of the Mule-Dev-202 exam is Use Anypoint Platform to monitor hyperautomation API endpoints?

This monitoring section is 7% of the exam, the smallest share, or about four of 60 questions as an editorial estimate.

When should I use a proxy endpoint?

When the API implementation is not a Mule application, cannot be modified to add autodiscovery, or should sit behind a separate governance layer.

What is the difference between rate limiting and spike control?

Rate limiting caps the number of requests over a time window. Spike control protects the backend from short bursts by limiting requests over a small interval.

Does Anypoint Monitoring cover APIs as well as applications?

Yes. It provides built-in dashboards for Mule applications and managed APIs, plus custom dashboards, alerts and log search.

Is Flex Gateway on this exam?

The objective names basic and proxy endpoint configurations. Flex Gateway is MuleSoft's newer gateway and is worth recognizing, but the outline does not name it.

How long should I study this section?

Plan about 4 to 6 hours as an editorial estimate, mostly applying policies and reading dashboards in a trial account.

Other CRM & Business Applications certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 6 knowledge

You have covered basic and proxy endpoints, autodiscovery, common policies and Anypoint Monitoring. Check whether you can pick the right policy and endpoint quickly.

Take the Mule-Dev-202 practice test Check your Mule-Dev-202 readiness

Keep going