CS0-004 sample questions — 25 answered and explained

Knowing normal process parentage is the baseline for spotting masquerading processes.

At boot, wininit.exe starts services.exe (the Service Control Manager) and lsass.exe; services.exe then starts every svchost.exe. Malware often names itself svchost.exe or lsass.exe, so a wrong parent (winlogon.exe for services.exe, services.exe for lsass.exe) is a strong lead. Each distractor swaps one link in that chain.

1. Recall the boot chain: wininit.exe starts services.exe and lsass.exe.
2. Recall that services.exe starts the svchost.exe instances.
3. Check each pair against that chain.
4. Select the two pairs that match it.

Exam tip: wininit.exe starts services.exe and lsass.exe; services.exe starts svchost.exe.

Containers are ephemeral, so their logs must be shipped off the container.

Containers are designed to be disposable and are rebuilt from immutable images, so anything written inside a container's writable layer disappears when it is replaced. Writing to stdout/stderr (or a logging sidecar/agent) and forwarding to a central platform keeps the evidence. Host snapshots and replica counts do not capture short-lived containers.

1. Note that the orchestrator destroys and replaces containers.
2. Recognize that data inside a container dies with it.
3. Choose continuous forwarding off the container.

Exam tip: Treat containers as disposable: ship their logs out continuously or lose them.

Virtualization and containerization isolate at different layers.

Containers are isolated processes on one shared host kernel, using namespaces and control groups. A kernel vulnerability or container escape can therefore affect the host and its other containers. VMs each run their own guest operating system and kernel, separated by the hypervisor, so the attacker must also break the hypervisor (a VM escape). CPU allocation, image signing and disk encryption are real controls but not the source of that boundary.

1. Identify the threat: one untrusted tenant attacking another.
2. Compare what the two workloads share.
3. Recognize that containers share a kernel and VMs do not.
4. Choose the kernel-isolation statement.

Exam tip: Containers share the host kernel; VMs each have their own behind a hypervisor.

Cloud-native services shift visibility from host agents to provider logs.

In serverless (function-as-a-service) the provider runs the operating system and runtime, so host-based tools such as EDR agents and authenticated scans have nothing to attach to. Detection moves to the provider's function logs, API/control-plane audit logs and configuration data, ingested into the SIEM. The distractors try to keep the host-based model that no longer applies.

1. Note the shift from a VM to serverless functions.
2. Recall who manages the underlying host in serverless.
3. Rule out host-based tooling.
4. Choose provider logs fed to the SIEM.

Exam tip: No host, no agent: monitor serverless through the provider's execution and audit logs.

APIs are an attack surface best governed at a single enforcement point.

An API gateway sits in front of the services and applies the same authentication and authorization checks, quotas/rate limits and logging to every call, so individual services do not need to be rewritten. A WAF with API rules is the tempting near-twin: it inspects requests for attacks, but enforcing caller identity and quotas for each API is the gateway's job. A published specification is design-time documentation, and a load balancer only spreads traffic.

1. List the requirements: authentication, rate limiting, central access logs.
2. Note the constraint: no change to each service.
3. Separate runtime enforcement from design-time documentation and attack filtering.
4. Pick the component built to enforce all three in front of the services.

Exam tip: Consistent API authentication, rate limiting and logging = API gateway.

Authorization (what a client may access) is different from authentication (who the user is).

OAuth 2.0 is a delegated authorization framework: an access token tells a resource server what the client may do, not reliably who the user is. OpenID Connect is an identity layer on OAuth 2.0 that issues an ID token (a signed JWT) with the user's identity and authentication details. SAML is the XML-based federation protocol, and transport protection comes from TLS in all of them.

1. Identify the goal: signing users in (authentication).
2. Recall that OAuth 2.0 is an authorization framework.
3. Recall that OIDC adds identity via the ID token.
4. Reject statements that describe SAML or TLS.

Exam tip: OAuth 2.0 authorizes; OpenID Connect authenticates on top of it.

Time synchronization supports authentication, not just log correlation.

