Explanation:
In Splunk, lookups are used to enrich search results with additional data from external sources (e.g., CSV files, KV Store, or scripts). To determine which statements are not true, we need to evaluate each option against Splunk’s lookup functionality. Below is a detailed analysis of each option, identifying which are false.

Analysis of Each Option:
A. Lookups can be time based:
Not true (False):
Lookups in Splunk are not inherently time-based. Lookup tables (e.g., CSV files or KV Store) are static or semi-static datasets that map field values to additional fields (e.g., user_id to username). They do not have a built-in time component like time-based searches or indexed data. While lookups can include a time field (e.g., a column with timestamps), this does not make them “time-based” in the way Splunk uses the term (e.g., like timechart or _time in events). Splunk does support time-based lookup definitions for specific use cases (e.g., matching events to a lookup based on a time range), but this is an advanced feature requiring specific configuration (e.g., TIME_FIELD in transforms.conf), not a default property of lookups.
For the Splunk Core Certified User (SPLK-1001) exam, lookups are typically considered static mappings, not time-based, making this statement misleading or false in the general context.
Conclusion:
This statement is not true in the context of standard lookup functionality.
B. Search results can be used to populate a lookup table:
True:
Splunk allows search results to populate lookup tables using the outputlookup command. This command writes the results of a search to a lookup file (e.g., a CSV or KV Store), overwriting or appending to the existing data.
Example:
textindex=web | stats count by user_id | outputlookup users.csv
This creates or updates users.csv with user_id and count columns based on the search results.
Conclusion:
This statement is true, so it does not apply as an answer to “not true.”
C. Splunk DB Connect can be used to populate a lookup table from relational databases:
True:
Splunk DB Connect is an add-on that allows Splunk to interact with relational databases. It can be used to pull data from a database table and populate a Splunk lookup table (e.g., a CSV or KV Store) using a database query.V Example:
A DB Connect input can run a SQL query (e.g., SELECT user_id, username FROM users) and save the results to a lookup file using outputlookup or directly as a KV Store collection.
Conclusion:
This statement is true, so it does not apply as an answer to “not true.”
D. Output from a script can be used to populate a lookup table:
True:
Splunk supports external lookups (scripted lookups), where a script (e.g., Python) generates data dynamically to populate a lookup table. Additionally, a script can generate data that is written to a lookup file using outputlookup or other mechanisms.
Example:
A Python script can output a CSV file, which is then uploaded to Splunk as a lookup table via Settings > Lookups > Lookup table files.
Conclusion:
This statement is true, so it does not apply as an answer to “not true.”
E. Lookup have a 10mg maximum size limit:
Not true (False):
Splunk does not impose a 10MB (megabyte) maximum size limit on lookup files by default. Lookup files (e.g., CSV files or KV Store collections) can be much larger, though performance may degrade with very large files (e.g., hundreds of MB or GB).
The size of lookup files is typically limited by system resources (e.g., disk space, memory) or configuration settings (e.g., max_memtable_bytes in limits.conf for in-memory lookups), but there is no specific 10MB limit hardcoded in Splunk.
The question’s phrasing (“10mg”) likely contains a typo, intending “10MB” (megabytes) rather than “10mg” (milligrams, which is irrelevant to file sizes). Even assuming “10MB,” this statement is false as no such limit exists by default.
Conclusion:
This statement is not true due to the incorrect size limit claim.

Final Answer:
The statements that are not true about lookups are:
A. Lookups can be time based (not true in the standard sense, as lookups are not inherently time-based).
E. Lookup have a 10mg maximum size limit (false, as there is no 10MB or 10mg limit).
Thus, the correct selections are A and E.
Additional Notes:

Lookups overview:
Lookups are static or semi-static datasets (e.g., CSV files, KV Store) used to enrich events with additional fields at search time.
Common commands:
lookup (enrich events), inputlookup (retrieve lookup contents), outputlookup (write to lookup).

ime-based lookups:
Advanced configurations allow time-based lookups (e.g., using TIME_FIELD in transforms.conf), but this is not a default feature and requires specific setup, making option A misleading for SPLK-1001.
SPLK-1001 context:
For the Splunk Core Certified User exam, understanding lookup functionality, including how they are populated and their limitations, is key. The exam may test misconceptions like incorrect size limits or advanced features like time-based lookups.
Verification:
Test outputlookup: Run index=web | stats count by user_id | outputlookup test.csv to confirm search results can populate a lookup.
Check DB Connect or scripted lookups in Splunk documentation to verify options C and D. Confirm no 10MB limit exists by uploading a large CSV file (>10MB) to Settings > Lookups > Lookup table files.

