Cyber Security Quiz: Endpoint Logging

10 questions · exam conditions

0:00

Endpoint LoggingQuestion 1 of 10

A Windows endpoint continues to send application-error events to a central collector. After a suspected password-spraying attempt, analysts find no failed-logon events in the collector. The same events are also absent from the endpoint's local Security log, although log forwarding reports no errors.

Which action would MOST directly address the reason the failed-logon events are unavailable?

Increase the maximum size of the local Security log to prevent older authentication events from being overwritten.

Enable the applicable failure-auditing subcategory so the endpoint generates failed-logon events before forwarding occurs.

Restart the event-forwarding service so it can resend failed-logon events retained in its outbound queue.

Modify the collector subscription to include application events in addition to events from the Security log.

← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Endpoint Logging

Practice Endpoint Logging in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Endpoint Logging, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Which action would MOST directly address the reason the failed-logon events are unavailable?

Increase the maximum size of the local Security log to prevent older authentication events from being overwritten.
Enable the applicable failure-auditing subcategory so the endpoint generates failed-logon events before forwarding occurs. (correct answer)
Restart the event-forwarding service so it can resend failed-logon events retained in its outbound queue.
Modify the collector subscription to include application events in addition to events from the Security log.

Explanation: When troubleshooting missing log events, always ask why the events don't exist before assuming a delivery or storage problem. The critical clue here is that failed-logon events are absent from both the central collector and the local Security log. That rules out any forwarding issue — if events aren't on the endpoint itself, nothing upstream can recover them. Windows only generates Security log events for activities that have auditing explicitly enabled. Failed logon attempts fall under the "Audit Logon Events" (or more specifically, the "Logon" failure subcategory in Advanced Audit Policy). If that failure auditing subcategory is disabled, Windows simply never writes those events — they're gone before forwarding even enters the picture. Enabling the correct failure-auditing subcategory, as B describes, directly fixes the root cause: the events will now be generated locally and subsequently forwarded. A is wrong because increasing the log size addresses overwriting of existing events, but the problem isn't that old events were purged — the events were never written in the first place. C is wrong because restarting the forwarding service can only resend events that were already captured locally; since the local log is also empty, there's nothing in any outbound queue to recover. D is wrong because the issue isn't a subscription misconfiguration — application events are already reaching the collector, and the Security log channel is presumably subscribed; the problem is that failed-logon events were never generated within that channel. Your study tip: on log-related questions, always trace the event lifecycle — generation → local storage → forwarding → collection. Missing events at every stage point to a generation failure, not a transport one.

Question 2

During an investigation, an endpoint log shows process creation at 10:04:58, while the network sensor records the process's first outbound connection at 10:00:03. Testing reveals that the endpoint clock is approximately five minutes fast.

Which logging practice would BEST support accurate correlation while preserving evidentiary context?

Replace each endpoint timestamp with collector receipt time and discard the endpoint's original timestamp.
Subtract five minutes from every historical endpoint event without recording that a correction was applied.
Sort all records by event severity because severity is less affected by endpoint clock differences.
Synchronize endpoint clocks and retain both original event times and documented normalized times during analysis. (correct answer)

Explanation: When correlating logs across multiple systems, your primary challenge is clock skew — the drift between different devices' internal clocks. A five-minute difference can make an effect appear before its cause, completely inverting the timeline of an attack. The goal is never to destroy original evidence but to contextualize it. The strongest approach is D: synchronize clocks going forward (typically via NTP) and, for historical records, document both the original timestamp and the corrected normalized time alongside a clear explanation of the adjustment. This preserves the chain of custody — a forensic requirement — while enabling accurate event ordering. Investigators and courts can verify your reasoning precisely because you kept the raw data intact. Option A fails because discarding the original timestamp destroys evidence. If your correction math is wrong, or if the clock skew was variable rather than fixed, you have no way to recover or audit the original data. Irreversible changes break forensic integrity. Option B is arguably worse than A — it silently modifies historical records without any notation that an adjustment occurred. This is a form of evidence tampering, even if unintentional. Undocumented alterations are inadmissible and professionally indefensible. Option C is a red herring. Severity is an analyst-assigned or rule-triggered field that has nothing to do with temporal accuracy. Sorting by severity tells you what was important, not when it happened — it does nothing to resolve clock skew. Study tip: On cybersecurity exams, any answer that permanently discards or silently modifies raw log data is almost always wrong. Forensic principles demand preservation first, normalization second, with full documentation of both.

