Cert++
  1. Home
  3. MuleSoft Platform Architect

MuleSoft Platform Architect

Checklist progressProgress

0/228Learned

MuleSoft Platform Architect Study Checklist
  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Marketing Cloud Account Engagement Specialist
  • Marketing Cloud Next Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Communications AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • Public Sector Solutions AP
  • Revenue Cloud Consultant
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Next Consultant
  • Tableau Architect
  • Slack Administrator
  • Slack Consultant
  • Slack Developer

Checklist progressProgress

0/228Learned

  • API-led connectivity versus point-to-point and ESB-centric integration
  • REST, SOAP, RPC, GraphQL and gRPC as interface technologies
  • API specification languages as the contract technology of API-led connectivity
  • Mule runtime, connectors and APIkit as API implementation technology
  • Roles of API implementations, API proxies and API clients at runtime
  • Synchronous web APIs versus asynchronous messaging in an application network
  • APIs, web services and web APIs compared
  • HTTP methods and resource semantics in web APIs
  • Web API contracts and decoupling clients from implementations
  • Web APIs as building blocks of an application network
  • Internal, partner and external APIs by audience and access
  • Assigning APIs to layers by functional focus
  • Anypoint Platform components across the API lifecycle
  • API mocking service in design-first API development
  • Anypoint Exchange as the application network's discovery catalog
  • API Manager versus Runtime Manager responsibilities
  • Anypoint Monitoring, API analytics and Anypoint Visualizer capabilities
  • Business groups and environments in Access Management
  • Center for Enablement versus traditional Center of Excellence
  • C4E mandate and cross-functional team composition
  • Sequencing the steps to establish a C4E
  • C4E-driven asset reuse and self-service through Anypoint Exchange
  • Selecting KPIs that measure C4E success
  • MuleSoft Catalyst methodology and its benefits for the IT delivery gap
  • MuleSoft Catalyst three pillars and their focus
  • Control plane versus runtime plane responsibilities
  • Choosing among MuleSoft-hosted, hybrid and customer-hosted plane combinations
  • When Anypoint Platform Private Cloud Edition fits the requirements
  • Selecting a MuleSoft-hosted control plane cloud for regional requirements
  • MuleSoft Government Cloud for FedRAMP-regulated organizations
  • Control plane cloud versus runtime region as independent choices
  • Identity Management versus Client Management on Anypoint Platform
  • SAML 2.0 versus OpenID Connect for Anypoint Platform SSO
  • Organization-wide identity providers versus environment-associated client providers
  • Supported external client provider options
  • External client providers for client registration and OAuth 2.0 enforcement
  • Control plane versus runtime plane data residency
  • Payload residency with customer-hosted Mule runtimes
  • Monitoring metrics and API analytics data residency
  • Application log residency and payload content in logs
  • Object Store v1 versus v2 data location on CloudHub
  • Meeting a regional data residency mandate across both planes
  • Roles of the API, API specification, API implementation and API client
  • Spec-first parallel development of API clients and implementations
  • APIkit scaffolding and request routing from the API specification
  • Client binding to API instance endpoints versus implementation endpoints
  • Impact of API implementation changes on existing API clients
  • API instance asset versions across minor, patch and major API changes
  • Dependency chains between API implementations and the APIs they invoke
  • Specification-driven design of reusable APIs
  • Anypoint Exchange as the catalog of reusable assets
  • API specification fragments as reusable design assets
  • Auto-generated Exchange asset portal for published API specifications
  • Exchange asset visibility versus runtime access protection
  • External developer portals and how new API versions reach them
  • Changes that require a new major API version
  • Minor versus patch increments for backward-compatible API changes
  • Quality-of-service and output value-domain changes in API versioning
  • Major version in the API URL and deprecation of superseded versions
  • Exchange asset version versus API version alignment
  • Anticorruption layer between Bounded Context data models
  • Safe versus idempotent HTTP methods
  • Client retry safety by HTTP method after a timeout or lost response
  • PUT versus POST versus PATCH for create and update operations
  • HTTP-native optimistic concurrency control
  • Benefits of decoupled API-led layers over point-to-point integration
  • Decomposing a business process into System, Process and Experience APIs
  • Matching protocols and interface styles to API-led layers
  • When to build Experience APIs, per channel or shared across channels
  • Bypassing an API-led layer versus adding a pass-through API
  • Functional focus of System, Process and Experience APIs
  • Ownership as a criterion for assigning APIs to layers
  • Rate of change as a criterion for assigning APIs to layers
  • System APIs exposing an existing Enterprise Data Model
  • Bounded Context data models for System APIs without an enterprise model
  • Approximately mirroring a backend data model in a System API
  • Enterprise canonical data model benefits and adoption costs
  • Bounded Context Data Model characteristics and context boundaries
  • Enterprise Data Model versus Bounded Context Data Models for an organization
  • Data model strategy across Experience, Process and System APIs
  • DataGraph unified schema linking, merging and collaboration
  • DataGraph versus a new Experience or Process API for consumer data needs
  • API version, API instance and environment relationships
  • Aligning API Manager environments with backend system environments
  • Separate API instances of one API version for distinct consumer groups
  • Deprecating versus deleting an API instance during consumer migration
  • Gateway policies versus API implementation logic for meeting NFRs
  • Policy application scope: resource-level, API-wide and automated
  • Rate Limiting versus Spike Control for throughput NFRs
  • SLA-based rate limiting and SLA tier design for API consumers
  • HTTP Caching policy for response-time and backend-load NFRs
  • CORS, header and message logging policies for non-security NFRs
  • Contract-changing policies versus policies transparent to API clients
  • Client ID Enforcement and the credentials declared in the API specification
  • Reflecting a policy in the spec: traits, snippets, republishing and redeploying
  • Control plane versus runtime roles in Mule Gateway policy enforcement
  • API proxy types and request validation levels
  • API proxy placement relative to clients, backends and network boundaries
  • When to choose Anypoint Service Mesh for policy enforcement
  • Experience API policy selection for external and partner consumers
  • Restricting Process and System API access to callers from the layer above
  • Traffic-protection policies placed by API-led tier
  • Edge-only versus layered policy enforcement across API-led tiers
  • Situations that require API clients to present client credentials
  • Credential placement options for the Client ID Enforcement policy
  • Client application registration and access requests from Exchange
  • SLA tiers and automatic versus manual approval of access requests
  • Approving or rejecting pending access requests in API Manager
  • Revoking versus deleting a client application contract
  • Contract scope across API instances, environments and API Groups
  • Client ID enforcement versus OAuth 2.0 access token enforcement
  • Basic Authentication Simple versus LDAP policies
  • IP allowlist and blocklist policies for restricting call origin
  • JSON and XML threat protection for malicious request payloads
  • Tokenization and detokenization policies for sensitive data
  • Combining and ordering several policies on one API instance
  • Anypoint Platform, external IdP and API gateway roles in an OAuth 2.0 token flow
  • External IdP as SSO identity provider versus OAuth 2.0 client provider
  • Native Anypoint client provider versus external OAuth 2.0 client providers
  • Matching the token enforcement policy to the OAuth 2.0 provider and token type
  • Client provider scope across root organization, business groups and environments
  • Included versus custom API policies for unmet or cross-cutting requirements
  • Purpose and runtime behaviour of Mule API autodiscovery
  • Prerequisites for pairing a Mule application with an API instance
  • Pairing cardinality between Mule applications and API instances
  • Autodiscovery API instance IDs and credentials across environments
  • Basic endpoint with autodiscovery versus a deployed API proxy
  • Requirements that call for an Anypoint VPC versus the shared worker cloud
  • Choosing among Anypoint VPC connectivity methods for a network topology
  • Private API exposure with VPC firewall rules and internal worker DNS
  • Dedicated Load Balancer needs that depend on an Anypoint VPC
  • Isolating environments and business groups with Anypoint VPCs
  • Anypoint VPC address-space sizing and overlap constraints
  • Runtime plane hosting options and operational responsibility
  • Managing customer-hosted Mule runtimes from the MuleSoft-hosted control plane
  • Control plane hosting choices and the runtime planes each supports
  • Unit tests versus integration tests for Mule applications
  • Where MUnit is best employed in an API implementation test strategy
  • Continuous integration responsibilities and benefits for Mule projects
  • Mule Maven plugin for automated deployment of API implementations
  • MUnit tests and coverage gates in an automated build
  • Build-once artifact promotion across Anypoint environments
  • Automated publishing of API specifications and assets to Exchange
  • Automating API Manager instances and policies in a CI/CD pipeline
  • API Functional Monitoring and BAT for automated API testing
  • Application state scenarios suited to Object Store on CloudHub
  • Preserving application state across CloudHub restarts and redeployments
  • Sharing state across multiple workers of one CloudHub application
  • Object Store versus CloudHub persistent queues for durability
  • Object Store v2 capacity, retention and throughput boundaries
  • Object Store regionality in multi-region and disaster recovery designs
  • Worker memory, heap and disk capacity when sizing a CloudHub application
  • vCore subscription consumption by worker size and worker count
  • Fractional versus whole-vCore CloudHub workers for performance consistency
  • Vertical worker sizing versus horizontal worker scale-out on CloudHub
  • CloudHub autoscaling policies for worker size and worker count
  • CloudHub platform redundancy, self-healing and zero-downtime updates
  • Worker count and availability zone failure outcomes
  • Persistent queues reliability and performance tradeoffs
  • Shared Load Balancer limits affecting app performance and reliability
  • Region placement effects on latency and data locality
  • Region outage behavior for apps deployed in one or several regions
  • Control plane outage effects on CloudHub apps and operations
  • Anypoint VPC prerequisite and environment scope of a Dedicated Load Balancer
  • Custom certificates and two-way TLS on Shared versus Dedicated Load Balancers
  • TLS versions and load-balancer-to-worker encryption on CloudHub
  • Vanity domains and DLB mapping rules for many APIs under one domain
  • Static inbound IP addresses for partner allowlisting through a load balancer
  • Shared Load Balancer rate limits versus Dedicated Load Balancer capacity
  • Environment association and deployment region for apps in an Anypoint VPC
  • CloudHub DNS records and ports for public and private worker access
  • Anypoint VPC firewall rules versus DLB allowlists for inbound access
  • Anypoint VPN versus AWS Direct Connect for on-premises data centers
  • VPC peering versus transit gateway attachment for customer-owned Amazon VPCs
  • Anypoint VPC address range and route planning for connected networks
  • Static IP allowlisting versus Anypoint VPC private connectivity to backends
  • Worker count and persistent queues for message-loss and downtime goals
  • Bypassing the CloudHub load balancer with worker-specific URLs
  • Dedicated Load Balancer resilience and client DNS handling
  • Redundant connectivity from Anypoint VPC to on-premises and AWS networks
  • Cross-region disaster recovery design for CloudHub API implementations
  • End-to-end single points of failure across API-led layers

