Salesforce-MuleSoft-Developer-II Exam Questions

Total 62 Questions


Last Updated On : 16-Jan-2025

When implementing a synchronous API where the event source is an HTTP Listener, a developer needs to return the same correlation ID back to the caller in the HTTP response header. How can this be achieved?


A. Enable the auto-generate CorrelationID option when scaffolding the flow


B. Enable the CorrelationID checkbox in the HTTP Listener configuration


C. Configure a custom correlation policy


D. NO action is needed as the correlation ID is returned to the caller in the response header by default





D.
  NO action is needed as the correlation ID is returned to the caller in the response header by default

Explanation:

When implementing a synchronous API where the event source is an HTTP Listener, Mule automatically propagates some message attributes between flows via outbound and inbound properties. One of these attributes is correlation ID, which is returned to the caller in the response header by default as MULE_CORRELATION_ID.

References: https://docs.mulesoft.com/mule-runtime/4.3/about-mule-message#message-attributes

A Mule application defines as SSL/TLS keystore properly ‘tis,keystore.keyPassword’’ as secure. How can this property be referenced to access its value within the application?


A. #{secure::tiskeystore,keyPassowrd}


B. ${secure::tiskeystore,keyPassowrd}


C. ${secure::tiskeystore,keyPassowrd}


D. p{secure::tiskeystore,keyPassowrd}





B.
  ${secure::tiskeystore,keyPassowrd}

Explanation:

secure::tiskeystore,keyPassowrd∗∗ShortExplanationofCorrectAnswerOnly:Toreferenceasecurepropertyvaluewithintheapplication,thedeveloperneedstousethesyntax{secure::}. In this case, the property name is tiskeystore,keyPassword, so the correct syntax is ${secure::tiskeystore,keyPassowrd}.

References: https://docs.mulesoft.com/mule-runtime/4.3/secure-configuration-properties#referencing-secure-properties

Which command is used to convert a JKS keystore to PKCS12?


A. Keytool-importkeystore –srckeystore keystore p12-srcstoretype PKCS12 –destkeystore keystore.jks –deststoretype JKS


B. Keytool-importkeystore –srckeystore keystore p12-srcstoretype JKS –destkeystore keystore.p12 –deststoretype PKCS12


C. Keytool-importkeystore –srckeystore keystore jks-srcstoretype JKS –destkeystore keystore.p13 –deststoretype PKCS12


D. Keytool-importkeystore –srckeystore keystore jks-srcstoretype PKCS12 –destkeystore keystore.p12 –deststoretype JKS





B.
  Keytool-importkeystore –srckeystore keystore p12-srcstoretype JKS –destkeystore keystore.p12 –deststoretype PKCS12

Explanation:

To convert a JKS keystore to PKCS12, the developer needs to use the keytool-importkeystore command with the following options: -srckeystore keystore.jks -srcstoretype JKS -destkeystore keystore.p12 -deststoretype PKCS12. This command imports all entries from a source JKS keystore (keystore.jks) into a destination PKCS12 keystore (keystore.p12). References: https://docs.oracle.com/en/java/javase/11/tools/keytool.html#GUID-5990A2E4-78E3-47B7-AE75-6D1826259549

XMLUnit


A. XMLUnit


B. Junit


C. MUnit Extensions Maven plugin


D. MUnit Maven plugin





C.
  MUnit Extensions Maven plugin

Explanation:

To unit test modules created with XML SDK, the developer needs to use the MUnit Extensions Maven plugin. This plugin allows testing XML SDK modules using MUnit by adding a dependency to the module under test and using a custom processor tag to invoke it. References: https://docs.mulesoft.com/mule-sdk/1.1/xml-sdk#testing

Two APIs are deployed to a two-node on-prem cluster. Due to a requirements change, the two APIs must communicate to exchange data asynchronously.


A. If the two APIs use the same domain, the VM Connector can be leveraged


B. The VM Connector is used to inter-application communication, so it is not possible to use the VM Connector


C. Instead of using the VM Connector use directly


D. It is not possible to use the VM Connector since the APIs are running in a cluster mode and each mode has it own set of VM Queues





A.
  If the two APIs use the same domain, the VM Connector can be leveraged

Explanation:

To communicate asynchronously between two APIs deployed to a two-node on-prem cluster, the developer can use the VM Connector if the two APIs use the same domain. The VM Connector allows passing messages between different Mule applications within a single Mule runtime instance or across different instances using shared memory or persistent storage. If two APIs are deployed under the same domain, they can share resources such as VM queues and communicate asynchronously using VM Connector operations.

References:

https://docs.mulesoft.com/mule-runtime/4.3/vm-connector

https://docs.mulesoft.com/mule-runtime/4.3/shared-resources

A Mule application uses API autodiscovery to access and enforce policies for a RESTful implementation.


A. Northing because flowRef is an optional attribute which can be passed runtime


B. The name of the flow that has APlkit Console to receive all incoming RESTful operation requests.


C. Any of the APIkit generate implement flows


D. The name of the flow that has HTTP listener to receive all incoming RESTful operation requests





D.
  The name of the flow that has HTTP listener to receive all incoming RESTful operation requests

Explanation:

To use API autodiscovery to access and enforce policies for a RESTful implementation, flowRef must be set to the name of the flow that has HTTP listener to receive all incoming RESTful operation requests. This way, API autodiscovery can identify the API implementation and associate it with the corresponding API specification and policies in API Manager. The flow that has HTTP listener is usually the main flow that contains the APIKit Router. References: https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept#flowref

A company with MuleSoft Titanium develops a Salesforce System API using MuleSoft out-of-the-box Salesforce Connector and deploys the API to CloudHub. Which steps provide the average number of requests and average response time of the Salesforce Connector?


