Hard Difficulty Questions

The app is not visible.

Why it fails: Visibility affects UI access, not alert execution.

The owner does not have write access.

Why it fails: Write access is needed for editing, but not execution.

The search is too short.

Why it fails: Search duration does not prevent triggering.

Field

Why it fails: Field is not a drilldown component.

Search

Why it fails: Search is an external component.

Use an 'on_load' script.

Why it fails: An 'on_load' script runs only when the dashboard initialises, not when a user changes an input, so other inputs never reset during interaction. It is tempting for one-time setup tasks, and would be correct for initialising default token values at page load.

Use a 'global' scope for all tokens.

Why it fails: Global scope shares a token across all inputs, so changing one updates the others rather than resetting them. It suits dashboards where inputs must stay synchronised. Resetting requires each input's token to be cleared when another changes, which Simple XML achieves through searchWhenChanged and depends/rejects declarations, not scope.

Use the 'reset' attribute on the input.

Why it fails: Simple XML has no 'reset' attribute on inputs; clearing other inputs requires a change handler that sets their tokens or a searchWhenChanged dependency, so this attribute is ignored. It is tempting because it reads like a native feature, and would be correct if Splunk offered such an attribute.

stats count by user, action | where action="failed" AND action="success"

Why it fails: Using stats to count by user and action produces separate rows for failed and success actions per user. The subsequent where clause cannot reference both actions in the same row because they are in different rows. This approach fails to correlate the two events; it only counts occurrences and does not link them temporally or sequentially.

join user [ search index=auth action=success ]

Why it fails: The join command combines results from a subsearch with the main search based on a common field, but it does not enforce time constraints or sequence. It would match any successful login for the same user regardless of time or order, which could produce false positives. Additionally, join has limitations with large result sets and does not natively handle time-based correlation.

eventstats values(action) as actions by user | where mvcount(actions)>1

Why it fails: eventstats adds a multivalue field 'actions' containing all action values for each user to every event. Filtering by mvcount>1 identifies users who have both failed and success actions, but it does not consider the order or the 10-minute window. It would include users whose failed and successful logins are hours apart, violating the correlation requirement.

indexes.conf

Why it fails: indexes.conf configures index storage, retention and bucket settings, and cannot attach lookups to searches. Automatic sourcetype-based lookup execution belongs in props.conf. indexes.conf is tempting because sourcetype is mentioned in the stem, but sourcetype settings there govern parsing and indexing, not lookup enrichment.

lookups.conf

Why it fails: lookups.conf defines lookup table definitions and their file paths, not when a lookup runs. Automatic execution for a sourcetype is bound through props.conf, which references the lookup definition. lookups.conf is tempting because its name suggests lookup configuration, and it is genuinely required to register the table itself.

transforms.conf

Why it fails: transforms.conf defines the lookup definition and its fields, but nothing in it binds that lookup to a sourcetype for automatic execution. props.conf performs that binding. transforms.conf is tempting because every automatic lookup needs a stanza there, yet on its own it never triggers during search.

savedsearches.conf

Why it fails: savedsearches.conf stores scheduled or saved search definitions, so it only enriches searches it defines, not every search across a sourcetype. props.conf applies the lookup globally to that sourcetype. savedsearches.conf is tempting because it can reference lookups, but that scope is per saved search.

User password

Why it fails: A user password is a secret credential, never exposed as a resolvable token for constructing a workflow action link. It is tempting because authentication data sometimes feeds integrations, and it would be correct when configuring a credential store or connection account, not as a link source.

System time

Why it fails: System time is a runtime clock value, not a field, token or variable that a workflow action can resolve into a link. It is tempting because time often drives workflow scheduling, and it would be correct when configuring a time-based trigger or condition, not when building a link's source.

where field == /value/i

Why it fails: The where clause does not accept bare regex literals with trailing flags; that syntax belongs to the search command's term matching. It is tempting because it mirrors familiar JavaScript and Perl regex notation, and would be correct in search, but where needs match(field, "(?i)value").