Design, describe, and differentiate between scenarios that use an OS or caching

0/6

  • Judging whether API data is a good candidate for caching
  • HTTP Caching policy versus Cache scope in the API implementation
  • HTTP Caching policy cache key and cacheable request design
  • Object Store as a shared cache for values from external systems
  • Sharing cached data across CloudHub workers and restarts
  • Object Store versus caching for API implementation requirements

Select resilience strategies that help web API clients guard against failures when invoking APIs

0/8

Invocation timeouts and timeout budgets across API-led layers

Learn this concept
Unseen

Retrying transient API invocation failures

Learn this concept
Unseen

Retry safety for non-idempotent API operations

Learn this concept
Unseen

Circuit breaker pattern for failing downstream APIs

Learn this concept
Unseen

Fallback API invocation, sequential versus parallel

Learn this concept
Unseen

Cached fallback results versus static fallback results

Learn this concept
Unseen

Layering multiple resilience strategies in one API client

Learn this concept
Unseen

Client-side resilience versus provider-side safeguards

Learn this concept
Unseen

Describe when horizontal scaling of an API implementation is or is not likely to benefit response time and throughput as seen by API clients

0/7

  • Vertical versus horizontal scaling of CloudHub workers
  • Response time versus throughput effects of horizontal scaling
  • Stateless design and shared-state overhead when scaling out
  • Workload types that do or do not benefit from scaling out
  • API implementation versus backend bottleneck when adding workers
  • Scaling one layer within an API-led invocation chain
  • Network placement latency and the limits of scaling out
  • Runtime-plane data producers versus control-plane monitoring tools
  • API gateway and API Manager as the source of API invocation data
  • Anypoint Monitoring agent as the source of Mule application metrics
  • Enabling monitoring data collection by runtime deployment target
  • Runtime Manager dashboards and CloudHub worker monitoring as data sources
  • Log data sources and log aggregation for Mule applications
  • Anypoint Visualizer data collection across the application network
  • API Functional Monitoring versus traffic-based API metrics and alerts
  • Alert families and the Anypoint Platform component that raises each
  • Metrics and dimensions captured for managed API invocations
  • Per-consumer usage metrics for API client applications
  • API invocation metrics versus Mule application metrics
  • Application-level invocation metrics versus network and payload data
  • Correlating invocation metrics across Experience, Process and System APIs
  • Matching API instance alert types to non-functional requirements
  • Request count alerts versus traffic-limiting policies
  • Alert design for Experience, Process and System API layers
  • API instance alert triggering and notification behavior
  • Runtime Manager versus Anypoint Monitoring alerts by deployment target
  • Worker availability and deployment outcome alerts for CloudHub apps
  • CPU and memory utilization alerts for Mule app workers
  • Message volume, error and response-time alerts for Mule apps
  • Server, server group and cluster alerts for on-premises Mule runtimes
  • Custom application alerts raised from flows via the CloudHub Connector
  • Alert threshold evaluation, retriggering and notification behaviour