Reference:
Splunk Documentation: About lookups
Splunk Documentation: outputlookup command
Splunk Documentation: Splunk DB Connect
Splunk Documentation: External lookups

Explanation:
Lookups do not overwrite your raw event data. They are applied at search time, meaning they temporarily enrich search results by adding fields from external sources—such as CSV files, KV store collections, or scripted outputs. This enrichment is non-destructive and does not modify the indexed data.

For example:
spl
index=web_logs | lookup user_roles userid OUTPUT role
This adds the role field to matching events based on userid, but the original event remains unchanged in the index. If you rerun the search without the lookup, the added field will not appear.
Lookups are ideal for mapping codes to descriptions, joining metadata, or enhancing visibility—but they never alter the raw event stored in Splunk.

❌ Why “True” Is Incorrect:
Lookups are search-time only
❌ They do not persist changes to indexed data.
Raw events are immutable once indexed
❌ Splunk’s indexing model ensures data integrity; lookups cannot overwrite or replace raw event content.

📚 References:
Splunk Docs – About lookups
Splunk Docs – lookup command

Explanation:
For any lookup to function—automatic or manual—a shared key is mandatory to link events to the lookup table. This key is the input field.
The lookup process works by taking a value from a field in your event (e.g., user_id) and matching it against a corresponding key column in the lookup table. When a match is found, the lookup appends the related fields from the table (e.g., department, email) to the event. Without this common input field to perform the join, the lookup operation has no basis for correlating data and will fail.

Why the Other Options Are Incorrect:
A) Source type:
A source type is a property of your main event data, not a requirement for the lookup file itself. While you often configure an automatic lookup for a specific source type, the lookup file (e.g., a CSV) is a standalone data source and does not need a source type defined.
B) At least five columns:
This is false. A lookup file can be effective with just two columns: one for the input key (e.g., product_id) and one for the output value to append (e.g., product_name). The number of columns is determined by your enrichment needs, not a mandatory minimum.
C) Timestamp:
A timestamp is not a mandatory column. Lookups are designed for reference data (like IP addresses to locations or user IDs to names), not time-series data. The correlation is based on the key field match, not a temporal join.

Reference
Splunk Documentation: About lookups
This page explains that a lookup defines "how to match fields from your events with fields in the lookup table," establishing the input field as the foundational component. It states, "The lookup matches the values in your events to the values in the lookup table and then adds the additional fields from the lookup table to your events based on that match," which is impossible without a designated input field.

Explanation:
In Splunk, DELETE permissions for knowledge objects—such as saved searches, reports, dashboards, and lookups—are not granted to all users by default. Permissions are governed by role-based access control, and only users with appropriate roles (e.g., admin) can delete certain objects.

By default:
Admins typically have full permissions, including read, write, and delete.
Power users may have read and write access but not delete for all objects.
Regular users often have limited access and cannot delete shared or global knowledge objects unless explicitly granted.
This ensures that critical content like shared dashboards or scheduled reports isn’t accidentally removed by unauthorized users.

❌ Why “True” Is Incorrect:
DELETE is a sensitive permission
❌ Allowing all users to delete knowledge objects would compromise data integrity and collaboration.
Permissions must be explicitly configured
❌ Splunk uses metadata and access control lists to manage who can delete what.

📚References:
Splunk Docs – Manage knowledge object permissions

Explanation:
In Splunk, knowledge objects (e.g., saved searches, reports, dashboards, lookups, event types, tags, and field extractions) can have different sharing levels: private (accessible only to the creator), app (shared within a specific app), or global (shared across all apps). The ability to create global knowledge objects depends on the user’s role and its associated permissions. Let’s evaluate each option based on Splunk’s default roles and capabilities.

