Cyber Security Quiz: Automating Security Checks
10 questions · exam conditions
0:00
Automating Security ChecksQuestion 1 of 10

A compliance check is scheduled every 15 minutes. It normally completes in 8 minutes, but an upstream service occasionally delays it for 25 minutes. Overlapping executions consume the same API quota and overwrite a shared report file.

Which control BEST addresses both concurrency and recovery from an interrupted execution?

Increase the interval to 30 minutes and assume each execution will finish before the next scheduled start.
Write each report to the same temporary filename and let the most recently completed execution replace earlier output.
Terminate every execution after 15 minutes so the scheduler can always begin the next one without overlap.
Enforce a single active execution with a renewable lease, and publish output atomically only after successful completion.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Automating Security Checks

Practice Automating Security Checks 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 Automating Security Checks, 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 compliance check is scheduled every 15 minutes. It normally completes in 8 minutes, but an upstream service occasionally delays it for 25 minutes. Overlapping executions consume the same API quota and overwrite a shared report file.

Which control BEST addresses both concurrency and recovery from an interrupted execution?

  1. Increase the interval to 30 minutes and assume each execution will finish before the next scheduled start.
  2. Write each report to the same temporary filename and let the most recently completed execution replace earlier output.
  3. Terminate every execution after 15 minutes so the scheduler can always begin the next one without overlap.
  4. Enforce a single active execution with a renewable lease, and publish output atomically only after successful completion. (correct answer)
Explanation: When designing automated jobs that share resources, you need to think about two distinct failure modes: race conditions (what happens when multiple instances run simultaneously) and atomicity (what happens when an execution is interrupted mid-write). A strong control must address both — not just one. Option D does exactly this. A renewable lease ensures only one execution is active at a time — if a job takes 25 minutes, the next scheduled trigger sees the lock, skips, and waits. "Atomic" publication means the report file is only replaced once a full, successful run completes, so readers never see a half-written or corrupted report. This is the classic mutex + atomic commit pattern used in distributed systems. Option A is wishful thinking. Extending the interval to 30 minutes doesn't prevent overlap when upstream delays push a job past 30 minutes — it just makes the problem less frequent. It also does nothing for interrupted executions. Option B makes the atomicity problem worse, not better. Letting the most recently completed run overwrite earlier output sounds reasonable, but two concurrent executions writing to the same temp file will corrupt each other's output mid-write — there's no coordination. Option C (hard kill at 15 minutes) prevents overlap by brute force but introduces a new hazard: executions that legitimately need 25 minutes are killed before finishing, guaranteeing incomplete reports and data loss. It trades one problem for another. Study tip: On concurrency questions, watch for answers that solve only half the problem. The exam often includes distractors that handle overlap or data integrity — but not both. Always ask: "Does this address both the race condition and the failure case?"

Question 2

A team automates weekly configuration checks. Some findings have approved risk exceptions. The current script suppresses every finding on an excepted server, including newly introduced misconfigurations unrelated to the approved risk.

How should the exception logic be redesigned to minimize false suppression without repeatedly reporting approved findings?

  1. Suppress all findings with the same severity as the approved finding until the server's next scheduled maintenance window.
  2. Remove excepted servers from automated checks and require asset owners to review those servers manually each quarter.
  3. Match exceptions to the asset and specific check identity, require expiration, and retain suppressed results with exception metadata. (correct answer)
  4. Suppress findings when their descriptions contain the exception title, and renew each match whenever the check runs again.
