ExamGecko
Home / MuleSoft / MCIA Level 1 Maintenance / List of questions
Ask Question

MuleSoft MCIA Level 1 Maintenance Practice Test - Questions Answers, Page 2

Question list
Search

List of questions

Search

Related questions











Question 11

Report
Export
Collapse

An API implementation is being designed that must invoke an Order API which is known to repeatedly experience downtime. For this reason a fallback API is to be called when the Order API is unavailable. What approach to designing invocation of the fallback API provides the best resilience?

Redirect client requests through an HTTP 303 temporary redirect status code to the fallback APIwhenever the Order API is unavailable
Redirect client requests through an HTTP 303 temporary redirect status code to the fallback APIwhenever the Order API is unavailable
Set an option in the HTTP Requester component that invokes the order API to instead invoke afallback API whenever an HTTP 4XX or 5XX response status code is received from Order API
Set an option in the HTTP Requester component that invokes the order API to instead invoke afallback API whenever an HTTP 4XX or 5XX response status code is received from Order API
Create a separate entry for the order API in API manager and then invoke this API as a fallback API if the primary Order API is unavailable
Create a separate entry for the order API in API manager and then invoke this API as a fallback API if the primary Order API is unavailable
Search Anypoint Exchange for a suitable existing fallback API and them implement invocations to their fallback API in addition to the Order API
Search Anypoint Exchange for a suitable existing fallback API and them implement invocations to their fallback API in addition to the Order API
Suggested answer: A

Explanation:

* Resilience testing is a type of software testing that observes how applications act under stress. It's meant to ensure the product's ability to perform in chaotic conditions without a loss of core functions or data; it ensures a quick recovery after unforeseen, uncontrollable events.

* In case an API invocation fails — even after a certain number of retries — it might be adequate to invoke a different API as a fallback. A fallback API, by definition, will never be ideal for the purpose of the API client, otherwise it would be the primary API.

* Here are some examples for fallback APIs:

- An old, deprecated version of the same API.

- An alternative endpoint of the same API and version (e.g. API in another CloudHub region).

- An API doing more than required, and therefore not as performant as the primary API.

- An API doing less than required and therefore forcing the API Client to offer a degraded service, which is still better than no service at all.

* API clients implemented as Mule applications offer the ‘Until Successful Scope and Exception’ strategies at their disposal, which together allow configuring fallback actions such as a fallback API invocation.

* All HTTP response status codes within the 3xx category are considered redirection messages. Thesecodes indicate to the user agent (i.e. your web browser) that an additional action is required in orderto complete the request and access the desired resource

MuleSoft MCIA Level 1 Maintenance image Question 11 explanation 53105 09182024213645000000

Hence correct answer is Redirect client requests through an HTTP 303 temporary redirect status codeto the fallback API whenever the Order API is unavailable

asked 18/09/2024
Ahmed Dawoud
41 questions

Question 12

Report
Export
Collapse

How are the API implementation , API client, and API consumer combined to invoke and process an API ?

The API consumer creates an API implementation , which receives API invocations from an API such that they are processed for an API client
The API consumer creates an API implementation , which receives API invocations from an API such that they are processed for an API client
The API consumer creates an API client which sends API invocations to an API such that they are processed by an API implementation
The API consumer creates an API client which sends API invocations to an API such that they are processed by an API implementation
An API client creates an API consumer, which receives API invocation from an API such that they are processed for an API implementation
An API client creates an API consumer, which receives API invocation from an API such that they are processed for an API implementation
The API client creates an API consumer which sends API invocations to an API such that they are processed by API implementation
The API client creates an API consumer which sends API invocations to an API such that they are processed by API implementation
Suggested answer: C

Explanation:

The API consumer creates an API client which sends API invocations to an API such that they are processed by an API implementation This is based on below definitions API client • An application component • that accesses a service • by invoking an API of that service - by definition of the term API over HTTP API consumer • A business role, which is often assigned to an individual • that develops API clients, i.e., performs the activities necessary for enabling an API client to invoke APIs API implementation • An application component • that implements the functionality

asked 18/09/2024
Kristian Gutierrez
47 questions

Question 13

Report
Export
Collapse

What Mule application can have API policies applied by Anypoint Platform to the endpoint exposed by that Mule application?

A Mule application that accepts requests over HTTP/1x
A Mule application that accepts requests over HTTP/1x
A Mule application that accepts JSON requests over TCP but is NOT required to provide a response.
A Mule application that accepts JSON requests over TCP but is NOT required to provide a response.
A Mule application that accepts JSON requests over WebSocket
A Mule application that accepts JSON requests over WebSocket
A Mule application that accepts gRPC requests over HTTP/2
A Mule application that accepts gRPC requests over HTTP/2
Suggested answer: A

Explanation:

* HTTP/1.1 keeps all requests and responses in plain text format.

* HTTP/2 uses the binary framing layer to encapsulate all messages in binary format, while stillmaintaining HTTP semantics, such as verbs, methods, and headers. It came into use in 2015, andoffers several methods to decrease latency, especially when dealing with mobile platforms andserver-intensive graphics and videos* Currently, Mule application can have API policies only for Mule application that accepts requestsover HTTP/1x

