MCIA-LEVEL-1 Practice Questions

Lets analyze the situation in regards to the different options available Option

:

A common

Experience API but separate Process APIs Analysis : This solution will not work because having

common experience layer will not help the purpose as mobile and web applications will have

different set of requirements which cannot be fulfilled by single experience layer API

Option : Common Process API Analysis : This solution will not work because creating a common

process API will impose limitations in terms of flexibility to customize API;s as per the requirements

of different applications. It is not a recommended approach.

Option : Separate set of API's for both the applications Analysis : This goes against the principle of

Anypoint API-led connectivity approach which promotes creating reusable assets. This solution may

work but this is not efficient solution and creates duplicity of code.

Hence the correct answer is: Separate Experience APIs for the mobile and web app, but a common

Process API that invokes separate System APIs created for the database and CRM system

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/MuleSoft_MCIA-Level-1/page_82_img_1.jpg

Lets analyze the situation in regards to the different options available Option

:

A common

Experience API but separate Process APIs Analysis : This solution will not work because having

common experience layer will not help the purpose as mobile and web applications will have

different set of requirements which cannot be fulfilled by single experience layer API

Option : Common Process API Analysis : This solution will not work because creating a common

process API will impose limitations in terms of flexibility to customize API;s as per the requirements

of different applications. It is not a recommended approach.

Option : Separate set of API's for both the applications Analysis : This goes against the principle of

Anypoint API-led connectivity approach which promotes creating reusable assets. This solution may

work but this is not efficient solution and creates duplicity of code.

Hence the correct answer is: Separate Experience APIs for the mobile and web app, but a common

Process API that invokes separate System APIs created for the database and CRM system

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/MuleSoft_MCIA-Level-1/page_83_img_1.jpg

Correct answer is Untill Successful scope can be implemented while calling backend API's The Until

Successful scope repeatedly triggers the scope's components (including flow

) until they all

succeed or until a maximum number of retries is exceeded The scope provides option to control the

max number of retries and the interval between retries The scope can execute any sequence of

processors that may fail for whatever reason and may succeed upon retry

Every Mule application deployed to CloudHub receives a DNS entry pointing to the CloudHub. The

DNS entry is a CNAME for the CloudHub Shared Load Balancer in the region to which the Mule

application is deployed. When we deploy the application on CloudHub, we get a generic url to access

the endpoints. Generic URL looks as below:

..cloudhub.io is the deployed application name

which is unique across all the MuleSoft clients. is the region name in which an application is

deployed.

The public CloudHub (shared) load balancer already redirects these requests, where myApp is the

name

of

the

Mule

application

deployment

to

CloudHub:

HTTP

requests

to

http://myApp..cloudhub.io redirects to

http://mule-worker-myApp..cloudhub.io:8081

HTTPS traffic to https://myApp..cloudhub.io redirects to

https://mule-worker-myApp..cloudhub.io:8082

Reference:

https://help.mulesoft.com/s/article/Enable-external-log-forwarding-for-Muleapplications-deployed-in-RTF

:

* As per definition of API by Mulesoft , it is Application Programming Interface using HTTP-based

protocols. Non-HTTP-based programmatic interfaces are not APIs.

* HTTP-based programmatic interfaces are APIs even if they don’t use REST or JSON. Hence

implementation based on Java RMI, CORBA/IIOP, raw TCP/IP interfaces are not API's as they are not

using HTTP.

* One more thing to note is FTP was not built to be secure. It is generally considered to be an

insecure protocol because it relies on clear-text usernames and passwords for authentication and

does not use encryption.

* Data sent via FTP is vulnerable to sniffing, spoofing, and brute force attacks, among other basic

attack methods.

Considering the above points only correct option is

-XML over ActiveMQ

- XML over SFTP

- XML/REST over HTTPS

Correct answer is Create WSDL specification using text editor SOAP services are specified using

WSDL. A client program connecting to a web service can read the WSDL to determine what functions

are available on the server. We can not create WSDL specification in Design Center. We need to use

external text editor to create WSDL.

:

Correct answer is When a Mule runtime on a given customer-hosted server is experiencing high

memory consumption during certain periods Using Anypoint Monitoring, you can configure two

different types of alerts: Basic alerts for servers and Mule apps Limit per organization: Up to 50 basic

alerts for users who do not have a Titanium subscription to Anypoint Platform You can set up basic

alerts to trigger email notifications when a metric you are measuring passes a specified threshold.

You can create basic alerts for the following metrics for servers or Mule apps: For on-premises

servers and CloudHub apps: * CPU utilization * Memory utilization * Thread count Advanced alerts

for graphs in custom dashboards in Anypoint Monitoring. You must have a Titanium subscription to

use this feature. Limit per organization: Up to 20 advanced alerts

When an operation in a Mule application fails to connect to an external server, the default behavior

is for the operation to fail immediately and return a connectivity error. You can modify this default

behavior by configuring a reconnection strategy for the operation. You can configure a reconnection

strategy for an operation either by modifying the operation properties or by modifying the

configuration of the global element for the operation. The following are the available reconnection

strategies and their behaviors: None Is the default behavior, which immediately returns a

connectivity error if the attempt to connect is unsuccessful Standard (reconnect) Sets the number of

reconnection attempts and the interval at which to execute them before returning a connectivity

error Forever (reconnect-forever) Attempts to reconnect continually at a given interval