A company has started to create an application network and is now planning to implement a Center for Enablement (C4E) organizational model. What key factor would lead the company to decide upon a federated rather than a centralized C4E?
A.
When there are a large number of existing common assets shared by development teams
B.
When various teams responsible for creating APIs are new to integration and hence need extensive training
C.
When development is already organized into several independent initiatives or groups
D.
When the majority of the applications in the application network are cloud based
When development is already organized into several independent initiatives or groups
Explanation: Explanation
Correct Answer: When development is already organized into several independent
initiatives or groups
*****************************************
>> It would require lot of process effort in an organization to have a single C4E team
coordinating with multiple already organized development teams which are into several
independent initiatives. A single C4E works well with different teams having at least a
common initiative. So, in this scenario, federated C4E works well instead of centralized
C4E.
A company requires Mule applications deployed to CloudHub to be isolated between nonproduction
and production environments. This is so Mule applications deployed to nonproduction
environments can only access backend systems running in their customerhosted
non-production environment, and so Mule applications deployed to production
environments can only access backend systems running in their customer-hosted
production environment. How does MuleSoft recommend modifying Mule applications,
configuring environments, or changing infrastructure to support this type of perenvironment
isolation between Mule applications and backend systems?
A.
Modify properties of Mule applications deployed to the production Anypoint Platform
environments to prevent access from non-production Mule applications
B.
Configure firewall rules in the infrastructure inside each customer-hosted environment so
that only IP addresses from the corresponding Anypoint Platform environments are allowed
to communicate with corresponding backend systems
C.
Create non-production and production environments in different Anypoint Platform
business groups
D.
Create separate Anypoint VPCs for non-production and production environments, then configure connections to the backend systems in the corresponding customer-hosted
environments
Create separate Anypoint VPCs for non-production and production environments, then configure connections to the backend systems in the corresponding customer-hosted
environments
Explanation: Explanation
Correct Answer: Create separate Anypoint VPCs for non-production and production
environments, then configure connections to the backend systems in the corresponding
customer-hosted environments.
*****************************************
>> Creating different Business Groups does NOT make any difference w.r.t accessing the
non-prod and prod customer-hosted environments. Still they will be accessing from both
Business Groups unless process network restrictions are put in place.
>> We need to modify or couple the Mule Application Implementations with the
environment. In fact, we should never implements application coupled with environments
by binding them in the properties. Only basic things like endpoint URL etc should be
bundled in properties but not environment level access restrictions.
>> IP addresses on CloudHub are dynamic until unless a special static addresses are
assigned. So it is not possible to setup firewall rules in customer-hosted infrastrcture. More
over, even if static IP addresses are assigned, there could be 100s of applications running
on cloudhub and setting up rules for all of them would be a hectic task, non-maintainable
and definitely got a good practice.
>> The best practice recommended by Mulesoft (In fact any cloud provider), is to have
your Anypoint VPCs seperated for Prod and Non-Prod and perform the VPC peering or
VPN tunneling for these Anypoint VPCs to respective Prod and Non-Prod customer-hosted
environment networks.
: https://docs.mulesoft.com/runtime-manager/virtual-private-cloud
Bottom of Form
Top of Form
In an organization, the InfoSec team is investigating Anypoint Platform related data traffic. From where does most of the data available to Anypoint Platform for monitoring and alerting originate?
A.
From the Mule runtime or the API implementation, depending on the deployment model
B.
From various components of Anypoint Platform, such as the Shared Load Balancer, VPC, and Mule runtimes
C.
From the Mule runtime or the API Manager, depending on the type of data
D.
From the Mule runtime irrespective of the deployment model
From the Mule runtime irrespective of the deployment model
Explanation: Explanation
Correct Answer: From the Mule runtime irrespective of the deployment model
*****************************************
>> Monitoring and Alerting metrics are always originated from Mule Runtimes irrespective
of the deployment model.
>> It may seems that some metrics (Runtime Manager) are originated from Mule Runtime
and some are (API Invocations/ API Analytics) from API Manager. However, this is
realistically NOT TRUE. The reason is, API manager is just a management tool for API
instances but all policies upon applying on APIs eventually gets executed on Mule
Runtimes only (Either Embedded or API Proxy).
>> Similarly all API Implementations also run on Mule Runtimes.
So, most of the day required for monitoring and alerts are originated fron Mule Runtimes
only irrespective of whether the deployment model is MuleSoft-hosted or Customer-hosted
or Hybrid.
What condition requires using a CloudHub Dedicated Load Balancer?
A.
When cross-region load balancing is required between separate deployments of the same Mule application
B.
When custom DNS names are required for API implementations deployed to customerhosted Mule runtimes
C.
When API invocations across multiple CloudHub workers must be load balanced
D.
When server-side load-balanced TLS mutual authentication is required between API
implementations and API clients
When server-side load-balanced TLS mutual authentication is required between API
implementations and API clients
Explanation: Explanation
Correct Answer: When server-side load-balanced TLS mutual authentication is required
between API implementations and API clients
*****************************************
Fact/ Memory Tip: Although there are many benefits of CloudHub Dedicated Load
balancer, TWO important things that should come to ones mind for considering it are:
>> Having URL endpoints with Custom DNS names on CloudHub deployed apps
>> Configuring custom certificates for both HTTPS and Two-way (Mutual) authentication.
Coming to the options provided for this question:
>> We CANNOT use DLB to perform cross-region load balancing between separate
deployments of the same Mule application.
>> We can have mapping rules to have more than one DLB URL pointing to same Mule
app. But vicevera (More than one Mule app having same DLB URL) is NOT POSSIBLE
>> It is true that DLB helps to setup custom DNS names for Cloudhub deployed Mule apps
but NOT true for apps deployed to Customer-hosted Mule Runtimes.
>> It is true to that we can load balance API invocations across multiple CloudHub workers
using DLB but it is NOT A MUST. We can achieve the same (load balancing) using SLB
(Shared Load Balancer) too. We DO NOT necessarily require DLB for achieve it.
So the only right option that fits the scenario and requires us to use DLB is when TLS
mutual authentication is required between API implementations and API clients.
Reference: https://docs.mulesoft.com/runtime-manager/cloudhub-dedicated-load-balancer
What is most likely NOT a characteristic of an integration test for a REST API
implementation?
A.
The test needs all source and/or target systems configured and accessible
B.
The test runs immediately after the Mule application has been compiled and packaged
C.
The test is triggered by an external HTTP request
D.
The test prepares a known request payload and validates the response payload
The test runs immediately after the Mule application has been compiled and packaged
Explanation: Explanation
Correct Answer: The test runs immediately after the Mule application has been compiled
and packaged
*****************************************
>> Integration tests are the last layer of tests we need to add to be fully covered.
>> These tests actually run against Mule running with your full configuration in place and are tested from external source as they work in PROD.
>> These tests exercise the application as a whole with actual transports enabled. So,
external systems are affected when these tests run.
So, these tests do NOT run immediately after the Mule application has been compiled and
packaged.
FYI... Unit Tests are the one that run immediately after the Mule application has been
compiled and packaged.
Reference: https://docs.mulesoft.com/mule-runtime/3.9/testing-strategies#integrationtesting
An API experiences a high rate of client requests (TPS) vwth small message paytoads.
How can usage limits be imposed on the API based on the type of client application?
A.
Use an SLA-based rate limiting policy and assign a client application to a matching SLA
tier based on its type
B.
Use a spike control policy that limits the number of requests for each client application
type
C.
Use a cross-origin resource sharing (CORS) policy to limit resource sharing between
client applications, configured by the client application type
D.
Use a rate limiting policy and a client ID enforcement policy, each configured by the
client application type
Use an SLA-based rate limiting policy and assign a client application to a matching SLA
tier based on its type
Explanation: Correct Answer: Use an SLA-based rate limiting policy and assign a client
application to a matching SLA tier based on its type.
*****************************************
>> SLA tiers will come into play whenever any limits to be imposed on APIs based on client
type
Reference: https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-slabased-
policies
Which three tools automate the deployment of Mule applications? (Choose 3 answers)
A. Runtime Manager
B. Anypoint Platform CLI
C. Platform APIs
D. Anypoint Studio
E. Mule Mayen plugin
F. API Community Manager
Explanation:
MuleSoft offers various tools to automate the deployment of Mule
applications, which can streamline deployment and management processes. Here’s how
each tool supports automated deployment:
What is true about API implementations when dealing with legal regulations that require all data processing to be performed within a certain jurisdiction (such as in the USA or the EU)?
A.
They must avoid using the Object Store as it depends on services deployed ONLY to the US East region
B.
They must use a Jurisdiction-local external messaging system such as Active MQ rather than Anypoint MQ
C.
They must te deployed to Anypoint Platform runtime planes that are managed by Anypoint Platform control planes, with both planes in the same Jurisdiction
D.
They must ensure ALL data is encrypted both in transit and at rest
They must te deployed to Anypoint Platform runtime planes that are managed by Anypoint Platform control planes, with both planes in the same Jurisdiction
Explanation: Explanation
Correct Answer: They must be deployed to Anypoint Platform runtime planes that are
managed by Anypoint Platform control planes, with both planes in the same Jurisdiction.
*****************************************
>> As per legal regulations, all data processing to be performed within a certain jurisdiction.
Meaning, the data in USA should reside within USA and should not go out. Same way, the
data in EU should reside within EU and should not go out.
>> So, just encrypting the data in transit and at rest does not help to be compliant with the
rules. We need to make sure that data does not go out too.
>> The data that we are talking here is not just about the messages that are published to
Anypoint MQ. It includes the apps running, transaction states, application logs, events,
metric info and any other metadata. So, just replacing Anypoint MQ with a locally hosted
ActiveMQ does NOT help.
>> The data that we are talking here is not just about the key/value pairs that are stored in
Object Store. It includes the messages published, apps running, transaction states,
application logs, events, metric info and any other metadata. So, just avoiding using Object
Store does NOT help.
>> The only option left and also the right option in the given choices is to deploy application
on runtime and control planes that are both within the jurisdiction.
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved