Cert++
  1. Home
  3. MuleSoft Developer II

MuleSoft Developer II

Checklist progressProgress

0/166Learned

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
  • Marketing Cloud Account Engagement Specialist
  • Marketing Cloud Next Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Communications AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • Public Sector Solutions AP
  • Revenue Cloud Consultant
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Next Consultant
  • Tableau Architect
  • Slack Administrator
  • Slack Consultant
  • Slack Developer

Checklist progressProgress

0/166Learned

  • Exchange asset version versus API version for API specifications
  • Major, minor and patch increments for API specification changes
  • API major version in the implementation base URI
  • API specification version as a Maven dependency of the Mule project
  • Changing the asset version of a managed API instance in API Manager
  • Upgrading an applied policy's definition and implementation versions
  • Policy enforcement requirements and runtime injection for a Mule API implementation
  • Choosing an included Mule Gateway policy for a stated requirement
  • SLA tiers with the SLA-based rate limiting policy
  • OAuth 2.0 access token enforcement policy configuration
  • Exposing validated OAuth token data to the backend and the Mule flow
  • Resource-level policies for specific methods and resource paths
  • Automated policies versus policies applied to a single API instance
  • Execution order of multiple policies on one API instance
  • Online versus offline custom policies
  • Server-side API response caching with the HTTP Caching policy
  • Object Store caching pattern inside a custom policy template
  • Custom policy caches on Object Store v2 and sharing across API instances
  • Asynchronous request with HTTP callback in a Mule API implementation
  • API Autodiscovery element configuration in a Mule 4 application
  • Basic endpoint versus proxy endpoint for Mule Gateway API instances
  • Anypoint Platform organization credentials for autodiscovery by deployment target
  • Setup sequence for pairing a Mule application with API Manager
  • Environment-specific API instance IDs for autodiscovery
  • Autodiscovery pairing status and gatekeeper behaviour at startup

Modularize and optimize Mule application Maven build configurations

0/8

  • Mule application project structure required for packaging
  • mule-artifact.json descriptor fields and minMuleVersion compatibility
  • Mule project packaging types and artifact classifiers
  • Mule Maven plugin package goal and packaging options
  • Repository and server credential setup across pom.xml and settings.xml
  • Centralizing connector and dependency versions in a shared parent POM
  • Shared libraries versus additional plugin dependencies in the Mule Maven plugin
  • SNAPSHOT versus release versions for reproducible Mule builds

Implement Maven-based automated deployment to Mule runtimes

0/9

  • Mule Maven plugin declaration and deployment execution controls
  • Mule Maven plugin goals and deployment commands
  • CloudHub deployment strategy configuration in pom.xml
  • CloudHub 2.0 deployment with the Mule Maven plugin
  • Standalone versus Runtime Manager REST API versus agent deployment
  • Authentication methods for Maven-based deployments
  • Mule runtime version, release channel and Java version in deployment config
  • Supplying application properties at deployment time through the plugin
  • Maven lifecycle sequence in an automated Mule deployment pipeline

Execute MUnit tests with Maven

0/6

MUnit Maven plugin and test dependency setup in pom.xml

Learn this concept
Unseen

Selecting and skipping MUnit tests from the Maven command line

Learn this concept
Unseen

MUnit Maven run environment: properties, dynamic ports and runtime version

Learn this concept
Unseen

MUnit coverage and test result reports from Maven runs

Learn this concept
Unseen

Enforcing minimum MUnit coverage levels in a Maven build

Learn this concept
Unseen

Parent POM pluginManagement inheritance for the MUnit Maven plugin

Learn this concept
Unseen

Build custom API policies

0/8

  • Custom policy development and delivery lifecycle
  • Scaffolding a custom policy project with the Maven archetype
  • Custom policy project files and their roles
  • Policy template XML with proxy, source and execute-next
  • Execution order of multiple policies around a flow
  • Outbound policies with the http-policy:operation block
  • Packaging and publishing a custom policy to Exchange with Maven
  • Extending custom policies with Mule plugins and custom code

Encapsulate common Mule application functionality in libraries

