Salesforce MuleSoft-Platform-Architect-I Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) Exam Practice Test

Explanation

Correct Answer: When the API implementation changes the structure of the request or response messages

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

>> RAML definition usually needs to be touched only when there are changes in the request/response schemas or in any traits on API.

>> It need not be modified for any internal changes in API implementation like performance tuning, backend system migrations etc..

In the API-led connectivity approach, APIs are categorized into Experience, Process, and System layers:

Enterprise Data Model Scope:

The Enterprise Data Model (EDM) generally supports System APIs and some Process APIs by defining standard data structures used across the organization. Experience APIs, however, are tailored to specific applications or interfaces and are less likely to be served directly by the EDM, as they may require customized data representations to meet the unique needs of each user interface.

Why Option C is Correct:

The Mobile Account Management EAPI serves mobile-specific needs and often requires data formatted differently from the standardized data models. Thus, it would be outside the direct scope of the EDM and might employ custom mappings to fit mobile application requirements.

Explanation of Incorrect Options:

Option A (Customer SAPI), Option B (Customer Lookup PAPI), and Option D (Service SAPI) would typically align with the EDM as they are closer to the core data and services the EDM supports.

ReferencesFor additional guidance, review MuleSoft's best practices on API-led connectivity and data modeling​.

Understanding Idempotency:

Idempotency is a concept in APIs where an operation can be performed multiple times without changing the result beyond the initial application. This is particularly important for operations that may be repeated due to network retries or client errors.

When to Consider Idempotency:

Idempotency should be taken into account when there is a risk of duplicate processing due to multiple requests being sent (e.g., retries or errors). This ensures that repeated requests do not result in unintended side effects, such as creating multiple records or processing the same transaction more than once.

Evaluating the Options:

Option A: While locked entities may need special handling, this is not directly related to idempotency.

Option B: Storing results for future responses could be useful but does not relate to idempotent operations.

Option C: Concurrent requests for the same entity might require handling for conflicts, but this scenario is better suited for transaction management or concurrency control.

Option D (Correct Answer): Preventing duplicate processing from multiple requests is a key reason to implement idempotency, ensuring that repeat requests have no adverse effects.

Conclusion:

Option D is the correct answer as idempotency is specifically used to handle scenarios where duplicate requests might be sent, preventing unintended processing.

Refer to MuleSoft's documentation on best practices for idempotency in API design for more details.

Explanation

Correct Answer: They must be deployed to Anypoint Platform runtime planes that are managed by Anypoint Platform control planes, with both planes in the same Jurisdiction.

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

>> As per legal regulations, all data processing to be performed within a certain jurisdiction. Meaning, the data in USA should reside within USA and should not go out. Same way, the data in EU should reside within EU and should not go out.

>> So, just encrypting the data in transit and at rest does not help to be compliant with the rules. We need to make sure that data does not go out too.

>> The data that we are talking here is not just about the messages that are published to Anypoint MQ. It includes the apps running, transaction states, application logs, events, metric info and any other metadata. So, just replacing Anypoint MQ with a locally hosted ActiveMQ does NOT help.

>> The data that we are talking here is not just about the key/value pairs that are stored in Object Store. It includes the messages published, apps running, transaction states, application logs, events, metric info and any other metadata. So, just avoiding using Object Store does NOT help.

>> The only option left and also the right option in the given choices is to deploy application on runtime and control planes that are both within the jurisdiction.

Understanding Circuit Breaker Policy:

A circuit breaker is a design pattern used to detect failures and prevent an application from continually trying to execute a failing operation. In this case, it will help improve response time and reduce demand on the downstream API.

The specified configuration includes conditions for opening, half-opening, and closing the circuit based on error rates over time:

Circuit Open: Triggered if there are more than 10 errors per minute for three consecutive minutes.

Circuit Half-Open: The circuit transitions to half-open if there is one error per minute.

Circuit Closed: The circuit closes if the error rate is less than one error per minute for five minutes.

Evaluating the Options:

Option A: Creating a custom policy with template expressions could work, but it would require custom development. Since the Anypoint Platform already has a Circuit Breaker policy available, this would be a less efficient and more complex solution.

