Cyber Security Quiz: Secure Configuration And Hardening
10 questions · exam conditions
0:00
Secure Configuration And HardeningQuestion 1 of 10

A company provisions laptops from a golden image. The image was hardened and approved four months ago, but it has not been updated since then. Technicians deploy the image, install current patches, and join the laptop to centralized configuration management before issuing it to a user.

Which improvement would MOST reduce exposure during provisioning while preserving baseline consistency?

Update, test, and version the golden image regularly, while still applying post-deployment patches and configuration verification.
Retain the approved image unchanged, because installing current patches after imaging fully addresses configuration and software age.
Replace the golden image with manual installation checklists, allowing technicians to select current settings for each individual laptop.
Deploy the old image only on an isolated network, then omit image maintenance once centralized management reports compliance.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Secure Configuration And Hardening

Practice Secure Configuration And Hardening 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 Secure Configuration And Hardening, 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 company provisions laptops from a golden image. The image was hardened and approved four months ago, but it has not been updated since then. Technicians deploy the image, install current patches, and join the laptop to centralized configuration management before issuing it to a user.

Which improvement would MOST reduce exposure during provisioning while preserving baseline consistency?

  1. Update, test, and version the golden image regularly, while still applying post-deployment patches and configuration verification. (correct answer)
  2. Retain the approved image unchanged, because installing current patches after imaging fully addresses configuration and software age.
  3. Replace the golden image with manual installation checklists, allowing technicians to select current settings for each individual laptop.
  4. Deploy the old image only on an isolated network, then omit image maintenance once centralized management reports compliance.
Explanation: When you see a question about secure provisioning and image management, think about two competing risks: baseline drift (an outdated image introduces old vulnerabilities) and configuration inconsistency (ad-hoc builds introduce human error). The best solution manages both simultaneously. A golden image grows stale over time. After four months without updates, the image itself carries unpatched vulnerabilities that exist on every laptop before technicians even touch it. Patching post-deployment helps, but it doesn't fix the fact that every device starts from a weakened, outdated baseline. Option A addresses this directly — by regularly updating, testing, and versioning the golden image, you shrink the vulnerability window that exists between deployment and patching, while version control preserves the auditability and consistency that make golden images valuable in the first place. Keeping post-deployment patches and configuration verification means you get defense in depth, not a single point of failure. Option B is the trap most students fall into. Patching after deployment does reduce exposure, but it doesn't eliminate the risk window during provisioning itself, and it ignores the compounding problem of a progressively more outdated baseline. Option C dismantles the entire purpose of a golden image — manual checklists introduce technician variability, which is exactly what standardized imaging prevents. Option D is essentially security theater: isolating deployment doesn't fix the underlying image, and dropping maintenance once centralized management reports compliance ignores the fact that compliance reporting reflects current state, not image currency. For exam strategy, watch for answers that solve part of a problem while ignoring a structural flaw — that's the hallmark of a distractor designed to catch students who think linearly rather than systemically.

Question 2

An administrator changes a local security setting on a group-managed workstation and confirms that the local management console displays the hardened value. A compliance scan performed after policy refresh still reports the workstation as noncompliant. Domain policy configures the same setting differently.

What should the administrator do FIRST to resolve the discrepancy?

  1. Determine the effective policy and its precedence, then correct the authoritative baseline or scope rather than the local display alone. (correct answer)
  2. Create a scheduled task that reapplies the local value after every domain policy refresh and before each compliance scan.
  3. Exclude the setting from compliance scans because the local console confirms that the intended hardened value was successfully configured.
  4. Reinstall the compliance scanner because a scanner should always accept the value shown in the local management console.
Explanation: When a compliance scan contradicts what you see in a local management console, you're being tested on Group Policy precedence — specifically, how Windows resolves conflicts between local settings and domain-level policy objects (GPOs). The key principle is LSDOU: Local, Site, Domain, Organizational Unit policies are applied in that order, with each layer overwriting the previous. Domain policy wins over local policy, meaning the local console can display a value that domain policy immediately overwrites during the next refresh cycle. This is exactly what's happening in the scenario. The administrator confirmed the local setting, but the compliance scanner — which reports the effective policy actually enforced on the system — correctly identifies that domain GPO is overriding the local configuration. Answer A is correct because it directs the administrator to first understand which policy is authoritative and where the real fix belongs: either updating the domain baseline or adjusting the GPO scope, not patching the symptom locally. Answer B is a dangerous workaround — scheduling a task to reapply local values after GPO refresh creates a perpetual conflict with domain policy and violates configuration management integrity. Answer C is a compliance evasion tactic; excluding a setting because the local console shows it "works" ignores the actual enforced state and defeats the purpose of scanning. Answer D is simply wrong — the scanner is behaving correctly by reporting the effective applied value, not the local display. For exam strategy, whenever you see a mismatch between a local setting and a domain-managed environment, immediately think policy precedence and effective configuration — the authoritative source always wins, and that's where the fix must happen.

