サンプル問題 1： What API policy would LEAST likely be applied to a Process API?
A: Custom circuit breaker
B: Client ID enforcement
C: Rate limiting
D: JSON threat protection
正解：D
Explanation: Correct Answer JSON threat protection Fact: Technically, there are no restrictions on what policy can be applied in what layer. Any policy can be applied on any layer API. However, context should also be considered properly before blindly applying the policies on APIs. That is why, this question asked for a policy that would LEAST likely be applied to a Process API. From the given options: >> All policies except "JSON threat protection" can be applied without hesitation to the APIs in Process tier. >> JSON threat protection policy ideally fits for experience APIs to prevent suspicious JSON payload coming from external API clients. This covers more of a security aspect by trying to avoid possibly malicious and harmful JSON payloads from external clients calling experience APIs. As external API clients are NEVER allowed to call Process APIs directly and also these kind of malicious and harmful JSON payloads are always stopped at experience API layer only using this policy, it is LEAST LIKELY that this same policy is again applied on Process Layer API. Reference: https://docs.mulesoft.com/api-manager/2.x/policy-mule3-provided-policies
サンプル問題 2： 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 production outage incidents reported in the last 24 hours
B: The number of API implementations that have a publicly accessible HTTP endpoint and are being managed by Anypoint Platform
C: The fraction of API implementations deployed manually relative to those deployed using a CI/CD tool
D: The number of API specifications in RAML or OAS format published to Anypoint Exchange
正解：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. Reference: https://help.mulesoft.com/s/question/0D52T00004mXSTUSA4/how-should-a-company-measure-c4e-success
サンプル問題 3： An organization is implementing a Quote of the Day API that caches today's quote. What scenario can use the GoudHub Object Store via the Object Store connector to persist the cache's state?
A: When there are three CloudHub deployments of the API implementation to three separate CloudHub regions that must share the cache state
B: When there are two CloudHub deployments of the API implementation by two Anypoint Platform business groups to the same CloudHub region that must share the cache state
C: When there is one deployment of the API implementation to CloudHub and anottV deployment to a customer-hosted Mule runtime that must share the cache state
D: When there is one CloudHub deployment of the API implementation to three CloudHub workers that must share the cache state
正解：D
Explanation: Correct Answer When there is one CloudHub deployment of the API implementation to three CloudHub workers that must share the cache state. Key details in the scenario: >> Use the CloudHub Object Store via the Object Store connector Considering above details: >> CloudHub Object Stores have one-to-one relationship with CloudHub Mule Applications. >> We CANNOT use an application's CloudHub Object Store to be shared among multiple Mule applications running in different Regions or Business Groups or Customer-hosted Mule Runtimes by using Object Store connector. >> If it is really necessary and very badly needed, then Anypoint Platform supports a way by allowing access to CloudHub Object Store of another application using Object Store REST API. But NOT using Object Store connector. So, the only scenario where we can use the CloudHub Object Store via the Object Store connector to persist the cache’s state is when there is one CloudHub deployment of the API implementation to multiple CloudHub workers that must share the cache state.
