• Cert++
  • Practice
  • Certle
  • Review
  • Tracks
  • Checklist
  • Guides
  • Upgrade
Cert++
  1. Home
  3. MuleSoft Platform Architect

MuleSoft Platform Architect

Checklist progress

0/188Learned

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
  • 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 Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • 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 Architect

Checklist progress

0/188Learned

  • Differentiate when to use Object Store (explicit key/value state such as watermarks/tokens that must persist and be shared across workers) from when to use caching (HTTP/cache-scope response caching to reduce latency and backend load), and choose the right mechanism for a stated quality goal.
  • Describe how the Cache scope and HTTP Caching policy reduce response time and downstream/backend load by serving repeated requests for the same idempotent, cacheable resource from cached results.
  • Explain the role of time-to-live (TTL) and entry expiration for Object Store entries, and predict the consequence of choosing a TTL that is too long (stale shared state) or too short (lost continuity across polling cycles or restarts) for a stated quality goal.
  • Identify the trap of using caching to store data that must be exact and durable (e.g., authoritative balances, sequence/idempotency keys, watermarks) — recognizing that a cache may evict entries and is not a persistence guarantee — and instead recommend Object Store for state that must not be silently lost.
  • Recognize the operational limits of Object Store v2 — eventual consistency, rate/throughput limits, entry size constraints, and higher latency of remote access — for a stated workload.
  • Given an API client that overwhelms a struggling backend with retries, choose the combination of resilience patterns (circuit breaker plus capped retries with backoff, relying on idempotent methods) that prevents cascading failure, selecting the exact number the question requires.
  • Explain why retries should use exponential backoff with jitter to avoid retry storms and the thundering-herd/synchronized-retry effect that amplifies load on a recovering backend.
  • Describe the circuit breaker states (closed, open, half-open) and what each state means for whether API calls are allowed through to the dependency.
  • Recognize idempotency (and idempotency keys) as the precondition that makes retries safe for non-idempotent operations such as POST, and explain why retrying a non-idempotent call without an idempotency mechanism risks duplicate side effects.
  • Select fallback or graceful-degradation strategies — returning cached or default responses — so that the failure of one downstream dependency does not take down the entire client application.
  • Describe how horizontal scaling increases aggregate throughput and concurrent request capacity as seen by API clients when the API implementation tier is the bottleneck.
  • Differentiate horizontal scaling (adding more workers/replicas behind a load balancer to raise concurrency) from vertical scaling (increasing worker size/vCores to add per-instance capacity), and select which is appropriate for a stated bottleneck (CPU/memory-bound per request versus high concurrent request volume).
  • Explain why horizontal scaling delivers throughput gains when the API implementation is effectively stateless or shares state via Object Store v2 and the load balancer distributes requests evenly.
  • Predict that sticky sessions, per-worker local state, or skewed load-balancer routing undermine the expected throughput benefit of horizontal scaling.
  • Identify when a shared downstream dependency (a single backend system, database connection pool, or rate-limited SaaS API) is the true bottleneck, and predict that scaling out the Mule API tier will not improve — and may worsen — client-observed throughput because the constraint simply moves to the saturated dependency.
  • Identify Anypoint Monitoring as the component that collects, aggregates, and visualizes runtime telemetry (built-in and custom dashboards, metrics, logs, and time-series data) for Mule applications and APIs, and distinguish its role from API Manager analytics.
  • Identify API Manager (and its analytics) as the component that generates API-invocation/usage data and policy-enforcement events for managed APIs at the gateway, and match it to questions about per-API consumption, SLA usage, and policy violations.
  • Identify Runtime Manager (for CloudHub workers and on-prem/RTF servers) as the component that generates application/worker resource and lifecycle data — CPU, memory, worker status, deployment events, and application logs — and match it to infrastructure-health monitoring needs.
  • Given a monitoring or alerting requirement (e.g., per-consumer API usage vs. worker CPU exhaustion vs. end-to-end latency across layers), select the correct Anypoint Platform component that produces the needed data and reject components that cannot produce that signal.
  • Identify that custom business/application metrics can be emitted from Mule flows (e.g., custom metrics/logging into Anypoint Monitoring) and match this capability to monitoring needs that built-in platform metrics do not cover.
  • Describe request volume / invocation count (requests over time) as an API-invocation metric and match it to questions about demand, traffic trends, and capacity planning.
  • Describe response time / latency and its distribution (average plus percentiles such as p90/p95/p99) as an API-invocation metric, and explain why percentiles reveal tail-latency problems that averages hide.
  • Describe the 4xx client-error rate as an API-invocation metric and identify what a rising 4xx rate indicates — authentication/authorization failures, policy rejections, or malformed client requests — versus a backend implementation failure.
  • Describe the 5xx server-error rate as an API-invocation metric and identify what a rising 5xx rate indicates — Mule application or backend-system implementation failures — versus client-side or policy-related 4xx errors.
  • Describe dimensional breakdowns of API-invocation metrics available in API Manager analytics — by API and version, client/application/consumer, resource/method, location, and time window — and match a diagnostic question to the dimension that isolates the cause.
  • Distinguish API Manager analytics (gateway-observed invocation/usage metrics for managed APIs) from Anypoint Monitoring metrics (deeper runtime, message-flow, and infrastructure telemetry), and select the source whose collected metrics answer a given invocation question.
  • Specify a high-latency / response-time alert (e.g., p95 or p99 response time above an SLA threshold) rather than alerting on average latency, and justify the percentile choice in terms of client-experienced performance.
  • Specify SLA-quota and rate-limit alerts in API Manager (quota approaching or exceeded) and match them to detecting abusive consumers or clients that will soon be throttled before hard rejection occurs.
  • Reason about which API-led layer (Experience, Process, or System) to alert on for a given failure mode — e.g., alert on the System-layer API to catch backend degradation early, and on the Experience layer to catch client-impacting symptoms — and avoid redundant alert noise across layers.
  • Specify a CPU-utilization threshold alert for CloudHub workers or RTF/on-prem servers and match sustained high CPU to the risk of thread starvation or degraded response times before clients are impacted.
  • Specify a memory-utilization threshold alert for CloudHub workers or RTF/on-prem servers and match sustained high memory to the risk of OutOfMemory failures, garbage-collection pressure, or worker restarts before clients are impacted.
  • Specify a worker/application status alert (worker not responding, application stopped/undeployed, or unresponsive) to detect an unhealthy or down Mule application, and distinguish it from a metric-threshold alert.
  • Specify a deployment-event alert (deployment failure or successful deployment notification) so that failed or unexpected deployments are surfaced to the operations team immediately.
  • Differentiate the technologies that realize an application network (web APIs over HTTP, API gateways/management, integration runtimes) from point-to-point integration, SOA/ESB, and message brokering.
  • Given a scenario describing how systems are connected today (e.g., tightly coupled point-to-point links or a central ESB bottleneck), recommend why API-led connectivity with discoverable, reusable APIs better enables decentralized, self-service consumption and reduces delivery friction.
  • Identify API specification languages (RAML and OAS) as technologies of API-led connectivity and match them to their role in defining machine-readable API contracts.
  • Identify the integration/runtime engine (Mule runtime with out-of-the-box connectors) as a technology of API-led connectivity and match it to its role in implementing APIs and connecting to backend systems.
  • Identify the API gateway as a technology of API-led connectivity and match it to its role in enforcing policies at the edge of an application network.
  • Distinguish API-led connectivity as an architectural approach/methodology from the underlying technologies that implement it (REST/HTTP, RAML/OAS, Mule runtime, connectors, API gateway), and identify the trap of treating a single product or protocol as 'API-led connectivity' itself.
  • Describe the defining characteristics of a web API in an application network: HTTP-based interface, defined contract/specification, independently versioned and managed, discoverable in Exchange, and consumed over the network.
  • Explain the role a web API plays as a managed, governed interface between providers and consumers — exposing capabilities through a stable contract while hiding backend implementation — and identify why this decoupling is central to building an application network.
  • Describe the core REST architectural characteristics of a web API: resource-oriented addressing via URIs, a uniform interface using standard HTTP methods and status codes, statelessness (each request self-contained), and typically synchronous request/response interaction over HTTP.
  • Identify the trap of assigning an API to a tier by what it technically can do rather than by ownership, functional focus, and rate of change, and choose the correct tier when an API's capability appears to fit multiple layers.
  • Describe the three axes used to assign an API to a tier — ownership (system, central/LOB, or channel team), functional focus (unlocking a backend system, composing business logic, or shaping data for a channel), and rate of change (slow, moderate, or fast) — and match each to the System, Process, or Experience tier.
  • Identify Design Center/API Designer as a high-level Anypoint Platform component and match it to its capability of designing API specifications.
  • Identify Anypoint Exchange as a high-level Anypoint Platform component and match it to its capability of discovering and sharing reusable assets.
  • Identify API Manager as a high-level Anypoint Platform component and match it to its capability of governing APIs and enforcing policies.
  • Identify Runtime Manager as a high-level Anypoint Platform component and match it to its capability of deploying and managing runtimes.
  • Identify Anypoint Monitoring/Analytics as a high-level Anypoint Platform component and match it to its capability of observing live application and API traffic.
  • Identify the Mule runtime engine as a high-level Anypoint Platform component and match it to its capability of executing Mule applications and API implementations.
  • Distinguish the control plane components of Anypoint Platform (design, management, governance, monitoring) from the runtime plane (where Mule applications execute), and identify which capabilities live in which plane.
  • Identify DataWeave as design-time developer tooling and match it to transforming data within Mule applications.
  • Given a described need at a specific stage of the API lifecycle (design a contract, share/reuse an asset, apply a security policy, deploy and scale a runtime, observe live traffic, or test before release), select the single Anypoint Platform component that best satisfies it and reject components that operate at a different lifecycle stage.
  • Describe the purpose and operating function of a Center for Enablement (C4E) — driving asset reuse, self-service consumption, and a federated delivery model rather than a centralized integration team.
  • Given an organization at a stated maturity level, advise how to establish a Center for Enablement (C4E) that fits its delivery model and governance needs.
  • Identify the KPIs that measure C4E success — number of reusable assets published, asset reuse/consumption rate, time-to-market for new projects, and developer self-service adoption.
  • Distinguish true C4E success KPIs from vanity or unrelated operational metrics when selecting measures of enablement effectiveness.
  • Identify the functions a C4E performs — setting standards and best practices, curating and promoting reusable assets in Exchange, onboarding and enabling delivery teams, and governing the platform.
  • Describe the three dimensions of MuleSoft Catalyst — Delivery (KPI-driven outcome delivery), Operating Model (the C4E), and Technology (the platform).
  • Match an organizational activity or goal to the correct MuleSoft Catalyst dimension — Delivery, Operating Model, or Technology.
  • Describe MuleSoft Catalyst as a prescriptive delivery methodology and benefits framework (not a product) whose purpose is to accelerate business outcomes by establishing measurable KPIs, an enabling operating model, and a reusable technology foundation.
  • Identify the benefits MuleSoft Catalyst delivers — faster time-to-market, increased asset reuse, and organizational change toward self-service consumption.
  • Distinguish the control plane (design, management, governance, monitoring services) from the runtime plane (where Mule applications execute).
  • For each hosting option (CloudHub/CloudHub 2.0, Runtime Fabric, customer-hosted on-premises, Private Cloud Edition), identify which plane MuleSoft operates versus which the customer operates.
  • Given organizational constraints (data residency, control over infrastructure, operational ownership), choose among runtime-plane hosting options — MuleSoft-hosted CloudHub, customer-hosted Mule runtimes on-premises, Anypoint Runtime Fabric (RTF) on customer Kubernetes/containers, and Private Cloud Edition (PCE) — and justify the best fit.
  • Distinguish hosting options for the Anypoint Platform control plane — MuleSoft-hosted SaaS control plane versus customer-managed control plane via Private Cloud Edition — and identify when each is required by compliance or isolation requirements.
  • Identify that MuleSoft offers regional MuleSoft-hosted control planes (e.g., the US and the EU control planes) and select the appropriate control-plane region when management/metadata data-residency or regulatory requirements dictate where control-plane data is stored, distinguishing this from runtime-plane region selection.
  • Distinguish Identity Management (who can log in to and use Anypoint Platform, via the built-in directory or an external IdP) from Client Management (how API client applications are provisioned and authenticated, via the built-in provider or an external OpenID Connect provider).
  • Given an organization that already uses an external identity provider for employees and a separate system for managing API consumer credentials, identify whether Identity Management, Client Management, or both must be configured to delegate to external systems.
  • Identify the supported Identity Management integration standards — built-in Anypoint directory plus SAML 2.0 and OpenID Connect external IdPs.
  • Identify the supported Client Management integration options — built-in client provider plus OpenID Connect dynamic client registration providers such as PingFederate, Okta, Azure AD/Microsoft Entra, ForgeRock, and OpenAM.
  • Identify the configuration constraints of Identity Management and Client Management — each is configured at the master organization (root business group) level and only one identity provider and one client provider can be active at a time.
  • Identify that request/response message payloads are not persisted by Anypoint Platform — they are processed in the runtime plane and pass through without being stored by the control plane.
  • Identify that metrics, metadata, monitoring/analytics, and management data are collected and stored by the Anypoint Platform control plane.
  • Given a data-residency requirement that affects control-plane data (metrics, metadata, management data) rather than payloads, determine that selecting a regional MuleSoft-hosted control plane (e.g., the EU control plane) or Private Cloud Edition — not merely a runtime region or VPC — is required, and reject a solution that controls only where payloads run while control-plane data still leaves the region.
  • Identify the dependency chain among an API specification (RAML/OAS contract), its implementation (the Mule app fulfilling the contract), and its clients.
  • Given a change to the API specification, implementation, or client, predict how that change propagates to (or is isolated from) the other artifacts.
  • Explain why designing the API specification first (contract-first/spec-driven) lets clients and implementation teams proceed in parallel.
  • Explain how a mocking service generated from the published API specification lets client developers build and test against the contract before any implementation exists, decoupling client delivery from implementation availability.
  • Describe how Design Center/API Designer is used to author reusable API-related assets — RAML/OAS specifications, fragments, data types, and traits.
  • Describe how Anypoint Exchange is used to publish, discover, and reuse API-related assets across the application network.
  • Identify how RAML fragments, traits, and data type libraries published to Exchange promote reuse across multiple API specifications, and recommend using shared fragments instead of duplicating definitions when several APIs need a common data model or behavior.
  • Explain how publishing an API specification to Exchange automatically provisions an interactive API console, documentation, and a mocking service for self-service exploration and contract-based client development.
  • Explain how one Exchange asset can declare a dependency on another (e.g., an API specification importing a published RAML fragment or data-type library) so that updating the shared asset propagates to consuming specifications, and recommend this dependency model to keep common definitions consistent across many APIs.
  • Distinguish the semantic version of a published Exchange asset/API specification from the version identifier exposed in the API base path/URI (e.g., /v1), and recognize that a MAJOR (breaking) change typically also drives a new major URI version while MINOR/PATCH changes do not.
  • Explain HTTP-native optimistic concurrency using ETag with If-Match / If-None-Match conditional headers, and choose this mechanism to prevent lost updates when multiple clients modify the same resource concurrently.
  • Distinguish safe HTTP methods (GET, HEAD, OPTIONS — no server state change) and idempotent methods (GET, HEAD, OPTIONS, PUT, DELETE — repeating the request yields the same end state) from methods that are not guaranteed idempotent (POST, PATCH).
  • Connect idempotency to client-side resilience: explain why idempotent methods (GET, PUT, DELETE) can be safely retried after a timeout or network failure without risk of duplicate side effects, while non-idempotent methods (POST) require an idempotency key or other safeguard before retrying, and choose the safe retry strategy for a given method.
  • Given a described business process spanning multiple backend systems and consuming channels, decompose it into the appropriate System, Process, and Experience APIs and assign each to its correct API-led connectivity layer.
  • Identify when orchestration/composition logic belongs in a Process API rather than being duplicated in Experience APIs or pushed into System APIs, and choose the layering that maximizes reuse for a multi-channel business process.
  • Describe the canonical responsibility of a System API in API-led connectivity: unlock and expose data from a single backend system of record.
  • Describe the canonical responsibility of a Process API in API-led connectivity: orchestrate and compose data across multiple systems to implement business logic that is independent of source systems and target channels.
  • Describe the canonical responsibility of an Experience API in API-led connectivity: reformat and tailor data for consumption by a specific channel or audience.
  • Identify the trap of designing one monolithic API to implement an entire multi-system, multi-channel business process instead of decomposing into layered APIs.
  • Recognize that API-led connectivity layers are logical role assignments, not a mandatory three-tier hierarchy — a consumer in one layer may call APIs in the same or any lower layer.
  • Predict how rate of change differs across layers (Experience APIs change fastest to serve evolving channels; System APIs change slowest, tracking backend systems) and use this to justify why a frequently changing channel requirement should not be built into a System API.
  • Identify that System APIs are typically owned by central/integration or system-owning teams focused on stable, reusable backend access, and use this ownership signal to justify a System-layer assignment.
  • Identify that Process APIs are typically owned by central or line-of-business teams focused on cross-system business logic, and use this ownership signal to justify a Process-layer assignment.
  • Identify that Experience APIs are typically owned by the channel or front-end team that consumes them, focused on the consuming application's needs, and use this ownership signal to justify an Experience-layer assignment.
  • Resolve a conflict among the three axes when they point to different layers (e.g., an API technically capable of cross-system composition but owned by and changing in lockstep with one backend), and select the layer that best matches the dominant ownership and functional-focus signals rather than raw technical capability.
  • Recommend whether a System API's data model should closely mirror its backend system's model or be abstracted/cleaned, based on requirements such as decoupling consumers from backend changes, organizational ownership, and the stability of the backend.
  • Recommend keeping the System API data model close to a single backend (rather than imposing a broad canonical/enterprise model on it) so that the System API stays a thin, faithful unlock of one system of record, and reject pushing cross-system normalization into a System API where it belongs in the Process layer.
  • Identify DataGraph's role — federating multiple existing APIs into a single GraphQL query endpoint for read-aggregation — and select it only where query federation fits, rejecting it for write/transactional orchestration or where a Process API is the appropriate choice.
  • Identify that Anypoint DataGraph ingests REST APIs already published to Exchange and unifies their schemas into a single federated GraphQL schema.
  • Reject DataGraph for implementing complex business orchestration, stateful workflows, or write/mutation transactions across systems, and select a Process API instead.
  • Reject DataGraph for enforcing per-channel business logic or data shaping, and select an Experience API instead.
  • Determine how many API instances to create across environments (e.g., separate instances per environment such as Dev/Test/Prod) in API Manager for a given API, and configure them appropriately given the nature of the API and the underlying data and system.
  • Explain how Anypoint Platform environments isolate API instances, applied policies, SLA tiers, and client contracts from one another.
  • Given an API promoted from non-production to production with different backends or credentials, choose the correct environment and API instance arrangement.
  • Distinguish the ways an API instance can be managed in API Manager — a Mule application using autodiscovery (no proxy), a Mule-runtime API proxy, or an API endpoint managed by a gateway — and select the instance type appropriate to whether the implementation is a Mule app and where policy enforcement must occur.
  • Map a stated throttling or traffic-protection NFR to the correct API policy — rate limiting, SLA-based rate limiting, or spike control.
  • Map a stated access-control NFR to the correct API policy — client ID enforcement or OAuth 2.0 access token enforcement.
  • Map a stated performance or observability NFR to the correct out-of-the-box policy — HTTP caching policy for reducing latency/backend load, or message logging for auditability/observability.
  • Recognize that some NFRs are better satisfied by components of the API implementation or platform (e.g., a Dedicated Load Balancer for custom TLS, the implementation flow for business validation, Object Store/caching for state) rather than by an API Manager policy, and choose the policy-versus-implementation approach that fits the requirement.
  • Explain that multiple policies applied to an API instance execute in a defined, reorderable sequence, and order them correctly so that authentication/identity policies run before authorization, rate limiting, and transformation policies for a stated set of NFRs.
  • Identify the trap of assuming that applying any API policy changes the specification, and select which policies among a set are transparent to clients versus which alter the contract clients must follow.
  • Identify that internal System and Process APIs not exposed to untrusted callers can rely on client ID enforcement and network controls such as IP allowlist.
  • Identify that Experience APIs facing the public internet require stronger end-user authentication (OAuth 2.0/OpenID Connect) and threat protection beyond client ID enforcement alone.
  • Describe how an API client transmits client_id and client_secret to a web API protected by client ID enforcement — typically as HTTP headers, sometimes as query parameters for legacy clients.
  • Given a client ID enforcement policy configured to read credentials from custom headers or query parameters, identify how the client must transmit client_id/client_secret and how this affects what the API specification must document.
  • Distinguish the two purposes for which a client supplies client_id and client_secret — directly satisfying a client ID enforcement policy on each API call, versus exchanging them at an OAuth 2.0 token endpoint to obtain an access token that is then presented to an API protected by OAuth access token enforcement — and identify which credential the API actually validates in each case.
  • Explain how a client application requests access to a specific API version in Exchange/API Manager by creating a contract and obtaining client credentials.
  • Explain how the API owner approves or rejects a client's access request, including the role of SLA tiers with manual versus automatic approval.
  • Explain how the API owner revokes a client's access by revoking or deleting the contract, invalidating the associated client credentials.
  • Predict the effect of API versioning on existing access — that a client's contract is bound to a specific API version/instance, so publishing a new version requires clients to request access (and possibly a new contract) to the new version while existing contracts to the old version remain valid until deprecated or retired.
  • Select an authentication-oriented security policy — client ID enforcement, OAuth 2.0 access token enforcement, JWT validation, or basic authentication — to verify caller identity for a stated security requirement.
  • Select a network-restriction or threat-mitigation security policy — IP allowlist/blocklist or JSON/XML threat protection — for a stated non-authentication security constraint.
  • Choose the correct combination of security policies (e.g., restricting access by network origin and validating tokens) for an API that must accept calls only from known networks and only with valid OAuth tokens, selecting the exact number of policies the question specifies.
  • Under OAuth 2.0 on Anypoint Platform, identify which component issues access tokens versus which component validates them at the API gateway.
  • Given an organization that delegates client management to an external OpenID Connect provider, identify which component issues access tokens, how the OAuth 2.0 access token enforcement policy validates them, and how this differs from using Anypoint Platform's built-in client provider.
  • Map the OAuth 2.0 roles to the actors in an Anypoint deployment — the API client application as the OAuth client, the external IdP/client provider as the authorization server that issues tokens, the backend/end user as the resource owner, and the API gateway (enforcing OAuth access token enforcement) as the resource server that validates tokens — and identify that Anypoint Platform is the policy enforcement point, not necessarily the token issuer.
  • Explain how Business Groups and environments scope client applications, contracts, and the configured client provider — client provider/identity configuration is set at the master organization/root level and inherited by Business Groups — and predict how this scoping determines which clients and credentials are valid for an API instance in a given environment.
  • Explain how API autodiscovery uses the API instance ID (apiId) configured in a running Mule application to bind that implementation to an API instance in API Manager so that managed policies are enforced without a separate proxy.
  • Given an API implementation that must enforce API Manager policies directly in the Mule runtime, identify the Autodiscovery configuration required: apiId plus platform credentials or a connected app.
  • Given missing or misconfigured Autodiscovery settings, predict that API Manager policies are not enforced and the API instance remains Unregistered.
  • Distinguish governing an API implementation via Autodiscovery (the Mule runtime acts as an embedded API gateway with no extra network hop) from deploying a separate API proxy in front of the implementation.
  • Identify the trap of reusing one apiId across multiple environments or sharing it between unrelated implementations.
  • Identify private connectivity to customer networks as a requirement that calls for an Anypoint VPC.
  • Identify a Dedicated Load Balancer requirement as calling for an Anypoint VPC.
  • Distinguish scenarios that require an Anypoint VPC from cases where the shared CloudHub worker cloud suffices.
  • Describe what an Anypoint VPC is: a virtual, private, isolated network segment in the CloudHub shared worker cloud, created in a specific cloud region with a customer-chosen CIDR block.
  • Match Anypoint VPC connectivity needs to the correct mechanism: VPC peering or AWS Transit Gateway for AWS-to-AWS networks, and IPsec VPN for on-premises or non-AWS networks.
  • Explain how Anypoint VPCs relate to environments and Business Groups: a VPC can be shared across or dedicated to specific environments, and VPC-to-environment mapping controls network isolation between workloads such as production and non-production.
  • Compare and contrast runtime-plane hosting options — CloudHub (MuleSoft-hosted), customer-hosted Mule runtimes on-premises, Anypoint Runtime Fabric on customer-managed Kubernetes/containers, and Private Cloud Edition — by who operates the infrastructure, deployment model, and isolation, and choose the best fit for stated constraints.
  • Distinguish the Anypoint Platform control plane (web UIs and management/orchestration services) from the runtime plane (where Mule applications execute).
  • Describe CloudHub as the MuleSoft-hosted, fully managed iPaaS runtime plane running on workers in a shared or VPC-isolated AWS environment.
  • Describe Anypoint Runtime Fabric as a container-based runtime plane that runs Mule applications on customer-managed infrastructure (on-premises, private cloud, or public cloud) with isolation, scaling, and automated failover.
  • Describe customer-hosted standalone Mule runtimes (manually installed Mule servers, optionally grouped into clusters or server groups and managed via Runtime Manager).
  • Describe Anypoint Platform Private Cloud Edition (PCE) as a fully customer-hosted deployment of both the control plane and the runtime plane.
  • Distinguish unit tests (isolating a flow or processor with mocked dependencies) from integration tests (exercising real connections between components or systems).
  • Specify where MUnit is best employed to run fast, automated tests of Mule applications within a CI/CD pipeline.
  • Describe MUnit as MuleSoft's testing framework for Mule applications: it integrates with the Maven build, asserts on event payload/attributes/variables, and produces coverage reports.
  • Given a testing requirement (verify a transformation output, confirm error-handling behavior, validate end-to-end downstream behavior, or measure flow coverage), choose whether a mocked MUnit unit test or an integration test is appropriate and where it belongs in the pipeline.
  • Identify the trap of relying solely on integration tests (brittle, slow, dependent on external systems) or solely on unit tests (may miss real connectivity or contract issues).
  • Identify Maven with the Mule Maven plugin as the primary option for automating build, test, and deploy of Mule API implementations.
  • Identify the Anypoint CLI and Platform APIs as options for automating deployment and platform operations in a DevOps workflow.
  • Identify CI servers (for example Jenkins, GitLab CI, Azure DevOps) as the orchestration layer for end-to-end Mule DevOps pipelines.
  • Explain how externalized and secure properties with per-environment values supplied at deploy time let the same artifact promote unchanged across environments.
  • Given a DevOps requirement (gate deployment on passing tests/coverage, promote a tested artifact through environments without rebuilding, publish an API spec for consumers, or deploy to a specific runtime plane), select the appropriate combination of Mule Maven plugin goals, Anypoint CLI/Platform APIs, and CI server configuration to satisfy it.

