Splunk Enterprise Certified Architect SPLK-2002 Exam Questions

Answer : D

The logical first step when starting a deployment plan is to collect the initial requirements for the deployment from all stakeholders. This includes identifying the business objectives, the data sources, the use cases, the security and compliance needs, the scalability and availability expectations, and the budget and timeline constraints. Collecting the initial requirements helps to define the scope and the goals of the deployment, and to align the expectations of all the parties involved.

Inventorying the currently deployed logging infrastructure, determining what apps and use cases will be implemented, and gathering statistics on the expected adoption of Splunk for sizing are all important steps in the deployment planning process, but they are not the logical first step. These steps can be done after collecting the initial requirements, as they depend on the information gathered from the stakeholders.

Answer : B

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 -- License Reporting and Troubleshooting

Answer : B

The Splunk Enterprise Security and Encryption documentation specifies that the primary mechanism for securing data in motion within a Splunk environment is to enable TLS/SSL encryption between forwarders and indexers. This ensures that log data transmitted from Universal Forwarders or Heavy Forwarders to Indexers is fully encrypted and protected from interception or tampering.

The correct configuration involves setting up signed SSL certificates on both forwarders and indexers:

On the forwarder, TLS settings are defined in outputs.conf, specifying parameters like sslCertPath, sslPassword, and sslRootCAPath.

On the indexer, TLS is enabled in inputs.conf and server.conf using the same shared CA for validation.

Splunk's documentation explicitly states that this configuration protects data-in-transit between the collection (forwarder) and indexing (storage) tiers --- which is the critical link where sensitive log data is most vulnerable.

Other communication channels (e.g., deployment server to clients or browser to Splunk Web) can also use encryption but do not secure the ingestion pipeline that handles the indexed data stream. Therefore, TLS should be implemented between Splunk forwarders and indexers.

Reference (Splunk Enterprise Documentation):

* Securing Data in Transit with SSL/TLS

* Configure Forwarder-to-Indexer Encryption Using SSL Certificates

* Server and Forwarder Authentication Setup Guide

* Splunk Enterprise Admin Manual -- Security and Encryption Best Practices

Answer : A, C

The deployer distributes apps and non-search related and manual configuration file changes to the search head cluster members. The deployer does not bootstrap a clean Splunk install for a search head cluster, as this is done by the captain. The deployer also does not distribute runtime knowledge object changes made by users across the search head cluster, as this is done by the replication factor. For more information, seeUse the deployer to distribute apps and configuration updatesin the Splunk documentation.

Answer : C

According to the indexes.conf reference in Splunk Enterprise, the parameter maxDataSize controls the maximum size (in GB or MB) of a single hot bucket before Splunk rolls it to a warm bucket. When the value is set to auto_high_volume on a 64-bit system, Splunk automatically sets the maximum hot bucket size to 10 GB.

The ''auto'' settings allow Splunk to choose optimized values based on the system architecture:

auto: Default hot bucket size of 750 MB (32-bit) or 10 GB (64-bit).

auto_high_volume: Specifically tuned for high-ingest indexes; on 64-bit systems, this equals 10 GB per hot bucket.

auto_low_volume: Uses smaller bucket sizes for lightweight indexes.

The purpose of larger hot bucket sizes on 64-bit systems is to improve indexing performance and reduce the overhead of frequent bucket rolling during heavy data ingestion. The documentation explicitly warns that these sizes differ on 32-bit systems due to memory addressing limitations.

Thus, for high-throughput environments running 64-bit operating systems, auto_high_volume = 10 GB is the correct and Splunk-documented configuration.

Reference (Splunk Enterprise Documentation):

* indexes.conf -- maxDataSize Attribute Reference

* Managing Index Buckets and Data Retention

* Splunk Enterprise Admin Manual -- Indexer Storage Configuration

* Splunk Performance Tuning: Bucket Management and Hot/Warm Transitions

Answer : D

Multiple search pipelines should be enabled only if CPU and memory resources are significantly under-utilized. Search pipelines are the processes that execute search commands and return results. Multiple search pipelines can improve the search performance by running concurrent searches in parallel. However, multiple search pipelines also consume more CPU and memory resources, which can affect the overall system performance. Therefore, multiple search pipelines should be enabled only if there are enough CPU and memory resources available, and if the system is not bottlenecked by disk I/O or network bandwidth.The number of concurrent users, the disk IOPS, and the Splunk Enterprise version are not relevant factors for enabling multiple search pipelines

Answer : C

Splunk Enterprise performs a CRC check against the first and last 256 bytes of a file by default, as stated in theinputs.conf specification. This is controlled by the initCrcLength parameter, which can be changed if needed. The CRC check helps Splunk Enterprise to avoid re-indexing the same file twice, even if it is renamed or rotated, as long as the content does not change. However, this also means that Splunk Enterprise might miss some files that have the same CRC but different content, especially if they have identical headers. To avoid this, the crcSalt parameter can be used to add some extra information to the CRC calculation, such as the full file path or a custom string. This ensures that each file has a unique CRC and is indexed by Splunk Enterprise. You can read more about crcSalt and initCrcLength in theHow log file rotation is handleddocumentation.