SY0-801 sample questions — 25 answered and explained

Non-repudiation and meaningful accounting both depend on unique identities; shared accounts make actions unattributable regardless of how strong the sign-in or how protected the logs are.

The scenario already has strong authentication and integrity-protected logs, which is why the other options are tempting: each strengthens something real. The gap is attribution. A log can only prove what an identity did; if five people share that identity, no amount of password rotation, token strength or log protection can name the person. Individual accounts close the gap.

1. List what is already in place: strong sign-in, protected logs.
2. Find what is missing: a link between an action and one person.
3. Recognise that a shared identity breaks that link.
4. Choose the change that gives each person their own identity.

Exam tip: No unique identity, no non-repudiation, however good the logs are.

Zero Trust grants no implicit trust based on network location; every access request is evaluated against identity, device and context.

The old VPN granted trust once, by network position; the new design grants access per application after checking who, from what device and under what conditions. That shift from location-based to request-based trust is Zero Trust. Least privilege and segmentation are tempting because Zero Trust designs use them, but neither by itself removes location-based trust.

1. Compare old and new: one-time network trust versus per-request checks.
2. Identify the signals checked: identity, device health, context.
3. Map 'never trust by location, always verify' to Zero Trust.
4. Treat segmentation and least privilege as supporting techniques.

Exam tip: Zero Trust: trust nothing by location; verify every request.

In NIST's Zero Trust model, the policy engine decides, the policy administrator turns the decision into session commands, and the policy enforcement point enforces it on the connection.

The three similarly named components are easy to mix up. The engine is the brain (decision), the administrator is the messenger that sets up or tears down the session, and the enforcement point is the gate in the data path. An identity provider feeds the engine authentication results.

1. Recall the three logical components from NIST SP 800-207.
2. Decide which one evaluates policy: the engine.
3. The administrator executes; the enforcement point enforces.
4. Identity systems are inputs to the decision.

Exam tip: Engine decides, administrator executes, enforcement point enforces.

Least privilege grants each user and process only the access needed for its task.

A password-reset role needs a narrow delegated permission, not full domain administration. Separation of duties is the usual near-twin, but it concerns splitting a process between people rather than trimming one person's rights.

1. Compare the task with the rights granted.
2. Rights far beyond the task violate least privilege.
3. Separation of duties is about splitting tasks, not sizing rights.

Exam tip: Least privilege: the rights the task needs, and no more.

STIX (Structured Threat Information Expression) is the language for threat intelligence content; TAXII (Trusted Automated Exchange of Intelligence Information) is the HTTPS API for transporting it.

The scenario describes two separate jobs: a standardized JSON language for the intelligence itself, and an HTTPS client-server API to deliver it. STIX 2.x is a JSON-based language for indicators, attack patterns and actors, and TAXII 2.x is the HTTPS protocol designed to carry it. OpenIOC is an older XML indicator format, and syslog forwards log messages, so any option using either fails one of the two requirements.

1. Split the stem into content (a JSON language) and transport (an HTTPS API).
2. Match STIX to the content role.
3. Match TAXII to the transport role.
4. Reject options that use an XML indicator format or a log-forwarding protocol.

Exam tip: STIX is what is said; TAXII is how it is sent.

Feed quality is about accuracy and relevance as much as speed: confidence ratings separate strong indicators from weak ones, and indicator aging retires addresses that have been reassigned.

Two facts explain the outage. Shared cloud-hosting addresses serve many tenants, so blocking one without confidence context takes out legitimate services; and attacker infrastructure moves on, so an address that was malicious months ago may now belong to someone else. A feed with confidence scores and expiry dates addresses both. More volume or broader coverage makes false positives worse, and standard formats solve an integration problem the company does not have.

1. Find the symptom: legitimate services blocked (false positives).
2. Map the single unverified report to missing confidence ratings.
3. Map the year-old addresses to missing indicator aging.
4. Reject changes that add more indicators or only change the format.