Describe the scenarios for which Object Store (OS) should be used with CloudHub

0/3

  • Describe scenarios where Object Store v2 is the right choice on CloudHub: persisting transient key/value state such as watermarks, OAuth tokens, idempotency keys, or counters that must be shared across workers and survive application restarts.
  • Distinguish Object Store v2 from an external database or distributed cache for shared worker state — OS v2 is appropriate for lightweight, low-volume key/value persistence integrated with Mule flows, not for large payloads, high-throughput transactional storage, or strong consistency requirements.
  • Explain that a single CloudHub worker's default in-memory/persistent Object Store is not shared with other workers and is lost on restart or re-deploy.

Select CloudHub worker sizes and configuration as appropriate

0/5

  • Given a workload's memory, CPU, and payload-size requirements, select an appropriate CloudHub worker size (vCores).
  • Given a concurrency or throughput requirement, select an appropriate CloudHub worker count for horizontal scale.
  • Describe what a CloudHub worker is: a dedicated, single-tenant Mule runtime instance sized in vCores.
  • Distinguish vertical scaling (choosing a larger worker size for memory-bound, large-payload, or CPU-intensive processing) from horizontal scaling (adding more workers for higher concurrency and availability), and select the correct scaling axis for a stated bottleneck.
  • Distinguish persistent from non-persistent VM queues on CloudHub and match the queue type to stated reliability and message-durability requirements.

