An organization uses various cloud-based SaaS systems and multiple on-premises systems. The on-premises systems are an important part of the organization's application network and can only be accessed from within the organization's intranet.
What is the best way to configure and use Anypoint Platform to support integrations with both the cloud-based SaaS systems and on-premises systems?
A) Use CloudHub-deployed Mule runtimes in an Anypoint VPC managed by Anypoint Platform Private Cloud Edition control plane
B) Use CloudHub-deployed Mule runtimes in the shared worker cloud managed by the MuleSoft-hosted Anypoint Platform control plane
C) Use an on-premises installation of Mule runtimes that are completely isolated with NO external network access, managed by the Anypoint Platform Private Cloud Edition control plane
D) Use a combination of Cloud Hub-deployed and manually provisioned on-premises Mule runtimes managed by the MuleSoft-hosted Anypoint Platform control plane
Answer : B
Correct Answe r: Use a combination of CloudHub-deployed and manually provisioned on-premises Mule runtimes managed by the MuleSoft-hosted Platform control plane.
*****************************************
Key details to be taken from the given scenario:
>> Organization uses BOTH cloud-based and on-premises systems
>> On-premises systems can only be accessed from within the organization's intranet
Let us evaluate the given choices based on above key details:
>> CloudHub-deployed Mule runtimes can ONLY be controlled using MuleSoft-hosted control plane. We CANNOT use Private Cloud Edition's control plane to control CloudHub Mule Runtimes. So, option suggesting this is INVALID
>> Using CloudHub-deployed Mule runtimes in the shared worker cloud managed by the MuleSoft-hosted Anypoint Platform is completely IRRELEVANT to given scenario and silly choice. So, option suggesting this is INVALID
>> Using an on-premises installation of Mule runtimes that are completely isolated with NO external network access, managed by the Anypoint Platform Private Cloud Edition control plane would work for On-premises integrations. However, with NO external access, integrations cannot be done to SaaS-based apps. Moreover CloudHub-hosted apps are best-fit for integrating with SaaS-based applications. So, option suggesting this is BEST WAY.
The best way to configure and use Anypoint Platform to support these mixed/hybrid integrations is to use a combination of CloudHub-deployed and manually provisioned on-premises Mule runtimes managed by the MuleSoft-hosted Platform control plane.
Which layer in the API-led connectivity focuses on unlocking key systems, legacy systems, data sources etc and exposes the functionality?
Answer : C
Correct Answe r: 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.
To minimize operation costs, a customer wants to use a CloudHub 1.0 solution. The customer's requirements are:
* Separate resources with two Business groups
* High-availability (HA) for all APIs
* Route traffic via Dedicated load balancer (DLBs)
* Separate environments into production and non-production
Which solution meets the customer's needs?
Answer : B
Understanding the Requirements:
Business Groups: The solution must support two business groups, which typically require separate VPCs for logical separation.
High Availability (HA): Requires deploying resources across multiple availability zones.
Dedicated Load Balancer (DLB): Traffic should be routed via DLBs, which operate within VPCs on CloudHub.
Separate Environments: There needs to be separation between production and non-production environments.
Evaluating the Options:
Option A: Using a single production and non-production VPC and differentiating business groups via availability zones is not ideal as it does not provide full separation for each business group, and using maximum CIDR allocation is wasteful.
Option B (Correct Answer): Creating separate production and non-production VPCs per business group with minimized CIDR blocks, multiple availability zones, and multiple workers per application for HA meets all requirements effectively.
Option C: While this option separates VPCs per business group, it does not fully address the requirement for HA across availability zones by specifying multi-zone deployment only during API deployment, which may not guarantee redundancy.
Option D: Configuring subnets to differentiate business groups within a single production and non-production VPC does not fully separate the business groups, which is a requirement.
Conclusion:
Option B is the best choice as it meets the requirements for high availability, business group separation, and cost efficiency by using minimized CIDR allocations and deploying multiple workers across availability zones.
For further reference, refer to MuleSoft's documentation on VPC configuration and high availability deployment strategies.
Several times a week, an API implementation shows several thousand requests per minute in an Anypoint Monitoring dashboard, Between these bursts, the
dashboard shows between two and five requests per minute. The API implementation is running on Anypoint Runtime Fabric with two non-clustered replicas, reserved vCPU 1.0
and vCPU Limit 2.0.
An API consumer has complained about slow response time, and the dashboard shows the 99 percentile is greater than 120 seconds at the time of the complaint. It also shows
greater than 90% CPU usage during these time periods.
In manual tests in the QA environment, the API consumer has consistently reproduced the slow response time and high CPU usage, and there were no other API requests at
this time. In a brainstorming session, the engineering team has created several proposals to reduce the response time for requests.
Which proposal should be pursued first?
Answer : A
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.
An online store's marketing team has noticed an increase in customers leaving online baskets without checking out. They suspect a technology issue is at the root cause of the baskets being left behind. They approach the Center for Enablement to ask for help identifying the issue. Multiple APIs from across all the layers of their application network are involved in the shopping application.
Which feature of the Anypoint Platform can be used to view metrics from all involved APIs at the same time?
Answer : B
Understanding the Need for Cross-API Monitoring:
The Center for Enablement (C4E) needs to investigate potential technical issues across multiple APIs in the application network that may be causing customers to abandon their carts.
This requires a solution that allows viewing metrics across several APIs in real-time to identify any performance issues or bottlenecks.
Evaluating Anypoint Platform Features:
Built-in Dashboards: Anypoint Platform provides built-in dashboards in Anypoint Monitoring, allowing teams to view metrics from multiple APIs in a single interface. This feature is designed to monitor API performance, latency, errors, and throughput, and is ideal for tracking performance across all layers of the application network.
Custom Dashboards: While custom dashboards allow for more tailored views, the built-in dashboards already aggregate metrics for multiple APIs, making it unnecessary to build a custom solution for this scenario.
Functional Monitoring: This feature is used to set up tests to monitor specific API functionality and uptime but is not suited for tracking metrics across multiple APIs in real-time.
API Manager: API Manager primarily focuses on managing API policies, contracts, and access control rather than providing detailed, real-time metrics across the entire application network.
Conclusion:
Option B (Built-in dashboards) is the best choice because it provides a comprehensive view of metrics from all APIs involved, enabling the C4E team to quickly identify any issues that may be contributing to abandoned shopping carts.
Refer to MuleSoft's documentation on Anypoint Monitoring and built-in dashboards for more details on configuring and using these dashboards effectively.
An organization wants MuleSoft-hosted runtime plane features (such as HTTP load balancing, zero downtime, and horizontal and vertical scaling) in its Azure environment. What runtime plane minimizes the organization's effort to achieve these features?
Answer : A
Correct Answe r: Anypoint Runtime Fabric
*****************************************
>> When a customer is already having an Azure environment, It is not at all an ideal approach to go with hybrid model having some Mule Runtimes hosted on Azure and some on MuleSoft. This is unnecessary and useless.
>> CloudHub is a Mulesoft-hosted Runtime plane and is on AWS. We cannot customize to point CloudHub to customer's Azure environment.
>> Anypoint Platform for Pivotal Cloud Foundry is specifically for infrastructure provided by Pivotal Cloud Foundry
>> Anypoint Runtime Fabric is right answer as it is a container service that automates the deployment and orchestration of Mule applications and API gateways. Runtime Fabric runs within a customer-managed infrastructure on AWS, Azure, virtual machines (VMs), and bare-metal servers.
-Some of the capabilities of Anypoint Runtime Fabric include:
-Isolation between applications by running a separate Mule runtime per application.
-Ability to run multiple versions of Mule runtime on the same set of resources.
-Scaling applications across multiple replicas.
-Automated application fail-over.
-Application management with Anypoint Runtime Manager.
A TemperatureSensors API instance is defined in API Manager in the PROD environment of the CAR_FACTORY business group. An AcmelemperatureSensors Mule
application implements this API instance and is deployed from Runtime Manager to the PROD environment of the CAR_FACTORY business group. A policy that requires a valid
client ID and client secret is applied in API Manager to the API instance.
Where can an API consumer obtain a valid client ID and client secret to call the AcmeTemperatureSensors Mule application?
Answer : D
When an API policy requiring a client ID and client secret is applied to an API instance in API Manager, API consumers must obtain these credentials through a registered client application. Here's how it works:
Anypoint Exchange and Client Applications:
To access secured APIs, API consumers need to create or register a client application in Anypoint Exchange. This process involves requesting access to the specific API, and once approved, the consumer can retrieve the client ID and client secret associated with the application.
Why Option D is Correct:
Option D accurately describes the process, as the client ID and client secret are generated and managed within Anypoint Exchange. API consumers can use these credentials to authenticate with the TemperatureSensors API.
of Incorrect Options:
Option A (secrets manager) is incorrect because client credentials for API access are not managed via secrets manager.
Option B (API Manager) is incorrect as API Manager manages policies but does not provide client-specific credentials.
Option C (Access Management) does not apply, as Access Management is primarily used for user roles and permissions, not API client credentials.
Reference For further details on managing client applications in Anypoint Exchange, consult MuleSoft documentation on client application registration and API security policies.