Salesforce MULESOFT-PLATFORM-ARCHITECT-I Online Practice Questions and Exam Preparation

Salesforce MULESOFT-PLATFORM-ARCHITECT-I Online Questions & Answers

• Question 31:

  What is true about where an API policy is defined in Anypoint Platform and how it is then applied to API instances?

  A. The API policy Is defined In Runtime Manager as part of the API deployment to a Mule runtime, and then ONLY applied to the specific API Instance
  B. The API policy Is defined In API Manager for a specific API Instance, and then ONLY applied to the specific API instance
  C. The API policy Is defined in API Manager and then automatically applied to ALL API instances
  D. The API policy is defined in API Manager, and then applied to ALL API instances in the specified environment
  B. The API policy Is defined In API Manager for a specific API Instance, and then ONLY applied to the specific API instance

  ---

  Explanation

  Once our API specifications are ready and published to Exchange, we need to visit API Manager and register an API instance for each API.

  API Manager is the place where management of API aspects takes place like addressing NFRs by enforcing policies on them.

  We can create multiple instances for a same API and manage them differently for different purposes.

  One instance can have a set of API policies applied and another instance of same API can have different set of policies applied for some other purpose.

  These APIs and their instances are defined PER environment basis. So, one need to manage them seperately in each environment.

  We can ensure that same configuration of API instances (SLAs, Policies etc..) gets promoted when promoting to higher environments using platform feature. But this is optional only. Still one can change them per environment basis if they

  have to.

  Runtime Manager is the place to manage API Implementations and their Mule Runtimes but NOT APIs itself. Though API policies gets executed in Mule Runtimes, We CANNOT enforce API policies in Runtime Manager. We would need to do

  that via API Manager only for a cherry picked instance in an environment.

  So, based on these facts, right statement in the given choices is - "The API policy is defined in API Manager for a specific API instance, and then ONLY applied to the specific API instance".

• Question 32:

  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
  B. A higher number of discoverable API-related assets in the application network

  ---

  Explanation

  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 fine-grained 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.

• Question 33:

  An API implementation is deployed to CloudHub.

  What conditions can be alerted on using the default Anypoint Platform functionality, where the alert conditions depend on the API invocations to an API implementation?

  A. When the API invocations are sent directly to the internal DNS record of the API implementation
  B. When the API invocations are not over-a- secure TLS/SSL communication channel
  C. When the APL invecations originate from a geography different than the API
  D. When the number of API invocations are below a threshold
  D. When the number of API invocations are below a threshold

  ---

  Explanation

• Question 34:

  A developer from the Central IT team has created an initial version of the RAML definition in Design Center for an OAuth 2. 0-protected System API and published it to Exchange. Another developer from LoB IT discovered the System API in Exchange and would like to leverage it in the Process API.

  What is the MuleSoft-recommended approach for Process API to invoke the System API?

  A. The Process API needs to import an CAuth 2. 0 module from Exchange first and update it with OAuth 2. 0 credentials before the System API can be invoked
  B. The Process API uses property YAML files to store the System API URLs and uses the HTTP Request Connector to invoke the Systerm API
  C. The Process APL uses the REST Connect Connector autogenerated in Exchange for the System API
  D. The Process API manually updates the Process API POM file to include the System API as a dependency
  C. The Process APL uses the REST Connect Connector autogenerated in Exchange for the System API

  ---

  Explanation

• Question 35:

  An Order API triggers a sequence of other API calls to look up details of an order's items in a back-end inventory database. The Order API calls the OrderItems process API, which calls the Inventory system API. The Inventory system API performs database operations in the back-end inventory database.

  The network connection between the Inventory system API and the database is known to be unreliable and hang at unpredictable times. Where should a two-second timeout be configured in the API processing sequence so that the Order API never waits more than two seconds for a response from the Orderltems process API?

  

  A. In the Orderltems process API implementation
  B. In the Order API implementation
  C. In the Inventory system API implementation
  D. In the inventory database
  A. In the Orderltems process API implementation

  ---

  Explanation

• Question 36:

  When using CloudHub with the Shared Load Balancer, what is managed EXCLUSIVELY by the API implementation (the Mule application) and NOT by Anypoint Platform?

  A. The assignment of each HTTP request to a particular CloudHub worker
  B. The logging configuration that enables log entries to be visible in Runtime Manager
  C. The SSL certificates used by the API implementation to expose HTTPS endpoints
  D. The number of DNS entries allocated to the API implementation
  C. The SSL certificates used by the API implementation to expose HTTPS endpoints

  ---

  Explanation

  The assignment of each HTTP request to a particular CloudHub worker is taken care by Anypoint Platform itself. We need not manage it explicitly in the API implementation and in fact we CANNOT manage it in the API implementation.

  The logging configuration that enables log entries to be visible in Runtime Manager is ALWAYS managed in the API implementation and NOT just for SLB. So this is not something we do EXCLUSIVELY when using SLB.

  We DO NOT manage the number of DNS entries allocated to the API implementation inside the code.

  Anypoint Platform takes care of this.

  It is the SSL certificates used by the API implementation to expose HTTPS endpoints that is to be managed EXCLUSIVELY by the API implementation. Anypoint Platform does NOT do this when using SLBs.

