Cyber Security Quiz: Security Logging
10 questions · exam conditions
0:00
Security LoggingQuestion 1 of 10

Five administrators use the same privileged application account. Audit logs record the account name, source jump host, action, target object, and timestamp. All administrators connect through that same jump host.

What is the principal limitation of these logs for incident attribution?

They cannot show which target object changed because shared accounts suppress application event details
They can show what the shared account did but cannot independently identify which individual performed the action
They cannot establish whether an action succeeded because the shared account prevents completion-status recording
They can reliably attribute actions to one administrator because each session produces a unique source-port entry
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Security Logging

Practice Security 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 Security 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

Five administrators use the same privileged application account. Audit logs record the account name, source jump host, action, target object, and timestamp. All administrators connect through that same jump host.

What is the principal limitation of these logs for incident attribution?

  1. They cannot show which target object changed because shared accounts suppress application event details
  2. They can show what the shared account did but cannot independently identify which individual performed the action (correct answer)
  3. They cannot establish whether an action succeeded because the shared account prevents completion-status recording
  4. They can reliably attribute actions to one administrator because each session produces a unique source-port entry
Explanation: When evaluating audit logs for incident attribution, the key question is: do the logs tell you who (the individual human) or just what (the account)? These are fundamentally different, and this distinction is what the question tests. Because all five administrators share a single privileged account, the logs can accurately record that the account performed an action — the timestamp, target object, and action type may all be perfectly intact. But the logs cannot tell you which person was behind that account at that moment. That's precisely why B is correct: the logs show what the shared account did but cannot independently identify the individual responsible. This is the core limitation of shared accounts in forensic investigations — you lose non-repudiation, meaning no single person can be held accountable because everyone can claim someone else did it. A is wrong because shared accounts don't inherently suppress application event details like target objects — the scenario even states that target objects are recorded. This distractor invents a technical limitation that doesn't exist. C is wrong for a similar reason: completion-status recording is not suppressed by shared account usage. That detail depends on how the application logs events, not on whether the account is shared. D is the sneakiest trap. Unique source-port entries are real artifacts, but they're ephemeral, non-authoritative, and don't map to a specific individual — they map to a network session. Ports are not identity credentials. A useful pattern to remember: whenever you see shared accounts in a security scenario, your first thought should be "non-repudiation is broken." That framing will guide you through attribution questions reliably.

Question 2

The security team commonly discovers account misuse about 75 days after it begins. Authentication logs are retained for 90 days, but detailed application audit logs and network flow records are retained for only 30 days.

Which change would MOST improve the team's ability to reconstruct these incidents?

  1. Increase authentication retention only, because a successful sign-in fully explains later application and network activity
  2. Retain application exception messages longer, because errors provide the same evidence as security audit events
  3. Keep current retention periods but collect more verbose records during the first 30 days after each event
  4. Extend relevant application and network retention beyond the detection window and preserve correlation fields (correct answer)
Explanation: When analyzing incident reconstruction questions, focus on the gap between when an attack begins and when it's detected — that window determines what evidence must survive long enough to be useful. Here, discovery happens at day 75, but application and network logs only last 30 days. That means by the time the team investigates, the most detailed evidence of what the attacker did has already been deleted. D is correct because it directly closes this gap. Extending application and network log retention beyond 75 days ensures evidence still exists when investigation begins. Preserving correlation fields — shared identifiers like session IDs, user IDs, or timestamps — is equally critical, because logs from different sources are only useful if you can link them together into a coherent attack timeline. A is wrong because it assumes authentication logs tell the whole story. Knowing someone logged in doesn't explain which data they accessed, what commands they ran, or which systems they moved to laterally. Authentication is the door; application and network logs are everything that happens inside. B contains a subtle trap: exception and error messages are diagnostic artifacts, not security audit trails. They record software failures, not user actions. An attacker operating successfully may generate no errors at all, leaving this log source completely silent. C sounds reasonable but misunderstands the problem. Verbose collection in the first 30 days doesn't help if those records are still deleted before detection occurs. Volume of detail is irrelevant if retention is the bottleneck. For exam strategy, whenever a question involves detection lag, immediately calculate whether retention periods exceed that lag — if they don't, extending retention is almost always the right fix.

Question 3

A user with legitimate access repeatedly submits refund requests just below the approval threshold. The requests use normal HTTPS sessions, valid tokens, and permitted API endpoints.

Which logging source is MOST useful for detecting this potential business-logic abuse?

  1. Firewall logs listing allowed connections to the API service on the expected destination port
  2. DNS logs listing successful name resolutions for the API service during the workday
  3. Authentication logs listing successful token validations and routine session expiration events
  4. Application audit logs listing refund amounts, account identities, approval paths, and transaction outcomes (correct answer)