Explanation: When you see a question about automated security checks and exception handling, focus on precision and auditability — the goal is suppressing only what's approved, only for as long as it's approved, while keeping a clear record of what was hidden and why. The right approach, C, achieves exactly this. By tying each exception to a specific asset and a specific check identity (not just the server broadly), you ensure that only the approved finding is suppressed. Requiring expiration dates forces periodic review so old exceptions don't silently accumulate. Retaining suppressed results with exception metadata preserves auditability — security teams can still see what was suppressed and verify it matches the original risk acceptance. This is the core of sound exception management. A is flawed because severity is a poor proxy for identity. Two findings can share a severity level while being completely unrelated — suppressing by severity would mask new, unapproved issues just because they happen to be "High" or "Medium." This is exactly the false-suppression problem the question is trying to solve. B removes excepted servers from automated scanning entirely, which is dangerous. Quarterly manual reviews create long blind spots. Automation exists precisely to catch newly introduced misconfigurations quickly — pulling a server out of that pipeline defeats the purpose. D uses description text-matching to trigger and auto-renew suppressions, which is fragile and exploitable. Slight wording changes can cause mismatches, and automatic renewal means exceptions never actually expire — they perpetually silence findings without human review. For the exam, remember: a well-designed exception is scoped narrowly (specific asset + specific check), time-bounded, and documented — any option that broadens, removes, or auto-perpetuates suppression is a red flag.

Question 3

An automated security check queries a third-party API. The service sometimes returns rate-limit responses with a Retry-After value and sometimes returns authentication failures. The current script immediately retries every error until it succeeds.

Which retry strategy is MOST appropriate for reliable and safe automation?

  1. Retry all failures at a fixed one-second interval, treating transient and permanent errors identically, and report success once any request completes.
  2. Retry authentication failures with exponential backoff and a retry limit, but skip rate-limited requests entirely so the report always finishes on schedule.
  3. Retry each failed request indefinitely using random delays, then report the overall job as successful if at least one request eventually completes.
  4. Retry only transient failures using bounded backoff, honor Retry-After, add jitter, and report unretrieved data as incomplete. (correct answer)
Explanation: When automating API calls in security tooling, you need to distinguish between recoverable errors (transient, like rate limits) and unrecoverable ones (permanent, like authentication failures). Retrying blindly treats every failure the same way, which wastes resources, can trigger account lockouts, and produces misleading results. Option D captures every best practice in one strategy: it retries only transient failures, so you aren't hammering an endpoint with credentials that are already rejected. It uses bounded backoff — exponential delays with a maximum retry count — so the script can't loop forever. It honors the Retry-After header, which tells you exactly how long the server wants you to wait before trying again. It adds jitter (small random delay variation) to prevent synchronized retry storms when multiple clients back off simultaneously. Critically, it reports unretrieved data as incomplete rather than lying about success. Option A fails because it treats transient and permanent errors identically — retrying an authentication failure at a fixed interval will never succeed and may lock the account. Option B fails in the opposite direction: skipping rate-limited requests means you silently drop data that could have been retrieved, and you're also applying backoff to the wrong error type (authentication failures should not be retried at all). Option C is the most dangerous — indefinite retries with no stopping condition can run forever, and declaring the job "successful" when only partial data returned is a false reporting outcome that could hide a security gap. For exam questions like this, look for answers that categorize errors before deciding on retry behavior — that's the hallmark of a well-designed automation policy.

Question 4

A nightly vulnerability-checking job creates a ticket for every finding returned by a scanner. Because the scanner assigns a new result ID on each run, the ticketing system now contains many tickets for the same unresolved vulnerability.

Which redesign would BEST preserve automation while supporting accurate finding lifecycles?

  1. Create tickets only for critical findings and continue using each scanner-generated result ID as the ticket key.
  2. Derive a stable fingerprint from the asset, vulnerability, and relevant location, then upsert and reopen tickets by fingerprint. (correct answer)
  3. Delete all tickets before each scan and recreate the current findings using the scanner-generated result IDs.
  4. Group all findings from each nightly run into one ticket keyed by the scan date and scanner name.
Explanation: When designing automated vulnerability management pipelines, the core challenge is idempotency — ensuring that repeated scans of the same unresolved issue update a single record rather than spawning duplicates. The root problem here is identity: if your ticket key changes every run, your system has no way to recognize "I've seen this before." The right approach, captured in B, is to derive a stable fingerprint from attributes that don't change between scans — the asset, the vulnerability type, and its location. By upserting (update-or-insert) on that fingerprint, the system updates an existing ticket if the finding persists, reopens it if it reappears after closing, and only creates a new ticket for genuinely new findings. This preserves full automation while maintaining an accurate, deduplicated lifecycle. A is flawed in two ways: restricting tickets to critical findings means lower-severity vulnerabilities are silently ignored, and it still uses the unstable scanner-generated ID as the key — so critical findings would still duplicate across runs. C eliminates duplication only by destroying history. Deleting all tickets nightly wipes remediation context, audit trails, and SLA tracking — a serious operational and compliance problem. D aggregates findings into a single dated ticket per run, which makes it nearly impossible to track the lifecycle of any individual vulnerability. You lose granularity, can't assign ownership per finding, and can't tell when a specific issue was resolved. Study tip: On security operations questions, watch for scenarios where identity and state management are the real issue. If a system creates duplicate records, the fix almost always involves defining a stable, meaningful key — not just changing what gets created.

