Security Operations Fundamentals and Setup
Get the foundation right first
Security Operations on the ServiceNow AI Platform is not one product but a set of separately licensed applications sharing a single data model: Security Incident Response (SIR), Threat Intelligence (TI), and Vulnerability Response (VR), plus add-ons such as Configuration Compliance and Security Operations analytics. Most "setup" exam items are really platform items wearing a security hat: plugin activation and dependency order, roles, assignment groups, properties, domain separation, and inbound email.
Know three things cold.
Security tables are not ITSM tables. Security incidents live in sn_si_incident (task-extended), not in the ITSM incident table, and the child work items are security incident tasks in sn_si_task. A favorite distractor offers "create an Incident record" as a containment step.
Roles are granular and additive. The pattern is admin / manager / analyst / read per application (sn_si.*, sn_ti.*, sn_vul.*). Holding sn_si.analyst grants nothing in TI or VR, and record visibility still depends on ACLs and assignment groups.
Licensing precedes configuration. Subscriptions are per application; enabling something in a personal developer instance does not mean it is entitled in production.
Worked example
An analyst sees the Security Incidents menu, but the list is empty and edits are blocked. Check in order: does the user's role set include the SIR analyst role; is the user in (or matched by) the assignment group on those records; do ACL/domain rules permit read? Role without group typically yields an empty list; group without role yields no menu at all.
Rule of thumb: sequence setup as plugins → roles → groups → properties → integrations → playbooks, and never tune playbooks before groups exist.