Structuring Mule Applications10% of the exam
Configuration files, properties and placeholders
How Mule 4 loads several XML configuration files into one context, resolves `${}` placeholders from YAML, .properties, secure and whole-file sources, decides which same-named property wins, picks an environment file at deployment, and shares resources through an on-premises domain.
Specify when and how to structure Mule applications into separate configuration and properties files, and predict outcomes.
~8 min read · 17 practice questions ·
What the exam expects
- Split one application into several XML configuration files (side by side or imported) and predict what happens when two files declare the same global element name.
- Load
.yamlor.propertiesfiles, write a nested-key placeholder, escape one, and chooseMule::p()or${file::...}when a plain placeholder is wrong. - Predict which value wins when a property is defined in several files or several sources, and set an environment-specific file per deployment on premises, in Studio and on CloudHub.
- Read encrypted values with Secure Configuration Properties and share connector configurations between on-premises apps with a Mule domain.
- Key terms: configuration properties (key-value strings loaded by
<configuration-properties>); global property (a<global-property>default, the lowest-precedence source); system property (a JVM-Dvalue set when Mule starts); secure properties (decrypted values read withsecure::); Mule domain (an on-premises project whosemule-domain-config.xmlholds resources shared by its apps).
Key facts
Duplicate global element names across files
- Detail
- The application does not load
Properties file location
- Detail
src/main/resources, or an absolute path
Same key in two loaded files
- Detail
- The first definition is preserved
\${x}- Detail
- Returns the literal string
${x}
${file::name}- Detail
- Whole file content becomes the string value
Precedence, top to bottom
- Detail
- Deployment, system, environment, application, global
Global default for
env- Detail
- Required for Studio metadata resolution
Dynamic
import file name- Detail
- Needs a system or environment property, not a global one
CloudHub
env value- Detail
- Properties tab in Deploy to Cloud, or in Runtime Manager Settings
Secure value reference
- Detail
${secure::key}; key supplied at runtime asruntime.property
Domains
- Detail
- One domain per app; on premises; no shared flows or subflows
Sources for this section (6)
- Modularize Configuration Filesdocs.mulesoft.com (opens in a new tab)
- Configuring Propertiesdocs.mulesoft.com (opens in a new tab)
- Mule Configuration Filedocs.mulesoft.com (opens in a new tab)
- Configuring Environment Propertiesdocs.mulesoft.com (opens in a new tab)
- Secure Configuration Propertiesdocs.mulesoft.com (opens in a new tab)
- Shared Resources (Mule Domains)docs.mulesoft.com (opens in a new tab)
- Why does a value read from a
.yamlor.propertiesfile arrive as text, even when it looks like a number? - When is the
<secure-properties:encrypt>tag needed inside<secure-properties:config>? - Which three kinds of input can
Mule::p("name")read? - How do you set a system property for a run inside Studio?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the MuleSoft Developer pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 40 lessons of the MuleSoft Developer guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Practice exams purchase adds inline bank questions and topic practice (17 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams