Get Instant Access to MCPA-Level-1 Practice Exam Questions [Q89-Q103]

February 27, 2025 latestexam 0 Comments

Rate this post

Get Instant Access to MCPA-Level-1 Practice Exam Questions

Reliable Study Materials & Testing Engine for MCPA-Level-1 Exam Success!

Becoming a certified MuleSoft Platform Architect can be a game-changer for your career. MuleSoft Certified Platform Architect – Level 1 certification can open up new job opportunities and help you stand out from other candidates. It demonstrates your expertise in the MuleSoft platform, which is highly valued by employers. Additionally, it can lead to higher salaries and better job security.

MuleSoft MCPA-Level-1 exam is designed to test the skills and knowledge of professionals who work with the MuleSoft Anypoint Platform. MuleSoft Certified Platform Architect – Level 1 certification is intended for architects who design and implement solutions using the MuleSoft Anypoint Platform, and who are responsible for ensuring the success of these solutions in their organizations.

NEW QUESTION 89
A large lending company has developed an API to unlock data from a database server and web server. The API has been deployed to Anypoint Virtual Private Cloud (VPC) on CloudHub 1.0.
The database server and web server are in the customer’s secure network and are not accessible through the public internet. The database server is in the customer’s AWS VPC, whereas the web server is in the customer’s on-premises corporate data center.
How can access be enabled for the API to connect with the database server and the web server?

Set up VPC peering with AWS VPC and a VPN tunnel to the customer’s on-premises corporate data center

Set up VPC peering with AWS VPC and the customer’s on-premises corporate data center

Setup a transit gateway to the customer’s on-premises corporate data center through AWS VPC

Set up VPC peering with the customer’s on-premises corporate data center and a VPN tunnel to AWS VPC

* Scenario Overview:
* The API resides in Anypoint Virtual Private Cloud (VPC) on CloudHub 1.0, where it requires connectivity to both an AWS-hosted database server and an on-premises web server.
* Both servers are isolated from the public internet: the database server is within the customer’s AWS VPC, and the web server is within the customer’s on-premises corporate data center.
* Connectivity Requirements:
* To connect to the AWS database server from the API in Anypoint VPC, VPC peering is ideal.
This would allow a private network connection between the MuleSoft Anypoint VPC and the customer’s AWS VPC, enabling secure, direct access to the database.
* To connect to the on-premises web server, a VPN tunnel is suitable. This would establish a secure, encrypted connection from the Anypoint VPC to the customer’s corporate data center, allowing secure data flow between the API and the on-premises web server.
* Analysis of Options:
* Option A (Correct Answer): Setting up VPC peering with AWS VPC enables private network connectivity with the database server, while a VPN tunnel to the on-premises data center allows secure access to the web server. This combination meets the requirements for secure, controlled access to both resources.
* Option B: VPC peering alone would not suffice because it does not support a connection from the Anypoint VPC directly to an on-premises network. A VPN is necessary for on-premises access.
* Option C: Setting up a transit gateway would provide connectivity within AWS but would not enable direct connectivity from CloudHub to the on-premises network.
* Option D: VPC peering with the on-premises network is not possible because VPC peering is typically used to connect two VPCs, not a VPC with an on-premises network.
* Conclusion:
* Option A is the correct choice, as it provides a complete solution by using VPC peering for AWS VPC connectivity and a VPN tunnel for secure on-premises connectivity. This setup aligns with Anypoint Platform best practices for connecting Anypoint VPCs to both AWS-hosted and on- premises systems, ensuring secure, controlled access to both the database and web server.
For more detailed reference, MuleSoft documentation on Anypoint VPC peering and VPN connectivity provides additional context on best practices for setting up these connections within a hybrid network infrastructure.

NEW QUESTION 90
When using CloudHub with the Shared Load Balancer, what is managed EXCLUSIVELY by the API implementation (the Mule application) and NOT by Anypoint Platform?

The assignment of each HTTP request to a particular CloudHub worker

The logging configuration that enables log entries to be visible in Runtime Manager

The SSL certificates used by the API implementation to expose HTTPS endpoints

The number of DNS entries allocated to the API implementation

