When can CloudHub Object Store v2 be used?
A. To store an unlimited number of key-value pairs
B. To store payloads with an average size greater than 15MB
C. To store information in Mule 4 Object Store v1
D. To store key-value pairs with keys up to 300 characters
Explanation: CloudHub Object Store v2 is a managed key-value store provided by
MuleSoft to support various use cases where temporary data storage is required. Here’s
why Option D is correct:
Key Length Support: Object Store v2 allows storage of keys with a length of up to
300 characters, making it suitable for applications needing flexible and descriptive
keys.
Limitations on Size:
Key-Value Limits: Object Store v2 is designed for moderate, transient storage
needs, and does not support unlimited storage. Thus, Option A is incorrect.
Backward Compatibility: Object Store v2 does not support Mule 4 applications
running Object Store v1. Option C is incorrect as Object Store v1 and v2 are
distinct.
A Platform Architect inherits a legacy monolithic SOAP-based web service that performs a number of tasks, including showing all policies belonging to a client. The service connects to two back-end systems — a life-insurance administration system and a general-insurance administration system — and then queries for insurance policy information within each system, aggregates the results, and presents a SOAP-based response to a user interface (UI). The architect wants to break up the monolithic web service to follow API-led conventions. Which part of the service should be put into the process layer?
A. Combining the insurance policy information from the administration systems
B. Presenting the SOAP-based response to the UI
C. Authenticating and maintaining connections to each of the back-end administration systems
D. Querying the data from the administration systems
Explanation:
In the API-led connectivity approach, each layer (System, Process, and
Experience) has a distinct purpose:
Say, there is a legacy CRM system called CRM-Z which is offering below functions:
1. Customer creation
2. Amend details of an existing customer
3. Retrieve details of a customer
4. Suspend a customer
A.
Implement a system API named customerManagement which has all the functionalities
wrapped in it as various operations/resources
B.
Implement different system APIs named createCustomer, amendCustomer,
retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns
C.
Implement different system APIs named createCustomerInCRMZ,
amendCustomerInCRMZ, retrieveCustomerFromCRMZ and suspendCustomerInCRMZ as
they are modular and has seperation of concerns
Implement different system APIs named createCustomer, amendCustomer,
retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns
Correct Answer: Implement different system APIs named createCustomer,
amendCustomer, retrieveCustomer and suspendCustomer as they are modular and has
seperation of concerns
*****************************************
>> It is quite normal to have a single API and different Verb + Resource combinations.
However, this fits well for an Experience API or a Process API but not a best architecture
style for System APIs. So, option with just one customerManagement API is not the best
choice here.
>> The option with APIs in createCustomerInCRMZ format is next close choice w.r.t
modularization and less maintenance but the naming of APIs is directly coupled with the
legacy system. A better foreseen approach would be to name your APIs by abstracting the
backend system names as it allows seamless replacement/migration of any backend
system anytime. So, this is not the correct choice too.
>> createCustomer, amendCustomer, retrieveCustomer and suspendCustomer is the right
approach and is the best fit compared to other options as they are both modular and same
time got the names decoupled from backend system and it has covered all requirements a
System API needs.
What is a typical result of using a fine-grained rather than a coarse-grained API deployment model to implement a given business process?
A.
A decrease in the number of connections within the application network supporting the business process
B.
A higher number of discoverable API-related assets in the application network
C.
A better response time for the end user as a result of the APIs being smaller in scope and complexity
D.
An overall tower usage of resources because each fine-grained API consumes less resources
A higher number of discoverable API-related assets in the application network
Explanation: Explanation
Correct Answer: A higher number of discoverable API-related assets in the application
network.
*****************************************
>> We do NOT get faster response times in fine-grained approach when compared to
coarse-grained approach.
>> In fact, we get faster response times from a network having coarse-grained APIs
compared to a network having fine-grained APIs model. The reasons are below.
Fine-grained approach:
1. will have more APIs compared to coarse-grained
2. So, more orchestration needs to be done to achieve a functionality in business process.
3. Which means, lots of API calls to be made. So, more connections will needs to be
established. So, obviously more hops, more network i/o, more number of integration points
compared to coarse-grained approach where fewer APIs with bulk functionality embedded
in them.
4. That is why, because of all these extra hops and added latencies, fine-grained approach
will have bit more response times compared to coarse-grained.
5. Not only added latencies and connections, there will be more resources used up in finegrained
approach due to more number of APIs.
That's why, fine-grained APIs are good in a way to expose more number of resuable assets
in your network and make them discoverable. However, needs more maintenance, taking
care of integration points, connections, resources with a little compromise w.r.t network
hops and response times.
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
Mule applications that implement a number of REST APIs are deployed to their own subnet
that is inaccessible from outside the organization.
External business-partners need to access these APIs, which are only allowed to be
invoked from a separate subnet dedicated to partners - called Partner-subnet. This subnet
is accessible from the public internet, which allows these external partners to reach it.
Anypoint Platform and Mule runtimes are already deployed in Partner-subnet. These Mule
runtimes can already access the APIs.
What is the most resource-efficient solution to comply with these requirements, while
having the least impact on other applications that are currently using the APIs?
A.
Implement (or generate) an API proxy Mule application for each of the APIs, then deploy the API proxies to the Mule runtimes
B.
Redeploy the API implementations to the same servers running the Mule runtimes
C.
Add an additional endpoint to each API for partner-enablement consumption
D.
Duplicate the APIs as Mule applications, then deploy them to the Mule runtimes
Implement (or generate) an API proxy Mule application for each of the APIs, then deploy the API proxies to the Mule runtimes
A company deploys Mule applications with default configurations through Runtime Manager to customer-hosted Mule runtimes. Each Mule application is an API implementation that exposes RESTful interfaces to API clients. The Mule runtimes are managed by the MuleSoft-hosted control plane. The payload is never used by any Logger components. When an API client sends an HTTP request to a customer-hosted Mule application, which metadata or data (payload) is pushed to the MuleSoft-hosted control plane?
A. Only the data
B. No data
C. The data and metadata
D. Only the metadata
Several times a week, an API implementation shows several thousand requests per minute
in an Anypoint Monitoring dashboard, Between these bursts, the
dashboard shows between two and five requests per minute. The API implementation is
running on Anypoint Runtime Fabric with two non-clustered replicas, reserved vCPU 1.0
and vCPU Limit 2.0.
An API consumer has complained about slow response time, and the dashboard shows the
99 percentile is greater than 120 seconds at the time of the complaint. It also shows greater than 90% CPU usage during these time periods.
In manual tests in the QA environment, the API consumer has consistently reproduced the
slow response time and high CPU usage, and there were no other API requests at
this time. In a brainstorming session, the engineering team has created several proposals
to reduce the response time for requests.
Which proposal should be pursued first?
A. Increase the vCPU resources of the API implementation
B. Modify the API client to split the problematic request into smaller, less-demanding requests
C. Increase the number of replicas of the API implementation
D. Throttle the APT client to reduce the number of requests per minute
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved