Select Two (Multi-Select) Questions

Collecting data from endpoints and forwarding it into the pipeline

Why it fails: Data collection from endpoints is performed by forwarders, which read files, listen on ports, or run scripts and then transmit events onward. Search heads consume already-indexed data for searching rather than gathering raw events from source systems, so this function does not belong to the search head tier.

Managing the license pool and issuing license warnings to peers

Why it fails: License management is handled by the license manager, which tracks daily indexing volume and enforces pool limits, while indexers report their usage to it. Search heads are license slaves in most topologies and do not administer the license pool or distribute violation warnings to other peers.

Storing raw event data in buckets on disk

Why it fails: Raw event storage in hot, warm, cold, and frozen buckets is the responsibility of indexers, which manage the index directories and retention lifecycle. Search heads do not persist the raw data they search, so assigning bucket storage to them misrepresents the tier separation in a distributed deployment.

bindDN

Why it fails: The bindDN is the distinguished name of the user that Splunk uses to bind to the LDAP server for searching. While often used, it is not strictly required if anonymous bind is allowed, and it is not directly involved in mapping groups to roles. The question asks for settings to authenticate users and map groups, so bindDN is not one of the two essential settings.

srvBaseDN

Why it fails: srvBaseDN is not a valid authentication.conf setting for LDAP. It might be confused with server-related settings, but it does not exist. The correct settings for LDAP are userBaseDN and groupBaseDN, among others like bindDN and userBaseFilter.

roleBaseDN

Why it fails: roleBaseDN is not a valid setting in authentication.conf. Role mapping is configured via groupBaseDN and roleMap, not by a roleBaseDN. This distractor might confuse those thinking of a separate base for roles, but roles are Splunk-side and not stored in LDAP.

Checking the /tmp directory for lock files.

Why it fails: Splunk writes no status lock files to /tmp; instance health is exposed through the splunkd port, CLI status commands and the monitoring console. It is tempting as a generic Unix habit, but /tmp inspection suits troubleshooting stale sockets, not confirming Splunk service state.

Reading the indexer cluster's raw binary data.

Why it fails: Indexer cluster buckets are compressed journal and rawdata archives, not a status interface; reading them yields no health signal. It is tempting because cluster data lives there, but direct bucket access suits disaster recovery or bucket repair, not routine instance monitoring.

Pinging the forwarder's local web port.

Why it fails: Universal forwarders run no local web port by default; their management port is 8089 and they push data outbound, so a ping proves nothing about Splunk status. It is tempting as a generic reachability check, but port pinging suits testing network connectivity to a listening service.

props.conf

Why it fails: props.conf sets parsing rules such as line breaking and timestamp recognition, which the indexer applies; a Universal Forwarder needs inputs.conf to select data and outputs.conf to reach the indexer. props.conf would be correct on a heavy forwarder or indexer performing parsing, but it does not establish the forwarding path.

indexes.conf

Why it fails: indexes.conf defines index storage, retention and paths on indexers, and a Universal Forwarder holds no index storage, so it cannot route data to an indexer. It would be correct when sizing or configuring indexes on the indexer itself; forwarding instead requires inputs.conf for data selection and outputs.conf for the destination.

web.conf

Why it fails: web.conf configures Splunk Web's UI settings on search heads, and the Universal Forwarder runs no web interface, so it cannot affect data delivery to the indexer. It would be correct when customising a search head's web experience, but forwarding requires outputs.conf to define the target indexer and inputs.conf to define what to send.

Editing outputs.conf

Why it fails: outputs.conf defines where a forwarder sends data — target indexers, load balancing and SSL settings — not which files, ports or scripts it collects. It is tempting because it is a genuine forwarder configuration file, and editing it is correct when the requirement is routing or securing outbound data, not defining inputs.

Using the Indexer UI web interface