asked 18/09/2024
Fermin Paneque Cabrera
39 questions

Question 14

Report
Export
Collapse

The implementation of a Process API must change. What is a valid approach that minimizes the impact of this change on API clients?

Implement required changes to the Process API implementation so that whenever possible, the Process API's RAML definition remains unchanged
Implement required changes to the Process API implementation so that whenever possible, the Process API's RAML definition remains unchanged
Update the RAML definition of the current Process API and notify API client developers by sending them links to the updated RAML definition
Update the RAML definition of the current Process API and notify API client developers by sending them links to the updated RAML definition
Postpone changes until API consumers acknowledge they are ready to migrate to a new Process API or API version
Postpone changes until API consumers acknowledge they are ready to migrate to a new Process API or API version
Implement the Process API changes in a new API implementation, and have the old API implementation return an HTTP status code 301 - Moved Permanently to inform API clients they should be calling the new API implementation
Implement the Process API changes in a new API implementation, and have the old API implementation return an HTTP status code 301 - Moved Permanently to inform API clients they should be calling the new API implementation
Suggested answer: A

Explanation:

* Option B shouldn't be used unless extremely needed, if RAML is changed, client needs to accommodate changes. Question is about minimizing impact on Client. So this is not a valid choice.

* Option C isn't valid as Business can't stop for consumers acknowledgment.

* Option D again needs Client to accommodate changes and isn't viable option.

* Best choice is A where RAML definition isn't changed and underlined functionality is changed without any dependency on client and without impacting client.

asked 18/09/2024
Marcel Janssen
38 questions

Question 15

Report
Export
Collapse

Organization wants to achieve high availability goal for Mule applications in customer hosted runtime plane. Due to the complexity involved, data cannot be shared among of different instances of same Mule application. What option best suits to this requirement considering high availability is very much critical to the organization?

The cluster can be configured
The cluster can be configured
Use third party product to implement load balancer
Use third party product to implement load balancer
High availability can be achieved only in CloudHub
High availability can be achieved only in CloudHub
Use persistent object store
Use persistent object store
Suggested answer: B

Explanation:

High availability is about up-time of your application

A) High availability can be achieved only in CloudHub isn't correct statement. It can be achieved in customer hosted runtime planes as well

B) An object store is a facility for storing objects in or across Mule applications. Mule runtime engine (Mule) uses object stores to persist data for eventual retrieval. It can be used for disaster recovery but not for High Availability. Using object store can't guarantee that all instances won't go down at once. So not an appropriate choice.

Reference: https://docs.mulesoft.com/mule-runtime/4.3/mule-object-stores

C) High availability can be achieved by below two models for on-premise MuleSoft implementations.

1) Mule Clustering – Where multiple Mule servers are available within the same cluster environment and the routing of requests will be done by the load balancer. A cluster is a set of up to eight servers that act as a single deployment target and high-availability processing unit. Application instances in a cluster are aware of each other, share common information, and synchronize statuses.

If one server fails, another server takes over processing applications. A cluster can run multiple applications. ( refer left half of the diagram) In given scenario, it's mentioned that 'data cannot be shared among of different instances'. So this is not a correct choice.

Reference: https://docs.mulesoft.com/runtime-manager/cluster-about

2) Load balanced standalone Mule instances – The high availability can be achieved even without cluster, with the usage of third party load balancer pointing requests to different Mule servers. This approach does not share or synchronize data between Mule runtimes. Also high availability achieved as load balanced algorithms can be implemented using external load balancer. ( refer right half of the diagram)

MuleSoft MCIA Level 1 Maintenance image Question 15 explanation 53109 09182024213645000000

asked 18/09/2024
Nivenl Surnder
33 questions

Question 16

Report
Export
Collapse

An organization needs to enable access to their customer data from both a mobile app and a web application, which each need access to common fields as well as certain unique fields. The data is available partially in a database and partially in a 3rd-party CRM system. What APIs should be created to best fit these design requirements?

MuleSoft MCIA Level 1 Maintenance image Question 16 53110 09182024213645000000

A Process API that contains the data required by both the web and mobile apps, allowing these applications to invoke it directly and access the data they need thereby providing the flexibility to add more fields in the future without needing API changes.
A Process API that contains the data required by both the web and mobile apps, allowing these applications to invoke it directly and access the data they need thereby providing the flexibility to add more fields in the future without needing API changes.
One set of APIs (Experience API, Process API, and System API) for the web app, and another set for the mobile app.
One set of APIs (Experience API, Process API, and System API) for the web app, and another set for the mobile app.
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
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
A common Experience API used by both the web and mobile apps, but separate Process APIs for the web and mobile apps that interact with the database and the CRM System.
A common Experience API used by both the web and mobile apps, but separate Process APIs for the web and mobile apps that interact with the database and the CRM System.
Suggested answer: C

Explanation:

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