Given an app deployed to the CloudHub shared worker cloud in one or more regions, describe and predict its reliability and performance characteristics

0/5

  • Given a CloudHub deployment with a specific worker count and availability-zone distribution, predict failover behavior when a single worker or zone becomes unavailable.
  • Given a CloudHub region choice, predict network latency to consumers and backend systems based on geographic proximity.
  • Given a single-region versus multi-region CloudHub deployment, predict exposure to a full region outage and the availability impact.
  • Describe how the CloudHub Shared Load Balancer round-robins requests across healthy workers and predict load distribution and throughput when one worker becomes unavailable.
  • Explain that CloudHub does not provide automatic cross-region failover for a single application deployment.

Identify the defining differences between the CloudHub Shared and Dedicated Load Balancers

0/5

  • Describe the CloudHub Shared Load Balancer as the default ingress: a shared cloudhub.io DNS name with no support for custom domains, customer-provided TLS certificates, mutual TLS, IP allowlisting, or URL-mapping rules.
  • Explain that a Dedicated Load Balancer (DLB) is provisioned into an Anypoint VPC and that an Anypoint VPC is a prerequisite for using a DLB.
  • Explain that a Dedicated Load Balancer can front multiple CloudHub applications and workers within its Anypoint VPC.
  • Explain that a Dedicated Load Balancer supports custom domains, customer-provided TLS certificates, mutual TLS (two-way TLS), and configurable cipher suites.
  • Explain that a Dedicated Load Balancer supports IP allowlisting and URL-mapping rules to route traffic to different applications under one hostname.

