Salesforce MuleSoft-Platform-Architect-I Exam Practice Test Instant Access

Question 1

Once an API Implementation is ready and the API is registered on API Manager, who should request the access to the API on Anypoint Exchange?

ANone

BBoth

CAPI Client

DAPI Consumer

Answer : D

Correct Answer : API Consumer

*****************************************

>> API clients are piece of code or programs that use the client credentials of API consumer but does not directly interact with Anypoint Exchange to get the access

>> API consumer is the one who should get registered and request access to API and then API client needs to use those client credentials to hit the APIs

So, API consumer is the one who needs to request access on the API from Anypoint Exchange

Question 2

What Anypoint Connectors support transactions?

ADatabase, JMS, VM

BDatabase, 3MS, HTTP

CDatabase, JMS, VM, SFTP

DDatabase, VM, File

Answer : A

Question 3

An API implementation is updated. When must the RAML definition of the API also be updated?

AWhen the API implementation changes the structure of the request or response messages

BWhen the API implementation changes from interacting with a legacy backend system deployed on-premises to a modern, cloud-based (SaaS) system

CWhen the API implementation is migrated from an older to a newer version of the Mule runtime

DWhen the API implementation is optimized to improve its average response time

Answer : A

Correct Answer : When the API implementation changes the structure of the request or response messages

*****************************************

>> RAML definition usually needs to be touched only when there are changes in the request/response schemas or in any traits on API.

>> It need not be modified for any internal changes in API implementation like performance tuning, backend system migrations etc..

Question 4

What is most likely NOT a characteristic of an integration test for a REST API implementation?

AThe test needs all source and/or target systems configured and accessible

BThe test runs immediately after the Mule application has been compiled and packaged

CThe test is triggered by an external HTTP request

DThe test prepares a known request payload and validates the response payload

Answer : B

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.

Question 5

Refer to the exhibit.

An organization uses one specific CloudHub (AWS) region for all CloudHub deployments.

How are CloudHub workers assigned to availability zones (AZs) when the organization's Mule applications are deployed to CloudHub in that region?

AWorkers belonging to a given environment are assigned to the same AZ within that region

BAZs are selected as part of the Mule application's deployment configuration

CWorkers are randomly distributed across available AZs within that region

DAn AZ is randomly selected for a Mule application, and all the Mule application's CloudHub workers are assigned to that one AZ

Answer : D

Correct Answer :Workers are randomly distributed across available AZs within that region.

*****************************************

>>Currently, we only have control to choose which AWS Region to choose but there is no control at all using any configurations or deployment options to decide what Availability Zone (AZ) to assign to what worker.

>>There areNOfixed or implicit rules on platform too w.r.t assignment of AZ to workers based on environment or application.

>>They are completely assigned inrandom. However, cloudhub definitely ensures that HA is achieved by assigning the workers to more than on AZ so that all workers are not assigned to same AZ for same application.

Bottom of Form

Top of Form

Question 6

When could the API data model of a System API reasonably mimic the data model exposed by the corresponding backend system, with minimal improvements over the backend system's data model?

AWhen there is an existing Enterprise Data Model widely used across the organization

BWhen the System API can be assigned to a bounded context with a corresponding data model

CWhen a pragmatic approach with only limited isolation from the backend system is deemed appropriate

DWhen the corresponding backend system is expected to be replaced in the near future

Answer : C

Correct Answer : When a pragmatic approach with only limited isolation from the

backend system is deemed appropriate.

*****************************************

General guidance w.r.t choosing Data Models:

>> If an Enterprise Data Model is in use then the API data model of System APIs should make use of data types from that Enterprise Data Model and the corresponding API implementation should translate between these data types from the Enterprise Data Model and the native data model of the backend system.

>> If no Enterprise Data Model is in use then each System API should be assigned to a Bounded Context, the API data model of System APIs should make use of data types from the corresponding Bounded Context Data Model and the corresponding API implementation should translate between these data types from the Bounded Context Data Model and the native data model of the backend system. In this scenario, the data types in the Bounded Context Data Model are defined purely in terms of their business characteristics and are typically not related to the native data model of the backend system. In other words, the translation effort may be significant.

>> If no Enterprise Data Model is in use, and the definition of a clean Bounded Context Data Model is considered too much effort, then the API data model of System APIs should make use of data types that approximately mirror those from the backend system, same semantics and naming as backend system, lightly sanitized, expose all fields needed for the given System API's functionality, but not significantly more and making good use of REST conventions.

The latter approach, i.e., exposing in System APIs an API data model that basically mirrors that of the backend system, does not provide satisfactory isolation from backend systems through the System API tier on its own. In particular, it will typically not be possible to 'swap out' a backend system without significantly changing all System APIs in front of that backend system and therefore the API implementations of all Process APIs that depend on those System APIs! This is so because it is not desirable to prolong the life of a previous backend system's data model in the form of the API data model of System APIs that now front a new backend system. The API data models of System APIs following this approach must therefore change when the backend system is replaced.

On the other hand:

>> It is a very pragmatic approach that adds comparatively little overhead over accessing the backend system directly

>> Isolates API clients from intricacies of the backend system outside the data model (protocol, authentication, connection pooling, network address, ...)

>> Allows the usual API policies to be applied to System APIs

>> Makes the API data model for interacting with the backend system explicit and visible, by exposing it in the RAML definitions of the System APIs

>> Further isolation from the backend system data model does occur in the API implementations of the Process API tier

Question 7

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?

AImplement (or generate) an API proxy Mule application for each of the APIs, then deploy the API proxies to the Mule runtimes

BRedeploy the API implementations to the same servers running the Mule runtimes

CAdd an additional endpoint to each API for partner-enablement consumption

DDuplicate the APIs as Mule applications, then deploy them to the Mule runtimes

Answer : A

Salesforce Certified MuleSoft Platform Architect I Exam Practice Test