Explanation: When a question describes suspicious behavior rather than suspicious traffic, your instinct should shift away from network-layer logs and toward logs that capture what users are actually doing inside an application. Business-logic abuse is the key concept here: the attacker isn't breaking any technical rules — the sessions are valid, the tokens are legitimate, the ports are allowed. The threat lives entirely in the pattern of transactions. That's exactly why D is correct. Application audit logs that record refund amounts, account identities, approval paths, and transaction outcomes give you the semantic context needed to spot the pattern — repeated requests clustering just below an approval threshold. No other log source can tell you what was requested, by whom, and what happened as a result. A is a trap for students who default to network-based detection. Firewall logs confirm that HTTPS connections to the API were permitted, but they carry zero information about what those requests contained or what business action occurred. B is similarly shallow — DNS resolution logs only confirm that a hostname was looked up, offering no transactional context whatsoever. C is the subtlest distractor: authentication logs do tie identity to sessions, but "token validated, session expired normally" tells you nothing about the refund amounts or how many were submitted. Successful authentication is expected behavior; it's the actions after authentication that reveal the abuse. The study tip here: when a scenario describes abuse by a legitimate user, network and auth logs will appear clean by design. Always ask, "Which log captures the business action, not just the connection?" That question will consistently point you toward application-layer audit logs.

Question 4

A web application firewall reports that it blocked several SQL injection attempts. Investigators must determine whether a later request actually caused customer records to be returned to a user.

Which source would provide the MOST relevant evidence about the suspected data disclosure?

  1. Firewall flow logs showing that a TCP connection to the web server was allowed
  2. Authentication logs showing that the requesting account had signed in earlier that day
  3. Web application firewall logs showing the signature assigned to each blocked attempt
  4. Application audit logs recording the account, endpoint, response outcome, and request correlation identifier (correct answer)
Explanation: When investigating a suspected data disclosure, you need to ask: what evidence would show that sensitive data was actually returned to a user? That question immediately narrows your focus to application-layer logs, not network- or authentication-layer logs, because only the application knows what data it served in its response. Application audit logs (D) are the strongest evidence precisely because they capture the full picture of a transaction: the account involved, the endpoint hit, the response outcome (did the server return records or an error?), and a correlation identifier that lets you trace a specific request end-to-end across multiple log sources. If customer records were disclosed, the response outcome field and correlated request chain will show it. Option A is a trap because TCP flow logs only confirm a connection was permitted — they say nothing about what data traveled through that connection or whether a query succeeded in extracting records. A firewall "allowed" log is no evidence of disclosure. Option B is similarly off-track. Authentication logs confirm identity and session establishment, but a valid login earlier in the day has no bearing on whether a later, potentially malicious request returned sensitive data. Legitimate credentials don't rule out misuse. Option C is the most tempting distractor — WAF logs are directly relevant to SQL injection — but they only record blocked attempts and their signatures. By definition, a blocked request didn't return data. The question asks about a later request that may have succeeded, which the WAF logs won't cover. Study tip: On questions about data disclosure investigations, always chase the log source closest to the response — application audit logs beat network and perimeter logs every time.

Question 5

An internet-facing application is located behind a reverse proxy. Every application access-log entry lists the proxy's address as the client address, while the proxy records the original client address.

Which logging design would BEST preserve reliable source attribution during an investigation?

  1. Record only the application server's TCP peer address because it cannot be supplied by an external client
  2. Accept a client-provided forwarded-address value and store it directly in application access logs
  3. Correlate proxy and application request identifiers while trusting forwarded addresses only from the managed proxy (correct answer)
  4. Use DNS logs to translate the proxy address into the hostname originally requested by each client
Explanation: When an application sits behind a reverse proxy, every request passes through an intermediary, which creates a fundamental attribution problem: the application only sees the proxy's IP, while the proxy alone knows the real client. Questions like this test whether you understand how to build a logging architecture that is both complete and tamper-resistant. The strongest design, captured in C, combines two complementary controls. First, it uses a correlated request identifier (such as a unique request ID injected by the proxy) so that proxy logs and application logs can be joined during an investigation — giving you the full picture. Second, it accepts forwarded-address headers (like X-Forwarded-For) only when they originate from the managed, trusted proxy. Because the proxy is infrastructure you control, its headers carry meaningful assurance; an attacker on the open internet cannot impersonate that source. A is appealing because TCP peer addresses genuinely cannot be spoofed by an external client — but that peer address is always the proxy, never the real user. Recording only that address leaves you with no useful attribution at all. B describes a classic injection attack vector. If any external client can supply a forwarded-address header and your application logs it without validation, an attacker simply crafts a false IP to pollute your audit trail and obscure their identity. D is a red herring. DNS reverse lookups resolve the proxy's hostname, not anything about the original client. Translating the proxy address to a hostname tells you nothing new about who initiated the request. Remember: in proxy architectures, trustworthy attribution requires both a correlation mechanism and a trusted boundary for forwarded metadata — neither alone is sufficient.

