Cyber Security Quiz: Core Security Principles
10 questions · exam conditions
0:00
Core Security PrinciplesQuestion 1 of 10

A database vendor must inspect query plans and restart one database service during a four-hour troubleshooting window. The vendor does not need to modify schemas, export records, or administer other database instances.

Which access design best applies the principle of least privilege without preventing the required work?

Assign a permanent database-administrator account protected by multifactor authentication, and review its activity after each support engagement.
Provide a shared operations account with full instance access, rotating its password immediately after the troubleshooting window closes.
Issue a time-limited role scoped to plan inspection and service restart on the specified instance, expiring at the end of the approved window.
Issue a time-limited read-only role covering every database instance, since read access cannot alter production systems.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Core Security Principles

Practice Core Security Principles 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 Core Security Principles, 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 database vendor must inspect query plans and restart one database service during a four-hour troubleshooting window. The vendor does not need to modify schemas, export records, or administer other database instances.

Which access design best applies the principle of least privilege without preventing the required work?

  1. Assign a permanent database-administrator account protected by multifactor authentication, and review its activity after each support engagement.
  2. Provide a shared operations account with full instance access, rotating its password immediately after the troubleshooting window closes.
  3. Issue a time-limited role scoped to plan inspection and service restart on the specified instance, expiring at the end of the approved window. (correct answer)
  4. Issue a time-limited read-only role covering every database instance, since read access cannot alter production systems.
Explanation: When a question asks about least privilege, train yourself to check three things: who gets access, how much access, and how long they keep it. The principle of least privilege means granting only the permissions necessary to complete a defined task — nothing more, nothing less, and not a moment longer than needed. The scenario is precise: the vendor needs to inspect query plans and restart one service on one instance. That narrow scope is your blueprint for the correct answer. C matches it exactly — a time-limited role scoped to plan inspection and service restart on the specified instance, expiring automatically when the window closes. It satisfies every requirement without granting anything extra, and the automatic expiration removes the risk of lingering access after the work is done. A fails because a permanent DBA account wildly exceeds what the task requires. Even with MFA and post-engagement review, you've handed over full administrative power indefinitely — reviewing logs afterward doesn't undo potential damage. B compounds two serious problems: shared accounts eliminate individual accountability (you can't attribute actions to a specific person), and "full instance access" far exceeds the narrow task at hand. Rotating the password afterward is damage control, not prevention. D sounds cautious because it's "read-only," but it covers every database instance when access to only one is justified — and critically, a read-only role can't perform the required service restart at all, making it both overly broad and functionally insufficient. As a study habit, remember: least privilege fails in two directions — too much permission or too little scope (wrong resource, wrong action). Always match access to the exact task.

Question 2

A software appliance includes an administrative web console. Small deployments manage it directly from the appliance, while enterprise deployments may need remote administration.

Which vendor configuration most closely follows secure-by-default principles?

  1. Listen on all interfaces by default, require a strong password, and recommend firewall restrictions in the deployment guide.
  2. Disable authentication on the local network by default, but require TLS when administrators enable Internet-facing access.
  3. Listen only on localhost with authentication enabled, requiring an explicit TLS-protected and access-controlled configuration for remote use. (correct answer)
  4. Select the listening interface automatically from detected network routes and notify the installer after configuration is complete.
Explanation: When evaluating vendor security configurations, you should anchor your thinking to the secure-by-default principle: a system should ship in its most restrictive safe state, requiring administrators to explicitly open access rather than explicitly close it. This "deny first, allow by choice" philosophy minimizes exposure from misconfiguration or skipped hardening steps. Option C embodies this perfectly. The console listens only on localhost, meaning it's unreachable from any network interface out of the box, and authentication is already enforced. Remote access isn't just discouraged — it requires deliberate, protected configuration (TLS plus access controls). No attacker can reach the console unless an administrator consciously enables it. That's secure-by-default working exactly as intended. Option A fails because listening on all interfaces by default immediately exposes the console to the network. Recommending firewall rules in documentation is security-by-hope — many administrators won't read or apply that guidance, leaving the console publicly reachable. Option B commits a serious mistake by disabling authentication on local networks, assuming "local" means "trusted." Internal threats, lateral movement, and misconfigured VLANs make this assumption dangerous. Authentication should never be off by default. Option D introduces unpredictability. Auto-detecting interfaces and notifying the installer after configuration means the system may already be exposed before anyone reviews its state. Secure-by-default requires safe behavior before human review, not a notification afterward. A useful mental shortcut: secure-by-default means the vendor does the hard work for you at installation time. On exam questions like this, any option that relies on documentation, manual follow-up, or assumed-trusted environments is almost certainly a distractor.

Question 3

A review shows that a service account used three of its twelve permissions during the last 30 days. One additional permission is required only for a documented quarter-end reconciliation that did not occur during the review period.

Which remediation best applies least privilege while accounting for the incomplete observation window?

  1. Retain all twelve permissions, because usage logs alone cannot prove that any granted permission will never be needed again.
  2. Retain the three observed permissions and provide the quarter-end permission through a tested, time-limited elevation workflow activated only at reconciliation. (correct answer)
  3. Remove every permission not observed during the review period and restore permissions informally if quarter-end processing fails at runtime.
  4. Create a second permanent account holding all nine unused permissions and store its credentials with the operations team for convenience.
Explanation: When you see a question pairing least privilege with an incomplete observation window, your job is to find the option that strips unnecessary access without creating operational risk from gaps in the data. Least privilege means granting only what is needed — but "needed" must account for legitimate, predictable future use, not just what happened to occur during one review period. B is correct because it does both things simultaneously. It reduces the account's standing permissions to only the three actively used, and it handles the documented quarter-end requirement through a time-limited elevation workflow — meaning that permission exists only when genuinely needed and is removed automatically afterward. This is least privilege plus operational rigor, not a compromise of either. A fails because it treats the observation gap as a reason to do nothing. That logic would make least privilege impossible to enforce: there will always be some theoretical future scenario. Unexercised permissions are a standing attack surface, and inaction is not a valid remediation strategy. C sounds aggressive but is actually reckless. Removing all unobserved permissions and then "restoring informally at runtime" means you've documented a known exception, ignored it during remediation, and created a break-glass situation with no tested process. Failing at reconciliation during quarter-end is a serious business risk. D compounds the problem. Creating a second permanent account holding all the unused permissions defeats least privilege entirely — and storing credentials with operations "for convenience" introduces credential-sharing and accountability gaps that violate basic access-control hygiene. Study tip: On least-privilege questions, watch for options that use incomplete data as an excuse for inaction (A) or that solve an access problem by creating a second access problem (D). The right answer almost always combines restriction with a controlled, documented exception path.

Question 4

A financial analyst has a direct read-only assignment to a reporting share. Effective-access review reveals that the analyst can also modify production files because the analyst's department group is nested inside a legacy operations group.

Which response best restores least privilege and reduces the chance of recurrence?

  1. Remove the analyst's direct read assignment, because direct permissions take precedence over permissions inherited through nested groups.
  2. Keep the inherited modification access but increase file auditing so unauthorized changes can be identified after they occur.
  3. Add an explicit deny for every production folder while leaving the legacy group nesting and broad operations membership unchanged.
  4. Remove the inappropriate group nesting, assign a task-scoped reporting role, and verify the analyst's resulting effective permissions. (correct answer)
Explanation: When you see access control questions involving nested groups and excessive permissions, your focus should be on the root cause. Least privilege isn't just about patching symptoms — it means eliminating the structural reason the over-permission exists in the first place. The right move here is D. The analyst's excessive modify access flows from a group nesting problem: the department group is buried inside a legacy operations group that carries production file permissions. Removing that inappropriate nesting eliminates the inherited access at its source. Pairing that with a task-scoped reporting role ensures the analyst gets exactly what the job requires — read access to reports — nothing more. Verifying the resulting effective permissions closes the loop, confirming the fix actually worked and no other nesting paths remain. A misunderstands how permissions compound. Removing the direct read assignment doesn't touch the modify access coming through the nested group — the analyst would lose their legitimate access but keep the dangerous one. That's backwards. B is a detective control, not a preventive one. Increasing auditing helps you notice damage after it happens, but it does nothing to stop the analyst from modifying production files. Relying on detection instead of prevention is never a least-privilege solution. C introduces explicit denies without fixing the underlying mess — the legacy group nesting and bloated operations membership stay intact. This creates a fragile, hard-to-maintain permission structure, and a single misconfiguration or new folder could expose production files again. Your study tip: when a question involves nested groups, always trace the permission to its origin — the fix must target the structural source, not layer on compensating controls.

Question 5

A hospital application normally depends on a central identity service. During an identity-service outage, unrestricted access could expose patient records, but completely blocking clinicians could delay emergency treatment.

Which outage behavior best reconciles secure-by-default operation with the safety requirement?

  1. Allow all users full access during the outage and reconstruct individual accountability later from workstation and network logs.
  2. Continue every cached session indefinitely with its previous privileges until the central identity service becomes available.
  3. Deny normal access but permit a locally protected, time-limited break-glass role with narrow functions and immutable auditing. (correct answer)
  4. Disable all application access during the outage, including emergency workflows, because fail-closed behavior permits no exceptions.
Explanation: When you see a question pairing security with safety-critical environments like healthcare, think about the fail-safe vs. fail-secure tension. Pure fail-closed (deny everything) protects data but can harm patients; pure fail-open (allow everything) protects patients but abandons security entirely. The right answer almost always lives in a carefully controlled middle path. Option C threads this needle precisely. A break-glass role is a well-established pattern that grants emergency access under strict constraints: the role is locally authenticated (no dependency on the outage-affected service), time-limited so privileges expire automatically, scoped narrowly to essential functions, and backed by immutable audit logs so every action is permanently recorded. This preserves both patient safety and accountability — the two core requirements in the scenario. Option A is dangerously wrong because granting full unrestricted access to all users abandons the principle of least privilege entirely. Promising to reconstruct accountability afterward is optimistic at best; logs can be incomplete, tampered with, or simply overwhelming to reconstruct. Option B fails because indefinitely extending cached sessions removes any time boundary or control mechanism. Privileges persist with no re-validation, and a compromised or terminated user's session would remain active indefinitely. Option D sounds principled but is actually dangerous in a clinical setting. Rigid fail-closed behavior that blocks emergency workflows violates the safety requirement explicitly stated in the scenario. Security controls must account for life-safety contexts. Study tip: On security exam questions involving critical infrastructure or healthcare, watch for answers that claim either absolute denial or absolute permissiveness — the correct answer almost always introduces a controlled exception mechanism with auditing and scope limits.

Question 6

An organization uses endpoint detection, network filtering, and centralized security logging. All three controls are administered through one cloud tenant using the same privileged identity provider. An attacker who compromised a tenant administrator disabled every control.

Which change would most improve defense in depth against this common-mode failure?

  1. Store protected log copies under a separately administered identity boundary and maintain isolated emergency credentials for control recovery. (correct answer)
  2. Require longer and more complex tenant-administrator passwords while retaining the same identities and recovery paths for all controls.
  3. Add more endpoint detection rules while keeping their management, alerting, and recovery entirely within the existing cloud tenant.
  4. Send additional control-status alerts to a monitoring dashboard hosted and authenticated inside the same cloud tenant.
Explanation: When you see a scenario where a single compromised identity dismantles multiple security controls simultaneously, you're looking at a common-mode failure — a single point of compromise that cascades across an entire system. Defense in depth only works when controls are truly independent, meaning an attacker who defeats one cannot automatically defeat the others. The core problem here is that endpoint detection, network filtering, and logging all share the same administrative identity boundary. One compromised tenant admin nukes everything. The fix must introduce genuine independence — a separate identity plane that the attacker's existing access cannot reach. Answer A accomplishes exactly this: immutable log copies under a distinct identity boundary preserve forensic evidence even after the tenant is compromised, and isolated emergency credentials allow recovery without relying on the compromised identity provider. This creates real separation, not cosmetic separation. Answer B fails because it only hardens the existing credentials — longer passwords don't help when those credentials are the attack surface. Once the single admin identity is compromised, complexity is irrelevant. Answer C is a trap: adding more detection rules sounds proactive, but if management and recovery remain inside the same tenant, the attacker still disables everything with one move. More rules don't fix architectural dependency. Answer D makes the same mistake — a monitoring dashboard authenticated through the same tenant is invisible or controllable by the attacker who already owns that tenant. An alert that the attacker can silence is no alert at all. The study tip here: whenever a question involves a single point of control failure, look for the answer that introduces a separate trust boundary — not just more complexity within the existing one.

Question 7

A cloud platform is revising how newly created object-storage containers are configured. Some customers legitimately publish static website content, but most containers hold internal data.

Which creation policy best implements secure-by-default behavior while preserving the public-hosting use case?

  1. Create containers as public and display a warning until an owner confirms that public access is still required.
  2. Create containers as private with encryption and logging enabled, requiring an explicit scoped action to permit public access. (correct answer)
  3. Create containers as public only for users in the web-development group, because their job function implies publication intent.
  4. Create containers without an access policy and allow the first uploaded object's permissions to determine container exposure.
Explanation: When you see a question about cloud storage configuration policy, focus on the secure-by-default principle: systems should launch in their most restrictive state, with privilege granted only through deliberate, auditable action — not assumed based on role, inheritance, or user confirmation. This principle makes B the strongest policy. Creating containers as private with encryption and logging enabled means that even if an administrator makes a mistake or forgets to configure a container, no data is accidentally exposed. The "explicit scoped action" requirement ensures that public access is a conscious, traceable decision — not a default someone forgot to change. Critically, this still supports the public-hosting use case; it just requires intentional opt-in, which is exactly what secure-by-default demands. A fails because it starts in an insecure state and relies on human follow-through to correct it. Warning prompts are routinely ignored or dismissed, meaning sensitive containers could remain public indefinitely. "Confirmation required" is not the same as "private by default." C introduces role-based assumptions that don't map cleanly to security boundaries. A web developer creating a container for internal build artifacts doesn't intend public exposure — job function is not a reliable proxy for data sensitivity. D is the most dangerous option. Deriving container permissions from the first uploaded object's settings is unpredictable and creates an implicit, non-auditable policy. This is a recipe for accidental exposure and violates both the principle of least privilege and secure-by-default. Study tip: On security exams, whenever a question asks about defaults, always favor the option that restricts access first and requires explicit elevation — that pattern almost always points to the correct answer.

Question 8

An attacker exploits a web application despite the web application firewall. The compromised process cannot read payroll tables because its database service account is restricted to the application's tables. A separate egress gateway also blocks the process from connecting to an unapproved external host.

Which assessment of the controls is most accurate?

  1. The database restriction applies least privilege, while the independently enforced egress restriction contributes defense in depth after compromise. (correct answer)
  2. The firewall bypass means defense in depth failed completely, because every preventive layer must stop the initial exploit.
  3. Encryption at rest should have replaced the database restriction, because encrypted tables remain unreadable to an exploited application.
  4. The egress gateway applies least privilege only, while the broad web-service account provides the necessary second defensive layer.
Explanation: When you see a question mixing multiple security controls, ask yourself two things: what security principle does each control embody, and do they operate independently of one another? That distinction unlocks this question. The scenario gives you three controls: a WAF (bypassed), a database service account restriction, and an egress gateway. The database restriction limits what data the compromised process can access — that's least privilege in action, granting only the permissions needed for the application's tables. The egress gateway prevents the attacker from exfiltrating data to an external host — and critically, it activates after the WAF already failed. Two separate controls, each limiting damage at a different layer after initial compromise. That's the textbook definition of defense in depth: independent, overlapping controls so that no single failure causes total loss. Answer A captures both principles correctly and is the right choice. Answer B is a common trap. Defense in depth does not require every layer to stop the initial exploit — it explicitly assumes layers will fail. The whole point is that surviving controls limit damage after a breach. Saying it "failed completely" because the WAF was bypassed misunderstands the concept entirely. Answer C confuses encryption at rest with access control. Encryption at rest protects data from someone accessing the raw storage files, not from an authenticated database session. An exploited application process using a valid service account would still be able to decrypt and read the data. Answer D reverses the principles. The egress gateway isn't least privilege — it's a containment/depth-of-defense control. The account restriction, not the gateway, is the least-privilege mechanism. Remember: least privilege = limiting permissions; defense in depth = independent layers that assume prior layers fail. Keeping these definitions clean will protect you from several common distractors on security exams.

Question 9

An installer deploys a network service that local applications can use immediately. Administrators may later permit remote clients to connect.

Which initial setup best reflects secure-by-default design?

  1. Use a documented factory password, accept local and remote connections, and require a password change at first login.
  2. Generate a unique secret, email it to all administrators, and enable remote access for the entire internal address range.
  3. Leave the secret blank, reject local connections, and let the first remote client claim administrative ownership.
  4. Generate a unique secret, restrict its storage to the service identity, and bind locally until remote access is explicitly configured. (correct answer)
Explanation: When evaluating security configurations, always ask: what is the safest possible state at installation, before any administrator has had a chance to customize anything? This is the core idea behind secure-by-default design — a system should expose the minimum necessary attack surface from the moment it is deployed, with expanded access requiring deliberate, explicit action. Option D captures this perfectly. Generating a unique secret per installation means no two deployments share credentials, eliminating the risk of credential-stuffing across instances. Restricting that secret to the service identity enforces least privilege — only the process that needs it can read it. Binding to localhost until remote access is explicitly configured means the network attack surface is zero until an administrator consciously opens it. Every expansion of access is an intentional decision, not a default. Option A fails immediately because a documented factory password is, by definition, publicly known — anyone who reads the manual can authenticate. Requiring a change at first login sounds responsible, but that window of exposure is a real vulnerability, especially in automated deployments where no human may ever "log in" interactively. Option B distributes the secret via email, which is an insecure channel subject to interception, forwarding, and archiving. It also pre-enables remote access for an entire address range — broadcasting opportunity to any attacker on the internal network. Option C is the most dangerous: a blank secret and unauthenticated remote ownership-claiming is essentially an open invitation for the first malicious actor to reach the service to take full control. Your study tip: on secure-by-default questions, the right answer almost always restricts first and requires explicit action to expand — treat any option that enables broad access or shares secrets through untrusted channels as an automatic disqualifier.

Question 10

An Internet-facing application uses a reverse proxy to block malicious requests. A recent parser flaw allowed specially encoded traffic to bypass the proxy and reach the application.

Which redesign most effectively adds defense in depth against similar attacks?

  1. Deploy a second reverse proxy with the same parsing engine and copy the first proxy's filtering rules to it.
  2. Add application-level input validation, restrict the service identity's database rights, and limit outbound traffic at a separate enforcement point. (correct answer)
  3. Increase the reverse proxy's logging level, retain logs longer, and alert whenever its blocked-request count rises.
  4. Move the existing reverse proxy behind a larger load balancer while continuing to rely on its current filtering policy.
Explanation: When you see a question about bypassing a security control, your instinct should be to think about defense in depth — the principle that no single layer should be a single point of failure. If one control fails, independent layers beneath it should still protect the system. The scenario describes a parser flaw that let malicious traffic slip past the reverse proxy entirely. The lesson here is that relying on one enforcement mechanism, no matter how well-configured, creates exactly this vulnerability. Answer B is correct because it adds independent, heterogeneous layers: application-level validation catches malicious input even after the proxy fails, restricted database permissions limit damage if the application is still exploited, and a separate outbound traffic enforcement point can detect or block exfiltration. Each layer operates independently and addresses a different attack surface — this is textbook defense in depth. Answer A is a trap. Adding a second proxy with the same parsing engine and the same rules means the same flaw will bypass both proxies identically. Redundancy is not the same as diversity; you need different mechanisms, not duplicates. Answer C improves detection and forensics — useful, but logging never stops an attack in progress. Knowing you were breached faster doesn't prevent the breach. Answer D is similarly cosmetic: placing the flawed proxy behind a load balancer doesn't change its filtering logic. The vulnerability travels with it. A useful study rule: whenever a question asks about improving security posture after a control fails, look for the answer that introduces diverse, independent layers rather than scaling or duplicating the broken control.