Salesforce MULESOFT PLATFORM ARCHITECT I Exam Questions
Questions for the MULESOFT PLATFORM ARCHITECT I were updated on : Dec 20 ,2025
Page 1 out of 11. Viewing questions 1-15 out of 152
Question 1
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?
- 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.
Answer:
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 2
An API is protected with a Client ID Enforcement policy and uses the default configuration. Access is
requested for the client application to the API, and an approved
contract now exists between the client application and the API
How can a consumer of this API avoid a 401 error "Unauthorized or invalid client application
credentials"?
- A. Send the obtained token as a header in every call
- B. Send the obtained: client_id and client_secret in the request body
- C. Send the obtained clent_id and clent_secret as URI parameters in every call
- D. Send the obtained clent_id and client_secret in the header of every API Request call
Answer:
C
Explanation:
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.
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.
Reference
For more details, consult MuleSoft’s documentation on Client ID Enforcement policies and expected
request configurations
Question 3
An API with multiple API implementations (Mule applications) is deployed to both CloudHub and
customer-hosted Mule runtimes. All the deployments are managed by
the MuleSoft-hosted control plane. An alert needs to be triggered whenever an API implementation
stops responding to API requests, even if no API clients have called the API implementation for some
time.
What is the most effective out-of-the-box solution to create these alerts to monitor the API
implementations?
- A. Create monitors in Anypoint Functional Monitoring for the API implementations, where each monitor repeatedly invokes an API implementation endpoint
- B. Add code to each API client to send an Anypoint Platform REST API request to generate a custom alert in Anypoint Platform when an API invocation times out
- C. Handle API invocation exceptions within the calling API client and raise an alert from that API client when such an exception is thrown
- D. Configure one Worker Not Responding alert.in Anypoint Runtime Manager for all API implementations that will then monitor every API implementation
Answer:
A
Explanation:
In scenarios where multiple API implementations are deployed across different environments
(CloudHub and customer-hosted runtimes), Anypoint Functional Monitoring is the most effective
tool to monitor API availability and trigger alerts when an API implementation becomes
unresponsive. Here’s how it works:
Using Anypoint Functional Monitoring:
Functional Monitoring allows you to create monitors that periodically invoke specific endpoints on
the API implementations, simulating a client request. This helps ensure that the API is responsive,
even if no actual client requests are being made.
If an API implementation does not respond as expected, Functional Monitoring can generate alerts,
notifying administrators of potential issues.
Why Option A is Correct:
By setting up Functional Monitoring to automatically invoke the API endpoints at regular intervals,
you ensure continuous monitoring and alerting capabilities, which are especially useful for APIs that
may experience periods of low or no traffic. This approach provides a proactive solution, allowing
you to identify and address issues before actual users are impacted.
of Incorrect Options:
Option B suggests modifying client applications to trigger alerts, which is not a best practice as it
shifts monitoring responsibility to clients, reducing control and consistency.
Option C involves handling exceptions within client applications, which does not address situations
where no clients are making requests.
Option D proposes a Worker Not Responding alert in Runtime Manager, which is limited to worker-
specific alerts and may not reliably monitor the API's actual responsiveness to requests.
Reference
For further information, refer to MuleSoft documentation on Anypoint Functional Monitoring setup
and usage for API availability monitoring .
Question 4
A Mule application implements an API. The Mule application has an HTTP Listener whose connector
configuration sets the HTTPS protocol and hard-codes the port
value. The Mule application is deployed to an Anypoint VPC and uses the CloudHub 1.0 Shared Load
Balancer (SLB) for all incoming traffic.
Which port number must be assigned to the HTTP Listener's connector configuration so that the
Mule application properly receives HTTPS API invocations routed through the
SLB?
- A. 8082
- B. 8092
- C. 80
- D. 443
Answer:
B
Explanation:
When using CloudHub 1.0’s Shared Load Balancer (SLB) for a Mule application configured with HTTPS
in an Anypoint VPC, specific ports must be configured for the application to correctly route incoming
traffic:
Port Requirement for SLB:
The CloudHub Shared Load Balancer for HTTPS traffic requires that applications listen on port 8092
for secure (HTTPS) communication. This port is reserved specifically for SSL traffic when using SLB
with Anypoint VPCs.
Why Option B is Correct:
Setting the HTTP Listener's connector configuration to 8092 aligns with CloudHub requirements for
HTTPS via the Shared Load Balancer.
of Incorrect Options:
Option A (8082) is used for non-HTTPS (HTTP) traffic.
Option C (80) and Option D (443) are standard web ports but are not applicable within CloudHub
SLB’s internal configuration for VPC routing.
Reference
For more information on the Shared Load Balancer port configurations, refer to MuleSoft’s
documentation on CloudHub and VPC load balancer requirements .
Question 5
An established communications company is beginning its API-led connectivity journey, The company
has been using a successful Enterprise Data Model for many years. The company has identified a self-
service account management app as the first effort for API-led, and it has identified the following
APIs.
Experience layer: Mobile Account Management EAPI, Browser Account Management EAPI
Process layer: Customer Lookup PAPI, Service Lookup PAPI, Account Lookup PAPI
System layer: Customer SAPI, Account SAPI, Product SAPI, Service SAPI
According to MuleSoft's API-led connectivity approach, which API would not be served by the
Enterprise Data Model?
- A. Customer SAPI
- B. Customer Lookup PAPI
- C. Mobile Account Management EAPI
- D. Service SAPI
Answer:
C
Explanation:
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.
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.
Reference
For additional guidance, review MuleSoft's best practices on API-led connectivity and data modeling .
Question 6
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?
- A. In secrets manager, request access to the Shared Secret static username/password
- B. In API Manager, from the PROD environment of the CAR_FACTORY business group
- C. In access management, from the PROD environment of the CAR_FACTORY business group
- D. In Anypoint Exchange, from an API client application that has been approved for the TemperatureSensors API instance
Answer:
D
Explanation:
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 .
Question 7
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
Answer:
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 8
An existing Quoting API is defined in RAML and used by REST clients for interacting with the quoting
engine. Currently there is a resource defined in the RAML that allows the creation of quotes;
however, a new requirement was just received to allow for the updating of existing quotes.
Which two actions need to be taken to facilitate this change so it can be processed?
Choose 2 answers
- A. Update the API implementation to accommodate the new update request
- B. Remove the old client applications and create new client applications to account for the changes
- C. Update the RAML with new method details for the update request
- D. Deprecate existing versions of the API in Exchange
- E. Add a new API policy to API Manager to allow access to the updated endpoint
Answer:
AC
Explanation:
To accommodate the new requirement of allowing updates to existing quotes, the following actions
should be taken:
Update the RAML Definition (Option C):
The RAML specification defines the structure and behavior of the API. Adding a new method (such as
PUT or PATCH) for updating quotes requires modifying the RAML to include this new endpoint. This
ensures the API specification is up-to-date and accurately reflects the new functionality.
Update the API Implementation (Option A):
Once the RAML is updated, the backend API implementation must also be modified to handle the
new update requests. This could involve adding logic to process and validate update requests,
connect to necessary backend resources, and apply the changes to existing quotes.
of Incorrect Options:
Option B (removing and creating new clients) is unnecessary; client applications can remain as they
are, with no need for complete replacement.
Option D (deprecating existing versions) may not be required if backward compatibility is
maintained.
Option E (adding a new policy) does not facilitate functional changes and is unrelated to
implementing the update feature.
Reference
For more details on updating RAML definitions and API implementations, refer to MuleSoft’s API
Design documentation on RAML and RESTful API practices .
Question 9
An auto manufacturer has a mature CI/CD practice and wants to automate packaging and
deployment of any Mule applications to various deployment targets, including CloudHub
workers/replicas, customer-hosted Mule runtimes, and Anypoint Runtime Fabric.
Which MuleSoft-provided tool or component facilitates automating the packaging and deployment
of Mule applications to various deployment targets as part of the company's
CI/CD practice?
- A. Anypoint Runtime Manager
- B. Mule Maven plugin
- C. Anypoint Platform CLI
- D. Anypoint Platform REST APIs
Answer:
B
Explanation:
For organizations with established CI/CD practices, the Mule Maven plugin is the recommended tool
for automating packaging and deployment across multiple environments, including CloudHub, on-
premise Mule runtimes, and Anypoint Runtime Fabric. Here’s why:
Automation with Maven:
The Mule Maven plugin allows for CI/CD integration by supporting automated build and deployment
processes. It is commonly used in CI/CD pipelines to handle application packaging and deployment
directly through Maven commands, making it ideal for teams that want consistent deployment
automation across different MuleSoft environments.
Supported Deployment Targets:
The Mule Maven plugin supports deployment to various targets, including CloudHub, Runtime
Fabric, and on-premises servers, thus meeting the needs of environments with diverse deployment
destinations.
Why Option B is Correct:
The Mule Maven plugin is specifically designed for CI/CD pipelines and integrates with Jenkins,
GitLab, and other CI/CD tools to facilitate continuous deployment. It is the most efficient MuleSoft-
provided tool for this purpose.
of Incorrect Options:
Option A (Anypoint Runtime Manager) provides deployment management but does not automate
CI/CD processes.
Option C (Anypoint Platform CLI) can script deployments but lacks direct integration with CI/CD
tools.
Option D (Anypoint Platform REST APIs) requires custom scripting for deployment, which can be
more complex than using the Mule Maven plugin.
Reference
For more details, refer to MuleSoft documentation on using the Mule Maven plugin for CI/CD .
Question 10
A manufacturing company has deployed an API implementation to CloudHub and has not configured
it to be automatically restarted by CloudHub when the worker is
not responding.
Which statement is true when no API Client invokes that API implementation?
- A. No alert on the API invocations and APT implementation can be raised
- B. Alerts on the APT invocation and API implementation can be raised
- C. No alert on the API invocations is raised but alerts on the API implementation can be raised
- D. Alerts on the API invocations are raised but no alerts on the API implementation can be raised
Answer:
C
Explanation:
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.
Reference
For additional information, check MuleSoft documentation on CloudHub monitoring and alert
configurations to understand worker status alerts versus invocation alerts .
Question 11
The Line of Business (LoB) of an eCommerce company is requesting a process that sends automated
notifications via email every time a new order is processed through the
customer's mobile application or through the internal company's web application. In the future,
multiple notification channels may be added: for example, text messages and
push notifications.
What is the most effective API-led connectivity approach for the scenario described above?
A.
Create one Experience API for the web application and one for the mobile application.
Create a Process API to orchestrate and retrieve the email template from = database.
Create a System API that sends the email using the Anypoint Connector for Email.
Create one Experience API for the web application and one for the mobile application.
Create a Process API to orchestrate and retrieve the email template from = database.
Create a System API that sends the email using the Anypoint Connector for Email.
B.
Create one Experience API for the web application and one for the mobile application,
Create a Process API to orchestrate, retrieve the email template from a database, and send the email
using the Anypoint Connector for Email.
C.
Create Experience APIs for both the web application and mobile application.
Create a Process API ta orchestrate, retrieve the email template from e database, and send the email
using the Anypoint Connector for Email.
\
D.
Create Experience APIs for both the web application and mobile application.
(Create 3 Process API to orchestrate and retrieve the email template from 2 databese.
Create a System API that sends the email using the Anypoint Connector for Email.
Answer:
A
Explanation:
In this scenario, the best approach to satisfy the API-led connectivity principles and support future
scalability is:
Experience APIs:
Create separate Experience APIs for the web application and the mobile application. This allows each
application to have an optimized interface, supporting different needs and potential differences in
request/response structures or security configurations.
Process API:
A single Process API can be used to orchestrate the workflow, including retrieving the email template
from a database and preparing the email content. By centralizing this logic in the Process layer, we
can ensure it is reusable and easily adaptable for different notification channels in the future.
System API:
A System API specifically designed for sending emails (using the Anypoint Connector for Email)
abstracts the email-sending functionality from the business logic. This approach ensures that the
email-sending function is reusable and scalable, and it can easily be extended or modified if other
notification channels (like SMS or push notifications) are added later.
Why Option A is Correct:
This structure aligns with API-led connectivity principles by separating concerns across Experience,
Process, and System layers. It provides flexibility for future notification channels and isolates each
layer’s responsibility, making it easier to maintain and scale.
of Incorrect Options:
Option B lacks a separate System API for sending emails, which goes against the principle of isolating
back-end functionality in System APIs.
Option C similarly lacks a dedicated System API, reducing flexibility and reusability.
Option D suggests creating multiple Process APIs for database retrieval, which adds unnecessary
complexity and does not adhere to the single-orchestration principle typically followed in API-led
design.
Reference
For further guidance on API-led connectivity and the responsibilities of each API layer, refer to
MuleSoft’s documentation on API-led architecture and design best practices .
Question 12
Which two statements are true about the technology architecture of an Anypoint Virtual Private
Cloud (VPC)?
Choose 2 answers
- A. Ports 8081 and 8082 are used
- B. CIDR blacks are used
- C. Anypoint VPC is responsible for load balancing the applications
- D. Round-robin load balancing is used to distribute client requests across different applications
- E. By default, HTTP requests can be made from the public internet to workers at port 6091
Answer:
BE
Explanation:
An Anypoint Virtual Private Cloud (VPC) provides a secure and private networking environment for
MuleSoft applications, using specific architectural elements:
CIDR Blocks:
Anypoint VPCs utilize CIDR blocks to define IP ranges, allowing organizations to control and segment
the VPC’s IP address space.
Port 6091 for HTTP Requests:
By default, HTTP requests can be made to workers on port 6091 from the public internet, providing
an accessible entry point unless additional restrictions are applied.
of Correct Answers (B, E):
CIDR blocks enable IP range management for VPCs, and port 6091 is the default public entry port,
which is part of Anypoint VPC’s default settings.
of Incorrect Options:
Option A (Ports 8081 and 8082) is incorrect; these are not default public ports for Anypoint VPC.
Option C (responsible for load balancing) is incorrect as load balancing requires a separate Dedicated
Load Balancer (DLB).
Option D (round-robin load balancing) applies to DLBs, not directly to VPCs.
Reference
For more on VPC setup and networking, refer to MuleSoft documentation on VPC configurations and
default port settings .
Question 13
Which statement is true about identity management and client management on Anypoint Platform?
- A. If an external identity provider is configured, the SAML 2.0 bearer tokens issued by the identity provider cannot be used for invocations of the Anypoint Platform web APIs
- B. If an external client provider is configured, it must be configured at the Anypoint Platform organization level and cannot be assigned to individual business groups and environments
- C. Anypoint Platform supports configuring one external identity provider
- D. Both client management and identity management require an identity provider
Answer:
C
Explanation:
Anypoint Platform allows organizations to integrate one external identity provider (IdP) for identity
and access management (IAM), supporting SSO and centralized user authentication.
Identity Provider Limit:
Anypoint Platform supports configuring a single IdP for the organization, which can be used to
authenticate all users across business groups and environments within that Anypoint organization.
of Correct Answer (C):
Configuring one IdP ensures centralized and secure identity management, aligned with MuleSoft’s
architecture.
of Incorrect Options:
Option A is incorrect because SAML 2.0 bearer tokens from external IdPs can indeed be used for
invoking Anypoint Platform APIs.
Option B is incorrect as client providers can be assigned to specific business groups and
environments.
Option D is incorrect since only identity management strictly requires an IdP; client management
does not.
Reference
For further details on identity management options, consult MuleSoft documentation on Anypoint
Platform’s IAM capabilities .
Question 14
An organization wants to create a Center for Enablement (C4E). The IT director schedules a series of
meetings with IT senior managers.
What should be on the agenda of the first meeting?
- A. Define C4E objectives, mission statement, guiding principles, a
- B. Explore API monetization options based on identified use cases through MuleSoft
- C. A walk through of common-services best practices for logging, auditing, exception handling, caching, security via policy, and rate limiting/throttling via policy
- D. Specify operating model for the MuleSoft Integrations division
Answer:
A
Explanation:
In the initial meeting for establishing a Center for Enablement (C4E), it’s essential to lay the
foundational vision, objectives, and guiding principles for the team. Here’s why this is crucial:
Clear Vision and Mission:
Defining the mission statement and objectives at the start ensures alignment within the organization
and clarifies the C4E’s role in supporting API-led development and integration practices.
Guiding Principles:
Establishing guiding principles will help the C4E maintain consistent practices and strategies across
projects. This serves as a framework for decisions and fosters shared understanding among IT leaders
and stakeholders.
of Correct Answer (A):
By prioritizing the C4E’s objectives and mission, the organization builds a solid foundation, paving
the way for subsequent meetings focused on technical standards, processes, and operating models.
of Incorrect Options:
Option B (API monetization) and Option C (common services best practices) are specific topics better
suited for later discussions.
Option D (specifying the operating model) is an important step but typically follows the
establishment of the C4E’s objectives and vision.
Reference
For more on C4E objectives and foundational setup, refer to MuleSoft’s documentation on
establishing a C4E and the roles and mission statements recommended for such initiatives .
Question 15
A team is planning to enhance an Experience API specification, and they are following API-led
connectivity design principles.
What is their motivation for enhancing the API?
- A. The primary API consumer wants certain kinds of endpoints changed from the Center for Enablement standard to the consumer system standard
- B. The underlying System API is updated to provide more detailed data for several heavily used resources
- C. An IP Allowlist policy is being added to the API instances in the Development and Staging environments
- D. A Canonical Data Model is being adopted that impacts several types of data included in the API
Answer:
D
Explanation:
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.
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.
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.
Reference
For 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 .