Exam MCIA-Level-1 Topic 3 Question 225 Discussion
Actual exam question for MuleSoft's MCIA-Level-1 exam
Question #: 225
Topic #: 3
Question #: 225
Topic #: 3
A leading eCommerce giant will use MuleSoft APIs on Runtime Fabric (RTF) to process customer orders.
Some customer-sensitive information, such as credit card information, is required in request payloads or is included in response payloads in some of the APIs. Other API requests and responses are not authorized to access some of this customer-sensitive information but have been implemented to validate and transform based on the structure and format of this customer-sensitive information (such as account IDs, phone numbers, and postal codes).
What approach configures an API gateway to hide sensitive data exchanged between API consumers and API implementations, but can convert tokenized fields back to their original value for other API requests or responses, without having to recode the API implementations?
Later, the project team requires all API specifications to be augmented with an additional non-functional requirement (NFR) to protect the backend services from a high rate of requests, according to defined service-level agreements (SLAs). The NFR's SLAs are based on a new tiered subscription level "Gold", "Silver", or
"Platinum" that must be tied to a new parameter that is being added to the Accounts object in their enterprise data model.
Following MuleSoft's recommended best practices, how should the project team now convey the necessary non-functional requirement to stakeholders?
Some customer-sensitive information, such as credit card information, is required in request payloads or is included in response payloads in some of the APIs. Other API requests and responses are not authorized to access some of this customer-sensitive information but have been implemented to validate and transform based on the structure and format of this customer-sensitive information (such as account IDs, phone numbers, and postal codes).
What approach configures an API gateway to hide sensitive data exchanged between API consumers and API implementations, but can convert tokenized fields back to their original value for other API requests or responses, without having to recode the API implementations?
Later, the project team requires all API specifications to be augmented with an additional non-functional requirement (NFR) to protect the backend services from a high rate of requests, according to defined service-level agreements (SLAs). The NFR's SLAs are based on a new tiered subscription level "Gold", "Silver", or
"Platinum" that must be tied to a new parameter that is being added to the Accounts object in their enterprise data model.
Following MuleSoft's recommended best practices, how should the project team now convey the necessary non-functional requirement to stakeholders?
Suggested Answer: C Vote an answer
To convey the necessary non-functional requirement (NFR) related to protecting backend services from a high rate of requests according to SLAs, the following steps should be taken:
* Create a Shared RAML Fragment: Develop a RAML fragment that defines the NFR, including the SLAs for different subscription levels ("Gold", "Silver", "Platinum"). This fragment should include the details on rate limiting and throttling based on the new parameter added to the Accounts object.
* Update API Specifications: Integrate the shared RAML fragment into each API specification. This ensures that the NFR is consistently applied across all relevant APIs.
* Publish to Exchange: Publish the updated API specifications and the shared RAML fragment to Anypoint Exchange. This makes the NFR visible and accessible to all stakeholders and developers, ensuring compliance and implementation consistency.
This approach ensures that the NFR is clearly communicated and applied uniformly across all API implementations.
References
* MuleSoft Documentation on RAML and API Specifications
* Best Practices for API Design and Documentation
* Create a Shared RAML Fragment: Develop a RAML fragment that defines the NFR, including the SLAs for different subscription levels ("Gold", "Silver", "Platinum"). This fragment should include the details on rate limiting and throttling based on the new parameter added to the Accounts object.
* Update API Specifications: Integrate the shared RAML fragment into each API specification. This ensures that the NFR is consistently applied across all relevant APIs.
* Publish to Exchange: Publish the updated API specifications and the shared RAML fragment to Anypoint Exchange. This makes the NFR visible and accessible to all stakeholders and developers, ensuring compliance and implementation consistency.
This approach ensures that the NFR is clearly communicated and applied uniformly across all API implementations.
References
* MuleSoft Documentation on RAML and API Specifications
* Best Practices for API Design and Documentation
by Scott at Aug 20, 2026, 02:11 PM
0
0
0
10
Comments
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Report Comment
Commenting
You can sign-up / login (it's free).