Why are B and C correct?
Splunk roles and permissions:
Splunk uses a role-based access control (RBAC) system, where roles like user, power, and admin have different capabilities.
Creating global knowledge objects requires the capability to share objects at the global level, which is typically granted to roles with higher privileges.
B. Power users:
The power role in Splunk is designed for users who need to create and manage knowledge objects beyond private scope.
By default, power users have the capability to share knowledge objects globally (e.g., via Settings > Knowledge objects > Permissions or by setting objects to “All apps” in Splunk Web). Capabilities include:
Creating saved searches, reports, dashboards, lookups, etc.
Sharing these objects at the app or global level.
Example:
A power user can create a report and set its permissions to “All apps” (global), making it accessible to all users across all apps.
Conclusion:
Power users can create global knowledge objects, so B is correct.
C. Administrators:
The admin role has the highest level of permissions in Splunk, including all capabilities of the power role and additional administrative privileges.
Administrators can create any knowledge object and share it globally by setting permissions to “All apps.”
They also have the ability to manage permissions for all knowledge objects, including those created by other users.
Example:
An admin can create a global lookup table (e.g., users.csv) or a dashboard shared across all apps.
onclusion:
Administrators can create global knowledge objects, so C is correct.

Why is A incorrect?
A. Users:
The user role in Splunk is the most restrictive default role, designed for basic search and reporting tasks.
By default, users can create knowledge objects (e.g., saved searches, reports, or dashboards), but these are typically private (accessible only to the creator) or, at most, shared within the app context (e.g., Search & Reporting app) if permissions allow.
Users do not have the capability to share knowledge objects globally (i.e., set to “All apps”) by default, as this requires specific capabilities (e.g., write_all_objects or similar) that are assigned to power or admin roles.

Example:
A user can create a report and share it within the Search & Reporting app, but they cannot make it global across all apps unless their role is modified to include additional permissions.
Conclusion:
Users cannot create global knowledge objects by default, so A is incorrect.

Additional Notes:
Knowledge object sharing levels:
Private:
Only the creator can access the object.
App:
Accessible to users with access to the specific app (e.g., Search & Reporting).
Global (All apps):
Accessible to all users across all apps, requiring higher privileges.

Custom roles:
Organizations can create custom roles with specific capabilities. If a custom “user” role is granted global sharing permissions (e.g., write_all_objects), users could theoretically create global knowledge objects, but this is not standard for the default user role. For SPLK-1001, the focus is on default roles (user, power, admin), so we assume standard configurations.

How to create global knowledge objects:
In Splunk Web, create a knowledge object (e.g., via Save As > Report or Settings > Lookups). Set permissions to “All apps” under Permissions (requires power or admin role). Example:
A power user creates a dashboard and sets its sharing to “All apps” to make it globally accessible.
SPLK-1001 context:
For the Splunk Core Certified User exam, understanding the capabilities of default roles (user, power, admin) and their ability to create and share knowledge objects is critical. The exam often tests knowledge of permissions and sharing scopes.
Verification:
Check role capabilities in Splunk Web under Settings > Roles to confirm that power and admin roles have permissions to share objects globally, while user does not.
Test by creating a report as a user and checking if “All apps” is an available sharing option (it won’t be for the user role).

Reference:
Splunk Documentation: Roles and capabilities
Splunk Documentation: Manage knowledge object permissions
Splunk Documentation: About knowledge objects

Explanation:
In Splunk, users do not have WRITE permission to all knowledge objects by default. Permissions are governed by object ownership, role-based access control (RBAC), and sharing settings. Only the owner of a knowledge object or users with explicitly granted WRITE access can modify it. This ensures secure and controlled management of shared resources across apps and users.

✅ Why B Is Correct
Splunk uses access control lists (ACLs) to manage permissions for knowledge objects such as saved searches, dashboards, event types, tags, and lookups. Each object has:
Owner:
The user who created the object.
Sharing level:
Private, App, or Global.
Permissions:
Read and/or Write, assigned to specific roles. By default, when a user creates a knowledge object, it is private and only accessible to that user. Even when shared at the app or global level, WRITE access must be explicitly granted to other roles. This prevents unauthorized edits and ensures operational integrity.
For example
, a dashboard created by user A and shared at the app level will be visible to other users in the same app, but only users with WRITE permission (via their role) can modify it. This behavior is consistent across all knowledge object types.

Splunk’s documentation confirms this:
“By default, only the owner of a knowledge object has write access to it.” — Splunk Docs: Manage Knowledge Object Permissions
“Permissions are assigned to roles, not individual users.” — Splunk Docs: About Users and Roles

❌ Why A Is Incorrect
A. True implies that all users can modify all knowledge objects, which is not how Splunk operates. This would violate basic security principles and lead to uncontrolled changes across shared dashboards, reports, and saved searches. Splunk enforces strict access controls to prevent such risks.
Even users with elevated roles like power or admin must have WRITE permission granted at the object level or via role configuration. Without it, they cannot edit or delete knowledge objects they do not own.

