Salesforce Certified MuleSoft Platform Integration Architect (Mule-Arch-202) Exam - Topic 7 Question 3 Discussion

Actual exam question for Salesforce's Salesforce Certified MuleSoft Platform Integration Architect (Mule-Arch-202) exam

Question #: 3
Topic #: 7

[All Salesforce Certified MuleSoft Platform Integration Architect (Mule-Arch-202) Questions]

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?

ACreate and deploy API proxies in API Manager for the NFR, change the baseurl in each
API specification to the corresponding API proxy implementation endpoint, and publish each modified API specification to Exchange

BUpdate each API specification with comments about the NFR's SLAs and publish each modified API specification to Exchange

CUpdate each API specification with a shared RAML fragment required to implement the NFR and publish the RAML fragment and each modified API specification to Exchange

DCreate a shared RAML fragment required to implement the NFR, list each API implementation endpoint in the RAML fragment, and publish the RAML fragment to Exchange

Show Suggested Answer

Suggested Answer: A

by Nickolas at May 18, 2024, 04:39 PM

Limited Time Offer

25%

Off

Get Premium Salesforce Certified MuleSoft Platform Integration Architect (Mule-Arch-202) Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

Submit Cancel

Lenna

3 months ago

Not sure if creating a RAML fragment is the best way to go.

upvoted 0 times

...

Anjelica

3 months ago

Definitely agree with using shared RAML fragments for clarity.

upvoted 0 times

...

Caprice

3 months ago

Surprised they didn't mention tokenization for sensitive data!

upvoted 0 times

...

Essie

4 months ago

I think updating specs with comments is too vague.

upvoted 0 times

...

Norah

4 months ago

Sounds like a solid plan to use API proxies for the NFR!

upvoted 0 times

...

Harrison

4 months ago

I'm a bit confused about whether we should be creating new RAML fragments or just updating existing ones. I feel like both options could work, but I can't remember which is recommended.

upvoted 0 times

...

France

4 months ago

I recall that using shared RAML fragments can help standardize the implementation of NFRs across multiple APIs. It seems like a good way to ensure consistency.

upvoted 0 times

...

Eun

4 months ago

I think we practiced a similar question where we had to update API specifications with comments. That might be an option here, but it feels a bit too simplistic for the NFR.

upvoted 0 times

...

Oretha

5 months ago

I remember we discussed how API proxies can help with hiding sensitive data, but I'm not entirely sure if that's the best approach for this specific scenario.

upvoted 0 times

...

Tammara

5 months ago

Okay, the sensitive data handling and the NFR for rate limiting seem like the main challenges here. I'm going to focus on understanding the MuleSoft best practices for each of those, and then I think I can put together a solid approach.

upvoted 0 times

...

Ines

5 months ago

Alright, I think I've got a handle on this. The key is using API proxies to handle the sensitive data and the rate limiting. And then we'll need to update the API specs accordingly. Let's do this!

upvoted 0 times

...

Madonna

5 months ago

Whoa, this is a lot of information to process. I'm a little confused about the different requirements and how they all fit together. I'll need to take some time to really understand the problem before I start trying to solve it.

upvoted 0 times

...

Merissa

5 months ago

Okay, let's see. We need to hide sensitive data but also be able to convert it back for other requests. And then we need to add an NFR for rate limiting. I think I have an idea, but I'll need to double-check the MuleSoft best practices.

upvoted 0 times

...

Vicente

5 months ago

Hmm, this seems like a tricky one. I'll need to carefully read through the details and think about the best approach.

upvoted 0 times

...

Hassie

5 months ago

I'm a little confused by the wording of this question. Let me re-read it and see if I can figure out the right answer.

upvoted 0 times

...

Galen

5 months ago

Hmm, the image shows a firewall rule, but I'm not sure exactly what it's telling me. I'll need to read the question and options closely to figure out the right answer.

upvoted 0 times

...

Daniel

5 months ago

I think I know the answer to this one. Segment routing needs to be enabled both globally and under the routing process, so I'm going with option A.

upvoted 0 times

...

Lauran

2 years ago

Haha, imagine if the project team just added a new 'Platinum VIP' tier that gave unlimited access to all the sensitive customer data. Talk about missing the point of security!

upvoted 0 times

Ernest

2 years ago

Haha, that would definitely defeat the purpose of protecting sensitive data!

upvoted 0 times

...

Shannon

2 years ago

A) Create and deploy API proxies in API Manager for the NFR, change the baseurl in each API specification to the corresponding API proxy implementation endpoint, and publish each modified API specification to Exchange

upvoted 0 times

...

Lizette

2 years ago

Definitely, they need to prioritize protecting customer data.

upvoted 0 times

...

Miles

2 years ago

That would be a major security breach!

upvoted 0 times

...

Jonell

2 years ago

Definitely, they need to prioritize protecting customer data.

upvoted 0 times

...

Chanel

2 years ago

That would be a major security breach!

upvoted 0 times

...

Veronique

2 years ago

I'm not sure about option A. Changing the base URL in the API specs seems like a bit of a hack to me. I'd prefer the more transparent approach of option C, where we can clearly document the new requirements.

upvoted 0 times

...

Helga

2 years ago

This question is all about securing sensitive customer data and implementing rate limiting for API requests. I think option C is the way to go, as it allows us to update the API specs with the necessary RAML fragments for the non-functional requirements.

upvoted 0 times