Salesforce-MuleSoft-Developer-I Practice Test Questions

Explanation

Set Payload sets a literal XML string, not parsed XML.
typeOf(payload) evaluates the payload type at runtime.
The output is serialized as JSON, so the response will be: "String"

Explanation:

In a Mule app, you set the HTTP Listener’s port via the http.port placeholder—here assigned to 9090. Locally or on-premise, this property drives the listener binding. CloudHub, however, ignores mule-app.properties placeholders for internal listener ports unless you override them in the Runtime Manager.

On CloudHub, all HTTP Listeners default to internal port 8081. Incoming traffic on standard port 80 is routed through a load balancer to 8081 inside the worker. This mapping is fixed and does not reflect any placeholder values.

After deployment, the worker logs explicitly report that the HTTP Listener is listening on port 8081, confirming CloudHub’s enforced port configuration and ensuring consistency across all deployed applications.

Incorrect options:

A. Port 80: That’s the external load-balancer port, not the internal listener.
B. Port 9090: Placeholder values aren’t applied for internal ports on CloudHub.
D. Not bound: The listener successfully binds to 8081, so it doesn’t fail.

Explanation:

In MuleSoft, when you use an HTTP Request to call another flow (even within the same app), the call is treated as an external HTTP call — like calling a separate service. As such:

Variables (vars) in the calling flow are preserved after the HTTP Request call completes.
The payload is replaced with the response payload from the called (child) flow.
Attributes (attributes) are replaced with those from the HTTP response, not preserved from before the request.

Incorrect Options Breakdown:

A. The payload and all variables – ❌ Payload is replaced.
C. The entire Mule event – ❌ Attributes and payload are changed.
D. The payload and all attributes – ❌ Payload and attributes change; only vars remain.

Explanation:

When you enable an SLA-based policy in API Manager, the proxy needs to be aware of the subscription credentials (for example, x-sapi-client or your chosen header name) so it can extract and validate them on each request. By updating your RAML to declare these headers, you teach the proxy to expect and forward them under the policy.

Once the RAML is updated, you re-publish (redeploy) the API proxy. The new proxy bundle includes both the header definitions and the SLA policy bindings, so incoming calls carrying those headers are subject to the configured rate limits and quotas.

Incorrect options:

A. Property placeholders aren’t involved in policy enforcement.
B. Env vars won’t inject header expectations into your proxy.
C. Restart alone won’t update the proxy bundle or RAML.

Explanation:

The flow starts with an HTTP GET request to /flights. The Set to XML component hardcodes an XML payload as a string literal (wrapped in quotes). The typeOf(payload) Transform Message then checks the payload's type. Despite the XML-like content, the payload is technically a string because it’s defined as raw text in the set-payload value. Thus, the result is "string" (Option A).

Why Other Options Are Wrong

B ("Java"): Incorrect because typeOf() doesn’t return "Java" for string literals.
C ("object"): The payload isn’t a complex object; it’s a literal string.
D ("XML"): While the content resembles XML, the payload’s data type is string, not parsed XML.

Explanation:

This MuleSoft flow is designed to handle a POST request to /order. When a request is received, it tries to write the incoming JSON payload to a file using the File Write operation. If this write operation fails due to a FILE:CONNECTIVITY error (for example, if the file system is unavailable or the directory is misconfigured), an error mapping is applied. In the file:write component, the error is mapped from FILE:CONNECTIVITY to a custom error type ORDER:NOT_CREATED, which allows the error handling to proceed in a controlled and meaningful way.

On the right side of the diagram, you can see a global error handler with multiple branches. The one for ORDER:NOT_CREATED has an On Error Continue scope, meaning the error is caught and the flow does not fail. Instead, a custom payload of "ORDER:NOT_CREATED" is set. This allows the application to return a meaningful business message to the caller while avoiding a 500 HTTP error response. The HTTP listener is configured to return whatever is in the final payload in plain text.

Since the FILE:CONNECTIVITY error is mapped to ORDER:NOT_CREATED, and this is handled with On Error Continue, the response payload will be the one defined in that scope: "ORDER:NOT_CREATED". This is what the web client receives in response. Other error handlers (like the "OTHER ERROR" with propagate) are ignored because the error is already handled, and the "File written" message is not executed due to the error interrupting the normal flow path.

Incorrect Options:

A. "FILE:CONNECTIVITY" – This is mapped to ORDER:NOT_CREATED, so it's not exposed.
C. "OTHER ERROR" – Not triggered because the error matched and was handled earlier.
D. "File written" – Not reached; flow exited before this due to the file write error.

Explanation:

Design Center’s API Designer lets you build and edit API specifications (RAML/OAS) and reusable fragments, while Flow Designer empowers you to develop Mule applications—all within the browser. But API portals—the developer-facing websites generated from those specs—are stood up and managed in Exchange/API Manager, not in Design Center.

Incorrect options:

• A. Mule Applications: you build these in Flow Designer.
• B. API fragments: defined right in API Designer.
• C. API specifications: authored via API Designer.

Explanation:

In MuleSoft, the Scatter-Gather router is used to invoke multiple routes in parallel and then aggregate their results. The key point is that it waits for all routes to complete before moving forward. So, the total execution time of the Scatter-Gather depends on the longest-running route among its parallel branches. Even if one route finishes quickly, the Scatter-Gather cannot proceed until the slowest one finishes.

In the provided flow, flow1 takes 10 seconds and flow2 takes 20 seconds. Since they run in parallel, both are triggered at the same time. The Scatter-Gather will not complete until both finish — which means it waits for 20 seconds, the time it takes for flow2 to complete. Only after both complete does the flow continue to the next step (Set Payload and Logger).

This timing model is important for performance tuning and understanding parallelism in Mule applications. The Scatter-Gather offers a non-blocking, asynchronous execution model, but the net wait time is governed by the longest running branch. This ensures reliable aggregation of responses from all routes and maintains synchronization before moving to the next stage in the flow.

Incorrect Options:

A. 0 – Not possible; Scatter-Gather must wait for results.
B. 10 – Only one branch; the slower (20s) must also complete.
D. 30 – Routes run in parallel, not sequentially.

Explanation:

In an application network, APIs expose interfaces (contracts) — typically in the form of RAML, OAS (Swagger), or WSDL specs. The implementation is the internal logic that fulfills those contracts.

If the implementation changes (e.g. performance improvements, new database queries, refactoring code), but the interface stays the same (same request/response shape, same endpoints, same data formats), consumers of that API do not need to change anything.

So:

No need to restart consuming applications (A is wrong)
No need to recode consuming applications (B is wrong)
No need to update the other APIs (C is wrong)

As long as the contract hasn’t changed, consumers remain unaffected. This is the core principle of loose coupling in API-led connectivity.

Explanation:

Since the legacy client only consumes SOAP web services, the correct interface documentation format is a WSDL (Web Services Description Language) file. WSDL is the standard XML-based format for describing SOAP-based services, including operations, endpoints, and message structures. This ensures compatibility with legacy SOAP clients (Option B).

Why Other Options Are Wrong

A (RAML): RAML defines RESTful APIs, not SOAP services.
C (JSON): JSON is used for REST APIs or data exchange, not SOAP.
D (Plain text): Informal and non-standard; SOAP requires structured WSDL.