MuleSoft-Platform-Architect-I試験問題集合格できるには更新された2025年10月テスト問題集 [Q83-Q105]

MuleSoft-Platform-Architect-I試験問題集合格できるには更新された2025年10月テスト問題集

MuleSoft-Platform-Architect-Iテスト問題練習は2025年最新のに更新された154問あります

質問 # 83
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. Remove the old client applications and create new client applications to account for the changes
• B. Deprecate existing versions of the API in Exchange
• C. Add a new API policy to API Manager to allow access to the updated endpoint
• D. Update the RAML with new method details for the update request
• E. Update the API implementation to accommodate the new update request

正解：D、E

解説：
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.

質問 # 84
Several times a week, an API implementation shows several thousand requests per minute in an Anypoint Monitoring dashboard, Between these bursts, the dashboard shows between two and five requests per minute. The API implementation is running on Anypoint Runtime Fabric with two non-clustered replicas, reserved vCPU 1.0 and vCPU Limit 2.0.
An API consumer has complained about slow response time, and the dashboard shows the 99 percentile is greater than 120 seconds at the time of the complaint. It also shows greater than 90% CPU usage during these time periods.
In manual tests in the QA environment, the API consumer has consistently reproduced the slow response time and high CPU usage, and there were no other API requests at this time. In a brainstorming session, the engineering team has created several proposals to reduce the response time for requests.
Which proposal should be pursued first?

• A. Modify the API client to split the problematic request into smaller, less-demanding requests
• B. Throttle the APT client to reduce the number of requests per minute
• C. Increase the vCPU resources of the API implementation
• D. Increase the number of replicas of the API implementation

正解：C

解説：
Scenario Analysis:
The API implementation is experiencing high CPU usage (over 90%) during bursts of requests, which correlates with slow response times, as indicated by a 99th percentile response time greater than 120 seconds.
The API implementation is running on Anypoint Runtime Fabric with two non-clustered replicas and has a reserved vCPU of 1.0 and a vCPU limit of 2.0.
The high CPU usage during bursts suggests that the current resources may not be sufficient to handle peak loads.
Evaluating the Options:
Option A (Correct Answer): Increasing the vCPU resources for each replica would provide more processing power to handle high traffic volumes, potentially reducing the response time during spikes. Since the CPU usage is consistently high during bursts, this option directly addresses the resource bottleneck.
Option B: Modifying the API client to split requests may reduce individual request load but could be complex to implement on the client side and may not fully address the high CPU issue.
Option C: Increasing the number of replicas could help distribute the load; however, with a high CPU load on each replica, adding more replicas without increasing CPU resources may not fully resolve the problem.
Option D: Throttling the client would reduce the number of requests, but this may not be acceptable if the client needs to maintain a high request rate. It also does not directly address the CPU limitations of the API implementation.
Conclusion:
Option A is the best choice as it addresses the root cause of high CPU usage by increasing the vCPU allocation, allowing the API to handle more requests efficiently. This should be pursued first before considering other options.
Refer to MuleSoft's documentation on Runtime Fabric and vCPU resource allocation for more details on optimizing API performance in high-demand environments.

質問 # 85
A Rate Limiting policy is applied to an API implementation to protect the back-end system. Recently, there have been surges in demand that cause some API client POST requests to the API implementation to be rejected with policy-related errors, causing delays and complications to the API clients.
How should the API policies that are applied to the API implementation be changed to reduce the frequency of errors returned to API clients, while still protecting the back-end system?

• A. Keep the Rate Limiting policy and add 9 Client ID Enforcement policy
• B. Remove the Rate Limiting policy and add a Spike Control policy
• C. Remove the Rate Limiting policy and add an HTTP Caching policy
• D. Keep the Rate Limiting policy and add an SLA-based Spike Control policy

正解：D

解説：
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.
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.
Reference
For more information on configuring Rate Limiting and SLA-based Spike Control policies, refer to MuleSoft documentation on API Policies and Rate Limiting.

質問 # 86
An organization wants to make sure only known partners can invoke the organization's APIs. To achieve this security goal, the organization wants to enforce a Client ID Enforcement policy in API Manager so that only registered partner applications can invoke the organization's APIs. In what type of API implementation does MuleSoft recommend adding an API proxy to enforce the Client ID Enforcement policy, rather than embedding the policy directly in the application's JVM?

• A. A Mule 3 or Mule 4 application modified with custom Java code
• B. A Non-Mule application
• C. A Mule 3 application using APIkit
• D. A Mule 4 application with an API specification