Question 5

An automated compliance report lists failed controls but stores only the final formatted document. An auditor disputes one result, and the team cannot determine which tool version, rule set, source response, or transformation produced it.

Which enhancement would BEST make future automated reports reproducible and defensible?

  1. Store only the final report and add the analyst's name so disputed results have an identifiable human owner.
  2. Email the report to several recipients and treat agreement among their copies as proof that each result is accurate.
  3. Retain immutable raw evidence plus timestamps, tool and rule versions, configuration, and hashes linking evidence to the report. (correct answer)
  4. Take screenshots of failed controls and replace raw machine output after an analyst confirms the formatted findings.
Explanation: When you see questions about audit trails, forensic integrity, or reproducible compliance reporting, think about what it would take to reconstruct a result from scratch and prove it hasn't changed. That's the core of defensibility. A truly reproducible and defensible report requires you to capture every input and transformation that produced the output: raw evidence, tool versions, rule sets, configurations, and cryptographic hashes that chain evidence to conclusions. Option C does exactly this. Immutable raw evidence ensures nothing can be altered after the fact, timestamps establish when events occurred, version details let you re-run the same tooling, and hashes create a verifiable link between source data and final output. If an auditor disputes a finding, you can trace it step-by-step back to its origin — that's reproducibility. Option A fails because attaching an analyst's name creates human accountability, not evidentiary accountability. A name tells you who owns the dispute, not what produced the result. Option B is particularly dangerous — distributing copies and treating consensus as proof of accuracy is not evidence-based validation. Identical copies of a flawed report are still flawed; distribution doesn't equal verification. Option D actually destroys the chain of evidence. Replacing raw machine output with analyst-confirmed screenshots removes the original, unaltered source, making future independent verification impossible. The study tip here: on cybersecurity exams, whenever a question involves disputes, audits, or forensic integrity, look for the answer that preserves the entire chain of custody — raw inputs, transformations, and verifiable links. Answers that shift responsibility to humans or consensus are almost always distractors.

Question 6

After a security tool upgrade, its JSON output omits a field that an automated policy parser previously treated as mandatory. The parser currently substitutes false for any missing Boolean field, causing affected controls to be reported as passing.

What is the MOST appropriate behavior for the automated check?

  1. Validate the expected schema and classify unparseable or missing required data as unknown, while alerting on the parser incompatibility. (correct answer)
  2. Continue substituting false because consistent Boolean output is more important than preserving the tool's schema semantics.
  3. Classify every control as failed whenever any field is missing, even if the missing field is unrelated to that control.
  4. Ignore the missing field and infer its value from the most recent successful report generated before the upgrade.
Explanation: When automated systems parse security tool output, the guiding principle is epistemic honesty — the system should never fabricate certainty where none exists. A missing required field is not evidence of a passing or failing control; it's a data gap, and treating it as anything else introduces silent errors into your security posture. Option A is correct because it handles the ambiguity responsibly on two fronts. First, classifying missing required data as unknown (rather than pass or fail) accurately reflects reality — you simply don't have enough information to make a determination. Second, actively alerting on the parser incompatibility ensures that humans are notified immediately, so the schema mismatch gets resolved rather than silently degrading your reporting. This is the behavior of a well-engineered, fail-aware system. Option B is the most dangerous trap. Substituting false for a missing Boolean doesn't preserve semantic integrity — it inverts it. In many Boolean security contexts, false means a control passed or a threat is absent, so this substitution actively masks real gaps and creates false assurance. Consistency without correctness is meaningless. Option C overcorrects in the opposite direction. Failing every control when any unrelated field is missing creates noise, alert fatigue, and unnecessary remediation work. It conflates "incomplete data" with "evidence of failure," which is equally misleading. Option D introduces stale data into a live assessment. Inferring values from pre-upgrade reports assumes the old data is still valid, which defeats the purpose of running current checks and may silently propagate outdated results. Study tip: On questions about automated security parsers, always ask: does this behavior preserve or obscure the true state of knowledge? Unknown is always more honest than a fabricated value.