• Question 37:

  What is a best practice when building System APIs?

  A. Document the API using an easily consumable asset like a RAML definition
  B. Model all API resources and methods to closely mimic the operations of the backend system
  C. Build an Enterprise Data Model (Canonical Data Model) for each backend system and apply it to System APIs
  D. Expose to API clients all technical details of the API implementation's interaction wifch the backend system
  B. Model all API resources and methods to closely mimic the operations of the backend system

  ---

  Explanation

• Question 38:

  An established communications company is beginning its API-led connectivity journey, The company has been using a successful Enterprise Data Model for many years.

  The company has identified a self-service account management app as the first effort for API- led, and it has identified the following APIs:

  1. Experience layer: Mobile Account Management EAPI, Browser Account Management EAPI

  2. Process layer: Customer Lookup PAPI, Service Lookup PAPI, Account Lookup PAPI

  3. System layer: Customer SAPI, Account SAPI, Product SAPI, Service SAPI

  According to MuleSoft's API-led connectivity approach, which API would not be served by the Enterprise Data Model?

  A. Customer SAPI
  B. Customer Lookup PAPI
  C. Mobile Account Management EAPI
  D. Service SAPI
  C. Mobile Account Management EAPI

  ---

  Explanation

• Question 39:

  A new upstream API Is being designed to offer an SLA of 500 ms median and 800 ms maximum (99th percentile) response time. The corresponding API implementation needs to sequentially invoke 3 downstream APIs of very similar

  complexity.

  The first of these downstream APIs offers the following SLA for its response time: median: 100 ms, 80th percentile: 500 ms, 95th percentile: 1000 ms.

  If possible, how can a timeout be set in the upstream API for the invocation of the first downstream API to meet the new upstream API's desired SLA?

  A. Set a timeout of 50 ms; this times out more invocations of that API but gives additional room for retries
  B. Set a timeout of 100 ms; that leaves 400 ms for the other two downstream APIs to complete
  C. No timeout is possible to meet the upstream API's desired SLA; a different SLA must be negotiated with the first downstream API or invoke an alternative API
  D. Do not set a timeout; the Invocation of this API Is mandatory and so we must wait until it responds
  B. Set a timeout of 100 ms; that leaves 400 ms for the other two downstream APIs to complete

  ---

  Explanation

  Key details to take from the given scenario:

  Upstream API's designed SLA is 500ms (median). Lets ignore maximum SLA response times.

  This API calls 3 downstream APIs sequentially and all these are of similar complexity.

  The first downstream API is offering median SLA of 100ms, 80th percentile: 500ms; 95th percentile:

  1000ms.

  Based on the above details:

  We can rule out the option which is suggesting to set 50ms timeout. Because, if the median SLA itself being offered is 100ms then most of the calls are going to timeout and time gets wasted in retried them and eventually gets exhausted with

  all retries. Even if some retries gets successful, the remaining time wont leave enough room for 2nd and 3rd downstream APIs to respond within time.

  The option suggesting to NOT set a timeout as the invocation of this API is mandatory and so we must wait until it responds is silly. As not setting time out would go against the good implementation pattern and moreover if the first API is not

  responding within its offered median SLA 100ms then most probably it would either respond in 500ms (80th percentile) or 1000ms (95th percentile). In BOTH cases, getting a successful response from 1st downstream API does NO GOOD

  because already by this time the Upstream API SLA of 500 ms is breached. There is no time left to call 2nd and 3rd downstream APIs.

  It is NOT true that no timeout is possible to meet the upstream APIs desired SLA.

  As 1st downstream API is offering its median SLA of 100ms, it means MOST of the time we would get the responses within that time. So, setting a timeout of 100ms would be ideal for MOST calls as it leaves enough room of 400ms for

  remaining 2 downstream API calls.

• Question 40:

  What Mule application can have API policies applied by

  Anypoint Platform to the endpoint exposed by that Mule application?

  

  A. Option A
  B. Option B
  C. Option C
  D. Option D
  A. Option A

  ---

  Explanation

  Anypoint API Manager and API policies are applicable to all types of HTTP/1.x APIs. They are not applicable to WebSocket APIs, HTTP/2 APIs and gRPC APIs