where field = '(?i)value'

Why it fails: The where clause evaluates expressions, and a quoted string with an inline flag is treated as a literal comparison, not a regex match. It is tempting because inline flags work in the search command's regex syntax, and would be correct there, but where requires the match function or a regex literal.

where field.case = "ignore"

Why it fails: Splunk fields have no case attribute, so this syntax references a nonexistent field and returns no results. It is tempting because it resembles configuration-style case settings, and would be correct in systems offering per-field case configuration, but SPL handles case through functions like lower or match.

Enable `popup` in the workflow action configuration.

Why it fails: There is no `popup` setting for workflow actions. Splunk workflow actions use `target` to control window behavior. Enabling a nonexistent setting would not resolve the issue. The correct approach is to set `target` to `_blank` to open the link in a new tab.

Set `link.uri` to include `target="_blank"` as an HTML attribute.

Why it fails: Workflow action URIs are plain URLs, not HTML anchors. Adding HTML attributes to the URI would break the link or be treated as part of the query string. The correct way to open in a new tab is to use the separate `target` configuration field, not to embed HTML attributes in the URI.

Change the action type from `link` to `search`.

Why it fails: Changing the action type to `search` would run a search instead of opening a URL, which does not meet the requirement. The action type `link` is correct for opening an external URL. The issue is the browser target, which is controlled by the `target` setting. Changing the action type would not open the external site.

It determines the refresh rate

Why it fails: Max Time bounds how far back the acceleration searches, defining the earliest event time covered, not how often the model rebuilds. It is tempting because both settings appear under acceleration configuration, and refresh rate suits controlling rebuild frequency, but Max Time governs the searchable time window.

It limits the number of events indexed

Why it fails: Max Time defines the earliest time boundary for which the acceleration summary is built, not an event-count cap; indexing volume is governed by licence and index settings. It is tempting because acceleration does summarise indexed data, but the parameter controls the summary's time span, so it would be the right choice when limiting how far back a model accelerates.

It restricts search execution time

Why it fails: Max Time sets the earliest timestamp covered by the acceleration summary, not a search timeout; search execution limits come from dispatch settings such as max_searches_per_cpu or the search job's time-to-live. It is tempting because acceleration affects query speed, but the parameter bounds the summary's time range, so it would be correct when defining how far back summaries are built.

KV Store lookups can only be created by uploading a CSV file through the Splunk web interface.

Why it fails: KV Store lookups are created as collections, not by uploading CSV files. Data can be inserted via REST API, the UI, or by using the outputlookup command with a KV Store lookup definition. Uploading a CSV file creates a CSV lookup, not a KV Store lookup.

KV Store lookups require a lookup definition with a case-sensitive match setting to be configured in transforms.conf.

Why it fails: While KV Store lookup definitions are configured in transforms.conf, case sensitivity is not a required setting. The default behavior depends on the KV Store collection's field types and the lookup definition settings. Case sensitivity can be controlled, but it is not mandatory for basic KV Store lookups.

KV Store lookups automatically replicate data across all search heads in a distributed environment without additional configuration.

Why it fails: KV Store replication in a distributed environment requires configuration of the KV Store replication factor and proper sharding. It does not happen automatically across all search heads. In a search head cluster, KV Store replication is managed by the cluster but must be configured appropriately.

hidden="$token$"

Why it fails: Splunk panel XML has no hidden attribute; visibility is controlled by the depends and rejects attributes, which evaluate a token condition. A hidden attribute would be tempting if you assumed a simple boolean-style toggle, but that syntax does not exist in Simple XML.

visible="$token$"

Why it fails: Simple XML panels expose no visible attribute; conditional display uses depends and rejects with a token expression. A visible attribute would seem logical for toggling a panel, but Splunk evaluates token conditions through depends, not a visibility flag.

show="true"

Why it fails: show="true" is a static boolean and cannot reference a token, so the panel never reacts to token value changes. It would be tempting as an obvious display toggle, but Splunk's conditional panel rendering requires depends or rejects with a token expression.

Use a field alias in `props.conf` to map `username` to `user`.

Why it fails: Field aliases simply provide an additional name for an existing field; they do not transform the value. If `user` contains `DOMAIN\username`, aliasing it to `username` would result in `username` having the same value, including the domain prefix. This does not meet the requirement of stripping the domain. Field aliases are useful for normalization across sourcetypes but cannot perform string manipulation.

Define a search-time field extraction using a regular expression in `props.conf` with `EXTRACT-username = (?<username>[^\\\\]+)$`.

Why it fails: While a regex extraction could capture the username portion, it would create a new field `username` only if the pattern matches. However, this extraction would also apply to events where `user` does not have a domain prefix, potentially causing unexpected matches. Moreover, it does not conditionally strip the domain; it always extracts the last segment after a backslash. This could lead to incorrect values if the username itself contains a backslash. Calculated fields with `replace()` are more precise for this transformation.

Create a lookup table that maps `user` to `username` and configure an automatic lookup.

Why it fails: A lookup table could map known `user` values to `username` values, but it would require maintaining a static list of all possible users, which is impractical and does not dynamically strip the domain prefix. Automatic lookups add overhead and are not designed for real-time string manipulation. This method would fail for new or unexpected user values and is not efficient for this scenario.

The lookup is set to read-only.

Why it fails: Read-only status governs whether the lookup file can be written to, not whether its contents are read and applied during search-time field enrichment. It is tempting because write failures are a familiar lookup problem, and it would be correct if the automatic lookup needed to update or overwrite entries in the table.

The lookup is shared globally.

Why it fails: Global sharing is a valid, common configuration for automatic lookups and does not prevent population; the failure lies in the lookup's permissions or the user's role lacking access to the lookup definition. Global sharing is tempting because permissions are a frequent cause, and it would be correct if the lookup were private to another app.

The lookup table file is too large.

Why it fails: Large lookup files still populate; size affects search performance and memory, not whether the automatic lookup matches and adds fields. It is tempting because oversized lookups cause known issues, and it would be correct if the file exceeded the lookup size limit and Splunk refused to load it.

They don't require lookup definitions.

Why it fails: Both lookup types require a lookup definition to map fields and configure matching; KV Store collections are referenced through the same transforms.conf stanza mechanism. The genuine advantage is that KV Store supports inserts, updates and deletes via REST, which CSV files cannot perform.

They use less disk space.

Why it fails: KV Store lookups store collections in the app's key-value store, consuming additional indexer or search head resources rather than reducing disk usage. They are correct when lookups need frequent updates or larger datasets that CSV files handle poorly.

They are faster for static data.

Why it fails: KV Store lookups read from an indexed, persistent collection, so they suit frequently changing data rather than static files; CSV lookups already handle static data efficiently by loading the file into memory. Speed on unchanging data is not the axis of difference — mutability and write-back are.

Lookups cannot be used with stats.

Why it fails: Lookups work fine alongside stats; you can pipe stats output into lookup or use lookup before aggregation. The claim misstates the limitation, so it cannot justify join. It is tempting because lookup and stats are often confused, yet lookup is correct when enriching events from a static CSV or KV Store table.

Joins are faster than lookups.

Why it fails: Join is generally slower, not faster, because it runs a subsearch with row and time limits before matching. Speed is not its advantage over lookup. It is tempting since join feels like a database operation, but join is correct when the subsearch must return multiple matching fields per event.

Joins are automatically cached.

Why it fails: Splunk's join does not cache its subsearch results; it runs the subsearch and enforces limits, whereas lookup files are the cached mechanism. It is tempting because caching sounds like a performance win, and join would be correct when correlating events where the subsearch returns fewer than 50,000 rows.

Joins only work on numerical fields.

Why it fails: Joins match on any field type, including strings, so this restriction does not exist. The real limitation concerns subsearch result caps and performance. It tempts because field-type mismatches do cause silent join failures, making a numeric-only rule sound plausible to anyone who has hit that error.

Joins are deprecated in Splunk.

Why it fails: Splunk still supports join; it is discouraged for large datasets rather than removed. The actual limitation is subsearch result caps and performance at scale. It tempts because Splunk documentation steers users towards stats and transaction, which reads like deprecation guidance to anyone skimming release notes.

Joins cannot be used with subsearches.

Why it fails: Joins explicitly accept a subsearch as the second argument, so this is false. The genuine limitation is that the subsearch returns a capped result set and the join runs against a single field pair. It tempts because subsearch truncation errors are common, so blame lands on subsearches rather than the join itself.

They are identical commands.

Why it fails: They differ in a concrete way: timechart always produces a time-ordered x-axis with span-based binning, while chart aggregates by any field without time bucketing. Timechart is correct when the question requires a trend over time; chart suits categorical comparisons.

Chart is for time-based data.

Why it fails: Reversed: chart plots metrics over any split-by field, not specifically time. Timechart is the command that bins results into time intervals on the x-axis. Chart is the correct choice when visualising a metric grouped by a categorical field such as host or status.

Timechart is for non-time fields.

Why it fails: Reversed: timechart requires the _time field and always plots against time; chart handles non-time fields such as host or sourcetype. Chart is the correct command for splitting a metric by a categorical dimension rather than producing a time series.

props.conf

Why it fails: Manual tag assignment is stored in tags.conf, not props.conf. props.conf governs parsing, field extraction and index-time settings; it cannot create tag definitions. It is tempting because props.conf is the usual place to configure field behaviour, and it would be correct when defining field aliases, calculated fields or lookup-based extractions rather than tagging.

eventtypes.conf

Why it fails: Tags are assigned in tags.conf, which maps tag names to field-value pairs; eventtypes.conf defines named search terms for event categorisation instead. It is tempting because event types group similar events for reuse in searches and alerts, so tagging an event type feels related. However, event types cannot assign tags to field-value pairs.

transforms.conf

Why it fails: Transforms.conf defines field extractions and lookups, not tag assignments; it cannot attach a tag to a specific field-value pair. It is tempting because transforms.conf is the correct place for lookup definitions and calculated field logic, but manual tagging belongs in props.conf using the TAG attribute.

Macros are expanded by the Indexer

Why it fails: Macro expansion happens in the search head's search-time pipeline, not on the indexer, which only parses raw data into index-time fields before any search runs. It is tempting because indexers do perform index-time field extraction, so users assume all processing occurs there; that applies to index-time configurations, not search-time macros.

Macros are expanded by the browser

Why it fails: Macro expansion occurs in the search head's search-time processing, not in the browser, which merely renders results returned by Splunk. It is tempting because browser-side JavaScript builds parts of the interface, so users assume client processing; that applies to dashboard rendering, not to search-language macro substitution.

Macros are expanded after the search finishes

Why it fails: Macro expansion happens during search parsing, before the search executes, so a macro cannot be expanded after completion. This option confuses expansion with post-processing. Macros are resolved at parse time, which is why arguments and definitions must be valid before the search runs.

where

Why it fails: 'where' filters search results by a boolean expression and returns matching events; it is a search command, not an aggregation function, so it cannot compute values across a result set. It is tempting because it appears inside stats-style pipelines. It would be correct when you need to filter events before aggregating them.

rename

Why it fails: rename is a Splunk search command that changes field names in results; it performs no aggregation and cannot be used inside a stats clause. It tempts because it appears alongside stats in pipelines and manipulates fields. rename would be correct when relabelling output fields after aggregation, not as the aggregating function itself.