Mulesoft MCIA-LEVEL1 Online Practice Questions and Exam Preparation

Mulesoft MCIA-LEVEL1 Online Questions & Answers

• Question 271:

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

  A. Implement required changes to the Process API implementation so that whenever possible, the Process API's RAML definition remains unchanged
  B. Update the RAML definition of the current Process API and notify API client developers by sending them links to the updated RAML definition
  C. Postpone changes until API consumers acknowledge they are ready to migrate to a new Process API or API version
  D. 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
  A. Implement required changes to the Process API implementation so that whenever possible, the Process API's RAML definition remains unchanged

  ---

  # 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.

• Question 272:

  An API implementation is being developed to expose data from a production database via HTTP requests. The API implementation executes a database SELECT statement that is dynamically created based upon data received from each incoming HTTP request. The developers are planning to use various types of testing to make sure the Mule application works as expected, can handle specific workloads, and behaves correctly from an API consumer perspective. What type of testing would typically mock the results from each SELECT statement rather than actually execute it in the production database?

  A. Unit testing (white box)
  B. Integration testing
  C. Functional testing (black box)
  D. Performance testing
  A. Unit testing (white box)

  ---

  In Unit testing instead of using actual backends, stubs are used for the backend services. This ensures that developers are not blocked and have no dependency on other systems. In Unit testing instead of using actual backends, stubs are used for the backend services. This ensures that developers are not blocked and have no dependency on other systems. Below are the typical characteristics of unit testing. -- Unit tests do not require deployment into any special environment, such as a staging environment -- Unit tests san be run from within an embedded Mule runtime -- Unit tests can/should be implemented using MUnit -- For read-only interactions to any dependencies (such as other APIs): allowed to invoke production endpoints -- For write interactions: developers must implement mocks using MUnit -- Require knowledge of the implementation details of the API implementation under test

• Question 273:

  Which API policy is most appropriate to protect publicly exposed APIs from excessively large or deeply nested JSON payloads?

  A. Rate limiting policy
  B. Client ID enforcement
  C. JSON threat protection
  D. IP whitelist policy
  C. JSON threat protection

  ---

  JSON threat protection limits payload size and depth to protect APIs from malicious JSON-based attacks.

• Question 274:

  Refer to the exhibit.

  

  A Mule application has an HTTP Listener that accepts HTTP DELETE requests. This Mule application Is deployed to three CloudHub workers under the control of the CloudHub Shared Load Balancer.

  A web client makes a sequence of requests to the Mule application's public URL. How is this sequence of web client requests distributed among the HTTP Listeners running in the three CloudHub workers?

  A. Each request is routed to the PRIMARY CloudHub worker in the PRIMARY Availability Zone (AZ)
  B. Each request is routed to ONE ARBiTRARY CloudHub worker in the PRIMARY Availability Zone (AZ)
  C. Each request Is routed to ONE ARBiTRARY CloudHub worker out of ALL three CloudHub workers
  D. Each request is routed (scattered) to ALL three CloudHub workers at the same time
  C. Each request Is routed to ONE ARBiTRARY CloudHub worker out of ALL three CloudHub workers

  ---

  Correct behavior is Each request is routed to ONE ARBITRARY CloudHub worker out of ALL three CloudHub workers

• Question 275:

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

  A. Custom circuit breaker
  B. Client ID enforcement
  C. Rate limiting
  D. JSON threat protection
  D. JSON threat protection

  ---

  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

• Question 276:

  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?

  

  A. 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.
  B. One set of APIs (Experience API, Process API, and System API) for the web app, and another set for the mobile app.
  C. 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
  D. 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.
  C. 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

  ---

  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

  

  Description automatically generated with low confidence 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

  

• Question 277:

  A company wants its users to log in to Anypoint Platform using the company's own internal user credentials. To achieve this, the company needs to integrate an external identity provider (IdP) with the company's Anypoint Platform master organization, but SAML 2.0 CANNOT be used. Besides SAML 2.0, what single-sign-on standard can the company use to integrate the IdP with their Anypoint Platform master organization?

  A. SAML 1.0
  B. OAuth 2.0
  C. Basic Authentication
  D. OpenID Connect
  D. OpenID Connect

  ---

  As the Anypoint Platform organization administrator, you can configure identity management in Anypoint Platform to set up users for single sign-on (SSO). Configure identity management using one of the following single sign-on standards: 1) OpenID Connect: End user identity verification by an authorization server including SSO 2) SAML 2.0: Web-based authorization including cross-domain SSO