Option B: Anypoint Monitoring alerts can be used for monitoring the API, but they do not provide circuit-breaking functionality. Additionally, implementing a retry strategy for the half-open state is not sufficient to achieve the required circuit breaker behavior.

Option C (Correct Answer): Adding the Circuit Breaker policy to the API instance on Anypoint Platform allows you to set up circuit-breaking conditions directly. This approach uses the built-in Circuit Breaker policy, where you can configure parameters such as error thresholds and time intervals to match the requirements. This solution is efficient, reliable, and leverages Anypoint’s out-of-the-box capabilities.

Option D: Implementing the strategy within a Mule application with a YAML configuration could be complex and less manageable. Additionally, it does not leverage Anypoint Platform’s built-in Circuit Breaker policy, which is more suited to this scenario.

Conclusion:

Option C is the correct choice, as it leverages Anypoint Platform’s Circuit Breaker policy. This solution allows for configuring thresholds and time intervals as specified, improving response time and reducing demand on the downstream API while utilizing Anypoint's managed policy feature.

Refer to MuleSoft’s documentation on implementing the Circuit Breaker policy in API Manager for detailed configuration guidance.

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.

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

Explanation

Correct Answer: Apply a basic authentication - LDAP policy; the internal Active Directory will be configured as the LDAP source for authenticating users.

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

>> IP Whitelisting does NOT fit for this purpose. Moreover, the users workstations may not necessarily have static IPs in the network.

>> OAuth 2.0 enforcement requires a client provider which isn't in the organizations system components.

>> It is not an effective approach to let every user create separate client credentials and configure those for their usage.

The effective way it to apply a basic authentication - LDAP policy and the internal Active Directory will be configured as the LDAP source for authenticating users.

Explanation

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

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

>> The private IP address range of an Anypoint VPC is NOT automatically chosen by CloudHub. It is chosen by us at the time of creating VPC using thr CIDR blocks.

CIDR Block: The size of the Anypoint VPC in Classless Inter-Domain Routing (CIDR) notation.

For example, if you set it to 10.111.0.0/24, the Anypoint VPC is granted 256 IP addresses from 10.111.0.0 to 10.111.0.255.

Ideally, the CIDR Blocks you choose for the Anypoint VPC come from a private IP space, and should not overlap with any other Anypoint VPC’s CIDR Blocks, or any CIDR Blocks in use in your corporate network.

that each CloudHub environment requires a separate Anypoint VPC. Once an Anypoint VPC is created, we can choose a same VPC by multiple environments. However, it is generally a best and recommended practice to always have seperate Anypoint VPCs for Non-Prod and Prod environments.

>> We use Anypoint VPN to link the underlying AWS VPC to an on-premises (non AWS) private network. NOT VPC Peering.

Explanation

Correct Answer: The API policy is defined in API Manager for a specific API instance, and then ONLY applied to the specific API instance.

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

>> Once our API specifications are ready and published to Exchange, we need to visit API Manager and register an API instance for each API.

>> API Manager is the place where management of API aspects takes place like addressing NFRs by enforcing policies on them.

>> We can create multiple instances for a same API and manage them differently for different purposes.

>> One instance can have a set of API policies applied and another instance of same API can have different set of policies applied for some other purpose.

>> These APIs and their instances are defined PER environment basis. So, one need to manage them seperately in each environment.

>> We can ensure that same configuration of API instances (SLAs, Policies etc..) gets promoted when promoting to higher environments using platform feature. But this is optional only. Still one can change them per environment basis if they have to.

>> Runtime Manager is the place to manage API Implementations and their Mule Runtimes but NOT APIs itself. Though API policies gets executed in Mule Runtimes, We CANNOT enforce API policies in Runtime Manager. We would need to do that via API Manager only for a cherry picked instance in an environment.

So, based on these facts, right statement in the given choices is - "The API policy is defined in API Manager for a specific API instance, and then ONLY applied to the specific API instance".

When setting up a custom domain for MuleSoft applications hosted on CloudHub 1.0 using a Dedicated Load Balancer (DLB), follow these steps:

Set Up the TLS Certificate: Configure the DLB (acme-dib-prod) with a TLS certificate that covers the custom domain api.acmecorp.com. This certificate will allow HTTPS traffic to be securely directed through the DLB to your Mule applications.

DNS Configuration with CNAME:

Create a CNAME record that points api.acmecorp.com to the DLB hostname acme-dib-prod.lb.anypointdns.net.

The CNAME record enables the custom domain to resolve to the DLB provided by MuleSoft's Anypoint Platform. This CNAME mapping directs all traffic to the correct DLB for processing and load distribution.

Why Option B is Correct:

A CNAME record provides the necessary aliasing to acme-dib-prod.lb.anypointdns.net, which is the endpoint managed by Anypoint Platform for your DLB.

Option B also correctly identifies the need to configure the DLB with a TLS certificate specifically for api.acmecorp.com rather than for the DLB's internal hostname.

Explanation of Incorrect Options:

Options that suggest configuring the DLB with a TLS certificate for the DLB’s internal hostname or using an A record are not suitable in this scenario. MuleSoft CloudHub 1.0 DLBs work with CNAME records to provide flexible and scalable domain management, and a direct IP (A record) is not supported for these load balancers.

ReferencesFor more information on configuring custom domains and DLBs on CloudHub 1.0, refer to the MuleSoft documentation on DLB setup and DNS configuration​​.

Explanation

Correct Answer:

1. Decrease the IT delivery gap

2. Meet various business demands without increasing the IT capacity

3. Make consumption of assets at the rate of production.

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

When using the Client ID Enforcement policy with default settings, MuleSoft expects the client_id and client_secret to be provided in the URI parameters of each request. This policy is typically used to control and monitor access by validating that each request has valid credentials. Here’s how to avoid a 401 Unauthorized error:

URI Parameters Requirement:

The default configuration for the Client ID Enforcement policy requires the client_id and client_secret to be included in each request’s URI parameters. This is a straightforward way to authenticate API requests without additional configurations.

Why Option C is Correct:

Providing client_id and client_secret in the URI parameters meets the policy’s requirements for each request, ensuring authorized access and avoiding the 401 error.

Explanation of Incorrect Options:

Option A (sending a token in the header) would be applicable for token-based authentication (like OAuth 2.0), not Client ID Enforcement.

Option B (request body) and Option D (header) are not valid locations for client_id and client_secret under the default configuration of Client ID Enforcement, which expects them in the URI.

ReferencesFor more details, consult MuleSoft’s documentation on Client ID Enforcement policies and expected request configurations

Explanation

Correct Answer: Increase the size of the CloudHub worker(s)

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

The key details that we can take out from the given scenario are:

>> API implementation uses a database bulk insert command to submit all the purchase data to a database

>> JDBC driver processes the data into a set of several temporary disk files on the CloudHub worker

>> Sometimes a request fails and the logs show a message indicating an out-of-file-space message

Based on above details:

>> Both auto-scaling options does NOT help because we cannot set auto-scaling rules based on error messages. Auto-scaling rules are kicked-off based on CPU/Memory usages and not due to some given error or disk space issues.

>> Increasing the number of CloudHub workers also does NOT help here because the reason for the failure is not due to performance aspects w.r.t CPU or Memory. It is due to disk-space.

>> Moreover, the API is doing bulk insert to submit the received batch data. Which means, all data is handled by ONE worker only at a time. So, the disk space issue should be tackled on "per worker" basis. Having multiple workers does not help as the batch may still fail on any worker when disk is out of space on that particular worker.

Therefore, the right way to deal this issue and resolve this is to increase the vCore size of the worker so that a new worker with more disk space will be provisioned.

In API-led design, an Experience API is enhanced to improve how data is delivered to end-user applications. One primary reason to enhance an Experience API is when new data standards, such as a Canonical Data Model, are adopted. Here’s why:

Canonical Data Model (CDM):

Adopting a CDM standardizes data representations across the organization, making APIs more consistent and easier to consume across various services and applications.

Updating the Experience API ensures that it delivers data in this standardized format, improving interoperability and reusability.