Question 3

Local administrators can clear endpoint logs. A compromised administrator account clears a Security log and later destroys the endpoint. Investigators want future log records to remain available even when an attacker obtains local administrative privileges.

Which design provides the STRONGEST protection against this risk?

Store larger circular logs on each endpoint and permit administrators to clear them when disk utilization becomes high.
Hide the local log viewer from standard users while leaving administrators with normal log-deletion permissions.
Forward events promptly to access-restricted, append-oriented central storage outside endpoint administrative control. (correct answer)
Increase the severity assigned to log-clear events so they cannot be deleted with the rest of the local log.

Explanation: When a question asks how to protect logs from a compromised administrator, your core framework should be separation of privilege and storage boundary. Ask yourself: if an attacker fully controls the endpoint, what resources are still out of reach? Anything stored locally and manageable by local admins is already compromised territory. Option C is the correct and strongest control because it removes logs from the attacker's reach entirely. By forwarding events in real time to a centralized, append-only repository that local administrators cannot access or modify, you ensure that even a fully compromised endpoint — destroyed afterward — leaves a preserved audit trail. The key properties here are promptness (events leave before deletion), append-only architecture (no overwriting), and out-of-band access controls (local admin rights don't extend to the log server). Option A fails because larger circular logs still live on the endpoint under local admin control. A compromised administrator can still clear them; more disk space just delays, rather than prevents, the problem. Option B is purely cosmetic — hiding the log viewer from standard users does nothing when the threat actor already holds administrative credentials, which grant full deletion rights regardless of UI visibility. Option D misunderstands how log deletion works: elevating a log-clear event's severity label doesn't technically prevent deletion; it simply flags it more prominently in the same store the attacker can still wipe. Your study tip: on security architecture questions, always trace the trust boundary. Controls that operate inside the compromised zone provide weak protection. The strongest designs move critical data or functions outside the attacker's administrative domain entirely.

Question 4

A remote office has limited bandwidth. Its endpoints generate verbose diagnostic logs, but investigators occasionally need those details after an incident. Authentication and privilege-change events must reach the central collector promptly.

Which configuration BEST balances bandwidth limits with endpoint forensic value?

Forward selected high-value security events promptly while retaining broader protected local logs under a managed retention policy. (correct answer)
Disable all diagnostic logging at generation time and forward only events that have already triggered an endpoint alert.
Forward every event immediately and shorten central retention so the office connection is not used for historical records.
Store all events only on endpoints and retrieve authentication records manually after analysts confirm an incident.

Explanation: When designing logging architectures for bandwidth-constrained environments, you need to balance three competing priorities: timely delivery of critical events, forensic completeness, and network efficiency. The key insight is that not all log data carries equal urgency — authentication and privilege-change events need near-real-time forwarding, while verbose diagnostics are valuable only retrospectively. Answer A captures this balance precisely. By forwarding high-value security events promptly (satisfying the immediate detection requirement) while retaining broader logs locally under a structured retention policy (preserving forensic depth without saturating the link), you get the best of both worlds. Local retention keeps diagnostic data available for post-incident investigation without consuming bandwidth during normal operations. Answer B is dangerous because it disables diagnostic log generation entirely — data that never exists can never be retrieved. Waiting for an alert to trigger forwarding also creates a circular problem: you may need those logs to understand why an alert fired, but they no longer exist. Answer C trades one problem for another. Forwarding everything immediately consumes exactly the bandwidth you're trying to conserve, and shortening central retention undermines the forensic value investigators need — you end up with neither efficiency nor completeness. Answer D fails the "promptly" requirement for authentication events. Manual retrieval after an incident is confirmed introduces dangerous delays, and storing everything only on endpoints creates a single point of failure if the endpoint is compromised or seized. Study tip: On questions mixing operational constraints (bandwidth, staffing) with security requirements (forensic readiness, real-time alerting), look for the answer that tiers data handling rather than applying a single blanket policy to all events.