• Question 278:

  A corporation has deployed Mule applications to different customer-hosted Mule runtimes. Mule applications deployed to these Mule runtimes are managed by Anypoint Platform.

  What needs to be installed or configured (if anything) to monitor these Mule applications from Anypoint Monitoring, and how is monitoring data from each Mule application sent to Anypoint Monitoring?

  A. Enable monitoring of individual Mule applications from the Runtime Manager application settings. Runtime Manager sends monitoring data to Anypoint Monitoring for each deployed Mule application.
  B. Install a Runtime Manager agent on each Mule runtime. Each Runtime Manager agent sends monitoring data from the Mule applications running in its Mule runtime to Runtime Manager, then Runtime Manager sends monitoring data to Anypoint Monitoring.
  C. Leave the out-of-the-box Anypoint Monitoring agent unchanged in its default Mule runtime installation. Each Anypoint Monitoring agent sends monitoring data from the Mule applications running in its Mule runtime to Runtime Manager, then Runtime Manager sends
  D. monitoring data to Anypoint Monitoring.
  E. Install an Anypoint Monitoring agent on each Mule runtime. Each Anypoint Monitoring agent sends monitoring data from the Mule applications running in its Mule runtime to Anypoint Monitoring.
  D. monitoring data to Anypoint Monitoring.

  ---

  To monitor Mule applications deployed to different customer-hosted Mule runtimes using Anypoint Monitoring, follow these steps:

  Install Anypoint Monitoring Agent: Install an Anypoint Monitoring agent on each Mule runtime. This agent is responsible for collecting monitoring data from the Mule applications running on that runtime.

  Data Transmission: Each Anypoint Monitoring agent sends the collected monitoring data directly to Anypoint Monitoring. This ensures that performance metrics, logs, and other relevant data are available for analysis and monitoring within the Anypoint Platform.

  By using the Anypoint Monitoring agent, organizations can effectively monitor their Mule applications across various environments, ensuring visibility and operational efficiency.

  References

  MuleSoft Documentation on Anypoint Monitoring Installing and Configuring Anypoint Monitoring Agent

• Question 279:

  Refer to the exhibit.

  

  One of the backend systems invoked by an API implementation enforces rate limits on the number of requests a particular client can make. Both the backend system and the API implementation are deployed to several non-production environments in addition to production.

  Rate limiting of the backend system applies to all non-production environments. The production environment, however, does NOT have any rate limiting.

  What is the most effective approach to conduct performance tests of the API implementation in a staging (non-production) environment?

  A. Create a mocking service that replicates the backend system's production performance characteristics. Then configure the API implementation to use the mocking service and conduct the performance tests
  B. Use MUnit to simulate standard responses from the backend system then conduct performance tests to identify other bottlenecks in the system
  C. Include logic within the API implementation that bypasses invocations of the backend system in a performance test situation. Instead invoking local stubs that replicate typical backend system responses then conduct performance tests using this API Implementation
  D. Conduct scaled-down performance tests in the staging environment against the rate limited backend system then upscale performance results to full production scale
  A. Create a mocking service that replicates the backend system's production performance characteristics. Then configure the API implementation to use the mocking service and conduct the performance tests

  ---

  Correct answer is Create a mocking service that replicates the backend system's production performance characteristics. Then configure the API implementation to use the mocking service and conduct the performance tests

  # MUnit is for only Unit and integration testing for APIs and Mule apps. Not for performance Testing, even if it has the ability to Mock the backend.

  # Bypassing the backend invocation defeats the whole purpose of performance testing. Hence it is not a valid answer.

  # Scaled down performance tests cant be relied upon as performance of API's is not linear against load.

• Question 280:

  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. A fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design
  B. The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region
  C. The FQDNs are determined by the application name, but can be modified by an administrator after deployment
  D. The FQDNs are determined by both the application name and the region
  D. The FQDNs are determined by both the application name and the region

  ---

  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