Question 3

An organization uses a centrally managed workstation baseline that disables all removable storage. A research team has a documented business requirement to import data from encrypted USB devices on six isolated workstations. The security team wants to preserve the baseline's intent while avoiding an unmanaged configuration deviation.

Which approach BEST addresses the requirement?

  1. Modify the enterprise baseline to permit encrypted removable storage on every workstation, then monitor its use through centralized logging.
  2. Create a documented, scoped exception for the six workstations, enforce device restrictions, and review the exception periodically. (correct answer)
  3. Allow researchers to enable removable storage temporarily through local administrator accounts, then require them to disable it afterward.
  4. Remove the six workstations from configuration management, isolate them logically, and assess their settings during annual audits.
Explanation: When you encounter questions about balancing operational needs against security baselines, think in terms of risk management through formal governance — the goal is never to eliminate exceptions, but to control them through documentation, scope, and review cycles. The correct approach here is B because it preserves the baseline's intent while acknowledging a legitimate, bounded business need. A scoped exception documents exactly which workstations are affected, enforces specific device controls (like requiring encryption), and includes a periodic review so the exception doesn't quietly become permanent. This is how mature security programs handle deviation — through a formal exception management process, not ad hoc workarounds. A fails because it expands a targeted exception into a blanket policy change affecting every workstation in the enterprise. This trades a controlled deviation for an unnecessary attack surface increase — monitoring alone doesn't compensate for an overly permissive baseline. C is dangerous because it relies on end users to manually re-disable a security control after use. Human process steps like this are unreliable, unauditable, and completely antithetical to the principle of least privilege — researchers shouldn't have local admin rights just to manage their own USB access. D removes the workstations from configuration management entirely, which is arguably worse than the original problem. Isolated machines with no baseline enforcement and only annual audits become unmanaged endpoints that create significant blind spots. As a study tip: on security exam questions, watch for answers that solve the immediate problem but break the governance model. The best answer almost always maintains traceability, documentation, and scheduled review — that's the fingerprint of a proper exception process.

Question 4

A configuration-management platform enforces a hardened web-server baseline every 30 minutes. An approved application update changes one service setting that the baseline currently prohibits. The platform repeatedly restores the old setting, causing the application to fail, and administrators repeatedly reapply the new setting.

What is the MOST appropriate long-term response?

  1. Pause enforcement on the affected servers until the next annual baseline review confirms whether the application remains necessary.
  2. Keep the current baseline unchanged and schedule an automation job to restore the application's setting after each enforcement cycle.
  3. Evaluate the changed setting, approve a narrowly scoped baseline exception or revision, and test it before controlled deployment. (correct answer)
  4. Convert the setting from enforced to audit-only across all web servers so future application updates cannot be reversed.
Explanation: When you see a scenario involving configuration management conflicts with approved changes, you're being tested on change management and baseline governance — specifically, how organizations balance security enforcement with legitimate operational needs. The core principle here is that a configuration baseline is a living document. When an approved application update legitimately requires a setting that the baseline prohibits, the right response isn't to fight the baseline or abandon enforcement — it's to formally evaluate whether the baseline itself needs updating. Answer C captures this perfectly: you assess the new setting's risk, obtain proper approval for a scoped exception or revision, validate it in a test environment, and deploy it through controlled change management. This keeps enforcement intact, documents the deviation, and preserves auditability — all hallmarks of mature security operations. Answer A is a governance failure in disguise. Pausing enforcement entirely while waiting for an annual review exposes every affected server to unchecked drift for potentially a year. "Pause" becomes a synonym for "abandon." Answer B is the worst operational habit you can encode into automation: scheduling a job to undo your security tool's enforcement creates an infinite loop of conflicting automations. You've now built technical debt and a phantom configuration that exists outside your documented baseline. Answer D trades targeted enforcement for system-wide audit-only mode — far too broad a response to a single-setting conflict. Removing enforcement across all web servers because one application needs one exception violates the principle of least privilege applied to configuration scope. Your takeaway: on exam questions about configuration conflicts, the correct answer almost always involves updating the formal baseline through proper approval channels, not disabling, bypassing, or fighting your enforcement tooling.

