Courseiva

CCNA Data Lifecycle Management Questions

19 questions · Data Lifecycle Management · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
Multi-Selectmedium

Which THREE factors influence the disk I/O performance of an indexer cluster?

Select 3 answers
A.Search concurrency
B.Daily ingestion volume
C.Deployment server latency
D.Storage latency/type
E.Number of users logged in
AnswersA, B, D

Concurrent searches compete with indexing for the same indexer disk bandwidth, so higher search concurrency increases read I/O and can slow bucket operations. This satisfies the stem's factor requirement because search load directly affects the disk I/O demands placed on indexer peers.

Why this answer

Search concurrency (A) is correct because concurrent searches generate simultaneous read operations against index buckets, and higher concurrency increases disk I/O load and contention on the indexers. Daily ingestion volume (B) is correct because the volume of data ingested per day determines how much data must be written to disk, merged, and later read, directly driving I/O throughput and IOPS requirements. Storage latency/type (D) is correct because the underlying disk technology (SSD vs.

HDD, RAID configuration, SAN/NAS latency) fundamentally bounds the achievable read/write performance of the indexer. Deployment server latency (C) is not a factor because the deployment server distributes configuration/apps to forwarders and does not handle index-time data path I/O. Number of users logged in (E) is not a direct factor because user count alone does not determine I/O; it is the searches and ingest those users generate that matter.

Exam trap

SPLK-2002 often tests whether candidates conflate management-plane components (deployment server, license master) with data-plane performance factors — only search concurrency, ingestion volume, and storage characteristics actually stress indexer disks.

Practice this question →
2
MCQmedium

A Splunk architect is calculating the storage requirement for an index that receives 500GB of raw data per day, with a 30-day retention period and a standard 50% compression ratio. If the raw data volume doubles, how should the retention period be modified to maintain the original storage footprint?

A.Decrease retention to 15 days
B.Keep retention at 30 days
C.Decrease retention to 7 days
D.Increase retention to 60 days
AnswerA

Doubling raw volume while keeping the same storage footprint requires halving the retention period, since compressed storage scales linearly with daily ingest. Reducing 30 days to 15 days exactly offsets the doubled daily volume at the unchanged 50% compression ratio, preserving the original total index size.

Why this answer

If the raw data volume doubles, to maintain the same storage footprint, the retention period must be halved. Originally, 500GB/day for 30 days with 50% compression yields a certain storage size. Doubling the daily volume to 1000GB/day means you can only retain half as many days for the same total storage.

Thus, retention should decrease to 15 days.

Exam trap

SPLK-2002 often tests the inverse relationship between data volume and retention period when storage capacity is fixed, causing candidates to incorrectly adjust retention in the same direction as volume change.

How to eliminate wrong answers

Option B is wrong because keeping retention at 30 days would double the storage footprint, not maintain it. Option C is wrong because decreasing retention to 7 days would reduce storage to less than half of the original, not maintain it. Option D is wrong because increasing retention to 60 days would quadruple the storage footprint, which is the opposite of the goal.

Practice this question →
3
MCQmedium

A Splunk architect is performing capacity planning. If an indexer receives 1TB of logs daily, and the Splunk compression factor is 1:10 (resulting in 100GB of storage per day), how much storage is needed for 30 days of data, including a 20% overhead for bucket overhead and metadata?

A.3.6 TB
B.1.2 TB
C.3.0 TB
D.4.2 TB
AnswerA

100GB daily compressed data over 30 days gives 3TB, then the 20% overhead for bucket metadata raises this to 3.6TB. This satisfies the stem's requirement to include overhead alongside the 1:10 compression factor, yielding the correct total storage capacity for the indexer.

Why this answer

The daily raw ingest is 1TB, which compresses at 1:10 to 100GB of on-disk storage per day. Over 30 days that is 100GB × 30 = 3TB of compressed data. Adding the 20% overhead for bucket metadata and index structures yields 3TB × 1.2 = 3.6TB, matching option A.

