Deal of The Day! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

Salesforce Exam MuleSoft-Platform-Architect-I Topic 3 Question 2 Discussion

Actual exam question for Salesforce's Salesforce Certified MuleSoft Platform Architect I exam
Question #: 2
Topic #: 3
[All Salesforce Certified MuleSoft Platform Architect I Questions]

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?

Show Suggested Answer Hide Answer
Suggested Answer: D

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.


Contribute your Thoughts:

Reta
2 months ago
Hey, I heard the exam is offering a 'Client ID Enforcement' mood ring for the right answer. Time to channel my inner API security guru!
upvoted 0 times
...
Mary
2 months ago
Hmm, I'd go with C as well. Mule 4 and API specs sound like the right way to handle this security requirement. Not trying to 'reinvent the wheel' here.
upvoted 0 times
...
Huey
2 months ago
D) A Non-Mule application? Really? I think MuleSoft would recommend using their own platform for this use case.
upvoted 0 times
Floyd
1 months ago
C) A Mule 4 application with an API specification
upvoted 0 times
...
Kimbery
2 months ago
B) A Mule 3 or Mule 4 application modified with custom Java code
upvoted 0 times
...
Yasuko
2 months ago
A) A Mule 3 application using APIkit
upvoted 0 times
...
Felicidad
2 months ago
B) A Mule 3 or Mule 4 application modified with custom Java code
upvoted 0 times
...
Felicidad
2 months ago
C) A Mule 4 application with an API specification
upvoted 0 times
...
Felicidad
2 months ago
A) A Mule 3 application using APIkit
upvoted 0 times
...
...
Yaeko
3 months ago
I agree with C. Mule 4 with an API spec is the way to go. Embedding the policy in the app's JVM sounds like a maintenance nightmare.
upvoted 0 times
Olga
2 months ago
I agree, C seems like the most efficient choice for enforcing the Client ID Enforcement policy.
upvoted 0 times
...
Edwin
2 months ago
I would go with C as well. It's more scalable and easier to maintain.
upvoted 0 times
...
Mauricio
2 months ago
Agreed, embedding the policy directly in the app's JVM does sound like a headache.
upvoted 0 times
...
Gilma
2 months ago
I think C is the best option too. It's much easier to manage with an API spec.
upvoted 0 times
...
Buck
2 months ago
Yeah, embedding the policy directly in the app's JVM does sound like a headache. C seems like the most efficient choice.
upvoted 0 times
...
Kimbery
2 months ago
I think C is the best option too. It's easier to manage with an API spec.
upvoted 0 times
...
Alonzo
2 months ago
I think C is the best option too. It's much easier to manage with an API spec.
upvoted 0 times
...
...
Margurite
3 months ago
C) A Mule 4 application with an API specification is the way to go. Seems like the most straightforward solution to enforce the Client ID policy.
upvoted 0 times
Jodi
3 months ago
A) A Mule 3 application using APIkit
upvoted 0 times
...
Teri
3 months ago
C) A Mule 4 application with an API specification is the way to go. Seems like the most straightforward solution to enforce the Client ID policy.
upvoted 0 times
...
...

Save Cancel