What should be ensured before sharing an API through a public Anypoint Exchange portal?
A.
The visibility level of the API instances of that API that need to be publicly accessible should be set to public visibility
B.
The users needing access to the API should be added to the appropriate role in
Anypoint Platform
C.
The API should be functional with at least an initial implementation deployed and accessible for users to interact with
D.
The API should be secured using one of the supported authentication/authorization mechanisms to ensure that data is not compromised
The visibility level of the API instances of that API that need to be publicly accessible should be set to public visibility
Explanation: Explanation
What are 4 important Platform Capabilities offered by Anypoint Platform?
A.
API Versioning, API Runtime Execution and Hosting, API Invocation, API Consumer Engagement
B.
API Design and Development, API Runtime Execution and Hosting, API Versioning, API
Deprecation
C.
API Design and Development, API Runtime Execution and Hosting, API Operations and
Management, API Consumer Engagement
D.
API Design and Development, API Deprecation, API Versioning, API Consumer
Engagement
API Design and Development, API Runtime Execution and Hosting, API Operations and
Management, API Consumer Engagement
Explanation: Explanation
Correct Answer: API Design and Development, API Runtime Execution and Hosting, API
Operations and Management, API Consumer Engagement
*****************************************
>> API Design and Development - Anypoint Studio, Anypoint Design Center, Anypoint
Connectors
>> API Runtime Execution and Hosting - Mule Runtimes, CloudHub, Runtime Services
>> API Operations and Management - Anypoint API Manager, Anypoint Exchange
>> API Consumer Management - API Contracts, Public Portals, Anypoint Exchange, API
Notebooks
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
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 API policy would be LEAST LIKELY used when designing an Experience API that is intended to work with a consumer mobile phone or tablet application?
A.
OAuth 2.0 access token enforcement
B.
Client ID enforcement
C.
JSON threat protection
D.
IPwhitellst
IPwhitellst
Explanation: Explanation
Correct Answer: IP whitelist
*****************************************
>> OAuth 2.0 access token and Client ID enforcement policies are VERY common to apply
on Experience APIs as API consumers need to register and access the APIs using one of
these mechanisms
>> JSON threat protection is also VERY common policy to apply on Experience APIs to
prevent bad or suspicious payloads hitting the API implementations.
>> IP whitelisting policy is usually very common in Process and System APIs to only
whitelist the IP range inside the local VPC. But also applied occassionally on some
experience APIs where the End User/ API Consumers are FIXED.
>> When we know the API consumers upfront who are going to access certain Experience
APIs, then we can request for static IPs from such consumers and whitelist them to prevent
anyone else hitting the API.
However, the experience API given in the question/ scenario is intended to work with a
consumer mobile phone or tablet application. Which means, there is no way we can know
all possible IPs that are to be whitelisted as mobile phones and tablets can so many in
number and any device in the city/state/country/globe.
So, It is very LEAST LIKELY to apply IP Whitelisting on such Experience APIs whose
consumers are typically Mobile Phones or Tablets.
Version 3.0.1 of a REST API implementation represents time values in PST time using ISO 8601 hh:mm:ss format. The API implementation needs to be changed to instead represent time values in CEST time using ISO 8601 hh:mm:ss format. When following the semver.org semantic versioning specification, what version should be assigned to the updated API implementation?
A.
3.0.2
B.
4.0.0
C.
3.1.0
D.
3.0.1
4.0.0
Explanation: Explanation
Correct Answer: 4.0.0
*****************************************
As per semver.org semantic versioning specification:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes.
- MINOR version when you add functionality in a backwards compatible manner.
- PATCH version when you make backwards compatible bug fixes.
As per the scenario given in the question, the API implementation is completely changing
its behavior. Although the format of the time is still being maintained as hh:mm:ss and there
is no change in schema w.r.t format, the API will start functioning different after this change
as the times are going to come completely different.
Example: Before the change, say, time is going as 09:00:00 representing the PST. Now on,
after the change, the same time will go as 18:00:00 as Central European Summer Time is
9 hours ahead of Pacific Time.
>> This may lead to some uncertain behavior on API clients depending on how they are
handling the times in the API response. All the API clients need to be informed that the API
functionality is going to change and will return in CEST format. So, this considered as a
MAJOR change and the version of API for this new change would be 4.0.0
Refer to the exhibit.
A developer is building a client application to invoke an API deployed to the STAGING
environment that is governed by a client ID enforcement policy.
What is required to successfully invoke the API?
A.
The client ID and secret for the Anypoint Platform account owning the API in the STAGING environment
B.
The client ID and secret for the Anypoint Platform account's STAGING environment
C.
The client ID and secret obtained from Anypoint Exchange for the API instance in the
STAGING environment
D.
A valid OAuth token obtained from Anypoint Platform and its associated client ID and
secret
The client ID and secret obtained from Anypoint Exchange for the API instance in the
STAGING environment
Explanation: Explanation
Correct Answer: The client ID and secret obtained from Anypoint Exchange for the API
instance in the STAGING environment
*****************************************
>> We CANNOT use the client ID and secret of Anypoint Platform account or any individual
environments for accessing the APIs
>> As the type of policy that is enforced on the API in question is "Client ID Enforcment
Policy", OAuth token based access won't work.
Right way to access the API is to use the client ID and secret obtained from Anypoint
Exchange for the API instance in a particular environment we want to work on.
References:
Managing API instance Contracts on API Manager
https://docs.mulesoft.com/api-manager/1.x/request-access-to-api-task
https://docs.mulesoft.com/exchange/to-request-access
https://docs.mulesoft.com/api-manager/2.x/policy-mule3-client-id-based-policies
A customer wants to host their MuleSoft applications in CloudHub 1.0, and these
applications should be available at the domain https://api.acmecorp.com.
After creating a dedicated load balancer (DLB) called acme-dib-prod, which further action
must the customer take to complete the configuration?
A. Configure the DLB with a TLS certificate for api.acmecorp.com and create an A record for api.acmecorp.com to the public IP addresses associated with their DLB
B. Configure the DLB with a TLS certificate for api.acmecorp.com and create a CNAME record from api.acmecorp.com to acme-dib-prod.|lb.anypointdns.net
C. Configure the DLB with a TLS certificate for acme-dib-prod.Jb.anypointdns.net and create a CNAME record from api.acmecorp:com to acme-dlb-prod.lb.anypointdns.net
D. Configure the DLB with a TLS certificate for aplacmecorp.com and create a CNAME record from api.aomecorp.com to acme-dib-prod.ei.cloubhub.io
Explanation:
When setting up a custom domain for MuleSoft applications hosted on
CloudHub 1.0 using a Dedicated Load Balancer (DLB), follow these steps:
Set Up the TLS Certificate: Configure the DLB (acme-dib-prod) with a TLS
certificate that covers the custom domain api.acmecorp.com. This certificate will
allow HTTPS traffic to be securely directed through the DLB to your Mule
applications.
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved