Cyber Security Quiz: Log Interpretation And Correlation
10 questions · exam conditions
0:00
Log Interpretation And CorrelationQuestion 1 of 10

A Windows host records these events:

Security event 4624: Computer=WEB01 SubjectUserName=WEB01$ TargetUserName=mrivera LogonType=3 IpAddress=10.1.4.25 TargetLogonId=0x91A2

Security event 4688 twelve seconds later: Computer=WEB01 SubjectUserName=mrivera SubjectLogonId=0x91A2 NewProcessName=C:\Windows\System32\cmd.exe

Which interpretation is best supported by correlating the fields in these events?

The WEB01 computer account remotely logged on to host 10.1.4.25
The mrivera account received a network logon on WEB01 and then started cmd.exe
The mrivera account used an interactive console logon directly on WEB01
The WEB01 computer account started cmd.exe under its machine identity
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Log Interpretation And Correlation

Practice Log Interpretation And Correlation 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 Log Interpretation And Correlation, 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

A Windows host records these events:

Security event 4624: Computer=WEB01 SubjectUserName=WEB01$ TargetUserName=mrivera LogonType=3 IpAddress=10.1.4.25 TargetLogonId=0x91A2

Security event 4688 twelve seconds later: Computer=WEB01 SubjectUserName=mrivera SubjectLogonId=0x91A2 NewProcessName=C:\Windows\System32\cmd.exe

Which interpretation is best supported by correlating the fields in these events?

  1. The WEB01 computer account remotely logged on to host 10.1.4.25
  2. The mrivera account received a network logon on WEB01 and then started cmd.exe (correct answer)
  3. The mrivera account used an interactive console logon directly on WEB01
  4. The WEB01 computer account started cmd.exe under its machine identity
Explanation: When correlating Windows Security events, the key is treating shared field values as a chain of evidence — the same ID appearing across multiple events proves they belong to the same session or actor. Here, Event 4624 tells you a network logon (LogonType=3) occurred on WEB01, where the TargetUserName is mrivera and the assigned TargetLogonId is 0x91A2. Twelve seconds later, Event 4688 shows a new process (cmd.exe) launched by mrivera with SubjectLogonId 0x91A2 — the exact same logon session ID. This linkage confirms that the same authenticated session that began with the network logon was used to spawn the command shell. That makes B the best-supported interpretation. A is backwards. The SubjectUserName WEB01$ in Event 4624 is the machine account authenticating the incoming request (the host vouching for the logon), not an account logging into 10.1.4.25. The IP address is the source of the connection, not the destination. C is wrong because LogonType=3 explicitly means a network logon, not an interactive console session. Interactive logons produce LogonType=2. If mrivera had sat at the keyboard, you'd see a different logon type with no IpAddress field. D is wrong because Event 4688 clearly shows SubjectUserName=mrivera, not WEB01$. The machine account initiated the authentication handshake, but the process was launched under the human user's identity. As a study habit, always cross-reference LogonId fields between 4624 and 4688 events — that pairing is a classic log correlation technique tested repeatedly on security exams.

Question 2

An email traverses two relays that assign different local queue identifiers:

Gateway: 14:10:02 queue_id=Q17 message_id=<8ab3@example.test> sender=payroll@example.test recipient=user@company.test action=accepted Relay: 14:10:08 queue_id=R92 original_message_id=<8ab3@example.test> action=forwarded

The DLP system records the following events:

Event 1: 14:10:09 queue_id=R92 verdict=sensitive_attachment Event 2: 14:10:10 queue_id=Q17 verdict=clean Event 3: 14:10:11 queue_id=R19 verdict=sensitive_attachment

Which DLP event can be most reliably correlated with the forwarded message?

  1. All three events, because they occurred shortly after the gateway acceptance
  2. Event 2, because the gateway queue identifier matches the accepted record
  3. Event 3, because its verdict and timestamp resemble the suspected message
  4. Event 1, because the relay queue identifier matches the forwarded record (correct answer)
