Free Preparation Discussions
MENU
Salesforce Certified MuleSoft Platform Architect I Exam Questions
- Salesforce Architect Certifications
- Salesforce MuleSoft Platform Architect I Certifications
- Topic 1: Explaining Application Network Basics: This topic includes sub-topics related to identifying and differentiating between technologies for API-led connectivity, describing the role and characteristics of web APIs, assigning APIs to tiers, and understanding Anypoint Platform components.
- Topic 2: Establishing Organizational and Platform Foundations: Advising on a Center for Enablement (C4E) and identifying KPIs, describing MuleSoft Catalyst's structure, comparing Identity and Client Management options, and identifying data residency types are essential sub-topics.
- Topic 3: Designing and Sharing APIs: Identifying dependencies between API components, creating and publishing reusable API assets, mapping API data models between Bounded Contexts, and recognizing idempotent HTTP methods.
- Topic 4: Designing APIs Using System, Process, and Experience Layers: Identifying suitable APIs for business processes, assigning them according to functional focus, and recommending data model approaches are its sub-topics.
- Topic 5: Governing Web APIs on Anypoint Platform: This topic includes sub-topics related to managing API instances and environments, selecting API policies, enforcing API policies, securing APIs, and understanding OAuth 2.0 relationships.
- Topic 6: Architecting and Deploying API Implementations: It covers important aspects like using auto-discovery, identifying VPC requirements, comparing hosting options and understanding testing methods. The topic also involves automated building, testing, and deploying in a DevOps setting.
- Topic 7: Deploying API Implementations to CloudHub: Understanding Object Store usage, selecting worker sizes, predicting app reliability and performance, and comparing load balancers. Avoiding single points of failure in deployments is also its sub-topic. Meeting API Quality Goals: This topic focuses on designing resilience strategies, selecting appropriate caching and OS usage scenarios, and describing horizontal scaling benefits.
- Topic 8: Monitoring and Analyzing Application Networks: It discusses Anypoint Platform components for data generation, collected metrics, and key alerts. This topic also includes specifying alerts to define Mule applications.
Free Salesforce Salesforce Certified MuleSoft Platform Architect I Exam Actual Questions
Note: Premium Questions for Salesforce Certified MuleSoft Platform Architect I were last updated On Oct. 04, 2024 (see below)
A retail company is using an Order API to accept new orders. The Order API uses a JMS queue to submit orders to a backend order management service. The normal load for orders is being handled using two (2) CloudHub workers, each configured with 0.2 vCore. The CPU load of each CloudHub worker normally runs well below 70%. However, several times during the year the Order API gets four times (4x) the average number of orders. This causes the CloudHub worker CPU load to exceed 90% and the order submission time to exceed 30 seconds. The cause, however, is NOT the backend order management service, which still responds fast enough to meet the response SLA for the Order API. What is the MOST resource-efficient way to configure the Mule application's CloudHub deployment to help the company cope with this performance challenge?
Correct Answer : Use a horizontal CloudHub autoscaling policy that triggers on CPU utilization greater than 70%
*****************************************
The scenario in the question is very clearly stating that the usual traffic in the year is pretty well handled by the existing worker configuration with CPU running well below 70%. The problem occurs only 'sometimes' occasionally when there is spike in the number of orders coming in.
So, based on above, We neither need to permanently increase the size of each worker nor need to permanently increase the number of workers. This is unnecessary as other than those 'occasional' times the resources are idle and wasted.
We have two options left now. Either to use horizontal Cloudhub autoscaling policy to automatically increase the number of workers or to use vertical Cloudhub autoscaling policy to automatically increase the vCore size of each worker.
Here, we need to take two things into consideration:
1. CPU
2. Order Submission Rate to JMS Queue
>> From CPU perspective, both the options (horizontal and vertical scaling) solves the issue. Both helps to bring down the usage below 90%.
>> However, If we go with Vertical Scaling, then from Order Submission Rate perspective, as the application is still being load balanced with two workers only, there may not be much improvement in the incoming request processing rate and order submission rate to JMS queue. The throughput would be same as before. Only CPU utilization comes down.
>> But, if we go with Horizontal Scaling, it will spawn new workers and adds extra hand to increase the throughput as more workers are being load balanced now. This way we can address both CPU and Order Submission rate.
Hence, Horizontal CloudHub Autoscaling policy is the right and best answer.
A company has started to create an application network and is now planning to implement a Center for Enablement (C4E) organizational model. What key factor would lead the company to decide upon a federated rather than a centralized C4E?
Correct Answer : When development is already organized into several independent initiatives or groups
*****************************************
>> It would require lot of process effort in an organization to have a single C4E team coordinating with multiple already organized development teams which are into several independent initiatives. A single C4E works well with different teams having at least a common initiative. So, in this scenario, federated C4E works well instead of centralized C4E.
An organization wants MuleSoft-hosted runtime plane features (such as HTTP load balancing, zero downtime, and horizontal and vertical scaling) in its Azure environment. What runtime plane minimizes the organization's effort to achieve these features?
Correct Answer : Anypoint Runtime Fabric
*****************************************
>> When a customer is already having an Azure environment, It is not at all an ideal approach to go with hybrid model having some Mule Runtimes hosted on Azure and some on MuleSoft. This is unnecessary and useless.
>> CloudHub is a Mulesoft-hosted Runtime plane and is on AWS. We cannot customize to point CloudHub to customer's Azure environment.
>> Anypoint Platform for Pivotal Cloud Foundry is specifically for infrastructure provided by Pivotal Cloud Foundry
>> Anypoint Runtime Fabric is right answer as it is a container service that automates the deployment and orchestration of Mule applications and API gateways. Runtime Fabric runs within a customer-managed infrastructure on AWS, Azure, virtual machines (VMs), and bare-metal servers.
-Some of the capabilities of Anypoint Runtime Fabric include:
-Isolation between applications by running a separate Mule runtime per application.
-Ability to run multiple versions of Mule runtime on the same set of resources.
-Scaling applications across multiple replicas.
-Automated application fail-over.
-Application management with Anypoint Runtime Manager.
Say, there is a legacy CRM system called CRM-Z which is offering below functions:
1. Customer creation
2. Amend details of an existing customer
3. Retrieve details of a customer
4. Suspend a customer
Correct Answer : Implement different system APIs named createCustomer, amendCustomer, retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns
*****************************************
>> It is quite normal to have a single API and different Verb + Resource combinations. However, this fits well for an Experience API or a Process API but not a best architecture style for System APIs. So, option with just one customerManagement API is not the best choice here.
>> The option with APIs in createCustomerInCRMZ format is next close choice w.r.t modularization and less maintenance but the naming of APIs is directly coupled with the legacy system. A better foreseen approach would be to name your APIs by abstracting the backend system names as it allows seamless replacement/migration of any backend system anytime. So, this is not the correct choice too.
>> createCustomer, amendCustomer, retrieveCustomer and suspendCustomer is the right approach and is the best fit compared to other options as they are both modular and same time got the names decoupled from backend system and it has covered all requirements a System API needs.
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?
Correct Answer : A Non-Mule application
*****************************************
>> All type of Mule applications (Mule 3/ Mule 4/ with APIkit/ with Custom Java Code etc) running on Mule Runtimes support the Embedded Policy Enforcement on them.
>> The only option that cannot have or does not support embedded policy enforcement and must have API Proxy is for Non-Mule Applications.
So, Non-Mule application is the right answer.
- Select Question Types you want
- Set your Desired Pass Percentage
- Allocate Time (Hours : Minutes)
- Create Multiple Practice tests with Limited Questions
- Customer Support
Therese
3 days agoBoris
4 days agoRolland
13 days agoBeckie
18 days agoLai
19 days agoWenona
1 months agoIlene
1 months agoSophia
1 months agoCarry
3 months agoRoxanne
3 months agoSylvia
4 months agoMattie
4 months agoJacinta
4 months agoAntonio
4 months agoIlene
5 months ago