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
  • 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
  • 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
  • MUnit Maven plugin and test dependency setup in pom.xml
  • Selecting and skipping MUnit tests from the Maven command line
  • MUnit Maven run environment: properties, dynamic ports and runtime version
  • MUnit coverage and test result reports from Maven runs
  • Enforcing minimum MUnit coverage levels in a Maven build
  • Parent POM pluginManagement inheritance for the MUnit Maven plugin
  • 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
  • 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
  • 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

Implement secure, environment-dependent properties management

0/7

  • 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

Create, package, and distribute keys and certificates

0/5

  • 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

Expose and invoke APIs over HTTPS

0/4

  • 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

Implement transport layer security (TLS) mutual authentication on the client and server side

0/3

  • 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

Implement API invocations authenticated by Basic Auth or OAuth2 with HTTP or REST connectors

0/5

HTTP Request Basic authentication configuration

Learn this concept
Unseen

Enforcing Basic authentication on an HTTP Listener with the Basic Security Filter

Learn this concept
Unseen

OAuth2 client credentials grant on the HTTP Request connector

Learn this concept
Unseen

OAuth2 authorization code grant for HTTP Request and connector configurations

Learn this concept
Unseen

REST Connect connector authentication from API specification security schemes

Learn this concept
Unseen

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. Secure data at rest and in transit

Enforcing Basic authentication on an HTTP Listener with the Basic Security Filter

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 conceptOAuth2 client credentials grant on the HTTP Request connector

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. Secure data at rest and in transit
Enforcing Basic authentication on an HTTP Listener with the Basic Security Filter

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 conceptOAuth2 client credentials grant on the HTTP Request connector

Explainer

The Basic Security Filter is an HTTP Connector operation that makes a Mule flow check a username and password before the rest of the flow runs. You place it right after an HTTP Listener and point it at one or more security providers, such as a Spring Security authentication manager, which it uses to authenticate the caller.
Core information
  • The Basic Security Filter (http:basic-security-filter in XML) is an operation of the HTTP Connector that enforces basic authentication. It validates the username and password sent in the request headers, so only authorized users reach the protected API.
More details and nuances
  • Providers can be listed two ways: as nested http:security-providers and http:security-provider elements, or as a securityProviders attribute that holds an expression list. The list refers to providers by the name given in the security manager. For example, a delegate-security-provider named ldap-provider is used with <http:basic-security-filter securityProviders="#[['ldap-provider']]" realm="mule-realm"/>.

Explainer

The Basic Security Filter is an HTTP Connector operation that makes a Mule flow check a username and password before the rest of the flow runs. You place it right after an HTTP Listener and point it at one or more security providers, such as a Spring Security authentication manager, which it uses to authenticate the caller.
Core information
  • The Basic Security Filter (http:basic-security-filter in XML) is an operation of the HTTP Connector that enforces basic authentication. It validates the username and password sent in the request headers, so only authorized users reach the protected API.
More details and nuances
  • Providers can be listed two ways: as nested http:security-providers and http:security-provider elements, or as a securityProviders attribute that holds an expression list. The list refers to providers by the name given in the security manager. For example, a delegate-security-provider named ldap-provider is used with <http:basic-security-filter securityProviders="#[['ldap-provider']]" realm="mule-realm"/>.