Exam trap

SPLK-2002 often tests whether candidates apply the compression ratio AND the overhead multiplier in the correct order — the trap is stopping at the compressed 30-day total (3TB) and forgetting the 20% bucket/metadata overhead.

How to eliminate wrong answers

Option B is wrong because 1.2TB reflects only 12 days of compressed data (or a miscalculation that ignores the 30-day multiplier). Option C is wrong because 3.0TB is the raw compressed total before the 20% bucket/metadata overhead is applied. Option D is wrong because 4.2TB over-applies overhead (roughly 40%) rather than the stated 20%.

Practice this question →
4
MCQeasy

What happens to data when a bucket's 'frozenTimePeriodInSecs' is reached?

A.It is moved back to the hot bucket state
B.It is re-indexed for better performance
C.It is moved to the warm bucket state
D.It is deleted or moved to a cold storage directory
AnswerD

When frozenTimePeriodInSecs elapses, the bucket rolls past the frozen state; Splunk then deletes it, or moves it to the cold storage path if coldToFrozenDir is configured. This satisfies the stem's condition that the bucket's frozen time period has been reached.

Why this answer

When a bucket reaches its frozenTimePeriodInSecs, Splunk considers the data frozen. Depending on the index's frozenTimePeriodInSecs and coldToFrozenDir or coldToFrozenScript settings, the bucket is either deleted or archived to a cold storage directory. This is the final stage of the bucket lifecycle.

Exam trap

The trap is confusing frozen with cold — candidates may think frozen data remains searchable or moves to warm, but it is actually deleted or archived out of the index.

How to eliminate wrong answers

Option A is wrong because buckets never move backward from frozen to hot; the lifecycle is one-directional (Hot → Warm → Cold → Frozen). Option B is wrong because re-indexing is not a lifecycle transition and does not occur at the frozen stage. Option C is wrong because moving to Warm is a forward transition from Hot, not from Frozen; frozen is the terminal state.

Practice this question →
5
MCQhard

What is the primary architectural trade-off when using very short 'maxHotSpanSecs' values?

A.Improved data ingestion speed
B.Reduced search performance
C.Increased metadata overhead on the indexer
D.Increased compression efficiency
AnswerC

Very short 'maxHotSpanSecs' values force frequent bucket rollover, so the indexer must create and track many more hot buckets. Each bucket carries its own metadata, and this proliferation increases metadata overhead on the indexer, directly satisfying the architectural trade-off the stem asks about.

Why this answer

'maxHotSpanSecs' defines the maximum time span a bucket can remain in the hot state before rolling to warm. Very short values cause buckets to roll frequently, creating many small buckets. Each bucket carries metadata (bloom filters, tsidx files, bucket manifest), so frequent rolling increases metadata overhead on the indexer and can degrade performance.

Exam trap

SPLK-2002 often tests whether candidates understand that short hot spans primarily increase metadata overhead rather than directly improving ingestion or compression, so candidates who pick 'reduced search performance' miss the root architectural cost.

How to eliminate wrong answers

Option A is wrong because ingestion speed is not improved by short hot spans; frequent rolling can actually slow ingestion due to increased bucket management. Option B is wrong because reduced search performance is a secondary symptom, not the primary architectural trade-off — the root cost is metadata overhead from many small buckets. Option D is wrong because compression efficiency typically decreases with smaller buckets, not increases, since larger buckets compress better.

Practice this question →
6
Multi-Selecteasy

Which TWO types of storage can be used for indexer data?

Select 2 answers
A.USB flash drives
B.Search head cache
C.Temporary memory storage
D.Object storage (SmartStore)
E.Local attached storage
AnswersD, E

SmartStore uses object storage as the remote tier for warm and cold buckets, while indexers cache hot buckets locally. It satisfies the constraint of cost-effective, scalable retention for indexer data without relying solely on attached disks.

Why this answer