正解：B

解説：
Correct Answer : A Non-Mule application
*****************************************
>> All type of Mule applications (Mule 3/ Mule 4/ with APIkit/ with Custom Java Code etc) running on Mule Runtimes support the Embedded Policy Enforcement on them.
>> The only option that cannot have or does not support embedded policy enforcement and must have API Proxy is for Non-Mule Applications.
So, Non-Mule application is the right answer.

質問 # 87
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. Configure one Worker Not Responding alert.in Anypoint Runtime Manager for all API implementations that will then monitor every API implementation
• C. 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
• D. Handle API invocation exceptions within the calling API client and raise an alert from that API client when such an exception is thrown

正解：A

解説：
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.

質問 # 88
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 C
• B. Option B
• C. Option D
• D. Option A

正解：D

解説：
Correct Answe r: 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.

質問 # 89
When should idempotency be taken into account?

• A. When making requests to update currently locked entities
• B. When sending concurrent update requests for the same entity
• C. When preventing duplicate processing from multiple sent requests
• D. When storing the results of s previous request for use in response to subsequent requests

正解：C

解説：
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.

質問 # 90
When can CloudHub Object Store v2 be used?

• A. To store key-value pairs with keys up to 300 characters
• B. To store payloads with an average size greater than 15MB
• C. To store information in Mule 4 Object Store v1
• D. To store an unlimited number of key-value pairs

正解：A

解説：
CloudHub Object Store v2 is a managed key-value store provided by MuleSoft to support various use cases where temporary data storage is required. Here's why Option D is correct:
Key Length Support: Object Store v2 allows storage of keys with a length of up to 300 characters, making it suitable for applications needing flexible and descriptive keys.
Limitations on Size:
Object Store v2 is not intended for large payload storage and has a recommended size limit below 10 MB for each value. Payloads exceeding 15 MB may cause performance issues and are better suited to a file storage system or database.
Option B is incorrect because storing payloads above 15 MB exceeds Object Store's optimal usage specifications.
Key-Value Limits: Object Store v2 is designed for moderate, transient storage needs, and does not support unlimited storage. Thus, Option A is incorrect.
Backward Compatibility: Object Store v2 does not support Mule 4 applications running Object Store v1. Option C is incorrect as Object Store v1 and v2 are distinct.
Reference
For more on CloudHub Object Store v2, refer to MuleSoft documentation on Object Store limitations and configuration.

質問 # 91
An Order API triggers a sequence of other API calls to look up details of an order's items in a back-end inventory database. The Order API calls the OrderItems process API, which calls the Inventory system API. The Inventory system API performs database operations in the back-end inventory database.
The network connection between the Inventory system API and the database is known to be unreliable and hang at unpredictable times.
Where should a two-second timeout be configured in the API processing sequence so that the Order API never waits more than two seconds for a response from the Orderltems process API?

• A. In the Inventory system API implementation
• B. In the inventory database
• C. In the Orderltems process API implementation
• D. In the Order API implementation

正解：C

解説：
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.

質問 # 92
4 Production environment is running on a dedicated Virtual Private Cloud (VPC) on CloudHub 1,0, and the security team guidelines clearly state no traffic on HTTP.
Which two options support these security guidelines?
Choose 2 answers

• A. Remove the entry from the VPC firewall rule
  
• B. Add the entry in the VPC firewall rule.
  
• C. Configure the IP Blocklist policy to control access to a configured API endpoint from either a single IP address or a range of IP addresses.
• D. Create a custom policy to apply to outgoing and incoming HTTP requests to control access to a configured API endpoint
• E. Configure the HTTPS protocol in HTTP listener in the Mule application

正解：A、E