🔍 Supporting Details
Splunk’s RBAC model ensures that:
Object visibility is controlled by sharing level (private, app, global).
Object modification is controlled by WRITE permission.
Roles define what users can see and do, not the users themselves.
For example:
A saved search shared globally but without WRITE permission for the user role will be visible but not editable by users with that role.
An event type created by a user and kept private will be invisible to others, regardless of their role.
This design supports multi-user environments, compliance, and auditability.

🧠 Real-World Scenario
In a security operations center (SOC), analysts create dashboards to monitor threat activity. These dashboards are shared globally for visibility. However, only users with the admin or security_manager role (with WRITE access) can modify them. This prevents accidental or unauthorized changes during active investigations.

📝 Summary
Splunk does not grant WRITE access to all users by default. Permissions are tightly controlled through:
Object ownership Role-based access
Explicit sharing and permission settings
This ensures secure, reliable, and auditable management of knowledge objects across teams and apps.

📚 References
Splunk Docs – Manage Knowledge Object Permissions
Splunk Docs – About Users and Roles
Splunk Docs – Knowledge Object Sharing

Explanation:
This question tests your understanding of the components that make up a Data Model object in Splunk.
In a Splunk Data Model, an Object is built from two primary components:
Attributes
Constraints

Why Option A is Correct:
Object Attributes define the fields (or data structure) of the object. They specify what data points are available for analysis. Attributes do not define the base search. The base search is defined by the Constraints.
Attributes = The "what" – the fields and their types (e.g., clientip, duration, status_code).
Constraints = The "how" – the search filters that populate the object with data (e.g., sourcetype=access_combined).
Therefore, Attributes do not define the base search.

Why Option B is Incorrect:
Object Attributes do define the fields for the object. This is their primary purpose. When you add a field to an object's attributes, you are explicitly defining it as part of that object's structure.

Reference:
Splunk Documentation: About Data Models
This page explains the structure: "A data model object is defined by two things: Constraints and Attributes." It clarifies that constraints are the "search filters" (the base search), while attributes "define the fields of the object." This directly confirms that attributes define fields but do not define the base search.

Explanation:
In Splunk data models, the fields associated with a dataset are called Attributes. These represent the individual data elements—such as username, ip_address, status_code, or action—that are extracted from events and used for analysis, reporting, and pivoting. Attributes define the structure of the dataset and are essential for building meaningful visualizations and searches within the data model framework.
Attributes can be added manually or derived automatically from event data. They support field aliases, calculated fields, and constraints, and they are the foundation for working with datasets in Pivot and other knowledge objects. Each attribute is tied to a specific field in the underlying event data and can be configured with display names, data types, and evaluation expressions.

This is confirmed in Splunk’s official documentation:
“Attributes are the fields that you define for a dataset. You can define attributes manually or derive them from the event data.” — Splunk Docs: Manage normalized schemas with data models

❌ Why B. Constraints Is Incorrect
Constraints in Splunk data models are not fields. Instead, they are filters that define the scope of the dataset by specifying which events should be included. For example, a constraint might be sourcetype=access_combined or index=security, which limits the dataset to events matching those criteria.
Constraints are applied at the root event dataset level or to child datasets to narrow down the data being modeled. They do not represent individual fields or attributes and cannot be used in Pivot or visualizations directly.

Splunk documentation clarifies this distinction:
“Constraints are search filters that define the scope of the dataset. They determine which events are included in the dataset.” — Splunk Docs: About data models

Summary|:
Attributes are the correct term for fields in a Splunk data model. They represent the data elements extracted from events and used for analysis.
Constraints are search filters that define which events are included in the dataset. They are not fields and cannot be used like attributes.
Understanding this distinction is essential for configuring and using data models effectively in Splunk, especially when preparing for the SPLK-1001 exam.

References:
Splunk Docs – About data models

Explanation:
In Splunk’s architecture, the indexer is responsible for reducing search results by performing search-time filtering, event retrieval, and field extraction. When a search is initiated, the search head distributes the query to indexers, which scan their local data and return only the relevant subset of results—not the entire dataset.
This process is called search result reduction, and it’s crucial for performance and scalability. Indexers handle:
Raw data parsing
Indexing and storage
Search-time filtering
Field extraction
Partial result aggregation
By reducing the volume of data sent back to the search head, indexers optimize bandwidth and memory usage, especially in distributed environments.