Explanation: When analyzing email log correlation, your job is to trace a single message across multiple systems using identifiers that travel with it — not just timestamps or verdicts. Here, the key linkage is the message_id field. The gateway assigns queue_id=Q17 and stamps the message with message_id=<8ab3@example.test>. When the relay receives and forwards it, it creates a new local queue ID (queue_id=R92) but explicitly references the original via original_message_id=<8ab3@example.test>. This is the handoff record — it proves R92 and Q17 refer to the same email. Event 1 references queue_id=R92, directly matching the relay's forwarded record. That makes Event 1 the most reliably correlated DLP event. Answer D is correct. Answer B is a tempting trap — Q17 does appear in the gateway acceptance log, but Event 2 fires after forwarding has already occurred and carries a clean verdict contradicting the relay's sensitive content flag. Using Q17 at this stage conflates the gateway's local identifier with the relay's processing. Answer A fails because proximity in time alone is not a reliable correlation method — coincidental timing could link completely unrelated messages. Answer C is the most dangerous distractor: it relies on circumstantial evidence (similar verdict, nearby timestamp) rather than a verified identifier chain. R19 appears nowhere in the passage's relay or gateway logs, so there's no documented link to this message at all. When correlating logs across mail hops, always follow the identifier chain — specifically fields like original_message_id or X-Original-Message-ID — rather than trusting timestamps or matching verdicts alone.

Question 3

A SIEM displays both the source event time and the ingestion time for three records:

Record 1: event_time=11:02:10 ingest_time=11:02:15 event=VPN_LOGIN Record 2: event_time=11:03:00 ingest_time=11:08:40 event=EDR_PROCESS_START Record 3: event_time=11:04:20 ingest_time=11:04:25 event=PROXY_CONNECT

The source clocks are synchronized, but the EDR collector experienced a delivery delay.

Which sequence should the analyst use when reconstructing activity on the endpoint?

  1. Proxy connection, VPN login, and then process start
  2. VPN login, proxy connection, and then process start
  3. Process start, VPN login, and then proxy connection
  4. VPN login, process start, and then proxy connection (correct answer)
Explanation: When reconstructing a timeline in a SIEM, you must always prioritize event time (when the action actually occurred on the system) over ingest time (when the SIEM received the log). Ingest time reflects network and collector latency, not reality — using it would distort your understanding of what happened and when. Looking at the event timestamps, the correct chronological order is straightforward: VPN_LOGIN at 11:02:10, EDR_PROCESS_START at 11:03:00, and PROXY_CONNECT at 11:04:20. This makes D the correct answer — VPN login, process start, then proxy connection. The EDR record arrived late (ingest at 11:08:40), but the source clock was synchronized and trustworthy, so the 11:03:00 event time stands. A is wrong because it places the proxy connection first, which ignores event timestamps entirely and instead mirrors an ingest-time ordering — a classic trap. B is wrong for the same reason: it correctly places VPN login first but then skips the process start, placing proxy connection second, which contradicts the actual event times. C is the most dangerous distractor — it places process start first, as if the late ingest time means the event happened later rather than earlier, completely inverting the reality of the delivery delay. A useful rule of thumb: when a question mentions clock synchronization alongside a delivery delay, it's signaling that event time is reliable even when ingest time looks suspicious. Always anchor your timeline to event time, and treat ingest time only as a diagnostic clue about collector health — not as a substitute for when events occurred.

Question 4

A proxy log contains the following entry:

time=16:22:10 user=jlee method=CONNECT destination=updates.bad-example.test:443 action=allowed bytes_from_client=517 bytes_to_client=0

No TLS-decryption logs or endpoint telemetry are available for this period.

What is the strongest conclusion supported by this record alone?

  1. The proxy permitted an authenticated connection attempt toward the destination (correct answer)
  2. The endpoint completed a TLS handshake and downloaded malicious content
  3. The destination rejected the connection before receiving any client traffic
  4. The user intentionally executed malware obtained from the destination
Explanation: When analyzing proxy logs, your job is to identify exactly what the log proves versus what it merely suggests. Proxy logs record the proxy's own actions — not what happened inside the tunnel afterward. The CONNECT method tells you the proxy established a tunnel toward updates.bad-example.test:443 on behalf of authenticated user jlee, and the action=allowed field confirms the proxy permitted it. That's precisely what A states — an authenticated connection attempt was permitted toward the destination. Notice the careful wording: "attempt," not "success." The log proves the proxy acted; it cannot prove what happened beyond that. B is a significant overreach. Without TLS decryption logs or endpoint telemetry (which the passage explicitly tells you are unavailable), you cannot confirm a handshake completed, let alone that malicious content was downloaded. The tunnel is opaque to the proxy. C contradicts the data. bytes_from_client=517 shows the client did send data into the tunnel, meaning traffic reached (or at least left toward) the destination. A rejection before receiving client traffic would typically show zero client bytes. D goes far beyond what any log record can establish. Intent and the presence of malware require forensic investigation, not a single proxy entry. A useful rule of thumb for exam questions like this: scope your conclusion to the data source. A proxy log proves proxy behavior. Endpoint behavior, network outcomes, and user intent each require their own evidence sources. When distractors make claims beyond the available data, eliminate them.

Question 5

A stateful firewall records these entries with synchronized timestamps:

13:40:10 session=771 interface=inside direction=out src=10.2.7.9:53120 dst=203.0.113.40:443 flags=S action=allow 13:40:10 session=771 interface=outside direction=in src=203.0.113.40:443 dst=10.2.7.9:53120 flags=SA action=allow

What is the best interpretation of the second record?

  1. It is an unsolicited inbound connection initiated by the external server
  2. It is a second outbound connection with reversed address logging
  3. It is a response associated with the internally initiated TCP session (correct answer)
  4. It is proof that application data was successfully exchanged over TLS
Explanation: When analyzing stateful firewall logs, the key is understanding that a stateful firewall tracks sessions, not just individual packets. Each logged entry belongs to a conversation, identified here by session=771 appearing in both records. In the first record, an internal host (10.2.7.9) initiates a TCP handshake — notice flags=S (SYN) — toward an external server on port 443. The firewall permits this outbound request and creates a session table entry. When the external server responds with flags=SA (SYN-ACK), the firewall consults its session table, recognizes this as the expected reply to session 771, and allows it inbound. This is exactly what C describes: the second record is the server's TCP handshake response to an internally initiated session. A is wrong because "unsolicited inbound connection" would appear as a new session with a SYN flag, not a SYN-ACK on an already-established session ID. Stateful firewalls specifically block unsolicited inbound SYNs unless a matching outbound SYN was recorded first. B is wrong because both records share the same session=771, confirming they're part of one bidirectional flow — not two separate connections. Address reversal between the records is normal and expected for return traffic. D is wrong because flags=SA is a TCP handshake packet, occurring before any application-layer data exchange. TLS negotiation and data transfer happen later in the session; this log only shows the connection being established. Your study tip: always cross-reference the session ID, flags, and direction fields together — stateful firewall questions test whether you understand that return traffic is expected, not suspicious.

Question 6

A DHCP server and a DNS resolver provide these records:

08:00 DHCPACK ip=10.8.2.19 mac=00:11:22:33:44:55 lease_end=12:00 09:12 DHCPRELEASE ip=10.8.2.19 mac=00:11:22:33:44:55 09:14 DHCPACK ip=10.8.2.19 mac=AA:BB:CC:DD:EE:FF lease_end=13:14 09:20 DNS_QUERY client_ip=10.8.2.19 name=command.example.test

The DHCP and DNS systems use synchronized clocks.

Which device is most directly associated with the DNS query?

  1. The device with MAC address 00:11:22:33:44:55 because its original lease had not expired
  2. The device with MAC address AA:BB:CC:DD:EE:FF because it held the latest active lease (correct answer)
  3. Both devices equally because the same IP address appeared in each DHCP acknowledgment
  4. Neither device because DNS records cannot be correlated with dynamically assigned addresses
Explanation: When correlating network activity to a specific device, the key is determining which device held the IP address at the exact moment the event occurred. IP-to-device mappings change over time with dynamic addressing, so timestamps are everything. Walk through the timeline: the first device (MAC 00:11:22:33:44:55) received 10.8.2.19 at 08:00 but voluntarily released it at 09:12 via DHCPRELEASE. That release terminated the lease early — the lease expiration of 12:00 became irrelevant the moment the device gave up the address. Two minutes later at 09:14, a second device (MAC AA:BB:CC:DD:EE:FF) received a fresh DHCPACK for the same IP, valid until 13:14. The DNS query fired at 09:20 — squarely within that second lease window. Therefore, B is correct: the device with MAC AA:BB:CC:DD:EE:FF held the active lease at query time. A is wrong because it ignores the DHCPRELEASE event. A released lease doesn't "survive" until its original expiration — the device relinquished the address voluntarily and explicitly. Treating the original expiry as still binding is a critical forensic error. C is wrong because sharing the same IP at different times creates no meaningful equivalence. The IP is a time-scoped identifier, not a permanent one. D is wrong because DHCP logs exist precisely to enable this kind of correlation — it's a standard forensic and incident-response technique called IP-to-MAC binding analysis. For the exam, remember: always check for early releases before assuming a lease is active. The lease end time is a ceiling, not a guarantee.

