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 end-to-end request processing of the API implementation?

When the response time of API invocations exceeds a threshold

When the API is invoked by an unrecognized API client

When a particular API client invokes the API too often within a given time period

When the response time of API invocations exceeds a threshold

When the API receives a very high number of API invocations

What is the main change to the IT operating model that MuleSoft recommends to organizations to improve innovation and clock speed?

Drive consumption as much as production of assets; this enables developers to discover and reuse assets from other projects and encourages standardization

Expose assets using a Master Data Management (MDM) system; this standardizes projects and enables developers to quickly discover and reuse assets from other projects

Implement SOA for reusable APIs to focus on production over consumption; this standardizes on XML and WSDL formats to speed up decision making

Create a lean and agile organization that makes many small decisions everyday; this speeds up decision making and enables each line of business to take ownership of its projects

A system API is deployed to a primary environment as well as to a disaster recovery (DR) environment, with different DNS names in each environment. A process API is a client to the system API and is being rate limited by the system API, with different limits in each of the environments. The system API's DR environment provides only 20% of the rate limiting offered by the primary environment. What is the best API fault-tolerant invocation strategy to reduce overall errors in the process API, given these conditions and constraints?

Invoke the system API deployed to the primary environment; add timeout and retry logic to the process API to avoid intermittent failures; if it still fails, invoke the system API deployed to the DR environment

Invoke the system API deployed to the primary environment; add retry logic to the process API to handle intermittent failures by invoking the system API deployed to the DR environment

In parallel, invoke the system API deployed to the primary environment and the system API deployed to the DR environment; add timeout and retry logic to the process API to avoid intermittent failures; add logic to the process API to combine the results

Invoke the system API deployed to the primary environment; add timeout and retry logic to the process API to avoid intermittent failures; if it still fails, invoke a copy of the process API deployed to the DR environment

A company uses a hybrid Anypoint Platform deployment model that combines the EU control plane with customer-hosted Mule runtimes. After successfully testing a Mule API implementation in the Staging environment, the Mule API implementation is set with environment-specific properties and must be promoted to the Production environment. What is a way that MuleSoft recommends to configure the Mule API implementation and automate its promotion to the Production environment?

Bundle properties files for each environment into the Mule API implementation's deployable archive, then promote the Mule API implementation to the Production environment using Anypoint CLI or the Anypoint Platform REST APIsB.

Modify the Mule API implementation's properties in the API Manager Properties tab, then promote the Mule API implementation to the Production environment using API Manager

Modify the Mule API implementation's properties in Anypoint Exchange, then promote the Mule API implementation to the Production environment using Runtime Manager

Use an API policy to change properties in the Mule API implementation deployed to the Staging environment and another API policy to deploy the Mule API implementation to the Production environment

An organization wants to make sure only known partners can invoke the organization's APIs. To achieve this security goal, the organization wants to enforce a Client ID Enforcement policy in API Manager so that only registered partner applications can invoke the organization's APIs. In what type of API implementation does MuleSoft recommend adding an API proxy to enforce the Client ID Enforcement policy, rather than embedding the policy directly in the application's JVM?

A Mule 3 application using APIkit

A Mule 3 or Mule 4 application modified with custom Java code

A Mule 4 application with an API specification

A company wants to move its Mule API implementations into production as quickly as possible. To protect access to all Mule application data and metadata, the company requires that all Mule applications be deployed to the company's customer-hosted infrastructure within the corporate firewall. What combination of runtime plane and control plane options meets these project lifecycle goals?

Manually provisioned customer-hosted runtime plane and customer-hosted control plane

MuleSoft-hosted runtime plane and customer-hosted control plane

Manually provisioned customer-hosted runtime plane and MuleSoft-hosted control plane

iPaaS provisioned customer-hosted runtime plane and MuleSoft-hosted control plane

Which of the below, when used together, makes the IT Operational Model effective?

Create resuable assets, make them discoverable so that LOB teams can self-serve and browse the APIs

Create reusable assets, Do marketing on the created assets across organization, Arrange time to time LOB reviews to ensure assets are being consumed or not

Create reusable assets, Make them discoverable so that LOB teams can self-serve and browse the APIs, Get active feedback and usage metrics

Create resuable assets, make them discoverable so that LOB teams can self-serve and browse the APIs

Which of the following sequence is correct?

API Consumer requests access to API >> API Client implementes logic to call an API >> API routes the request to >> API Implementation

API Client implementes logic to call an API >> API Consumer requests access to API >> API Implementation routes the request to >> API

API Consumer requests access to API >> API Client implementes logic to call an API >> API routes the request to >> API Implementation

API Consumer implementes logic to call an API >> API Client requests access to API >> API Implementation routes the request to >> API

API Client implementes logic to call an API >> API Consumer requests access to API >> API routes the request to >> API Implementation

An organization has created an API-led architecture that uses various API layers to integrate mobile clients with a backend system. The backend system consists of a number of specialized components and can be accessed via a REST API. The process and experience APIs share the same bounded-context model that is different from the backend data model. What additional canonical models, bounded-context models, or anti-corruption layers are best added to this architecture to help process data consumed from the backend system?