Option D (Object storage (SmartStore)) is correct because Splunk indexers can store bucket data remotely in object storage such as S3, Azure Blob, or GCS via SmartStore, keeping only cache and metadata locally. Option E (Local attached storage) is correct because indexers traditionally write buckets to locally attached disks (e.g., direct-attached SAS/SATA/NVMe volumes) as their primary index storage. Option A (USB flash drives) is not a supported or recommended indexer storage medium due to reliability and performance limits.

Option B (Search head cache) is incorrect because the search head cache accelerates searches and is not indexer data storage. Option C (Temporary memory storage) is incorrect because indexer data must persist; RAM is used only for transient in-memory processing, not as a storage type for indexer data.

Exam trap

SPLK-2002 often tests the distinction between supported persistent storage (local disk, SmartStore object storage) and unsupported or non-persistent options (USB drives, RAM, search head cache), catching candidates who confuse temporary caches with data storage tiers.

Practice this question →
7
MCQhard

In a SmartStore architecture, what happens when a bucket is evicted from local cache?

A.The bucket is moved to the cold path
B.The bucket is no longer searchable
C.The local disk space is freed
D.The bucket is deleted from remote storage
AnswerC

Eviction removes the bucket's cached copy from the indexer's local disk, reclaiming that capacity for other buckets. The bucket's data remains available in remote storage, so only local disk space is freed, satisfying the cache-eviction behaviour described.

Why this answer

In SmartStore, buckets are cached locally on indexers for search performance, but when the cache fills, the cache manager evicts buckets back to remote storage (S3, Azure Blob, GCS). Eviction frees the local disk space occupied by that bucket's data, allowing new buckets to be cached. The bucket remains fully searchable because it can be re-fetched from remote storage on demand.

Exam trap

The trap here is confusing eviction with deletion or with cold-path migration — candidates often assume evicted data is gone or unsearchable, when in fact it is simply removed from local cache and remains available remotely.

How to eliminate wrong answers

Option A is wrong because eviction does not move a bucket to the cold path; the cold path is a local directory concept, whereas SmartStore eviction removes the local copy entirely. Option B is wrong because evicted buckets remain searchable — Splunk downloads them from remote storage when a search needs them. Option D is wrong because eviction only removes the local cached copy; the authoritative copy in remote storage is never deleted by eviction.

Practice this question →
8
MCQhard

What is the purpose of the 'homePath.maxDataSizeMB' setting in indexes.conf?

A.Sets the maximum size of a single hot bucket
B.Limits the total size of all hot/warm buckets in the homePath
C.Limits the number of buckets to 100
D.Sets the size limit for the cold path
AnswerB

This setting caps the combined on-disk footprint of all hot and warm buckets stored under homePath, forcing older data to roll to cold or frozen storage once the threshold is reached. It directly satisfies the stem's constraint by bounding homePath growth rather than per-index or per-bucket size.

Why this answer

homePath.maxDataSizeMB sets the maximum total size, in megabytes, of all hot and warm buckets stored in the index's homePath. When this limit is reached, Splunk rolls the oldest warm buckets to the coldPath to free space, making it a retention and capacity control for the homePath volume.

Exam trap

SPLK-2002 often tests the confusion between per-bucket size settings (maxDataSize) and per-path total size settings (homePath.maxDataSizeMB, coldPath.maxDataSizeMB), as well as the parallel structure between homePath and coldPath limits.

How to eliminate wrong answers

Option A is wrong because the maximum size of a single hot bucket is controlled by maxDataSize (which accepts values like 'auto', 'auto_high_volume', or a number in MB), not homePath.maxDataSizeMB. Option C is wrong because there is no setting that limits buckets to 100; bucket counts are governed by maxWarmDBCount and related settings, not a fixed 100. Option D is wrong because the cold path size is controlled by coldPath.maxDataSizeMB, not homePath.maxDataSizeMB.

Practice this question →
9
MCQhard

An indexer cluster is suffering from 'bucket repair' loops. What is the most likely cause related to the bucket lifecycle?

