Splunk will ingest firewall logs that must be kept for one year and be searchable by the whole SOC, and HR system audit logs that must be kept for seven years and be searchable only by two investigators. What is the correct design?
Select an answer to reveal the explanation.
Short Explanation
Think filing cabinets: you lock the HR cabinet and set its shred date separately from the busy one everyone uses. In Splunk, the index is that cabinet — retention and role access are set per index. The trap is sourcetypes or tags; they label data, but they don't lock it or age it out.
Full Explanation
In Splunk, data retention and access control are both applied at the index level. Each index has its own retention settings that determine when buckets roll to frozen and are deleted or archived, and roles are granted permission to search specific indexes. Placing firewall data and HR audit data in separate indexes therefore allows a one-year retention for the first and a seven-year retention for the second, while only the investigators' role is allowed to search the HR index. Tagging HR events in a shared index and hiding them from dashboards is cosmetic: any user with access to the index can still search the raw events directly. Using one index with seven-year retention and a deletion search is fragile, keeps firewall data too long until the search runs, and deleting events requires a privileged capability that should not be routine. Assigning different sourcetypes does not change retention, because retention is a property of the index, not of the sourcetype, and it does nothing to restrict who can search. Exam caveat: separate indexes are also the standard way to meet different compliance or performance requirements for distinct data sources. Operational check: create both indexes with their retention values, map each input to its index, and log in as a SOC analyst to confirm the HR index returns no results.