A developer deploys an API to CloudHub and applies an OAuth policy on API Manager. During testing, the API response is slow, so the developer reconfigures the API so that the out-of-the-box HTTP Caching policy is applied first, and the OAuth API policy is applied second. What will happen when an HTTP request is received?
A. In case of a cache hit, both the OAuth and HTTP Caching policies are evaluated; then the cached response is returned to the caller
B. In case of a cache it, only the HTTP Caching policy is evaluating; then the cached response is returned to the caller
C. In case of a cache miss, only the HTTP Caching policy is evaluated; then the API retrieves the data from the API implementation, and the policy stores the data to be cached in Object Store
D. In case of a cache miss, both the OAuth and HTTP Cachingpolicies are evaluated; then the API retrieves the data from the API implementation, and the policy does not store the data in Object Store
A Mule API receives a JSON payload and updates the target system with the payload. The developer uses JSON schemas to ensure the data is valid.
How can the data be validation before posting to the target system?
A.
Use a DataWeave 2.09 transform operation, and at the log of the DataWeave script, add:
%dw 2.0
Import.json-moduls
B.
Using the DataWeave if Else condition test the values of the payload against the examples included in the schema
C.
Apply the JSON Schema policy in API Manager and reference the correct schema in the policy configuration
D.
Add the JSON module dependency and add the validate-schema operation in the flow, configured to reference the schema
Add the JSON module dependency and add the validate-schema operation in the flow, configured to reference the schema
To validate the data before posting to the target system, the developer should add the JSON module dependency and add the validate-schema operation in the flow, configured to reference the schema. The JSON module provides a validate-schema operation that validates a JSON payload against a JSON schema and throws an error if the payload is invalid.
References:
https://docs.mulesoft.com/json-module/1.1/json-validate-schema
Which statement is true about using mutual TLS to secure an application?
A.
Mutual TLS requires a hardware security module to be used
B.
Mutual TLS authenticates the identity of the server before the identity of the client
C.
Mutual TLS ensures only authorized end users are allowed to access an endpoint
D.
Mutual TLS increases the encryption strength versus server-side TLS alone
Mutual TLS authenticates the identity of the server before the identity of the client
Explanation
Mutual TLS (mTLS) is an extension of TLS that requires both parties (client and server) to present their certificates to each other during the handshake process. This way, both parties can verify each other’s identity and establish a secure connection. The authentication of the server happens before the authentication of the client, as the server sends its certificate first and then requests the client’s certificate.
References:
https://docs.mulesoft.com/mule-runtime/4.3/tls-configuration#mutual-authentication
An organization uses CloudHub to deploy all of its applications. How can a common-global-handler flow be configured so that it can be reused across all of the organization’s deployed applications?
A.
Create a Mule plugin project
Create a common-global-error-handler flow inside the plugin project.
Use this plugin as a dependency in all Mute applications.
Import that configuration file in Mute applications.
B.
Create a common-global-error-handler flow in all Mule Applications Refer to it flow-ref wherever needed.
C.
Create a Mule Plugin project
Create a common-global-error-handler flow inside the plugin project.
Use this plugin as a dependency in all Mule applications
D.
Create a Mule daman project.
Create a common-global-error-handler flow inside the domain project.
Use this domain project as a dependency.
Create a Mule Plugin project
Create a common-global-error-handler flow inside the plugin project.
Use this plugin as a dependency in all Mule applications
Explanation:
To configure a common-global-handler flow that can be reused across all of the organization’s deployed applications, the developer should create a Mule Plugin project, create a common-global-error-handler flow inside the plugin project, and use this plugin as a dependency in all Mule applications. This way, the developer can import the common-global-error-handler flow in any application that needs it and avoid duplicating the error handling logic.
References:
https://docs.mulesoft.com/mule-runtime/4.3/error-handling#global-error-handler
A company deploys 10 public APIs to CloudHub. Each API has its individual health endpoint defined. The platform operation team wants to configure API Functional Monitoring to monitor the health of the APIs periodically while minimizing operational overhead and cost.
How should API Functional Monitoring be configured?
A.
From one public location with each API in its own schedule
B.
From one private location with all 10 APIs in a single schedule
C.
From one public location with all 10 APIs in a single schedule
D.
From 10 public locations with each API in its own schedule
From one public location with all 10 APIs in a single schedule
Explanation:
To configure API Functional Monitoring to monitor the health of 10 public APIs periodically while minimizing operational overhead and cost, the developer should use one public location with all 10 APIs in a single schedule. A public location is a worker that runs in a CloudHub shared environment, which is cheaper and easier to maintain than a private location. A single schedule allows running all 10 APIs tests at the same time and frequency, which reduces complexity and resource consumption.
References:
https://docs.mulesoft.com/functional-monitoring/fm-create-monitor#create-a-monitor
A healthcare portal needs to validate the token that it sends to a Mule API. The developer plans to implement a custom policy using the HTTP Policy Transform Extension to match the token received in the header from the heathcare portal. Which files does the developer need to create in order to package the custom policy?
A.
Deployable ZIP file, YAML configuration file
B.
JSON properties file, YAML configuration file
C.
JSON properties file, XML template file
D.
XML template file, YAML configuration file
XML template file, YAML configuration file
Explanation:
To package a custom policy using the HTTP Policy Transform Extension, the developer needs to create an XML template file and a YAML configuration file. The XML template file defines the policy logic using Mule components and placeholders for user-defined properties. The YAML configuration file defines the metadata of the policy, such as its name, description, category, parameters, and dependencies.
References:
https://docs.mulesoft.com/api-manager/2.x/http-policy-transform#packaging-the-policy
Which pattern should be used to invoke multiple HTTP APIs in parallel and roll back failed requests in sequence?
A.
A database as a transactional outbox and an Until Successful router to retry any requests
B.
A Parallel for Each scope with each HTTP request wrapped in a Try scope
C.
Scatter-Gather as central Saga orchestrator for all API request with compensating actions for failing routes
D.
VM queues as a reliability pattern with error handlers to roll back any requests
Scatter-Gather as central Saga orchestrator for all API request with compensating actions for failing routes
Explanation:
To invoke multiple HTTP APIs in parallel and roll back failed requests in sequence, the developer should use a Scatter-Gather router as a central Saga orchestrator for all API requests with compensating actions for failing routes. A Scatter-Gather router executes multiple routes concurrently and aggregates the results. A Saga orchestrator coordinates a series of actions across different services and handles failures by executing compensating actions. Therefore, using a Scatter-Gather router as a Saga orchestrator allows invoking multiple HTTP APIs in parallel and rolling back any failed requests in sequence.
References:
https://docs.mulesoft.com/mule-runtime/4.3/scatter-gather-concept
https://docs.mulesoft.com/mule-runtime/4.3/saga
A Mule implementation uses a HTTP Request within an Unit Successful scope to connect to an API. How should a permanent error response like HTTP:UNAUTHORIZED be handle inside Until Successful to reduce latency?
A.
Configure retrying until a MULERETRY_EXHAUSTED error is raised or the API responds back with a successful response.
B.
In Until Successful configuration, set the retry count to 1 for error type HTTP: UNAUTHORIZED.
C.
Put the HTTP Request inside a try scope in Unit Successful.
In the error handler, use On Error Continue to catch permanent errors like HTTP UNAUTHORIZED.
D.
Put the HTTP Request inside a try scope in Unit Successful.
In the error handler, use On Error Propagate to catch permanent errors like HTTP UNAUTHORIZED.
Put the HTTP Request inside a try scope in Unit Successful.
In the error handler, use On Error Continue to catch permanent errors like HTTP UNAUTHORIZED.
Explanation:
To handle a permanent error response like HTTP:UNAUTHORIZED inside Until Successful, the developer should put the HTTP Request inside a try scope in Unit Successful, and use On Error Continue to catch permanent errors like HTTP UNAUTHORIZED in the error handler. This way, the developer can avoid retrying requests that will always fail due to a permanent error, and reduce latency. On Error Continue allows the flow to continue processing after handling the error.
References:
https://docs.mulesoft.com/mule-runtime/4.3/until-successful-scope
https://docs.mulesoft.com/mule-runtime/4.3/on-error-continue-concept
| Page 1 out of 6 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved