Refer to the exhibit.

One of the backend systems invoked by an API implementation enforces rate limits on the number of requests a particular client can make. Both the backend system and the API implementation are deployed to several non-production environments in addition to production.
Rate limiting of the backend system applies to all non-production environments. The production environment, however, does NOT have any rate limiting.
What is the most effective approach to conduct performance tests of the API implementation in a staging (non-production) environment?

• A.Create a mocking service that replicates the backend system's production performance characteristics. Then configure the API implementation to use the mocking service and conduct the performance tests
• B.Include logic within the API implementation that bypasses invocations of the backend system in a performance test situation. Instead invoking local stubs that replicate typical backend system responses then conduct performance tests using this API Implementation
• C.Conduct scaled-down performance tests in the staging environment against the rate limited backend system then upscale performance results to full production scale
• D.Use MUnit to simulate standard responses from the backend system then conduct performance tests to identify other bottlenecks in the system

Comment: *

Name: *

Email: *

Verification: *

A Mule application contains a Batch Job with two Batch Steps (Batch_Step_1 and Batch_Step_2). A payload with 1000 records is received by the Batch Job.
How many threads are used by the Batch Job to process records, and how does each Batch Step process records within the Batch Job?

• A.Each Batch Job uses SEVERAL THREADS for the Batch Steps
  Each Batch Step instance receives ONE record at a time as the payload, and BATCH STEP INSTANCES execute IN PARALLEL to process records and Batch Steps in ANY order as fast as possible
• B.Each Batch Job uses SEVERAL THREADS for the Batch Steps
  Each Batch Step instance receives ONE record at a time as the payload, and RECORDS are processed IN PARALLEL within and between the two Batch Steps
• C.Each Batch Job uses a SINGLE THREAD for all Batch Steps
  Each Batch Step instance receives ONE record at a time as the payload, and RECORDS are processed IN ORDER, first through Batch_Step_1 and then through Batch_Step_2
• D.Each Batch Job uses a SINGLE THREAD to process a configured block size of record Each Batch Step instance receives A BLOCK OF records as the payload, and BLOCKS of records are processed IN ORDER

Comment: *

Name: *

Email: *

Verification: *

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 for state JMS consumer threads to be destroyed After the timeout, a new JMS consumer thread is created
• 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 between committing the transaction and the completion of the Mule flow After the timeout, flow processing triggers an error

Comment: *

Name: *

Email: *

Verification: *

What is true about the network connections when a Mule application uses a JMS connector to interact with a JMS provider (message broker)?

• A.To complete sending a JMS message, the JMS connector must establish a network connection with the JMS message recipient
• B.To receive messages into the Mule application, the JMS provider initiates a network connection to the JMS connector and pushes messages along this connection
• C.The JMS connector supports both sending and receiving of JMS messages over the protocol determined by the JMS provider
• D.The AMQP protocol can be used by the JMS connector to portably establish connections to various types of JMS providers

Correct Answer: C

* To send message or receive JMS (Java Message Service) message no separate network connection need to be established. So option A, C and D are ruled out.
Correct answer: The JMS connector supports both sending and receiving of JMS messages over the protocol determined by the JMS provider.
* JMS Connector enables sending and receiving messages to queues and topics for any message service that implements the JMS specification.
* JMS is a widely used API for message-oriented middleware.
* It enables the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous.
MuleSoft Doc Reference: https://docs.mulesoft.com/jms-connector/1.7/

Comment: *

Name: *

Email: *

Verification: *

An organization has decided on a cloudhub migration strategy that aims to minimize the organizations own IT resources. Currently, the organizational has all of its Mule applications running on its own premises and uses an premises load balancer that exposes all APIs under the base URL https://api.acme.com As part of the migration strategy, the organization plans to migrate all of its Mule applications and load balancer to cloudhub What is the most straight-forward and cost effective approach to the Mule applications deployment and load balancing that preserves the public URLs?

• A.Deploy the Mule applications to Cloudhub
  Update the CNAME record for an api.acme.com in the organizations DNS server pointing to the A record of a cloudhub dedicated load balancer(DLB) Apply mapping rules in the DLB to map URLs to their corresponding Mule applications
• B.For each migrated Mule application, deploy an API proxy Mule application to Cloudhub with all applications under the control of a dedicated load balancer(CLB) Update the CNAME record for api.acme.com in the organization DNS server pointing to the A record of a cloudhub dedicated load balancer(DLB) Apply mapping rules in the DLB to map each API proxy application to its corresponding Mule applications
• C.Deploy the Mule applications to Cloudhub
  Create CNAME record for api.acme.com in the Cloudhub Shared load balancer (SLB) pointing to the A record of the on-premise load balancer Apply mapping rules in the SLB to map URLs to their corresponding Mule applications
• D.Deploy the Mule applications to Cloudhub
  Update the CNAME record for api.acme.com in the organization DNS server pointing to the A record of the cloudhub shared load balancer(SLB) Apply mapping rules in the SLB to map URLs to their corresponding Mule applications.

Comment: *

Name: *

Email: *

Verification: *