0/6

  • Packaging common Mule flows and global elements as a mule-plugin library
  • Exporting resources and packages from a Mule artifact
  • Publishing a shared library to Exchange with the Mule Maven plugin
  • Consuming a common library: dependency declaration and configuration import
  • Shared library changes: per-app property override versus new library version
  • Common library versus Mule domain for sharing configuration

Implement custom message processors using the Mule SDK or XML SDK

0/7

  • Java Mule SDK versus XML SDK for a custom message processor
  • XML SDK module and operation definition
  • XML SDK operation parameters versus module properties
  • Mule SDK for Java project generation and build
  • Choosing a Mule SDK component type: operations, sources, routers, functions
  • Java SDK extension model annotations for operation classes and injected arguments
  • Adding a custom SDK module to a Mule application
  • Custom health check flow in a Mule application
  • CloudHub health monitoring and automatic restarts
  • Application logs versus runtime log and log4j2.xml configuration scope
  • Application log4j2.xml appenders, rolling files and pattern layouts
  • Logger component categories mapped to log4j2 loggers
  • Asynchronous versus synchronous logging in Mule applications
  • Performance-aware logging practices for production Mule apps
  • Log levels and package categories in log4j2.xml
  • Changing log levels from Runtime Manager for deployed apps
  • Anypoint Monitoring Log Points for logging without redeployment
  • Runtime Manager app logs versus Anypoint Monitoring log management
  • Anypoint Monitoring log search queries and filters
  • External log aggregation with Log4j appenders on CloudHub 2.0, Runtime Fabric and hybrid
  • Custom Log4j logging on CloudHub 1.0 while keeping Runtime Manager logs
  • Enabling Anypoint Monitoring for CloudHub, CloudHub 2.0 and Runtime Fabric apps
  • Anypoint Monitoring agent setup for hybrid Mule servers and clusters
  • Built-in dashboards, custom dashboards and Anypoint Insights for app metrics
  • Inbound endpoint path normalization in monitoring dashboards
  • Runtime Manager alerts versus Anypoint Monitoring alerts
  • API Functional Monitoring for scheduled endpoint testing
  • Runtime Manager agent publishers for external monitoring tools
  • Correlation ID sourcing for events arriving over HTTP
  • Custom correlation ID generator configuration
  • Propagating correlation IDs on outbound HTTP requests
  • Correlation IDs and MDC logging variables in log output
  • Tracing module With CorrelationID scope
  • Persisting correlation IDs across asynchronous and messaging boundaries
  • Persistent versus transient object store configuration
  • Object store persistence on standalone on-premises runtimes
  • Object store data in on-premises Mule clusters
  • Object Store v2 persistence for CloudHub deployments
  • Mule Maven plugin settings for persistent object storage
  • Object Store v2 TTL settings and service limits
  • Persistence Gateway for Runtime Fabric object stores
  • VM publish, publish-consume, consume and listener operations
  • VM transient versus persistent queues across deployment targets
  • Reliable acquisition pattern with a transactional VM listener
  • Sharing VM queues between applications in a Mule domain
  • Anypoint MQ standard versus FIFO queues for ordering and delivery
  • Anypoint MQ acknowledgement modes and ACK and NACK operations
  • Anypoint MQ redelivery limits and dead-letter queues
  • Anypoint MQ subscriber prefetch and polling settings for throughput
  • Anypoint MQ payload size limits and message serialization
  • Anypoint MQ cross-region failover with fallback queues
  • Correlation ID propagation across VM and Anypoint MQ queues
  • Response validators and success status codes on the HTTP Request operation
  • Response timeout configuration for HTTP requests
  • Handling backend HTTP error types and setting the API's response status
  • Reconnection strategy versus Until Successful for HTTP failures
  • Until Successful retries for transient versus permanent HTTP failures
  • Choosing Validation module operations for runtime message assertions
  • Validation failure error types and custom failure messages
  • Error mappings and error handlers for failed validations in an API flow
  • Validation module All scope versus chained individual validators
  • JSON module Validate schema operation configuration
  • XML module Validate schema operation against XSD documents
  • Handling schema validation failures and reading violation details
  • Resolving referenced schemas locally during validation
  • When to use scatter-gather versus Parallel For Each or sequential calls
  • Scatter-gather aggregated result structure and payload extraction
  • Variable propagation across scatter-gather routes
  • Configuring scatter-gather timeout, maxConcurrency and target variables
  • Scatter-gather with repeatable versus non-repeatable streams
  • Scatter-gather execution inside a transaction
  • Reading route results and failures from a composite routing error
  • Route-level Try scope handling versus flow-level composite routing handling
  • Compensating completed scatter-gather routes after a partial failure
  • Scatter-gather route timeouts in partial-failure handling
  • Cache scope with an object-store caching strategy
  • Cache key generation for cached API invocation responses
  • Cache scope filter expressions and cache invalidation
  • Cache storage and synchronized access across Mule workers
  • Client-side Cache scope versus server-side HTTP Caching policy
  • Environment-specific property files selected by an env property
  • Secure Properties module configuration and secure property references
  • Encrypting values with the Secure Properties Tool
  • Supplying the secure properties decryption key at deployment time
  • Safely hidden application properties versus encrypted secure properties
  • Protecting property values on CloudHub 2.0 and Runtime Fabric
  • Property override precedence across Runtime Manager, system and bundled properties
  • Asymmetric encryption, certificate authorities and PKI trust services
  • Generating a Mule server keystore with keytool
  • Self-signed versus CA-signed certificates and certificate signing requests
  • Distributing public certificates and building peer truststores
  • Keystore and truststore packaging and TLS store attributes
  • HTTPS listener configuration with a TLS context keystore
  • HTTPS listener ports and last-mile TLS by deployment target
  • HTTPS request configuration and server certificate trust
  • TLS protocol versions and cipher suites in Mule TLS contexts
  • One-way TLS versus mutual TLS store requirements
  • Server-side mutual TLS on an HTTPS Listener configuration
  • Client-side mutual TLS on an HTTP Request configuration
  • HTTP Request Basic authentication configuration
  • Enforcing Basic authentication on an HTTP Listener with the Basic Security Filter
  • OAuth2 client credentials grant on the HTTP Request connector
  • OAuth2 authorization code grant for HTTP Request and connector configurations
  • REST Connect connector authentication from API specification security schemes

