Splunk Enterprise Certified Admin common mistakes
Splunk Enterprise Certified Admin · Understand the traps and how to avoid them.
Editing settings directly in $SPLUNK_HOME/etc/system/default/ or in an app's default/ directory and expecting the change to persist.
Candidates memorize setting names but not the configuration file precedence model. Files under default/ are overwritten during upgrades and are not meant for local changes, so edits appear to work until an upgrade or app update.
What to do instead
Place overrides in etc/system/local/ or in the app's local/ directory. Verify the effective value and which file supplies it with splunk btool list --debug, and remember precedence: system/local > app/local > app/default > system/default.
Assuming a universal forwarder can perform full parsing, field extraction, or event routing with props.conf/transforms.conf.
Candidates conflate forwarder types. The UF has a limited pipeline: it can do line breaking and basic input processing but does not run the full parsing pipeline or heavy regex transforms.
What to do instead
Send raw data from the UF and do parsing at the indexer or search head, or deploy a heavy forwarder when parsing, filtering, or routing must happen before indexing. Remember: UF forwards; heavy forwarder parses.
Believing indexing stops the moment license volume is exceeded, or ignoring license warnings until search is disabled.
The license behavior is counterintuitive: Splunk continues indexing during a violation, and search functionality is what gets restricted after the warning period. Candidates often study only the licensed volume number.
What to do instead
Monitor license usage proactively from the license manager and Monitoring Console, set alerts at 80–90% of quota, and know the difference between a warning period and enforcement. Check violations with the license usage report and _license index.
Assigning users directly to admin or another broad built-in role because a custom role's capabilities 'did not seem to work.'
Candidates do not account for role inheritance and the fact that a user with multiple roles receives the union of capabilities. A missing capability is usually a role-assignment or app-context problem, not a reason to grant admin.
What to do instead
Build least-privilege custom roles, assign them alongside (not instead of) any required base roles, and verify effective capabilities with Settings > Roles or | rest /services/authentication/users. Check that the role is assigned in the correct app context.
Configuring only frozenTimePeriodInSecs or only maxTotalDataSizeMB and then expecting buckets to roll exactly as planned.
Candidates memorize one retention setting. In practice either the age limit or the size limit can trigger bucket rolling, and disk pressure can force earlier freezing than the configured age.
What to do instead
Set both age and size retention values deliberately, understand homePath/coldPath/frozenPath and cold-to-frozen behavior, and validate with splunk list index and the index's bucket timeline.
Placing a [monitor://...] input stanza in an app on the indexer and expecting it to collect files from remote servers.
Candidates forget that inputs run wherever splunkd runs. An indexer monitor input only reads files local to that indexer; distributed data collection requires a forwarder on the source host.
What to do instead
Deploy inputs.conf to forwarders through a deployment server or forwarder app, and verify collection with splunk list monitor, splunk btool inputs list --debug, and the _internal index on the forwarder.
Putting outputs.conf on the indexer instead of the forwarder, or forgetting to enable receiving on the indexer with splunk enable listen 9997.
Candidates mix up the direction of the data pipeline. outputs.conf tells a forwarder where to send data; the indexer must have a receiving port enabled to accept it.
What to do instead
Configure outputs.conf on the forwarder, enable the receiver on the indexer, and test both sides with splunk list forward-server on the forwarder and splunk list tcpin on the indexer. Check splunkd.log for connection errors.
Searching the wrong internal index for operational data, such as looking in _audit for license usage or in _internal for user login history.
Candidates treat all internal indexes as interchangeable. _internal holds splunkd logs and metrics, _audit holds audited user actions, and _license holds license usage data.
What to do instead
Learn the purpose of _internal, _audit, _license, _introspection, and _metrics, and use the Monitoring Console for health checks rather than guessing an index. Validate with | eventcount or | metadata.
Installing an app only on the search head when it contains index-time props/transforms, then wondering why indexed fields are missing.
Candidates do not determine app scope before deployment. Index-time settings must be present on indexers, while search-time knowledge objects can live on search heads.
What to do instead
Classify the app's content: index-time configuration goes to indexers (or the cluster bundle), search-time configuration to search heads. Use the cluster master bundle or search head deployer, and restart as required.
Setting replication_factor higher than the number of indexers, or search_factor higher than replication_factor, in an indexer cluster.
Candidates memorize the terms but not the constraints. A cluster cannot create more replicas than peers, and it cannot create more searchable copies than replicas.
What to do instead
Plan capacity first: replication_factor must not exceed the number of peers, and search_factor must not exceed replication_factor. In multisite clusters, also account for site_replication_factor and site_search_factor before enabling the cluster.