Why it fails: A Universal Forwarder ships without the full Splunk web interface, so no Indexer UI exists to configure its inputs; that UI belongs to indexers and search heads. It is tempting because indexers do accept input configuration through their own UI, but forwarders are configured via files or the CLI.

Using the License Master API

Why it fails: The License Master API manages licence allocation and usage reporting across a Splunk deployment; it has no mechanism for defining inputs on a forwarder. It is tempting because Splunk does expose REST endpoints for many administrative tasks, and those endpoints are the right tool when the goal is querying or adjusting licensing.

The bucket is locked by a search head.

Why it fails: A search head lock prevents the bucket from being rolled or frozen while a search holds it, and the lock is released afterwards; freezing is driven by the bucket's age exceeding frozenTimePeriodInSecs or by disk pressure. Locking is a transient search-time condition, not a lifecycle trigger.

The index reaches maxHotBuckets.

Why it fails: MaxHotBuckets triggers a roll from hot to warm, not freezing; freezing occurs when the bucket's newest data ages past frozenTimePeriodInSecs or when indexer disk usage forces eviction. It is tempting because hot bucket limits do govern bucket lifecycle transitions, but they stop at the warm stage.

The license master is unreachable.

Why it fails: License master unavailability affects indexing volume enforcement and search warnings, not bucket lifecycle; buckets freeze when their data ages past frozenTimePeriodInSecs or when the indexer's disk usage exceeds the threshold. Licensing is tempting because it governs ingestion, but it never moves buckets between states.

It can only forward data to one indexer at a time.

Why it fails: A Universal Forwarder can be configured with multiple outputs to send data to several indexers or indexer clusters simultaneously, so the one-indexer limit is false. It is tempting because a single forwarder often points at one receiving indexer in small deployments, where that topology genuinely applies.

It requires a full Splunk Enterprise license.

Why it fails: Universal Forwarders require no Splunk Enterprise licence; they are free to deploy and only need a licence on the receiving indexers. It is tempting because full Splunk Enterprise instances do consume licence volume, so learners assume forwarding software carries the same licensing obligation.

It performs full data parsing and indexing.

Why it fails: The Universal Forwarder only collects and forwards raw data; parsing and indexing happen on the indexer, so it cannot perform them. It is tempting because heavy forwarders can parse at source, and that capability is what you would choose when you need to filter or route events before transmission.

Deployment Server

Why it fails: Data model acceleration is managed through the search head's data model configuration and the indexers that build and store the acceleration summaries; the deployment server distributes apps and configuration to forwarders, playing no role in summary creation. It is tempting because it pushes configurations, but acceleration summaries are built by indexers, not deployed by it.

License Master

Why it fails: The licence master tracks licence usage and violations; it does not build, store or manage data model acceleration summaries, which indexers create and search heads coordinate. It is tempting because licensing governs feature availability, but acceleration management is a search head and indexer responsibility, not a licensing function.

Heavy Forwarder

Why it fails: Data model acceleration summaries are built and maintained by indexers, with the search head managing the data model definitions; a heavy forwarder only routes and parses data before indexing, so it neither builds nor stores acceleration summaries. It is tempting because heavy forwarders handle parsing, but acceleration occurs after indexing.

coldPath.maxDataSizeMB = 512000

Why it fails: coldPath.maxDataSizeMB limits the cold bucket footprint under the cold path only. It does not cap the entire index at 500 GB because hot and warm buckets are excluded, and it does not delete data older than 90 days. This setting alone cannot satisfy either of the stated requirements.

homePath.maxDataSizeMB = 512000

Why it fails: homePath.maxDataSizeMB limits only the hot and warm bucket footprint under the index's home path. Cold buckets stored elsewhere are excluded, so total raw data could exceed 500 GB. It also does not enforce the 90-day age limit, leaving the age-based deletion requirement unmet.

maxDataSize = 512000

