Splunk Core Certified Consultant Free Sample Questions

On a three-site cluster, site_replication_factor = origin:1, total:2 keeps one copy on the origin site and sends the remaining copy to a site that has no copy yet, so the two copies of every bucket sit on two different sites. site_search_factor = origin:1, total:2 makes both copies searchable. When LON fails, every bucket therefore still has a searchable copy in NYC or TOK. The manager detects the failure after the heartbeat timeout (60 seconds by default); until it has reassigned primacy to the surviving searchable copies, searches return partial results. Then the cluster is valid again and the search returns complete results. No copies need to be converted, because the surviving copies are already searchable.

useACK = true enables indexer acknowledgment, which is disabled by default. The forwarder keeps a copy of each data block in its in-memory wait queue until the indexer confirms it has written the data to disk. If no acknowledgment arrives (the indexer goes down, its disk is full, or the network drops), the forwarder resends the block, to the next indexer when load balancing is used. This protects data in flight, though a resend after a lost ACK can create duplicates. During a forwarder shutdown it waits up to ackTimeoutOnShutdown (30 s) for outstanding ACKs. compressed, autoLBFrequency and sendCookedData = false do not protect against data loss.

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.

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.

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.

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.

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.

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.

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.

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.