Explanation of Correct Answer (D):

A CDM impacts the structure and types of data the API provides, and this update would be directly relevant to an Experience API, as it is the primary point of interaction for applications.

Explanation of Incorrect Options:

Option A involves adapting to consumer-specific standards, which is against API-led design principles.

Option B involves changes in System APIs, which don’t directly mandate changes to the Experience API unless data formatting adjustments are required.

Option C (IP Allowlist) relates to security rather than API design and would not motivate a functional enhancement of the API.

ReferencesFor more details on the use of Canonical Data Models in API-led architecture, refer to MuleSoft’s guidelines on data standardization and Experience API best practices​.

When managing high traffic to an API, especially with POST requests, it is crucial to ensure the API’s policies both protect the back-end systems and provide a smooth client experience. Here’s the approach to reducing errors:

Rate Limiting Policy: This policy enforces a limit on the number of requests within a defined time period. However, rate limiting alone may cause clients to hit limits during demand surges, leading to errors.

Adding an SLA-based Spike Control Policy:

Spike Control is designed to handle sudden increases in traffic by smoothing out bursts of requests, which is particularly useful during high-demand periods.

By configuring SLA-based Spike Control, you can define thresholds for specific client tiers. For instance, premium clients might have higher limits or more flexibility in traffic bursts than standard clients.

Why Option D is Correct:

Keeping the Rate Limiting policy continues to provide baseline protection for the back-end.

Adding the SLA-based Spike Control policy allows for differentiated control, where requests are queued or delayed during bursts rather than outright rejected. This approach significantly reduces error responses to clients while still controlling overall traffic.

Explanation of Incorrect Options:

Option A (adding Client ID Enforcement) would not reduce errors related to traffic surges.

Option B (HTTP Caching) is not applicable as caching is generally ineffective for non-idempotent requests like POST.

Option C (only Spike Control without Rate Limiting) may leave the back-end system vulnerable to sustained high traffic levels, reducing protection.

ReferencesFor more information on configuring Rate Limiting and SLA-based Spike Control policies, refer to MuleSoft documentation on API Policies and Rate Limiting​​.

Explanation

Correct Answer: API Consumer requests access to API >> API Client implementes logic to call an API >> API routes the request to >> API Implementation

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

>> API consumer does not implement any logic to invoke APIs. It is just a role. So, the option stating "API Consumer implementes logic to call an API" is INVALID.

>> API Implementation does not route any requests. It is a final piece of logic where functionality of target systems is exposed. So, the requests should be routed to the API implementation by some other entity. So, the options stating "API Implementation routes the request to >> API" is INVALID

>> The statements in one of the options are correct but sequence is wrong. The sequence is given as "API Client implementes logic to call an API >> API Consumer requests access to API >> API routes the request to >> API Implementation". Here, the statements in the options are VALID but sequence is WRONG.

>> Right option and sequence is the one where API consumer first requests access to API on Anypoint Exchange and obtains client credentials. API client then writes logic to call an API by using the access client credentials requested by API consumer and the requests will be routed to API implementation via the API which is managed by API Manager.

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.

Understanding the API Flow and Timeout Requirement:

The Order API initiates a call to the OrderItems process API, which in turn calls the Inventory system API to fetch details from the inventory database.

The requirement specifies that the Order API should not wait more than two seconds for a response from the OrderItems process API, even if there are delays further down the chain (between Inventory system API and the database).

Choosing the Appropriate Timeout Location:

Setting the timeout at the OrderItems process API level ensures that if the Inventory system API takes longer than two seconds to respond, the OrderItems process API will terminate the request and send a timeout response back to the Order API. This prevents the Order API from waiting indefinitely due to the unreliable connection to the database.

If the timeout were set in the Inventory system API or database, it would not help the Order API directly, as the OrderItems process API would still be waiting for a response.

Detailed Analysis of Each Option:

Option A (Correct Answer): Setting the timeout in the OrderItems process API allows it to control how long it waits for a response from the Inventory system API. If the Inventory system API does not respond within two seconds, the OrderItems process API can terminate the call and return a timeout response to the Order API, meeting the requirement.