Question 5

An endpoint records a successful remote logon to a privileged account at an unusual time. A junior analyst closes the alert because the event outcome is labeled Success rather than Failure.

Which interpretation of the log outcome is MOST accurate?

The success outcome confirms the account owner authorized the activity, because credential theft would produce a failed logon before any successful session.
The success outcome means the audited operation completed; legitimacy still depends on context such as the source host, account, and timing. (correct answer)
The success outcome indicates the endpoint's access-control policy allowed the request but does not confirm that authentication credentials were verified.
The success outcome reflects whether the event record was written without errors, not the result of the underlying logon action itself.

Explanation: When analyzing security logs, you must resist the instinct to equate a "Success" outcome with "nothing bad happened." Log outcome fields describe the technical result of the operation — did the system complete the action? — not the legitimacy or authorization behind it. A privileged account successfully accessed by an attacker using stolen credentials will log exactly the same "Success" as a legitimate administrator logging in normally. Answer B captures this correctly. A successful logon simply means the authentication mechanism completed and access was granted. Whether that event is benign or malicious requires layered context: which account, from where, at what time, and compared to what baseline. Closing an alert solely because the outcome reads "Success" is precisely the mistake that lets insider threats and credential-based attacks go undetected. Answer A is wrong because it assumes credential theft produces a failed logon first. In reality, an attacker who has already obtained valid credentials — through phishing, password spraying, or a data breach — will authenticate successfully on the first attempt. There is no required failure precursor. Answer C describes something closer to authorization (policy evaluation) rather than authentication. "Success" in a logon event specifically reflects completed authentication, not just a policy check that bypassed credential verification. Answer D is wrong because it conflates the event recording outcome with the logon action outcome. These are separate concerns; a log entry can be written correctly while still describing a malicious event. Study tip: On security analyst exams, watch for questions that test whether you understand log fields as technical descriptors, not security verdicts — context always determines legitimacy, never a single field value alone.

Question 6

A SIEM rule treats Windows Event ID 1000 as a single event type. Analysts discover that two different providers use that numeric ID for unrelated conditions, causing false correlations across endpoints.

Which modification would BEST distinguish the events?

Correlate only on the numeric event ID because event IDs are globally unique across all Windows providers.
Include provider, channel, event ID, and relevant version or payload fields when identifying the event type. (correct answer)
Replace the event ID with severity because each severity represents one consistent operating-system action.
Group events by endpoint IP address because identical IDs from one address necessarily share the same meaning.

Explanation: When working with SIEM rules and Windows event logging, you need to understand that event IDs are provider-scoped, not globally unique. A numeric ID like 1000 is meaningful only in combination with the provider that generated it — different providers can reuse the same number for completely unrelated purposes. This is the core trap this question is testing. The best fix, as described in B, is to build event-matching logic that combines the provider name, channel, event ID, and relevant version or payload fields together. This composite fingerprint uniquely identifies what actually happened, eliminating the false correlations caused by two providers sharing the same numeric ID. A is factually wrong — event IDs are not globally unique across all Windows providers. This is precisely the misconception that created the problem in the scenario. Relying solely on the numeric ID guarantees false correlations. C introduces severity as a replacement for event ID, but severity levels (informational, warning, error, critical) are coarse categories shared across thousands of event types. Replacing a specific identifier with a broad category makes correlation less precise, not more. D groups events by endpoint IP address, assuming same-source events share meaning. But if two different providers on the same machine both log event ID 1000, grouping by IP doesn't resolve the ambiguity at all — it actually concentrates the confusion. As a study tip: whenever a SIEM or log-analysis question involves event identification, think composite key, not single field. Provider + channel + event ID is the minimum trustworthy combination for distinguishing Windows events in any real-world detection rule.

Question 7

An endpoint uses a circular event log with a fixed maximum size. Its central collector is unavailable for six hours, but the endpoint continues producing events at a high rate. When connectivity returns, recent events arrive, while the earliest events from the outage are missing locally and centrally.

Which change would MOST directly reduce the chance of the same loss during a future collector outage?

Lower the collector's alert threshold so analysts are notified about a greater number of recent endpoint events.
Clear the endpoint log before maintenance so the forwarding service begins with an empty event queue.
Increase protected local retention or archive logs before rollover, based on expected event volume and outage duration. (correct answer)
Change event timestamps to collector receipt time so records forwarded after an outage remain in sequence.

Explanation: When you see a question about log integrity during connectivity outages, think about the root cause of the loss: a circular (ring) buffer overwrites the oldest entries once it reaches capacity. The problem isn't the outage itself — it's that the endpoint kept generating events faster than the buffer could preserve them, causing early outage events to be overwritten before they could ever be forwarded. That's exactly why C is correct. Increasing the local retention size means the buffer can hold more events before rollover occurs, giving the forwarding service enough runway to catch up once connectivity returns. Alternatively, archiving logs before rollover — essentially snapshotting them to a secondary location — ensures older events survive even when the primary buffer wraps. Both approaches directly attack the mechanism of loss: buffer exhaustion. A is a red herring. Lowering alert thresholds changes analyst notification behavior at the collector, but does nothing to preserve events on the endpoint side. If the events were never retained locally, no threshold adjustment will recover them. B is actively harmful. Clearing the log before maintenance destroys any existing data and gives the forwarding service nothing to work with — it makes the problem worse, not better. D addresses timestamp sequencing, which is a cosmetic ordering issue after events arrive. It doesn't prevent events from being overwritten locally in the first place, so it solves the wrong problem entirely. As a study tip: whenever a scenario involves a circular buffer and data loss, your first instinct should be capacity and retention — ask yourself whether the buffer is large enough to bridge the gap between production rate and forwarding rate.

Question 8

A Linux endpoint contains several security-relevant records in its local logs that never reached the remote syslog server. The configuration uses connectionless transport, and packet loss occurred during a network congestion event.

Which change would BEST improve delivery reliability without assuming that encryption alone prevents message loss?

Use a reliable stream transport with authenticated encryption and configure local queuing for temporary delivery failures. (correct answer)
Retain connectionless transport but increase message severity so network devices prioritize every security event.
Enable authenticated encryption over the existing connectionless transport because authentication guarantees retransmission.
Disable local logging after transmission so duplicate records cannot consume storage during periods of congestion.

Explanation: When evaluating log delivery reliability, you need to think about two distinct layers: the transport mechanism and the storage/queuing strategy. A question like this is testing whether you understand that encryption and authentication are about confidentiality and integrity, not delivery guarantees. The core problem here is that connectionless transport — UDP, which syslog traditionally uses — offers no retransmission. When network congestion causes packet loss, those log messages are simply gone. The fix requires addressing both the transport and the failure-recovery strategy. Answer A does exactly this: switching to a reliable stream transport (TCP) means the protocol itself handles retransmission, and adding local queuing ensures that if the remote server is temporarily unreachable, messages are buffered locally and delivered once connectivity recovers. Authenticated encryption is included as a security enhancement, not the reliability mechanism — that distinction matters. Answer B is a trap. Increasing message severity may affect QoS prioritization on some devices, but it doesn't guarantee delivery and doesn't address the fundamental problem that UDP has no retransmission mechanism. You'd still lose packets under heavy congestion. Answer C contains a classic misconception: authentication verifies who sent a message and confirms integrity, but it does not trigger retransmission. Authentication operates at the cryptographic layer, not the transport reliability layer. Connectionless transport with authentication still drops packets silently. Answer D is counterproductive. Disabling local logging after transmission eliminates your only fallback. If transmission fails, those records are permanently lost — the exact problem you're trying to solve. Your study tip: whenever you see "encryption" or "authentication" offered as a solution to a delivery or availability problem, treat it as a distractor. Reliability requires transport-layer guarantees, not cryptographic ones.

