Practice Free SPLK-2002 Exam Online Questions
Question #21
Which of the following strongly impacts storage sizing requirements for Enterprise Security?
- A . The number of scheduled (correlation) searches.
- B . The number of Splunk users configured.
- C . The number of source types used in the environment.
- D . The number of Data Models accelerated.
Correct Answer: D
D
Explanation:
Data Model acceleration is a feature that enables faster searches over large data sets by summarizing the raw data into a more efficient format. Data Model acceleration consumes additional disk space, as it stores both the raw data and the summarized data. The amount of disk space required depends on the size and complexity of the Data Model, the retention period of the summarized data, and the compression ratio of the data. According to the Splunk Enterprise Security Planning and Installation Manual, Data Model acceleration is one of the factors that strongly impacts storage sizing requirements for Enterprise Security. The other factors are the volume and type of data sources, the retention policy of the data, and the replication factor and search factor of the index cluster. The number of scheduled (correlation) searches, the number of Splunk users configured, and the number of source types used in the environment are not directly related to storage sizing requirements for Enterprise Security1
1: https://docs.splunk.com/Documentation/ES/6.6.0/Install/Plan#Storage_sizing_requirements
D
Explanation:
Data Model acceleration is a feature that enables faster searches over large data sets by summarizing the raw data into a more efficient format. Data Model acceleration consumes additional disk space, as it stores both the raw data and the summarized data. The amount of disk space required depends on the size and complexity of the Data Model, the retention period of the summarized data, and the compression ratio of the data. According to the Splunk Enterprise Security Planning and Installation Manual, Data Model acceleration is one of the factors that strongly impacts storage sizing requirements for Enterprise Security. The other factors are the volume and type of data sources, the retention policy of the data, and the replication factor and search factor of the index cluster. The number of scheduled (correlation) searches, the number of Splunk users configured, and the number of source types used in the environment are not directly related to storage sizing requirements for Enterprise Security1
1: https://docs.splunk.com/Documentation/ES/6.6.0/Install/Plan#Storage_sizing_requirements
Question #22
When preparing to ingest a new data source, which of the following is optional in the data source assessment?
- A . Data format
- B . Data location
- C . Data volume
- D . Data retention
Correct Answer: D
D
Explanation:
Data retention is optional in the data source assessment because it is not directly related to the ingestion process. Data retention is determined by the index configuration and the storage capacity of the Splunk platform. Data format, data location, and data volume are all essential information for planning how to collect, parse, and index the data source.
Reference: Drive more value through data source and use case optimization – Splunk, page 9 Data source planning for Splunk Enterprise Security
D
Explanation:
Data retention is optional in the data source assessment because it is not directly related to the ingestion process. Data retention is determined by the index configuration and the storage capacity of the Splunk platform. Data format, data location, and data volume are all essential information for planning how to collect, parse, and index the data source.
Reference: Drive more value through data source and use case optimization – Splunk, page 9 Data source planning for Splunk Enterprise Security
Question #23
In an existing Splunk environment, the new index buckets that are created each day are about half the size of the incoming data. Within each bucket, about 30% of the space is used for rawdata and about 70% for index files.
What additional information is needed to calculate the daily disk consumption, per indexer, if indexer clustering is implemented?
- A . Total daily indexing volume, number of peer nodes, and number of accelerated searches.
- B . Total daily indexing volume, number of peer nodes, replication factor, and search factor.
- C . Total daily indexing volume, replication factor, search factor, and number of search heads.
- D . Replication factor, search factor, number of accelerated searches, and total disk size across cluster.
Correct Answer: B
B
Explanation:
The additional information that is needed to calculate the daily disk consumption, per indexer, if indexer clustering is implemented, is the total daily indexing volume, the number of peer nodes, the replication factor, and the search factor. These information are required to estimate how much data is ingested, how many copies of raw data and searchable data are maintained, and how many indexers are involved in the cluster. The number of accelerated searches, the number of search heads, and the total disk size across the cluster are not relevant for calculating the daily disk consumption, per indexer. For more information, see [Estimate your storage requirements] in the Splunk documentation.
B
Explanation:
The additional information that is needed to calculate the daily disk consumption, per indexer, if indexer clustering is implemented, is the total daily indexing volume, the number of peer nodes, the replication factor, and the search factor. These information are required to estimate how much data is ingested, how many copies of raw data and searchable data are maintained, and how many indexers are involved in the cluster. The number of accelerated searches, the number of search heads, and the total disk size across the cluster are not relevant for calculating the daily disk consumption, per indexer. For more information, see [Estimate your storage requirements] in the Splunk documentation.
Question #24
What is needed to ensure that high-velocity sources will not have forwarding delays to the indexers?
- A . Increase the default value of sessionTimeout in server, conf.
- B . Increase the default limit for maxKBps in limits.conf.
- C . Decrease the value of forceTimebasedAutoLB in outputs. conf.
- D . Decrease the default value of phoneHomelntervallnSecs in deploymentclient .conf.
Correct Answer: B
B
Explanation:
To ensure that high-velocity sources will not have forwarding delays to the indexers, the default limit for maxKBps in limits.conf should be increased. This parameter controls the maximum bandwidth that a forwarder can use to send data to the indexers. By default, it is set to 256 KBps, which may not be sufficient for high-volume data sources. Increasing this limit can reduce the forwarding latency and improve the performance of the forwarders. However, this should be done with caution, as it may affect the network bandwidth and the indexer load.
Option B is the correct answer.
Option A is incorrect because the sessionTimeout parameter in server.conf controls the duration of a TCP connection between a forwarder and an indexer, not the bandwidth limit.
Option C is incorrect because the forceTimebasedAutoLB parameter in outputs.conf controls the frequency of load balancing among the indexers, not the bandwidth limit.
Option D is incorrect because the phoneHomelntervallnSecs parameter in deploymentclient.conf controls the interval at which a forwarder contacts the deployment server, not the bandwidth limit12
1: https://docs.splunk.com/Documentation/Splunk/9.1.2/Admin/Limitsconf#limits.conf.spec
2: https://docs.splunk.com/Documentation/Splunk/9.1.2/Forwarding/Routeandfilterdatad#Set_the_maximum_bandwidth_usage_for_a_forwarder
B
Explanation:
To ensure that high-velocity sources will not have forwarding delays to the indexers, the default limit for maxKBps in limits.conf should be increased. This parameter controls the maximum bandwidth that a forwarder can use to send data to the indexers. By default, it is set to 256 KBps, which may not be sufficient for high-volume data sources. Increasing this limit can reduce the forwarding latency and improve the performance of the forwarders. However, this should be done with caution, as it may affect the network bandwidth and the indexer load.
Option B is the correct answer.
Option A is incorrect because the sessionTimeout parameter in server.conf controls the duration of a TCP connection between a forwarder and an indexer, not the bandwidth limit.
Option C is incorrect because the forceTimebasedAutoLB parameter in outputs.conf controls the frequency of load balancing among the indexers, not the bandwidth limit.
Option D is incorrect because the phoneHomelntervallnSecs parameter in deploymentclient.conf controls the interval at which a forwarder contacts the deployment server, not the bandwidth limit12
1: https://docs.splunk.com/Documentation/Splunk/9.1.2/Admin/Limitsconf#limits.conf.spec
2: https://docs.splunk.com/Documentation/Splunk/9.1.2/Forwarding/Routeandfilterdatad#Set_the_maximum_bandwidth_usage_for_a_forwarder
Question #25
Which of the following options can improve reliability of syslog delivery to Splunk? (Select all that apply.)
- A . Use TCP syslog.
- B . Configure UDP inputs on each Splunk indexer to receive data directly.
- C . Use a network load balancer to direct syslog traffic to active backend syslog listeners.
- D . Use one or more syslog servers to persist data with a Universal Forwarder to send the data to Splunk indexers.
Correct Answer: A,D
A,D
Explanation:
Syslog is a standard protocol for sending log messages from various devices and applications to a central server. Syslog can use either UDP or TCP as the transport layer protocol. UDP is faster but less reliable, as it does not guarantee delivery or order of the messages. TCP is slower but more reliable, as it ensures delivery and order of the messages. Therefore, to improve the reliability of syslog delivery to Splunk, it is recommended to use TCP syslog.
Another option to improve the reliability of syslog delivery to Splunk is to use one or more syslog servers to persist data with a Universal Forwarder to send the data to Splunk indexers. This way, the syslog servers can act as a buffer and store the data in case of network or Splunk outages. The Universal Forwarder can then forward the data to Splunk indexers when they are available.
Using a network load balancer to direct syslog traffic to active backend syslog listeners is not a reliable option, as it does not address the possibility of data loss or duplication due to network failures or Splunk outages. Configuring UDP inputs on each Splunk indexer to receive data directly is also not a reliable option, as it exposes the indexers to the network and increases the risk of data loss or duplication due to UDP limitations.
A,D
Explanation:
Syslog is a standard protocol for sending log messages from various devices and applications to a central server. Syslog can use either UDP or TCP as the transport layer protocol. UDP is faster but less reliable, as it does not guarantee delivery or order of the messages. TCP is slower but more reliable, as it ensures delivery and order of the messages. Therefore, to improve the reliability of syslog delivery to Splunk, it is recommended to use TCP syslog.
Another option to improve the reliability of syslog delivery to Splunk is to use one or more syslog servers to persist data with a Universal Forwarder to send the data to Splunk indexers. This way, the syslog servers can act as a buffer and store the data in case of network or Splunk outages. The Universal Forwarder can then forward the data to Splunk indexers when they are available.
Using a network load balancer to direct syslog traffic to active backend syslog listeners is not a reliable option, as it does not address the possibility of data loss or duplication due to network failures or Splunk outages. Configuring UDP inputs on each Splunk indexer to receive data directly is also not a reliable option, as it exposes the indexers to the network and increases the risk of data loss or duplication due to UDP limitations.
Question #26
When should a Universal Forwarder be used instead of a Heavy Forwarder?
- A . When most of the data requires masking.
- B . When there is a high-velocity data source.
- C . When data comes directly from a database server.
- D . When a modular input is needed.
Correct Answer: B
B
Explanation:
According to the Splunk blog1, the Universal Forwarder is ideal for collecting data from high-velocity data sources, such as a syslog server, due to its smaller footprint and faster performance. The Universal Forwarder performs minimal processing and sends raw or unparsed data to the indexers, reducing the network traffic and the load on the forwarders.
The other options are false because:
When most of the data requires masking, a Heavy Forwarder is needed, as it can perform advanced filtering and data transformation before forwarding the data2.
When data comes directly from a database server, a Heavy Forwarder is needed, as it can run modular inputs such as DB Connect to collect data from various databases2.
When a modular input is needed, a Heavy Forwarder is needed, as the Universal Forwarder does not include a bundled version of Python, which is required for most modular inputs2.
B
Explanation:
According to the Splunk blog1, the Universal Forwarder is ideal for collecting data from high-velocity data sources, such as a syslog server, due to its smaller footprint and faster performance. The Universal Forwarder performs minimal processing and sends raw or unparsed data to the indexers, reducing the network traffic and the load on the forwarders.
The other options are false because:
When most of the data requires masking, a Heavy Forwarder is needed, as it can perform advanced filtering and data transformation before forwarding the data2.
When data comes directly from a database server, a Heavy Forwarder is needed, as it can run modular inputs such as DB Connect to collect data from various databases2.
When a modular input is needed, a Heavy Forwarder is needed, as the Universal Forwarder does not include a bundled version of Python, which is required for most modular inputs2.
Question #27
In which phase of the Splunk Enterprise data pipeline are indexed extraction configurations processed?
- A . Input
- B . Search
- C . Parsing
- D . Indexing
Correct Answer: D
D
Explanation:
Indexed extraction configurations are processed in the indexing phase of the Splunk Enterprise data pipeline. The data pipeline is the process that Splunk uses to ingest, parse, index, and search data. Indexed extraction configurations are settings that determine how Splunk extracts fields from data at index time, rather than at search time. Indexed extraction can improve search performance, but it also increases the size of the index. Indexed extraction configurations are applied in the indexing phase, which is the phase where Splunk writes the data and the .tsidx files to the index. The input phase is the phase where Splunk receives data from various sources and formats. The parsing phase is the phase where Splunk breaks the data into events, timestamps, and hosts. The search phase is the phase where Splunk executes search commands and returns results.
D
Explanation:
Indexed extraction configurations are processed in the indexing phase of the Splunk Enterprise data pipeline. The data pipeline is the process that Splunk uses to ingest, parse, index, and search data. Indexed extraction configurations are settings that determine how Splunk extracts fields from data at index time, rather than at search time. Indexed extraction can improve search performance, but it also increases the size of the index. Indexed extraction configurations are applied in the indexing phase, which is the phase where Splunk writes the data and the .tsidx files to the index. The input phase is the phase where Splunk receives data from various sources and formats. The parsing phase is the phase where Splunk breaks the data into events, timestamps, and hosts. The search phase is the phase where Splunk executes search commands and returns results.
Question #28
A customer has an environment with a Search Head Cluster and an indexer cluster. They are troubleshooting license usage data, including indexed volume in bytes per pool, index, host, source type, and source.
Where should the license_usage.log file be retrieved from in this environment?
- A . Cluster Manager and Search Head Cluster Deployer
- B . License Manager
- C . Search Head Cluster Deployer only
- D . All indexers
Correct Answer: B
B
Explanation:
The license_usage.log file is generated and maintained on the License Manager node in a Splunk deployment. This log provides detailed statistics about daily license consumption, including data volume indexed per pool, index, sourcetype, source, and host.
In a distributed or clustered environment (with both search head and indexer clusters), the License Manager acts as the central authority that collects license usage information from all indexers and consolidates it into this log. The License Manager receives periodic reports from each license peer (indexer) and records them in:
$SPLUNK_HOME/var/log/splunk/license_usage.log
The log is automatically indexed into the _internal index with sourcetype=splunkd and can be queried using searches such as:
index=_internal source=*license_usage.log* type="RolloverSummary"
Other components like the Cluster Manager, SHC Deployer, or individual indexers do not store the full consolidated license usage data ― they only send summarized reports to the License Manager.
Therefore, the License Manager is the definitive and Splunk-documented location for retrieving and analyzing license_usage.log data across a distributed deployment.
Reference (Splunk Enterprise Documentation):
• Managing Licenses in a Distributed Environment
• license_usage.log Reference and Structure
• Monitoring License Consumption Using the License Manager
• Splunk Enterprise Admin Manual C License Reporting and Troubleshooting
B
Explanation:
The license_usage.log file is generated and maintained on the License Manager node in a Splunk deployment. This log provides detailed statistics about daily license consumption, including data volume indexed per pool, index, sourcetype, source, and host.
In a distributed or clustered environment (with both search head and indexer clusters), the License Manager acts as the central authority that collects license usage information from all indexers and consolidates it into this log. The License Manager receives periodic reports from each license peer (indexer) and records them in:
$SPLUNK_HOME/var/log/splunk/license_usage.log
The log is automatically indexed into the _internal index with sourcetype=splunkd and can be queried using searches such as:
index=_internal source=*license_usage.log* type="RolloverSummary"
Other components like the Cluster Manager, SHC Deployer, or individual indexers do not store the full consolidated license usage data ― they only send summarized reports to the License Manager.
Therefore, the License Manager is the definitive and Splunk-documented location for retrieving and analyzing license_usage.log data across a distributed deployment.
Reference (Splunk Enterprise Documentation):
• Managing Licenses in a Distributed Environment
• license_usage.log Reference and Structure
• Monitoring License Consumption Using the License Manager
• Splunk Enterprise Admin Manual C License Reporting and Troubleshooting
Question #29
Where does the Splunk deployer send apps by default?
- A . etc/slave-apps/<app-name>/default
- B . etc/deploy-apps/<app-name>/default
- C . etc/apps/<appname>/default
- D . etc/shcluster/<app-name>/default
Correct Answer: D
D
Explanation:
The Splunk deployer sends apps to the search head cluster members by default to the path etc/shcluster/<app-name>/default. The deployer is a Splunk component that distributes apps and configurations to members of a search head cluster.
Splunk’s documentation recommends placing the configuration bundle in the $SPLUNK_HOME/etc/shcluster/apps directory on the deployer, which then gets distributed to the search head cluster members. However, it should be noted that within each app’s directory, configurations can be under default or local subdirectories, with local taking precedence over default for configurations. The reference to etc/shcluster/<app-name>/default is not a standard directory structure and might be a misunderstanding. The correct path where the deployer pushes configuration bundles is $SPLUNK_HOME/etc/shcluster/apps
D
Explanation:
The Splunk deployer sends apps to the search head cluster members by default to the path etc/shcluster/<app-name>/default. The deployer is a Splunk component that distributes apps and configurations to members of a search head cluster.
Splunk’s documentation recommends placing the configuration bundle in the $SPLUNK_HOME/etc/shcluster/apps directory on the deployer, which then gets distributed to the search head cluster members. However, it should be noted that within each app’s directory, configurations can be under default or local subdirectories, with local taking precedence over default for configurations. The reference to etc/shcluster/<app-name>/default is not a standard directory structure and might be a misunderstanding. The correct path where the deployer pushes configuration bundles is $SPLUNK_HOME/etc/shcluster/apps
Question #30
(Which of the following is a valid way to determine if a new bundle push will trigger a rolling restart?)
- A . splunk show cluster-bundle-status
- B . splunk apply cluster-bundle
- C . splunk validate cluster-bundle ―check-restart
- D . splunk apply cluster-bundle ―validate-bundle
Correct Answer: C
C
Explanation:
The splunk validate cluster-bundle –check-restart command is the officially documented Splunk Enterprise method to determine if a configuration bundle push will trigger a rolling restart within an indexer cluster.
When configuration changes are made on the Cluster Manager (Master Node)―for example, updates to indexes.conf, props.conf, or transforms.conf―Splunk administrators must validate the bundle before pushing it to all peer nodes. Using this command allows the Cluster Manager to simulate the deployment and verify whether the configuration modifications necessitate a restart across peer indexers to take effect.
The –check-restart flag specifically reports whether:
The configuration changes are minor (no restart required).
The changes affect components that require a full or rolling restart (e.g., changes to indexing paths, volume definitions, or replication factors).
Running this validation prior to an actual splunk apply cluster-bundle command prevents service disruption during production operations.
Other commands such as splunk show cluster-bundle-status display deployment status but not restart requirements, and splunk apply cluster-bundle executes the actual deployment, not validation.
Reference (Splunk Enterprise Documentation):
• Indexer Clustering: Deploy Configuration Bundles with Validation
• splunk validate cluster-bundle Command Reference
• Managing Indexer Clusters C Rolling Restarts and Bundle Deployment Best Practices
• Splunk Enterprise Admin Manual C Cluster Manager Maintenance Commands
C
Explanation:
The splunk validate cluster-bundle –check-restart command is the officially documented Splunk Enterprise method to determine if a configuration bundle push will trigger a rolling restart within an indexer cluster.
When configuration changes are made on the Cluster Manager (Master Node)―for example, updates to indexes.conf, props.conf, or transforms.conf―Splunk administrators must validate the bundle before pushing it to all peer nodes. Using this command allows the Cluster Manager to simulate the deployment and verify whether the configuration modifications necessitate a restart across peer indexers to take effect.
The –check-restart flag specifically reports whether:
The configuration changes are minor (no restart required).
The changes affect components that require a full or rolling restart (e.g., changes to indexing paths, volume definitions, or replication factors).
Running this validation prior to an actual splunk apply cluster-bundle command prevents service disruption during production operations.
Other commands such as splunk show cluster-bundle-status display deployment status but not restart requirements, and splunk apply cluster-bundle executes the actual deployment, not validation.
Reference (Splunk Enterprise Documentation):
• Indexer Clustering: Deploy Configuration Bundles with Validation
• splunk validate cluster-bundle Command Reference
• Managing Indexer Clusters C Rolling Restarts and Bundle Deployment Best Practices
• Splunk Enterprise Admin Manual C Cluster Manager Maintenance Commands