Option B: Setting the timeout in the Order API would not limit the wait time at the OrderItems process API level, meaning the OrderItems process API could still wait indefinitely for the Inventory system API, leading to a longer delay.

Option C: Setting the timeout in the Inventory system API only affects the connection to the database and does not influence how long the OrderItems process API waits for the Inventory system API's response.

Option D: Setting a timeout in the database is not feasible in this context since database timeouts are typically configured for database operations and would not directly control the API response times in the overall API chain.

Conclusion:

Option A is the best choice, as it ensures that the OrderItems process API does not hold the Order API longer than the required two seconds, even if the downstream connection to the database hangs. This configuration aligns with MuleSoft best practices for setting timeouts in API orchestration to manage dependencies and prevent delays across a chain of API calls.

For additional information on timeout settings, refer to MuleSoft documentation on handling timeouts and API orchestration best practices.

Explanation

Correct Answer: Create API Notebooks and Include them in the relevant Anypoint exchange entries

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

>> API Notebooks are the one on Anypoint Platform that enable us to provide code-centric API documentation

Bottom of Form

Top of Form

Explanation

Correct Answer: JSON threat protection

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

Fact: Technically, there are no restrictions on what policy can be applied in what layer. Any policy can be applied on any layer API. However, context should also be considered properly before blindly applying the policies on APIs.

That is why, this question asked for a policy that would LEAST likely be applied to a Process API.

From the given options:

>> All policies except "JSON threat protection" can be applied without hesitation to the APIs in Process tier.

>> JSON threat protection policy ideally fits for experience APIs to prevent suspicious JSON payload coming from external API clients. This covers more of a security aspect by trying to avoid possibly malicious and harmful JSON payloads from external clients calling experience APIs.

As external API clients are NEVER allowed to call Process APIs directly and also these kind of malicious and harmful JSON payloads are always stopped at experience API layer only using this policy, it is LEAST LIKELY that this same policy is again applied on Process Layer API.

Explanation

Correct Answer: They provide an additional layer of resilience on top of the underlying backend system, thereby insulating clients from extended failure of these systems.

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

In API-led connectivity,

>> Experience APIs - allow for innovation at the user interface level by consuming the underlying assets without being aware of how data is being extracted from backend systems.

>> Process APIs - compose data from various sources and combine them with orchestration logic to create higher level value

>> System APIs - reduce the dependency on the underlying backend systems by helping unlock data from backend systems in a reusable and consumable way.

However, they NEVER promise that they provide an additional layer of resilience on top of the underlying backend system, thereby insulating clients from extended failure of these systems.

For an organization starting with API-led connectivity to integrate a siloed back-end system with a new CRM, the following approach aligns with best practices and MuleSoft’s Center for Enablement (C4E) guidance:

API-led Connectivity: This model organizes APIs into distinct layers (System, Process, and Experience) to improve reusability, modularity, and manageability.

System APIs are used to expose and unlock data from core systems (such as back-end applications or databases).

Process APIs orchestrate data across multiple systems and transform it as needed.

Experience APIs format the data specifically for consumption by applications or devices, such as the CRM in this case.

Step to Support Application Network:

Create a System API for the back-end system. This API should expose the necessary data to support integration with the CRM.

By creating a System API with a RESTful interface, data can be accessed in a standardized way, making it easier to integrate with other systems and supporting future scalability.

Why Option D is Correct:

Creating a System API aligns with the principle of API-led connectivity, ensuring that data is exposed in a reusable manner. This API can then be orchestrated by Process APIs as needed to meet CRM requirements and can easily be extended to other applications.

Explanation of Incorrect Options:

Option A (creating a business process model) does not directly enable connectivity or expose back-end data through APIs.

Option B is unnecessary at this stage; assessing CRM capabilities like OAuth 2.0 support is not directly related to creating the application network via System APIs.

Option C contradicts API-led best practices by suggesting a point-to-point integration, which API-led connectivity seeks to avoid due to its lack of flexibility and scalability.

ReferencesRefer to MuleSoft’s API-led Connectivity resources for a detailed framework on building scalable integration layers using System, Process, and Experience APIs​​.