Question 9

An endpoint sends the same event through both a native event-forwarding subscription and a security agent. The collector receives two records with slightly different receipt times and formats, causing an alert rule to count one failed logon twice.

Which approach would BEST reduce false duplicate counts while preserving genuinely repeated failed logons?

Discard every second failed-logon record received from each endpoint, regardless of event content or forwarding path.
Deduplicate records solely by source IP address because one endpoint can produce only one failed logon at a time.
Keep only the first failed-logon event per user each day and suppress all later events for that account.
Normalize both feeds and deduplicate using stable source-event attributes within a narrowly defined time window. (correct answer)

Explanation: When dealing with duplicate events in a SIEM or log-collection pipeline, the core challenge is distinguishing accidental duplicates (same event, two delivery paths) from genuine repeated events (two real failed logons). The right deduplication strategy must suppress the former without masking the latter. The best approach, reflected in D, is to normalize both feeds into a common schema first, then compare records using stable, event-specific attributes — such as username, endpoint hostname, event ID, and originating timestamp — within a tight time window (e.g., 5–10 seconds). If two records share those attributes and arrive within that window, they're almost certainly the same event delivered twice. Records outside that window, or with different attributes, represent distinct logon failures and are preserved. Each wrong answer creates a different kind of blind spot. A blindly discards every second record regardless of content, meaning a real second failed logon attempt could be silently dropped — a serious detection gap. B deduplicates only on source IP, which ignores that a single IP can host multiple users or services generating independent failed logons simultaneously; you'd lose legitimate security events. C keeps only the first failed logon per user per day, completely suppressing evidence of brute-force or credential-stuffing attacks that generate dozens of failures — exactly the pattern you want to catch. A useful study tip: whenever a question involves deduplication or correlation in security monitoring, ask yourself "does this method destroy real signal?" The correct approach always uses a combination of content matching and time bounding — neither attribute alone is sufficient, and neither should override genuine event uniqueness.

Question 10

A syslog collector has a rule that accepts only messages with the authpriv facility and a severity of warning or more severe. Assume the sender labels every message correctly.

Which message will the collector accept under this rule?

An authpriv.notice message reporting a successful authentication-policy change.
An authpriv.err message reporting repeated authentication-service failures. (correct answer)
A local0.crit message reporting a critical failure in a custom service.
An auth.info message reporting a routine user authentication attempt.

Explanation: When filtering syslog messages, two conditions must both be satisfied: the facility must match, and the severity must meet the threshold. Syslog severities are ranked 0–7, where lower numbers are more severe — Emergency (0) through Debug (7). "Warning or more severe" means a severity level of Warning (4) or lower numerically: Warning, Error, Critical, Alert, and Emergency all qualify. Notice (5), Info (6), and Debug (7) do not. Choice B — authpriv.err — satisfies both conditions perfectly. The facility is authpriv ✓, and Error (severity 3) is more severe than Warning (severity 4), so it clears the threshold ✓. This is your correct answer. Choice A fails on severity. authpriv.notice has the right facility, but Notice is severity 5, which is less severe than Warning (4). It doesn't meet the threshold and gets dropped. Choice C fails on facility. local0.crit has a severity of Critical (2), which would easily pass the threshold — but the facility is local0, not authpriv. Both conditions must match, and this one fails the facility check entirely. Choice D fails on both counts. auth.info uses the auth facility (different from authpriv — these are distinct in syslog) and has a severity of Info (6), which is well below the Warning threshold. A useful memory aid: think of syslog severity as a countdown from crisis to calm — the lower the number, the higher the urgency. Whenever a question sets a minimum severity, translate it mentally to "this number or smaller."