A.Insufficient replication factor
B.Bucket corruption preventing indexer recovery
C.Excessive search concurrency
D.Misconfigured cold path
AnswerB

Corrupted bucket files halt the indexer's replication and searchability recovery, so the cluster repeatedly attempts to repair the same buckets, producing repair loops. The lifecycle constraint is that buckets must reach a searchable, replicated state; persistent corruption prevents that transition, driving endless repair cycles.

Why this answer

Bucket repair loops in an indexer cluster occur when the cluster master repeatedly attempts to fix or replicate a bucket that cannot reach a healthy state, usually because the bucket's data files are corrupted on disk. Corruption prevents the indexer from validating the bucket checksum, so the master keeps triggering repair operations that fail again, producing the loop.

Exam trap

SPLK-2002 often tests whether candidates conflate replication factor problems with corruption — replication issues produce 'under-replicated' states, while repair loops specifically point to data integrity failures that prevent the bucket from ever validating.

How to eliminate wrong answers

Option A is wrong because an insufficient replication factor causes under-replication warnings and search factor issues, but it does not by itself cause repair loops — the master would simply report buckets as non-compliant. Option C is wrong because excessive search concurrency affects search performance and can cause skipped searches or resource contention, not bucket repair cycles. Option D is wrong because a misconfigured cold path causes buckets to fail to move to cold storage or to be lost, generating errors about path availability, but not the repeated repair behavior characteristic of corruption.

Practice this question →
10
Multi-Selecteasy

Which TWO of these factors determine when a bucket rolls from hot to warm?

Select 2 answers
A.maxDataSize
B.maxWarmDBCount
C.maxTotalDataSizeMB
D.maxHotSpanSecs
E.frozenTimePeriodInSecs
AnswersA, D

maxDataSize sets the size threshold for a hot bucket; once the bucket reaches that volume, Splunk rolls it to warm. This satisfies the stem's question by naming the size-based condition that triggers the hot-to-warm transition.

Why this answer

In Splunk index lifecycle management, a bucket rolls from hot to warm based on the index's maxDataSize (option A), which sets the size threshold (in MB, or auto/auto_high_volume) that a hot bucket may reach before it rolls to warm, and maxHotSpanSecs (option D), which sets the maximum age in seconds a hot bucket may remain hot before rolling. These two settings are the specific hot-to-warm rollover triggers configured in indexes.conf. The other options do not govern this transition: maxWarmDBCount (B) limits how many warm buckets are retained before older ones roll to cold, maxTotalDataSizeMB (C) controls total index size for freezing/retention, and frozenTimePeriodInSecs (E) defines the retention period after which buckets are frozen and deleted.

Exam trap

SPLK-2002 often tests the confusion between hot-to-warm roll triggers (maxDataSize, maxHotSpanSecs) and retention/aging settings (maxWarmDBCount, maxTotalDataSizeMB, frozenTimePeriodInSecs) — candidates pick a retention parameter thinking it controls the roll.

Practice this question →
11
MCQmedium

A user wants to restore data from frozen buckets. What is the process for making this data searchable again?

A.Copy to the thawedPath and use the 'rebuild' command
B.Directly copy files to the warm path
C.Change the frozenTimePeriodInSecs
D.Run 'splunk restore --bucket'
AnswerA

Frozen buckets are not directly searchable, so the archived files must first be copied into the thawedPath directory, then the rebuild command regenerates the index entries. This restores searchability, satisfying the stem's requirement to make frozen data searchable again.

Why this answer

To restore frozen buckets, you copy the bucket files to the thawedPath directory defined in indexes.conf, then run the splunk rebuild command on that bucket directory to regenerate the necessary metadata (such as the .tsidx and bucket manifest files) so Splunk can search the data again. Simply placing files in the thawed path without rebuilding leaves the bucket unrecognized and unsearchable.

Exam trap