Prepare for the Exam

Play Today's Certle

Study Community

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

Go to Discord
  1. MuleSoft Developer II Checklist
  3. Implement maintainable and modular Mule applications and their Maven builds

Parent POM pluginManagement inheritance for the MUnit Maven plugin

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 166 concepts on the Salesforce MuleSoft Developer II exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptCustom policy development and delivery lifecycle

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

Study Community

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

Go to Discord
Close
  1. MuleSoft Developer II Checklist
  3. Implement maintainable and modular Mule applications and their Maven builds
Parent POM pluginManagement inheritance for the MUnit Maven plugin

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 166 concepts on the Salesforce MuleSoft Developer II exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptCustom policy development and delivery lifecycle

Explainer

The MUnit Maven plugin runs MUnit tests as part of a Maven build, for example in a continuous integration environment. When several Mule projects share one parent POM, you can declare the plugin once in the parent's <pluginManagement> section. Each child project can then inherit, override, or ignore that shared definition.
Core information
  • To share the MUnit Maven plugin across projects, put its declaration in the <pluginManagement> section (inside <build>) of the parent pom.xml. Every child project under that parent can then reference this one definition instead of repeating it.
More details and nuances
  • Declaring the plugin in the parent's <pluginManagement> does not apply it to children by itself. Each child must reference the plugin in its own <plugin> section, and a child that does not declare the MUnit plugin there does not inherit the plugin from the parent.

Explainer

The MUnit Maven plugin runs MUnit tests as part of a Maven build, for example in a continuous integration environment. When several Mule projects share one parent POM, you can declare the plugin once in the parent's <pluginManagement> section. Each child project can then inherit, override, or ignore that shared definition.
Core information
  • To share the MUnit Maven plugin across projects, put its declaration in the <pluginManagement> section (inside <build>) of the parent pom.xml. Every child project under that parent can then reference this one definition instead of repeating it.
More details and nuances
  • Declaring the plugin in the parent's <pluginManagement> does not apply it to children by itself. Each child must reference the plugin in its own <plugin> section, and a child that does not declare the MUnit plugin there does not inherit the plugin from the parent.