Create a bounded-context model for the system layer to closely match the backend data model, and add an anti-corruption layer to let the different bounded contexts cooperate across the system and process layers

Create a bounded-context model for every layer and overlap them when the boundary contexts overlap, letting API developers know about the differences between upstream and downstream data models

Create a canonical model that combines the backend and API-led models to simplify and unify data models, and minimize data transformations.

Create a bounded-context model for the system layer to closely match the backend data model, and add an anti-corruption layer to let the different bounded contexts cooperate across the system and process layers

Create an anti-corruption layer for every API to perform transformation for every data model to match each other, and let data simply travel between APIs to avoid the complexity and overhead of building canonical models

An API client calls one method from an existing API implementation. The API implementation is later updated. What change to the API implementation would require the API client's invocation logic to also be updated?

When a new required field is added to the method called by the API client

When the data type of the response is changed for the method called by the API client

When a new method is added to the resource used by the API client

When a new required field is added to the method called by the API client

When a child method is added to the method called by the API client

Traffic is routed through an API proxy to an API implementation. The API proxy is managed by API Manager and the API implementation is deployed to a CloudHub VPC using Runtime Manager. API policies have been applied to this API. In this deployment scenario, at what point are the API policies enforced on incoming API client requests?

At both the API proxy and the API implementation

At a MuleSoft-hosted load balancer

What is a key requirement when using an external Identity Provider for Client Management in Anypoint Platform?

To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider

Single sign-on is required to sign in to Anypoint Platform

The application network must include System APIs that interact with the Identity Provider

To invoke OAuth 2.0-protected APIs managed by Anypoint Platform, API clients must submit access tokens issued by that same Identity Provider

APIs managed by Anypoint Platform must be protected by SAML 2.0 policies

How can the application of a rate limiting API policy be accurately reflected in the RAML definition of an API?

By refining the response definitions by adding the x-ratelimit-* response headers with description, type, and example

By refining the resource definitions by adding a description of the rate limiting policy behavior

By refining the request definitions by adding a remaining Requests query parameter with description, type, and example

By refining the response definitions by adding the out-of-the-box Anypoint Platform rate-limit-enforcement securityScheme with description, type, and example

By refining the response definitions by adding the x-ratelimit-* response headers with description, type, and example

An organization has several APIs that accept JSON data over HTTP POST. The APIs are all publicly available and are associated with several mobile applications and web applications.The organization does NOT want to use any authentication or compliance policies for these APIs, but at the same time, is worried that some bad actor could send payloads that could somehow compromise the applications or servers running the API implementations.What out-of-the-box Anypoint Platform policy can address exposure to this threat?

Apply a JSON threat protection policy to all APIs to detect potential threat vectors

Shut out bad actors by using HTTPS mutual authentication for all API invocations

Apply an IP blacklist policy to all APIs; the blacklist will Include all bad actors

Apply a Header injection and removal policy that detects the malicious data before it is used

Apply a JSON threat protection policy to all APIs to detect potential threat vectors

What is a key performance indicator (KPI) that measures the success of a typical C4E that is immediately apparent in responses from the Anypoint Platform APIs?

The number of API specifications in RAML or OAS format published to Anypoint Exchange

The number of production outage incidents reported in the last 24 hours

The number of API implementations that have a publicly accessible HTTP endpoint and are being managed by Anypoint Platform

The fraction of API implementations deployed manually relative to those deployed using a CI/CD tool

The number of API specifications in RAML or OAS format published to Anypoint Exchange

An organization is implementing a Quote of the Day API that caches today's quote.What scenario can use the GoudHub Object Store via the Object Store connector to persist the cache's state?

When there is one CloudHub deployment of the API implementation to three CloudHub workers that must share the cache state

When there are three CloudHub deployments of the API implementation to three separate CloudHub regions that must share the cache state

When there are two CloudHub deployments of the API implementation by two Anypoint Platform business groups to the same CloudHub region that must share the cache state

When there is one deployment of the API implementation to CloudHub and anottV deployment to a customer-hosted Mule runtime that must share the cache state

When there is one CloudHub deployment of the API implementation to three CloudHub workers that must share the cache state

What condition requires using a CloudHub Dedicated Load Balancer?

When server-side load-balanced TLS mutual authentication is required between API implementations and API clients

When cross-region load balancing is required between separate deployments of the same Mule application

When custom DNS names are required for API implementations deployed to customer-hosted Mule runtimes

When API invocations across multiple CloudHub workers must be load balanced

When server-side load-balanced TLS mutual authentication is required between API implementations and API clients

What do the API invocation metrics provided by Anypoint Platform provide?

Data on past API invocations to help identify anomalies and usage patterns across various APIs

ROI metrics from APIs that can be directly shared with business users

Measurements of the effectiveness of the application network based on the level of reuse

Data on past API invocations to help identify anomalies and usage patterns across various APIs

