SPLK-2002 Practice Questions

Before installing complex, distributed Splunk components like indexer and search head clusters, defining the overall Splunk deployment topology is a vital prerequisite. The topology serves as the architectural blueprint, specifying the number of instances for each role (indexers, search heads, cluster manager, etc.), their interconnections, and the clustering strategy. This foundational plan dictates hardware requirements, network configuration, and the placement of components. Installing clusters without a defined topology would be inefficient and likely lead to significant rework, performance issues, and scalability problems.

A. Data source inventory is crucial for capacity planning but is an input to designing the topology, not the final architectural plan itself.

B. Data policy definitions (e.g., retention) are configured on the infrastructure after the topology has been designed and implemented.

D. Education and training plans are important for user adoption and operational success but are not a technical prerequisite for the installation process.

- Splunk Enterprise Documentation, Distributed Deployment Manual, "Plan a distributed deployment". (This section emphasizes that the first step is to decide on the components you need and the architecture that will connect them).

- Splunk Validated Architectures, "Splunk Validated Architectures Overview". (This guide stresses the importance of starting with a reference architecture/topology before deployment to ensure performance and scalability).

When troubleshooting why an app is not appearing on a deployment client, a systematic check of the configuration and logs is required. First, verify serverclass.conf on the deployment server to ensure the client is correctly targeted by the server class deploying the app. Second, check deploymentclient.conf on the client to confirm the targetUri is pointing to the correct deployment server. Third, examine the splunkd.log on both the client and the server for errors related to the "phone home" process, such as connection failures or authentication issues.

C: Apps intended for deployment must be placed in SPLUNKHOME/etc/deployment-apps/ on the deployment server, not SPLUNKHOME/etc/apps/. Checking the wrong directory is an incorrect troubleshooting step.

1. Splunk Enterprise Documentation, Updating Splunk Enterprise Instances, "Troubleshoot the deployment server". This guide outlines checking server classes, client configurations, and logs.

2. Splunk Enterprise Documentation, serverclass.conf specification file. This document explains how server classes map apps to clients.

3. Splunk Enterprise Documentation, deploymentclient.conf specification file. This document details client-side settings, including the targetUri.

To calculate the daily disk consumption per indexer in a cluster, several key factors are required. You must know the total daily indexing volume as the baseline. The replication factor (RF) is critical as it determines the total number of data copies stored across the cluster for availability. The search factor (SF) is also needed as it dictates how many of those copies are searchable, which can affect storage. Finally, to find the per indexer consumption, the total calculated storage must be divided by the number of peer nodes in the cluster.

A. The number of accelerated searches contributes to storage but is secondary to the core data replication determined by the RF.

C. The number of search heads is irrelevant to the storage calculations on the indexer tier.

D. This option omits the total daily indexing volume, which is the essential starting point for any storage calculation.

1. Splunk Enterprise Documentation, Managing Indexers and Clusters of Indexers, "Configure the replication factor". This section explains that RF determines the number of copies of each bucket, directly impacting total storage.

2. Splunk Enterprise Documentation, Capacity Planning Manual, "Storage". This manual details the formula for calculating total cluster storage, which includes daily data volume, replication factor, and the number of indexers.

3. Splunk Enterprise Documentation, Managing Indexers and Clusters of Indexers, "The basics of indexer cluster architecture". This document defines the roles of peer nodes, RF, and SF in a cluster.

To retire a site, you must tell the master where to send any bucket-level requests that still reference the old site. In server.conf [clusterconfig] you add the attribute sitemappings = :, mapping the decommissioned site to an active one.

B. availablesites lists all active sites but does not redirect a removed site.

C. sitesearchfactor defines search-time bucket copies, unrelated to decommissioning.

D. sitereplicationfactor defines data-time bucket copies, unrelated to decommissioning.

1. Splunk Enterprise 9.0 “Managing Indexers and Clusters of Indexers”, section “Decommission an indexer cluster site”, step 3 – server.conf setting sitemappings (PDF p. 266).

2. Splunk Enterprise 9.1 Admin Manual, server.conf spec – [clusterconfig]/sitemappings description.