Prepare for the Exam

Play Today's Certle

Study Community

Ask questions and get the latest info from other MuleSoft Platform Architect studiers.

Go to Discord
  1. MuleSoft Platform Architect Checklist
  3. Meeting API quality goals

Cached fallback results versus static fallback results

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 228 concepts on the Salesforce MuleSoft Platform Architect exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptLayering multiple resilience strategies in one API client

Checklist progress

0/228 (0%)

0 of 228 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle

Study Community

Ask questions and get the latest info from other MuleSoft Platform Architect studiers.

Go to Discord
Close
  1. MuleSoft Platform Architect Checklist
  3. Meeting API quality goals
Cached fallback results versus static fallback results

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 228 concepts on the Salesforce MuleSoft Platform Architect exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptLayering multiple resilience strategies in one API client

Explainer

When an API call cannot give a client a fresh answer, the client can return a fallback result instead. A cached fallback result is a real value saved from an earlier response and read back later. A static fallback result is a fixed value set ahead of time. In a Mule app, an Object Store can hold cached values, and the Retrieve operation's default value can supply a static one.
Core information
  • A cached fallback reuses a value that was saved earlier, so it exists only after at least one value has been stored. A static fallback is fixed in advance, so it never depends on an earlier response.
More details and nuances
  • The defaultValue is returned but not stored. A static fallback never fills the cache, so later Retrieve calls for the same key keep returning the default until a real value is stored.

Explainer

When an API call cannot give a client a fresh answer, the client can return a fallback result instead. A cached fallback result is a real value saved from an earlier response and read back later. A static fallback result is a fixed value set ahead of time. In a Mule app, an Object Store can hold cached values, and the Retrieve operation's default value can supply a static one.
Core information
  • A cached fallback reuses a value that was saved earlier, so it exists only after at least one value has been stored. A static fallback is fixed in advance, so it never depends on an earlier response.
More details and nuances
  • The defaultValue is returned but not stored. A static fallback never fills the cache, so later Retrieve calls for the same key keep returning the default until a real value is stored.