• Home
• Splunk Exams
• SPLK-1005 - Splunk Cloud Certified Admin

SPLK-1005 Splunk Practice Test Questions and Exam Dumps

Question 1

When setting up monitoring for directories that include various file types, which setting should be excluded from inputs.conf and instead be managed through props.conf for proper event classification?

A. sourcetype
B. host
C. source
D. index

Correct answer: A

Explanation:

In Splunk, the configuration files inputs.conf and props.conf are essential for data ingestion and parsing. Each file serves a distinct purpose in the data pipeline, and knowing where to define certain settings—especially in complex environments like those involving mixed file types—is critical for accurate data classification and event handling.

When monitoring directories that contain mixed file types (e.g., CSV logs, JSON logs, application logs), the main challenge is that each file type likely corresponds to a different sourcetype. The sourcetype in Splunk determines how the data is parsed and interpreted. For example, different sourcetypes may use different line-breaking rules, field extractions, or timestamp formats.

Why the sourcetype Should Be Omitted from inputs.conf

If you were to set a sourcetype in inputs.conf, that value would be applied globally to all files in the monitored directory. That’s fine if the files are all the same type, but problematic when they differ. Applying a single sourcetype to mixed formats will likely result in incorrect parsing, rendering the data unreliable or unusable.

Instead, you should omit the sourcetype from inputs.conf and define rules in props.conf to assign sourcetypes dynamically based on pattern matching. This can be done by matching on file paths, filenames, or other metadata in combination with transforms.conf.

Example Scenario

Say you're monitoring the /var/log/mixed/ directory, and it contains:

• app1.log (JSON format)

• app2.log (CSV format)

• app3.log (Apache log format)

Rather than assigning a generic sourcetype in inputs.conf, you can set up your configuration like this:

This setup ensures that each file type is assigned the correct sourcetype dynamically, enabling accurate parsing and indexing.

Why Other Options Are Incorrect

• B (host): This is typically assigned in inputs.conf and doesn't need to vary based on file type.

• C (source): Like host, the source is automatically assigned by the file path or can be set in inputs.conf.

• D (index): The index is usually a consistent destination for logs and is set in inputs.conf.

In summary, when dealing with directories containing multiple file formats, you should omit the sourcetype setting from inputs.conf and manage it through props.conf with transforms, so each file type is parsed and handled correctly.

Correct answer: A

Question 2

In a managed Splunk Cloud environment, what is the correct method for configuring HTTP Event Collector (HEC) tokens?

A. Any token will be accepted by HEC, the data may just end up in the wrong index.
B. A token is generated when configuring a HEC input, which should be provided to the application developers.
C. Obtain a token from the organization’s application developers and apply it in Settings > Data Inputs > HTTP Event Collector > New Token.
D. Open a support case for each new data input and a token will be provided.

Correct answer: B

Explanation:

In Splunk Cloud (managed environment), HTTP Event Collector (HEC) is a robust method for ingesting data directly into Splunk via RESTful API endpoints. It is commonly used for integrating third-party apps, services, and custom code that pushes log or event data into Splunk.

The core component of this functionality is the HEC token, which acts as a secure identifier allowing authorized data sources to send information into Splunk. Understanding how to configure and distribute these tokens is essential for effective data ingestion and secure access management.

Let’s break down the correct process and evaluate each answer:

• Correct Process (Option B):
  In Splunk Cloud, a HEC input is created via the user interface (Settings > Data Inputs > HTTP Event Collector). During the creation of this input, you specify details such as the token name, index destination, and source type. Once the configuration is completed, Splunk generates a unique token. This token is then shared with application developers or systems that will be sending data to HEC. They will include the token in the header of their HTTP requests to authenticate and route their data correctly. This ensures a secure and traceable mechanism for data ingestion.

Now let’s analyze the incorrect options:

• Option A (Any token will be accepted by HEC):
  This is false and highly insecure. HEC only accepts valid tokens that have been explicitly configured within the Splunk environment. Using an invalid token results in authentication failure, and the data will be rejected entirely, not routed to the wrong index. This option misrepresents how token-based authentication works.

• Option C (Obtain a token from developers and apply it in Splunk):
  This reverses the correct flow. In practice, Splunk administrators generate the token and then give it to developers, not the other way around. Application developers cannot independently generate tokens valid in Splunk’s environment. Therefore, this option is incorrect.

• Option D (Open a support case for each new data input):
  While it’s true that Splunk Cloud (managed) environments may limit access to certain backend configurations, creating HEC tokens does not require a support case in most cases. Admins can create them through the standard Splunk UI unless permissions are restricted by the organization. This answer adds unnecessary steps and is not representative of typical usage.

 The proper and secure method for using HEC in Splunk Cloud is for an admin to create a HEC input, at which point a token is generated. This token is then shared with developers so they can configure their applications to send data correctly. Thus, the best and most accurate answer is B.

Question 3

Given that an Apache access log is being ingested into Splunk using a monitor input, how does Splunk determine which time zone to apply when parsing the event timestamp?

A. The value of the TZ attribute in props.conf for the access_combined sourcetype.
B. The value of the TZ attribute in props.conf for the my.webserver.example host.
C. The time zone of the Heavy/Intermediate Forwarder with the monitor input.
D. The time zone indicator in the raw event data.

Correct Answer: D

Explanation:

When Splunk ingests data, particularly from log files such as Apache access logs, one of the key steps in the parsing process is timestamp extraction, which includes determining the correct time zone. Apache access logs, especially those in access_combined format, typically include a timestamp string like:

[01/May/2025:14:45:32 -0700]

In this string:

• 01/May/2025:14:45:32 is the timestamp.

• -0700 is the time zone offset from UTC.

The correct answer is D, because Splunk relies first and foremost on the time zone indicator embedded directly in the raw event data itself. When such a time zone offset is present in the log line, Splunk parses and applies it, converting the time to UTC internally. This approach ensures that data is time-normalized across sources with varying time zones.

Let’s examine the other options and clarify why they are not correct:

A. The value of the TZ attribute in props.conf for the access_combined sourcetype.
This setting is used only when the raw event data does not contain a time zone indicator. If the event includes a clearly defined offset (like -0700), then the TZ setting is ignored. So, while you can use TZ = America/Los_Angeles in props.conf to define a time zone, it will only apply if the time zone cannot be determined from the raw data itself.

B. The value of the TZ attribute in props.conf for the my.webserver.example host.
Just like with sourcetypes, the TZ setting can be applied based on the host, but again, only if the time zone cannot be determined from the event. Since Apache access logs include the offset in the timestamp, this setting would be overridden by the raw event data.

C. The time zone of the Heavy/Intermediate Forwarder with the monitor input.
This is a common misconception. The time zone of the forwarder (Heavy or Universal) does not influence how timestamps are parsed from the data. Instead, forwarders simply send raw events and, if applicable, pre-parsed metadata to the indexer. Time zone interpretation is based on the content of the event and parsing rules, not the system clock of the machine doing the forwarding.

In summary, Splunk prioritizes the time zone indicator found in the event itself, such as the -0700 in Apache logs, for timestamp parsing. Only in cases where this indicator is missing would it fall back on configurations like the TZ attribute in props.conf. This makes raw event data the most authoritative source for time zone information during ingestion.

Therefore, the correct answer is D.

Question 4

Which syntax components must be present in inputs.conf to enable the ingestion of data from files or directories into Splunk?

A. A monitor stanza, sourcetype, and index is required to ingest data.
B. A monitor stanza, sourcetype, index, and host is required to ingest data.
C. A monitor stanza and sourcetype is required to ingest data.
D. Only the monitor stanza is required to ingest data.

Correct answer: D

Explanation:

In Splunk, the inputs.conf file is the primary configuration file used to specify how data is collected (or “ingested”) from various sources such as files, directories, network ports, and scripts. When configuring file or directory monitoring in Splunk using this file, you typically define a monitor stanza to identify the path of the file or directory you wish to monitor.

