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

MuleSoft Platform Integration Architect

Checklist progress

0/166Learned

MuleSoft Platform Integration 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/166Learned

  • Given a set of stakeholder statements for an integration project, classify which are functional requirements (what the system must do) versus non-functional requirements (qualities such as throughput, latency, availability, security, scalability).
  • Given non-functional requirements (e.g., 99.99% uptime, sub-200ms response, 5000 TPS), identify which Anypoint Platform deployment or architecture decisions those NFRs most directly constrain.
  • Translate quantified non-functional requirements (RPO/RTO, TPS, percentile latency, concurrent users, message size, retention) into concrete, measurable, testable acceptance criteria that drive design and validation decisions.
  • Given a requirement to design, document, and publish a REST API contract before implementation, select the appropriate Anypoint Platform components (API Designer, Design Center, Exchange, RAML/OAS specifications).
  • Identify which Anypoint Platform feature governs and manages event-driven (AsyncAPI) interfaces versus traditional web APIs, and when API Manager, Exchange, and Anypoint MQ apply.
  • Select the Anypoint Platform features needed to apply governance, rate limiting, and security policies to a deployed API without changing application code.
  • Differentiate API management deployment patterns — embedded API gateway (Mule runtime/auto-discovery), API proxy in front of an implementation, and Flex Gateway for non-Mule/Kubernetes services — and select the right pattern for a given backend and topology.
  • Recognize how API fragments, data types, traits, and library reuse in Design Center/Exchange and API specification versioning support consistent, reusable API design across teams.
  • Select platform features for API consumer onboarding and self-service (Anypoint API Experience Hub / developer portal in Exchange, application registration, SLA tier request/approval, contracts) to expose and monetize/govern APIs to internal or external consumers.
  • Identify the role of API Governance (rulesets, conformance) and Anypoint Platform's design-time governance in enforcing organizational API standards across published specifications.
  • Differentiate the Anypoint Platform control plane from the runtime plane, and identify which responsibilities (management, monitoring vs. application execution) belong to each.
  • Given data residency, isolation, and operational-control constraints, select the appropriate runtime plane deployment option (CloudHub, CloudHub 2.0, Runtime Fabric, customer-hosted/on-prem standalone runtimes).
  • Compare MuleSoft-hosted (US/EU) versus Anypoint Platform Private Cloud Edition control plane options and the requirements that drive choosing a private control plane.
  • Compare CloudHub 1.0 and CloudHub 2.0 (private spaces, Kubernetes-based replicas/vCores, networking, deployment model) and select the appropriate iPaaS option for a given isolation, networking, and scaling requirement.
  • Differentiate the operational responsibility split (who patches/upgrades the runtime, manages infrastructure, owns availability) across CloudHub, CloudHub 2.0, Runtime Fabric (self-managed vs. appliance), and customer-hosted runtimes.
  • Recognize how a single control plane manages applications deployed to heterogeneous runtime planes simultaneously, and the constraints on connecting customer-hosted/RTF runtimes to the control plane (agent, connectivity, offline operation).
  • Explain how a Mule runtime cluster shares state across nodes (distributed shared memory / Hazelcast) and how this differs from independent CloudHub workers, and select scenarios where clustering is required.
  • Differentiate primary-node-only flow execution (e.g., scheduler and poll sources running on a single cluster node) from load-balanced flows distributed across all cluster nodes.
  • Explain how distributed Object Stores and VM queues behave in a Mule runtime cluster (shared across nodes via the cluster grid) and select the correct configuration for state-sharing requirements.
  • Identify which deployment options support true clustering (customer-hosted runtimes, Runtime Fabric) versus those that achieve horizontal scale through independent workers (CloudHub), and the high-availability implications of each.
  • Differentiate a Mule server group (independently managed runtimes with no shared state) from a Mule cluster (shared memory grid via Hazelcast) and select the correct grouping for a management-only requirement.
  • Explain cluster quorum and split-brain considerations, including minimum node requirements for reliable cluster operation.
  • Differentiate unicast versus multicast node discovery for Mule clusters and identify the network and latency constraints required for reliable clustering.
  • Given a requirement to securely connect CloudHub workers to on-premises resources, select among VPC, VPN, VPC peering, Transit Gateway, and DLB.
  • Explain when a Dedicated Load Balancer (DLB) is required (custom domains, custom certificates/mTLS, custom rules) versus the shared load balancer for CloudHub apps.
  • Identify CloudHub static IP, IP whitelisting/allowlisting, and internal load balancing capabilities and select the right feature to satisfy a partner firewall or routing constraint.
  • Determine how CloudHub workers in multiple regions/VPCs communicate and how to architect cross-region connectivity for availability and latency requirements.
  • Explain how Anypoint VPC and firewall rules control inbound/outbound traffic for CloudHub workers, default outbound internet access, and DNS/connectivity to backend systems, and select rules that satisfy a security or connectivity constraint.
  • Identify when a Mule domain project (shared domain) is beneficial—e.g., sharing an HTTP listener connector/port or shared connectors across apps on the same customer-hosted runtime—and when it is unnecessary or unsupported (CloudHub).
  • Explain the constraints and trade-offs of domain-shared resources (coupling apps to a shared runtime, deployment dependencies) and select scenarios where they are clearly justified.
  • Identify which connector configurations and resources can be shared via a Mule domain (e.g., HTTP/HTTPS listener configs, JMS connectors, VM connectors, shared libraries).
  • Recognize which resources cannot be shared via a domain and the deployment constraint that all applications using a domain must run on the same Mule runtime instance.
  • Explain how Mule 4 class loader isolation prevents dependency/version conflicts between connectors and modules, and the implications for shared libraries and dependency management.
  • Given a scenario where two connectors require conflicting versions of a transitive Java library, predict how Mule 4 class loader isolation resolves it and what configuration (shared libraries) is needed.
  • Explain when a Java dependency must be declared as a shared library (e.g., JDBC driver for the Database connector) so it is visible to the connector's class loader, and predict the failure (ClassNotFound/driver not found) if it is not.
  • Differentiate the Mule 4 application/module/container class loading layers (Mule modules exporting only their public API) from Mule 3's flat classpath, and the implications for using third-party Java code and avoiding leaking internal classes.
  • Describe the Mule 4 self-tuning thread pools (UBER, CPU_LIGHT, CPU_INTENSIVE, BLOCKING_IO) and how event processors are scheduled onto the appropriate pool.
  • Given a flow with blocking I/O operations, analyze the implications of Mule 4's reactive model for back-pressure, throughput, and thread allocation.
  • Differentiate proactor pattern thread hand-off and back-pressure (HTTP 503/rejected events) behavior under load, and select design changes (async, queueing, sizing) to avoid event rejection when the runtime is saturated.

