Explanation

Correct Answer :  API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane .

*****************************************

> >  We CANNOT use Shared Load balancer to load balance APIs on customer hosted runtimes

> >  For Hybrid deployment models, the on-premises are first connected to Runtime Manager using  Runtime Manager agent .  So, the connection is initiated first from On-premises to Runtime Manager. Then all control can be done from Runtime Manager.

> >  Anypoint Runtime Manager CANNOT ensure automatic HA. Clusters/Server Groups etc should be configured before hand.

Only TRUE statement in the given choices is, API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane. There are several references below to justify this statement.

References :

https://docs.mulesoft.com/runtime-manager/deployment-strategies#hybrid-deployments

https://help.mulesoft.com/s/article/On-Premise-Runtimes-Disconnected-From-US-Control-Plane-June-18th-2018

https://help.mulesoft.com/s/article/Runtime-Manager-cannot-manage-On-Prem-Applications-and-Servers-from-US-Control-Plane-June-25th-2 019

https://help.mulesoft.com/s/article/On-premise-Runtimes-Appear-Disconnected-in-Runtime-Manager-May-29th-2018

============================

============================

Explanation

Correct Answer: 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-clie nt-id-based-policies

Explanation

Correct Answers: API Design and Development and API Runtime Execution and Hosting

*****************************************

> > API Design and Development - Anypoint Studio, Anypoint Design Center, Anypoint Connectors

> > API Runtime Execution and Hosting - Mule Runtimes, CloudHub, Runtime Services

> > API Operations and Management - Anypoint API Manager, Anypoint Exchange

> > API Consumer Management - API Contracts, Public Portals, Anypoint Exchange, API Notebooks

Explanation

Correct Answers :  API Operations and Management and API Consumer Engagement

*****************************************

> >   API Design and Development  - Anypoint Studio, Anypoint Design Center, Anypoint Connectors

> >   API Runtime Execution and Hosting  - Mule Runtimes, CloudHub, Runtime Services

> >   API Operations and Management  - Anypoint API Manager, Anypoint Exchange

> >   API Consumer Management  - API Contracts, Public Portals, Anypoint Exchange, API Notebooks

Bottom of Form

Top of Form

Explanation

Correct Answer: System Layer

The APIs used in an API-led approach to connectivity fall into three categories:

System APIs – these usually access the core systems of record and provide a means of insulating the user from the complexity or any changes to the underlying systems. Once built, many users, can access data without any need to learn the underlying systems and can reuse these APIs in multiple projects.

Process APIs – These APIs interact with and shape data within a single system or across systems (breaking down data silos) and are created here without a dependence on the source systems from which that data originates, as well as the target channels through which that data is delivered.

Experience APIs – Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to-point integrations for each channel. An Experience API is usually created with API-first design principles where the API is designed for the specific user experience in mind.

In the API-led connectivity approach, each layer (System, Process, and Experience) has a distinct purpose:

System APIs : These APIs connect directly to backend systems to expose and unlock data in a standardized way.

Process APIs : These are responsible for orchestrating and processing data across different systems, combining information where needed.

Experience APIs : These are designed for specific user interfaces or applications, often transforming data formats to fit the needs of each consumer application.

Why Option A is Correct :

Process APIs are designed to combine data from multiple systems, which aligns with the function of aggregating policy information from both the life and general insurance systems. This aggregation logic would ideally reside in the Process layer, separating data retrieval from data orchestration.

Moving this functionality to the Process layer enables reusability and modularity, as other Experience APIs or services could also leverage the combined policy data if needed.

Explanation of Incorrect Options :

Option B (Presenting the SOAP-based response) would be managed by the Experience layer, as this layer adapts data formats for specific interfaces.

Option C (Authenticating and maintaining backend connections) would typically be handled within the System layer, where backend integration and security handling occurs.

Option D (Querying data) is the function of System APIs, which access the backend systems directly and expose the raw data without additional processing.

References For further details on API-led architecture and the roles of each layer, refer to MuleSoft’s documentation on API-led connectivity and API layers ​​.

Scenario Analysis :

The API implementation is experiencing high CPU usage (over 90%) during bursts of requests, which correlates with slow response times, as indicated by a 99th percentile response time greater than 120 seconds.

The API implementation is running on Anypoint Runtime Fabric with two non-clustered replicas and has a reserved vCPU of 1.0 and a vCPU limit of 2.0 .

The high CPU usage during bursts suggests that the current resources may not be sufficient to handle peak loads.

Evaluating the Options :

Option A (Correct Answer) : Increasing the vCPU resources for each replica would provide more processing power to handle high traffic volumes, potentially reducing the response time during spikes. Since the CPU usage is consistently high during bursts, this option directly addresses the resource bottleneck.

Option B : Modifying the API client to split requests may reduce individual request load but could be complex to implement on the client side and may not fully address the high CPU issue.

Option C : Increasing the number of replicas could help distribute the load; however, with a high CPU load on each replica, adding more replicas without increasing CPU resources may not fully resolve the problem.

Option D : Throttling the client would reduce the number of requests, but this may not be acceptable if the client needs to maintain a high request rate. It also does not directly address the CPU limitations of the API implementation.

Conclusion :

Option A is the best choice as it addresses the root cause of high CPU usage by increasing the vCPU allocation, allowing the API to handle more requests efficiently. This should be pursued first before considering other options.

Refer to MuleSoft’s documentation on Runtime Fabric and vCPU resource allocation for more details on optimizing API performance in high-demand environments.

Explanation

Correct Answer: Set a timeout of 100ms; that leaves 400ms for other two downstream APIs to complete

*****************************************

Key details to take from the given scenario:

> > Upstream API ' s designed SLA is 500ms (median). Lets ignore maximum SLA response times.

> > This API calls 3 downstream APIs sequentially and all these are of similar complexity.

> > The first downstream API is offering median SLA of 100ms, 80th percentile: 500ms; 95th percentile: 1000ms.

Based on the above details:

> > We can rule out the option which is suggesting to set 50ms timeout. Because, if the median SLA itself being offered is 100ms then most of the calls are going to timeout and time gets wasted in retried them and eventually gets exhausted with all retries. Even if some retries gets successful, the remaining time wont leave enough room for 2nd and 3rd downstream APIs to respond within time.

> > The option suggesting to NOT set a timeout as the invocation of this API is mandatory and so we must wait until it responds is silly. As not setting time out would go against the good implementation pattern and moreover if the first API is not responding within its offered median SLA 100ms then most probably it would either respond in 500ms (80th percentile) or 1000ms (95th percentile). In BOTH cases, getting a successful response from 1st downstream API does NO GOOD because already by this time the Upstream API SLA of 500 ms is breached. There is no time left to call 2nd and 3rd downstream APIs.

> > It is NOT true that no timeout is possible to meet the upstream APIs desired SLA.

As 1st downstream API is offering its median SLA of 100ms, it means MOST of the time we would get the responses within that time. So, setting a timeout of 100ms would be ideal for MOST calls as it leaves enough room of 400ms for remaining 2 downstream API calls.

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.

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.