The SSL certificates used by the API implementation to expose HTTPS endpoints
*****************************************
>> The assignment of each HTTP request to a particular CloudHub worker is taken care by Anypoint Platform itself. We need not manage it explicitly in the API implementation and in fact we CANNOT manage it in the API implementation.
>> The logging configuration that enables log entries to be visible in Runtime Manager is ALWAYS managed in the API implementation and NOT just for SLB. So this is not something we do EXCLUSIVELY when using SLB.
>> We DO NOT manage the number of DNS entries allocated to the API implementation inside the code.
Anypoint Platform takes care of this.
It is the SSL certificates used by the API implementation to expose HTTPS endpoints that is to be managed EXCLUSIVELY by the API implementation. Anypoint Platform does NOT do this when using SLBs.

NEW QUESTION 91
Which of the below, when used together, makes the IT Operational Model effective?

Create reusable assets, Do marketing on the created assets across organization, Arrange time to time LOB reviews to ensure assets are being consumed or not

Create reusable assets, Make them discoverable so that LOB teams can self-serve and browse the APIs, Get active feedback and usage metrics

Create resuable assets, make them discoverable so that LOB teams can self-serve and browse the APIs

Create reusable assets, Make them discoverable so that LOB teams can self-serve and browse the APIs, Get active feedback and usage metrics.
*****************************************
Diagram, arrow Description automatically generated

NEW QUESTION 92
What is true about the technology architecture of Anypoint VPCs?

The private IP address range of an Anypoint VPC is automatically chosen by CloudHub

Traffic between Mule applications deployed to an Anypoint VPC and on-premises systems can stay within a private network

Each CloudHub environment requires a separate Anypoint VPC

VPC peering can be used to link the underlying AWS VPC to an on-premises (non AWS) private network

NEW QUESTION 93
A code-centric API documentation environment should allow API consumers to investigate and execute API client source code that demonstrates invoking one or more APIs as part of representative scenarios.
What is the most effective way to provide this type of code-centric API documentation environment using Anypoint Platform?

Enable mocking services for each of the relevant APIs and expose them via their Anypoint Exchange entry

Ensure the APIs are well documented through their Anypoint Exchange entries and API Consoles and share these pages with all API consumers

Create API Notebooks and include them in the relevant Anypoint Exchange entries

Make relevant APIs discoverable via an Anypoint Exchange entry

NEW QUESTION 94
An organization wants to make sure only known partners can invoke the organization’s APIs. To achieve this security goal, the organization wants to enforce a Client ID Enforcement policyin API Manager so that only registered partner applications can invoke the organization’s APIs. In what type of API implementation does MuleSoft recommend adding an API proxy to enforce the Client ID Enforcement policy, rather than embedding the policy directly in the application’s JVM?

A Mule 3 application using APIkit

A Mule 3 or Mule 4 application modified with custom Java code

A Mule 4 application with an API specification

A Non-Mule application

A Non-Mule application
*****************************************
>> All type of Mule applications (Mule 3/ Mule 4/ with APIkit/ with Custom Java Code etc) running on Mule Runtimes support the Embedded Policy Enforcement on them.
>> The only option that cannot have or does not support embedded policy enforcement and must have API Proxy is for Non-Mule Applications.
So, Non-Mule application is the right answer.

NEW QUESTION 95
A customer wants to monitor and gain insights about the number of requests coming in a given time period as well as to measure key performance indicators (response times, CPU utilization, number of active APIs).
Which tool provides these data insights?

Anypoint Monitoring

APT Manager

Runtime Alerts

Functional Monitoring

* Understanding Anypoint Monitoring and Its Capabilities:
* Anypoint Monitoring provides comprehensive visibility into Mule applications, offering metrics and analytics such as request counts, response times, CPU utilization, memory usage, and other key performance indicators (KPIs). This tool is designed to help teams monitor API usage, troubleshoot issues, and optimize application performance.
* Evaluating the Options:
* Option A (Correct Answer): Anypoint Monitoring is the ideal tool for this requirement. It provides real-time insights into metrics such as the number of requests, response times, CPU utilization, and active API usage.
* Option B (API Manager): API Manager focuses on API lifecycle management, including applying policies, managing contracts, and setting access controls. It does not provide performance monitoring or KPI tracking.
* Option C (Runtime Alerts): Runtime Alerts can notify users of specific conditions, like high CPU usage, but they do not provide a full suite of metrics or insights over a given time period.
* Option D (Functional Monitoring): Functional Monitoring focuses on functional testing of APIs rather than performance and usage metrics. It does not provide continuous KPI tracking.
* Conclusion:
* Option A is the correct answer. Anypoint Monitoring is the most suitable tool to track the specified metrics, providing detailed insights into API requests, response times, CPU usage, and active API counts.
For further details, refer to MuleSoft’s Anypoint Monitoring documentation on configuring dashboards and tracking performance metrics.

