Free SPLK-3003 sample questions

Correct answer: Isolate the problematic apps onto a separate, smaller Search Head Cluster.

In a search head cluster every KV store write is delegated to the KV store captain, while reads stay local. Write-heavy apps therefore load one KV store that the whole cluster shares, and adding members does not spread that write load. Moving the apps with heavy KV store use to their own, smaller search head cluster gives them a separate KV store and removes their contention from the primary cluster. Moving high-write lookups to CSV goes against Splunk guidance: CSV lookups suit files that are small or rarely modified and need a full rewrite for every edit, while KV store lookups suit large or frequently updated tables. `splunk clean kvstore` deletes KV store data and is meant for resynchronization or restore, and search concurrency settings do not address KV store contention.

Correct answer: `stats` retrieves all the sourcetypes in one search and groups them by the shared field in a single pass, while `join` runs a separate subsearch whose results are capped (50,000 rows and 60 seconds by default) and merged on the search head.

Splunk recommends `stats` (or `transaction`) over `join` and `append` in most cases. The usual rewrite is one search that retrieves every sourcetype (for example `sourcetype=a OR sourcetype=b`) followed by `stats ... by `, so the events are fetched once and correlated in a single pass. `join` must run a separate subsearch, and by default only 50,000 right-side rows can be joined, within 60 seconds (`[join] subsearch_maxout` and `subsearch_maxtime` in limits.conf), so large correlations are truncated. `stats` is a transforming command, not a streaming one. Reading accelerated summaries is what `tstats` does, and `stats` outputs a results table, not `_raw` events.

Correct answer: Create a transform in `transforms.conf` on the Heavy Forwarder that sets the destination index based on a regex of the event data, and apply it in `props.conf`.

The correct way to route events to different indexes based on their content is at parse time on a Heavy Forwarder or on the Indexers. This is achieved by defining a stanza in `props.conf` that applies a `TRANSFORMS-` class. This class then points to a stanza in `transforms.conf` which uses a regular expression (`REGEX`) to match event patterns and sets the `DEST_KEY` to `_MetaData:Index` with the `FORMAT` set to the target index name (e.g., `pci_index`). This ensures events are written to the correct index upon arrival.

Correct answer: The MC instance has not been added to the indexer cluster as a search head.

The MC is a search head that gathers data by searching other instances. Most instances (search heads, deployment servers, the license manager, non-clustered indexers) are added to it as search peers, but the docs say: "Do not add clustered indexers." Instead, you add the cluster manager as a search peer and configure the MC instance as a search head of the indexer cluster, as a multisite search head when the cluster is multisite. The MC then reaches the cluster's peers through the cluster, the same way any cluster search head does. If that step is missed, the cluster's indexers are missing from the MC even though the other instances appear. There is no `[mc_roles]` stanza, and licenses do not restrict monitoring.

Correct answer: False

False. `site0` is not a valid site for a peer node. According to server.conf, `site0` can be set only on search heads or on forwarders that participate in indexer discovery. On a search head it disables search affinity; on an indexer-discovery forwarder it sends data to peers on all sites. Every peer must belong to a real site (`site1` to `site63`) so that the manager can apply the site replication and search factors.

Correct answer: Create two target group stanzas in `outputs.conf` (e.g., `[tcpout:sec_cluster]`, `[tcpout:ops_cluster]`) and set `_TCP_ROUTING` in each input stanza in `inputs.conf` to direct each input to the appropriate group.

Define one target group per destination in `outputs.conf` (for example `[tcpout:sec_cluster]` and `[tcpout:ops_cluster]`, each with its `server` list). Then set `_TCP_ROUTING = ` in each input stanza of `inputs.conf`, so security inputs go to sec_cluster and operations inputs go to ops_cluster. A universal forwarder can route by data input this way. Event-based routing through props.conf/transforms.conf works only on a heavy forwarder.

Correct answer: Create (or keep) native Splunk accounts for these administrators. No extra setting is needed: they sign in at `https:// : /en-US/account/login?loginType=splunk`, which bypasses the SAML redirect.

No extra setting is needed. Native Splunk authentication always takes precedence over external schemes, so native accounts keep working while SAML is enabled. To bypass the SAML redirect, the administrators browse to https:// : /en-US/account/login?loginType=splunk and sign in with their local credentials. This works even when the IdP is unreachable. authentication.conf has no "fallback" setting, `authType` accepts only one value, and `[roleMap_SAML]` maps IdP groups to roles; it does not enable local login.

Correct answer: `maxConcurrentDownloads` in the `[global]` stanza (default 0, which means no limit)

`maxConcurrentDownloads` in the `[global]` stanza of `serverclass.conf` sets the maximum number of deployment clients that can download app bundles from the deployment server at the same time. A client that is refused retries at its next phone home. The default 0 means no limit, so raising the throttled value (or resetting it to 0) lets more forwarders download at once. `phoneHomeIntervalInSecs` is a client-side `deploymentclient.conf` setting. `crossServerChecksum` keeps app checksums consistent across several deployment servers behind a load balancer. `restartSplunkd` only controls whether clients restart after an app update.

Correct answer: The replication factor is set to a number greater than the current number of active peer nodes in the cluster.

If the `replication_factor` in `server.conf` is, for example, 3, but there are only 2 active peer nodes, the cluster master will be in a constant state of trying to create a third copy of every bucket. It will continuously fail to find a valid target peer, leading to an endless cycle of bucket-fixing activities and high CPU load on the master node. This is a common misconfiguration issue in undersized or partially failed clusters.

Correct answer: A Search Head Cluster Deployer

A Search Head Cluster (SHC) requires a Deployer to manage and distribute configurations (apps, conf files) to all cluster members. This ensures that every member has an identical set of configurations, which is critical for consistent behavior and functionality. The Deployer is a separate Splunk instance dedicated to this role.