解説：
Security Guidelines Overview:
The production environment is hosted on a dedicated Virtual Private Cloud (VPC) on CloudHub 1.0, with a specific requirement from the security team that no traffic should occur over HTTP. This implies that only secure HTTPS traffic should be permitted, and HTTP access (port 8081, the default HTTP port in Mule applications) should be disabled.
Evaluating the Options:
Option A (Correct Answer): Configuring the HTTPS protocol in the HTTP listener in the Mule application ensures that all traffic is encrypted and occurs over HTTPS (port 8092 by default for HTTPS on Mule applications). This directly aligns with the security guideline to prevent unencrypted HTTP traffic.
Option B: Creating a custom policy for incoming and outgoing HTTP requests could provide some control over access, but it does not enforce the use of HTTPS exclusively. This option does not disable HTTP traffic and, therefore, does not meet the guideline effectively.
Option C (Correct Answer): Removing the entry for HTTP (port 8081) in the VPC firewall rule ensures that HTTP traffic is completely blocked at the firewall level. This prevents any HTTP requests from reaching the application, adding a layer of security that complies with the guidelines.
Option D: The IP Blocklist policy controls access based on IP addresses but does not enforce the use of HTTPS. This policy does not address the specific requirement of preventing HTTP traffic.
Option E: Adding a firewall rule entry for HTTP (port 8081) would enable HTTP traffic, which directly contradicts the security guidelines. Therefore, this option should be avoided.
Conclusion:
Option A and Option C are the correct choices. Configuring the HTTPS protocol in the Mule application's HTTP listener ensures that only HTTPS traffic is allowed, and removing the firewall rule for HTTP (port 8081) blocks any HTTP traffic from reaching the application. Together, these options enforce secure traffic as required by the security guidelines.
Refer to MuleSoft documentation on configuring HTTP listeners and managing VPC firewall rules for further details on implementing these security controls.

質問 # 93
What is the most performant out-of-the-box solution in Anypoint Platform to track transaction state in an asynchronously executing long-running process implemented as a Mule application deployed to multiple CloudHub workers?

• A. File-based storage
• B. Persistent Object Store
• C. java.util.WeakHashMap
• D. Redis distributed cache

正解：B

解説：
Correct Answer : Persistent Object Store
*****************************************
>> Redis distributed cache is performant but NOT out-of-the-box solution in Anypoint Platform
>> File-storage is neither performant nor out-of-the-box solution in Anypoint Platform
>> java.util.WeakHashMap needs a completely custom implementation of cache from scratch using Java code and is limited to the JVM where it is running. Which means the state in the cache is not worker aware when running on multiple workers. This type of cache is local to the worker. So, this is neither out-of-the-box nor worker-aware among multiple workers on cloudhub. https://www.baeldung.com/java-weakhashmap
>> Persistent Object Store is an out-of-the-box solution provided by Anypoint Platform which is performant as well as worker aware among multiple workers running on CloudHub. https://docs.mulesoft.com/object-store/ So, Persistent Object Store is the right answer.

質問 # 94
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. Increase the size of the CloudHub worker(s)
• B. Use a CloudHub autoscaling policy to increase the size of the CloudHub worker
• C. Increase the number of CloudHub workers
• D. se a CloudHub autoscaling policy to add CloudHub workers

正解：C

解説：
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.

質問 # 95
Refer to the exhibit.
What is the best way to decompose one end-to-end business process into a collaboration of Experience, Process, and System APIs?
A) Handle customizations for the end-user application at the Process API level rather than the Experience API level B) Allow System APIs to return data that is NOT currently required by the identified Process or Experience APIs C) Always use a tiered approach by creating exactly one API for each of the 3 layers (Experience, Process and System APIs) D) Use a Process API to orchestrate calls to multiple System APIs, but NOT to other Process APIs

• A. Option C
• B. Option D
• C. Option B
• D. Option A

正解：C

解説：
Correct Answe r: Allow System APIs to return data that is NOT currently required by the identified Process or Experience APIs.
*****************************************
>> All customizations for the end-user application should be handled in "Experience API" only. Not in Process API
>> We should use tiered approach but NOT always by creating exactly one API for each of the 3 layers. Experience APIs might be one but Process APIs and System APIs are often more than one. System APIs for sure will be more than one all the time as they are the smallest modular APIs built in front of end systems.
>> Process APIs can call System APIs as well as other Process APIs. There is no such anti-design pattern in API-Led connectivity saying Process APIs should not call other Process APIs.
So, the right answer in the given set of options that makes sense as per API-Led connectivity principles is to allow System APIs to return data that is NOT currently required by the identified Process or Experience APIs. This way, some future Process APIs can make use of that data from System APIs and we need NOT touch the System layer APIs again and again.

質問 # 96
A System API is designed to retrieve data from a backend system that has scalability challenges. What API policy can best safeguard the backend system?

• A. Client ID enforcement
• B. SLA-based rate limiting
• C. Auth 2 token enforcement
• D. IPwhitelist

正解：B

