Mule-Dev-201 · Domain 12 of 12

Mule-Dev-201 Domain 12: Deploying and Managing APIs and Integrations

The final section moves from Studio to Anypoint Platform: deploying applications to CloudHub, placing APIs under API Manager with a proxy or autodiscovery, and applying policies such as client ID enforcement and SLA-based rate limiting.

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

About 12 min read Reviewed October 2026

Overview

Building a Mule application is only half the job; it then has to run somewhere and be governed as an API. This section covers CloudHub, MuleSoft's managed cloud runtime, and API Manager, which applies policies to APIs without changing their code. Applications are packaged as deployable JAR files and deployed from Anypoint Studio, from Runtime Manager or with the Mule Maven plugin, with environment-specific properties set at deployment.

The exam guide has three objectives: deploy applications to CloudHub; manage APIs using separate proxies and auto-discovery; and manage API policies. Expect questions on the listener settings CloudHub expects, how Runtime Manager properties override values in the application, when to deploy a separate proxy application versus configuring API Autodiscovery in the implementation, and what policies such as client ID enforcement, rate limiting and SLA-based rate limiting do, including what consumers must do to gain access.

How it's tested

Deployment questions describe an application and ask how to configure or deploy it so it runs correctly in CloudHub. API management questions describe a governance requirement, such as securing, throttling or tracking consumers, and ask which approach or policy meets it with the least change to the implementation.

  • Make it run in CloudHub

    An application works locally but not after deployment, and you pick the listener, property or naming fix.

  • Proxy or autodiscovery

    You decide whether to deploy a separate proxy or link the implementation to API Manager with autodiscovery.

  • Pick the policy

    A requirement to identify, throttle or block consumers leads you to the correct API Manager policy and setup.

Reasoning it through

A partner must be limited to 100 calls a minute while internal apps get 1,000, and every caller must be identified. Plain Rate Limiting applies one limit to everyone, so it does not fit. Rate Limiting - SLA Based uses SLA tiers attached to client applications, so the partner requests access in Exchange under a 100-per-minute tier and internal apps use a higher tier. Callers then send their client ID and secret with each request.

Objectives 3

Official objectives from the Salesforce outline, in outline order.

12.1 Deploy applications to CloudHub.Packaging, deployment options, listener settings and properties.
What it means
CloudHub runs Mule applications on MuleSoft-managed infrastructure. You can deploy from Anypoint Studio, by uploading the packaged JAR in Runtime Manager, or with the Mule Maven plugin in a CI/CD pipeline. CloudHub 2.0 runs applications as replicas in shared or private spaces, while CloudHub 1.0 uses workers sized by vCores.
What to understand
Configure the HTTP Listener with host 0.0.0.0 and a port from a property such as ${http.port}; CloudHub expects applications to listen on 8081 for HTTP and routes public traffic to it. Set environment values, such as hosts, credentials and the env property, in Runtime Manager's Properties tab, where they override values packaged in the application, and mark sensitive keys as secure so their values are hidden. Application names must be unique where they form part of the public URL. Use Runtime Manager to view logs, scale replicas or workers and restart the application.
How it shows up
An application fails or misbehaves after deployment, and you choose the configuration change that fixes it.
Common confusion
A hard-coded localhost listener host or port that works in Studio can break a CloudHub deployment.
12.2 Manage APIs using separate proxies and auto-discovery.Linking runtime traffic to an API Manager instance.
What it means
API Manager governs an API instance created from a specification in Exchange. There are two common ways to connect it to traffic: deploy a separate API proxy application, generated by API Manager, that receives requests, applies policies and forwards them to the implementation URL; or configure API Autodiscovery in the implementation itself so the Mule runtime registers with API Manager and enforces policies directly.
What to understand
Autodiscovery needs the API instance ID and a reference to the flow with the HTTP Listener, and the runtime needs the environment's Anypoint Platform client ID and secret so it can register and download policies. Until policies are retrieved, the gatekeeper feature blocks requests, typically with 503. A proxy suits implementations you cannot change or that are not Mule applications, at the cost of another deployment and network hop. Autodiscovery avoids the extra application but requires editing and redeploying the implementation once.
How it shows up
A scenario describes an implementation and constraints, and you choose proxy or autodiscovery and its required settings.
Common confusion
Autodiscovery uses an API instance ID from API Manager, not the Exchange asset ID or the application name.
12.3 Manage API policies.Applying client ID enforcement, rate limiting, SLA tiers and other policies.
What it means
Policies are applied in API Manager to an API instance and enforced at runtime by the proxy or the autodiscovered application, without changing the implementation code. Common policies include Client ID Enforcement, Rate Limiting, Rate Limiting - SLA Based, Spike Control, IP Allowlist, JWT Validation and HTTP Basic Authentication.
What to understand
Client ID Enforcement requires each request to carry a valid client ID and secret, usually as headers or query parameters, from a client application that has an approved contract with the API. Consumers request access from the API's Exchange page, choosing an SLA tier if tiers exist; tiers can be approved automatically or manually. Rate Limiting - SLA Based needs SLA tiers and client identification to apply per-consumer limits, and returns 429 when a limit is exceeded. Plain Rate Limiting applies one limit to all callers.
How it shows up
A governance requirement is described, and you choose the policy and the steps a consumer must take.
Common confusion
SLA-based rate limiting cannot work without client identification, because the tier is attached to the client application.