A. Access Anypoint Monitoring’s built-in dashboard. Select a resource.

Locate the information under the Connectors tab.


B. Access Anypoint Monitoring’s built-in dashboard Seclect a resource.

Create a custom dashboard to retrieve the information.


C. Access Anypoint Monitoring built-in dashboard.

Select a resource.

Locate the information under Log Manager < Raw Data.





A.
  Access Anypoint Monitoring’s built-in dashboard. Select a resource.

Locate the information under the Connectors tab.



Explanation:

To get the average number of requests and average response time of the Salesforce Connector, the developer should access Anypoint Monitoring’s built-in dashboard, select a resource (such as an application or an API), and locate the information under the Connectors tab. The Connectors tab shows metrics for each connector used by the resource, such as average requests per minute, average response time, and failures.

References:

https://docs.mulesoft.com/monitoring/built-in-dashboard-reference

An organization uses CloudHub to deploy all of its applications. How can a common-global-handler flow be configured so that it can be reused across all of the organization’s deployed applications?


A. Create a Mule plugin project

Create a common-global-error-handler flow inside the plugin project.

Use this plugin as a dependency in all Mute applications.

Import that configuration file in Mute applications.


B. Create a common-global-error-handler flow in all Mule Applications Refer to it flow-ref wherever needed.


C. Create a Mule Plugin project

Create a common-global-error-handler flow inside the plugin project.

Use this plugin as a dependency in all Mule applications


D. Create a Mule daman project.

Create a common-global-error-handler flow inside the domain project.

Use this domain project as a dependency.





C.
  Create a Mule Plugin project

Create a common-global-error-handler flow inside the plugin project.

Use this plugin as a dependency in all Mule applications



Explanation:

To configure a common-global-handler flow that can be reused across all of the organization’s deployed applications, the developer should create a Mule Plugin project, create a common-global-error-handler flow inside the plugin project, and use this plugin as a dependency in all Mule applications. This way, the developer can import the common-global-error-handler flow in any application that needs it and avoid duplicating the error handling logic. References: https://docs.mulesoft.com/mule-runtime/4.3/error-handling#global-error-handler

An order processing system is composed of multiple Mule application responsible for warehouse, sales and shipping. Each application communication using Anypoint MQ. Each message must be correlated against the original order ID for observability and tracing. How should a developer propagate the order ID as the correlation ID across each message?


A. Use the underlying HTTP request of Anypoint MQ to set the ‘X-CORRELATION_ID’ header to the order ID


B. Set a custom Anypoint MQ user property to propagate the order ID and set the correlation ID in the receiving applications.


C. Use the default correlation ID, Anypoint MQ will sutomatically propagate it.


D. Wrap all Anypoint MQ Publish operations within a With CorrelationID scope from the Tracing module, setting the correlation ID to the order ID






Explanation:

To propagate the order ID as the correlation ID across each message using Anypoint MQ, the developer should wrap all Anypoint MQ Publish operations within a With CorrelationID scope from the Tracing module, setting the correlation ID to the order ID. The With CorrelationID scope allows setting a custom correlation ID for any event that occurs within it. The Tracing module also enables distributed tracing across different Mule applications and services using Anypoint Monitoring.

References: https://docs.mulesoft.com/tracing-module/1.0/tracing-module-reference#with-correlation-id-scope https://docs.mulesoft.com/tracing-module/1.0/tracing-module-concepts

The Center for Enablement team published a common application as a reusable module to the central Nexus repository. How can the common application be included in all API implementations?


A. Download the common application from Naxus and copy it to the src/main/resources folder in the API


B. Copy the common application’s source XML file and out it in a new flow file in the src/main/mule folder


C. Add a Maven dependency in the PCM file with multiple-plugin as


D. Add a Maven dependency in the POM file with jar as





D.
  Add a Maven dependency in the POM file with jar as

Explanation:

To include a common application as a reusable module in all API implementations, the developer should add a Maven dependency in the POM file with jar as . This way, the developer can reuse Mule code from another application by packaging it as a JAR file and adding it as a dependency in the POM file of the API implementation. The classifier element specifies that it is a JAR file. References: https://docs.mulesoft.com/mule-runtime/4.3/mmp-concept#add-a-maven-dependency-to-the-pom-file


Page 1 out of 7 Pages

About Salesforce MuleSoft-Developer-II Exam


Salesforce MuleSoft-Developer-II Exam is a certification designed for developers who are proficient in advanced MuleSoft Anypoint Platform features, application development, and integration solutions.

Key Facts:

Exam Questions: 60
Type of Questions: MCQs
Exam Time: 120 minutes
Exam Price: $375
Passing Score: 70%

Key Topics:

1. Advanced MuleSoft Application Development: 20% of exam
2. Integration and Messaging Patterns: 20% of exam
3. DataWeave and Data Transformation: 15% of exam
4. API Design and Implementation: 15% of exam
5. Performance and Optimization: 10% of exam
6. Security and Policies: 10% of exam
7. Deployment and Monitoring: 10% of exam

Recommended Salesforce MuleSoft-Developer-II Study Resources


1. Official MuleSoft Training
2. Documentation and Guides
3. SalesforceExams MuleSoft-Developer-II Practice Test
4. Community and Forums
5. Hands-On Practice

Salesforce MuleSoft-Developer-II Certification Benefits


Professional RecognitionValidates your advanced skills in MuleSoft development.
Career AdvancementOpens up opportunities for senior integration developer roles.
Higher Earning PotentialCertified professionals command competitive salaries.

By earning the Salesforce MuleSoft-Developer-II Certification, you showcase your expertise in building advanced and scalable MuleSoft solutions, positioning yourself as a leader in the integration field.