Question 7

An automated cloud-security inventory calls an API that returns at most 1,000 resources and includes a continuation token when more results exist. During testing, the account contains exactly 2,000 resources, but the report contains only the first 1,000.

Which implementation would MOST reliably prevent the report from silently appearing complete?

  1. Request the largest documented page size once and label the response complete when exactly 1,000 resources are returned.
  2. Run several identical first-page requests in parallel and merge resources after removing duplicate resource identifiers.
  3. Follow each continuation token until none is returned, and mark the report incomplete if any page request fails. (correct answer)
  4. Stop requesting pages when a response contains fewer than 1,000 resources, regardless of any continuation token supplied.
Explanation: When working with paginated APIs in security tooling, the core risk isn't just missing data — it's missing data silently, making a partial result look complete. Any implementation that can finish without raising an alarm when data is absent is a liability in a security context. The right approach, captured in C, is to follow every continuation token until the API returns none, and critically, to flag the report as incomplete if any page request fails mid-chain. This means the system never assumes completion — it confirms it. With 2,000 resources and a 1,000-item page cap, you need exactly two successful requests. If the second fails, the report is marked incomplete rather than silently accepted as full coverage. A is the bug described in the scenario itself. Stopping after one request because the page happened to be "full" (exactly 1,000 items) assumes a full page means no more data, which is precisely wrong — a full page is actually a signal that more data may exist. B introduces parallelism on the first page only, which does nothing to retrieve subsequent pages. Deduplicating identical results from the same first page doesn't solve pagination at all — it just adds complexity without benefit. D is a subtler trap. Stopping when a response returns fewer than the maximum might seem logical (partial page = last page), but it ignores continuation tokens, which are the authoritative signal. A truncated page could still carry a token indicating more data exists. When you see API pagination questions, remember: the continuation token is the source of truth, not the page size. Never infer completeness from volume alone.

Question 8

A daily automation job checks cloud storage policies in several production accounts. It currently uses a permanent administrator access key embedded in the script so that the same file can run unattended on every account.

Which replacement MOST improves the security of the automation while retaining unattended operation?

  1. Store the permanent administrator key in an encrypted configuration file that the script decrypts using a local static key.
  2. Use a workload identity to obtain short-lived credentials for a read-only checking role in each authorized account. (correct answer)
  3. Place a separate permanent administrator key for each account in environment variables supplied by the scheduler.
  4. Use one permanent read-only key in all accounts and rotate it automatically after each daily execution completes.