Create high-level integration architectures using API-led Connectivity

0/4

Given a set of systems and business processes, map components to the System, Process, and Experience API layers of API-led Connectivity and justify the layering.

Learn this concept
Unseen

Identify violations of API-led layering principles (e.g., an Experience API directly accessing a backend system) and select the corrected architecture.

Learn this concept
Unseen

Explain how API-led Connectivity promotes reuse and decoupling, and select where to place orchestration/aggregation logic given new channel requirements.

Learn this concept
Unseen

Relate API-led Connectivity to MuleSoft's Application Network / Center for Enablement (C4E) concepts (asset reuse, self-service consumption, decentralized delivery) and select governance decisions that maximize reuse across the organization.

Learn this concept
Unseen

Create high-level integration architectures using web APIs and HTTP

0/1

  • Select connection management settings (timeouts, connection pooling, keep-alive) to meet reliability and performance requirements for synchronous HTTP integrations.

Create high-level integration architectures using event-driven APIs and message brokers

0/5

  • Differentiate point-to-point queueing from publish-subscribe and select the appropriate messaging topology and broker feature (DLQ, message TTL, ordering) for reliability requirements.
  • Explain the role of AsyncAPI specifications and event-driven API governance in Anypoint Platform for designing event-driven interfaces.
  • Compare Apache Kafka characteristics (partitions, consumer groups, offsets, log retention/replay) and select it when high-throughput event streaming or replay is required.
  • Design for delivery guarantees and idempotency in event-driven systems (at-least-once vs at-most-once vs exactly-once, acknowledgement modes, dead-letter handling, poison messages) and select the broker/consumer configuration that satisfies a no-loss/no-duplicate requirement.
  • Select event notification or event-carried state transfer patterns when loose coupling and near-real-time updates are required without full event history.