Kerberos messages carry timestamps to prevent replay, so the KDC rejects requests from clients whose clocks differ from its own by more than the maximum tolerance (five minutes by default in Active Directory). Event 4771 with failure code 0x25 (KRB_AP_ERR_SKEW) is the domain controller saying exactly that, and the branch's events arriving minutes out of step in the SIEM confirm the drift. Stale passwords and password spraying produce bad-password failures (0x18), and the LDAPS certificate plays no part in Kerberos sign-in. The fix is to restore the branch's time source and keep every site in one NTP hierarchy.

1. Note the scope: one site, the same users succeed elsewhere.
2. Decode event 4771 failure code 0x25 as clock skew too great.
3. Connect it to the branch's timestamps arriving minutes out of step in the SIEM.
4. Rule out causes that would give bad-password codes or affect every site.

Exam tip: Kerberos failure 0x25 means clock skew; AD allows five minutes by default.

Privileged access management removes standing privilege and controls how privileged credentials are used.

PAM platforms grant elevation just in time and remove it afterwards, inject credentials from a vault so users never see them (rotating them after use), and proxy and record privileged sessions. Each distractor delivers two of the three: password checkout reveals the secret to the administrator, permanent group membership is standing privilege, and logon events are not session recording. Only the option combining time-limited membership with a credential-injecting, recording proxy meets all three.

1. List the three requirements: no standing rights, recorded sessions, unknown passwords.
2. Map each mechanism to the requirement it delivers.
3. Note that password checkout reveals the password and logon events are not recordings.
4. Choose the option that meets all three.

Exam tip: PAM = just-in-time elevation + vaulted, rotated credentials + recorded sessions.

Secrets management keeps credentials out of code and makes them short-lived.

A secrets manager (vault) stores credentials centrally, controls and audits access, and lets applications retrieve them at runtime, which removes them from code and configuration. Dynamic secrets go further: the vault creates a unique, time-limited database credential on request and revokes it on expiry, shrinking the window in which a leak is useful. Periodic rotation into an environment variable is the tempting near-twin, but the credential is still static between rotations. The other distractors keep the static secret in the repository or protect it in a way the leak bypasses.

1. Separate the two goals: no static secrets in code, short useful life.
2. Match runtime retrieval from a vault to the first goal.
3. Match dynamic, expiring credentials to the second.
4. Reject options that leave the static secret in the repository.

Exam tip: Fetch secrets from a vault at runtime and prefer dynamic, expiring credentials.

Segmentation affects scan visibility: a scanner outside a segment sees only what the firewall permits.

The scanner and targets are in different segments separated by a firewall. Every host shows only 443, and authenticated checks fail on every host, which fits a rule that permits HTTPS and blocks SMB and SSH. The usual fixes are a scanner engine inside the segment or a narrowly scoped firewall rule for the scanner's address. Credentials alone or the template cannot explain the identical port picture across all hosts.

1. Note where the scanner sits relative to the firewall.
2. Compare the open ports with the firewall rule.
3. Explain both the missing ports and the authentication failures with one cause.

Exam tip: Scanning across a firewall measures the firewall: place scanners per segment.

Segmentation shapes scanner placement: distributed engines avoid wide firewall exceptions while preserving coverage.

Both full credentialed coverage and minimal firewall changes are required. A central scanner with any-port access achieves coverage but needs wide rules into each zone. Scanning only permitted ports keeps rules small but loses coverage. Per-zone scan engines report to a central manager over a single management connection, satisfying both constraints. Physically moving a scanner between zones defeats the segmentation itself.

1. List the two constraints: full credentialed coverage and minimal inter-zone rules.
2. Eliminate options that meet only one.
3. Choose distributed engines with one management path per zone.

Exam tip: Many zones, few rules: one scan engine per zone, one console.

PCI DSS regulatory scanning: external scans are quarterly and must be performed by an Approved Scanning Vendor.

PCI DSS v4.0.1 requirement 11.3.2 requires external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor, with passing results. Frequency is already correct here, so the gap is who performed the scan. Authenticated scanning is an internal-scan requirement, and scans from inside the CDE are internal scans.

1. Check frequency: quarterly meets the requirement.
2. Check performer: external scans need an ASV.
3. Separate internal-scan rules from external-scan rules.