MuleSoft MCIA Level 1 Maintenance image Question 16 explanation 53110 09182024213645000000

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

MuleSoft MCIA Level 1 Maintenance image Question 16 explanation 53110 09182024213645000000

asked 18/09/2024
Anand Prakash
31 questions

Question 17

Report
Export
Collapse

What is true about automating interactions with Anypoint Platform using tools such as Anypoint Platform REST API's, Anypoint CLI or the Mule Maven plugin?

By default, the Anypoint CLI and Mule Maven plugin are not included in the Mule runtime
By default, the Anypoint CLI and Mule Maven plugin are not included in the Mule runtime
Access to Anypoint Platform API;s and Anypoint CLI can be controlled separately thruough the roles and permissions in Anypoint platform, so that specific users can get access to Anypoint CLI while others get access to the platform API's
Access to Anypoint Platform API;s and Anypoint CLI can be controlled separately thruough the roles and permissions in Anypoint platform, so that specific users can get access to Anypoint CLI while others get access to the platform API's
Anypoint Platform API's can only automate interactions with CloudHub while the Mule maven plugin is required for deployment to customer hosted Mule runtimes
Anypoint Platform API's can only automate interactions with CloudHub while the Mule maven plugin is required for deployment to customer hosted Mule runtimes
API policies can be applied to the Anypoint platform API's so that only certain LOS's has access to specific functions
API policies can be applied to the Anypoint platform API's so that only certain LOS's has access to specific functions
Suggested answer: A

Explanation:

Correct answer is By default, the Anypoint CLI and Mule Maven plugin are not included in the Mule runtime Maven is not part of runtime though it is part of studio. You do not need it to deploy in order to deploy your app. Same is the case with CLI.

asked 18/09/2024
PANAGIOTIS SYKAS
39 questions

Question 18

Report
Export
Collapse

An organization uses one specific CloudHub (AWS) region for all CloudHub deployments. How are CloudHub workers assigned to availability zones (AZs) when the organization's Mule applications are deployed to CloudHub in that region?

Workers belonging to a given environment are assigned to the same AZ within that region.
Workers belonging to a given environment are assigned to the same AZ within that region.
AZs are selected as part of the Mule application's deployment configuration.
AZs are selected as part of the Mule application's deployment configuration.
Workers are randomly distributed across available AZs within that region.
Workers are randomly distributed across available AZs within that region.
An AZ is randomly selected for a Mule application, and all the Mule application's CloudHub workers are assigned to that one AZ
An AZ is randomly selected for a Mule application, and all the Mule application's CloudHub workers are assigned to that one AZ
Suggested answer: C

Explanation:

Correct answer is Workers are randomly distributed across available AZs within that region. This ensure high availability for deployed mule applications Mulesoft documentation reference :

https://docs.mulesoft.com/runtime-manager/cloudhub-hadr

asked 18/09/2024
rita whitfield
38 questions

Question 19

Report
Export
Collapse

What best describes the Fully Qualified Domain Names (FQDNs), also known as DNS entries, created when a Mule application is deployed to the CloudHub Shared Worker Cloud?

A fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design
A fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design
The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region
The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region
The FQDNs are determined by the application name, but can be modified by an administrator after deployment
The FQDNs are determined by the application name, but can be modified by an administrator after deployment
The FQDNs are determined by both the application name and the region
The FQDNs are determined by both the application name and the region
Suggested answer: D

Explanation:

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:

<application-name>.<region>.cloudhub.io <application-name> is the deployed application name which is unique across all the MuleSoft clients. <region> 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.<region>.cloudhub.io redirects to http://mule-worker-myApp.<region>.cloudhub.io:8081

HTTPS traffic to https://myApp.<region>.cloudhub.io redirects to

https://mule-worker-myApp.<region>.cloudhub.io:8082

asked 18/09/2024
Istvan Flach
30 questions

Question 20

Report
Export
Collapse

What API policy would LEAST likely be applied to a Process API?

Custom circuit breaker
Custom circuit breaker
Client ID enforcement
Client ID enforcement
Rate limiting
Rate limiting
JSON threat protection
JSON threat protection
Suggested answer: D

Explanation:

Key to this question lies in the fact that Process API are not meant to be accessed directly by clients.

Lets analyze options one by one. Client ID enforcement : This is applied at process API level generally to ensure that identity of API clients is always known and available for API-based analytics Rate Limiting : This policy is applied on Process Level API to secure API's against degradation of service that can happen in case load received is more than it can handle Custom circuit breaker : This is also quite useful feature on process level API's as it saves the API client the wasted time and effort of invoking a failing API. JSON threat protection : This policy is not required at Process API and rather implemented as Experience API's. This policy is used to safeguard application from malicious attacks by injecting malicious code in JSON object. As ideally Process API's are never called from external world , this policy is never used on Process API's Hence correct answer is JSON threat protection MuleSoft Documentation Reference : https://docs.mulesoft.com/api-manager/2.x/policy-mule3- json-threat

asked 18/09/2024
jonathan siu
41 questions
Total 116 questions
Go to page: of 12