Design Mule applications and integration solutions using common messaging patterns and technologies

0/4

  • Given a routing requirement, select the correct enterprise integration pattern (content-based router, message filter) and the Mule component that implements it.
  • Given a splitting or aggregation requirement, select the correct pattern (splitter, scatter-gather/aggregator) and the Mule component that implements it.
  • Given a transformation or observation requirement, select the correct pattern (message translator, wire tap) and the Mule component that implements it.
  • Select the guaranteed-delivery pattern (reliable acquisition with persistent queues) when messages must not be lost between acquisition and processing.
  • Differentiate property sources in Mule 4 (properties/YAML files, secure properties, system properties, environment variables, CloudHub/Runtime Manager properties) and select the correct precedence and approach for environment-specific configuration.
  • Given a requirement to protect sensitive values (passwords, keys), select the Secure Properties / Secure Configuration Properties module approach versus plaintext properties and identify how the encryption key is provided at runtime.
  • Explain property placeholder resolution and the use of a property to select environment-specific files (e.g., ${env}.yaml via a system property), and predict resolution behavior when the same key is defined in multiple sources of differing precedence.
  • Recognize how externalizing properties to Runtime Manager/CloudHub (including hidden/secured properties) supports promoting the same artifact across environments without rebuilding, and select this over baking values into the deployable archive.
  • Differentiate flows, subflows, and private flows and select the correct construct for synchronous reuse, encapsulation, and modularity in a Mule application.
  • Select flow references versus inline processing and identify when configuration elements should be defined at application scope for reuse across flows.
  • Explain the Mule event structure (payload, attributes, variables) and how it propagates across flows and flow references, including the behavior of variables vs. payload across boundaries.
  • Differentiate On Error Continue (error handled, processing continues) from On Error Propagate (error re-raised, processing stops) and select the correct handler for a requirement.
  • Select the Try scope, flow-level error handler, or global error handler for isolating and handling errors in a specific section versus application-wide.
  • Use Error Mapping and Raise Error to transform connector errors into application-specific error types and control the resulting payload and HTTP status.
  • Explain Mule error types (namespace:identifier, hierarchy, suppressed/parent matching), how connectors declare errors, and how to define and match custom error types for selective handling.
  • Differentiate flow processing strategies and exchange patterns (synchronous flows, async/one-way scope, flow vs subflow event/transaction propagation) and predict how variables, transactions, and errors propagate through flow references vs the Async scope.
  • Given a conditional branching requirement, select the Choice router and predict which route executes based on DataWeave expression evaluation.
  • Given a parallel aggregation requirement, select Scatter-Gather and predict its aggregated output structure and composite error behavior.
  • Given a resilience or iteration requirement, select among First Successful, Round Robin, For Each, or Parallel For Each and predict throughput and error behavior.
  • Predict the output structure and error behavior of iterative scopes (For Each preserves original payload and iterates collections sequentially; Parallel For Each returns an aggregated collection and concurrency; Batch for very large sets) and select among them for ordering, payload-shape, and throughput requirements.
  • Explain Choice router evaluation (first matching when/otherwise, DataWeave expression conditions) and how the variable/payload state is shared across routes, and select correct routing logic for a content-based routing requirement.
  • Select Salesforce Bulk API v1 or v2 operations via the connector for high-volume data loads and recognize when bulk processing is required over standard APIs.
  • Explain how the Salesforce Connector subscribes to Change Data Capture (CDC) events and the replay ID mechanism for recovering missed change events.
  • Explain how the Salesforce Connector subscribes to Platform Events or legacy PushTopic streaming channels and the durability implications of replay IDs.
  • Recognize Salesforce API limits and bulk vs. standard API trade-offs when integrating high-volume loads through the Salesforce Connector.
  • Select username-password or OAuth 2.0 JWT bearer flow authentication for headless server-to-server Salesforce integrations.
  • Select OAuth 2.0 authorization code flow and connected app configuration when a user-interactive authorization context is required.
  • Recognize how the Salesforce Connector surfaces DataSense metadata for SObjects/operations and handles error/partial-failure results in bulk and composite operations, and select handling for per-record success/failure responses.
  • Identify common configuration features shared across core connectors (HTTP, Database, File, FTP/SFTP, JMS, VM)—connection providers, pooling, reconnection, TLS—and select correct settings for a connectivity requirement.
  • Differentiate connector operation types (listener/source vs. operation/processor) and select the correct connector + operation for inbound vs. outbound integration patterns.
  • Explain connector polling/source features common across connectors (watermarking for incremental reads, scheduling strategies, idempotent processing, file matchers/post-processing actions like move/delete) and select correct configuration to avoid reprocessing or data loss.
  • Differentiate operation-level configuration shared by connectors (streaming vs in-memory, target/target value to avoid overwriting payload, transactional action participation, reconnection strategy, request/response timeouts) and select settings for a robustness or payload-preservation requirement.
  • Identify connector-supplied DataSense metadata as an input/output metadata source in Transform Message and recognize when it is automatically available.
  • Select example data, sample data, or explicit schemas (JSON schema, XSD, CSV/flat-file definitions) as metadata sources when a connector cannot supply DataSense metadata.
  • Explain how DataSense and defined metadata types enable design-time mapping and validation in Transform Message, and the implications of missing or weakly-typed metadata.
  • Recognize how DataWeave reads the payload/attributes/variables and MIME type to infer the reader format, and how setting output MIME type and explicit schemas (JSON schema, XSD, flat-file schema) controls writer behavior in Transform Message.
  • Design how canonical types are published and reused (e.g., as RAML/Exchange fragments or shared metadata types) so that System and Process APIs map to/from a governed canonical format consistently across the application network.
  • Select Validation module validators (is-not-null, matches regex, is-true, etc.) for in-flow business rule validation with Mule error type mapping.
  • Select Raise Error with a custom error type when validation failure must produce a specific application-defined error for downstream handling.
  • Differentiate the Validation module's 'all' vs short-circuit validations and how validation failures map to Mule error types for downstream error handling.
  • Select the correct validation layer in an API-led architecture (RAML/OAS request schema enforcement via APIkit/automatic 400 responses, gateway policy validation, vs in-flow business validation) for a given separation-of-concerns and error-response requirement.
  • Design an MUnit test that isolates a flow under test by mocking connector operations (mock-when), setting up events, and asserting on payload/attributes/variables; select the correct MUnit construct for each need.
  • Use MUnit verify-call to assert that a specific processor or connector operation was invoked with expected parameters during a test.
  • Use MUnit spy to observe intermediate payload, attribute, or variable values without mocking the spied processor.
  • Use MUnit error assertions (assert-that-error, expect-error) and coverage reporting to validate error-handling paths and measure test coverage.
  • Differentiate MUnit test structure (test/behavior/execution/validation sections, before/after suite and test scopes for setup/teardown) and select the correct lifecycle hook for shared fixtures vs per-test state.
  • Select MUnit parameterized tests and lifecycle hooks (before-suite, before-test, after-test) for shared fixtures versus per-test isolated state.
  • Configure MUnit coverage thresholds and flow enablement settings to fail builds when test coverage falls below required levels.
  • Use MUnit Tools (store, retrieve, assert-that with matchers) to write deterministic assertions on payload structure and values.
  • Given a testing goal (validate end-to-end behavior with real systems vs. measure throughput/latency under load), determine whether unit (MUnit), integration, or performance testing is the appropriate strategy.
  • Differentiate the objectives and tooling of integration testing versus performance/load testing for Mule applications and what each can and cannot validate.
  • Design a performance test strategy (baseline/soak/spike/stress tests, representative workloads, environment parity with production, measuring percentile latency and throughput, identifying bottlenecks) and identify what must be controlled to make results meaningful.
  • Identify where each test type fits in a CI/CD pipeline and the use of test doubles/stubs vs real downstream systems/sandbox environments for integration tests, selecting the right approach for reliability and repeatability.
  • Differentiate transient vs. persistent VM queues and explain VM queue behavior across deployment options (single worker, CloudHub multiple workers, clustered runtimes) including which scenarios share a queue.
  • Given a need for intra-app asynchronous decoupling and load balancing, select VM queues and predict their reliability/ordering characteristics versus an external broker.
  • Recognize VM connector limitations and scope (queues are local to a single application/deployment, not a cross-application broker; CloudHub workers do not share VM queues by default; transactional and redelivery support) and select VM vs Anypoint MQ for a cross-app or cross-worker requirement.
  • Design VM-based reliability (publish-consume vs publish with reply, persistent queues participating in transactions, redelivery on failure) and predict message durability/loss behavior on worker restart or crash in each deployment option.
  • Differentiate Object Store v2 (CloudHub) behavior, limits, TTL, and persistence from in-memory/persistent object stores on customer-hosted/clustered runtimes, and select the right OS configuration per deployment.
  • Given a requirement to share state across CloudHub workers, determine whether Object Store v2 is shared across workers and how to use the OS Connector operations (store, retrieve, remove, contains).
  • Recognize Object Store v2 API rate limits and throttling behavior and select an external store when request rates exceed OS v2 limits.
  • Recognize Object Store v2 size and capacity constraints (key/value size limits, max entries, TTL/expiration) and select OS v2 versus an external cache when limits would be exceeded.
  • Differentiate defining a custom object store config (in-memory vs persistent, entryTtl, expirationInterval, maxEntries) from the default/implicit object store, and select configuration so state survives restarts and is shared appropriately in clusters vs CloudHub.
  • Configure watermarking on poll sources and the Idempotent Message Validator with a shared/persistent Object Store for duplicate detection across workers.
  • Configure the Cache scope and Until Successful scope with object-store-backed state and select the correct Object Store for cross-worker coherence.
  • Configure OAuth token storage for connectors in a shared/persistent Object Store so authenticated connections work consistently across clustered or multi-worker deployments.
  • Given the cost/complexity of XA transactions, select reliable alternatives (idempotent receivers, reliable acquisition with VM/persistent queues, saga/compensation, at-least-once + dedup) and justify the choice.
  • Explain the Reliability Pattern (reliable acquisition into a persistent queue then process) and select it over XA when endpoints don't all support XA.
  • Design idempotency and exactly-once-effect processing using business/idempotency keys, the Idempotent Message Validator, and de-duplication with an object store, and select this approach to achieve reliability without distributed transactions.
  • Apply the saga/compensation pattern for multi-step distributed updates (orchestrated vs choreographed, compensating actions for partial failures) and select it over XA when participants cannot enlist in a global transaction.
  • Select the Until Successful scope to retry a set of processors on transient processing failures, including object-store-backed retry state.
  • Select connector reconnection strategies (reconnect, reconnect-forever, frequency, max attempts) for transient connection-establishment failures.
  • Select source redelivery policies (max redelivery count, dead-letter behavior) to handle poison messages and repeated processing failures at the message source.
  • Given a poison-message problem, explain how a redelivery policy detects repeated processing of the same message and how it interacts with transactions and DLQs.
  • Configure Until Successful behavior (maxRetries, millisBetweenRetries, what constitutes failure, the error raised when retries are exhausted) and select retry vs circuit-breaker-style handling for a downstream system that is intermittently unavailable.
  • Differentiate reconnection strategy applied at connection-establishment time (initial connect and runtime reconnection) from per-operation retry (Until Successful) and from source-level redelivery, and select the combination needed for end-to-end resilience to both connection loss and processing failures.
  • Differentiate high availability (within a region/cluster: multiple workers, clustering, persistent queues) from disaster recovery (cross-region failover, RPO/RTO) and select the correct approach for each deployment option.
  • Given RPO/RTO targets, design HA and DR for CloudHub (multi-worker, multi-region), Runtime Fabric, and customer-hosted clusters and identify what the platform provides vs. what the architect must design.
  • Identify CloudHub HA features (worker auto-restart on failure, persistent queues for zero-message-loss across workers, multiple workers across availability zones) and recognize what CloudHub does and does not automatically protect against.
  • Design a cross-region disaster recovery approach (active-active vs active-passive, data replication, DNS/load-balancer failover, idempotent reprocessing, control-plane region considerations) and select the topology that meets given RPO/RTO and cost constraints.
  • Identify which Mule connectors/resources support local vs. XA transactions (JMS, VM, DB) and design a transaction scope spanning multiple resources, recognizing connectors that cannot participate.
  • Differentiate local transactions from XA (two-phase commit) and select the correct transactional scope/action (ALWAYS_BEGIN, BEGIN_OR_JOIN, etc.) for an atomicity requirement, including performance trade-offs of XA.
  • Predict transaction propagation and boundary behavior across flow references, async/parallel scopes, and sources (a transaction is bound to a single thread; async/Scatter-Gather/Parallel For Each break the transaction; only certain message sources can begin transactions) and select a design that keeps the transaction intact.
  • Given throughput/latency targets, size CloudHub workers (vCore sizing) and worker count, and select horizontal vs. vertical scaling, parallelization, and caching to meet capacity goals.
  • Identify performance bottlenecks (blocking I/O, synchronous chaining, large payloads in memory) and select architectural changes (async processing, queueing, caching, non-blocking connectors) to improve throughput.
  • Relate vCore allocation to capacity (vCore CPU/memory characteristics, fractional vs full vCores, how worker size affects concurrency and heap) and select sizing that satisfies throughput while controlling cost, including when to scale out vs scale up.
  • Differentiate Mule 4 repeatable streaming (in-memory vs. file-store) from non-repeatable streaming and select the correct streaming strategy when a payload must be consumed multiple times (e.g., logging then writing).
  • Given memory-constrained processing of large files, configure repeatable file-store streaming and predict the memory/disk trade-offs versus fully buffering in memory.
  • Tune repeatable streaming strategy parameters (initialBufferSize, bufferSizeIncrement, maxBufferSize/maxInMemorySize for in-memory; in-memory threshold for file-store) and predict the error/behavior when a stream exceeds the configured limit.
  • Predict streaming consumption pitfalls (a non-repeatable stream consumed twice or beyond a scope is exhausted/closed; streams crossing async/transaction boundaries) and select the streaming strategy/design that keeps the stream usable where needed.
  • Select the correct construct for processing large datasets (For Each with batch size, Parallel For Each, Batch Job with batch steps/aggregator) and predict throughput, ordering, and error-handling implications.
  • Explain Batch Job phases (Load and Dispatch, Process, On Complete), record-level error handling (max failed records), and batch aggregator behavior; select Batch over For Each for very large or resilient record processing.
  • Configure batch tuning and semantics (block size, accepted/failed record filtering with acceptPolicy, batch job instance persistence/queueing to disk, aggregator with streaming vs fixed size, getting batch job result/statistics) for a high-volume resilient processing requirement.
  • Recognize Batch deployment considerations across deployment options (batch persistence to local disk, behavior in CloudHub workers vs clusters, where batch can/cannot run as primary-only) and select a design that processes large sequences reliably in the target deployment.
  • Design least-privilege access using Anypoint Platform roles, permissions, business groups, and environment-scoped authorization for a team scenario.
  • Configure SAML or OIDC single sign-on for Anypoint Platform user access and integrate with a corporate identity provider.
  • Configure connected apps with appropriate scopes for machine-to-machine automation while enforcing least privilege for CI/CD and administrative tasks.
  • Select client ID enforcement or OAuth 2.0 access token enforcement API Manager policies to authenticate API consumers.
  • Select mutual TLS (mTLS) policies and certificate configuration to secure API access for trusted client certificate holders.
  • Select Anypoint Security edge policies for WAF/threat protection and payload inspection at the perimeter of Runtime Fabric deployments.
  • Select IP allowlisting and TLS termination at the Anypoint Security edge to control perimeter access to integration endpoints.
  • Select tokenization at the edge to protect sensitive data (PII/PCI) before it enters downstream Mule applications.
  • Identify and counteract credential exposure risks (hardcoded secrets, unencrypted properties) using Secure Properties and externalized configuration.
  • Design TLS/mTLS configuration for Mule (one-way vs two-way TLS, keystore/truststore, TLS context reuse, certificate management/rotation) and select the correct configuration for securing inbound and outbound connections to a specific trust requirement.
  • Given a compliance requirement to track configuration/administrative changes, determine whether Anypoint audit logs satisfy it and how to query/retain them via the Audit Log Query API.
  • Differentiate the scope/retention of Anypoint audit logs from application runtime logs and Anypoint Monitoring, and design a compliance logging strategy that combines audit logs (control-plane changes) with forwarded application logs (data-plane activity) where each is required.
  • Design a CI/CD pipeline for Mule apps using the Mule Maven Plugin (package/deploy to CloudHub, RTF, on-prem) and MUnit Maven Plugin (run tests/coverage), and select the correct plugin/goal for each pipeline stage.
  • Explain how to parameterize environment-specific deployment (properties, secure properties, connected app credentials) in a Maven-driven pipeline and publish reusable assets to Exchange via Maven.
  • Design build-once/deploy-many promotion across environments (single immutable artifact promoted dev→test→prod, environment differences supplied at deploy time via Runtime Manager/connected-app config) and reject patterns that rebuild per environment.
  • Select the correct Mule Maven Plugin deployment configuration for the target runtime plane (CloudHub vs CloudHub 2.0 vs Runtime Fabric vs standalone/on-prem) and recognize the authentication options (connected app vs username/password) and goals used in an automated deploy.
  • Explain how connected apps and scopes enable automated/headless interactions with Anypoint Platform and how they differ from user credentials for CI/CD automation.
  • Design Mule application logging using Log4j2 configuration and select per-deployment options (CloudHub default log persistence/limits, forwarding to external log aggregators, customer-hosted file appenders) for a given retention/observability requirement.
  • Given a requirement to centralize logs across workers/environments, select an approach (disable CloudHub log forwarding to send to external SIEM/Splunk, log4j2 appenders) and recognize CloudHub log size/retention limits.
  • Design structured/correlated logging (correlation IDs across flows and APIs, log levels, asynchronous logging for performance, avoiding logging sensitive data) and select log4j2 configuration that supports troubleshooting distributed transactions without harming throughput.
  • Differentiate logging mechanics across runtime planes (CloudHub managed logs and Runtime Manager log access/limits vs Runtime Fabric log forwarding vs customer-hosted file/rolling appenders) and select the logging architecture that meets retention and access requirements per deployment.
  • Identify Anypoint Monitoring capabilities (built-in dashboards, custom dashboards, metrics, alerts, functional monitoring, log management) and what is available across CloudHub, Runtime Fabric, and customer-hosted deployments.
  • Given an SLA/observability requirement, select the right Anypoint Monitoring feature (alerts on metrics/thresholds, functional monitoring synthetic checks, distributed tracing/transaction visibility) and recognize tier/licensing differences.
  • Recognize what telemetry Anypoint Monitoring collects and how it is enabled across deployment options (built-in for CloudHub, agent/runtime requirements for Runtime Fabric and customer-hosted, custom metrics/business events) and select a monitoring design appropriate to the chosen runtime plane.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other MuleSoft Platform Integration Architect studiers. 595 members and growing.

Go to Discord

Explain how API-led Connectivity promotes reuse and decoupling, and select where to place orchestration/aggregation logic given new channel requirements.

Explainer

Learn More

Practice Question

Keep going

Next conceptRelate API-led Connectivity to MuleSoft's Application Network / Center for Enablement (C4E) concepts (asset reuse, self-service consumption, decentralized delivery) and select governance decisions that maximize reuse across the organization.

Checklist progress

0/166 (0%)

0 of 166 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 Integration Architect studiers. 595 members and growing.

Go to Discord

Explainer

API-led connectivity is a structured approach to connecting systems that replaces fragile point-to-point integrations with a reusable, three-layer API architecture. It exists to decouple systems from each other so teams can build, modify, and scale integrations without breaking existing workflows. By separating data access, business logic, and user interfaces, organizations can rapidly adapt to new channels while keeping core systems stable.

Core information
  • API-led connectivity organizes integrations into three distinct layers—System, Process, and Experience APIs—each handling a specific stage of the data flow.
More details and nuances
  • Changes to a back-end system only require updates to its corresponding System API, leaving Process and Experience APIs completely unaffected.