Exam tip: PCI external scans: every quarter, by an ASV.

Regulatory requirements set scan frequency and triggers: PCI DSS internal scans are quarterly and after significant change.

PCI DSS v4.0.1 requires internal vulnerability scans at least once every three months (11.3.1) and after any significant change (11.3.1.3), with high-risk and critical findings resolved and rescanned. The ASV requirement and the internet vantage point belong to external scans (11.3.2), and annual testing is the penetration-test cadence (11.4).

1. Separate internal from external scanning requirements.
2. Recall the internal frequency and the change trigger.
3. Reject requirements that belong to external scans or penetration testing.

Exam tip: PCI internal scans: quarterly and after every significant change.

Credentialed scanning and regulation: PCI DSS v4.0.1 requires authenticated internal scans with properly managed credentials.

Requirement 11.3.1.2 (in effect since 31 March 2025) requires internal scans to be authenticated with sufficient privileges, and the accounts used to be managed per requirement 8.2.2. The lockout was a credential-management problem, so the fix is a dedicated scanning account with appropriate privileges, not dropping authentication. ASV reports cover external scans, frequency does not replace depth, and a domain admin account is excessive privilege for a scanner.

1. Identify the requirement as authenticated internal scanning.
2. Treat the lockout as a credential-management issue to fix, not a reason to stop authenticating.
3. Choose the option with sufficient but controlled privileges.

Exam tip: PCI v4 internal scans must be authenticated: fix the scan account, don't drop it.

External scans assess the perimeter from an attacker's position on the internet; internal scans assess what lies behind it.

The vantage point determines what a scan sees. To model an internet attacker, the scanner must sit outside the perimeter with no credentials. Internal, agent-based and credentialed scans all add access the attacker would not have.

1. Identify the attacker's position: on the internet, no access.
2. Pick the scan whose vantage point matches it.

Exam tip: Want the attacker's view? Scan from outside.

Diamond Model meta-features: timestamp, phase, result, direction, methodology and resources.

Direction captures the path of an event between features, with values such as victim-to-infrastructure, infrastructure-to-victim or bidirectional. A beacon from the laptop to the actor's server is victim-to-infrastructure. Result, phase and methodology describe outcome, sequence position and class of activity.

1. Identify what is being recorded: who initiated the connection and toward whom.
2. Match it to the meta-feature describing flow between features.
3. Rule out outcome (result), sequence (phase) and activity class (methodology).

Exam tip: Which way did it flow? Direction. Did it work? Result.

The extended Diamond Model adds two meta-features across the diamond: social-political (adversary to victim) and technology (capability to infrastructure).

The observation is about how the capability communicates over its infrastructure, using DNS rather than HTTP. That is the technology meta-feature, which also explains why blocking HTTP left the channel open. Social-political links the other axis (adversary and victim), and methodology and resources are standard meta-features that describe different things.

1. Identify the two features being linked: capability and infrastructure.
2. Recall which extended meta-feature spans that axis: technology.
3. Check the other axis (adversary and victim) belongs to social-political.

Exam tip: Technology links capability to infrastructure; social-political links adversary to victim.

Diamond Model analysis builds from events to activity threads (one intrusion, in order) to activity groups (clusters of similar events and threads).

The analysts are clustering many separate intrusions by shared features (loader, registrant email, timing) into one confidence-weighted set to track: an activity group. Threads describe the ordered steps of a single intrusion, and activity-attack graphs support defensive planning.

1. Note the scope: 14 separate intrusions, not one.
2. Note the goal: cluster by shared features with confidence weighting.
3. Match clustering across intrusions to activity groups; ordered steps within one to threads.

Exam tip: Thread = one intrusion in order; group = many intrusions clustered by similarity.

The Diamond Model's adversary feature can be split into the adversary operator (who conducts the activity) and the adversary customer (who benefits from it).

The hack-for-hire crew conducted the intrusion and the competitor commissioned and benefited from it. The model records them separately as operator and customer, so the analysis does not merge them into one adversary. The other pairs are real Diamond Model distinctions that belong to the victim, infrastructure and capability features.

1. Identify that both parties sit on the adversary vertex.
2. Separate who performed the activity from who benefited.
3. Map them to operator and customer.

Exam tip: Operator does the hacking; customer benefits from it.

ATT&CK IDs: tactics TA####, techniques T####, sub-techniques T####.###, mitigations M####, groups G####, software S####, campaigns C####.

A T-prefixed ID with a three-digit suffix is a sub-technique of the parent technique. T1566.001 is Spearphishing Attachment under T1566 Phishing. Tactics and mitigations have their own prefixes, and procedures are documented as examples rather than separate IDs.

1. Read the prefix: T means technique.
2. Read the suffix: .### means a sub-technique of that technique.
3. Rule out the other object types by their prefixes.

Exam tip: T#### is a technique; T####.### is one of its sub-techniques.

In ATT&CK one technique can sit under several tactics; the tactic recorded is the adversary's goal at that step.

Valid Accounts (T1078) is listed under Initial Access, Persistence, Privilege Escalation and Defense Evasion. The first logon's goal was getting in, and the second's was higher rights, so the tactics are Initial Access then Privilege Escalation. Harvesting the credentials is a separate Credential Access technique, which is why that near-twin is tempting.

1. For each logon, ask what the adversary was trying to achieve at that moment.
2. First logon: get a foothold from outside, Initial Access.
3. Second logon: obtain higher rights, Privilege Escalation.

Exam tip: The same technique maps to different tactics depending on the adversary's goal at that step.

An action plan defines owners, deadlines and an escalation path, so missed remediation is pushed to the next level of authority in a predictable way.

Escalation exists so overdue findings do not stall when an owner does not respond. The plan already says who comes next: the owner's line manager, then the CISO. Another reminder repeats what failed, bringing in the CISO at the same time skips the plan's order, and logging an acceptance nobody made hides the risk.

1. Confirm the deadline has passed and normal follow-up has failed.
2. Follow the escalation path the action plan defines.
3. Do not record a risk decision that the accountable person has not made.

Exam tip: Missed deadline plus no response means escalate along the plan's defined path.

When remediation cannot meet the SLA, the action plan escalates to the accountable risk owner for a formal exception, documented with compensating controls and a review date.

Two facts decide this. First, a compensating control lowers risk but does not close the finding or authorize missing the SLA. Second, only the accountable risk owner can accept the residual risk, so the analyst's job is to prepare and escalate the exception request. Self-approving, reclassifying the finding, or reporting a breach indefinitely all leave the decision unmade.

1. Recognise that the SLA cannot be met for a business reason.
2. A compensating control supports an exception; it is not the decision.
3. Route the exception to the accountable risk owner with an expiry or review date.

Exam tip: Analysts document exceptions; accountable risk owners approve them.

Action plans list dependencies: tasks, releases or approvals that must happen before a fix can proceed. Recording them explains delays and sets interim protection.

The fix depends on an external release the team does not control. A good action plan records that dependency with its expected date, keeps the finding tracked, and adds an interim mitigation such as a WAF rule or disabling the affected feature. Upgrading a bundled component on its own risks breaking the application, while an exception or a request for a hotfix with everything on hold leaves the exposure unmitigated.

1. Find what blocks the fix: the vendor's framework release.
2. Record the dependency with its owner and expected date.
3. Reduce exposure in the meantime instead of waiting with no protection.

Exam tip: When a fix waits on something else, record the dependency and mitigate in the meantime.

Dependencies in an action plan fix the order of tasks; operational constraints fix how many can run at once. A good plan respects both and adds checkpoints and owners.

Three constraints combine. The dependency means the agent must be running and verified before firmware on each host. The availability constraint allows one host out at a time and each host out only once. Only the per-host sequence of agent, verification, then firmware meets all three. Firmware first breaks the dependency, a single check at the end skips the per-host verification, and two separate passes take each host out twice.

1. Map the technical dependency: agent, verify, then firmware.
2. Apply the operational constraints: one host out at a time, each host out once.
3. Check every option against all constraints, not just the obvious one.
4. Choose the per-host sequence with a checkpoint before firmware.

Exam tip: Sequence remediation by dependency, pace it by operational constraint, and checkpoint each step.