A Mule 4 API has been deployed to CloudHub and a Basic Authentication - Simple policy has been applied to all API methods and resources. However, the API is still accessible by clients without using authentication. How is this possible?
A. The APE Router component is pointing to the incorrect Exchange version of the APT
B. The Autodiscovery element is not present, in the deployed Mule application
C. No… for client applications have been created of this API
D. One of the application’s CloudHub workers restarted
Explanation:
When a Basic Authentication policy is applied to an API on CloudHub but
clients can still access the API without authentication, the likely cause is a missing
Autodiscovery element. Here’s how this affects API security:
When using CloudHub with the Shared Load Balancer, what is managed EXCLUSIVELY
by the API implementation (the Mule application) and NOT by Anypoint Platform?
A.
The assignment of each HTTP request to a particular CloudHub worker
B.
The logging configuration that enables log entries to be visible in Runtime Manager
C.
The SSL certificates used by the API implementation to expose HTTPS endpoints
D.
The number of DNS entries allocated to the API implementation
The SSL certificates used by the API implementation to expose HTTPS endpoints
Explanation: Explanation
Correct Answer: The SSL certificates used by the API implementation to expose HTTPS
endpoints
*****************************************
>> The assignment of each HTTP request to a particular CloudHub worker is taken care by
Anypoint Platform itself. We need not manage it explicitly in the API implementation and in
fact we CANNOT manage it in the API implementation.
>> The logging configuration that enables log entries to be visible in Runtime Manager is
ALWAYS managed in the API implementation and NOT just for SLB. So this is not
something we do EXCLUSIVELY when using SLB.
>> We DO NOT manage the number of DNS entries allocated to the API implementation
inside the code. Anypoint Platform takes care of this.
It is the SSL certificates used by the API implementation to expose HTTPS endpoints that
is to be managed EXCLUSIVELY by the API implementation. Anypoint Platform does NOT
do this when using SLBs.
Which out-of-the-box key performance indicator measures the success of a typical Center for Enablement and is immediately available in responses from Anypoint Platform APIs?
A. Per business group, the ratio of the number of production APT implementations deployed using a C1/CD pipeline to the number of production API implementations deployed manually
B. Per deployed API implementation, the amount of bandwidth consumed each day
C. Per published API, the number of developers that downloaded s version of the API specification
D. Per published API, the number of consumers that requested access to the API and have been approved in the Production environment
When designing an upstream API and its implementation, the development team has been
advised to NOT set timeouts when invoking a downstream API, because that downstream
API has no SLA that can be relied upon. This is the only downstream API dependency of
that upstream API.
Assume the downstream API runs uninterrupted without crashing. What is the impact of
this advice?
A.
An SLA for the upstream API CANNOT be provided
B.
The invocation of the downstream API will run to completion without timing out
C.
A default timeout of 500 ms will automatically be applied by the Mule runtime in which the upstream API implementation executes
D.
A toad-dependent timeout of less than 1000 ms will be applied by the Mule runtime in
which the downstream API implementation executes
An SLA for the upstream API CANNOT be provided
Explanation: Explanation
Correct Answer: An SLA for the upstream API CANNOT be provided.
*****************************************
>> First thing first, the default HTTP response timeout for HTTP connector is 10000 ms (10
seconds). NOT 500 ms.
>> Mule runtime does NOT apply any such "load-dependent" timeouts. There is no such
behavior currently in Mule.
>> As there is default 10000 ms time out for HTTP connector, we CANNOT always
guarantee that the invocation of the downstream API will run to completion without timing
out due to its unreliable SLA times. If the response time crosses 10 seconds then the
request may time out.
The main impact due to this is that a proper SLA for the upstream API CANNOT be
provided.
Reference: https://docs.mulesoft.com/http-connector/1.5/http-documentation#parameters-3
An organization has implemented a Customer Address API to retrieve customer address
information. This API has been deployed to multiple environments and has been configured
to enforce client IDs everywhere.
A developer is writing a client application to allow a user to update their address. The
developer has found the Customer Address API in Anypoint Exchange and wants to use it
in their client application.
What step of gaining access to the API can be performed automatically by Anypoint
Platform?
A.
Approve the client application request for the chosen SLA tier
B.
Request access to the appropriate API Instances deployed to multiple environments using the client application's credentials
C.
Modify the client application to call the API using the client application's credentials
D.
Create a new application in Anypoint Exchange for requesting access to the API
Approve the client application request for the chosen SLA tier
Explanation: Explanation
Correct Answer: Approve the client application request for the chosen SLA tier
*****************************************
>> Only approving the client application request for the chosen SLA tier can be automated
>> Rest of the provided options are not valid
Reference: https://docs.mulesoft.com/api-manager/2.x/defining-sla-tiers#defining-a-tier
What Mule application deployment scenario requires using Anypoint Platform Private Cloud Edition or Anypoint Platform for Pivotal Cloud Foundry?
A.
When it Is required to make ALL applications highly available across multiple data centers
B.
When it is required that ALL APIs are private and NOT exposed to the public cloud
C.
When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data
D.
When ALL backend systems in the application network are deployed in the
organization's intranet
When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data
Explanation: Explanation
Correct Answer: When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data.
*****************************************
We need NOT require to use Anypoint Platform PCE or PCF for the below. So these
options are OUT.
>> We can make ALL applications highly available across multiple data centers using
CloudHub too.
>> We can use Anypoint VPN and tunneling from CloudHub to connect to ALL backend
systems in the application network that are deployed in the organization's intranet.
>> We can use Anypoint VPC and Firewall Rules to make ALL APIs private and NOT
exposed to the public cloud.
Only valid reason in the given options that requires to use Anypoint Platform PCE/ PCF is -
When regulatory requirements mandate on-premises processing of EVERY data item,
including meta-data
A developer from the Central IT team has created an initial version of the RAML definition in Design Center for an OAuth 2.0-protected System API and published it to Exchange. Another developer from LoB IT discovered the System API in Exchange and would like to leverage it in the Process API. What is the MuleSoft-recommended approach for Process API to invoke the System API?
A. The Process API needs to import an CAuth 2.0 module from Exchange first and update it with OAuth 2.0 credentials before the System API can be invoked
B. The Process API uses property YAML files to store the System API URLs and uses the HTTP Request Connector to invoke the Systerm API
C. The Process APL uses the REST Connect Connector autogenerated in Exchange for the System API
D. The Process API manually updates the Process API POM file to include the System API as a dependency
Explanation:
In MuleSoft’s ecosystem, when a Process API needs to consume a System
API (published to Exchange and protected by OAuth 2.0), the recommended approach is to
utilize the REST Connect Connector. Here’s how it aligns with best practices:
What is typically NOT a function of the APIs created within the framework called API-led connectivity?
A.
They provide an additional layer of resilience on top of the underlying backend system,
thereby insulating clients from extended failure of these systems.
B.
They allow for innovation at the user Interface level by consuming the underlying assets
without being aware of how data Is being extracted from backend systems.
C.
They reduce the dependency on the underlying backend systems by helping unlock data
from backend systems In a reusable and consumable way.
D.
They can compose data from various sources and combine them with orchestration logic to create higher level value.
They provide an additional layer of resilience on top of the underlying backend system,
thereby insulating clients from extended failure of these systems.
Explanation: Explanation
Correct Answer: They provide an additional layer of resilience on top of the underlying
backend system, thereby insulating clients from extended failure of these systems.
*****************************************
In API-led connectivity,
>> Experience APIs - allow for innovation at the user interface level by consuming the
underlying assets without being aware of how data is being extracted from backend
systems.
>> Process APIs - compose data from various sources and combine them with
orchestration logic to create higher level value
>> System APIs - reduce the dependency on the underlying backend systems by helping
unlock data from backend systems in a reusable and consumable way.
However, they NEVER promise that they provide an additional layer of resilience on top of
the underlying backend system, thereby insulating clients from extended failure of these
systems.
https://dzone.com/articles/api-led-connectivity-with-mule
| Page 1 out of 19 Pages |