Explanation: When a question asks how to secure automated cloud access, your mental framework should center on two principles: least privilege (grant only what's needed) and ephemeral credentials (short-lived tokens are far safer than permanent keys, because stolen credentials expire quickly on their own). The strongest solution here is B. A workload identity — such as an AWS IAM role assumed by a CI/CD runner, or a GCP service account bound to a workload — lets the automation obtain short-lived credentials automatically at runtime. Critically, it also enforces read-only access, which matches what a checking job actually needs. No long-lived secret ever sits in the code or config, and any compromised token is useless within minutes. Each of the other options preserves the fundamental problem: a permanent, long-lived secret that an attacker can steal and reuse indefinitely. A adds encryption around the key, but the decryption key is itself a static secret stored locally — you've just added a layer of false complexity without eliminating the root risk. C moves permanent keys into environment variables, which is slightly better than hardcoding, but you've now multiplied the number of permanent secrets (one per account) rather than eliminating them; more secrets means a larger attack surface. D reduces privilege correctly by switching to read-only, and rotation is a good habit, but rotating a permanent key after each run still leaves a valid key exposed for up to 24 hours — and rotation doesn't help if the key was already exfiltrated. On security exams, whenever you see "permanent key" paired with "automation," that's a red flag. The correct answer almost always involves ephemeral, role-based credentials tied to least-privilege access.

Question 9

A CI job runs security-scan | tee scan.log. The scanner returns a nonzero status when a policy violation is found, but tee completes successfully. The CI job therefore reports success even when the scanner detects violations.

Which change BEST corrects the automation without discarding the log output?

  1. Enable pipeline failure propagation or explicitly capture the scanner's status, then base the CI result on that status. (correct answer)
  2. Search scan.log for the word "critical" and fail only when that exact text appears in the output.
  3. Reverse the pipeline so that tee executes before the scanner and its successful status cannot mask the result.
  4. Treat creation of a nonempty scan.log as failure because successful security scans should produce no diagnostic output.
Explanation: When working with shell pipelines in CI/CD security contexts, the critical concept to understand is exit status propagation. In a Unix pipeline like cmd1 | cmd2, the pipeline's exit status defaults to the last command's exit code — not the first. So if tee succeeds (exit 0), the entire pipeline reports success, regardless of what the scanner returned. Answer A is correct because it attacks the root cause directly. You can fix this either by enabling pipefail in bash (set -o pipefail), which makes the pipeline fail if any command fails, or by capturing the scanner's exit code explicitly before piping — then using that captured status as the CI job's result. Both approaches preserve the log output while correctly propagating the violation signal. Answer B is tempting but brittle: it relies on parsing specific text ("critical") from the log, which breaks if the scanner's output format changes, uses different severity labels, or produces violations that don't include that exact word. You'd get false negatives for real violations with different wording. Answer C is logically impossible — tee reads from stdin, so it must come after the data source. You can't pipe output into tee and then into the scanner; reversing the pipeline doesn't make sense and wouldn't execute at all as described. Answer D misunderstands how scanners work. Security tools routinely write informational output even on clean scans — treating any nonempty log as failure would produce constant false positives. Study tip: Whenever you see CI pipeline failures tied to exit codes, immediately think about pipefail and which command's exit status the shell is actually evaluating — it's almost never the middle of the pipeline.

Question 10

A company replaces its nightly access-review inventory with webhook-triggered checks. Each identity change should generate a webhook, but maintenance outages can delay or permanently lose some events.

Which design BEST combines timely checks with confidence that no changes remain unexamined?

  1. Use only webhooks and assume that successful processing of each received event proves the inventory is complete.
  2. Process webhooks promptly and also run periodic authoritative reconciliation using a stored checkpoint or full inventory. (correct answer)
  3. Disable webhooks and perform a full inventory after every known maintenance outage reported by the provider.
  4. Count received webhooks and declare completeness whenever the count is greater than it was during the prior day.
Explanation: When you see a question about event-driven architectures in security contexts, ask yourself: what happens when events are missed? Webhooks are powerful for real-time responsiveness, but they are inherently unreliable delivery mechanisms — network failures, provider outages, and race conditions can silently drop events. A secure system must account for both speed and completeness. The strongest design, captured in B, layers two complementary mechanisms: webhooks for low-latency detection of identity changes, and periodic authoritative reconciliation (using a stored checkpoint or full inventory scan) to catch anything the webhook stream dropped. Together, they give you fast reaction time and a safety net that guarantees eventual completeness — no single point of failure. A is dangerously overconfident. Processing every received webhook only proves you handled what arrived, not that everything was delivered. Undetected dropped events leave gaps in your inventory with no signal that anything is wrong — exactly the kind of blind spot attackers exploit. C eliminates the real-time benefit entirely. Waiting for a reported outage before acting means your response is reactive and dependent on your provider's communication, which may itself be delayed or incomplete. You'd also miss events lost during unreported micro-outages. D confuses volume with validity. A higher webhook count than yesterday says nothing about whether specific, critical events (like a privileged account modification) were received. It's a meaningless completeness heuristic. Your study takeaway: in security architecture questions, any answer that relies on a single mechanism for both speed and completeness is almost always a distractor. Look for answers that combine real-time signals with authoritative ground-truth validation.