The TailingProcessor is the Splunk component responsible for handling [monitor://] stanzas, which includes reading files and applying any regular expressions defined in the input configuration. If there is an issue interpreting a regex within a monitor stanza (e.g., in hostregex), the corresponding error messages will be logged specifically to tailingprocessor.log. While a critical error might also appear in splunkd.log, the tailingprocessor.log is the most direct and detailed source for troubleshooting these specific inputs.

A. btool.log shows the final, merged configuration settings from all .conf files but does not log runtime processing errors.

B. metrics.log records performance data and metrics about the Splunk instance, not configuration parsing or processing errors.

C. splunkd.log is the main process log; while it may contain the error, tailingprocessor.log is the specialized log for this component.

- Splunk Enterprise Documentation, Troubleshooting Manual, "What Splunk Enterprise logs". This section describes the purpose of various log files, identifying tailingprocessor.log for debugging issues with the Tailing Processor, which manages monitor inputs.

- Splunk Enterprise Documentation, Getting Data In, "Monitor files and directories with the CLI", Section: "How Splunk software monitors files". This section describes the role of the Tailing Processor.

The command splunk clean kvstore is the officially documented command-line interface (CLI) tool used to remove all data from the KV store on a Splunk instance. This action is irreversible and is typically used during development, testing, or when a complete reset of the KV store's contents is required. It must be run from the $SPLUNKHOME/bin directory.

B. splunk clear kvstore: The clear verb is not used for this function in the Splunk CLI; the correct verb is clean.

C. splunk delete kvstore: The delete verb is not a valid command for managing the KV store as a whole from the CLI.

D. splunk reinitialize kvstore: reinitialize is not a valid verb for this Splunk CLI command. The correct and documented command is splunk clean kvstore.

- Splunk Enterprise Documentation. (2023). Admin Manual, "Use the command line to manage KV Store". This section explicitly lists and describes the splunk clean kvstore command as the method to "Remove all data from KV Store."

- Splunk Enterprise Documentation. (2023). Developing Views and Apps for Splunk Web, "KV Store". The documentation on administering the KV store references the CLI tools for maintenance, including the clean command.

A multi-site indexer cluster is configured on the manager node. This can be done by directly editing the server.conf file to add the [multisite] stanza and define site-specific attributes. Alternatively, the splunk edit cluster-config command-line interface (CLI) tool can be used to modify these same settings. Splunk Web is used for monitoring the cluster's status and performing some management tasks, but not for the initial multi-site setup. Editing default configuration files is against Splunk best practices.

A. Splunk Web is used for monitoring and managing an already configured cluster, not for the initial multi-site architectural setup.

D. The default directory contains template files. You should never edit files in this directory as they can be overwritten during upgrades.

- Splunk Enterprise Documentation, Managing Indexers and Clusters of Indexers, "Configure a multisite indexer cluster", Section: "Enable multisite on the manager node". This section details using both the CLI and server.conf for configuration.

- Splunk Enterprise Documentation, Admin Manual, "server.conf". This specification file documents the [multisite] and [clustering] stanzas required for this configuration.

The deployer is a Splunk Enterprise instance responsible for managing and distributing configurations to the members of a search head cluster. Its primary function is to push a consistent set of knowledge objects, apps, and certain manual configurations from a central location ($SPLUNKHOME/etc/shcluster/) to all cluster members. This ensures uniformity for configurations that are not automatically replicated by the cluster captain, such as app configurations and other non-runtime settings.

B. Bootstraps a clean Splunk install for a SHC. Incorrect. Bootstrapping is an initial, one-time setup process performed on each member individually, not a function of the deployer.

D. Distributes runtime knowledge object changes made by users across the SHC. Incorrect. Runtime changes made via the UI (e.g., creating saved searches) are automatically replicated across members by the cluster captain.

Splunk Enterprise Distributed Search Manual, "Use the deployer to distribute apps and configuration updates". The documentation states, "The deployer is the tool for distributing apps and other configurations to the cluster members." It also clarifies, "You must use the deployer to distribute all app and configuration updates. Do not attempt to make ad hoc changes on individual members."

Splunk Enterprise Distributed Search Manual, "Configuration updates that the cluster replicates". This section distinguishes between deployer-pushed configurations and captain-replicated runtime configurations.

In a search-head cluster the scheduler skips any member flagged as an “adhoc” search head.

Setting captainisadhocsearchhead = true in the [shclustering] stanza of server.conf on the captain causes the captain itself to be treated as an adhoc search head, so it will not be assigned scheduled searches. All user-initiated (ad-hoc) searches can still run, but the scheduler load is removed from the captain, reducing its workload.

A. adhocsearchhead affects only the local member and is ignored by the captain scheduler; it does not single out the captain.

B. Same parameter as A but limited to the current captain; still not the correct directive for excluding scheduled searches.

C. Setting captainisadhocsearchhead on every member is unnecessary; only the node that is captain must have it set.

1. Splunk Enterprise server.conf.spec, [shclustering] – “captainisadhocsearchhead = … When true the captain is treated as an adhoc search head and will not run scheduled searches.” (etc/system/README/server.conf.spec, Splunk 9.0.4).

2. Splunk Enterprise Distributed Search Manual 9.0, “Prevent the captain from running scheduled searches”, para 1-2.

Version-compatibility rules for indexer clusters require that the cluster-master (manager) run the same or a later release than its peer indexers, while search heads may run the same release as, or one release newer than, the peer indexers. Peer nodes are only required to be on a supported release—not necessarily identical—and they must not be newer than the master. Hence, only statement D is correct.

A. Peers should run compatible versions but need not be identical.

B. Search heads can be the same or newer than the master; master need not be newest.

C. Peers cannot be newer than the master; rule is reversed.

D. Correct.

1. Splunk Enterprise Distributed Search Manual > Indexer Clustering > “Version compatibility between cluster nodes” (Splunk 9.0, Table 1).

2. Splunk Release Notes > “Upgrade path and mixed-version support for indexer clusters” (Splunk 9.1, §Cluster version matrix).