Question 7

A NAT gateway records the following outbound translation:

12:10:08 internal=10.20.5.44:51514 translated=198.51.100.8:62001 destination=203.0.113.77:443 protocol=tcp

An external intrusion-detection sensor records several connections at approximately the same time.

Which IDS record most directly corresponds to the translated connection?

  1. src=10.20.5.44:51514 dst=203.0.113.77:443 protocol=tcp
  2. src=198.51.100.8:51514 dst=203.0.113.77:443 protocol=tcp
  3. src=198.51.100.8:62001 dst=203.0.113.77:443 protocol=tcp (correct answer)
  4. src=203.0.113.77:443 dst=198.51.100.8:62001 protocol=tcp
Explanation: When an external IDS sensor monitors traffic, it sees packets after NAT has been applied — meaning it observes the translated (public-facing) addresses, not the original internal ones. This is the core concept being tested: understanding which address pair is visible to a sensor positioned outside the NAT gateway. Looking at the NAT log, the gateway took the internal source 10.20.5.44:51514 and replaced it with the public address and new port 198.51.100.8:62001 before sending the packet toward 203.0.113.77:443. An external IDS sitting outside the NAT device sees exactly this translated packet — source 198.51.100.8:62001, destination 203.0.113.77:443. That makes C the correct match. A is wrong because it shows the pre-NAT internal address 10.20.5.44:51514 as the source. An external sensor never sees the internal RFC 1918 address — that's the whole point of NAT. B uses the correct public IP but keeps the original source port 51514 instead of the translated port 62001. PAT (Port Address Translation) replaces both the IP and the source port, so this is a subtle but important error. D flips the source and destination entirely, which would represent an inbound reply from the remote server back to the gateway, not the outbound connection the question describes. A useful rule of thumb: always ask yourself where the sensor is positioned relative to the NAT boundary. Inside the boundary → original addresses; outside the boundary → translated addresses. Sensor placement determines what traffic it can see.

Question 8

During an investigation, an analyst confirms that the authentication server's clock was 4 minutes 20 seconds fast. The application server's clock was accurate.

Authentication log: 10:02:50 user=ksingh event=MFA_APPROVED request_id=7F31 Application log: 09:58:45 user=ksingh event=SESSION_CREATED request_id=7F31

Which interpretation best accounts for the clock difference and the shared request identifier?

  1. The application session preceded MFA approval by approximately four minutes
  2. MFA approval preceded application session creation by approximately fifteen seconds (correct answer)
  3. Both events occurred simultaneously because their request identifiers match
  4. The records cannot be correlated because their displayed timestamps differ
Explanation: When correlating logs across systems in a forensic investigation, your first job is clock normalization — adjusting all timestamps to a common reference before drawing any conclusions about event ordering. Here, the authentication server was running 4 minutes and 20 seconds fast. That means every timestamp it recorded is inflated by that amount. To find the true time of the MFA event, subtract the skew: 10:02:50−0:04:20=09:58:3010{:}02{:}50 - 0{:}04{:}20 = 09{:}58{:}30 Now compare the normalized events:
  • MFA approved (normalized): 09:58:30
  • Session created (accurate): 09:58:45
MFA approval happened roughly 15 seconds before session creation — which is exactly the expected behavior. A user authenticates, then the application creates a session. The shared request_id=7F31 confirms these two records describe the same transaction. B is correct because it accurately reflects this corrected sequence. A is tempting if you skip normalization entirely and read the raw timestamps at face value — 10:02:50 vs. 09:58:45 looks like about four minutes, but that gap is the clock skew, not a real-world delay. C conflates correlation with simultaneity. Matching request IDs prove the events are related, not that they happened at the same instant. D is the "give up" answer. Differing timestamps don't make correlation impossible — that's precisely why clock normalization exists. Study tip: On security and forensics questions, always ask "are these clocks synchronized?" before interpreting any timestamp ordering. Clock skew is one of the most common sources of misleading log sequences.

Question 9

