Free Practice Questions for Splunk SPLK-5002 Exam

Global field mappings provide a consistent mapping layer when data is exported from Enterprise Security data models or saved searches into Splunk SOAR. The objective is to ensure that semantically equivalent values are represented consistently regardless of which detection, search, or data model produced the source event.

This becomes important when SOAR receives security events from multiple searches. One source might expose an endpoint as dest, another as host, and another might use a product-specific field. Consistent global mapping allows downstream SOAR workflows to operate on standardized field semantics instead of requiring every playbook to understand every upstream schema variation.

A field alias is a Splunk knowledge object that can make one indexed or extracted field available under another name during search processing, but that is not the cross-export mapping mechanism requested here. “Field labels” likewise do not establish the global ES-to-SOAR translation layer. The important clue is the requirement for consistency across both data-model and saved-search exports , which implies a centrally applied mapping configuration.

This design reduces duplicated transformation logic and improves the portability and reliability of automated response workflows.

Study Guide topics: Global field mappings, Enterprise Security-to-SOAR integration, data normalization, event export, automation data consistency.

The required combination must satisfy two independent requirements : restrict the dataset to failed Azure Active Directory authentication activity and represent the origin of those events geographically. Option D provides that combination by selecting the failure-oriented Azure AD sign-in data and using geographic-coordinate information with a Cluster Map .

A geographic cluster visualization is appropriate when individual events contain point locations such as latitude and longitude. Multiple sign-in failures originating from the same geographic area can then be grouped visually, making concentrations outside the expected operating region—here, North America—immediately apparent. This is particularly useful for authentication monitoring because a raw table of IP addresses does not provide the same rapid geographic interpretation.

The search must also distinguish failures from successful authentication. Merely plotting all sign-ins would allow large quantities of legitimate activity to obscure the specific anomalous behavior being investigated. Conversely, choosing an inappropriate geographic visualization for point-coordinate data would not provide the intended presentation.

Study Guide topics: Azure AD authentication data, failed-login filtering, geospatial enrichment, geographic dashboards, Cluster Map visualization, security analytics.

Windows Security Event ID 4740 records the condition “A user account was locked out.” Consequently, a detection that counts EventCode 4740 events and aggregates them by user is specifically measuring repeated account-lockout activity. The appropriate detection is therefore Detect Excessive User Account Lockouts .

From a detection-engineering perspective, a useful analytic would establish a baseline or threshold and then aggregate by the affected account, for example conceptually using stats count by user. A high number of lockouts may indicate password spraying, credential-stuffing activity, an incorrectly configured service using stale credentials, or an automated process repeatedly authenticating with an invalid password. Context such as source workstation, account type, time window, and historical frequency would improve fidelity.

The distractors represent different telemetry classes. Excessive successful or failed logins normally involve authentication events such as 4624/4625 rather than 4740. Network-connection detections require network or endpoint connection telemetry, and AWS security scanning is unrelated to Windows account-lockout auditing.

The supplied material presents EventCode 4740 specifically in this detection-selection context on page 3.

Study Guide topics: Windows security telemetry, EventCode-based analytics, aggregation, account lockouts, authentication detections, threshold-based detection engineering.

Triage generally provides the lowest-friction opportunity for replacing manual SOC work with automation because much of triage consists of deterministic, repetitive information-gathering and enrichment tasks.

A SOAR playbook can automatically retrieve reputation information, collect endpoint details, query identity context, check threat intelligence, detonate suspicious files or URLs, deduplicate findings, and assemble evidence before an analyst reviews the incident. These activities are generally reversible and low impact compared with active response operations. The supplied material demonstrates this principle through automation scenarios where SOAR handles repetitive Attack Analyzer submission and data-collection steps before presenting the information to an analyst.

Containment introduces greater friction because actions such as disabling an account or isolating a production endpoint can disrupt business operations. Remediation may involve deleting files, changing configurations, resetting credentials, or restoring systems and therefore generally requires stronger controls. Rendering a verdict frequently requires contextual human judgment, particularly where evidence is ambiguous.

Automating triage first therefore provides high efficiency gains while maintaining relatively low operational risk.

Study Guide topics: SOAR automation, triage, enrichment, incident-response lifecycle, automation guardrails, containment, remediation.

Zero Trust is the methodology among these choices that directly supports reducing and preventing malicious lateral movement. Zero Trust architectures reject implicit trust based solely on network location and instead continuously evaluate identities, devices, applications, permissions, and access conditions.

Lateral movement occurs when an adversary who has gained an initial foothold attempts to access additional systems, credentials, services, or network segments. Zero Trust limits this ability through principles such as least privilege, strong identity verification, access segmentation, constrained authorization, device posture evaluation, and continuous monitoring. An attacker compromising one endpoint should therefore not automatically gain trusted access to adjacent resources.

The Lockheed Martin Cyber Kill Chain models stages of adversary activity and can help defenders understand attack progression, but it is not itself an access-control methodology designed to prevent lateral movement. MITRE ATT & CK catalogs adversary tactics and techniques, including lateral-movement techniques, but primarily provides a knowledge framework rather than the preventive architecture requested. A breakglass mechanism provides emergency privileged access and must itself be tightly governed.

Zero Trust therefore most directly addresses the architectural conditions that enable lateral movement.

Study Guide topics: Zero Trust; lateral movement; least privilege; segmentation; identity-centric security; access control; adversary containment.

The key-value pairs appearing after the ? character in a URL are parameters , more specifically query parameters . The example structure shown in the supplied material follows the standard pattern:

?type=hash & data= < value >

Here, type=hash and data= < value > are query parameters. The question mark marks the beginning of the URL ' s query component, while an ampersand ( & ) separates multiple parameter pairs. Each parameter typically consists of a key followed by = and its corresponding value.

This must be distinguished from an HTTP payload , which is normally transmitted in the request body, particularly with operations such as POST or PUT. Headers are separate HTTP metadata elements containing information such as authorization credentials, content type, accepted response formats, and user-agent information. “KV Elements” is not the HTTP/REST terminology for the URL query component.

Understanding this distinction is important when configuring SOAR integrations because an API may require values in different locations. Supplying a required query parameter in the request body—or vice versa—can result in validation failures even when the correct data is present.

Study Guide topics: REST APIs; query parameters; HTTP requests; SOAR integrations; URL structure; API troubleshooting.

EventCode 4104 represents PowerShell Script Block Logging , making it the relevant telemetry for inspecting PowerShell code executed in an environment. The question specifically ties the detection requirement to PowerShell Script Block Logging and therefore directly points to 4104.

Script Block Logging provides visibility into PowerShell script content after PowerShell has processed the command or script block. From a detection-engineering perspective, this can expose suspicious commands, modules, functions, credential-access behavior, encoded or obfuscated PowerShell content, and scripts associated with offensive frameworks. An engineer can search this telemetry for characteristics associated with the behavior discovered during the red-team exercise and subsequently operationalize reliable indicators into a detection.

EventCode 4624 , by comparison, represents a successful Windows logon and can be useful in authentication and lateral-movement analysis, but it is not the PowerShell Script Block Logging event explicitly requested. The remaining distractor event codes do not represent the logging mechanism identified in the question.

The distinction matters because endpoint detections depend on selecting telemetry that observes the relevant layer of attacker behavior. Here, PowerShell execution content—not merely authentication—is the required visibility source.

Study Guide topics: PowerShell logging, EventCode 4104, endpoint telemetry, behavioral detection, red-team findings, Windows security monitoring.

The Enterprise Security threat-intelligence lookup associated with file-based intelligence is file_intel .

Splunk Enterprise Security organizes threat-intelligence indicators according to observable type. This allows the Threat Intelligence Framework to normalize and match compatible indicators against event telemetry. File-oriented intelligence can contain characteristics such as file hashes, file names, or other file-related observables used to identify known malicious artifacts.

The naming convention is important. file_hash describes a type of file indicator but is not the threat-intelligence lookup name requested by the question. user_intel and user_hash concern user-oriented naming and do not correspond to the file intelligence collection.

The supplied study material demonstrates the same Threat Intelligence Framework design by asking which intelligence KV store contains malicious FQDNs, reinforcing that ES separates intelligence into purpose-specific collections such as service_intel. The exact file_intel question is not shown verbatim in the uploaded 60-question set, but the collection naming and threat-intelligence architecture are consistent with the framework tested there.

Study Guide topics: Threat Intelligence Framework, file_intel, file indicators, IOC normalization, threat matching, KV Store intelligence collections.

Assets are not one of the metadata types returned by Splunk ' s metadata command. The command supports indexed metadata categories including hosts, sources, and sourcetypes , making option C the exception.

Typical examples include:

| metadata type=hosts

| metadata type=sources

| metadata type=sourcetypes

The command provides summarized information about indexed data and can expose attributes such as event counts and first or last observed times without requiring analysts to perform a broad raw-event search. This makes it useful when validating data availability, determining whether a particular host or sourcetype is still reporting, and performing general data-source inventory work.

An asset , by contrast, is an enriched security entity within the broader Enterprise Security context. Asset information can be maintained through Assets and Identities mechanisms and associated lookup structures, but it is not a metadata command type.

The distinction is important in security data engineering. Indexed metadata describes how Splunk stores and categorizes incoming event data; asset context describes organizational entities and their attributes. Confusing those layers can result in inefficient searches or incorrect assumptions about where contextual information resides.

Study Guide topics: metadata, hosts, sources, sourcetypes, indexed metadata, data-source inventory, Assets and Identities.