Compare and contrast the options for CloudHub networking in the presence of customer-owned Amazon VPCs and on-premises data centers

0/6

  • Explain that an Anypoint VPC enables a private network boundary with firewall rules and is the prerequisite for VPC peering, AWS Transit Gateway attachment, IPsec VPN, and Dedicated Load Balancer connectivity.
  • Describe VPC peering between an Anypoint VPC and a customer-owned AWS VPC: direct VPC-to-VPC connectivity, non-transitive routing, and the requirement for non-overlapping CIDR blocks.
  • Describe AWS Transit Gateway connectivity from an Anypoint VPC: hub-and-spoke access to many VPCs, transitive routing, and cross-region reach.
  • Given a multi-VPC or hub-and-spoke AWS topology, select VPC peering versus AWS Transit Gateway to connect an Anypoint VPC to customer-owned Amazon VPCs.
  • Explain when an IPsec VPN with a customer gateway is the appropriate option to connect an Anypoint VPC to an on-premises data center over the public internet.
  • Identify the constraint that CIDR blocks must not overlap across an Anypoint VPC and any peered VPC, Transit Gateway–attached network, or VPN-connected on-premises network.

Identify and avoid single points of failure in CloudHub deployments of API implementations

0/5

Identify a single-worker CloudHub deployment as a single point of failure and recommend deploying two or more workers for high availability.