SPLK-2002 often tests the specific command name and directory (thawedPath plus splunk rebuild) for restoring frozen buckets, catching candidates who invent non-existent commands or confuse the thawed path with the warm path.

How to eliminate wrong answers

Option B is wrong because directly copying files to the warm path bypasses Splunk's bucket lifecycle management and does not regenerate the required metadata, so the data will not be searchable and may corrupt the index. Option C is wrong because changing frozenTimePeriodInSecs only affects when future buckets roll to frozen; it does not restore already-frozen data or make it searchable. Option D is wrong because there is no 'splunk restore --bucket' command in Splunk; the correct CLI command is 'splunk rebuild' applied to the thawed bucket directory.

Practice this question →
12
MCQeasy

Which metric is the best predictor of the storage needed for an indexer in a cluster?

A.Number of forwarders
B.Search concurrency
C.Number of users
D.Daily ingestion volume
AnswerD

Daily ingestion volume directly determines how much raw data lands in the index each day, and Splunk's compression and retention policies scale from that figure. It is the primary input for sizing calculations, whereas licence usage, user counts or search concurrency affect performance rather than storage capacity.

Why this answer

Daily ingestion volume is the primary driver of indexer storage requirements because Splunk's storage footprint is a function of how much data is ingested per day multiplied by retention period and replication/search factor. Other metrics like forwarder count or user count do not directly determine bytes stored.

Exam trap

SPLK-2002 often tests whether candidates confuse concurrency-related metrics (users, searches, forwarders) with storage drivers — the trap is picking forwarder count because it sounds like it scales with data, when volume is the actual determinant.

How to eliminate wrong answers

Option A is wrong because the number of forwarders indicates data sources, not volume — 100 forwarders sending 1 MB/day each is trivial, while 1 forwarder sending 1 TB/day is enormous. Option B is wrong because search concurrency affects CPU and memory sizing, not storage capacity. Option C is wrong because the number of users affects concurrency and licensing (if per-user), but not the raw storage footprint of indexed data.

Practice this question →
13
Multi-Selectmedium

Which THREE components are part of the Splunk index directory structure?

Select 3 answers
A.hotPath
B.coldPath
C.warmPath
D.homePath
E.thawedPath
AnswersB, D, E

coldPath is the directory storing buckets that have rolled from warm to cold, holding older searchable data on cheaper storage. Together with homePath and thawedPath it forms the three configurable index path components, directly answering which parts constitute the Splunk index directory structure.

Why this answer

In Splunk's indexes.conf, each index defines three path settings that make up its on-disk directory structure: coldPath (B), homePath (D), and thawedPath (E). homePath holds the hot and warm buckets (the newly written, actively searchable data), coldPath stores buckets that have rolled from warm to cold, and thawedPath is where archived buckets are restored when an admin runs the rebuild command to bring them back online. These three are the actual configurable path attributes of an index, so B, D, and E are correct. The other options are not valid index path settings: hotPath (A) and warmPath (C) do not exist as separate configuration keys because hot and warm buckets both reside under homePath, so they are not part of the index directory structure.

Exam trap

SPLK-2002 often tests the misconception that hot and warm buckets have their own dedicated path settings, when in reality both live under homePath and only coldPath and thawedPath are separate configuration attributes.

Practice this question →
14
MCQmedium

An architect is configuring a Splunk indexer cluster with SmartStore. The remote storage is an S3 bucket. To ensure data integrity and availability, the architect must configure the cluster to use a remote storage that supports which feature?

A.Strong read-after-write consistency
B.Cross-region replication
C.Server-side encryption
D.Object versioning
AnswerA

SmartStore requires strong read-after-write consistency to ensure that when an indexer uploads a bucket to remote storage, any subsequent read from another indexer (or the same one) returns the latest version. Without this, searches might miss recently indexed data or retrieve stale buckets, leading to inconsistencies and potential data loss.

Why this answer

SmartStore relies on strong read-after-write consistency to ensure that uploaded buckets are immediately visible to all indexers. This guarantees that searches access the most recent data and prevents inconsistencies, making it a fundamental requirement for remote storage backends.

