Get all the Information About Salesforce MuleSoft-Platform-Architect-I Exam 2026 Practice Test Questions
Check Real Salesforce MuleSoft-Platform-Architect-I Exam Question for Free (2026)
Salesforce MuleSoft-Platform-Architect-I Exam Syllabus Topics:
| Topic | Details |
|---|---|
| Topic 1 |
|
| Topic 2 |
|
| Topic 3 |
|
| Topic 4 |
|
| Topic 5 |
|
NEW QUESTION # 30
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 the majority of the applications in the application network are cloud based
- B. When there are a large number of existing common assets shared by development teams
- C. When various teams responsible for creating APIs are new to integration and hence need extensive training
- D. When development is already organized into several independent initiatives or groups
Answer: D
NEW QUESTION # 31
What should be ensured before sharing an API through a public Anypoint Exchange portal?
- A. The API should be functional with at least an initial implementation deployed and accessible for users to interact with
- B. The users needing access to the API should be added to the appropriate role in Anypoint Platform
- C. The API should be secured using one of the supported authentication/authorization mechanisms to ensure that data is not compromised
- D. The visibility level of the API instances of that API that need to be publicly accessible should be set to public visibility
Answer: D
Explanation:
Correct Answer : The visibility level of the API instances of that API that need to be publicly accessible should be set to public visibility.
*****************************************
Reference:
https://docs.mulesoft.com/exchange/to-share-api-asset-to-portal
NEW QUESTION # 32
What Mule application can have API policies applied by
Anypoint Platform to the endpoint exposed by that Mule application?
A) A Mule application that accepts requests over HTTP/1.x
B) A Mule application that accepts JSON requests over TCP but is NOT required to provide a response
C) A Mute application that accepts JSON requests over WebSocket
D) A Mule application that accepts gRPC requests over HTTP/2
- A. Option A
- B. Option B
- C. Option C
- D. Option D
Answer: A
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
NEW QUESTION # 33
When could the API data model of a System API reasonably mimic the data model exposed by the corresponding backend system, with minimal improvements over the backend system's data model?
- A. When there is an existing Enterprise Data Model widely used across the organization
- B. When the System API can be assigned to a bounded context with a corresponding data model
- C. When a pragmatic approach with only limited isolation from the backend system is deemed appropriate
- D. When the corresponding backend system is expected to be replaced in the near future
Answer: C
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
NEW QUESTION # 34
A company deploys Mule applications with default configurations through Runtime Manager to customer-hosted Mule runtimes. Each Mule application is an API implementation that exposes RESTful interfaces to API clients. The Mule runtimes are managed by the MuleSoft-hosted control plane. The payload is never used by any Logger components.
When an API client sends an HTTP request to a customer-hosted Mule application, which metadata or data (payload) is pushed to the MuleSoft-hosted control plane?
- A. The data and metadata
- B. Only the data
- C. No data
- D. Only the metadata
Answer: D
Explanation:
Understanding the Data Flow Between Mule Runtimes and Control Plane:
When Mule applications are deployed on customer-hosted Mule runtimes, the MuleSoft-hosted control plane (Anypoint Platform) can monitor and manage these applications. However, due to data privacy and security, the control plane only collects specific types of information.
Typically, only metadata about the request and response (such as headers, status codes, and timestamps) is sent to the MuleSoft-hosted control plane. The actual payload data is not transmitted unless explicitly configured, ensuring that sensitive data remains within the customer's network.
Evaluating the Options:
Option A (Only the data): This is incorrect because the payload data itself is not automatically sent to the control plane in default configurations.
Option B (No data): This is incorrect as well; while the payload is not sent, metadata is still collected and sent to the control plane.
Option C (The data and metadata): This option is incorrect because data (payload) is not transmitted to the control plane by default.
Option D (Correct Answer): Only the metadata is sent to the MuleSoft-hosted control plane by default, aligning with MuleSoft's design to prioritize security and data privacy for customer-hosted runtimes.
Conclusion:
Option D is the correct answer, as by default, only metadata is sent to the MuleSoft-hosted control plane, and not the payload. This configuration is designed to protect sensitive data from being exposed outside the customer's hosted environment.
For more details, refer to MuleSoft's documentation on telemetry data collected in customer-hosted Mule runtimes and the MuleSoft control plane.
NEW QUESTION # 35
What is true about the technology architecture of Anypoint VPCs?
- A. Each CloudHub environment requires a separate Anypoint VPC
- B. VPC peering can be used to link the underlying AWS VPC to an on-premises (non AWS) private network
- C. Traffic between Mule applications deployed to an Anypoint VPC and on-premises systems can stay within a private network
- D. The private IP address range of an Anypoint VPC is automatically chosen by CloudHub
Answer: C
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.
Reference:
Only true statement in the given choices is that the traffic between Mule applications deployed to an Anypoint VPC and on-premises systems can stay within a private network.
https://docs.mulesoft.com/runtime-manager/vpc-connectivity-methods-concept
NEW QUESTION # 36
A new upstream API Is being designed to offer an SLA of 500 ms median and 800 ms maximum (99th percentile) response time. The corresponding API implementation needs to sequentially invoke 3 downstream APIs of very similar complexity.
The first of these downstream APIs offers the following SLA for its response time: median: 100 ms, 80th percentile: 500 ms, 95th percentile: 1000 ms.
If possible, how can a timeout be set in the upstream API for the invocation of the first downstream API to meet the new upstream API's desired SLA?
- A. Do not set a timeout; the Invocation of this API Is mandatory and so we must wait until it responds
- B. Set a timeout of 100 ms; that leaves 400 ms for the other two downstream APIs to complete
- C. Set a timeout of 50 ms; this times out more invocations of that API but gives additional room for retries
- D. No timeout is possible to meet the upstream API's desired SLA; a different SLA must be negotiated with the first downstream API or invoke an alternative API
Answer: B
Explanation:
Correct Answer : Set a timeout of 100ms; that leaves 400ms for other two downstream APIs to complete
*****************************************
Key details to take from the given scenario:
>> Upstream API's designed SLA is 500ms (median). Lets ignore maximum SLA response times.
>> This API calls 3 downstream APIs sequentially and all these are of similar complexity.
>> The first downstream API is offering median SLA of 100ms, 80th percentile: 500ms; 95th percentile: 1000ms.
Based on the above details:
>> We can rule out the option which is suggesting to set 50ms timeout. Because, if the median SLA itself being offered is 100ms then most of the calls are going to timeout and time gets wasted in retried them and eventually gets exhausted with all retries. Even if some retries gets successful, the remaining time wont leave enough room for 2nd and 3rd downstream APIs to respond within time.
>> The option suggesting to NOT set a timeout as the invocation of this API is mandatory and so we must wait until it responds is silly. As not setting time out would go against the good implementation pattern and moreover if the first API is not responding within its offered median SLA 100ms then most probably it would either respond in 500ms (80th percentile) or 1000ms (95th percentile). In BOTH cases, getting a successful response from 1st downstream API does NO GOOD because already by this time the Upstream API SLA of 500 ms is breached. There is no time left to call 2nd and 3rd downstream APIs.
>> It is NOT true that no timeout is possible to meet the upstream APIs desired SLA.
As 1st downstream API is offering its median SLA of 100ms, it means MOST of the time we would get the responses within that time. So, setting a timeout of 100ms would be ideal for MOST calls as it leaves enough room of 400ms for remaining 2 downstream API calls.
NEW QUESTION # 37
Which scenario is suited for MUnit tests instead of integration tests?
- A. When no mocking is permissible
- B. When testing does not require knowledge of implementation details
- C. For read-only interactions to any dependencies (such as other web APIs)
- D. For tests that are implemented using SoapUI
Answer: C
Explanation:
MUnit is MuleSoft's testing framework for creating and running automated tests within Anypoint Studio. It is specifically designed for unit testing Mule applications and is best suited when testing doesn't require understanding the inner workings or implementation details of the components being tested.
Ideal Use Cases for MUnit:
MUnit is optimal when testing individual flows, functions, or components in isolation. This type of testing focuses on verifying the behavior of each unit without needing to understand the complete system.
Since unit tests do not require external integrations or dependencies to be live, mocking is commonly used in MUnit to simulate the behavior of external services and APIs.
Why Option B is Correct:
Option B aligns with the concept of unit testing, where the emphasis is on testing functionality rather than system integration. Integration tests, on the other hand, would require implementation knowledge and live endpoints, making them unsuitable for MUnit's scope.
of Incorrect Options:
Option A (read-only interactions) and Option C (no mocking) do not suit MUnit's typical testing environment as MUnit is designed with mocking capabilities to simulate dependencies.
Option D (SoapUI-based tests) suggests an external testing tool, while MUnit is specific to MuleSoft.
Reference
For more on MUnit best practices, refer to MuleSoft's MUnit documentation.
NEW QUESTION # 38
What is true about automating interactions with Anypoint Platform using tools such as Anypoint Platform REST APIs, Anypoint CU, or the Mule Maven plugin?
- A. API policies can be applied to the Anypoint Platform APIs so that ONLY certain LOBs have access to specific functions
- B. Anypoint Platform APIs can ONLY automate interactions with CloudHub, while the Mule Maven plugin is required for deployment to customer-hosted Mule runtimes
- C. By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications
- D. Access to Anypoint Platform APIs and Anypoint CU can be controlled separately through the roles and permissions in Anypoint Platform, so that specific users can get access to Anypoint CLI white others get access to the platform APIs
Answer: C
Explanation:
Correct Answer : By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications
*****************************************
>> We CANNOT apply API policies to the Anypoint Platform APIs like we can do on our custom written API instances. So, option suggesting this is FALSE.
>> Anypoint Platform APIs can be used for automating interactions with both CloudHub and customer-hosted Mule runtimes. Not JUST the CloudHub. So, option opposing this is FALSE.
>> Mule Maven plugin is NOT mandatory for deployment to customer-hosted Mule runtimes. It just helps your CI/CD to have smoother automation. But not a compulsory requirement to deploy. So, option opposing this is FALSE.
>> We DO NOT have any such special roles and permissions on the platform to separately control access for some users to have Anypoint CLI and others to have Anypoint Platform APIs. With proper general roles/permissions (API Owner, Cloudhub Admin etc..), one can use any of the options (Anypoint CLI or Platform APIs). So, option suggesting this is FALSE.
Only TRUE statement given in the choices is that - Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications.
Maven is part of Studio or you can use other Maven installation for development.
CLI is convenience only. It is one of many ways how to install app to the runtime.
These are definitely NOT part of anything except your process of deployment or automation.
NEW QUESTION # 39
Refer to the exhibit.
Three business processes need to be implemented, and the implementations need to communicate with several different SaaS applications.
These processes are owned by separate (siloed) LOBs and are mainly independent of each other, but do share a few business entities. Each LOB has one development team and their own budget In this organizational context, what is the most effective approach to choose the API data models for the APIs that will implement these business processes with minimal redundancy of the data models?
A) Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities
B) Build distinct data models for each API to follow established micro-services and Agile API-centric practices
C) Build all API data models using XML schema to drive consistency and reuse across the organization
D) Build one centralized Canonical Data Model (Enterprise Data Model) that unifies all the data types from all three business processes, ensuring the data model is consistent and non-redundant
- A. Option A
- B. Option B
- C. Option C
- D. Option D
Answer: A
Explanation:
Correct Answer : Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.
*****************************************
>> The options w.r.t building API data models using XML schema/ Agile API-centric practices are irrelevant to the scenario given in the question. So these two are INVALID.
>> Building EDM (Enterprise Data Model) is not feasible or right fit for this scenario as the teams and LOBs work in silo and they all have different initiatives, budget etc.. Building EDM needs intensive coordination among all the team which evidently seems not possible in this scenario.
So, the right fit for this scenario is to build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.
NEW QUESTION # 40
A retail company with thousands of stores has an API to receive data about purchases and insert it into a single database. Each individual store sends a batch of purchase data to the API about every 30 minutes. The API implementation uses a database bulk insert command to submit all the purchase data to a database using a custom JDBC driver provided by a data analytics solution provider. The API implementation is deployed to a single CloudHub worker. The JDBC driver processes the data into a set of several temporary disk files on the CloudHub worker, and then the data is sent to an analytics engine using a proprietary protocol. This process usually takes less than a few minutes. Sometimes a request fails. In this case, the logs show a message from the JDBC driver indicating an out-of-file-space message. When the request is resubmitted, it is successful. What is the best way to try to resolve this throughput issue?
- A. Use a CloudHub autoscaling policy to increase the size of the CloudHub worker
- B. se a CloudHub autoscaling policy to add CloudHub workers
- C. Increase the size of the CloudHub worker(s)
- D. Increase the number of CloudHub workers
Answer: D
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.
NEW QUESTION # 41
What is a key performance indicator (KPI) that measures the success of a typical C4E that is immediately apparent in responses from the Anypoint Platform APIs?
- A. The number of API implementations that have a publicly accessible HTTP endpoint and are being managed by Anypoint Platform
- B. The fraction of API implementations deployed manually relative to those deployed using a CI/CD tool
- C. The number of production outage incidents reported in the last 24 hours
- D. The number of API specifications in RAML or OAS format published to Anypoint Exchange
Answer: D
Explanation:
Correct Answer : The number of API specifications in RAML or OAS format published to Anypoint Exchange
*****************************************
>> The success of C4E always depends on their contribution to the number of reusable assets that they have helped to build and publish to Anypoint Exchange.
>> It is NOT due to any factors w.r.t # of outages, Manual vs CI/CD deployments or Publicly accessible HTTP endpoints
>> Anypoint Platform APIs helps us to quickly run and get the number of published RAML/OAS assets to Anypoint Exchange. This clearly depicts how successful a C4E team is based on number of returned assets in the response.
NEW QUESTION # 42
Which of the following sequence is correct?
- A. API Client implementes logic to call an API >> API Consumer requests access to API >> API routes the request to >> API Implementation
- B. API Client implementes logic to call an API >> API Consumer requests access to API >> API Implementation routes the request to >> API
- C. API Consumer implementes logic to call an API >> API Client requests access to API >> API Implementation routes the request to >> API
- D. API Consumer requests access to API >> API Client implementes logic to call an API >> API routes the request to >> API Implementation
Answer: D
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.
NEW QUESTION # 43
What are the major benefits of MuleSoft proposed IT Operating Model?
- A. 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 - B. 1. Decrease the IT delivery gap
2. Meet various business demands without increasing the IT capacity
3. Focus on creation of reusable assets first. Upon finishing creation of all the possible assets then inform the LOBs in the organization to start using them - C. 1. Decrease the IT delivery gap
2. Meet various business demands by increasing the IT capacity and forming various IT departments
3. Make consumption of assets at the rate of production
Answer: A
Explanation:
Correct Answe r:
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.
*****************************************
NEW QUESTION # 44
What is most likely NOT a characteristic of an integration test for a REST API implementation?
- A. The test is triggered by an external HTTP request
- B. The test needs all source and/or target systems configured and accessible
- C. The test prepares a known request payload and validates the response payload
- D. The test runs immediately after the Mule application has been compiled and packaged
Answer: D
Explanation:
Correct Answer : The test runs immediately after the Mule application has been compiled and packaged
*****************************************
>> Integration tests are the last layer of tests we need to add to be fully covered.
>> These tests actually run against Mule running with your full configuration in place and are tested from external source as they work in PROD.
>> These tests exercise the application as a whole with actual transports enabled. So, external systems are affected when these tests run.
So, these tests do NOT run immediately after the Mule application has been compiled and packaged.
FYI... Unit Tests are the one that run immediately after the Mule application has been compiled and packaged.
NEW QUESTION # 45
What condition requires using a CloudHub Dedicated Load Balancer?
- A. When API invocations across multiple CloudHub workers must be load balanced
- B. When server-side load-balanced TLS mutual authentication is required between API implementations and API clients
- C. When custom DNS names are required for API implementations deployed to customer-hosted Mule runtimes
- D. When cross-region load balancing is required between separate deployments of the same Mule application
Answer: B
Explanation:
Correct Answer : When server-side load-balanced TLS mutual authentication is required between API implementations and API clients
*****************************************
Fact/ Memory Tip: Although there are many benefits of CloudHub Dedicated Load balancer, TWO important things that should come to ones mind for considering it are:
>> Having URL endpoints with Custom DNS names on CloudHub deployed apps
>> Configuring custom certificates for both HTTPS and Two-way (Mutual) authentication.
Coming to the options provided for this question :
>> We
CANNOT use DLB to perform cross-region load balancing between separate deployments of the same Mule application.
>> We can have mapping rules to have more than one DLB URL pointing to same Mule app. But vicevera (More than one Mule app having same DLB URL) is NOT POSSIBLE
>> It is true that DLB helps to setup custom DNS names for Cloudhub deployed Mule apps but NOT true for apps deployed to Customer-hosted Mule Runtimes.
>> It is true to that we can load balance API invocations across multiple CloudHub workers using DLB but it is NOT A MUST. We can achieve the same (load balancing) using SLB (Shared Load Balancer) too. We DO NOT necessarily require DLB for achieve it.
So the only right option that fits the scenario and requires us to use DLB is when TLS mutual authentication is required between API implementations and API clients.
NEW QUESTION # 46
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 manage and process the secure direct communication between a back-end system and an end-user client of mobile device in the application network
- B. To secure, Manage, and process communication with specific types of end-user client applications or devices in the application network
- C. To secure and optimize the data synchronization processing of large data dumps between back-end systems
- D. To automate parts of business processes by coordinating and orchestrating the invocation of other APIs in the application network
Answer: D
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.
NEW QUESTION # 47
A company has created a successful enterprise data model (EDM). The company is committed to building an application network by adopting modern APIs as a core enabler of the company's IT operating model. At what API tiers (experience, process, system) should the company require reusing the EDM when designing modern API data models?
- A. At the experience and system tiers
- B. At the experience and process tiers
- C. At the process and system tiers
- D. At the experience, process, and system tiers
Answer: C
Explanation:
Correct Answer : At the process and system tiers
*****************************************
>> Experience Layer APIs are modeled and designed exclusively for the end user's experience. So, the data models of experience layer vary based on the nature and type of such API consumer. For example, Mobile consumers will need light-weight data models to transfer with ease on the wire, where as web-based consumers will need detailed data models to render most of the info on web pages, so on. So, enterprise data models fit for the purpose of canonical models but not of good use for experience APIs.
>> That is why, EDMs should be used extensively in process and system tiers but NOT in experience tier.
NEW QUESTION # 48
What API policy would be LEAST LIKELY used when designing an Experience API that is intended to work with a consumer mobile phone or tablet application?
- A. JSON threat protection
- B. OAuth 2.0 access token enforcement
- C. Client ID enforcement
- D. IPwhitellst
Answer: D
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.
NEW QUESTION # 49
An enterprise is embarking on the API-led digital transformation journey, and the central IT team has started to define System APIs. Currently there is no Enterprise Data Model being defined within the enterprise, and the definition of a clean Bounded Context Data Model requires too much effort.
According to MuleSoft's recommended guidelines, how should the System API data model be defined?
- A. If there are misspellings of the data fields in the back-end system, Systerm APIs should not correct it, and expose it as-is to mirror the back-end systems
- B. The System APIs should expose all back-end system fields
- C. The data model should define its own naming convention, and not follow the same naming as the back-end systems
- D. The data model of the System APIs should make use of data types that approximately mirror those from the back-end systems
Answer: D
Explanation:
When defining data models for System APIs without an established Enterprise Data Model, MuleSoft recommends mirroring the back-end systems' data types to achieve quick and effective integration without adding complexity. This approach has several benefits:
Alignment with Backend Systems:
Mirroring data types ensures consistency with backend data sources, which simplifies integration, reduces mapping requirements, and minimizes potential data transformation issues.
Flexibility for Future Enhancements:
By retaining close alignment with backend data structures, System APIs can evolve to support an Enterprise Data Model in the future without immediate restructuring.
of Incorrect Options:
Option A (exposing misspellings) is not recommended as System APIs should still ensure a professional and coherent interface.
Option C (custom naming) complicates the API structure without adding immediate value in the absence of a clear data model.
Option D (exposing all fields) is unnecessary and can reduce performance and add complexity.
Reference
Refer to MuleSoft best practices for data modeling in System APIs for additional information on mirroring backend systems.
NEW QUESTION # 50
A system API is deployed to a primary environment as well as to a disaster recovery (DR) environment, with different DNS names in each environment. A process API is a client to the system API and is being rate limited by the system API, with different limits in each of the environments. The system API's DR environment provides only 20% of the rate limiting offered by the primary environment. What is the best API fault-tolerant invocation strategy to reduce overall errors in the process API, given these conditions and constraints?
- A. Invoke the system API deployed to the primary environment; add timeout and retry logic to the process API to avoid intermittent failures; if it still fails, invoke the system API deployed to the DR environment
- B. In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment; add timeout and retry logic to the process API to avoid intermittent failures; add logic to the process API to combine the results
- C. Invoke the system API deployed to the primary environment; add timeout and retry logic to the process API to avoid intermittent failures; if it still fails, invoke a copy of the process API deployed to the DR environment
- D. Invoke the system API deployed to the primary environment; add retry logic to the process API to handle intermittent failures by invoking the system API deployed to the DR environment
Answer: A
Explanation:
Correct Answer : Invoke the system API deployed to the primary environment; add timeout and retry logic to the process API to avoid intermittent failures; if it still fails, invoke the system API deployed to the DR environment
*****************************************
There is one important consideration to be noted in the question which is - System API in DR environment provides only 20% of the rate limiting offered by the primary environment. So, comparitively, very less calls will be allowed into the DR environment API opposed to its primary environment. With this in mind, lets analyse what is the right and best fault-tolerant invocation strategy.
1. Invoking both the system APIs in parallel is definitely NOT a feasible approach because of the 20% limitation we have on DR environment. Calling in parallel every time would easily and quickly exhaust the rate limits on DR environment and may not give chance to genuine intermittent error scenarios to let in during the time of need.
2. Another option given is suggesting to add timeout and retry logic to process API while invoking primary environment's system API. This is good so far. However, when all retries failed, the option is suggesting to invoke the copy of process API on DR environment which is not right or recommended. Only system API is the one to be considered for fallback and not the whole process API. Process APIs usually have lot of heavy orchestration calling many other APIs which we do not want to repeat again by calling DR's process API. So this option is NOT right.
3. One more option given is suggesting to add the retry (no timeout) logic to process API to directly retry on DR environment's system API instead of retrying the primary environment system API first. This is not at all a proper fallback. A proper fallback should occur only after all retries are performed and exhausted on Primary environment first. But here, the option is suggesting to directly retry fallback API on first failure itself without trying main API. So, this option is NOT right too.
This leaves us one option which is right and best fit.
- Invoke the system API deployed to the primary environment
- Add Timeout and Retry logic on it in process API
- If it fails even after all retries, then invoke the system API deployed to the DR environment.
NEW QUESTION # 51
......
Use Free MuleSoft-Platform-Architect-I Exam Questions that Stimulates Actual EXAM : https://www.examdiscuss.com/Salesforce/exam/MuleSoft-Platform-Architect-I/
Get Ready to Boost your Prepare for your MuleSoft-Platform-Architect-I Exam with 154 Questions: https://drive.google.com/open?id=1SKu8tEJ0o4Tx05jGP98KANpGrt7tmuHu