What aspects of a CI/CD pipeline for Mute applications can be automated using MuleSoft-provided Maven plugins?

• A.Compile, package, unit test, validate unit test coverage, deploy
• B.Compile, package, unit test, deploy, integration test
• C.Compile, package, unit test, deploy, create associated API instances in API Manager B Import from API designer, compile, package, unit test, deploy, publish to Am/point Exchange

Comment: *

Name: *

Email: *

Verification: *

An organization is designing a Mule application to periodically poll an SFTP location for new files containing sales order records and then process those sales orders. Each sales order must be processed exactly once.
To support this requirement, the Mule application must identify and filter duplicate sales orders on the basis of a unique ID contained in each sales order record and then only send the new sales orders to the downstream system.
What is the most idiomatic (used for its intended purpose) Anypoint connector, validator, or scope that can be configured in the Mule application to filter duplicate sales orders on the basis of the unique ID field contained in each sales order record?

• A.Configure a Cache scope to filter and store each record from the received file by the order ID
• B.Configure a Database connector to filter and store each record by the order ID
• C.Configure an Idempotent Message Validator component to filter each record by the order ID
• D.Configure a watermark In an On New or Updated File event source to filter unique records by the order ID

Comment: *

Name: *

Email: *

Verification: *

A company is using Mulesoft to develop API's and deploy them to Cloudhub and on premises targets.
Recently it has decided to enable Runtime Fabric deployment option as well and infrastructure is set up for this option.
What can be used to deploy Runtime Fabric?

• A.AnypointCLI
• B.Anypoint platform REST API's
• C.Directly uploading ajar file from the Runtime manager
• D.Mule maven plug-in

Comment: *

Name: *

Email: *

Verification: *

An organization is migrating all its Mule applications to Runtime Fabric (RTF). None of the Mule applications use Mule domain projects.
Currently, all the Mule applications have been manually deployed to a server group among several customer hosted Mule runtimes.
Port conflicts between these Mule application deployments are currently managed by the DevOps team who carefully manage Mule application properties files.
When the Mule applications are migrated from the current customer-hosted server group to Runtime Fabric (RTF), fo the Mule applications need to be rewritten and what DevOps port configuration responsibilities change or stay the same?

• A.Yes, the Mule applications Must be rewritten
  DevOps No Longer needs to manage port conflicts between the Mule applications
• B.Yes, the Mule applications Must be rewritten
  DevOps Must Still Manage port conflicts.
• C.NO, The Mule applications do NOT need to be rewritten
  DevOps MUST STILL manage port conflicts
• D.NO, the Mule applications do NO need to be rewritten
  DevOps NO LONGER needs to manage port conflicts between the Mule applications.

Comment: *

Name: *

Email: *

Verification: *

An organization needs to enable access to their customer data from both a mobile app and a web application, which each need access to common fields as well as certain unique fields. The data is available partially in a database and partially in a 3rd-party CRM system. What APIs should be created to best fit these design requirements?

• A.A Process API that contains the data required by both the web and mobile apps, allowing these applications to invoke it directly and access the data they need thereby providing the flexibility to add more fields in the future without needing API changes.
• B.One set of APIs (Experience API, Process API, and System API) for the web app, and another set for the mobile app.
• C.Separate Experience APIs for the mobile and web app, but a common Process API that invokes separate System APIs created for the database and CRM system
• D.A common Experience API used by both the web and mobile apps, but separate Process APIs for the web and mobile apps that interact with the database and the CRM System.

Correct Answer: C

Lets analyze the situation in regards to the different options available Option : A common Experience API but separate Process APIs Analysis : This solution will not work because having common experience layer will not help the purpose as mobile and web applications will have different set of requirements which cannot be fulfilled by single experience layer API Option : Common Process API Analysis : This solution will not work because creating a common process API will impose limitations in terms of flexibility to customize API;s as per the requirements of different applications. It is not a recommended approach.
Option : Separate set of API's for both the applications Analysis : This goes against the principle of Anypoint API-led connectivity approach which promotes creating reusable assets. This solution may work but this is not efficient solution and creates duplicity of code.
Hence the correct answer is: Separate Experience APIs for the mobile and web app, but a common Process API that invokes separate System APIs created for the database and CRM system A screenshot of a computer Description automatically generated with low confidence

Lets analyze the situation in regards to the different options available Option : A common Experience API but separate Process APIs Analysis : This solution will not work because having common experience layer will not help the purpose as mobile and web applications will have different set of requirements which cannot be fulfilled by single experience layer API Option : Common Process API Analysis : This solution will not work because creating a common process API will impose limitations in terms of flexibility to customize API;s as per the requirements of different applications. It is not a recommended approach.
Option : Separate set of API's for both the applications Analysis : This goes against the principle of Anypoint API-led connectivity approach which promotes creating reusable assets. This solution may work but this is not efficient solution and creates duplicity of code.
Hence the correct answer is: Separate Experience APIs for the mobile and web app, but a common Process API that invokes separate System APIs created for the database and CRM system Diagram Description automatically generated

Comment: *

Name: *

Email: *

Verification: *