Question 6

A firewall log shows that an employee workstation established an allowed HTTPS connection to an internal reporting server. Minutes later, a sensitive report was exported from that server.

Which evidence would BEST establish that a particular account performed the export successfully?

  1. An application audit event identifying the account, export action, object, and completion status (correct answer)
  2. A firewall event identifying the workstation, server address, destination port, and allowed action
  3. A DNS log showing that the workstation resolved the reporting server's hostname
  4. A network flow record showing the connection duration and total number of transferred bytes
Explanation: When a question asks you to establish that a specific account performed a specific action successfully, you're being tested on the difference between network-layer evidence and application-layer evidence. Network logs can tell you that a connection happened — application audit logs tell you who did what and whether it worked. Answer A is correct because an application audit event captures exactly what accountability requires: the identity (which account), the action (export), the object (which report), and the outcome (completion status). This is the only option that directly ties a named user to the sensitive action itself. Without the account identity and success status, you cannot definitively attribute the export to anyone. Answer B describes a firewall event, which confirms that a workstation was permitted to reach the server over HTTPS. It tells you about the connection, not the action — and crucially, it identifies a machine, not a user account. Multiple users could share a workstation. Answer C shows a DNS resolution, which only confirms that the workstation looked up the server's hostname. This is even further removed from the export event — it's a precursor to a connection, not evidence of what happened during it. Answer D provides a network flow record with duration and byte count. While a large transfer might suggest a file export occurred, it cannot tell you which account initiated it, what was exported, or whether the action completed successfully. Correlation is not attribution. Study tip: On security questions about accountability and attribution, always ask: does this log identify a user and confirm an outcome? Only application-layer audit logs typically do both.

Question 7

Authentication logs use UTC, network-device logs use local time, and application logs use local time with no time-zone field. Investigators are trying to correlate a sign-in, a connection, and an administrative change that occurred within several minutes.

What should investigators do FIRST to avoid drawing an incorrect sequence of events?

  1. Sort all events by their recorded timestamps and treat matching usernames as confirmation of sequence
  2. Determine each source's time zone and clock offset, then normalize timestamps before correlating events (correct answer)
  3. Use the network-device timestamps because packet-handling systems provide the authoritative event order
  4. Group events by source address because address matching removes the need to compare timestamps
Explanation: When correlating events across multiple log sources, your first instinct should be to ask: "Are all these clocks speaking the same language?" Timestamps are only meaningful for sequencing when they reference a common baseline. If they don't, you're comparing apples to oranges — and a three-minute offset could completely reverse your perceived order of events. This is exactly why B is correct. Before you can draw any conclusions about which event happened first, you must identify each source's time zone and any clock drift, then convert everything to a single reference frame (typically UTC). Only after normalization can you safely line up a sign-in, a connection attempt, and an administrative change and trust that the sequence reflects reality. Skipping this step risks building an entire investigation on a false timeline. A is dangerously flawed: sorting by raw timestamps when those timestamps use different zones or offsets will produce a sequence that looks ordered but is factually wrong. Matching usernames confirms identity, not timing. C incorrectly grants authority to network-device logs simply because they handle packets — there's no forensic principle that makes one log source inherently more time-accurate than another; network devices can be misconfigured or unsynchronized too. D is similarly wrong because IP address correlation tells you who is communicating, not when — it doesn't eliminate the need for timestamp comparison at all. Study tip: On questions involving multi-source log analysis, watch for answer choices that skip normalization and jump straight to correlation. That shortcut is almost always a trap. Normalize first, correlate second — this is a foundational principle in digital forensics and SIEM workflows.

Question 8

An identity provider records 900 failed sign-in attempts against many employee accounts from one IP address. Five minutes later, one of those accounts signs in successfully from the same IP address and accesses a payroll application.

Which log evidence would BEST help determine whether the successful sign-in represented an account compromise rather than an employee mistyping a password?

  1. Payroll application error logs showing whether the application generated exceptions after the sign-in
  2. Authentication logs showing failure patterns, MFA results, device identifiers, and the successful session details (correct answer)
  3. Network availability logs showing whether the identity provider remained reachable during the failed attempts
  4. Operating system startup logs showing whether the payroll server restarted near the successful sign-in
