Practice Free MuleSoft Platform Architect I Exam Online Questions
Question #41
A company stores financial transaction data in two legacy systems. For each legacy system, a separate, dedicated System API (SAPI) exposes data for that legacy system. A Process API (PAPI) merges the data retrieved from ail of the System APIs into a common format. Several API clients call the PAPI through its public domain name.
The company now wants to expose a subset of financial data to a newly developed mobile application that uses a different Bounded Context Data Model. The company wants to follow MuleSoft’s best practices for building out an effective application network.
Following MuleSoft’s best practices, how can the company expose financial data needed by the mobile application in a way that minimizes the impact on the currently running API clients, API implementations, and support asset reuse?
- A . Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2. - B . Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2. - C . Create a new mobile Experince API (EAPI) chat exposes that subset of PAPI endpoints. Add transformtion login to the mobile Experince API implementation to make mobile data compatible with the required PAPIs.
- D . Develop and deploy is new PAPI implementation with data transformation and … login to support this required endpoints of both mobile and web clients.
Deploy an API Proxy with an endpoint from API Manager that redirect the existing PAPI endpoints to the new PAPI.
Correct Answer: A
A
Explanation:
To achieve the goal of exposing financial data to a new mobile application while following MuleSoft’s best practices, the company should follow an API-led connectivity approach. This approach ensures minimal disruption to existing clients, maximizes reusability, and respects the separation of concerns across API layers.
of Solution:
Experience APIs for Client-Specific Requirements:
Create two new Experience APIs (EAPI-1 and EAPI-2) for the mobile application, tailored to meet the specific data and format requirements of the mobile application. These APIs encapsulate the client-specific needs and provide a custom interface without impacting other clients.
Process API Layer for Data Transformation:
By adding Mobile PAPI-2, we allow the mobile application to access the required subset of data, formatted according to the mobile application’s requirements. This approach ensures that data transformation and aggregation are handled in the Process layer, maintaining consistency and reusability across different applications.
Reuse of System APIs:
Both the new Mobile PAPI-2 and existing PAPI-1 access data from System APIs (SAPI-1 and SAPI-2), which continue to expose data from each legacy system in a consistent, reusable manner. This avoids duplicating logic and ensures that data access remains centralized and manageable.
Why Option A is Correct:
Option A aligns with MuleSoft’s best practices by isolating client-specific requirements in the Experience layer, utilizing Process APIs for data orchestration and transformation, and maintaining reusable System APIs for backend access.
This approach also ensures that the current API clients are not impacted, as new clients (e.g., the mobile app) interact with newly defined Experience APIs without modifying the existing API setup. of Incorrect Options:
Option B: This option seems similar but lacks clarity on the separation of mobile-specific requirements and does not explicitly mention data transformation, which is essential in this scenario.
Option C: Creating a single mobile Experience API that exposes a subset of PAPI endpoints directly adds unnecessary complexity and may violate the separation of concerns, as transformation logic should not be in the Experience layer.
Option D: Deploying a new PAPI and using an API Proxy to redirect existing endpoints would add unnecessary complexity, disrupt the current API clients, and increase maintenance efforts.
Reference
For additional guidance, refer to MuleSoft documentation on API-led connectivity best practices and best practices for structuring Experience, Process, and System APIs.
A
Explanation:
To achieve the goal of exposing financial data to a new mobile application while following MuleSoft’s best practices, the company should follow an API-led connectivity approach. This approach ensures minimal disruption to existing clients, maximizes reusability, and respects the separation of concerns across API layers.
of Solution:
Experience APIs for Client-Specific Requirements:
Create two new Experience APIs (EAPI-1 and EAPI-2) for the mobile application, tailored to meet the specific data and format requirements of the mobile application. These APIs encapsulate the client-specific needs and provide a custom interface without impacting other clients.
Process API Layer for Data Transformation:
By adding Mobile PAPI-2, we allow the mobile application to access the required subset of data, formatted according to the mobile application’s requirements. This approach ensures that data transformation and aggregation are handled in the Process layer, maintaining consistency and reusability across different applications.
Reuse of System APIs:
Both the new Mobile PAPI-2 and existing PAPI-1 access data from System APIs (SAPI-1 and SAPI-2), which continue to expose data from each legacy system in a consistent, reusable manner. This avoids duplicating logic and ensures that data access remains centralized and manageable.
Why Option A is Correct:
Option A aligns with MuleSoft’s best practices by isolating client-specific requirements in the Experience layer, utilizing Process APIs for data orchestration and transformation, and maintaining reusable System APIs for backend access.
This approach also ensures that the current API clients are not impacted, as new clients (e.g., the mobile app) interact with newly defined Experience APIs without modifying the existing API setup. of Incorrect Options:
Option B: This option seems similar but lacks clarity on the separation of mobile-specific requirements and does not explicitly mention data transformation, which is essential in this scenario.
Option C: Creating a single mobile Experience API that exposes a subset of PAPI endpoints directly adds unnecessary complexity and may violate the separation of concerns, as transformation logic should not be in the Experience layer.
Option D: Deploying a new PAPI and using an API Proxy to redirect existing endpoints would add unnecessary complexity, disrupt the current API clients, and increase maintenance efforts.
Reference
For additional guidance, refer to MuleSoft documentation on API-led connectivity best practices and best practices for structuring Experience, Process, and System APIs.
Question #41
A company stores financial transaction data in two legacy systems. For each legacy system, a separate, dedicated System API (SAPI) exposes data for that legacy system. A Process API (PAPI) merges the data retrieved from ail of the System APIs into a common format. Several API clients call the PAPI through its public domain name.
The company now wants to expose a subset of financial data to a newly developed mobile application that uses a different Bounded Context Data Model. The company wants to follow MuleSoft’s best practices for building out an effective application network.
Following MuleSoft’s best practices, how can the company expose financial data needed by the mobile application in a way that minimizes the impact on the currently running API clients, API implementations, and support asset reuse?
- A . Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2. - B . Add two new Experience APIs (EAPI-i and EAPI-2}.
Add Mobile PAPI-2 to expose the Intended subset of financial data as requested.
Both PAPIs access the Legacy Systems via SAPI-1 and SAP]-2. - C . Create a new mobile Experince API (EAPI) chat exposes that subset of PAPI endpoints. Add transformtion login to the mobile Experince API implementation to make mobile data compatible with the required PAPIs.
- D . Develop and deploy is new PAPI implementation with data transformation and … login to support this required endpoints of both mobile and web clients.
Deploy an API Proxy with an endpoint from API Manager that redirect the existing PAPI endpoints to the new PAPI.
Correct Answer: A
A
Explanation:
To achieve the goal of exposing financial data to a new mobile application while following MuleSoft’s best practices, the company should follow an API-led connectivity approach. This approach ensures minimal disruption to existing clients, maximizes reusability, and respects the separation of concerns across API layers.
of Solution:
Experience APIs for Client-Specific Requirements:
Create two new Experience APIs (EAPI-1 and EAPI-2) for the mobile application, tailored to meet the specific data and format requirements of the mobile application. These APIs encapsulate the client-specific needs and provide a custom interface without impacting other clients.
Process API Layer for Data Transformation:
By adding Mobile PAPI-2, we allow the mobile application to access the required subset of data, formatted according to the mobile application’s requirements. This approach ensures that data transformation and aggregation are handled in the Process layer, maintaining consistency and reusability across different applications.
Reuse of System APIs:
Both the new Mobile PAPI-2 and existing PAPI-1 access data from System APIs (SAPI-1 and SAPI-2), which continue to expose data from each legacy system in a consistent, reusable manner. This avoids duplicating logic and ensures that data access remains centralized and manageable.
Why Option A is Correct:
Option A aligns with MuleSoft’s best practices by isolating client-specific requirements in the Experience layer, utilizing Process APIs for data orchestration and transformation, and maintaining reusable System APIs for backend access.
This approach also ensures that the current API clients are not impacted, as new clients (e.g., the mobile app) interact with newly defined Experience APIs without modifying the existing API setup. of Incorrect Options:
Option B: This option seems similar but lacks clarity on the separation of mobile-specific requirements and does not explicitly mention data transformation, which is essential in this scenario.
Option C: Creating a single mobile Experience API that exposes a subset of PAPI endpoints directly adds unnecessary complexity and may violate the separation of concerns, as transformation logic should not be in the Experience layer.
Option D: Deploying a new PAPI and using an API Proxy to redirect existing endpoints would add unnecessary complexity, disrupt the current API clients, and increase maintenance efforts.
Reference
For additional guidance, refer to MuleSoft documentation on API-led connectivity best practices and best practices for structuring Experience, Process, and System APIs.
A
Explanation:
To achieve the goal of exposing financial data to a new mobile application while following MuleSoft’s best practices, the company should follow an API-led connectivity approach. This approach ensures minimal disruption to existing clients, maximizes reusability, and respects the separation of concerns across API layers.
of Solution:
Experience APIs for Client-Specific Requirements:
Create two new Experience APIs (EAPI-1 and EAPI-2) for the mobile application, tailored to meet the specific data and format requirements of the mobile application. These APIs encapsulate the client-specific needs and provide a custom interface without impacting other clients.
Process API Layer for Data Transformation:
By adding Mobile PAPI-2, we allow the mobile application to access the required subset of data, formatted according to the mobile application’s requirements. This approach ensures that data transformation and aggregation are handled in the Process layer, maintaining consistency and reusability across different applications.
Reuse of System APIs:
Both the new Mobile PAPI-2 and existing PAPI-1 access data from System APIs (SAPI-1 and SAPI-2), which continue to expose data from each legacy system in a consistent, reusable manner. This avoids duplicating logic and ensures that data access remains centralized and manageable.
Why Option A is Correct:
Option A aligns with MuleSoft’s best practices by isolating client-specific requirements in the Experience layer, utilizing Process APIs for data orchestration and transformation, and maintaining reusable System APIs for backend access.
This approach also ensures that the current API clients are not impacted, as new clients (e.g., the mobile app) interact with newly defined Experience APIs without modifying the existing API setup. of Incorrect Options:
Option B: This option seems similar but lacks clarity on the separation of mobile-specific requirements and does not explicitly mention data transformation, which is essential in this scenario.
Option C: Creating a single mobile Experience API that exposes a subset of PAPI endpoints directly adds unnecessary complexity and may violate the separation of concerns, as transformation logic should not be in the Experience layer.
Option D: Deploying a new PAPI and using an API Proxy to redirect existing endpoints would add unnecessary complexity, disrupt the current API clients, and increase maintenance efforts.
Reference
For additional guidance, refer to MuleSoft documentation on API-led connectivity best practices and best practices for structuring Experience, Process, and System APIs.
Question #43
A company is building an application network using MuleSoft’s recommendations for various API layers.
What is the main (default) role of a process API in an application network?
- A . To secure and optimize the data synchronization processing of large data dumps between back-end systems
- B . To manage and process the secure direct communication between a back-end system and an end-user client of mobile device in the application network
- C . To automate parts of business processes by coordinating and orchestrating the invocation of other APIs in the application network
- D . To secure, Manage, and process communication with specific types of end-user client applications or devices in the application network
Correct Answer: C
C
Explanation:
Role of Process API in API-led Connectivity:
In MuleSoft’s API-led connectivity approach, a Process API is used to coordinate, aggregate, and orchestrate data from various System APIs. It is primarily responsible for implementing business logic that spans multiple backend systems or entities, transforming and combining data as needed to support business processes.
Process APIs are not directly exposed to end-user clients; rather, they work between System APIs and Experience APIs, providing business logic and orchestration capabilities.
Evaluating the Options:
Option A: Process APIs are not typically responsible for large data dumps or data synchronization.
That function would be handled by a System API or a specialized batch process.
Option B: Managing direct, secure communication between back-end systems and end-user clients is typically the role of Experience APIs rather than Process APIs.
Option C (Correct Answer): Process APIs are designed to coordinate and orchestrate calls to multiple other APIs in the network, which supports the automation of business processes.
Option D: Securing and managing communication with end-user clients is typically the role of
Experience APIs, not Process APIs.
Conclusion:
Option C is the correct answer, as the main role of a Process API is to coordinate and orchestrate interactions between other APIs, enabling business processes to function seamlessly across multiple systems.
Refer to MuleSoft’s API-led connectivity documentation for further explanation of the roles and responsibilities of Process APIs in an application network.
C
Explanation:
Role of Process API in API-led Connectivity:
In MuleSoft’s API-led connectivity approach, a Process API is used to coordinate, aggregate, and orchestrate data from various System APIs. It is primarily responsible for implementing business logic that spans multiple backend systems or entities, transforming and combining data as needed to support business processes.
Process APIs are not directly exposed to end-user clients; rather, they work between System APIs and Experience APIs, providing business logic and orchestration capabilities.
Evaluating the Options:
Option A: Process APIs are not typically responsible for large data dumps or data synchronization.
That function would be handled by a System API or a specialized batch process.
Option B: Managing direct, secure communication between back-end systems and end-user clients is typically the role of Experience APIs rather than Process APIs.
Option C (Correct Answer): Process APIs are designed to coordinate and orchestrate calls to multiple other APIs in the network, which supports the automation of business processes.
Option D: Securing and managing communication with end-user clients is typically the role of
Experience APIs, not Process APIs.
Conclusion:
Option C is the correct answer, as the main role of a Process API is to coordinate and orchestrate interactions between other APIs, enabling business processes to function seamlessly across multiple systems.
Refer to MuleSoft’s API-led connectivity documentation for further explanation of the roles and responsibilities of Process APIs in an application network.
Question #44
A system API has a guaranteed SLA of 100 ms per request. The system API is deployed to a primary environment as well as to a disaster recovery (DR) environment, with different DNS names in each environment. An upstream process API invokes the system API and the main goal of this process API is to respond to client requests in the least possible time.
In what order should the system APIs be invoked, and what changes should be made in order to speed up the response time for requests from the process API?
- A . In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response
- B . In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment using a scatter-gather configured with a timeout, and then merge the responses
- C . Invoke the system API deployed to the primary environment, and if it fails, invoke the system API deployed to the DR environment
- D . Invoke ONLY the system API deployed to the primary environment, and add timeout and retry logic to avoid intermittent failures
Correct Answer: A
A
Explanation:
Correct Answer In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response. >> The API requirement in the given scenario is to respond in least possible time.
>> The option that is suggesting to first try the API in primary environment and then fallback to API in DR environment would result in successful response but NOT in least possible time. So, this is NOT a right choice of implementation for given requirement.
>> Another option that is suggesting to ONLY invoke API in primary environment and to add timeout and retries may also result in successful response upon retries but NOT in least possible time. So, this is also NOT a right choice of implementation for given requirement.
>> One more option that is suggesting to invoke API in primary environment and API in DR environment in parallel using Scatter-Gather would result in wrong API response as it would return merged results and moreover, Scatter-Gather does things in parallel which is true but still completes its scope only on finishing all routes inside it. So again, NOT a right choice of implementation for given requirement
The Correct choice is to invoke the API in primary environment and the API in DR environment parallelly, and using ONLY the first response received from one of them.
A
Explanation:
Correct Answer In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response. >> The API requirement in the given scenario is to respond in least possible time.
>> The option that is suggesting to first try the API in primary environment and then fallback to API in DR environment would result in successful response but NOT in least possible time. So, this is NOT a right choice of implementation for given requirement.
>> Another option that is suggesting to ONLY invoke API in primary environment and to add timeout and retries may also result in successful response upon retries but NOT in least possible time. So, this is also NOT a right choice of implementation for given requirement.
>> One more option that is suggesting to invoke API in primary environment and API in DR environment in parallel using Scatter-Gather would result in wrong API response as it would return merged results and moreover, Scatter-Gather does things in parallel which is true but still completes its scope only on finishing all routes inside it. So again, NOT a right choice of implementation for given requirement
The Correct choice is to invoke the API in primary environment and the API in DR environment parallelly, and using ONLY the first response received from one of them.
Question #45
What CANNOT be effectively enforced using an API policy in Anypoint Platform?
- A . Guarding against Denial of Service attacks
- B . Maintaining tamper-proof credentials between APIs
- C . Logging HTTP requests and responses
- D . Backend system overloading
Correct Answer: A
A
Explanation:
Correct Answer Guarding against Denial of Service attacks >> Backend system overloading can be handled by enforcing "Spike Control Policy"
>> Logging HTTP requests and responses can be done by enforcing "Message Logging Policy"
>> Credentials can be tamper-proofed using "Security" and "Compliance" Policies
However, unfortunately, there is no proper way currently on Anypoint Platform to guard against DOS attacks.
Reference: https://help.mulesoft.com/s/article/DDos-Dos-at
A
Explanation:
Correct Answer Guarding against Denial of Service attacks >> Backend system overloading can be handled by enforcing "Spike Control Policy"
>> Logging HTTP requests and responses can be done by enforcing "Message Logging Policy"
>> Credentials can be tamper-proofed using "Security" and "Compliance" Policies
However, unfortunately, there is no proper way currently on Anypoint Platform to guard against DOS attacks.
Reference: https://help.mulesoft.com/s/article/DDos-Dos-at
Question #45
What CANNOT be effectively enforced using an API policy in Anypoint Platform?
- A . Guarding against Denial of Service attacks
- B . Maintaining tamper-proof credentials between APIs
- C . Logging HTTP requests and responses
- D . Backend system overloading
Correct Answer: A
A
Explanation:
Correct Answer Guarding against Denial of Service attacks >> Backend system overloading can be handled by enforcing "Spike Control Policy"
>> Logging HTTP requests and responses can be done by enforcing "Message Logging Policy"
>> Credentials can be tamper-proofed using "Security" and "Compliance" Policies
However, unfortunately, there is no proper way currently on Anypoint Platform to guard against DOS attacks.
Reference: https://help.mulesoft.com/s/article/DDos-Dos-at
A
Explanation:
Correct Answer Guarding against Denial of Service attacks >> Backend system overloading can be handled by enforcing "Spike Control Policy"
>> Logging HTTP requests and responses can be done by enforcing "Message Logging Policy"
>> Credentials can be tamper-proofed using "Security" and "Compliance" Policies
However, unfortunately, there is no proper way currently on Anypoint Platform to guard against DOS attacks.
Reference: https://help.mulesoft.com/s/article/DDos-Dos-at
Question #47
A Mule 4 API has been deployed to CloudHub and a Basic Authentication – Simple policy has been applied to all API methods and resources. However, the API is still accessible by clients without using authentication.
How is this possible?
- A . The APE Router component is pointing to the incorrect Exchange version of the APT
- B . The Autodiscovery element is not present, in the deployed Mule application
- C . No… for client applications have been created of this API
- D . One of the application’s CloudHub workers restarted
Correct Answer: B
B
Explanation:
When a Basic Authentication policy is applied to an API on CloudHub but clients can still access the API without authentication, the likely cause is a missing Autodiscovery element. Here’s how this affects API security:
Autodiscovery in MuleSoft:
The Autodiscovery element is essential for linking an API implementation deployed in CloudHub with its API instance defined in API Manager. This connection allows the policies applied in API Manager, such as Basic Authentication, to be enforced on the deployed API.
Why Option B is Correct:
Without Autodiscovery, the deployed application does not "know" about the policies configured in API Manager, resulting in unrestricted access. Adding Autodiscovery enables the API to enforce the policies correctly.
of Incorrect Options:
Option A (incorrect Exchange version) would not cause bypassing of security policies.
Option C (missing client applications) does not impact authentication policy enforcement.
Option D (worker restart) is irrelevant to policy enforcement.
Reference
Refer to MuleSoft documentation on Autodiscovery configuration and linking API Manager policies for additional information on setting up secure API policies.
B
Explanation:
When a Basic Authentication policy is applied to an API on CloudHub but clients can still access the API without authentication, the likely cause is a missing Autodiscovery element. Here’s how this affects API security:
Autodiscovery in MuleSoft:
The Autodiscovery element is essential for linking an API implementation deployed in CloudHub with its API instance defined in API Manager. This connection allows the policies applied in API Manager, such as Basic Authentication, to be enforced on the deployed API.
Why Option B is Correct:
Without Autodiscovery, the deployed application does not "know" about the policies configured in API Manager, resulting in unrestricted access. Adding Autodiscovery enables the API to enforce the policies correctly.
of Incorrect Options:
Option A (incorrect Exchange version) would not cause bypassing of security policies.
Option C (missing client applications) does not impact authentication policy enforcement.
Option D (worker restart) is irrelevant to policy enforcement.
Reference
Refer to MuleSoft documentation on Autodiscovery configuration and linking API Manager policies for additional information on setting up secure API policies.
Question #48
A company has started to create an application network and is now planning to implement a Center for Enablement (C4E) organizational model.
What key factor would lead the company to decide upon a federated rather than a centralized C4E?
- A . When there are a large number of existing common assets shared by development teams
- B . When various teams responsible for creating APIs are new to integration and hence need extensive training
- C . When development is already organized into several independent initiatives or groups
- D . When the majority of the applications in the application network are cloud based
Correct Answer: C
C
Explanation:
Correct Answer When development is already organized into several independent initiatives or groups
>> It would require lot of process effort in an organization to have a single C4E team coordinating with multiple already organized development teams which are into several independent initiatives. A single C4E works well with different teams having at least a common initiative. So, in this scenario, federated C4E works well instead of centralized C4E.
C
Explanation:
Correct Answer When development is already organized into several independent initiatives or groups
>> It would require lot of process effort in an organization to have a single C4E team coordinating with multiple already organized development teams which are into several independent initiatives. A single C4E works well with different teams having at least a common initiative. So, in this scenario, federated C4E works well instead of centralized C4E.
Question #49
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?
- A . Increase the vCPU resources of the API implementation
- B . Modify the API client to split the problematic request into smaller, less-demanding requests
- C . Increase the number of replicas of the API implementation
- D . Throttle the APT client to reduce the number of requests per minute
Correct Answer: A
A
Explanation:
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.
A
Explanation:
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.
Question #50
An operations team is analyzing the effort needed to set up monitoring of their application network. They are looking at which API invocation metrics can be used to identify and predict trouble without having to write custom scripts or install additional analytics software or tools.
Which type of metrics can satisfy this goal of directly identifying and predicting failures?
- A . The number and types of API policy violations per day
- B . The effectiveness of the application network based on the level of reuse
- C . The number and types of past API invocations across the application network
- D . The ROI from each APT invocation
Correct Answer: A
A
Explanation:
To monitor an application network and predict issues without custom scripts, policy violation metrics are critical. They provide insights into potential problems by tracking instances where API usage does not conform to defined policies.
Here’s why this approach is suitable:
Predictive Monitoring:
Tracking API policy violations (such as rate limits or spike controls being hit) can indicate surges in
traffic or misuse, which may lead to throttling or service degradation if not addressed.
By monitoring these violations, teams can proactively adjust limits or optimize API handling to prevent actual failures.
No Custom Scripting Needed:
Policy violation metrics are available within MuleSoft’s Anypoint Monitoring, meaning there’s no need to implement custom solutions or external tools to gather and interpret this data. of Incorrect Options:
Option B (effectiveness based on reuse) does not directly predict failures.
Option C (past invocation counts) offers historical usage data but does not inherently identify issues.
Option D (ROI from API invocation) is a business metric and does not provide technical insights for
failure prediction.
Reference
For more details on leveraging policy violation metrics for proactive monitoring, refer to MuleSoft documentation on Anypoint Monitoring.
A
Explanation:
To monitor an application network and predict issues without custom scripts, policy violation metrics are critical. They provide insights into potential problems by tracking instances where API usage does not conform to defined policies.
Here’s why this approach is suitable:
Predictive Monitoring:
Tracking API policy violations (such as rate limits or spike controls being hit) can indicate surges in
traffic or misuse, which may lead to throttling or service degradation if not addressed.
By monitoring these violations, teams can proactively adjust limits or optimize API handling to prevent actual failures.
No Custom Scripting Needed:
Policy violation metrics are available within MuleSoft’s Anypoint Monitoring, meaning there’s no need to implement custom solutions or external tools to gather and interpret this data. of Incorrect Options:
Option B (effectiveness based on reuse) does not directly predict failures.
Option C (past invocation counts) offers historical usage data but does not inherently identify issues.
Option D (ROI from API invocation) is a business metric and does not provide technical insights for
failure prediction.
Reference
For more details on leveraging policy violation metrics for proactive monitoring, refer to MuleSoft documentation on Anypoint Monitoring.