Why it fails: maxDataSize controls the size at which a single hot bucket rolls to warm, not the total index size. Setting it to 512000 MB would create impractically large buckets and would not cap the index at 500 GB. It also does not delete old data, so neither requirement is met by this setting.

License Forwarder

Why it fails: A licence forwarder does not exist in Splunk licensing; forwarders only send data, and licence usage is reported by indexers to the licence manager. It is tempting because forwarders are genuine Splunk components, and a licence manager is a valid licence configuration component, so the terms appear to combine plausibly.

License Alert Manager

Why it fails: License Alert Manager is not a Splunk component; alerting on licence usage is handled through the Monitoring Console or platform alerts, not a dedicated manager. It tempts because Splunk does surface licence warnings and violations, so a named alerting component sounds plausible. It would never be correct here, as no such component exists in a licence configuration.

It includes Splunk Enterprise features.

Why it fails: The Free licence runs a restricted subset of Enterprise functionality, disabling features such as authentication, distributed search and alerting. It is tempting because it is the same binary as Enterprise, yet in a scenario needing full Enterprise capability, a paid licence would be the correct choice.

It supports multiple user roles.

Why it fails: Free licence disables authentication entirely, so all users share one admin-level role; multiple roles cannot be configured. It is tempting because role-based access control is standard in licensed Splunk deployments, where defining several roles would indeed be the correct approach.

It supports distributed search.

Why it fails: Distributed search requires a paid licence; Free operates as a standalone instance only. It is tempting because distributed search is a headline Enterprise capability, and in a multi-indexer deployment with a paid licence it would be the correct architecture, but Free cannot enable it.

$SPLUNK_HOME/bin

Why it fails: Configuration files live under $SPLUNK_HOME/etc (system/default and apps), not the bin directory, which holds executables such as splunkd and the CLI. It is tempting because $SPLUNK_HOME/bin is a familiar path referenced when running Splunk commands, but it contains no .conf files to inspect.

$SPLUNK_HOME/var/run

Why it fails: $SPLUNK_HOME/var/run stores runtime state and process information, including the splunkd PID file, not configuration files. It is tempting as a sibling of etc under SPLUNK_HOME, and it is the correct location when checking whether splunkd is running or inspecting runtime artefacts.

$SPLUNK_HOME/var/log

Why it fails: $SPLUNK_HOME/var/log holds Splunk's own internal log files, such as splunkd.log, not configuration. It is tempting because troubleshooting often starts there, and it is the right place when diagnosing service errors, licence warnings or search failures rather than locating .conf settings.

Network cables.

Why it fails: Network cables are physical infrastructure, not searchable Splunk entities; Knowledge Objects are user-created artefacts such as saved searches, field extractions, lookups and tags. The term 'object' invites confusion with tangible hardware, and cables would be the correct answer only in a cabling or physical-topology question.

Hard drives.

Why it fails: Hard drives are physical storage hardware, whereas Splunk Knowledge Objects are configuration artefacts like saved searches, event types, lookups and field extractions. Calling hardware an 'object' makes this tempting, and a hard drive would be the right answer in a question about storage capacity or indexer hardware sizing.

server.conf

Why it fails: server.conf tunes cluster-wide behaviour such as indexer discovery and licence settings, not data ingestion or parsing. It is tempting because it governs how indexers and search heads communicate, which would be the right file when configuring replication or distributed search rather than sourcetype parsing.

indexes.conf

Why it fails: indexes.conf defines index storage paths, retention and sizing, not how incoming data is parsed. It is tempting because indexes are central to ingestion, and it would be correct when setting maxDataSize, frozenTimePeriodInSecs or per-index homePath rather than field extraction.

Browser type used for access

Why it fails: The Universal Forwarder is a headless daemon; browser type affects nothing because no browser interacts with it. It is tempting because browser compatibility matters for Splunk Web on search heads, where it would be the correct consideration, but forwarders expose no web interface.

The number of users logged in

