Which APIs can be used with DataGraph to create a unified schema?
A. APIs 1, 3, 5
B. APIs 2, 4 ,6
C. APIs 1, 2, s5, 6
D. APIs 1, 2, 3, 4
Explanation:
To create a unified schema in MuleSoft's DataGraph, APIs must be exposed
in a way that allows DataGraph to pull and consolidate data from these APIs into a single
schema accessible to consumers. DataGraph provides a federated approach, combining
multiple APIs to form a single, unified API endpoint.
In this setup:
APIs 1, 2, 3, and 4 are suitable candidates for DataGraph because they are hosted
within the Customer VPC on CloudHub and are accessible either through a
Shared Load Balancer (LB) or a Dedicated Load Balancer (DLB). Both of these
load balancers provide public access, which is a necessary condition for
DataGraph as it must access the APIs to aggregate data.
APIs 5 and 6 are hosted on Customer Hosted Server 2, which is explicitly marked
as "Not public". Since DataGraph requires API access through a publicly
reachable endpoint to aggregate them into a unified schema, APIs 5 and 6 cannot
be used with DataGraph in this configuration.
APIs 3 and 4 on Customer Hosted Server 1 appear accessible through a Shared
LB, implying public accessibility that meets DataGraph’s requirements.
By combining APIs 1, 2, 3, and 4 within DataGraph, you can create a unified schema that
enables clients to query data seamlessly from all these APIs as if it were from a single
source.
This setup allows for efficient data retrieval and can simplify API consumption by reducing
the need to call multiple APIs individually, thus optimizing performance and developer
experience.
A System API is designed to retrieve data from a backend system that has scalability challenges. What API policy can best safeguard the backend system?
A.
IPwhitelist
B.
SLA-based rate limiting
C.
Auth 2 token enforcement
D.
Client ID enforcement
SLA-based rate limiting
Explanation: Explanation
Correct Answer: SLA-based rate limiting
*****************************************
>> Client Id enforement policy is a "Compliance" related NFR and does not help in
maintaining the "Quality of Service (QoS)". It CANNOT and NOT meant for protecting the
backend systems from scalability challenges.
>> IP Whitelisting and OAuth 2.0 token enforcement are "Security" related NFRs and again
does not help in maintaining the "Quality of Service (QoS)". They CANNOT and are NOT
meant for protecting the backend systems from scalability challenges.
Rate Limiting, Rate Limiting-SLA, Throttling, Spike Control are the policies that are "Quality
of Service (QOS)" related NFRs and are meant to help in protecting the backend systems
from getting overloaded.
https://dzone.com/articles/how-to-secure-apis
What is true about automating interactions with Anypoint Platform using tools such as Anypoint Platform REST APIs, Anypoint CU, or the Mule Maven plugin?
A.
Access to Anypoint Platform APIs and Anypoint CU can be controlled separately through the roles and permissions in Anypoint Platform, so that specific users can get access to Anypoint CLI white others get access to the platform APIs
B.
Anypoint Platform APIs can ONLY automate interactions with CloudHub, while the Mule Maven plugin is required for deployment to customer-hosted Mule runtimes
C.
By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications
D.
API policies can be applied to the Anypoint Platform APIs so that ONLY certain LOBs have access to specific functions
By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications
Explanation: Explanation
Correct Answer: By default, the Anypoint CLI and Mule Maven plugin are NOT included in
the Mule runtime, so are NOT available to be used by deployed Mule applications
*****************************************
>> We CANNOT apply API policies to the Anypoint Platform APIs like we can do on our
custom written API instances. So, option suggesting this is FALSE.
>> Anypoint Platform APIs can be used for automating interactions with both CloudHub
and customer-hosted Mule runtimes. Not JUST the CloudHub. So, option opposing this is
FALSE.
>> Mule Maven plugin is NOT mandatory for deployment to customer-hosted Mule
runtimes. It just helps your CI/CD to have smoother automation. But not a compulsory
requirement to deploy. So, option opposing this is FALSE.
>> We DO NOT have any such special roles and permissions on the platform to separately
control access for some users to have Anypoint CLI and others to have Anypoint Platform
APIs. With proper general roles/permissions (API Owner, Cloudhub Admin etc..), one can
use any of the options (Anypoint CLI or Platform APIs). So, option suggesting this is
FALSE.
Only TRUE statement given in the choices is that - Anypoint CLI and Mule Maven plugin
are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule
applications.
Maven is part of Studio or you can use other Maven installation for development.
CLI is convenience only. It is one of many ways how to install app to the runtime.
These are definitely NOT part of anything except your process of deployment or
automation.
An organization uses various cloud-based SaaS systems and multiple on-premises
systems. The on-premises systems are an important part of the organization's application
network and can only be accessed from within the organization's intranet.
What is the best way to configure and use Anypoint Platform to support integrations with
both the cloud-based SaaS systems and on-premises systems?
A) Use CloudHub-deployed Mule runtimes in an Anypoint VPC managed by Anypoint
Platform Private Cloud Edition control plane
A.
Option A
B.
Option B
C.
Option C
D.
Option D
Option B
Explanation: •Explanation
Correct Answer: Use a combination of CloudHub-deployed and manually provisioned onpremises
Mule runtimes managed by the MuleSoft-hosted Platform control plane.
*****************************************
Key details to be taken from the given scenario:
>> Organization uses BOTH cloud-based and on-premises systems
>> On-premises systems can only be accessed from within the organization's intranet
Let us evaluate the given choices based on above key details:
>> CloudHub-deployed Mule runtimes can ONLY be controlled using MuleSoft-hosted
control plane. We CANNOT use Private Cloud Edition's control plane to control CloudHub
Mule Runtimes. So, option suggesting this is INVALID
>> Using CloudHub-deployed Mule runtimes in the shared worker cloud managed by the
MuleSoft-hosted Anypoint Platform is completely IRRELEVANT to given scenario and silly
choice. So, option suggesting this is INVALID
>> Using an on-premises installation of Mule runtimes that are completely isolated with NO
external network access, managed by the Anypoint Platform Private Cloud Edition control
plane would work for On-premises integrations. However, with NO external access,
integrations cannot be done to SaaS-based apps. Moreover CloudHub-hosted apps are
best-fit for integrating with SaaS-based applications. So, option suggesting this is BEST
WAY.
The best way to configure and use Anypoint Platform to support these mixed/hybrid
integrations is to use a combination of CloudHub-deployed and manually provisioned onpremises
Mule runtimes managed by the MuleSoft-hosted Platform control plane.
A business process is being implemented within an organization's application network. The architecture group proposes using a more coarse-grained application network design with relatively fewer APIs deployed to the application network compared to a more fine-grained design. Overall, which factor typically increases with a more coarse-grained design for this business process implementation and deployment compared with using a more finegrained design?
A. The complexity of each API implementation
B. The number of discoverable assets related to APIs deployed in the application network
C. The number of possible connections between API implementations in the application network
D. The usage of network infrastructure resources by the application network
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 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
The number of API specifications in RAML or OAS format published to Anypoint
Exchange
Explanation: 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-acompany-
measure-c4e-success
To minimize operation costs, a customer wants to use a CloudHub 1.0 solution. The
customer's requirements are:
A. One production and one non-production Virtual Private Cloud (VPC).
Use availability zones to differentiate between Business groups.
Allocate maximum CIDR per VPCs to ensure HA across availability zones
B. One production and one non-production Virtual Private Cloud (VPC) per Business
group.
Minimize CIDR aligning with projected application total.
Choose a MuleSoft CloudHub 1.0 region with multiple availability zones.
Deploy multiple workers for HA,
C. One production and one non-production Virtual Private Cloud (VPC) per Business
group.
Minimize CIDR aligning with projected application total.
Divide availability zones during deployment of APIs for HA.
D. One production and one non-production Virtual Private Claud (VPC).
Configure subnet to differentiate between business groups.
Allocate maximum CIDR per VPCs to make it easier to add Child groups.
Span VPC to cover three availability zones.
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved