A school-district SOC lists ess_analyst versus ess_admin style permissions. Which pairing of work to ES capability is correct?
Select an answer to reveal the explanation.
Short Explanation
ess_analyst is the badge for the queue, not the keys to the building. Analysts live on Incident Review or Analyst Queue. Content, configuration, and acceleration stay with engineering and admin-style roles — not every ES login is ess_admin.
Full Explanation
In a school-district SOC, the correct pairing is that SOC Analysts use Incident Review or Analyst Queue, while engineering and admin-style roles own content and configuration. Permission models such as ess_analyst versus ess_admin exist so queue workers can triage without inheriting the keys to edit detections and accelerate data models. Civic education environments need that separation to reduce accidental change during busy school-year shifts.
Claiming every ES user is an admin because notables cannot be triaged without editing correlation searches fails by concept: triage does not require content-edit rights. Claiming Analysts own CIM acceleration while admins only open investigations fails by concept: acceleration and content configuration are engineering/admin concerns; investigations are Analyst work. Claiming Architects triage the queue while Analysts configure the ES app fails by concept: it reverses both roles.
Exam caveat: Map UI surfaces to roles—Incident Review/Analyst Queue for Analysts; content, configuration, and acceleration for engineering/admin—not "everyone is ess_admin."
Operational check: Review ES role mappings so Analyst accounts can disposition notables and open investigations but cannot edit correlation searches or acceleration settings; route those changes through engineering change tickets.