NEW QUESTION 96
A set of tests must be performed prior to deploying API implementations to a staging environment. Due to data security and access restrictions, untested APIs cannot be granted access to the backend systems, so instead mocked data must be used for these tests. The amount of available mocked data and its contents is sufficient to entirely test the API implementations with no active connections to the backend systems. What type of tests should be used to incorporate this mocked data?

Integration tests

Performance tests

Functional tests (Blackbox)

Unit tests (Whitebox)

Correct answer: Unit tests (Whitebox)
*****************************************
Reference:
As per general IT testing practice and MuleSoft recommended practice, Integration and Performance tests should be done on full end to end setup for right evaluation. Which means all end systems should be connected while doing the tests. So, these options are OUT and we are left with Unit Tests and Functional Tests.
As per attached reference documentation from MuleSoft:
Unit Tests – are limited to the code that can be realistically exercised without the need to run it inside Mule itself. So good candidates are Small pieces of modular code, Sub Flows, Custom transformers, Custom components, Custom expression evaluators etc.
Functional Tests – are those that most extensively exercise your application configuration. In these tests, you have the freedom and tools for simulating happy and unhappy paths. You also have the possibility to create stubs for target services and make them success or fail to easily simulate happy and unhappy paths respectively.
As the scenario in the question demands for API implementation to be tested before deployment to Staging and also clearly indicates that there is enough/ sufficient amount of mock data to test the various components of API implementations with no active connections to the backend systems, Unit Tests are the one to be used to incorporate this mocked data.

NEW QUESTION 97
Refer to the exhibit.

A developer is building a client application to invoke an API deployed to the STAGING environment that is governed by a client ID enforcement policy.
What is required to successfully invoke the API?

The client ID and secret for the Anypoint Platform account owning the API in the STAGING environment

The client ID and secret for the Anypoint Platform account’s STAGING environment

The client ID and secret obtained from Anypoint Exchange for the API instance in the STAGING environment

A valid OAuth token obtained from Anypoint Platform and its associated client ID and secret

The client ID and secret obtained from Anypoint Exchange for the API instance in the STAGING environment
*****************************************
>> We CANNOT use the client ID and secret of Anypoint Platform account or any individual environments for accessing the APIs
>> As the type of policy that is enforced on the API in question is “Client ID Enforcment Policy”, OAuth token based access won’t work.
Right way to access the API is to use the client ID and secret obtained from Anypoint Exchange for the API instance in a particular environment we want to work on.
References:
Managing API instance Contracts on API Manager
https://docs.mulesoft.com/api-manager/1.x/request-access-to-api-task
https://docs.mulesoft.com/exchange/to-request-access
https://docs.mulesoft.com/api-manager/2.x/policy-mule3-client-id-based-policies

NEW QUESTION 98
A retail company is using an Order API to accept new orders. The Order API uses a JMS queue to submit orders to a backend order management service. The normal load for orders is being handled using two (2) CloudHub workers, each configured with 0.2 vCore. The CPU load of each CloudHub worker normally runs well below 70%. However, several times during the year the Order API gets four times (4x) the average number of orders. This causes the CloudHub worker CPU load to exceed 90% and the order submission time to exceed 30 seconds. The cause, however, is NOT the backend order management service, which still responds fast enough to meet the response SLA for the Order API. What is the MOST resource-efficient way to configure the Mule application’s CloudHub deployment to help the company cope with this performance challenge?

Permanently increase the size of each of the two (2) CloudHub workers by at least four times (4x) to one (1) vCore

Use a vertical CloudHub autoscaling policy that triggers on CPU utilization greater than 70%

Permanently increase the number of CloudHub workers by four times (4x) to eight (8) CloudHub workers