Proactive identification of likely future policy violations that exceed a given threat threshold

What is true about the technology architecture of Anypoint VPCs?

Traffic between Mule applications deployed to an Anypoint VPC and on-premises systems can stay within a private network

The private IP address range of an Anypoint VPC is automatically chosen by CloudHub

Traffic between Mule applications deployed to an Anypoint VPC and on-premises systems can stay within a private network

Each CloudHub environment requires a separate Anypoint VPC

VPC peering can be used to link the underlying AWS VPC to an on-premises (non AWS) private network

An API implementation is deployed on a single worker on CloudHub and invoked by external API clients (outside of CloudHub). How can an alert be set up that is guaranteed to trigger AS SOON AS that API implementation stops responding to API invocations?

Configure a 'worker not responding' alert in Anypoint Runtime Manager

Implement a heartbeat/health check within the API and invoke it from outside the Anypoint Platform and alert when the heartbeat does not respond

Configure a 'worker not responding' alert in Anypoint Runtime Manager

Handle API invocation exceptions within the calling API client and raise an alert from that API client when the API Is unavailable

Create an alert for when the API receives no requests within a specified time period

Refer to the exhibit. what is true when using customer-hosted Mule runtimes with the MuleSoft-hosted Anypoint Platform control plane (hybrid deployment)?

API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane

Anypoint Runtime Manager initiates a network connection to a Mule runtime in order to deploy Mule applications

The MuleSoft-hosted Shared Load Balancer can be used to load balance API invocations to the Mule runtimes

API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane

Anypoint Runtime Manager automatically ensures HA in the control plane by creating a new Mule runtime instance in case of a node failure

What best describes the Fully Qualified Domain Names (FQDNs), also known as DNS entries, created when a Mule application is deployed to the CloudHub Shared Worker Cloud?

The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region

A fixed number of FQDNs are created, IRRESPECTIVE of the environment and VPC design

The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region

The FQDNs are determined by the application name, but can be modified by an administrator after deployment

The FQDNs are determined by both the application name and the Anypoint Platform organization

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

The SSL certificates used by the API implementation to expose HTTPS endpoints

The assignment of each HTTP request to a particular CloudHub worker

The logging configuration that enables log entries to be visible in Runtime Manager

The SSL certificates used by the API implementation to expose HTTPS endpoints

The number of DNS entries allocated to the API implementation

An API experiences a high rate of client requests (TPS) vwth small message paytoads. How can usage limits be imposed on the API based on the type of client application?

Use an SLA-based rate limiting policy and assign a client application to a matching SLA tier based on its type

Use a spike control policy that limits the number of requests for each client application type

Use a cross-origin resource sharing (CORS) policy to limit resource sharing between client applications, configured by the client application type

Use a rate limiting policy and a client ID enforcement policy, each configured by the client application type

A code-centric API documentation environment should allow API consumers to investigate and execute API client source code that demonstrates invoking one or more APIs as part of representative scenarios.What is the most effective way to provide this type of code-centric API documentation environment using Anypoint Platform?

Create API Notebooks and include them in the relevant Anypoint Exchange entries

Enable mocking services for each of the relevant APIs and expose them via their Anypoint Exchange entry

Ensure the APIs are well documented through their Anypoint Exchange entries and API Consoles and share these pages with all API consumers

Create API Notebooks and include them in the relevant Anypoint Exchange entries

Make relevant APIs discoverable via an Anypoint Exchange entry

Refer to the exhibit. An organization is running a Mule standalone runtime and has configured Active Directory as the Anypoint Platform external Identity Provider. The organization does not have budget for other system components. What policy should be applied to all instances of APIs in the organization to most effecuvelyKestrict access to a specific group of internal users?

Apply a basic authentication - LDAP policy; the internal Active Directory will be configured as the LDAP source for authenticating users

Apply a client ID enforcement policy; the specific group of users will configure their client applications to use their specific client credentials

Apply an IP whitelist policy; only the specific users' workstations will be in the whitelist

Apply an OAuth 2.0 access token enforcement policy; the internal Active Directory will be configured as the OAuth server

What is a best practice when building System APIs?

Model all API resources and methods to closely mimic the operations of the backend system

Document the API using an easily consumable asset like a RAML definition

Model all API resources and methods to closely mimic the operations of the backend system

Build an Enterprise Data Model (Canonical Data Model) for each backend system and apply it to System APIs

Expose to API clients all technical details of the API implementation's interaction wifch the backend system

Salesforce Certified MuleSoft Developer I Practice Test 1

Question 1 / 40

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

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

The API policy Is defined In API Manager for a specific API Instance, and then ONLY applied to the specific API instance

The API policy Is defined in API Manager and then automatically applied to ALL API instances

The API policy is defined in API Manager, and then applied to ALL API instances in the specified environment

Comment (0)

Salesforce Certified MuleSoft Developer I Practice Test 1

Question

Salesforce Certified MuleSoft Developer I Practice Tests

Practice Tests