The question asks what is strictly required—not what is typically recommended or best practice. That’s a crucial distinction. While specifying additional fields like sourcetype, index, and host provides greater control and clarity, only one element is technically required: the monitor stanza itself.

Understanding the Minimum Syntax

Here is the minimum viable configuration for inputs.conf to ingest data from a file or directory:

[monitor:///var/log/syslog]

That single line is enough to start ingesting data from /var/log/syslog. When this minimal configuration is used, Splunk will apply default values for:

• sourcetype: It will attempt to auto-assign based on file characteristics or name.

• index: If not explicitly specified, the data goes into the default index.

• host: Splunk assigns the default host value based on system settings.

Therefore, from a functional perspective, only the monitor stanza is required.

Optional But Recommended Fields

Let’s review why the other fields, while commonly used, are not required:

• sourcetype: Helps Splunk apply correct field extractions and timestamp parsing rules. Best practice, but not essential.

• index: Specifies where the data will be stored. Default is used if none is specified.

• host: Identifies the source system of the data. Splunk can infer this automatically.

Evaluating the Options

• A (monitor stanza, sourcetype, and index): These are commonly used, but only the monitor stanza is required.

• B (monitor stanza, sourcetype, index, and host): Too many fields. Host is not required at all, and neither are sourcetype or index.

• C (monitor stanza and sourcetype): Again, sourcetype is useful, but not mandatory.

• D (Only the monitor stanza is required): This is the only technically correct option based on Splunk’s configuration behavior.

Practical Implications

Although only the monitor stanza is necessary for ingestion to begin, relying on default behavior can lead to unorganized or improperly parsed data, which in turn complicates search, analysis, and correlation. Therefore, while option D is correct from a technical standpoint, in real-world environments, it’s highly recommended to also include sourcetype and index at a minimum to maintain data quality and governance.

Correct answer: D

Question 5

Which of the following are valid configuration settings for file and directory monitor inputs in Splunk?

A. host, index, source_length, _TCP_Routing, host_segment
B. host, index, sourcetype, _TCP_Routing, host_regex, host_segment
C. host, index, directory, host_regex, host_segment
D. host, index, sourcetype, _UDP_Routing, host_regex, host_segment

Correct answer: B

Explanation:

In Splunk, file and directory monitor inputs are used to continuously monitor the contents of files or directories on a file system and forward the events to the indexers. These inputs are configured using a set of parameters in either the inputs.conf file or via the Splunk Web interface.

Let’s break down the valid and commonly used settings for monitoring file and directory inputs, and then analyze each of the options.

Common and valid settings for monitor inputs include:

• host: Defines the host field for the events generated by the input. Can be set manually or dynamically.

• index: Specifies the index where the events should be stored.

• sourcetype: Assigns a sourcetype to the data being ingested.

• _TCP_Routing: Advanced setting that allows routing events to specific TCP output groups, typically used in forwarding configurations.

• host_regex: Allows extracting the host value dynamically from the monitored file path using regular expressions.

• host_segment: Defines which segment of the file path should be used as the host value.

Other advanced options exist, but these are commonly used in production environments.

Now, let’s examine each option:

A. host, index, source_length, _TCP_Routing, host_segment

• host and index are valid.

• _TCP_Routing is valid for routing to specific output groups.

• host_segment is valid for dynamic host assignment.

• However, source_length is not a valid setting for monitor inputs; it does not exist in the documentation or configuration parameters for this context.

• This option is incorrect.

B. host, index, sourcetype, _TCP_Routing, host_regex, host_segment

• Every setting in this option is valid.

• host, index, and sourcetype are essential fields.

• _TCP_Routing is a legitimate advanced routing option.

• host_regex and host_segment are both used to dynamically derive the host value from file paths.

• This is the correct answer.

C. host, index, directory, host_regex, host_segment

• host, index, host_regex, and host_segment are valid.

• However, directory is not a valid configuration key. When monitoring directories, the path itself is specified as the stanza name, not as a directory parameter.

• This option is incorrect.

D. host, index, sourcetype, _UDP_Routing, host_regex, host_segment

• host, index, sourcetype, host_regex, and host_segment are valid.

• _UDP_Routing is not a valid setting in Splunk; Splunk does not support such a parameter. Routing in Splunk for network inputs generally refers to TCP forwarding mechanisms, not UDP-based configuration like _UDP_Routing.

• This option is incorrect.

The only option that includes exclusively valid and relevant parameters for configuring file and directory monitor inputs is Option B. It correctly lists standard and advanced parameters used in real-world Splunk configurations for file monitoring.

Therefore, the correct answer is B.

Question 6

Which of the following are characteristics of a managed Splunk Cloud environment?

A. Availability of premium apps, no IP address whitelisting or blacklisting, deployed in US East AWS region.
B. 20GB daily maximum data ingestion, no SSO integration, no availability of premium apps.
C. Availability of premium apps, SSO integration, IP address whitelisting and blacklisting.
D. Availability of premium apps, SSO integration, maximum concurrent search limit of 20.

Correct Answer: C

Explanation:
Splunk Cloud Platform is a fully managed, cloud-based version of Splunk Enterprise that offers scalable data analytics without the overhead of on-prem infrastructure. In a managed Splunk Cloud environment, Splunk itself is responsible for deployment, availability, scaling, and maintenance. These environments are designed to be enterprise-ready, including several critical features that support security, flexibility, and extensibility.

The correct answer is C because the following features are indeed part of the managed Splunk Cloud offering:

1. Availability of Premium Apps:
   Managed Splunk Cloud environments support premium Splunk apps such as Splunk Enterprise Security (ES), Splunk IT Service Intelligence (ITSI), and Splunk Observability Cloud integrations. These apps provide advanced capabilities like threat detection, IT monitoring, and analytics, and they are fully supported in the managed cloud offering.

2. SSO Integration:
   Managed Splunk Cloud supports Single Sign-On (SSO) integration via SAML 2.0, allowing enterprise customers to integrate with identity providers like Okta, Azure AD, and others. This supports secure and seamless user authentication and access control, which is essential for organizations with large user bases and compliance requirements.

3. IP Address Whitelisting and Blacklisting:
   Splunk Cloud supports network access control by allowing customers to define IP address allowlists (whitelists) and blocklists (blacklists). This capability is critical in restricting access to your Splunk environment based on trusted networks, improving security posture.

Now let’s analyze why the other options are incorrect:

A. While it mentions availability of premium apps, it falsely states no IP whitelisting/blacklisting—which is incorrect. Managed Splunk Cloud environments do allow both. Additionally, restricting deployment to a single AWS region like US East is not accurate; customers can choose from several supported regions across AWS and GCP depending on their needs and compliance requirements.

B. This option is entirely inaccurate. Splunk Cloud does not impose a 20GB daily ingestion cap; instead, the ingestion volume depends on the pricing plan or subscription tier. Furthermore, SSO integration is supported, and premium apps are available, making all three statements in this option incorrect.

D. While this option lists premium apps and SSO integration, it incorrectly states a maximum concurrent search limit of 20. In Splunk Cloud, concurrent search limits are configurable and scale based on subscription level and capacity planning, and are not hard-capped at 20. In fact, limits can be significantly higher for enterprise-tier customers.

In summary, the most accurate representation of a managed Splunk Cloud environment’s capabilities is option C, as it correctly reflects the features related to app support, security integration, and access control—key pillars of the managed cloud experience.

Therefore, the correct answer is C.

Question 7

Which of the following accurately describes how to configure a Universal Forwarder to act as an Intermediate Forwarder in a Splunk environment?

A. This can only be turned on using the Settings > Forwarding and Receiving menu in Splunk Web/UI.
B. The configuration changes can be made using Splunk Web, CLI, directly in configuration files, or via a deployment app.
C. The configuration changes can be made using CLI, directly in configuration files, or via a deployment app.
D. It is only possible to make this change directly in configuration files or via a deployment app.

Correct answer: C

Explanation:

In a Splunk deployment, a Universal Forwarder (UF) is a lightweight agent installed on source machines to collect and forward logs to indexers or other forwarders. When a Universal Forwarder is configured to act as an Intermediate Forwarder, it does not index data itself but simply relays the data it receives from other forwarders to another destination, typically a Heavy Forwarder or an indexer. This setup is useful for load balancing, network segmentation, or secure data transfer between firewalls.

Methods for Configuring an Intermediate Forwarder

The question centers on which tools or methods can be used to configure a UF as an intermediate forwarder. Unlike a full Splunk Enterprise instance, the Universal Forwarder does not include Splunk Web—the graphical user interface (GUI). Therefore, any option that mentions Splunk Web is automatically incorrect when applied to Universal Forwarders.

To configure a Universal Forwarder as an intermediate forwarder, you typically use the following:

• Command Line Interface (CLI): You can run CLI commands like splunk add forward-server to specify where the UF should forward data.

• Configuration Files: You can edit configuration files such as outputs.conf and inputs.conf directly to control forwarding behavior.

• Deployment Apps: If you're using a deployment server, you can push configuration bundles or apps that include outputs.conf and other relevant settings to multiple forwarders at once.

Here’s an example snippet from outputs.conf for setting up an intermediate forwarder:

[tcpout]

defaultGroup = indexerGroup

[tcpout:indexerGroup]

server = indexer1.domain.com:9997, indexer2.domain.com:9997

This setup defines a forwarding group that allows the UF to relay data downstream. If it is receiving data from other UFs (i.e., acting as an intermediate forwarder), this is sufficient.

Evaluating the Options

• A (This can only be turned on using the Settings > Forwarding and Receiving menu in Splunk Web/UI): Incorrect. The Universal Forwarder has no Splunk Web interface at all.

• B (The configuration changes can be made using Splunk Web, CLI, directly in configuration files, or via a deployment app): Incorrect. This includes Splunk Web, which is not available on Universal Forwarders.

• C (The configuration changes can be made using CLI, directly in configuration files, or via a deployment app): Correct. These are the three valid and supported methods for configuring a Universal Forwarder.

• D (It is only possible to make this change directly in configuration files or via a deployment app): Partially correct but unnecessarily restrictive. The CLI is also a valid and common method for configuration.

Therefore, the most accurate and complete answer is C, as it encompasses all valid methods for configuring a UF as an intermediate forwarder.

Correct answer: C

Question 8

What is the function of the followTail attribute when used in inputs.conf for a file monitor input in Splunk?

A. Pauses a file monitor if the queue is full.
B. Only creates a tail checkpoint of the monitored file.
C. Ingests a file starting with new content and then reading older events.
D. Prevents pre-existing content in a file from being ingested.

Correct answer: D

Explanation:

The followTail attribute in Splunk is a setting available in the inputs.conf configuration file. It is specifically used when configuring file or directory monitor inputs. This attribute plays a significant role in controlling whether previously existing content in a file is indexed when Splunk begins monitoring that file.

Let’s walk through what followTail does and analyze how it compares to the other options.

Function of followTail

When followTail = true, Splunk starts monitoring the file from the end (tail) and does not ingest any existing content that was already in the file when monitoring began. Only new data appended to the file after the monitor starts will be indexed. This setting is particularly useful when you are only interested in capturing future events and want to avoid reprocessing a potentially large backlog of existing data.

By default, followTail = false, meaning Splunk will read and index the entire content of the file from the beginning upon first discovery.

This setting is often used in the following scenarios:

• When you set up a monitor on a large log file but only care about new entries.

• When you want to simulate the behavior of the tail -f Unix command, focusing on newly added lines only.

Now, let’s evaluate the answer choices:

• A. Pauses a file monitor if the queue is full:
  This is incorrect. The followTail attribute has nothing to do with queue management or buffering. Splunk uses internal queues, but those are governed by separate mechanisms such as throughput settings or indexing pipeline configurations. followTail does not influence queue behavior.

• B. Only creates a tail checkpoint of the monitored file:
  This sounds plausible but is misleading. While followTail causes Splunk to skip to the end of the file and begin indexing from there, the phrase “only creates a tail checkpoint” is not accurate or representative of what the setting actually does. Splunk still creates a full tracking context (checkpoint), but the intent of the setting is to not ingest existing content, not to change the checkpointing behavior fundamentally.

• C. Ingests a file starting with new content and then reading older events:
  This is the opposite of what followTail does. Splunk does not read older events after new ones when followTail is enabled. Instead, it skips the old content entirely and only ingests events that appear in the file after monitoring begins. This makes the option incorrect.

• D. Prevents pre-existing content in a file from being ingested:
  This is exactly what the followTail attribute does. It ensures that Splunk starts ingesting only new events and ignores all content that existed in the file prior to the monitor's activation.

The followTail attribute is designed for cases where you want to start tailing a file from the current end point and ignore existing historical content. This prevents loading old data, making onboarding cleaner when only future logs are relevant. Among all choices, only D accurately describes this functionality.

Therefore, the correct answer is D.

Question 9

When a Change Request needs to be made in a Splunk Cloud environment, who is responsible for submitting the support case to Splunk Support?

A. The party requesting the change.
B. Certified Splunk Cloud administrator.
C. Splunk infrastructure owner.
D. Any person with the appropriate entitlement.

Correct Answer: D

Explanation:
In the context of Splunk Cloud, a Change Request (CR) refers to a formal process by which customers request changes to be made to their managed Splunk environment. This might include activities such as upgrading an app, configuring certain settings, enabling premium features, or making adjustments that require Splunk Support’s intervention in the backend infrastructure.

When it comes to submitting such requests to Splunk Support, Splunk enforces a role-based access and entitlement model. The correct policy is that only users with the appropriate entitlements assigned to their support account are authorized to submit support cases. Hence, the correct answer is D: Any person with the appropriate entitlement.

Now let’s explore the reasoning and clarify why the other options are incorrect:

A. The party requesting the change.
This might not always be valid. Just because someone wants the change does not automatically mean they are authorized to submit a Change Request. Splunk Support must verify that the person making the request has the right level of access and entitlement for security and accountability purposes. If the requester lacks proper entitlement, the request will be rejected or returned for escalation through the appropriate channels.

B. Certified Splunk Cloud administrator.
Although this seems like a plausible answer, being certified is not a determining factor in support entitlement. A certified administrator may or may not be assigned the appropriate roles in the Splunk Support Portal. Only users designated as Authorized Support Contacts (ASCs) or similarly entitled individuals can open Change Requests. Certification alone is not sufficient.

C. Splunk infrastructure owner.
The "infrastructure owner" role is ambiguous and is not a formal access level recognized by Splunk's support entitlement model. Furthermore, ownership of infrastructure doesn’t guarantee that the individual is set up as an Authorized Support Contact or has appropriate permissions. Therefore, this role does not inherently have the right to submit a Change Request to Splunk Support.

D. Any person with the appropriate entitlement.
This is the correct and official answer. Splunk’s support model requires that only users who are registered as Authorized Support Contacts (or equivalent entitlement levels) may log support cases, including Change Requests. These individuals are verified by Splunk to have the necessary authority to request changes that could impact the production environment. This ensures the integrity, security, and traceability of requested changes within a managed Splunk Cloud instance.

These authorized contacts are typically configured when the support contract is activated and can be modified by the account’s support administrator. They have access to the Splunk Support Portal, can open cases, and interact with Support Engineers directly.

 For a Change Request to be officially submitted and handled by Splunk Support, it must be submitted by someone who has been granted the necessary support entitlement on the customer’s account. This protects against unauthorized or potentially disruptive changes and ensures accountability and traceability.

Therefore, the correct answer is D.