High-yield concepts

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

  • CloudHub 2.0

    MuleSoft's current managed runtime, running applications as replicas in shared or private spaces.

    Remember
    CloudHub 1.0 uses workers sized by vCores.
    Tested as
    Deployment target questions.
    Trap
    Assuming applications run on your own servers.

  • Listener on CloudHub

    Host 0.0.0.0 and port from ${http.port}, usually 8081.

    Remember
    CloudHub routes public traffic to that port.
    Tested as
    Post-deployment failures.
    Trap
    Hard-coding localhost.

  • Runtime Manager properties

    Values set at deployment that override packaged properties.

    Remember
    Mark sensitive keys secure to hide their values.
    Tested as
    Environment configuration.
    Trap
    Rebuilding the JAR for each environment.

  • Deployable JAR

    Package built from the project, including dependencies, for deployment.

    Remember
    Deploy from Studio, Runtime Manager or the Maven plugin.
    Tested as
    Packaging questions.
    Trap
    Uploading source folders.

  • API instance

    API Manager record for a specific deployment of an API from Exchange.

    Remember
    Policies attach to the instance.
    Tested as
    API management questions.
    Trap
    Applying policies to the Exchange asset itself.

  • API proxy

    Separate application that forwards requests to the implementation and enforces policies.

    Remember
    No change to the implementation.
    Tested as
    Non-Mule or unchangeable backends.
    Trap
    Assuming it is always required.

  • API Autodiscovery

    Configuration linking a Mule application to its API instance by ID and flow.

    Remember
    Needs environment client credentials.
    Tested as
    Avoiding a separate proxy.
    Trap
    Using the wrong identifier.

  • Gatekeeper

    Blocks API traffic until policies have been downloaded.

    Remember
    Requests fail, typically with 503, until the API is ready.
    Tested as
    Unexpected failures right after deployment.
    Trap
    Blaming the implementation logic.

  • Client ID Enforcement

    Policy requiring a valid client ID and secret per request.

    Remember
    Consumers get credentials via an approved contract in Exchange.
    Tested as
    Identifying consumers.
    Trap
    Thinking an Exchange page view grants access.

  • SLA tiers

    Named access levels with request limits attached to client contracts.

    Remember
    Approval can be automatic or manual.
    Tested as
    Per-consumer limits.
    Trap
    Using plain Rate Limiting for per-consumer quotas.

Side by side

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

Proxy vs autodiscovery

ConceptMeaningKey differenceCommon trap
API proxy Separate app in front of the implementation No implementation change; extra hop and deployment Choosing it when a single Mule app was requested
API Autodiscovery Implementation registers with API Manager itself One application; requires config and redeploy once Forgetting platform client credentials

Throttling and access policies

ConceptMeaningKey differenceCommon trap
Client ID Enforcement Requires approved client credentials Identifies who is calling Expecting it to limit request rates
Rate Limiting One request limit for all callers Not tied to consumers Using it for per-partner quotas
Rate Limiting - SLA Based Limits per client by SLA tier Needs tiers and client identification Applying it without client credentials
Spike Control Smooths bursts by delaying or rejecting excess requests Protects backends from short peaks Confusing it with contractual quotas