Exam trap

The trap here is confusing optional security or redundancy features like encryption or versioning with the core consistency requirement that SmartStore depends on.

Practice this question →
15
MCQhard

Which configuration file and stanza are used to define the bucket lifecycle policy for a custom index named 'customer_data'?

A.datamodels.conf [customer_data]
B.server.conf [customer_data]
C.indexes.conf [customer_data]
D.inputs.conf [customer_data]
AnswerC

The `[customer_data]` stanza in `indexes.conf` defines per-index bucket lifecycle settings, including `frozenTimePeriodInSecs`, `maxHotBuckets` and `maxWarmDBCount`. Splunk reads these attributes at index creation and rollover, so placing the custom index's stanza here directly satisfies the requirement to configure its bucket lifecycle policy.

Why this answer

The bucket lifecycle policy for an index is defined in indexes.conf within the stanza for that index. The stanza name is the index name, so for 'customer_data', it's [customer_data]. This file contains settings like homePath, coldPath, frozenTimePeriodInSecs, and other retention-related parameters.

Exam trap

SPLK-2002 often tests the specific configuration file for index settings, causing candidates to confuse indexes.conf with other .conf files like inputs.conf or server.conf.

How to eliminate wrong answers

Option A is wrong because datamodels.conf is used to define data models for Pivot, not index bucket lifecycle. Option B is wrong because server.conf contains server-wide settings, not per-index bucket policies. Option D is wrong because inputs.conf defines data inputs, not index storage or lifecycle.

Practice this question →
16
MCQmedium

You need to reduce the number of small buckets created in your index. Which parameter should you increase?

A.maxWarmDBCount
B.frozenTimePeriodInSecs
C.minHotBuckets
D.maxDataSize
AnswerD

maxDataSize sets the target size at which a bucket rolls to a new one; raising it lets each bucket hold more events before sealing, directly reducing the count of small buckets created in the index.

Why this answer

The maxDataSize parameter in indexes.conf controls the maximum size of a hot bucket before it rolls to warm. Increasing maxDataSize allows each bucket to hold more data, which reduces the total number of buckets created for a given volume of ingested data. This directly addresses the goal of reducing small buckets.

Exam trap

SPLK-2002 often tests whether candidates confuse bucket retention settings with bucket creation settings — the trap is picking maxWarmDBCount or frozenTimePeriodInSecs because they mention buckets, but only maxDataSize controls how large a bucket grows before rolling.

How to eliminate wrong answers

Option A is wrong because maxWarmDBCount limits how many warm buckets are retained before freezing or deleting the oldest; increasing it does not reduce bucket creation, it only changes retention of existing warm buckets. Option B is wrong because frozenTimePeriodInSecs defines the retention period (how long data is kept before freezing), which affects data lifecycle, not bucket count. Option C is wrong because minHotBuckets is not a standard indexes.conf parameter for controlling bucket creation; hot bucket behavior is governed by maxDataSize and related settings.

Practice this question →
17
MCQmedium

An architect is tasked with enabling SmartStore for an indexer cluster. What is the primary requirement for the remote storage backend?

A.A local RAID 10 array
B.An S3-compatible object store
C.A network-attached storage (NAS) with NFS v4
D.A SAN with Fibre Channel connectivity
AnswerB

SmartStore caches bucket data locally while ageing cold buckets to remote storage, so the backend must expose an S3-compatible API; native S3, GCS or Azure Blob via gateway all qualify. This satisfies the stem's requirement for a remote object store rather than block or file storage.

Why this answer

SmartStore requires an S3-compatible object store as the remote storage tier because it uses the S3 API to upload and download bucket data (rawdata and tsidx) to remote storage while keeping only cache and metadata locally. Splunk supports Amazon S3, S3-compatible stores (e.g., MinIO, Dell ECS), Azure Blob, and GCS via the appropriate remote storage provider. Local RAID, NAS, or SAN do not expose the S3 API that SmartStore depends on.

