SY0-801 security operations explained

Security Operations is the largest SY0-801 domain at 27%. It has eight objectives (4.1 to 4.8) covering the day-to-day work of a security administrator: applying controls, managing assets and vulnerabilities, monitoring, identity and access, automation, incident response and investigation. It is also where performance-based questions are most likely to ask you to apply a concept rather than recall one.

4.1 Mitigating controls

Topics include segmentation, access controls, hardening, sandboxing, deception technology (honeypot, honeynet, honeyfile, honeytoken, canary account), MDM, application allow and block lists, IDS and IPS variants (NIDS, NIPS, HIDS, HIPS, WIPS), firewalls (WAF, UTM, layer 4 and layer 7), content filtering, DLP, EDR and XDR, network access control (802.1X, captive portals, posture checks), secrets scanning, input validation, code signing, Group Policy and SELinux.

Email security is a favourite: SPF lists servers allowed to send for a domain, DKIM signs messages, DMARC tells receivers what to do when checks fail and reports results, and BIMI displays a brand logo for authenticated mail.

4.2 and 4.3 Assets and vulnerabilities

Asset management follows a life cycle from planning and procurement through assignment, tracking and decommissioning. Vulnerability management covers identification (scanning, IPAM, CSPM, source code review), analysis and prioritisation by severity and context, remediation, verification, reporting, bug bounty programs and responsible disclosure. Good prioritisation combines CVSS with asset criticality and exposure, not CVSS alone.

4.4 Alerting and monitoring

Know log aggregation, alert tuning, agent versus agentless collection, SIEM, SCAP, NetFlow, SNMP, syslog, port mirroring and dashboards. NetFlow records who talked to whom and how much, not the payload; a packet capture records the content.

4.5 Identity and access management

Access reviews

Objective 4.5 lists “access review” as its own item, between access management policies and password concepts. An access review is a periodic check, by someone accountable, that each account still needs the access it holds. Provisioning answers “should this person get access?” once; the review asks the same question again later, because jobs, projects and contracts change while permissions tend to stay.

The problem it solves has a name elsewhere in the outline: privilege creep (objective 3.2). A user moves from finance to sales, receives the sales role, and keeps the finance rights because nobody removed them. Over a few moves that account collects access no single role would justify, which breaks least privilege and makes a compromised account far more valuable to an attacker.

A practical review has four parts:

• Scope. Which accounts or resources: privileged accounts, service accounts, third-party and guest accounts, or one sensitive application.
• Reviewer. Usually the manager or the resource owner, not the user and not only IT. The person who knows whether the access is still needed signs off.
• Decision. Each entitlement is approved or removed, and removals are carried out, not just noted.
• Evidence. The result is recorded, which is what auditors look for under objective 5.5 and what frameworks expect. NIST SP 800-53, for example, includes reviewing accounts for compliance with account management requirements at an organisation-defined frequency (control AC-2).

Higher-risk accounts get reviewed more often. Privileged, emergency access and third-party accounts are typical candidates, and just-in-time access shrinks what needs reviewing because standing privileges are removed in the first place. Reviews also catch the accounts deprovisioning missed, such as a contractor whose account still works after the contract ended.

On Security+ this is vendor-neutral. You will not be asked about a particular product’s review feature; the access reviews and entitlement management guide shows how one platform automates the same idea.

Exam pitfall: do not confuse an access review with log review or activity monitoring. Checking logs shows what an account did; an access review asks what it is allowed to do and whether it still should be. If a scenario describes a user with permissions left over from a previous role, the answer is a periodic access review (with least privilege), not more MFA or a stronger password policy.

4.6 Automation and orchestration

Use cases include user and resource provisioning, desired state management, anomaly detection and ticket management. Considerations include guardrails, complexity, cost and process risk. V8 adds AI: agentic systems, chatbots, predictive analysis and AI-augmented baselines. Also expect CI/CD, workflows and integrations.

4.7 and 4.8 Incident response and investigation

The incident response objective lists preparation (training, tabletop exercises, playbooks), identification, containment, eradication and recovery, notification and post-incident activity such as lessons learned and root cause analysis. Digital forensics adds chain of custody, e-discovery and preservation. Investigation sources include logs, metadata, vulnerability scans, NetFlow/IPFIX, packet captures, system images, memory dumps and snapshots.

When ransomware is found on a server, containment (isolating it) comes before eradication and recovery.

Example questions

Revision tips

Practise ordering incident response steps and picking a tool from a requirement. For IAM, memorise model names with one scenario each. Next, program management and oversight.