Exam traps

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

  1. Rebuild per environment

    What candidates pick
    Packaging a separate JAR for each environment.
    Why it looks right
    Configuration often lives inside the project.
    Why it's wrong
    Runtime Manager properties override packaged values, so one artifact can move through environments.

    Clue to watch for The requirement mentions promotion from test to production.

  2. Proxy always needed

    What candidates pick
    Deploying a proxy for every API.
    Why it looks right
    Proxies are the classic way to apply policies.
    Why it's wrong
    Autodiscovery lets a Mule implementation enforce policies itself without another application.

    Clue to watch for The implementation is a Mule app the team can change.

  3. Wrong identifier

    What candidates pick
    Configuring autodiscovery with the application name or asset ID.
    Why it looks right
    Those names are more visible.
    Why it's wrong
    Autodiscovery needs the API instance ID created in API Manager.

    Clue to watch for Options list several different IDs.

  4. Global limit for tiers

    What candidates pick
    Plain Rate Limiting for partner-specific quotas.
    Why it looks right
    It is the simplest throttling policy.
    Why it's wrong
    It applies one limit to everyone; SLA-based limits need tiers and client IDs.

    Clue to watch for Different consumers need different limits.

  5. Exchange view grants access

    What candidates pick
    Assuming consumers can call the API after finding it in Exchange.
    Why it looks right
    Exchange is the discovery portal.
    Why it's wrong
    With client ID enforcement, a client application must have an approved contract and send its credentials.

    Clue to watch for Calls return 401 despite a valid URL.

Answer framework

Use these steps for deployment and API management questions.

  1. Package the application and check its listener uses 0.0.0.0 and a port property compatible with CloudHub.
  2. Move environment-specific values into properties and set or override them in Runtime Manager, marking sensitive keys as secure.
  3. Create an API instance in API Manager from the Exchange specification, then choose a proxy for unchangeable backends or autodiscovery for Mule implementations.
  4. For autodiscovery, configure the API instance ID and listener flow, and provide the environment's platform client credentials to the runtime.
  5. Apply policies to the instance: client ID enforcement to identify callers, SLA tiers for per-consumer limits, and rate limiting or spike control for protection.

Practice question

A team has a Mule 4 API implementation deployed to CloudHub. They want to apply client ID enforcement from API Manager without deploying any additional application. What must they do?

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

Checklist

0 of 11

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

Study strategy

Use a free Anypoint Platform trial account and deploy one of the applications from your earlier labs to CloudHub. Set its listener port from a property, add an environment property in Runtime Manager and confirm the override in the logs. Mark one property as secure and see how it appears in the console.

Then publish the specification to Exchange, create an API instance in API Manager and try both connection approaches: deploy a proxy that points to your application, and configure autodiscovery in the implementation. Apply client ID enforcement, register a client application from Exchange, and call the API with and without credentials. Add SLA tiers and an SLA-based rate limit, and exceed the limit to see the 429 response.

The section is 7%, but the hands-on steps take time to set up, so plan about a week. Keep notes on which IDs and credentials each step needs, because the exam focuses on those details.

FAQ

What weight does Deploying and Managing APIs and Integrations have on Mule-Dev-201?

Deploying and Managing APIs and Integrations is 7% of the exam, about four of the 60 scored questions. It covers CloudHub deployment, proxies and autodiscovery, and API policies.

Should I study CloudHub 1.0 or CloudHub 2.0?

Know both at a high level. The exam guide says deploy to CloudHub without naming a version, and its questions align to the Spring '24 release, when both were in use. Focus on listener settings, properties and Runtime Manager tasks common to both.

When should I use an API proxy instead of autodiscovery?

Use a proxy when you cannot change the implementation or it is not a Mule application. Use autodiscovery when the implementation is a Mule app you can configure and redeploy.

Why do requests fail right after I link an API with autodiscovery?

The gatekeeper blocks traffic until the runtime has registered and downloaded the API's policies. Check that the platform client credentials and API instance ID are correct.

How does a consumer get a client ID and secret?

The consumer registers a client application and requests access to the API from its Exchange page, choosing an SLA tier if tiers exist. After approval, the application's credentials work with the API.

Is Anypoint Flex Gateway on the exam?

Flex Gateway is now a common way to enforce policies, but the objectives name proxies and autodiscovery. Know that Flex Gateway exists and study the named approaches in depth.

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 12 knowledge

You have studied CloudHub deployment, proxies, autodiscovery and API policies. Check whether you can choose the right deployment and policy setup in Mule-Dev-201 questions.

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

Keep going