Exam tip: A good feed is accurate, relevant and current - confidence scores and indicator aging matter more than volume.

OSINT is intelligence gathered from publicly available sources such as websites, blogs, social media and public advisories.

The deciding detail is that every source is publicly available. That makes it open-source intelligence. Proprietary intelligence requires a paid subscription, human intelligence comes from people rather than published material, and internal intelligence comes from the organization's own systems.

1. List the sources used.
2. Check whether each is publicly accessible.
3. Public and external = OSINT.

Exam tip: Publicly available = OSINT; paid = proprietary; gathered from people = HUMINT; your own logs = internal.

ISACs are industry-specific information sharing communities in which member organizations exchange threat intelligence under agreed terms.

Two requirements decide the answer: intelligence specific to the healthcare sector, and sharing among peer organizations that protect what they receive. An ISAC (for healthcare, Health-ISAC) is built for exactly that. A commercial feed and a government CERT are not peer communities, and an open-source feed is public, so none meets both requirements.

1. Note the two requirements: sector focus and trusted peer sharing.
2. Recall which source is organized by industry with member sharing rules.
3. Check that the alternatives miss at least one requirement.

Exam tip: Sector-specific intelligence shared among peers = ISAC.

Internal intelligence comes from the organization's own logs, alerts and incident history and is the most relevant source for what is targeting that organization.

Failed logins and blocked connections are recorded by the organization's own systems. External sources - OSINT, vendor feeds and ISAC bulletins - describe what others have seen and add context, but only internal data shows what actually reached this network.

1. Note the requirement: attacks reaching this organization.
2. Ask which source records events on its own systems.
3. Internal logs are the only source that does.

Exam tip: What is hitting you is in your own logs; external sources add context.

The threat intelligence life cycle runs requirements, collection, processing, analysis, dissemination and feedback, with feedback steering the next cycle.

The report has already been disseminated, and the manager is evaluating its usefulness for the team that produced it. That is feedback: it refines requirements and sources for the next iteration. Collection, processing and analysis all come before a report is delivered.

1. Place the event on the timeline: after the report was distributed.
2. Identify who is acting: the consumer, reviewing usefulness.
3. The consumer's evaluation returned to the producers is feedback.

Exam tip: Feedback closes the loop: consumers tell producers what was useful.

A hybrid cloud joins environments, and the link between them becomes part of the attack surface.

This is a hybrid design: an on-premises data center and a public cloud working as one system. What is new compared with either environment alone is the interconnection, typically a VPN or dedicated link, plus the need for consistent identity and policy on both sides. Hypervisor patching is the provider's duty, an air gap would stop the web tier from working, and backup encryption on-premises is an existing control rather than one the hybrid design introduces.

1. Identify the model: on-premises and public cloud used together, which is hybrid.
2. Ask what exists now that did not exist before: a connection between the two.
3. Eliminate the provider-owned task and the option that breaks the requirement.
4. Choose securing the interconnection.

Exam tip: Hybrid cloud adds an interconnection that must be secured like any other entry point.

Infrastructure as Code defines and deploys infrastructure from version-controlled templates.

IaC replaces manual console configuration with templates that describe networks, servers and security rules. Because the templates are code, they can be reviewed, versioned and deployed the same way every time. Serverless and microservices are application architectures, and software-defined networking separates network control from forwarding hardware, so none of them describes servers and firewall rules kept as versioned templates and deployed by a pipeline.

1. Note that infrastructure is written as template files.
2. Note the version control and automated deployment.
3. Match infrastructure defined and deployed as code to IaC.

Exam tip: Infrastructure written as versioned templates and deployed automatically is IaC.

IaC makes deployments consistent, repeatable and reviewable.

Manual changes in a console differ from one person and one day to the next, and they leave no reviewable record. With IaC, the configuration is written once, reviewed like code and applied identically everywhere, so environments match a known baseline. IaC does not encrypt data unless told to, does not change where workloads physically run and does not by itself reduce dependence on a provider.

1. Identify what changes: configuration moves from manual clicks to templates.
2. Ask what templates guarantee: the same result every deployment.
3. Connect that consistency to fewer misconfigurations.

Exam tip: IaC's security value is consistency: the same reviewed configuration every time.

IaC replicates whatever is in the template, including its mistakes.

Two facts decide this. First, IaC copies a template's settings into every environment, so one flaw became 40 exposures; the fix belongs where the flaw lives, in the template, checked before deployment. Second, drift detection compares live resources to the template, and these environments were never changed, so drift detection reports nothing. Encryption at rest and a different deployment model leave the public-read permission in place.

1. Locate the source of the flaw: the shared template, not later changes.
2. Recall what drift detection compares: live state against the template.
3. See that the live state matches the flawed template, so drift detection is silent.
4. Choose the control that inspects templates before they are deployed.

Exam tip: A flaw in an IaC template spreads everywhere it is deployed; scan the template, because drift detection only catches changes from it.

Operational technology prioritizes availability and safety over confidentiality.

OT systems, such as controllers on a production line, act on the physical world. If they stop or behave unpredictably, production halts and people can be hurt. That is why OT security puts availability and safety first, while traditional IT usually emphasizes confidentiality. It is also why OT patching is slow and carefully scheduled rather than rapid.

1. Note that the systems control physical processes.
2. Ask what failure looks like: stopped production or physical harm.
3. Match that to availability and safety as the top priority.

Exam tip: In OT, keeping the process running safely outranks protecting data confidentiality.

Hardening reduces a system's attack surface by removing what it does not need and changing insecure defaults.

All three findings are configuration weaknesses on the server: an unneeded service, a default credential and an unnecessary feature. The only option that removes them at the source is hardening to a secure baseline. A WAF and segmentation reduce exposure around the server and EDR adds detection, but each leaves the weaknesses in place.

1. Classify the findings: unused service, default account, unneeded feature.
2. Note that all are fixed by changing the server's own configuration.
3. Choose hardening, which removes them rather than shielding them.

Exam tip: Unneeded services, defaults and features are fixed by hardening the host, not by putting controls in front of it.

Static code analysis (SAST) finds security flaws in source code without running the program.

The check must run on source code at pull-request time and must not need a running application. That is static code analysis. Secrets scanning also inspects the repository but looks for credentials, code signing deals with authenticity and integrity, and a WAF protects a deployed application at runtime.

1. Note the timing: before merge.
2. Note the constraint: the application is not running.
3. Note the target: insecure coding patterns.
4. Choose static code analysis.

Exam tip: Find flaws in code without running it: static analysis. Prove who published code: code signing.

A web application firewall filters HTTP at Layer 7, where application attacks such as SQL injection live.

The attack is inside allowed HTTPS requests, so anything that filters by address and port cannot tell it apart from real orders. A WAF understands HTTP requests and parameters and can block injection patterns. The NIDS only alerts, and a forward proxy controls outbound user browsing rather than inbound traffic to a site.

1. Note that the attack arrives on an allowed port.
2. Note that the malicious part is in the HTTP request content.
3. Choose the Layer 7 control placed in front of web applications: a WAF.

Exam tip: Attacks inside allowed web traffic need Layer 7 inspection: put a WAF in front of the application.

Layer 4 filtering sees addresses and ports; Layer 7 filtering identifies the application protocol carried in the connection.

Two facts combine. A port-based (Layer 4) rule cannot tell SSH from HTTPS when both use TCP 443, so a port 22 block is irrelevant. And the fix must leave browsing working, which rules out simply blocking 443. An application-aware Layer 7 policy that allows only TLS on 443 meets both needs. The WAF is a real Layer 7 control but faces the wrong direction, and rate limiting does not stop a single tunnel.

1. Note that the tunnel hides on an allowed port.
2. Recognise that a port rule cannot separate protocols on the same port.
3. Keep browsing working, so 443 cannot be closed.
4. Choose an application-aware Layer 7 policy on the outbound path.

Exam tip: When attackers reuse an allowed port, only a Layer 7 rule that checks the protocol can stop them.

Rule-based firewalls match rules in order, stop at the first match and deny anything left unmatched.

Two facts are needed. The connection starts at the application servers, so they are the source and the database is the destination on TCP 1433. And with first-match processing, a permit placed below a broader deny that covers the same traffic is never evaluated. Only the rule with the right direction placed above rule 10 works.

1. Identify who initiates the connection: the application servers.
2. Write the rule with that subnet as source and the database as destination on TCP 1433.
3. Check rule order: the broad deny in rule 10 matches first.
4. Place the permit above rule 10.

Exam tip: Source is who starts the connection, and in a first-match rule set a specific permit must sit above the broad deny.

Rate limiting caps the number of requests a client can make in a time window, blunting brute force and floods.

The traffic is many well-formed requests from a few sources, and the constraint forbids locking accounts. Rate limiting per source addresses volume from those sources without touching the accounts themselves. Lockout is the obvious control but breaks the stated constraint; validation and HIDS do not reduce the request rate.

1. Characterise the attack: high request volume from few sources.
2. Apply the constraint: do not lock out owners.
3. Choose a control that limits request rate per source.

Exam tip: High-volume guessing from few sources: rate-limit the requests, rather than locking the accounts.

Content filtering can be enforced centrally (proxy) for on-network traffic or by an agent on the device for roaming users.

The deciding fact is that the laptops' traffic never passes through any company network, so a proxy at headquarters never sees it. The filtering must run on the laptop, which leaves three on-device options. An application allow list governs which programs run, not which sites the browser reaches, and a host firewall port rule cannot classify sites by category. An agent-based content filter enforces a URL category policy on the device itself, so it applies at home, in hotels and in the office.

1. Note where the traffic flows: straight from home to the internet.
2. Eliminate controls that only see traffic passing through headquarters.
3. Among on-device controls, pick the one that filters by site category: an agent-based content filter.

Exam tip: Roaming devices off the corporate network need agent-based filtering; a central proxy only sees traffic sent through it.

Standards make policy intent measurable and mandatory; procedures say how; guidelines are optional.

Two constraints decide it. The requirements must be mandatory and measurable, which rules out a guideline (optional) and a revised policy (high-level intent). Each site must still choose how to comply, which rules out a procedure (prescribed steps). Only a standard is both mandatory and focused on what must be achieved rather than how.

1. List the constraints: mandatory, measurable, local choice of method.
2. Remove the optional document: guideline.
3. Remove the document that prescribes steps: procedure.
4. Remove the document that only states intent: policy.
5. Choose the standard.

Exam tip: A standard says what must be achieved; a procedure says how.

RFCs are IETF publications; standards-track RFCs are the authoritative specifications of internet protocols.

Interoperating with other TLS 1.3 implementations requires following the same protocol specification, and TLS 1.3 is defined in an IETF Request for Comments (RFC 8446). Benchmarks, implementation guides and advisories all assume the protocol already exists rather than defining it.

1. Note the need: an authoritative protocol specification.
2. Recall who defines internet protocols: the IETF.
3. Recall the IETF's document series: RFCs.
4. Choose the RFC.

Exam tip: Internet protocol specifications are published as RFCs.

A standard operating procedure gives the ordered steps for a routine process so it is performed consistently.

The key requirements are a recurring business process, a fixed order of steps and the same result no matter who does it. That is the purpose of an SOP. The access control policy is the tempting option, but policies state rules and authority; the SOP is how those rules are carried out each time.

1. Note that the task recurs with every new hire.
2. Note the need for a fixed order and consistent results.
3. Separate rules (policy) from steps (procedure).
4. Choose the SOP.

Exam tip: Routine process, same steps every time: standard operating procedure.