MuleSoft MCD-Level-1 - MuleSoft Certified Developer - Level 1 (Mule 4)

1. Set Payload “Start”

2. 'Is Balnk String' Creates an Error object with #[error.description] =“String is not blank”

3. Default Error Handler catches and Propagates error

4. 'On Error Propogate' is 'RED IN RED OUT'. It Returns Status Code : 500 & #[error.description]

--------------------------------------------------------------------------------------------------------------------------

Correct answer is String is not blank. Because validation component will throw an error as payload is not blank.

A picture containing timeline Description automatically generated

Bottom of Form

Top of Form

Variables are stored under Mule event. Please refer to below image for the hierarchy .

Graphical user interface Description automatically generated

Option 3 is the only corect answer as it concatenates payload with String.

Below option wont work.

#["The payload is " ++ payload]

Concatenation function expects both arguments to be string. As the question says payload is json object , this will throw error while running it. You can try this in Anypoint Studio and you will get the same result which I mentioned.

hence correct answer is

The payload is: #[payload]

* RAML file contains lot of information that could be considered as "not API-describing". Sort of "economy-class" members.

Equally important, but not necessarily part of the main RAML file.

* Through !includes, RAML allows us to build file-distributed API definitions, which is not only useful to encourage code reuse but also improves readability.

* We can create RAML fragments with such code and then include them in main RAML project using !include like:

types:

Book: !include bookDataType.raml and

examples:

input: !include bookExample.raml

* Additionally for

----------------------------------------------------------------------------------------------------------------------------------------

Correct Answer: D

Correct answer is below as it follows the correct syntax.

/customers:

/{customerId}:

get:

This question validates you knowledge on Batch Processing. Before we analyze the question , lets revise a bit about batch filters.

Batch Filters

You can apply one or more filters as attributes to any number of batch steps.Imagine a batch job whose first batch step checks if a Salesforce contact exists for a record, and a second batch step that updates each existing Salesforce contact with new information. You can apply a filter to the second batch step to ensure it only processes records that didn’t fail during the first batch step.By having batch steps accept only some records for processing, you streamline the batch job so the Mule runtime engine can focus only on the relevant data for a particular batch step.

A batch step uses two attributes to filter records:

acceptExpression

acceptPolicy

Each batch step can accept one acceptExpression and one acceptPolicy attributes to filter records.

Use the acceptExpression attribute to process only records that evaluate to true; if the record evaluates to false, the batch step skips the record and sends it to the next one. In other words, the records with an accept expression that resolves to false are the ones that Mule filters out.

The example below filters out all records where the age is less than 21; the batch step does not process those records.

...

Mule Ref Doc : Refining Batch Steps Processing | MuleSoft Documentation

As we are clear with above concepts , now lets understand this solution step by step.

1) Batch Step (Less than 50)

Accept expression for this batch step is less than 50. Hence elements which will go in this batch step are amount value 40 and 2. Hence output of logger in first batch step is

{amount=140}

{amount=102}

2) Batch Step (Greater than 20)

Accept condition for this batch step is greater than 20. Note that input amount values for this batch step are 100 , 140 and 102 (last two values have been updated in batch step less than 50)

As all values satisfy this condition out put of second logger is

{step2amount=100}

{step2amount=140}

{step2amount=102}

Hence correct answer to this question is

{amount=140}

{amount=102}

{step2amount=100}

{step2amount=140}

{step2amount=102}

2) Batch Step (Greater than 20)

Accept condition for this batch step is greater than 20. Note that input amount values for this batch step are 100 , 140 and 102 (last two values have been updated in batch step less than 50)

As all values satisfy this condition out put of second logger is

{step2amount=100}

{step2amount=140}

{step2amount=102}

Hence correct answer to this question is

{amount=140}

{amount=102}

{step2amount=100}

{step2amount=140}

{step2amount=102}

Correct answer is Nothing needs to be changed in the other APIs or their associated applications

This is the benefit of having separate interface layer. As there are no changes to interface , no changes are required on the API's which consumes this API in context

This helps CloudHub to dynamically allocates a port at deployment time.

MuleSoft Doc Ref : https://docs.mulesoft.com/mule-runtime/4.3/deploy-to-cloudhub#prerequisites