An analyst reviews the following records. The VPN and proxy log in UTC, while the endpoint record includes its local UTC offset.

VPN: 2026-03-18T14:03:12Z user=aramos action=login result=success src=198.51.100.24 EDR: 2026-03-18T09:03:58-05:00 host=LAP-22 user=aramos process=powershell.exe Proxy: 2026-03-18T14:04:15Z user=aramos host=LAP-22 action=CONNECT dst=files.example.net

After normalizing the timestamps, which sequence of events is correct?

  1. VPN login, PowerShell execution, and then proxy connection (correct answer)
  2. PowerShell execution, VPN login, and then proxy connection
  3. VPN login, proxy connection, and then PowerShell execution
  4. PowerShell execution, proxy connection, and then VPN login
Explanation: When logs come from different sources, timestamps often use different formats and offsets — your first job is always to normalize everything to UTC before drawing any conclusions. Here's how to do that with these three records. The VPN log is already in UTC: 14:03:12Z. The proxy log is also UTC: 14:04:15Z. The EDR record, however, uses a local time with a −05:00 offset, meaning local time is five hours behind UTC. To convert 09:03:58−05:00 to UTC, you add five hours: 14:03:58Z. Sorted chronologically in UTC, the sequence is:
  • 14:03:12Z — VPN login (aramos authenticates)
  • 14:03:58Z — PowerShell execution on LAP-22 (46 seconds later)
  • 14:04:15Z — Proxy connection to files.example.net (77 seconds after VPN)
That makes A correct: VPN login → PowerShell execution → proxy connection. This also tells a coherent attack story — the user logs in remotely, launches PowerShell, then exfiltrates or fetches data through the proxy. B is wrong because it places PowerShell before the VPN login, which would only be true if you misread the raw 09:03 as UTC rather than converting it. C incorrectly swaps PowerShell and the proxy connection, ignoring that 14:03:58 precedes 14:04:15. D inverts nearly everything, suggesting PowerShell and the proxy ran before the VPN login — a reversal of all three events. The study tip: whenever you see mixed UTC offsets in log analysis questions, convert all timestamps to UTC first before answering anything about sequence. Treat raw local times as traps.

Question 10

A detection rule generates an alert when the same source produces at least four failed logins for the same account within an inclusive five-minute window, followed by a successful login for that account within two minutes after the qualifying window.

10:00:00 src=192.0.2.44 user=admin result=fail 10:01:00 src=192.0.2.44 user=admin result=fail 10:03:00 src=192.0.2.44 user=root result=fail 10:04:00 src=192.0.2.44 user=admin result=fail 10:05:00 src=192.0.2.44 user=admin result=fail 10:06:30 src=192.0.2.44 user=admin result=success

How should the rule evaluate these events?

  1. Generate an alert because admin has four failures followed by a timely success (correct answer)
  2. Do not alert because the root failure breaks the consecutive admin sequence
  3. Do not alert because the first and fourth admin failures are five minutes apart
  4. Generate an alert because all five failures count regardless of account name
Explanation: When analyzing detection rules, your job is to apply the rule's exact criteria — no more, no less — to the log data. Break the rule into its components and check each one independently. Here, the rule requires: (1) at least four failed logins for the same account from the same source within an inclusive five-minute window, and (2) a successful login for that account within two minutes after that window closes. Filtering only user=admin failures from 192.0.2.44, you get four events: 10:00:00, 10:01:00, 10:04:00, and 10:05:00. The window spanning 10:00:00 to 10:05:00 is exactly five minutes — inclusive means both endpoints count, so this satisfies condition one. The successful admin login at 10:06:30 falls 90 seconds after 10:05:00, well within the two-minute threshold. Answer A is correct. Answer B is wrong because the rule filters by account name. The root failure at 10:03:00 belongs to a different account and is simply irrelevant to the admin evaluation — it doesn't "break" anything. Answer C contains a subtle but critical error: it treats the window as exclusive. Because the rule explicitly says inclusive, 10:00:00 to 10:05:00 is exactly five minutes and fully qualifies. Don't let the word "apart" mislead you into subtracting one endpoint. Answer D is wrong because mixing account names violates the rule's "same account" requirement. Bundling root and admin failures together misreads the rule's scope. Study tip: When a rule specifies inclusive boundaries, always count both endpoints. This single word frequently determines whether a window qualifies or not on detection-logic questions.