A school-district analyst needs to prove a new parent-portal user lookup returns the expected department before the next phishing wave. There is no live attack to search. Which command creates a dummy row so the lookup can be tested?
Select an answer to reveal the explanation.
Short Explanation
With no live phish to hunt, mint a fake row. makeresults is the scratch pad: one dummy user or hash, then eval and lookup to see if the parent-portal table behaves. It does not wait for an attacker and it does not scan a year of school logons.
Full Explanation
makeresults generates synthetic events so an analyst can validate lookup behavior, tokens, or search logic without waiting for production hits. A school-district parent-portal test typically creates one dummy row, evals a known test user or hash, and pipes that row into lookup to prove department enrichment returns as expected before the next phishing wave. Controlled synthetic input is the point: predictable keys, immediate pass/fail, no dependence on live attackers. tstats against a year of Authentication events reads live data at high cost and still may not include the exact test identity you need. transaction cannot invent a user that never appeared in the indexes; it only groups existing events. rex on index=* likewise searches real raw data and cannot guarantee a clean test account when none exists. Exam caveat: makeresults tests the lookup definition and search pipeline—it does not prove the parent-portal identity source stays current in production without a separate data-quality check. Operational check: makeresults a known good portal user and a known miss, pipe both through eval and lookup, verify department output on the hit and safe non-match behavior on the miss, then save the test search beside the lookup change record.