❌ Why Other Options Are Incorrect:
A. Search heads
❌ Search heads coordinate and display results but do not reduce them. They receive filtered data from indexers and handle final formatting, visualization, and user interaction.
C. Forwarders
❌ Forwarders send data to indexers but do not participate in search execution or result reduction. Their role is ingestion, not querying.

📚 Valid References:
Splunk Docs –Distributed search

Explanation:
This question tests your understanding of the core responsibilities of the main Splunk components in the data pipeline.

Why Option B is Correct:
Indexers are the workhorses of the Splunk platform responsible for the core data processing and storage functions:
Parsing Incoming Data: When an indexer receives raw data (either directly from a forwarder or another source), it processes the data pipeline. This includes:
Breaking the data into individual events.
Identifying timestamps.
Extracting fields like host, source, and sourcetype.
Applying custom parsing and transformations based on configurations (props.conf, transforms.conf).
Storing Data on Disk: After parsing, the indexer writes the processed events to its repository on disk, known as an index. It creates both the raw data files and the index files (tsidx) that enable fast searching.

Why the Other Options Are Incorrect:
A) Forwarders:
Universal Forwarders and Heavy Forwarders are responsible for collecting and sending data. They have a very limited role in parsing (mainly for line-breaking and some rudimentary metadata assignment like source and host). They do not store data on disk for long-term retention and searchability; their primary job is reliable data transportation.
C) Search Heads:
Search heads are responsible for coordinating searches, managing user requests, and presenting results. They do not parse incoming raw data for indexing, nor do they store the primary data on disk. They may cache some knowledge objects or search results temporarily, but this is not their primary function.

Reference:
Splunk Documentation: How the Splunk platform processes and stores data
This page details the data pipeline, showing that the indexing phase (handled by indexers) is where parsing, indexing, and writing to disk occur.
Splunk Documentation: How the Splunk platform works
This resource outlines the roles, clearly stating that indexers "index the data, creating the .tsidx and compressed rawdata files," which is the act of parsing and storing on disk.

Explanation:
In Splunk, sourcetype is the key attribute used to categorize data during indexing. It defines the format and structure of incoming events, allowing Splunk to apply appropriate parsing rules, field extractions, and timestamp recognition. This ensures consistent interpretation of data across searches, dashboards, and alerts.
For example, logs from Apache web servers might be assigned sourcetype=access_combined, while Cisco firewall logs could use sourcetype=cisco:asa. By assigning the correct sourcetype, Splunk knows how to break events, extract fields, and normalize data for search-time operations.
This categorization is essential for accurate field discovery, efficient searching, and reliable reporting. Without a proper sourcetype, Splunk may misinterpret the data, leading to broken events or missing fields.

❌ Why Other Options Are Incorrect:
B. index
❌ The index determines where data is stored, not how it’s categorized. While important for search scope and retention policies, it doesn’t define the data’s structure or format.
C. source
❌ The source refers to the origin of the data, such as a file path (/var/log/syslog) or input stream. It helps identify where the data came from but doesn’t control parsing or categorization.

D. host
❌ The host identifies the system that generated the data, like web01 or fw02. It’s useful for filtering and grouping but doesn’t influence how Splunk interprets the event format.

📚 Valid References:
Splunk Docs – About sourcetypes
Splunk Docs – Data inputs and indexing

Explanation:
This question tests your understanding of Splunk's deployment architecture and the capabilities of a single instance.

Why the Answer is False:
A single instance of Splunk (often referred to as a "standalone" deployment) is fully capable of performing all the core functions of the Splunk platform by itself. This includes:
Input:
It can collect data from files, network ports, scripts, and other inputs directly.
Parsing:
It processes the raw data, breaking it into events, extracting timestamps, and applying field extraction rules.
Indexing:
It writes the parsed data to its local indexes on disk.
Searching:
It allows users to search and analyze the data it has stored.
In fact, a single-instance deployment is the standard starting point for many users and is perfectly valid for smaller environments. The distributed roles (Forwarder, Indexer, Search Head) exist to scale out these functions for high-volume, high-availability, or distributed data collection scenarios, but they are not a requirement for the basic operation of the software.
Conclusion:
The statement is false because a single Splunk instance can indeed manage input, parsing, and indexing.

Reference:
Splunk Documentation: Splunk Enterprise components
This page describes the different components (Forwarder, Indexer, Search Head) but also implicitly confirms that a single instance can perform all roles, as distributed deployments involve separating these functions from a standalone instance. The very existence of a "standalone deployment" model confirms that a single instance can handle the entire data pipeline.