解説：
Correct Answer : SLA-based rate limiting
*****************************************
>> Client Id enforement policy is a "Compliance" related NFR and does not help in maintaining the "Quality of Service (QoS)". It CANNOT and NOT meant for protecting the backend systems from scalability challenges.
>> IP Whitelisting and OAuth 2.0 token enforcement are "Security" related NFRs and again does not help in maintaining the "Quality of Service (QoS)". They CANNOT and are NOT meant for protecting the backend systems from scalability challenges.
Rate Limiting, Rate Limiting-SLA, Throttling, Spike Control are the policies that are "Quality of Service (QOS)" related NFRs and are meant to help in protecting the backend systems from getting overloaded.
https://dzone.com/articles/how-to-secure-apis

質問 # 97
The implementation of a Process API must change.
What is a valid approach that minimizes the impact of this change on API clients?

• A. Postpone changes until API consumers acknowledge they are ready to migrate to a new Process API or API version
• B. Update the RAML definition of the current Process API and notify API client developers by sending them links to the updated RAML definition
• C. Implement the Process API changes in a new API implementation, and have the old API implementation return an HTTP status code 301 - Moved Permanently to inform API clients they should be calling the new API implementation
• D. Implement required changes to the Process API implementation so that whenever possible, the Process API's RAML definition remains unchanged

正解：D

解説：
Correct Answer : Implement required changes to the Process API implementation so that, whenever possible, the Process API's RAML definition remains unchanged.
*****************************************
Key requirement in the question is:
>> Approach that minimizes the impact of this change on API clients
Based on above:
>> Updating the RAML definition would possibly impact the API clients if the changes require any thing mandatory from client side. So, one should try to avoid doing that until really necessary.
>> Implementing the changes as a completely different API and then redirectly the clients with 3xx status code is really upsetting design and heavily impacts the API clients.
>> Organisations and IT cannot simply postpone the changes required until all API consumers acknowledge they are ready to migrate to a new Process API or API version. This is unrealistic and not possible.
The best way to handle the changes always is to implement required changes to the API implementations so that, whenever possible, the API's RAML definition remains unchanged.

質問 # 98
Refer to the exhibit.

what is true when using customer-hosted Mule runtimes with the MuleSoft-hosted Anypoint Platform control plane (hybrid deployment)?

• A. The MuleSoft-hosted Shared Load Balancer can be used to load balance API invocations to the Mule runtimes
• B. Anypoint Runtime Manager initiates a network connection to a Mule runtime in order to deploy Mule applications
• C. Anypoint Runtime Manager automatically ensures HA in the control plane by creating a new Mule runtime instance in case of a node failure
• D. API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane

正解：D

解説：
Correct Answe r: API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane.
*****************************************
>> We CANNOT use Shared Load balancer to load balance APIs on customer hosted runtimes
>> For Hybrid deployment models, the on-premises are first connected to Runtime Manager using Runtime Manager agent. So, the connection is initiated first from On-premises to Runtime Manager. Then all control can be done from Runtime Manager.
>> Anypoint Runtime Manager CANNOT ensure automatic HA. Clusters/Server Groups etc should be configured before hand.
Only TRUE statement in the given choices is, API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane. There are several references below to justify this statement.
Reference:
https://docs.mulesoft.com/runtime-manager/deployment-strategies#hybrid-deployments
https://help.mulesoft.com/s/article/On-Premise-Runtimes-Disconnected-From-US-Control-Plane-June-18th-2018
https://help.mulesoft.com/s/article/Runtime-Manager-cannot-manage-On-Prem-Applications-and-Servers-from-US-Control-Plane-June-25th-2019
https://help.mulesoft.com/s/article/On-premise-Runtimes-Appear-Disconnected-in-Runtime-Manager-May-29th-2018

質問 # 99
What do the API invocation metrics provided by Anypoint Platform provide?

• A. Measurements of the effectiveness of the application network based on the level of reuse
• B. ROI metrics from APIs that can be directly shared with business users
• C. Data on past API invocations to help identify anomalies and usage patterns across various APIs
• D. Proactive identification of likely future policy violations that exceed a given threat threshold

正解：C

解説：
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.

質問 # 100
What CANNOT be effectively enforced using an API policy in Anypoint Platform?

• A. Maintaining tamper-proof credentials between APIs
• B. Logging HTTP requests and responses
• C. Backend system overloading
• D. Guarding against Denial of Service attacks

正解：D

解説：
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.

質問 # 101
A company deployed an API to a single worker/replica in the shared cloud in the U.S. West Region.
What happens when the Availability Zone experiences an outage?

