Available in 1, 3, 6 and 12 Months Free Updates Plans
PDF: $15 $60

Test Engine: $20 $80

PDF + Engine: $25 $99

MuleSoft-Integration-Architect-I Practice Test


Page 10 out of 54 Pages

As a part of project requirement, client will send a stream of data to mule application. Payload size can vary between 10mb to 5GB. Mule application is required to transform the data and send across multiple sftp servers. Due to the cost cuttings in the organization, mule application can only be allocated one worker with size of 0.2 vCore. As an integration architect , which streaming strategy you would suggest to handle this scenario?


A. In-memory non repeatable stream


B. File based non-repeatable stream


C. In-memory repeatable stream


D. File based repeatable storage





D.
  File based repeatable storage

Explanation

As the question says that data needs to be sent across multiple sftp serves , we cannot use non-repeatable streams. The non-repeatable strategy disables repeatable streams, which enables you to read an input stream only once.

You cant use in memory storage because with 0.2 vcore you will get only 1 GB of heap memory. Hence application will error out for file more than 1 GB.

Hence the correct option is file base repeatable stream

An organization is successfully using API led connectivity, however, as the application network grows, all the manually performed tasks to publish share and discover, register, apply policies to, and deploy an API are becoming repetitive pictures driving the organization to automate this process using efficient CI/'CD pipeline. Considering Anypoint platforms capabilities how should the organization approach automating is API lifecycle?


A. Use runtime manager rest apis for API management and mavenforAPI deployment


B. Use Maven with a custom configuration required for the API lifecycle


C. Use Anypoint CLI or Anypoint Platform REST apis with scripting language such as groovy


D. Use Exchange rest api's for API management and MavenforAPI deployment





C.
  Use Anypoint CLI or Anypoint Platform REST apis with scripting language such as groovy

Explanation:

To automate the API lifecycle in a CI/CD pipeline efficiently, leveraging Anypoint Platform's capabilities is crucial. Anypoint CLI (Command Line Interface) and Anypoint Platform REST APIs provide robust tools for managing various aspects of the API lifecycle, such as publishing, sharing, discovering, registering, applying policies, and deploying APIs. By using these tools with a scripting language like Groovy, you can script and automate these tasks to reduce manual intervention, ensuring consistency and efficiency.

Anypoint CLI allows you to interact with the Anypoint Platform from the command line, enabling automated deployments, management of APIs, and configuration of policies. The Anypoint Platform REST APIs provide comprehensive programmatic access to the platform’s functionalities, allowing for seamless integration into CI/CD pipelines. By combining these with a scripting language, you can create scripts that automate repetitive tasks, streamline processes, and ensure that your API lifecycle management is both efficient and reliable.

References:

MuleSoft Documentation on Anypoint CLI

MuleSoft Documentation on Anypoint Platform REST APIs

In which order are the API Client, API Implementation, and API interface components called in a typical REST request?


A. API Client > API implementation > API Interface


B. API interface > API Client > API Implementation


C. API Client > API Interface > API implementation


D. API Implementation > API Interface > API Client





C.
  API Client > API Interface > API implementation

Explanation:

In a typical REST request, the order of interaction is:

API Client: The client initiates the request to access data or functionality exposed by the API. API Interface: This represents the contract or the definition of the API, often specified in OpenAPI or RAML. It defines the endpoints, request/response formats, and other API details. API Implementation: This is the actual backend logic that processes the request and returns the response. It interacts with databases, other services, or performs business logic to fulfill the request.

References:

Understanding REST APIs

API Design and Implementation

Insurance organization is planning to deploy Mule application in MuleSoft Hosted runtime plane. As a part of requirement , application should be scalable . highly available. It also has regulatory requirement which demands logs to be retained for at least 2 years. As an Integration Architect what step you will recommend in order to achieve this?


A. It is not possible to store logs for 2 years in CloudHub deployment. External log management system is required.


B. When deploying an application to CloudHub , logs retention period should be selected as 2 years


C. When deploying an application to CloudHub, worker size should be sufficient to store 2 years data


D. Logging strategy should be configured accordingly in log4j file deployed with the application.





A.
  It is not possible to store logs for 2 years in CloudHub deployment. External log management system is required.

Explanation

Correct answer is It is not possible to store logs for 2 years in CloudHub deployment. External log management system is required. CloudHub has a specific log retention policy, as described in the documentation: the platform stores logs of up to 100 MB per app & per worker or for up to 30 days, whichever limit is hit first. Once this limit has been reached, the oldest log information is deleted in chunks and is irretrievably lost. The recommended approach is to persist your logs to a external logging system of your choice (such as Splunk, for instance) using a log appender. Please note that this solution results in the logs no longer being stored on our platform, so any support cases you lodge will require for you to provide the appropriate logs for review and case resolution

A Mule application name Pub uses a persistence object store. The Pub Mule application is deployed to Cloudhub and it configured to use Object Store v2. Another Mule application name sub is being developed to retrieve values from the Pub Mule application persistence object Store and will also be deployed to cloudhub. What is the most direct way for the Sub Mule application to retrieve values from the Pub Mule application persistence object store with the least latency?


A. Use an object store connector configured to access the Pub Mule application persistence object store


B. Use a VM connector configured to directly access the persistence queue of the Pub Mule application persistence object store.


C. Use an Anypoint MQ connector configured to directly access the Pub Mule application persistence object store


D. Use the Object store v2 REST API configured to access the Pub Mule application persistence object store.





D.
  Use the Object store v2 REST API configured to access the Pub Mule application persistence object store.

Explanation

* The Object Store V2 API enables API access to Anypoint Platform Object Store v2.

* You can configure a Mule app to use the Object Store REST API to store and retrieve values from an object store in another Mule app. However, Object Store v2 is not designed for app-to-app communication. To share data between two Mule4 apps, use a queue in Anypoint MQ.

* The Object Store v2 APIs enable you to use REST to perform the following:

- Retrieve a list of object stores and keys associated with an application.

- Store and retrieve key-value pairs in an object store.

- Delete key-value pairs from an object store.

- Retrieve Object Store usage statistics for your organization.

- Object Store provides these APIs:

Object Store API

Object Store Stats API

Reference: [Reference: https://docs.mulesoft.com/object-store/osv2-apis, Additional Info:, When to use Object Store and when to use VM, Diagram Description automatically generated]


Page 10 out of 54 Pages
Previous