Exam trap

SPLK-2002 often tests whether candidates confuse SmartStore's remote tier with traditional shared storage — the trap is selecting NAS/SAN because they are 'shared,' when SmartStore specifically requires an S3-compatible object store.

How to eliminate wrong answers

Option A is wrong because a local RAID 10 array is block storage attached to the indexer and cannot serve as the remote object store SmartStore requires — it also defeats the purpose of decoupling compute from storage. Option C is wrong because NFS v4 is a file-level protocol, not the S3 object API, and SmartStore does not support NFS as a remote volume. Option D is wrong because Fibre Channel SAN provides block-level LUNs, not S3-compatible object semantics, and is not a supported SmartStore backend.

Practice this question →
18
MCQmedium

An architect is designing an index lifecycle for compliance. The requirement is to keep data for exactly 7 years. Which setting must be configured to prevent premature deletion?

A.frozenTimePeriodInSecs
B.maxTotalDataSizeMB
C.maxWarmDBCount
D.maxHotSpanSecs
AnswerA

frozenTimePeriodInSecs defines the retention window in seconds before indexed buckets may be rolled to frozen and eventually deleted. Setting it to 220752000 seconds (7 years) prevents the indexer from archiving data prematurely, directly satisfying the exact seven-year compliance retention requirement.

Why this answer

frozenTimePeriodInSecs is the index-level setting in indexes.conf that defines the age (in seconds) at which buckets roll from cold to frozen, triggering deletion (or archival if a coldToFrozenScript/archiver is configured). Setting it to 7 years (220,752,000 seconds) ensures data is retained for exactly that period before being frozen. This is the only setting in the list that controls retention by time rather than by size or count.

Exam trap

SPLK-2002 often tests the confusion between time-based retention (frozenTimePeriodInSecs) and size/count-based retention (maxTotalDataSizeMB, maxWarmDBCount), tricking candidates into picking a size limit when the requirement is explicitly a time window.

How to eliminate wrong answers

Option B is wrong because maxTotalDataSizeMB controls retention by total index size in megabytes, not by time — it forces the oldest buckets to freeze once the size threshold is hit, which could delete data well before 7 years. Option C is wrong because maxWarmDBCount limits how many warm buckets can exist before the oldest rolls to cold; it governs warm-to-cold transitions, not the 7-year retention boundary. Option D is wrong because maxHotSpanSecs controls how long a hot bucket stays hot before rolling to warm, which is a lifecycle stage transition unrelated to long-term retention.

Practice this question →
19
MCQmedium

A Splunk architect is configuring a new index called `netflow` that must retain data for exactly 90 days, then delete it automatically. The index will receive high volume and is expected to grow significantly. Which setting in `indexes.conf` should the architect use to enforce this retention period, ensuring that buckets are removed from the index after 90 days?

A.frozenTimePeriodInSecs = 7776000
B.coldToFrozenScript = 7776000
C.maxDataSize = 7776000
D.homePath.maxDataSizeMB = 7776000
AnswerA

Setting `frozenTimePeriodInSecs` to 7776000 (90 days × 86400 seconds) instructs Splunk to roll buckets to frozen status after that age, and since no archival destination is configured, they are deleted. This directly enforces the required retention period for the `netflow` index, satisfying the exact 90-day deletion requirement.

Why this answer

Retention in Splunk is controlled by `frozenTimePeriodInSecs`, which defines the age at which buckets are frozen. For the `netflow` index, setting it to 7776000 seconds (90 days) ensures that buckets older than 90 days are moved to frozen status and, without a frozen archive, deleted. This matches the requirement precisely.

Exam trap

The trap here is confusing size-based limits like `maxDataSize` or `homePath.maxDataSizeMB` with time-based retention, which is exclusively governed by `frozenTimePeriodInSecs`.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Data Lifecycle Management questions.

Start 20-question session