Why it fails: Forwarder throughput is governed by inputs, parsing, and network bandwidth; interactive logins are irrelevant because the forwarder runs as a service independent of user sessions. It is tempting because concurrent users do affect search head load, where that factor would be the correct consideration.

Database Server

Why it fails: Splunk's standard architecture comprises indexers, search heads and forwarders; it stores data in its own indexed flat-file buckets rather than a relational database server. A database server is tempting because most log-analytics stacks pair a search tier with a SQL store, and it would be the right component in a conventional three-tier application architecture.

Web Server

Why it fails: Splunk includes a web server, but it is not a distinct architectural component.

[tcpout]

Why it fails: [tcpout] is a outputs.conf stanza, defining forwarding destinations for indexed data. indexes.conf stanzas name indexes and set their storage, retention and sizing parameters. An administrator configuring forwarder output groups would correctly edit outputs.conf, not indexes.conf.

[input]

Why it fails: [input] is not an indexes.conf stanza; it belongs in inputs.conf, where it defines data inputs. indexes.conf stanzas configure index storage, retention and volume settings, such as [default] or [myindex]. An administrator defining a file or network input would correctly place [input] in inputs.conf.

[source::...]

Why it fails: [source::...] is a props.conf stanza type, used to apply field extractions or line breaking to a matching source. indexes.conf accepts only index-name stanzas plus [default] and [volume:...]. Configuring per-source parsing behaviour belongs in props.conf, not indexes.conf.

[indexer_cluster]

Why it fails: inputs.conf holds data input stanzas; indexer clustering is configured in server.conf and indexes.conf, not inputs.conf. It is tempting because clustered indexers receive inputs, but cluster membership and replication settings belong to server.conf, so [indexer_cluster] is invalid here.

[index_retention]

Why it fails: inputs.conf defines data inputs such as [monitor://], [splunktcp://] and [script://] stanzas; index retention is configured in indexes.conf via frozenTimePeriodInSecs. It is tempting because retention sounds like an input-related setting, but it governs index lifecycle, which belongs to indexes.conf, not inputs.conf.

[search_head]

Why it fails: inputs.conf contains input stanzas; [search_head] is not one of them, as search head behaviour is governed by server.conf and distsearch.conf. It is tempting because search heads consume forwarded data, but their configuration lives in those files, not inputs.conf.

Delete the license pool.

Why it fails: Deleting a license pool removes the pool's allocation, which does not resolve a violation and can worsen it by leaving indexers unlicensed. It is tempting as cleanup of an unused pool, but violations are cleared by adding licence capacity or reducing indexed volume, not by deleting pools.

Restart the license master.

Why it fails: Restarting the license master does not change licence usage or allocation; the violation persists once indexing resumes. It is tempting because restarts often clear transient warnings, but a genuine violation reflects exceeded daily indexing volume, resolved by adding licence capacity or reducing ingest.

Reinstall Splunk on the indexers.

Why it fails: Reinstalling Splunk on indexers destroys configuration and indexed data without altering licence entitlement, so the violation remains. It is tempting as a heavy-handed reset, but violations stem from indexing volume exceeding the licence, resolved by adding capacity or reducing ingest.

Indexer discovery

Why it fails: Indexer discovery allows forwarders to dynamically discover indexers in a cluster. It does not affect the replication or searchability of buckets. It is related to data ingestion, not data replication. Therefore, it is not required to ensure that a copy of each bucket is available for search after an indexer failure.

Site replication

Why it fails: Site replication is used in multisite clustering to control how buckets are replicated across sites. It is not required to ensure searchability after a single indexer failure within a site. While it can provide additional resilience, it is not one of the two factors that directly control the number of copies and searchable copies.

Bucket rolling

Why it fails: Bucket rolling is the process of moving buckets from hot to warm to cold states based on size or time. It does not control replication or searchability. While it affects how data is stored, it does not ensure that multiple copies exist across indexers. Thus, it is not a factor for this requirement.