• Cert++
  • Practice
  • Certle
  • Review
  • Tracks
  • Checklist
  • Guides
  • Upgrade
Cert++
  1. Home
  3. MuleSoft Developer II

MuleSoft Developer II

Checklist progress

0/93Learned

MuleSoft Developer II

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/93Learned

Implement versioning of specific API-related artifacts

0/3

  • Distinguish the Exchange API specification asset version from the API instance/version registered in API Manager, and identify which artifact a given version number applies to.
  • Given a requirement to run two incompatible API versions simultaneously, identify that the public version should be represented in the URI base path (e.g. /api/v2) and registered as a separate API instance in API Manager rather than overwriting the existing version.
  • Identify how Exchange dependency versioning and asset deprecation/promotion let API consumers pin to a specific spec version while the publisher continues to evolve newer versions.

Configure custom or out-of-the-box (OOTB) API policies

0/9

Given a non-functional requirement (throttle traffic, block bursts, enforce registered apps, validate tokens), select the correct OOTB API policy: rate-limiting, spike control, client ID enforcement, or JWT validation.

Learn this concept
Unseen

Identify that client ID enforcement requires consumers to send valid client_id/client_secret credentials obtained by requesting access to the API in Exchange/API Manager.

Learn this concept
Unseen

Identify that client ID enforcement is typically paired with an SLA tier and a rate-limiting-SLA policy to enforce contracted throughput per consumer.

Learn this concept
Unseen

Given multiple policies applied to one API, explain how policy ordering/priority determines execution sequence and configure the order so that, for example, authentication runs before rate-limiting.

Learn this concept
Unseen

Identify how API policies can be applied at the automated-policy/environment level versus per individual API instance.

Learn this concept
Unseen

Given a header manipulation or simple transformation requirement at the gateway, identify the header injection/removal OOTB policy as the correct mechanism rather than modifying the Mule flow.

Learn this concept
Unseen

Given a browser-based client failing cross-origin requests, identify the OOTB CORS policy (and its allowed origins/methods/headers configuration) as the correct gateway mechanism rather than hand-coding CORS headers in the flow.

Learn this concept
Unseen

Distinguish JWT Validation from OpenID Connect / OAuth 2.0 access-token enforcement (external token introspection) and choose the correct policy for a stated identity-provider scenario.

Learn this concept
Unseen

Identify the IP allowlist/blocklist OOTB policy and recognize which network-access requirement it addresses.

Learn this concept
Unseen

Implement server-side caching of API invocations using API policies

0/3

  • Given a requirement to reduce backend load for repeated identical GET requests at the gateway, identify the HTTP Caching API policy as the correct server-side caching mechanism.
  • Given a caching misconfiguration, recognize how a poorly chosen cache key can serve stale or cross-user responses.
  • Configure HTTP Caching policy TTL/expiration and an invalidation or distributed-cache strategy.

Code API implementations to perform API auto-discovery