• A. CloudHub will auto-redeploy the API in another Availability Zone in the U.S. West Region
• B. CloudHub will auto-redeploy the APL in the U.S. East Region
• C. The APT will be unavailable until the availability comes back online, at which time the worker/replica will be auto-restarted
• D. The Anypoint Platform admin is alerted when the AP] is experiencing an outage and needs the trigger the CI/CD pipeline to redeploy to the US. East Region

正解：C

解説：
In a CloudHub deployment with a single worker/replica located in a specific Availability Zone (AZ), if an AZ experiences an outage, here's what happens:
Worker Availability: Since the application is deployed in a single AZ, CloudHub does not automatically redeploy the application in a different zone or region during an outage. Thus, if the current AZ is unavailable, the application will be offline.
Auto-Restart upon AZ Recovery: Once the affected AZ is back online, CloudHub will auto-restart the worker in the same AZ without manual intervention. This ensures that as soon as the AZ is functional, the application resumes automatically.
of Correct Answer (B):
Option B accurately describes the situation, as the API will remain unavailable until the original AZ is restored.
CloudHub does not currently support automatic failover across regions or other availability zones within the same region for single-worker deployments on the shared cloud.
of Incorrect Options:
Option A (auto-redeployment in the U.S. East region) is incorrect, as CloudHub does not migrate across regions automatically.
Option C (redeployment in another AZ within the U.S. West) is not a feature for single-worker deployments.
Option D (manual redeployment triggered by an admin) is unnecessary as CloudHub handles restarts automatically when the AZ is back online.
Reference
Refer to MuleSoft CloudHub's availability and disaster recovery documentation for more information on how CloudHub manages availability in shared environments.

質問 # 102
A system API has a guaranteed SLA of 100 ms per request. The system API is deployed to a primary environment as well as to a disaster recovery (DR) environment, with different DNS names in each environment. An upstream process API invokes the system API and the main goal of this process API is to respond to client requests in the least possible time. In what order should the system APIs be invoked, and what changes should be made in order to speed up the response time for requests from the process API?

• A. In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment using a scatter-gather configured with a timeout, and then merge the responses
• B. Invoke the system API deployed to the primary environment, and if it fails, invoke the system API deployed to the DR environment
• C. Invoke ONLY the system API deployed to the primary environment, and add timeout and retry logic to avoid intermittent failures
• D. In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response

正解：D

解説：
Correct Answer : In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment, and ONLY use the first response.
*****************************************
>> The API requirement in the given scenario is to respond in least possible time.
>> The option that is suggesting to first try the API in primary environment and then fallback to API in DR environment would result in successful response but NOT in least possible time. So, this is NOT a right choice of implementation for given requirement.
>> Another option that is suggesting to ONLY invoke API in primary environment and to add timeout and retries may also result in successful response upon retries but NOT in least possible time. So, this is also NOT a right choice of implementation for given requirement.
>> One more option that is suggesting to invoke API in primary environment and API in DR environment in parallel using Scatter-Gather would result in wrong API response as it would return merged results and moreover, Scatter-Gather does things in parallel which is true but still completes its scope only on finishing all routes inside it. So again, NOT a right choice of implementation for given requirement The Correct choice is to invoke the API in primary environment and the API in DR environment parallelly, and using ONLY the first response received from one of them.

質問 # 103
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. A walk through of common-services best practices for logging, auditing, exception handling, caching, security via policy, and rate limiting/throttling via policy
• B. Specify operating model for the MuleSoft Integrations division
• C. Explore API monetization options based on identified use cases through MuleSoft
• D. Define C4E objectives, mission statement, guiding principles, a

正解：D

解説：
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.

質問 # 104
What is true about where an API policy is defined in Anypoint Platform and how it is then applied to API instances?

• A. The API policy Is defined in API Manager and then automatically applied to ALL API instances
• B. The API policy Is defined In Runtime Manager as part of the API deployment to a Mule runtime, and then ONLY applied to the specific API Instance
• C. The API policy Is defined In API Manager for a specific API Instance, and then ONLY applied to the specific API instance
• D. The API policy is defined in API Manager, and then applied to ALL API instances in the specified environment

正解：C

解説：
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".

質問 # 105
......

正真正銘のMuleSoft-Platform-Architect-I問題集には100%合格率練習テスト問題集：https://www.goshiken.com/Salesforce/MuleSoft-Platform-Architect-I-mondaishu.html

更新されたプレミアムMuleSoft-Platform-Architect-I試験エンジンPDF：https://drive.google.com/open?id=1Edw7rA_COuHbD27ft0RXXN11Frv30Dks