Explanation

Correct Answer: When a pragmatic approach with only limited isolation from the backend system is deemed appropriate.

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

General guidance w.r.t choosing Data Models:

>> If an Enterprise Data Model is in use then the API data model of System APIs should make use of data types from that Enterprise Data Model and the corresponding API implementation should translate between these data types from the Enterprise Data Model and the native data model of the backend system.

>> If no Enterprise Data Model is in use then each System API should be assigned to a Bounded Context, the API data model of System APIs should make use of data types from the corresponding Bounded Context Data Model and the corresponding API implementation should translate between these data types from the Bounded Context Data Model and the native data model of the backend system. In this scenario, the data types in the Bounded Context Data Model are defined purely in terms of their business characteristics and are typically not related to the native data model of the backend system. In other words, the translation effort may be significant.

>> If no Enterprise Data Model is in use, and the definition of a clean Bounded Context Data Model is considered too much effort, then the API data model of System APIs should make use of data types that approximately mirror those from the backend system, same semantics and naming as backend system, lightly sanitized, expose all fields needed for the given System API’s functionality, but not significantly more and making good use of REST conventions.

The latter approach, i.e., exposing in System APIs an API data model that basically mirrors that of the backend system, does not provide satisfactory isolation from backend systems through the System API tier on its own. In particular, it will typically not be possible to "swap out" a backend system without significantly changing all System APIs in front of that backend system and therefore the API implementations of all Process APIs that depend on those System APIs! This is so because it is not desirable to prolong the life of a previous backend system’s data model in the form of the API data model of System APIs that now front a new backend system. The API data models of System APIs following this approach must therefore change when the backend system is replaced.

On the other hand:

>> It is a very pragmatic approach that adds comparatively little overhead over accessing the backend system directly

>> Isolates API clients from intricacies of the backend system outside the data model (protocol, authentication, connection pooling, network address, …)

>> Allows the usual API policies to be applied to System APIs

>> Makes the API data model for interacting with the backend system explicit and visible, by exposing it in the RAML definitions of the System APIs

>> Further isolation from the backend system data model does occur in the API implementations of the Process API tier

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.

Explanation

Correct Answer: 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.

Explanation

Correct Answer: When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data.

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

We need NOT require to use Anypoint Platform PCE or PCF for the below. So these options are OUT.

>> We can make ALL applications highly available across multiple data centers using CloudHub too.

>> We can use Anypoint VPN and tunneling from CloudHub to connect to ALL backend systems in the application network that are deployed in the organization's intranet.

>> We can use Anypoint VPC and Firewall Rules to make ALL APIs private and NOT exposed to the public cloud.

Only valid reason in the given options that requires to use Anypoint Platform PCE/ PCF is - When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data.

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.

Explanation

Correct Answer: 8082

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

>> 8091 and 8092 ports are to be used when keeping your HTTP and HTTPS app private to the LOCAL VPC respectively.

>> Above TWO ports are not for Shared AWS VPC/ Shared Worker Cloud.

>> 8081 is to be used when exposing your HTTP endpoint app to the internet through Shared LB

>> 8082 is to be used when exposing your HTTPS endpoint app to the internet through Shared LB

So, API invocations should be sent to port 8082 when calling this HTTPS based app.

Scenario Analysis:

The eCommerce company’s Product Details feature requires low response time and consistent data for a feature where data rarely changes (only once or twice a year).

The database response time is slow due to high volume, so querying the database directly on each request would lead to poor performance and higher response times.

Optimal Solution Requirements:

Low Response Time: Data retrieval should be fast and not depend on database performance.

Fault Tolerance and Data Consistency: Cached or stored data should be consistent and resilient in case of database unavailability, as the product details data changes infrequently.

Evaluating the Options:

Option A: Using a Cache scope would temporarily store the product details in memory, which could improve performance but might not be suitable for infrequent updates (only twice a year), as cache expiration policies typically require shorter durations.

Option B: Storing product details in Anypoint MQ and then retrieving it through a subscriber is not suitable for this use case. Anypoint MQ is better for messaging rather than as a data storage mechanism.

