An XA transaction Is being configured that involves a JMS connector listening for Incoming JMS messages.
What is the meaning of the timeout attribute of the XA transaction, and what happens after the timeout expires?

• A.The time that is allowed to pass between committing the transaction and the completion of the Mule flow After the timeout, flow processing triggers an error
• B.The time that Is allowed to pass between receiving JMS messages on the same JMS connection After the timeout, a new JMS connection Is established
• C.The time that Is allowed to pass without the transaction being ended explicitly After the timeout, the transaction Is forcefully rolled-back
• D.The time that Is allowed to pass for state JMS consumer threads to be destroyed After the timeout, a new JMS consumer thread is created

Correct Answer: C

* Setting a transaction timeout for the Bitronix transaction manager
# Set the transaction timeout either
- In wrapper.conf
- In CloudHub in the Properties tab of the Mule application deployment
# The default is 60 secs. It is defined as
mule.bitronix.transactiontimeout = 120
* This property defines the timeout for each transaction created for this manager.
If the transaction has not terminated before the timeout expires it will be automatically rolled back.
--------------------------------------------------------------------------------------------------------------------- Additional Info around Transaction Management:
Bitronix is available as the XA transaction manager for Mule applications
# To use Bitronix, declare it as a global configuration element in the Mule application
<bti:transaction-manager />
# Each Mule runtime can have only one instance of a Bitronix transaction manager, which is shared by all Mule applications
# For customer-hosted deployments, define the XA transaction manager in a Mule domain
- Then share this global element among all Mule applications in the Mule runtime Graphical user interface, table Description automatically generated with medium confidence

Comment: *

Name: *

Email: *

Verification: *

An organization has several APIs that accept JSON data over HTTP POST. The APIs are all publicly available and are associated with several mobile applications and web applications. The organization does NOT want to use any authentication or compliance policies for these APIs, but at the same time, is worried that some bad actor could send payloads that could somehow compromise the applications or servers running the API implementations. What out-of-the-box Anypoint Platform policy can address exposure to this threat?

• A.Apply a Header injection and removal policy that detects the malicious data before it is used
• B.Apply an IP blacklist policy to all APIs; the blacklist will Include all bad actors
• C.Shut out bad actors by using HTTPS mutual authentication for all API invocations
• D.Apply a JSON threat protection policy to all APIs to detect potential threat vectors

Comment: *

Name: *

Email: *

Verification: *

What API policy would LEAST likely be applied to a Process API?

• A.Custom circuit breaker
• B.Client ID enforcement
• C.Rate limiting
• D.JSON threat protection

Comment: *

Name: *

Email: *

Verification: *

Mule application A receives a request Anypoint MQ message REQU with a payload containing a variable-length list of request objects. Application A uses the For Each scope to split the list into individual objects and sends each object as a message to an Anypoint MQ queue.
Service S listens on that queue, processes each message independently of all other messages, and sends a response message to a response queue.
Application A listens on that response queue and must in turn create and publish a response Anypoint MQ message RESP with a payload containing the list of responses sent by service S in the same order as the request objects originally sent in REQU.
Assume successful response messages are returned by service S for all request messages.
What is required so that application A can ensure that the length and order of the list of objects in RESP and REQU match, while at the same time maximizing message throughput?

• A.Use a Scatter-Gather within the For Each scope to ensure response message order Configure the Scatter-Gather with a persistent object store
• B.Perform all communication involving service S synchronously from within the For Each scope, so objects in RESP are in the exact same order as request objects in REQU
• C.Use an Async scope within the For Each scope and collect response messages in a second For Each scope in the order In which they arrive, then send RESP using this list of responses
• D.Keep track of the list length and all object indices in REQU, both in the For Each scope and in all communication involving service Use persistent storage when creating RESP

Comment: *

Name: *

Email: *

Verification: *

Refer to the exhibit.

A Mule application has an HTTP Listener that accepts HTTP DELETE requests. This Mule application Is deployed to three CloudHub workers under the control of the CloudHub Shared Load Balancer.
A web client makes a sequence of requests to the Mule application's public URL.
How is this sequence of web client requests distributed among the HTTP Listeners running in the three CloudHub workers?

• A.Each request is routed to the PRIMARY CloudHub worker in the PRIMARY Availability Zone (AZ)
• B.Each request is routed to ONE ARBiTRARY CloudHub worker in the PRIMARY Availability Zone (AZ)
• C.Each request Is routed to ONE ARBiTRARY CloudHub worker out of ALL three CloudHub workers
• D.Each request is routed (scattered) to ALL three CloudHub workers at the same time

Comment: *

Name: *

Email: *

Verification: *