Explanation: When investigating a potential account compromise, you need to distinguish between two very different stories: an attacker who finally guessed the right password after hundreds of attempts, versus an employee who simply mistyped their own password repeatedly. The key is gathering evidence that speaks directly to who authenticated and how — not just whether a login succeeded. Authentication logs are the right tool here because they capture the complete picture of the sign-in event. They show the pattern of 900 failures (consistent with credential stuffing or password spraying), whether multi-factor authentication was challenged and passed or bypassed entirely, what device fingerprint or token was presented, and the session details of the successful login. If an attacker succeeded, you'd likely see MFA skipped or spoofed, an unrecognized device identifier, and session behavior inconsistent with the real employee. A genuine mistyping employee would typically pass MFA normally on their registered device. Choice A is a distractor that sounds technical but answers the wrong question — application exceptions tell you about software behavior after access was granted, not whether the authentication itself was legitimate. Choice C describes network availability, which is irrelevant; the identity provider was clearly reachable since logins (failed and successful) were recorded. Choice D looks at server restart logs on the payroll server, which have no bearing on whether the authentication was compromised — a server restart doesn't influence credential validity. As a study tip: on security questions involving incident investigation, always ask "which evidence speaks most directly to the authentication event itself?" Log sources closest to the authentication layer will almost always outrank application-level or infrastructure logs.

Question 9

A host sends traffic to an unfamiliar external service over TLS. The organization does not decrypt outbound traffic but retains network flow records and DNS query logs.

What security conclusion can these logs MOST reasonably support?

  1. They reveal destination addresses, timing, frequency, and volume patterns, but cannot confirm the encrypted payload content (correct answer)
  2. They reconstruct transferred files because flow byte counts preserve the application-layer payload structure
  3. They confirm the user authorized the transfer because DNS query records identify the initiating account
  4. They support only reachability conclusions because TLS conceals all metadata including connection timing and volume
Explanation: When analyzing what network visibility tools can and cannot reveal, you need to mentally separate metadata from content. Flow records and DNS logs are metadata sources — they tell you about the communication, not what was communicated. Keeping this distinction sharp is the key to this question. Network flow records capture connection-level attributes: source/destination IPs, ports, timestamps, duration, and byte counts. DNS logs reveal which domain names were queried and when. Together, these let analysts identify who talked to whom, when, how often, and how much data moved — powerful for behavioral analysis, anomaly detection, and threat hunting. This is exactly what A describes, making it the correct answer. Even without decrypting TLS, you can detect unusual data volumes, off-hours connections, or beaconing patterns purely from metadata. B is wrong because byte counts in flow records reflect packet-level volume, not application-layer payload structure. You cannot reconstruct transferred files from byte counts alone — file reconstruction requires payload inspection, which TLS prevents without decryption. C confuses DNS records with authentication logs. DNS queries show that a device resolved a domain name — they do not identify which user account initiated the transfer or whether that user authorized it. Attributing DNS queries to specific users requires integration with additional identity data. D goes too far in the other direction. TLS does encrypt the payload, but it does not conceal metadata like connection timing, duration, volume, or destination IP — all of which remain visible in flow records. The study tip here: on exam questions about encrypted traffic, always ask yourself "does encryption hide this specific attribute?" TLS hides content, not connection metadata.

Question 10

During a suspected intrusion, a central logging platform contains no authentication events from one server for a two-hour period. Events from that server appear normally before and after the gap.

Which interpretation is MOST appropriate before concluding that no sign-ins occurred?

  1. The absence proves no authentication occurred because successful and failed sign-ins are always logged centrally
  2. The absence proves an attacker deleted the records because ordinary collection failures affect all log sources
  3. The gap may reflect collection or source failure and should be checked against health and local logs (correct answer)
  4. The gap can be ignored if network flow records show the server remained reachable during that period
Explanation: When you encounter a question about missing log data, resist the urge to immediately draw conclusions. The core concept being tested here is log integrity vs. log availability — understanding that an absence of log entries can stem from collection problems, not just from the absence of events (or their deletion). Option C is correct because it reflects sound forensic discipline. A two-hour gap in a central logging platform — while events appear normally before and after — is a classic signature of a collection or forwarding failure, not necessarily a security event. Before concluding anything, you should cross-reference the server's local logs and the logging pipeline's health metrics. Only after ruling out infrastructure failure can you responsibly attribute the gap to malicious activity or actual absence of sign-ins. Option A falls into the trap of over-trusting centralized logging. No logging system is perfectly reliable — network drops, agent crashes, or configuration drift can all cause gaps. Centralization does not guarantee completeness. Option B makes the opposite mistake: it leaps to an attacker explanation without evidence. Ordinary collection failures are actually more common than deliberate log tampering, and this assumption could waste investigative resources or lead to a false incident declaration. Option D introduces a plausible-sounding but logically flawed argument. Network reachability tells you the server was online — it says nothing about whether authentication events were generated or whether they were successfully forwarded to the central platform. Study tip: On security exam questions involving log gaps, always ask: "Could the pipeline have failed, not the event?" Investigators call this distinguishing absence of evidence from evidence of absence — a principle tested frequently.