Option C (Correct Answer): Using an object store to store and retrieve product details is ideal. Object stores in MuleSoft are designed for persistent storage of key-value pairs, which allows storing data retrieved from the database initially. This provides quick, consistent access without querying the database on every request, aligning with requirements for low response time, fault tolerance, and data consistency.

Option D: Selecting data directly from the database for each request would not meet the performance requirement due to known slow response times from the database.

Conclusion:

Option C is the best answer, as using an object store allows caching the infrequently updated product details. This approach reduces the dependency on the database, significantly improving response time and ensuring consistent data.

Refer to MuleSoft documentation on Object Store v2 and best practices for data caching to implement this solution effectively.

Explanation

Correct Answer: Bundle properties files for each environment into the Mule API implementation's deployable archive, then promote the Mule API implementation to the Production environment using Anypoint CLI or the Anypoint Platform REST APIs

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

>> Anypoint Exchange is for asset discovery and documentation. It has got no provision to modify the properties of Mule API implementations at all.

>> API Manager is for managing API instances, their contracts, policies and SLAs. It has also got no provision to modify the properties of API implementations.

>> API policies are to address Non-functional requirements of APIs and has again got no provision to modify the properties of API implementations.

So, the right way and recommended way to do this as part of development practice is to bundle properties files for each environment into the Mule API implementation and just point and refer to respective file per environment.

Explanation

Correct Answer: The CloudHub shared load balancer

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

The scenario in this question can be split as below:

>> There are 3 CloudHub workers (So, there are already good number of workers to handle high volume of requests)

>> The workers are not using static IP addresses (So, one CANNOT use customer load-balancing solutions without static IPs)

>> Looking for most cost-effective component to load balance the client requests among the workers.

Based on the above details given in the scenario:

>> Runtime autoscaling is NOT at all cost-effective as it incurs extra cost. Most over, there are already 3 workers running which is a good number.

>> We cannot go for a customer-hosted load balancer as it is also NOT most cost-effective (needs custom load balancer to maintain and licensing) and same time the Mule App is not having Static IP Addresses which limits from going with custom load balancing.

>> An API Proxy is irrelevant there as it has no role to play w.r.t handling high volumes or load balancing.

So, the only right option to go with and fits the purpose of scenario being most cost-effective is - using a CloudHub Shared Load Balancer.

Explanation

Correct Answer: GET, OPTIONS, HEAD

Explanation

Correct Answer: The remaining capacity allowed by the API implementation.

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

>> Reference:

Understanding Coarse-Grained vs. Fine-Grained API Design:

A coarse-grained design consolidates multiple operations within a single API, leading to fewer APIs but with more complex implementations. Conversely, a fine-grained design breaks down functionalities into smaller, more specific APIs, resulting in simpler implementations but a larger number of APIs.

Evaluating the Options:

Option A (Correct Answer): With a coarse-grained design, each API handles more functionalities, increasing the complexity of each API implementation as it needs to manage more use cases and logic.

Option B: A coarse-grained design typically reduces the number of APIs, so fewer discoverable assets are available.

Option C: Fewer APIs generally mean fewer connections between them in the application network.

Option D: Network infrastructure usage may actually decrease with fewer APIs, as there are fewer calls between APIs.

Conclusion:

Option A is the correct answer, as the complexity of each API implementation increases in a coarse-grained design due to the consolidation of multiple functionalities into single APIs.

Refer to MuleSoft’s documentation on API design principles and best practices for coarse-grained vs. fine-grained API implementation.

Explanation

Correct Answer: 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

When an API implementation is deployed on CloudHub without configuring automatic restarts in case of worker non-responsiveness, MuleSoft’s monitoring and alerting behavior is as follows:

API Invocation Alerts:

If no clients are invoking the API, there will be no invocation alerts triggered, as alerts related to invocations depend on actual client requests.

Implementation-Level Alerts:

Even without invocation, CloudHub can still monitor the state of the API implementation. If the worker becomes unresponsive, an alert related to the API implementation's health or availability could still be raised.

Why Option C is Correct:

This option correctly identifies that no invocation-related alerts would be triggered in the absence of client requests, while implementation-level alerts could still be generated based on the worker's state.

ReferencesFor additional information, check MuleSoft documentation on CloudHub monitoring and alert configurations to understand worker status alerts versus invocation alerts​.

Explanation

Correct Answer: Process Layer

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

>> Experience layer is dedicated for enrichment of end user experience. This layer is to meet the needs of different API clients/ consumers.

>> System layer is dedicated to APIs which are modular in nature and implement/ expose various individual functionalities of backend systems

>> Process layer is the place where simple or complex business orchestration logic is written by invoking one or many System layer modular APIs

So, Process Layer is the right answer.

Explanation

Correct Answer: IP whitelist

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

>> OAuth 2.0 access token and Client ID enforcement policies are VERY common to apply on Experience APIs as API consumers need to register and access the APIs using one of these mechanisms

>> JSON threat protection is also VERY common policy to apply on Experience APIs to prevent bad or suspicious payloads hitting the API implementations.

>> IP whitelisting policy is usually very common in Process and System APIs to only whitelist the IP range inside the local VPC. But also applied occassionally on some experience APIs where the End User/ API Consumers are FIXED.

>> When we know the API consumers upfront who are going to access certain Experience APIs, then we can request for static IPs from such consumers and whitelist them to prevent anyone else hitting the API.

However, the experience API given in the question/ scenario is intended to work with a consumer mobile phone or tablet application. Which means, there is no way we can know all possible IPs that are to be whitelisted as mobile phones and tablets can so many in number and any device in the city/state/country/globe.

So, It is very LEAST LIKELY to apply IP Whitelisting on such Experience APIs whose consumers are typically Mobile Phones or Tablets.

Explanation

Correct Answer: Data on past API invocations to help identify anomalies and usage patterns across various APIs

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

API Invocation metrics provided by Anypoint Platform:

>> Does NOT provide any Return Of Investment (ROI) related information. So the option suggesting it is OUT.

>> Does NOT provide any information w.r.t how APIs are reused, whether there is effective usage of APIs or not etc...

>> Does NOT prodive any prediction information as such to help us proactively identify any future policy violations.

So, the kind of data/information we can get from such metrics is on past API invocations to help identify anomalies and usage patterns across various APIs.

Explanation

Correct Answer: They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity.

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

Below TWO are characteristics of Integration Tests but NOT unit tests:

>> They test the validity of input and output of source and target systems.

>> They must be triggered by an external client tool or event source.

It is NOT TRUE that Unit Tests must be run in a unit testing environment with dedicated Mule runtimes for the environment.

MuleSoft offers MUnit for writing Unit Tests and they run in an embedded Mule Runtime without needing any separate/ dedicated Runtimes to execute them. They also do NOT need any external connectivity as MUnit supports mocking via stubs.

Center for Enablement (C4E) KPIs:

A Center for Enablement (C4E) in MuleSoft focuses on enabling self-service and reuse by providing APIs that can be consumed across the organization. A key metric of success is how many consumers are utilizing the published APIs.

The number of consumers who have requested and received access to an API indicates the level of adoption and reuse, which aligns with the goals of a C4E.

Evaluating the Options:

Option A: This metric could indicate deployment automation, but it is not a direct measure of C4E’s success in enabling API reuse and consumption.

Option B: Bandwidth usage per API implementation provides insight into API traffic but does not measure C4E enablement or consumer engagement.

Option C: The number of developers downloading an API specification can be an indicator of interest but does not confirm actual usage or enablement.

Option D (Correct Answer): The number of consumers who have requested and received access to an API in production is a key metric indicating API adoption and reuse, which aligns with C4E’s goals.

Conclusion:

Option D is the correct answer as it provides a direct measure of consumer engagement and adoption, indicating the success of the C4E in promoting API usage across the organization.

Refer to MuleSoft’s documentation on C4E KPIs and API usage metrics for additional insights.

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.

Explanation

Correct Answer: Option A

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

>> Anypoint API Manager and API policies are applicable to all types of HTTP/1.x APIs.

>> They are not applicable to WebSocket APIs, HTTP/2 APIs and gRPC APIs