Splunk Enterprise Certified Admin: Configuration Files

The precedence ladder

Splunk merges configuration stanza by stanza and key by key, never file by file. From lowest to highest precedence: etc/system/default → etc/apps/*/default → etc/system/local → etc/apps/*/local → etc/users/*/local (user context only). A key set in a higher-precedence file wins; keys that appear only lower down still apply, which is why partial overrides work.

Never edit default

default/ ships with Splunk or with an app and is overwritten on upgrade. Put changes in local/: system/local for global settings, <app>/local for app-scoped ones. Object sharing and permissions live in metadata/default.meta and metadata/local.meta, not in the .conf files themselves.

Verify with btool

splunk btool props list --debug prints the effective configuration and the file each value came from. This is the single most useful diagnostic and a frequent exam answer whenever a setting appears to be ignored.

Traps

• Editing a default file, or placing parsing config on the wrong tier.
• Assuming user-level settings are global - they apply only inside that user's context.
• Expecting instant effect: most conf files reload automatically, a few need splunk reload or a restart, and forwarders only pick up changes on their next deployment poll.
• Assuming file order resolves conflicts - precedence is driven by directory, then app ordering.

Rule of thumb

When in doubt, btool it. Confirm which file is winning before changing anything, then write the change into local/ so it survives upgrades.