Lookup Fundamentals

• ✓ A.The lookup command can be used to add fields from a lookup table to search results
• B.External lookups can only be used with CSV files
• ✓ C.KV store lookups support real-time updates during a search
• D.CSV lookups can be updated in real-time by adding rows to the CSV file
• E.Automatic lookups are configured in macros.conf

Why A: Option A is correct because the `lookup` command in Splunk is specifically designed to enrich search results by adding fields from a lookup table (such as CSV, KV Store, or external lookups) based on matching field values. This is a fundamental use case for lookups in Splunk, allowing you to augment raw event data with additional context from a static or dynamic source.

• A.Lookups can only add new fields to events; they cannot replace existing field values.
• B.External lookups can only retrieve data from CSV files.
• ✓ C.KV Store lookups require defining a collection in collections.conf.
• ✓ D.CSV lookups can be updated by replacing the CSV file without restarting Splunk.
• E.Lookup files can only be stored in $SPLUNK_HOME/etc/system/lookups/.

Why C: CSV lookups can be updated by replacing the file; Splunk automatically reloads them. KV Store lookups require a collection definition in collections.conf. The other options are false: lookup files can be stored in app directories, external lookups can connect to various data sources via scripts, and lookups can replace field values if configured with overwrite=true.

• A.Lookups can only be defined by administrators.
• ✓ B.A lookup definition can include time-based expiration.
• C.Lookups are case-sensitive by default.
• ✓ D.Lookups can be defined from CSV files or KV store collections.
• E.Lookups can only be used in the 'lookup' command.

Why B: Options B and D are correct. B: A lookup definition can include time-based expiration, allowing lookups to automatically refresh after a specified period. D: Lookups can be defined from CSV files or KV store collections, providing flexibility in data sources. A is false because lookups can be defined by power users and administrators, not just administrators. C is false because lookups are case-insensitive by default, not case-sensitive. E is false because lookups can be used in multiple commands such as 'lookup', 'inputlookup', and 'outputlookup'.

• A.Define the lookup in props.conf with an automatic lookup stanza.
• B.Use the inputlookup command in a search.
• ✓ C.Define the lookup in transforms.conf with a filename and field mapping.
• D.Use the lookup command with the file path.
• E.Use the eval command with the lookup function directly in search.

Why C: To make a lookup table available in all searches, the lookup definition must be created in transforms.conf. This file defines the lookup table filename, field mapping, and other properties. Once defined, the lookup can be used with the lookup command, the inputlookup command, or automatic lookups configured in props.conf. Option C correctly identifies this requirement.

• A.lookup ip_host.csv hostname OUTPUT ip
• B.lookup ip_host.csv hostname as hostname ip as ip_output
• C.inputlookup ip_host.csv
• ✓ D.lookup ip_host.csv ip as ip_output hostname as hostname_output

Why D: Option D is correct because the lookup command syntax for mapping multiple fields is 'lookup <lookup-table> <input-field1> as <output-field1> <input-field2> as <output-field2>'. Here, 'lookup ip_host.csv ip as ip_output hostname as hostname_output' correctly maps the ip field from your data to ip_output in the lookup, and hostname from the lookup to hostname_output. Option A incorrectly uses OUTPUT, which is used for single field output. Option B has reversed order and missing output alias. Option C returns all rows without mapping.