Learn this concept
Unseen

Identify a per-worker local Object Store (instead of shared Object Store v2) as a single point of failure for stateful multi-worker applications and recommend Object Store v2 to share state.

Learn this concept
Unseen

Identify non-persistent VM queues as a single point of failure for in-flight messages and recommend persistent VM queues when message durability is required.

Learn this concept
Unseen

Identify a single non-redundant backend system or a single Dedicated Load Balancer as architectural single points of failure and recommend redundant backends or DLB capacity as appropriate.

Learn this concept
Unseen

Explain that CloudHub auto-restarts an unhealthy worker (self-healing) but that restart of a lone worker still causes downtime for in-flight requests.

Learn this concept
Unseen

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

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

Go to Discord

Identify a single-worker CloudHub deployment as a single point of failure and recommend deploying two or more workers for high availability.

Explainer

Learn More

Practice Question

Keep going

Next conceptIdentify a per-worker local Object Store (instead of shared Object Store v2) as a single point of failure for stateful multi-worker applications and recommend Object Store v2 to share state.

Checklist progress

0/188 (0%)

0 of 188 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

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

Go to Discord

Explainer

A single-worker CloudHub deployment creates a single point of failure because the application relies entirely on one availability zone. Deploying with two or more workers distributes the application across multiple zones, ensuring that a data center outage does not cause service interruption. This multi-worker setup enables CloudHub's load balancing to maintain continuous availability and horizontal scalability.

Core information
  • A single-worker deployment concentrates all application traffic and processing into one availability zone, creating a single point of failure.
More details and nuances
  • If a single-worker deployment experiences an availability zone outage, CloudHub automatically migrates the application to a different zone, but the application will experience downtime during the restart and migration process.