An organization's security policies mandate complete control of the login credentials used to log in to Anypoint Platform.
What feature of Anypoint Platform should be used to meet this requirement?

• A.Federated Client Management
• B.Federated Identity Management
• C.Enterprise Security Module
• D.Client ID Secret

Comment: *

Name: *

Email: *

Verification: *

A retailer is designing a data exchange interface to be used by its suppliers. The interface must support secure communication over the public internet. The interface must also work with a wide variety of programming languages and IT systems used by suppliers.
What are suitable interface technologies for this data exchange that are secure, cross-platform, and internet friendly, assuming that Anypoint Connectors exist for these interface technologies?

• A.SOAP over HTTPS HOP over TLS gRPC over HTTPS
• B.EDJFACT XML over SFTP JSON/REST over HTTPS
• C.XML over ActiveMQ XML over SFTP XML/REST over HTTPS
• D.CSV over FTP YAML over TLS JSON over HTTPS

Comment: *

Name: *

Email: *

Verification: *

An Order microservice and a Fulfillment microservice are being designed to communicate with their dients through message-based integration (and NOT through API invocations).
The Order microservice publishes an Order message (a kind of command message) containing the details of an order to be fulfilled. The intention is that Order messages are only consumed by one Mute application, the Fulfillment microservice.
The Fulfilment microservice consumes Order messages, fulfills the order described therein, and then publishes an OrderFulfilted message (a kind of event message). Each OrderFulfilted message can be consumed by any interested Mule application, and the Order microservice is one such Mute application.
What is the most appropriate choice of message broker(s) and message destination(s) in this scenario?

• A.Older messages are sent directly to the Fulfillment microservices
  OrderFulfilled messages are sent directly to the Order microservice
  The Order microservice Interacts with one AMQP-compatible message broker and the Fulfillment microservice Interacts with a different AMQP-compatible message broker, so that both message brokers can be chosen and scaled to best support the toad each microservice
• B.Order messages are sent to a JMS queue OrderFulfilled messages are sent to a JMS topic Both microservices Interact with the same JMS provider (message broker) Instance, which must therefore scale to support the load of both microservices
• C.Order messages are sent to a JMS queue OrderFulfilled messages are sent to a JMS topic The Order microservice Interacts with one JMS provider (message broker) and the Fulfillment microservice interacts with a different JMS provider, so that both message brokers can be chosen and scaled to best support the load of each microservice
• D.O Order messages are sent to an Anypoint MQ exchange
  OrderFulfilted messages are sent to an Anypoint MQ queue
  Both microservices interact with Anypoint MQ as the message broker, which must therefore scale to support the toad of both microservices

Comment: *

Name: *

Email: *

Verification: *

What is not true about Mule Domain Project?

• A.This allows Mule applications to share resources
• B.Expose multiple services within the Mule domain on the same port
• C.Only available Anypoint Runtime Fabric
• D.Send events (messages) to other Mule applications using VM queues

Correct Answer: C

* Mule Domain Project is ONLY available for customer-hosted Mule runtimes, but not for Anypoint Runtime Fabric
* Mule domain project is available for Hybrid and Private Cloud (PCE). Rest all provide application isolation and can't support domain project.
What is Mule Domain Project?
* A Mule Domain Project is implemented to configure the resources that are shared among different projects. These resources can be used by all the projects associated with this domain. Mule applications can be associated with only one domain, but a domain can be associated with multiple projects. Shared resources allow multiple development teams to work in parallel using the same set of reusable connectors. Defining these connectors as shared resources at the domain level allows the team to: - Expose multiple services within the domain through the same port. - Share the connection to persistent storage. - Share services between apps through a well-defined interface. - Ensure consistency between apps upon any changes because the configuration is only set in one place.
* Use domains Project to share the same host and port among multiple projects. You can declare the http connector within a domain project and associate the domain project with other projects. Doing this also allows to control thread settings, keystore configurations, time outs for all the requests made within multiple applications. You may think that one can also achieve this by duplicating the http connector configuration across all the applications. But, doing this may pose a nightmare if you have to make a change and redeploy all the applications.
* If you use connector configuration in the domain and let all the applications use the new domain instead of a default domain, you will maintain only one copy of the http connector configuration. Any changes will require only the domain to the redeployed instead of all the applications.
You can start using domains in only three steps:
1) Create a Mule Domain project
2) Create the global connector configurations which needs to be shared across the applications inside the Mule Domain project
3) Modify the value of domain in mule-deploy.properties file of the applications

Comment: *

Name: *

Email: *

Verification: *

Anypoint Exchange is required to maintain the source code of some of the assets committed to it, such as Connectors, Templates, and API specifications.
What is the best way to use an organization's source-code management (SCM) system in this context?

• A.Organizations should continue to use an SCM system of their choice, in addition to keeping source code for these asset types in Anypoint Exchange, thereby enabling parallel development, branching, and merging
• B.Organizations need to use Anypoint Exchange as the main SCM system to centralize versioning and avoid code duplication
• C.Organizations can continue to use an SCM system of their choice for branching and merging, as long as they follow the branching and merging strategy enforced by Anypoint Exchange
• D.Organizations need to point Anypoint Exchange to their SCM system so Anypoint Exchange can pull source code when requested by developers and provide it to Anypoint Studio

Comment: *

Name: *

Email: *

Verification: *