Which of the following best fits the definition of API-led connectivity?
A.
API-led connectivity is not just an architecture or technology but also a way to organize people and processes for efficient IT delivery in the organization
B.
API-led connectivity is a 3-layered architecture covering Experience, Process and System layers
C.
API-led connectivity is a technology which enabled us to implement Experience, Process and System layer based APIs
API-led connectivity is not just an architecture or technology but also a way to organize people and processes for efficient IT delivery in the organization
Explanation: Explanation
Correct Answer: API-led connectivity is not just an architecture or technology but also a
way to organize people and processes for efficient IT delivery in the organization.
*****************************************
Reference: https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/
Refer to the exhibit. An organization is running a Mule standalone runtime and has
configured Active Directory as the Anypoint Platform external Identity Provider. The organization does not have budget for other system components.
What policy should be applied to all instances of APIs in the organization to most
effecuvelyKestrict access to a specific group of internal users?
A.
Apply a basic authentication - LDAP policy; the internal Active Directory will be
configured as the LDAP source for authenticating users
B.
Apply a client ID enforcement policy; the specific group of users will configure their client applications to use their specific client credentials
C.
Apply an IP whitelist policy; only the specific users' workstations will be in the whitelist
D.
Apply an OAuth 2.0 access token enforcement policy; the internal Active Directory will be configured as the OAuth server
Apply a basic authentication - LDAP policy; the internal Active Directory will be
configured as the LDAP source for authenticating users
Explanation: Explanation
Correct Answer: Apply a basic authentication - LDAP policy; the internal Active Directory
will be configured as the LDAP source for authenticating users.
*****************************************
>> IP Whitelisting does NOT fit for this purpose. Moreover, the users workstations may not
necessarily have static IPs in the network.
>> OAuth 2.0 enforcement requires a client provider which isn't in the organizations system
components.
>> It is not an effective approach to let every user create separate client credentials and
configure those for their usage.
The effective way it to apply a basic authentication - LDAP policy and the internal Active
Directory will be configured as the LDAP source for authenticating users.
Reference: https://docs.mulesoft.com/api-manager/2.x/basic-authentication-ldap-concept
What correctly characterizes unit tests of Mule applications?
A.
They test the validity of input and output of source and target systems
B.
They must be run in a unit testing environment with dedicated Mule runtimes for the environment
C.
They must be triggered by an external client tool or event source
D.
They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity
They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity
Explanation: Explanation
Correct Answer: They are typically written using MUnit to run in an embedded Mule runtime
that does not require external connectivity.
*****************************************
Below TWO are characteristics of Integration Tests but NOT unit tests:
>> They test the validity of input and output of source and target systems.
>> They must be triggered by an external client tool or event source.
It is NOT TRUE that Unit Tests must be run in a unit testing environment with dedicated
Mule runtimes for the environment.
MuleSoft offers MUnit for writing Unit Tests and they run in an embedded Mule Runtime
without needing any separate/ dedicated Runtimes to execute them. They also do NOT
need any external connectivity as MUnit supports mocking via stubs.
https://dzone.com/articles/munit-framework
What is a best practice when building System APIs?
A.
Document the API using an easily consumable asset like a RAML definition
B.
Model all API resources and methods to closely mimic the operations of the backend system
C.
Build an Enterprise Data Model (Canonical Data Model) for each backend system and apply it to System APIs
D.
Expose to API clients all technical details of the API implementation's interaction wifch
the backend system
Model all API resources and methods to closely mimic the operations of the backend system
Explanation: Explanation
Correct Answer: Model all API resources and methods to closely mimic the operations of
the backend system.
*****************************************
>> There are NO fixed and straight best practices while opting data models for APIs. They
are completly contextual and depends on number of factors. Based upon those factors, an
enterprise can choose if they have to go with Enterprise Canonical Data Model or Bounded
Context Model etc.
>> One should NEVER expose the technical details of API implementation to their API
clients. Only the API interface/ RAML is exposed to API clients.
>> It is true that the RAML definitions of APIs should be as detailed as possible and should
reflect most of the documentation. However, just that is NOT enough to call your API as
best documented API. There should be even more documentation on Anypoint Exchange
with API Notebooks etc. to make and create a developer friendly API and repository..
>> The best practice always when creating System APIs is to create their API interfaces by
modeling their resources and methods to closely reflect the operations and functionalities
of that backend system.
Traffic is routed through an API proxy to an API implementation. The API proxy is managed
by API Manager and the API implementation is deployed to a CloudHub VPC using
Runtime Manager. API policies have been applied to this API. In this deployment scenario,
at what point are the API policies enforced on incoming API client requests?
A.
At the API proxy
B.
At the API implementation
C.
At both the API proxy and the API implementation
D.
At a MuleSoft-hosted load balancer
At the API proxy
Explanation: Explanation
Correct Answer: At the API proxy
*****************************************
>> API Policies can be enforced at two places in Mule platform.
>> One - As an Embedded Policy enforcement in the same Mule Runtime where API
implementation is running.
>> Two - On an API Proxy sitting in front of the Mule Runtime where API implementation is
running.
>> As the deployment scenario in the question has API Proxy involved, the policies will be
enforced at the API Proxy.
Which of the following sequence is correct?
A.
API Client implementes logic to call an API >> API Consumer requests access to API >>
API Implementation routes the request to >> API
B.
API Consumer requests access to API >> API Client implementes logic to call an API >>
API routes the request to >> API Implementation
C.
API Consumer implementes logic to call an API >> API Client requests access to API >>
API Implementation routes the request to >> API
D.
API Client implementes logic to call an API >> API Consumer requests access to API >>
API routes the request to >> API Implementation
API Consumer requests access to API >> API Client implementes logic to call an API >>
API routes the request to >> API Implementation
Explanation: Explanation
Correct Answer: API Consumer requests access to API >> API Client implementes logic to
call an API >> API routes the request to >> API Implementation
*****************************************
>> API consumer does not implement any logic to invoke APIs. It is just a role. So, the
option stating "API Consumer implementes logic to call an API" is INVALID.
>> API Implementation does not route any requests. It is a final piece of logic where
functionality of target systems is exposed. So, the requests should be routed to the API
implementation by some other entity. So, the options stating "API Implementation routes
the request to >> API" is INVALID
>> The statements in one of the options are correct but sequence is wrong. The sequence
is given as "API Client implementes logic to call an API >> API Consumer requests access
to API >> API routes the request to >> API Implementation". Here, the statements in the
options are VALID but sequence is WRONG.
>> Right option and sequence is the one where API consumer first requests access to API
on Anypoint Exchange and obtains client credentials. API client then writes logic to call an
API by using the access client credentials requested by API consumer and the requests will
be routed to API implementation via the API which is managed by API Manager
A Mule application exposes an HTTPS endpoint and is deployed to the CloudHub Shared Worker Cloud. All traffic to that Mule application must stay inside the AWS VPC. To what TCP port do API invocations to that Mule application need to be sent?
A.
443
B.
8081
C.
8091
D.
8082
8082
Explanation: Explanation
Correct Answer: 8082
*****************************************
>> 8091 and 8092 ports are to be used when keeping your HTTP and HTTPS app private
to the LOCAL VPC respectively.
>> Above TWO ports are not for Shared AWS VPC/ Shared Worker Cloud.
>> 8081 is to be used when exposing your HTTP endpoint app to the internet through
Shared LB
>> 8082 is to be used when exposing your HTTPS endpoint app to the internet through
Shared LB
So, API invocations should be sent to port 8082 when calling this HTTPS based app.
References:
https://docs.mulesoft.com/runtime-manager/cloudhub-networking-guide
https://help.mulesoft.com/s/article/Configure-Cloudhub-Application-to-Send-a-HTTPSRequest-
Directly-to-Another-Cloudhub-Application
https://help.mulesoft.com/s/question/0D52T00004mXXULSA4/multiple-http-listerners-oncloudhub-
one-with-port-9090
What is true about where an API policy is defined in Anypoint Platform and how it is then applied to API instances?
A.
The API policy Is defined In Runtime Manager as part of the API deployment to a Mule
runtime, and then ONLY applied to the specific API Instance
B.
The API policy Is defined In API Manager for a specific API Instance, and then ONLY
applied to the specific API instance
C.
The API policy Is defined in API Manager and then automatically applied to ALL API instances
D.
The API policy is defined in API Manager, and then applied to ALL API instances in the
specified environment
The API policy Is defined In API Manager for a specific API Instance, and then ONLY
applied to the specific API instance
Explanation: Explanation
Correct Answer: The API policy is defined in API Manager for a specific API instance, and
then ONLY applied to the specific API instance.
*****************************************
>> Once our API specifications are ready and published to Exchange, we need to visit API
Manager and register an API instance for each API.
>> API Manager is the place where management of API aspects takes place like
addressing NFRs by enforcing policies on them.
>> We can create multiple instances for a same API and manage them differently for
different purposes.
>> One instance can have a set of API policies applied and another instance of same API
can have different set of policies applied for some other purpose.
>> These APIs and their instances are defined PER environment basis. So, one need to
manage them seperately in each environment.
>> We can ensure that same configuration of API instances (SLAs, Policies etc..) gets
promoted when promoting to higher environments using platform feature. But this is
optional only. Still one can change them per environment basis if they have to.
>> Runtime Manager is the place to manage API Implementations and their Mule Runtimes
but NOT APIs itself. Though API policies gets executed in Mule Runtimes, We CANNOT
enforce API policies in Runtime Manager. We would need to do that via API Manager only
for a cherry picked instance in an environment.
So, based on these facts, right statement in the given choices is - "The API policy is
defined in API Manager for a specific API instance, and then ONLY applied to the specific
API instance".
Reference: https://docs.mulesoft.com/api-manager/2.x/latest-overview-concept
| Page 1 out of 19 Pages |