Question 5

A Windows service that processes uploaded documents runs under a shared domain account. The account can sign in interactively, has local administrator rights on twelve servers, and uses a manually rotated password. The service requires access to one input share and one local working directory.

Which redesign BEST follows endpoint-hardening principles?

  1. Retain the shared account, deny remote desktop access to reduce exposure, and keep local administrator rights on all twelve servers so that document-processing updates and restarts cannot fail.
  2. Use a dedicated managed service identity, deny interactive sign-in, and grant access only to the required share and local working directory. (correct answer)
  3. Run the service under each server's built-in administrator account, using a distinct password per server so that one compromised credential does not immediately affect all twelve systems.
  4. Use a dedicated domain user account with interactive access enabled, then rely on frequent password rotation and centralized login auditing to detect and control any credential misuse.
Explanation: When you see a question about hardening a Windows service account, anchor your thinking to three core principles: least privilege (grant only what's needed), minimize attack surface (remove unnecessary capabilities), and reduce credential exposure (automate secrets management where possible). The scenario describes a high-risk configuration: a shared account with interactive login, local admin rights across twelve servers, and manual password rotation. Every one of those traits is a red flag. Option B directly addresses all of them. A dedicated managed service identity cannot be used for interactive login by design, which eliminates a whole class of attacks — an attacker who steals the credential still can't pivot using RDP or a console session. Scoping access to only the required share and working directory means a compromise of this service doesn't cascade into unrelated systems. This is textbook least-privilege hardening. Option A fails because retaining shared credentials and broad admin rights across twelve servers is exactly the problem to solve — blocking RDP is a cosmetic fix that leaves the core vulnerabilities intact. Option C trades one bad pattern (shared account) for another (built-in administrator accounts), which are high-value targets with known SIDs and often excluded from lockout policies; this actually widens the attack surface rather than shrinking it. Option D improves auditability but keeps interactive access enabled and relies on detecting misuse rather than preventing it — compensating controls are not substitutes for proper configuration. Your study tip: on hardening questions, always ask whether an answer removes a privilege or merely monitors it. Detection is never as strong as prevention when evaluating architectural security decisions.

Question 6

Developers run a diagnostic web service on their managed laptops. The service must be reachable from test devices on a dedicated laboratory subnet but must not be reachable from office networks or public Wi-Fi. The current host firewall rule permits the service from any source on every network profile.

Which configuration BEST hardens the laptops while retaining required functionality?

  1. Restrict the inbound rule to the laboratory subnet and appropriate network profile, and keep the service blocked on other profiles. (correct answer)
  2. Permit the inbound rule on every profile, but change the diagnostic service from its default port to an undocumented high port.
  3. Disable the host firewall on the laboratory profile, while relying on the laboratory's perimeter firewall to limit incoming connections.
  4. Block the service on all profiles and provide developers with local administrator rights to open the firewall when testing begins.
Explanation: When hardening a host firewall, your goal is least privilege: allow only the traffic that is explicitly required, from only the sources that need it, under only the conditions where it applies. Windows (and most OS-level firewalls) support network profiles — such as Domain, Private, and Public — precisely so rules can be scoped to the right context. Any time a question asks you to restrict a service to a specific group of users without breaking their workflow, think: source IP restriction + correct profile. Option A is the right answer because it does exactly this. It narrows the inbound rule to the laboratory subnet (limiting source) and ties it to the appropriate network profile (limiting context), while keeping the rule blocked on every other profile. This preserves full functionality for developers during testing and eliminates exposure everywhere else — a textbook least-privilege configuration. Option B is the trap known as security through obscurity. Moving a service to a high port does not actually block access — any attacker running a port scan will find it. It provides the illusion of security without real access control. Option C trades a granular host-based control for sole reliance on a perimeter firewall, violating defense in depth. Perimeter firewalls can be misconfigured or bypassed; the host firewall is a critical second layer. Option D removes the service entirely until someone manually re-enables it, which introduces operational friction and human error risk. Granting local admin rights as a workaround is itself a security anti-pattern that expands the attack surface. Study tip: On security exams, answers that reference both source restriction and contextual scoping (like network profiles) almost always beat partial solutions like port obfuscation or perimeter-only controls.

Question 7

A security team applies the highest-security profile from an industry benchmark to every server. The profile disables a feature required by the organization's clustered database platform, causing failover tests to fail. Management does not want to abandon use of the benchmark.

What should the security team do NEXT?

  1. Revert all benchmark settings because a baseline that disrupts one required feature is unsuitable for the server environment.
  2. Retain the profile unchanged because compliance with an external benchmark takes precedence over application availability requirements.
  3. Adopt the benchmark's least restrictive profile for all servers so required features are unlikely to be disabled in future deployments.
  4. Tailor the benchmark through risk assessment, document the required deviation, and validate compensating controls and failover behavior. (correct answer)
Explanation: When you see a question about security hardening conflicts with operational requirements, think about the core principle of risk-based security: benchmarks are starting points, not absolute mandates. The goal is never perfect compliance — it's managing risk intelligently while keeping systems functional. Tailoring the benchmark is exactly the right approach here, making D correct. A reputable benchmark like CIS or DISA STIG explicitly allows organizations to deviate from specific controls when a business justification exists. The process requires a formal risk assessment to understand what protection the disabled control provided, documentation of the deviation (so auditors understand why), and compensating controls to mitigate the residual risk — for example, additional network segmentation or enhanced monitoring around the database cluster. Validating failover behavior afterward confirms the deviation actually solved the problem without introducing new gaps. Each distractor represents a real trap. A is an overreaction — discarding an entire benchmark because one control conflicts throws away significant security value for a problem that has a targeted solution. B mistakes compliance theater for genuine security; no credible framework requires you to break your own infrastructure, and availability is itself a security property (the "A" in CIA triad). C trades one extreme for another — adopting the least restrictive profile weakens security across all servers just to avoid one edge case, which is disproportionate. Study tip: On security exams, answers that involve process — risk assessment, documentation, compensating controls — are frequently correct because they reflect how mature security programs actually operate. When you see "abandon everything" or "never deviate," treat those as red flags.

Question 8

A legacy inventory system requires an obsolete file-sharing protocol. Only three application servers must communicate with it, but the protocol is currently enabled on all employee endpoints. Replacing the inventory system will take one year.

Which hardening action BEST applies least functionality without immediately disrupting the business process?

  1. Leave the protocol enabled on all systems, but configure endpoint monitoring to alert whenever a user initiates a file-sharing session.
  2. Disable the protocol on employee endpoints and use a restricted intermediary or isolated segment for the required server communications. (correct answer)
  3. Disable the protocol enterprise-wide and permit administrators to re-enable it manually whenever the inventory system must be accessed.
  4. Keep the protocol enabled only on employee endpoints that use disk encryption and receive operating-system patches each month.
Explanation: When you see a question about hardening a system while preserving a required business function, think through the principle of least functionality — the idea that systems should be configured to support only the capabilities absolutely necessary for their role. The goal isn't to eliminate risk entirely overnight, but to minimize the attack surface without breaking what the business depends on. The best approach here is B. Since only three application servers genuinely need the legacy protocol, removing it from the remaining employee endpoints dramatically shrinks the exposure. Routing those three servers through an isolated segment or intermediary keeps the inventory system functional while ensuring the vulnerable protocol never touches general-purpose workstations. This is least functionality in action: you're granting access precisely where it's needed and nowhere else. A fails because simply monitoring for misuse doesn't reduce the attack surface at all — the protocol remains enabled everywhere, leaving every endpoint vulnerable. Alerting is a detective control, not a preventive one. C sounds appealing, but re-enabling the protocol manually whenever access is needed introduces human error, creates inconsistent configurations, and disrupts workflows unpredictably. "Disable everything and re-enable on demand" is operationally fragile and doesn't scale. D is a red herring. Disk encryption and monthly patching are good hygiene practices, but they do nothing to restrict the vulnerable protocol itself. An attacker exploiting the file-sharing protocol doesn't care whether the disk is encrypted — the protocol is still exposed. As a study tip, remember that least functionality questions test scope restriction, not just monitoring or patching. Ask yourself: "Does this action actually limit who can use the risky feature?"

Question 9

New laptops use full-disk encryption, a trusted platform module, and Secure Boot. A manager concludes that users can therefore retain local administrator rights because unauthorized changes will be prevented by these controls.

Which assessment of the manager's conclusion is MOST accurate?

  1. The conclusion is valid because Secure Boot prevents administrator-installed malware from running after an authorized operating system starts.
  2. The conclusion is valid if disk-encryption recovery keys are centrally escrowed and the trusted platform module is properly configured.
  3. The conclusion is invalid because these controls protect startup and stored data but do not prevent privileged changes during an authorized session. (correct answer)
  4. The conclusion is invalid only when laptops are off the corporate network and cannot retrieve current revocation information.
Explanation: When you see a question about security controls and access management, ask yourself: what layer of the system does each control actually protect, and when does that protection apply? This distinction separates architectural knowledge from managerial assumptions. Full-disk encryption protects data at rest — if a laptop is stolen and the drive is removed, the data is unreadable. A Trusted Platform Module (TPM) validates system integrity during boot and securely stores cryptographic keys. Secure Boot ensures only cryptographically signed bootloaders and OS components can load at startup. Notice what all three have in common: they operate at the hardware/firmware layer and during the boot process. None of them govern what a logged-in, privileged user can do after the operating system is running. A local administrator can still install malware, modify system files, disable security agents, or exfiltrate data during a fully authorized session. That's why C is correct — the manager conflates "we protected the boot process and stored data" with "we prevented all unauthorized changes," which is a fundamental category error. A is wrong because Secure Boot does not block administrator-installed software from executing post-boot; it only validates components before the OS hands off control. B is wrong because properly escrowed recovery keys and a configured TPM improve key management and boot integrity, but still do nothing to restrict what a privileged user can do in an active session. D is wrong because revocation checks relate to certificate validation, not to controlling local administrator behavior on or off the network. Your study tip: map each security control to its scope (what it protects) and timing (when it applies). Exams frequently exploit the gap between a control's actual function and what managers assume it covers.

Question 10

An organization is implementing application allowlisting on finance workstations. A proposed rule allows any executable signed by a widely used software publisher. The publisher signs dozens of utilities, including scripting and remote-administration tools that finance users do not require.

Which rule design would provide the STRONGEST hardening while remaining maintainable?

  1. Allow every executable signed by the publisher, because signature validation establishes that all of the publisher's utilities are appropriate.
  2. Allow executables by filename from any directory, while using endpoint monitoring to detect unexpected changes to the permitted files.
  3. Allow only approved products or signer attributes at constrained versions and locations, then test updates before expanding the rules. (correct answer)
  4. Allow all programs installed by local administrators, because administrative approval provides equivalent control to application allowlisting.
Explanation: When you see a question about application allowlisting, focus on the principle of least privilege combined with maintainability — the goal is to permit only what users genuinely need, defined as precisely as possible, without creating unmanageable rules. The strongest design, captured in C, restricts approvals to specific products, signer attributes, approved versions, and trusted installation paths — then requires staged testing before expanding rules. This combination closes the attack surface by blocking the publisher's unnecessary scripting and remote-administration tools while ensuring the ruleset can realistically be kept current. Version pinning and path constraints also prevent attackers from exploiting a valid signature on a tool dropped into an arbitrary directory. A fails because a valid signature only proves authenticity — it says nothing about whether a tool is appropriate for finance users. Signing dozens of attack-capable utilities under one publisher certificate means a single broad rule exposes every one of those utilities. This is the "overly permissive allowlist" trap. B swaps prevention for detection. Filename-only rules are trivially bypassed by renaming malware, and relying on monitoring rather than restriction means the damage is done before detection fires. Allowlisting is a preventive control; detection is compensating, not equivalent. D essentially dissolves the allowlist entirely. Local administrator approval is an authorization step, not a technical enforcement mechanism — it provides no cryptographic or path-based enforcement and reintroduces the same risk that allowlisting was meant to eliminate. For exam strategy, remember: whenever a question pairs a broad, easy rule against a narrow, well-scoped rule, the narrow rule almost always wins on security grounds — breadth is a vulnerability, not a feature.