Use a horizontal CloudHub autoscaling policy that triggers on CPU utilization greater than 70%

Use a horizontal CloudHub autoscaling policy that triggers on CPU utilization greater than
70%
*****************************************
The scenario in the question is very clearly stating that the usual traffic in the year is pretty well handled by the existing worker configuration with CPU running well below 70%. The problem occurs only “sometimes” occasionally when there is spike in the number of orders coming in.
So, based on above, We neither need to permanently increase the size of each worker nor need to permanently increase the number of workers. This is unnecessary as other than those “occasional” times the resources are idle and wasted.
We have two options left now. Either to use horizontal Cloudhub autoscaling policy to automatically increase the number of workers or to use vertical Cloudhub autoscaling policy to automatically increase the vCore size of each worker.
Here, we need to take two things into consideration:
1. CPU
2. Order Submission Rate to JMS Queue
>> From CPU perspective, both the options (horizontal and vertical scaling) solves the issue. Both helps to bring down the usage below 90%.
>> However, If we go with Vertical Scaling, then from Order Submission Rate perspective, as the application is still being load balanced with two workers only, there may not be much improvement in the incoming request processing rate and order submission rate to JMS queue. The throughput would be same as before.
Only CPU utilization comes down.
>> But, if we go with Horizontal Scaling, it will spawn new workers and adds extra hand to increase the throughput as more workers are being load balanced now. This way we can address both CPU and Order Submission rate.
Hence, Horizontal CloudHub Autoscaling policy is the right and best answer.

NEW QUESTION 99
4A developer for a transportation organization is implementing exactly one processing functionality in a Reservation Mule application to process and store passenger records. This Reservation application will be deployed to multiple CloudHub workers/replicas. It is possible that several external systems could send duplicate passenger records to the Reservation application.
An appropriate storage mechanism must be selected to help the Reservation application process each passenger record exactly once as much as possible. The selected storage mechanism must be shared by all the CloudHub workers/replicas in order to synchronize the state information to assist attempting exactly once processing of each passenger record by the deployed Reservation Mule application.
Which type of simple storage mechanism in Anypoint Platform allows the Reservation Mule application to update and share data between the CloudHub workers/replicas exactly once, with minimal development effort?

Persistent Object Store

Runtime Fabric Object Store

Non-persistent Object Store

In-memory Mule Object Store

* Processing Requirements and Storage Mechanism:
* The Reservation Mule application will be deployed to multiple CloudHub workers/replicas, meaning that each worker must share state information to handle records exactly once. This requires a shared storage mechanism where state can be stored and accessed by multiple instances to avoid duplicate processing of the same records.
* A Persistent Object Store in Anypoint Platform can be used to store records in a way that is accessible across multiple workers, providing a reliable mechanism for “exactly once” processing.
* Evaluating the Options:
* Option A (Correct Answer): A Persistent Object Store is designed to retain data across different application instances and can be shared by all workers on CloudHub. It helps achieve idempotency by ensuring that a record is processed exactly once.
* Option B: Runtime Fabric Object Store is used for applications deployed in Anypoint Runtime Fabric, not CloudHub. This option would not be compatible with the CloudHub deployment.
* Option C: A Non-persistent Object Store does not retain data across application restarts or different instances, making it unsuitable for the requirement of synchronized storage for exactly- once processing.
* Option D: An In-memory Mule Object Store is local to each worker and is not shared across instances, so it does not meet the requirement for a shared storage mechanism accessible to all CloudHub workers.
* Conclusion:
* Option A is the correct answer, as a Persistent Object Store allows data sharing across multiple CloudHub workers, enabling them to synchronize and achieve “exactly once” processing of passenger records with minimal development effort.
Refer to MuleSoft’s documentation on Object Store configurations and usage for best practices on handling state across distributed instances.

NEW QUESTION 100
An API implementation is deployed on a single worker on CloudHub and invoked by external API clients (outside of CloudHub). How can an alert be set up that is guaranteed to trigger AS SOON AS that API implementation stops responding to API invocations?

Implement a heartbeat/health check within the API and invoke it from outside the Anypoint Platform and alert when the heartbeat does not respond

Configure a “worker not responding” alert in Anypoint Runtime Manager

Handle API invocation exceptions within the calling API client and raise an alert from that API client when the API Is unavailable