0/4

  • Given a requirement to enforce API Manager policies on a deployed Mule app WITHOUT an API proxy, identify that API auto-discovery (the api-gateway Autodiscovery element binding the app to an API instance) is required, not an API proxy.
  • Identify the required auto-discovery configuration elements apiId (the API instance ID from API Manager) and flowRef pointing to the main HTTP Listener flow.
  • Identify that Anypoint Platform credentials or a connected app must be supplied to the runtime so an auto-discovered app can register itself with API Manager.
  • Given symptoms that policies are not being enforced on an auto-discovered app, diagnose common causes (wrong/missing apiId, missing platform credentials, flowRef not pointing at the Listener flow, mismatched environment) and select the fix.
  • Given several Mule projects sharing common dependencies and plugin configuration, identify how a parent POM and dependencyManagement/BOM centralize and align versions to avoid duplication and version drift.
  • Identify the role of the Mule Maven Plugin in validating, packaging, and producing a deployable Mule application archive.
  • Identify how to configure the Anypoint Exchange Maven repository and credentials (in settings.xml, not hardcoded in the POM) so a build can resolve and publish private organization assets.
  • Given a CI/CD requirement to deploy automatically to CloudHub, RTF, or a standalone runtime, identify the Mule Maven Plugin deployment goal and the correct deployment configuration block for that target.
  • Given a POM that hardcodes Anypoint credentials, identify the security defect and select the correct fix: reference a Maven settings.xml server entry or connected-app/environment variables instead of plaintext credentials.
  • Identify the CloudHub-specific deployment parameters required by the Mule Maven Plugin (worker size, worker count, region, and target name).
  • Identify the Runtime Fabric (RTF) deployment parameters required by the Mule Maven Plugin (target and provider).
  • Identify how environment-specific runtime properties and secure property keys are passed at deploy time through the Mule Maven Plugin (properties/secureProperties) rather than baked into the artifact.
  • Identify that deployment is triggered by binding the Mule Maven Plugin deploy goal to the deploy phase and running it with the -DmuleDeploy flag (mvn deploy -DmuleDeploy), and distinguish this from a plain mvn deploy that only publishes the artifact to a Maven repository/Exchange.
  • Identify that the MUnit Maven Plugin runs MUnit tests during the build's test phase and that a failing assertion or unmet coverage threshold should fail the build in CI.
  • Given a requirement to enforce a minimum test coverage in CI, configure the MUnit Maven Plugin coverage settings (requiredApplicationCoverage / failBuild) to gate the build.
  • Identify how to skip or selectively run MUnit tests in a Maven build (e.g. -DskipMunitTests, -Dmunit.test).
  • Identify why MUnit tests must mock, spy, or stub connectors so they run hermetically in CI without live external systems.
  • Identify the structure of a custom policy project: the mule-policy.xml (policy logic with before/after the protected resource), the policy YAML/definition declaring configurable properties, and the pom packaging as a mule-policy that is published to Exchange.
  • Distinguish a Mule domain project (shared configuration like HTTP listener connections/TLS shared across co-deployed apps on the same on-prem runtime) from a shared library/common module (reusable flows/connectors), and choose the right one for a stated reuse requirement.
  • Identify the limitation that Mule domains apply only to on-premises/standalone (shared-server) deployments and are not used to share connection config across separate CloudHub workers.
  • Given a requirement to add reusable Java-based logic exposed as a Mule operation, identify the Mule SDK (Java) with @Extension/@Operations and the correct annotations for parameters, configuration, and connection.
  • Distinguish the Mule SDK (Java) from the XML SDK (module operations defined entirely in XML by composing existing Mule components) and choose the appropriate one based on whether custom Java code is needed.
  • Given a production troubleshooting requirement, identify effective structured logging in Mule (Logger component, structured/JSON logs, including correlation IDs) over ad-hoc or excessive logging.
  • Identify how Mule uses Log4j2 (log4j2.xml) for appenders, pattern layouts, and async logging, and how to configure logging output for CloudHub versus on-prem.
  • Identify how to change log levels per logger or package in log4j2.xml or at runtime to increase diagnostic detail (e.g. DEBUG) without redeploying.
  • Identify the performance, storage, and security consequences of leaving verbose DEBUG logging enabled in production.
  • Given a requirement to centralize and search logs from many workers/apps, identify log aggregation approaches (Anypoint Monitoring log management, or forwarding to an external SIEM/ELK/Splunk via a Log4j2 appender) and their trade-offs.
  • Given a requirement to monitor throughput, response time, failures, and resource usage, identify the appropriate Anypoint Platform capability (Anypoint Monitoring dashboards/alerts, Runtime Manager metrics) versus external APM tools.
  • Identify what built-in metrics and custom metrics/alerts Anypoint Monitoring provides and how to configure alerts for conditions such as high error rate or CPU/memory thresholds.
  • Given a requirement to proactively detect availability/SLA breaches before users do, identify Anypoint Functional Monitoring (synthetic/scheduled probe monitors against endpoints) as distinct from passive metric dashboards, and recognize when each is appropriate.
  • Given a multi-hop integration that must be traceable end-to-end, identify how Mule's correlation ID is generated, carried on the event, and propagated downstream so all log entries for one transaction share an ID.
  • Identify how to propagate the Mule correlation ID downstream by passing it in an X-Correlation-ID (or equivalent) header on the HTTP Request connector.
  • Identify how to read or override the correlation ID from an inbound header on the HTTP Listener so the Mule event joins an external trace.
  • Identify how to persist/restore a correlation ID across asynchronous boundaries (queues, async scopes, ObjectStore) so correlation is not lost when processing resumes on a different thread or worker.
  • Distinguish a transient (in-memory) ObjectStore from a persistent ObjectStore and choose persistent storage when data must survive restarts or be shared across CloudHub workers.
  • Identify that on multi-worker CloudHub, in-memory/per-worker stores are not shared and that Object Store v2 (the platform-managed REST-backed store) is required to share state across workers.
  • Identify ObjectStore configuration options (entry TTL/expiration, max entries, persistent flag) and how they affect stored data across deployment models.
  • Identify the differences and limits of Object Store across deployment options (Object Store v2 for CloudHub with its API rate/throughput limits versus persistent stores on-prem/RTF) and choose appropriately for durability and scale.
  • Identify that Object Store v2 enforces a maximum TTL/retention (entries are not retained indefinitely) and how the expiration interval and entry-TTL settings interact, so a design relying on permanent persistence in OSv2 is incorrect.
  • Given a requirement for reliable in-app/cluster message handoff that must survive restarts, identify a persistent (and where needed transactional) VM queue rather than a transient VM queue.
  • Identify how VM connector transactions provide reliable once-and-only-once processing for queued messages.
  • Identify the Until Successful scope (with retry count/backoff) as the mechanism to retry a failed HTTP invocation and how it differs from connector reconnection strategies.
  • Identify how the HTTP Request connector's default failOnStatusCode behavior treats non-2xx responses as errors.
  • Identify HTTP connector error types (e.g. HTTP:BAD_REQUEST, HTTP:TIMEOUT, HTTP:CONNECTIVITY) so error handling can branch by failure category.
  • Given an unreliable downstream API, design a fault-tolerant invocation combining reconnection strategy, Until Successful retries with backoff, and a fallback or error handler.
  • Identify why unbounded HTTP retries or retrying non-idempotent calls without safeguards is a dangerous design.
  • Identify how to safely retry non-idempotent operations by introducing an idempotency key/Idempotent Message Validator (or de-duplication via ObjectStore) so a retried POST does not create duplicate side effects.
  • Given a requirement to enforce business rules and reject bad input early, identify the Validation module (is/isNot, all/any, isNotNull, isNumber, etc.) as the idiomatic way to assert conditions and raise VALIDATION errors.
  • Identify how the Validation module raises MULE:VALIDATION (and specific validation error types) and how 'all'/'any' validations aggregate multiple checks, plus how to supply custom error messages.
  • Given a requirement to reject payloads that do not conform to a contract, identify JSON Schema validation (JSON module) or XML schema (XSD) validation as the correct mechanism rather than manual DataWeave checks.
  • Given independent calls that can run concurrently to reduce latency, identify scatter-gather as the correct parallel router and recognize that For Each / sequential processing would be the wrong choice.
  • Identify how scatter-gather aggregates branch results into a key-indexed map of routes (each with payload/attributes) and that branch execution order is not guaranteed.
  • Identify that when any scatter-gather branch fails, a MULE:COMPOSITE_ROUTING error is raised that carries the results/failures of all branches, and how to inspect it to determine which branches succeeded.
  • Given a scatter-gather where some branches commit side effects and one fails, design a compensating-transaction handler that uses the COMPOSITE_ROUTING error to undo/roll back the successful branches' effects.
  • Given repeated expensive outbound calls whose results can be reused, identify the Cache scope (caching strategy backed by an ObjectStore) as the client-side caching mechanism and distinguish it from server-side HTTP Caching policy.
  • Identify how the Cache scope's caching strategy computes a cache key using the default key versus a custom keyGenerator expression.
  • Identify how Cache scope TTL, expiration, and ObjectStore backing are configured so cache hits skip the wrapped processors.
  • Given credentials/secrets that differ per environment and must not be stored in plaintext, identify the Mule Secure Configuration Properties module with per-environment encrypted property files as the correct mechanism.
  • Identify how the Secure Configuration Properties decryption master key is supplied at deploy/runtime (e.g. -M-Dkey=... or encrypt.key via the Mule Maven Plugin) and must never be committed with the artifact.
  • Identify the ${secure::propertyName} reference syntax for reading decrypted secure properties in Mule configuration.
  • Identify the supported Secure Configuration Properties encryption algorithms and modes (e.g. Blowfish/AES with CBC).
  • Identify how environment-specific secure property files (e.g. config-dev.yaml, config-prod.yaml) are selected via the mule.env property.
  • Distinguish a keystore (holds the entity's private key and certificate, presented to prove identity) from a truststore (holds trusted CA/peer certificates used to validate the other party) and choose the correct one for a server vs client role.
  • Distinguish JKS versus PKCS12 keystore formats and identify when each is appropriate for a Mule TLS configuration.
  • Identify how keytool is used to generate keypairs/CSRs and import CA-signed certificates into a keystore for Mule.
  • Identify how certificates and keystores are packaged with or securely supplied to a Mule application at deployment time.
  • Identify secure practices for distributing keys/certificates across environments (protecting keystore passwords as secure properties, rotating certs, not committing private keys) for a production deployment.
  • Given a requirement to expose an API over HTTPS, identify that the HTTP Listener must use protocol HTTPS with a TLS context referencing a keystore containing the server's certificate and private key.
  • Given a requirement to invoke an external HTTPS API whose certificate is signed by a private/internal CA, identify that the HTTP Request connector needs a TLS context truststore containing that CA certificate to validate the server.
  • Identify how a global TLS context is defined once and shared between HTTP Listener and HTTP Request connectors.
  • Identify how enabledProtocols and cipher suites are restricted in a TLS context for a hardened HTTPS configuration.
  • Identify that enabling the TLS context 'insecure' flag (or otherwise disabling trust validation) bypasses certificate verification and is an unsafe production practice, versus correctly importing the server/CA certificate into a truststore.
  • Distinguish one-way TLS (only the server presents a certificate) from mutual TLS/mTLS (both client and server present and validate certificates) and choose mTLS when the requirement is to authenticate the client by certificate.
  • Identify the server-side mTLS configuration (Listener TLS context with a keystore for its identity plus a truststore of trusted client CAs, and enabling client authentication 'required') to enforce client certificate validation.
  • Identify the client-side mTLS configuration (Requester TLS context with a keystore holding the client's certificate/key plus a truststore for the server's CA) so the Mule app can present a client cert to a server requiring mTLS.
  • Given an outbound call to an API protected by HTTP Basic Auth, identify how to configure Basic authentication on the HTTP Request connector (username/password supplied via secure properties, not hardcoded).
  • Distinguish the OAuth2 client credentials grant (machine-to-machine) from the authorization code grant (on behalf of a user) and choose the correct grant for a stated outbound integration scenario.
  • Identify how the HTTP connector OAuth module is configured with token URL, client id/secret, and scopes to obtain access tokens.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other MuleSoft Developer II studiers. 593 members and growing.

Go to Discord

Identify the IP allowlist/blocklist OOTB policy and recognize which network-access requirement it addresses.

Explainer

Learn More

Practice Question

Keep going

Next conceptGiven a requirement to reduce backend load for repeated identical GET requests at the gateway, identify the HTTP Caching API policy as the correct server-side caching mechanism.

Checklist progress

0/93 (0%)

0 of 93 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 Developer II studiers. 593 members and growing.

Go to Discord

Explainer

The IP allowlist and blocklist policies are out-of-the-box API Manager tools that address network-access requirements by filtering traffic based on source IP addresses. They exist to enforce security boundaries that restrict API consumption to trusted networks or block known untrusted sources.

Core information
  • These policies operate at the API gateway to evaluate inbound requests against configured IP rules before the traffic reaches your Mule application.
More details and nuances
  • During CloudHub to CloudHub 2.0 migrations, the IP allowlist and blocklist policies do not rely on internal status, ensuring their enforcement behavior remains consistent without requiring cache resets.