Create an alert for when the API receives no requests within a specified time period

Correct answer: Configure a “Worker not responding” alert in Anypoint Runtime Manager.
*****************************************
>> All the options eventually helps to generate the alert required when the application stops responding.
>> However, handling exceptions within calling API and then raising alert from API client is inappropriate and silly. There could be many API clients invoking the API implementation and it is not ideal to have this setup consistently in all of them. Not a realistic way to do.
>> Implementing a health check/ heartbeat with in the API and calling from outside to detmine the health sounds OK but needs extra setup for it and same time there are very good chances of generating false alarms when there are any intermittent network issues between external tool calling the health check API on API implementation. The API implementation itself may not have any issues but due to some other factors some false alarms may go out.
>> Creating an alert in API Manager when the API receives no requests within a specified time period would actually generate realistic alerts but even here some false alarms may go out when there are genuinely no requests from API clients.
The best and right way to achieve this requirement is to setup an alert on Runtime Manager with a condition “Worker not responding”. This would generate an alert AS SOON AS the workers become unresponsive.

NEW QUESTION 101
Which component monitors APIs and endpoints at scheduled intervals, receives reports about whether tests pass or fail, and displays statistics about API and endpoint performance?

API Analytics

Anypoint Monitoring dashboards

APT Functional Monitoring

Anypoint Runtime Manager alerts

* Understanding API Functional Monitoring:
* API Functional Monitoring is a feature within MuleSoft’s Anypoint Platform that enables users to monitor the health and performance of APIs and endpoints by running functional tests at scheduled intervals.
* It checks whether APIs are functioning as expected by running test calls and then evaluating if the response meets the desired conditions. This is particularly useful for testing endpoint availability, checking for specific data in responses, and measuring API performance over time.
* Component Features:
* Scheduled Intervals: Functional monitoring allows configuring tests to run at regular intervals, such as every minute, hour, or day, depending on the monitoring requirements.
* Reports on Test Pass/Fail Status: After each test run, API Functional Monitoring reports whether the API passed or failed the test conditions.
* Performance Statistics: It displays metrics like average response time, success rate, and error rates, giving insights into API health and performance.
* Evaluating the Options:
* Option A (API Analytics): API Analytics provides insights on API usage and metrics but does not involve scheduled tests for pass/fail status or endpoint health checks.
* Option B (Anypoint Monitoring Dashboards): These dashboards display API metrics but do not actively test API endpoints or provide pass/fail reporting on a scheduled basis.
* Option C (Correct Answer): API Functional Monitoring fits the description, as it is designed to monitor API and endpoint health with scheduled test runs and display statistics about performance.
* Option D (Anypoint Runtime Manager Alerts): Runtime Manager alerts notify users of issues with application status but do not actively test endpoints at scheduled intervals.
* Conclusion:
* Option C (API Functional Monitoring) is the correct answer because it provides the necessary tools to test API functionality, monitor endpoint health, and display performance statistics in real- time.
Refer to MuleSoft documentation on API Functional Monitoring for further guidance on setting up and configuring these tests in Anypoint Platform.

NEW QUESTION 102
What CANNOT be effectively enforced using an API policy in Anypoint Platform?

Guarding against Denial of Service attacks

Maintaining tamper-proof credentials between APIs

Logging HTTP requests and responses

Backend system overloading

NEW QUESTION 103
What is a key requirement when using an external Identity Provider for Client Management in Anypoint Platform?

Single sign-on is required to sign in to Anypoint Platform

The application network must include System APIs that interact with the Identity Provider

To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider

APIs managed by Anypoint Platform must be protected by SAML 2.0 policies

Explanation/Reference: https://www.folkstalk.com/2019/11/mulesoft-integration-and-platform.html

Loading …

Validate your Skills with Updated MCPA-Level-1 Exam Questions & Answers and Test Engine: https://www.latestcram.com/MCPA-Level-1-exam-cram-questions.html

Related Certifications

512-50 (1)
712-50 (1)
ECSS (1)
EC0-349 (1)
212-89 (1)

Free Cram & Latest Exams Dumps

Get Instant Access to MCPA-Level-1 Practice Exam Questions [Q89-Q103]

leave a comment Cancel reply

Related Certifications

Recent Posts

Archives

Categories