General Security Concepts practice questions

Procedure, because it always defines the highest-level mandatory rules.

Why wrong: A procedure is a defined sequence of actions or tasks used to complete a specific process, such as a step-by-step incident response checklist. It is not a high-level rule set; it derives its authority from policies and describes 'how' rather than 'what' employees must always do. Procedures are also rarely company-wide in scope and are typically tailored to a workflow or system, so they cannot be the single document that defines mandatory rules for everyone.

Guideline, because it provides optional suggestions for best behavior.

Why wrong: Although guidelines do provide recommended best practices, they are by definition discretionary and use language like 'should' or 'may,' leaving room for employee judgment. The company's stated need is for a single document that tells employees what they are required to do; an optional framework would not establish enforceable expectations or support compliance audits. Thus a guideline fails because it cannot convey binding, organization-wide mandates.

Standard, because it contains only optional advice about security.

Why wrong: Standards are actually mandatory, not optional advice; they define specific implementation details such as encryption requirements, password complexity rules, or platform baseline settings. However, a standard is usually subordinate to a policy and applies to particular technologies or processes rather than serving as the overarching, company-wide rule document. The option's claim that a standard contains 'only optional advice' is factually incorrect, which makes it a poor justification even if the conclusion might seem plausible.

Put keys in an unencrypted text file on a server

Why wrong: Storing keys in an unencrypted text file, such as a plain .key file on a web server, is insecure because any application or user with filesystem access can read the key material directly. If an attacker exploits a vulnerability to gain shell access, they can simply cat the file and own the entire encryption infrastructure. Keys should be protected with encryption at rest and stored in a secure keystore, not lying on disk in a readable format.

Reuse the same key across many systems forever

Why wrong: Reusing the same key across many systems indefinitely creates a single point of failure for the entire enterprise. If one system is breached and the key is extracted, all the other systems that share the key can be decrypted instantly, breaking down security boundaries between environments. Continuous reuse also increases the volume of ciphertext available for cryptanalysis, making it easier for an attacker to recover the key using statistical techniques.

Send keys through a public chat room

Why wrong: Transmitting keys through a public chat room is completely unsafe because the channel is neither encrypted nor authenticated — the key can be sniffed in transit or captured by anyone with access to the chat server logs. Even short-lived message endpoints expose the key to third parties and create a permanent record of the secret. Secure key distribution should be done in-band using asymmetric encryption or via a dedicated key management service.

Encrypt the build server disks with full-disk encryption so the private key stays protected.

Why wrong: Full-disk encryption protects data at rest, but it does not stop an attacker who has already compromised the running server. Once the system is booted and unlocked, the key can still be accessed by malware or an interactive intruder. It reduces theft risk, not signing-key exposure during operation.

Store the private key in a read-only artifact repository so all build agents can access it.

Why wrong: Storing the private key in a read-only artifact repository fails to reduce the cryptographic risk because it does not eliminate the duplication of the signing key across multiple build servers; an attacker compromising either server could still extract the key from the repository’s storage layer. This option is tempting because artifact repositories are designed to centralise and version binary assets, and in a scenario where the key must be distributed to many build agents without hardware security modules, a read-only repository would prevent accidental overwrites while providing access control.

Replace the signing process with file hashes and checksums to verify release integrity.

Why wrong: Hashes and checksums can show that a file changed, but they do not prove authenticity or source. An attacker who can replace the firmware can also replace the hash value. Digital signatures are needed when the goal is trusted origin and tamper evidence.

Message sent from a trusted internal help desk portal

Why wrong: A message genuinely sent from a trusted internal help desk portal is not a warning sign; rather, it indicates a likely legitimate origin because the portal is an authoritative communication channel. While attackers can spoof display names or create lookalike portals, this option describes a trusted source, so it does not align with typical phishing red flags. The presence of such a known, internal sender reduces rather than increases suspicion.

Correct spelling and matching domain name

Why wrong: Correct spelling and a domain name that matches the legitimate organization actually lower the likelihood of phishing because many phishing attempts are identified by typos, grammatical errors, or lookalike domains. A well-formed message with an exact domain match lacks the common linguistic and structural anomalies that often indicate fraud. Therefore, this option is not a warning sign; it is a trait of a more sophisticated or legitimate message.

Email signed with a known employee's regular signature block

Why wrong: An email signed with a known employee's regular signature block is not a reliable warning sign, but it also does not indicate a problem because signatures are easily harvested from public sources or previous emails and can be copied verbatim. Attackers frequently include forged signature blocks to lend false credibility, yet the mere presence of a familiar signature does not authenticate the sender. Thus, it is neither a clear warning sign nor a definitive sign of legitimacy.

Locked server rack

Why wrong: A locked server rack is a preventive physical control that deters and delays unauthorized access by requiring an authorized key or combination. It does not detect, log, or sound an alarm if someone defeats the lock, so it cannot provide evidence or notification after a breach. If an attacker bypasses the lock, the rack gives no mechanism to observe or record the intrusion, making it fundamentally preventive rather than detective.

Employee security awareness training

Why wrong: Employee security awareness training is an administrative preventive control that reduces the likelihood of social engineering or human error by educating staff before they encounter a threat, such as phishing or vishing. Training does not generate logs, monitor user activity, or analyze system events, and it has no post-incident detection capability. Its purpose is to stop mistakes during an attack attempt, not to identify breaches after they have occurred, so it cannot be classified as detective.

Disk encryption on a laptop

Why wrong: Disk encryption on a laptop is a technical preventive control that ensures confidentiality by requiring an authentication key to decrypt data, so an unauthorized person can't read files if the device is stolen. It does not detect unauthorized access attempts, record a device's location, or create an alert; if the device is lost, encryption only limits data exposure, not notify anyone. Because it acts before data compromise by denying access, it is preventive, not detective.

Badge reader at the server room door

Why wrong: A badge reader at the server room door is a physical control because it is a tangible access-restriction mechanism installed at a specific entry point. It authenticates an individual's physical presence through a credential, limiting who can enter a facility or sensitive area, but it does not govern user conduct or set procedural rules across the organization.

Host-based firewall on laptops

Why wrong: A host-based firewall on laptops is a technical control because it is software that actively inspects network traffic and applies filtering rules on the device itself. It automates security enforcement by allowing or blocking connections based on preconfigured rules, reducing reliance on user decisions, and it is designed to protect each laptop from unauthorized network access.

Encryption of data on the hard drive

Why wrong: Encryption of data on the hard drive is a technical control because it applies cryptographic algorithms to render stored information unreadable to unauthorized parties. The confidentiality safeguard is executed by software or hardware elements, and its functionality is independent of user behavior or documented policies, relying instead on key management and mathematical protection.

Storing a password as a hash

Why wrong: Hashing is a one-way cryptographic function used to store password verification tokens (e.g., bcrypt, PBKDF2) persistently, but it never creates a reversible cipher or a secure channel for data traversing a network. A hash digest represents the original password only through a non-invertible transformation, so it cannot provide the confidentiality that encryption in transit requires. Even if a hash value were transmitted, it is not encrypted traffic—an eavesdropper who does not need the plaintext can still capture and replay the digest.

Comparing file integrity with a checksum

Why wrong: A checksum (such as CRC32 or SHA-256) produces a fixed-size digest designed to detect accidental or malicious changes to data, but it is a deterministic, unkeyed function that does not conceal the payload's content. Computing and attaching a checksum to a message does nothing to scramble the data while it moves; an interceptor can read the plaintext exactly as sent. Thus, a checksum supports integrity verification only, and it fails entirely to satisfy the confidentiality requirement of encryption in transit.

Sharing a symmetric key by email

Why wrong: Emailing a symmetric key is fundamentally insecure because conventional email protocols (SMTP, IMAP, POP3) rarely provide end-to-end encryption; even with opportunistic TLS between hops, the key is exposed at intermediate mail relays and can be read by anyone who intercepts the message. Email is not a designed key-distribution channel—it lacks out-of-band verification and leaves the key open to unauthorized access and silent replacement. Secure key transport must rely on mechanisms like asymmetric key wrapping, ephemeral Diffie-Hellman, or a physically separate out-of-band channel, never plaintext email.

Detective control, because a rule set later identifies malicious traffic.

Why wrong: A detective control operates after an event to identify attack indicators, such as an intrusion detection rule that flags malicious traffic destined for the payroll server. However, the scenario's controls are proactive: the temporary network restriction limits access before exploitation, and the approval requirement governs change before it occurs. A rule set that later identifies malicious traffic would be a detective control, but that is not the function described, and the scenario prioritizes preventing exposure, not detecting an already-occurred intrusion.

Corrective control, because the control repairs the vulnerable software itself.

Why wrong: A corrective control restores system integrity after an incident, such as applying the patch to repair the vulnerable software, reverting to a known-good image, or rebuilding the server from scratch. In this scenario, the patch is explicitly delayed, so the underlying software weakness remains; the temporary network restriction and approval workflow do not fix or remediate the vulnerable payroll application. Since no step repairs the software itself, calling the control corrective is inaccurate—it compensates for the unpatched flaw rather than correcting it.

Deterrent control, because a warning banner discourages misuse of the server.

Why wrong: A deterrent control discourages misuse by making a potential attacker believe that action is risky, often through warning banners that state activity is monitored and unauthorized access will be prosecuted. While such a banner might reduce casual attacks, the scenario's primary mechanisms are the temporary network restriction, which physically blocks access, and the written approval requirement, which administratively governs changes. Neither depends on fear or intimidation to influence behavior, so classifying the control as deterrent ignores the actual technical and procedural safeguards in use.

Least privilege, because users are being limited to only the finance application they need.

Why wrong: Least privilege is part of the proposal, but it does not fully capture the repeated trust checks and dynamic access decisions. The exhibit emphasizes that device posture, session risk, and authentication state are continuously reconsidered. That behavior goes beyond simple permission reduction and reflects an architecture that assumes no implicit trust from network location or initial login.

Defense in depth, because the company is adding multiple security layers around the finance app.

Why wrong: Defense in depth does involve multiple layers, and this design certainly uses them. However, the central idea in the exhibit is not just layering controls; it is refusing to trust the session simply because it started on a managed network. The repeated validation and per-request access decisions are what make zero trust the better fit.

Need-to-know, because users should only see the finance data required for their jobs.

Why wrong: Need-to-know limits information exposure, but the proposal is focused on when and how access is granted, especially after device risk changes. The issue is not just data visibility; it is the assumption of trust after VPN login. Continuous revalidation of identity and device state is a zero trust concept, not merely a need-to-know rule.

Decrypt and re-encrypt every backup object immediately with a new data key.

Why wrong: Decrypting and re-encrypting every backup object with a new data-encryption key would mean reading and rewriting all backup ciphertext, which is enormously expensive, time-consuming, and risks exposure of plaintext data on disk or in transit. Envelope encryption exists precisely to avoid this: data is encrypted under unique DEKs, and only the DEKs are protected by the KEK, so rotating the KEK should never require touching the underlying objects. This approach defeats the purpose of the key hierarchy and would be a massive operational burden for no security benefit.

Destroy the old key before the rewrapping process finishes.

Why wrong: Destroying the old KEK before all DEKs have been successfully rewrapped is a critical operational error: any DEK still wrapped under the old KEK becomes permanently irrecoverable, which means all backup objects encrypted with that DEK are lost. Rewrapping is not instantaneous—it must be done atomically for each DEK, and the old key must remain available until every dependent key has been migrated. This is wrong because it trades a security convenience for data availability, violating the fundamental rule that key destruction is the final step after ensuring no ciphertext remains bound to the key.

Replace the hashing algorithm used for file integrity checks.

Why wrong: Replacing the hashing algorithm used for file-integrity checks is a configuration change that is completely orthogonal to key rotation: hashes verify data integrity, while encryption keys protect confidentiality. Rotating keys—whether the KEK or DEK—has no effect on hash values, and changing the hash algorithm would not address any scenario in which a key is suspected of compromise. This is incorrect because it conflates two distinct cryptographic primitives and would leave the actual key-management problem unresolved.

Separation of duties, because one person cannot both request and approve the access.

Why wrong: Separation of duties is a fraud-prevention control that requires multiple individuals to complete critical transactions, such as the same user cannot both request and approve a change. The scenario describes restricting a contractor's access scope—not splitting the authorization workflow into multiple roles. There is no mention of a two-person rule or conflicting duties needing segregation, so this principle does not apply to the described situation.

Defense in depth, because multiple layers of security tools are deployed around the server.

Why wrong: Defense in depth is a security architecture strategy that layers independent controls—firewalls, IDS, antivirus, etc.—so that a failure in one layer is compensated by another. While a jump host may be one such layer, the question's focus is on the granularity of the contractor's access rights, not the number of security mechanisms surrounding the server. The wrongness lies in that the scenario emphasizes authorization scope rather than a multi-layered defense posture.

Zero trust, because every request is automatically denied until proven safe.

Why wrong: Zero trust is a security model that assumes no implicit trust and continuously verifies every access request based on context, device health, and user identity. In the scenario, the contractor's access is pre-provisioned with a fixed set of permissions and does not involve continuous risk-based evaluation or dynamic policy decisions. The limitation of access is a static access control measure, not the real-time verification that defines zero trust.

Encrypt each password with a single symmetric key and store the key in the database.

Why wrong: Symmetric encryption is a reversible process: any algorithm that can encrypt a password with a key can also decrypt it with that same key. If the single key is stored alongside the ciphertext in the database, an attacker who steals the database gains both the locked password and the key to unlock it, rendering the protection meaningless. Even if the key is stored separately, a single compromise of that key exposes every password in the organization, whereas password hashing is specifically designed to be irreversible and cannot be undone by a key.

Add a digital signature to each stored password so users can verify it.

Why wrong: A digital signature is a mechanism for proving the origin and integrity of a message, not for keeping it secret or resisting offline guessing. Signing a stored password does not alter its recoverability or prevent an attacker from taking the stored value and checking password guesses against it; signatures do not change the one-way nature of the hash. Furthermore, users have no way to 'verify' a stored password signature in practice, and the signature itself adds no computational cost to an attacker's brute-force attempts, leaving the same vulnerability as an unsalted hash.

Hash all passwords with the same unsalted SHA-256 value.

Why wrong: Hashing every password with the same unsalted SHA-256 produces identical hashes for identical passwords, allowing an attacker to instantly see which passwords are reused across accounts. SHA-256 is an extremely fast algorithm with no salt, so an attacker with a GPU cluster can compute roughly 10–20 billion guesses per second and use precomputed rainbow tables to reverse the hashes in minutes. Any password that appears in a common wordlist becomes trivially recoverable, and even complex passwords are vulnerable because the lack of salt enables parallel cracking across the entire database.

Decrypt the package with the vendor's private key before installation.

Why wrong: The vendor's private key is never distributed because it is the sole secret used to generate digital signatures that establish the vendor's identity. Decrypting a package with the vendor's private key would only make sense if the vendor had encrypted it for a recipient's public key, but that is not how software distribution works—packages are typically signed, not encrypted, and encryption would use the recipient's public key. Attempting to use the private key for decryption is both conceptually incorrect and a catastrophic security failure if the key were ever disclosed.

Rotate the organization's internal encryption key before downloading.

Why wrong: Rotating the organization's internal encryption key is a routine operational task that changes the key used to protect its own data, having no relation to the vendor's patch package. It cannot authenticate the package source, detect tampering, or validate the package's cryptographic signature, so it offers no defense against a forged or malicious update. Moreover, such a rotation could interrupt legitimate encrypted systems and give a false sense of security if done immediately before a mass deployment.

Check only the file timestamp and size on disk.

Why wrong: File timestamp and size are metadata that an attacker can easily set or preserve while replacing the file with malware, and even legitimate downloads can change these attributes due to time zone or filesystem differences. They provide no proof of who created the package or whether its content is byte-for-byte identical to the vendor's original release. Without cryptographic validation like a signature or hash, an attacker can mimic the expected values, so these checks are insufficient for trustworthy patch deployment.

Requiring multi-factor authentication for system administration: Accountability

Why wrong: Incorrect — MFA enforces least privilege by requiring specific authentication, not accountability.

Enabling comprehensive logging and monitoring: Least privilege

Why wrong: Incorrect — logging and monitoring ensure accountability, not least privilege.

Disabling unnecessary services and ports: Least privilege

Why wrong: Incorrect — disabling unnecessary services reduces the attack surface, not least privilege.

Need-to-know

Why wrong: Need-to-know is an access control principle that restricts access to information based on the user's specific job requirements. For the contractor, this means seeing only the merger project's data, not unrelated company records, even if the contractor has clearance or credentials. It directly matches the scenario: access is scoped to the data essential for the assigned project.

Integrity

Why wrong: Integrity is a security property ensuring data has not been altered or corrupted by unauthorized actions. Nothing in the scenario involves modification, version control, or data trustworthiness. The concern is purely about which information the contractor may access, making integrity the wrong principle to apply.

Zero trust

Why wrong: Zero trust is an architectural model that requires continuous verification of every user and device request, regardless of whether they are inside or outside the network. The scenario describes a one-time access decision based on project assignment, not ongoing authentication or session validation. Need-to-know is the specific principle, while zero trust would be a broader framework that could implement it.

Allow employees to add any root CA as long as the certificate is password-protected.

Why wrong: Password-protecting a root CA certificate only guards the private key; the certificate itself is a public trust anchor that, once placed in the Trusted Root Store, authorizes the CA to issue certificates for any domain. An attacker with access to the password-protected store (or the CA itself) can still forge certificates for legitimate sites, because the browser will treat any certificate chained to that root as valid. PINning and managed trust stores are needed to reduce the blast radius of an untrusted root.

Rely on HTTPS alone because any certificate over TLS is safe.

Why wrong: HTTPS provides encryption and server authentication only when the client correctly validates the certificate chain against a set of trusted roots. If a malicious root CA is trusted, the browser accepts the attacker's certificate for any domain, so HTTPS offers no extra protection and the attacker can relay traffic through the connection. Thus, relying solely on HTTPS without verifying the trust store is insufficient against local trust-store tampering.

Disable DNS because certificate trust does not depend on hostnames.

Why wrong: Disabling DNS would break hostname resolution entirely, and certificate validation absolutely depends on hostnames: the browser checks that the certificate's SAN matches the requested DNS name. Even if DNS were disabled, a tampered Trusted Root Store would still cause the browser to accept a malicious certificate for whatever IP or hostname the attacker uses. Removing DNS would not restore integrity to the certificate trust chain; it would only disrupt legitimate application communication.

Embed private keys in the container image so redeployments are simpler.

Why wrong: Embedding private keys in a container image couples the secret to immutable image layers that are distributed to every replica. Anyone with access to the registry, CI cache, or a compromised node can extract the key with a single command, and the blast radius includes every environment using that image. Key rotation then demands rebuilding and redeploying the image, which is exactly the kind of operational friction the approach aims to avoid.

Replace the CA with a self-signed certificate on every node.

Why wrong: Self-signed certificates on every node require each node to independently validate the identity of every other node, typically via manual fingerprint pinning or a shared trust store that has no central management. Renovation and rotation become a distributed chore because there is no CA to revoke or reissue identities. This approach leaves services vulnerable to impersonation and does not scale to a dynamic microservices environment.

Convert the key file to base64 before storing it in the image.

Why wrong: Convert to from binary to base64 is simply a character encoding change, not encryption or even obfuscation. A base64-encoded private key is trivially decoded with standard command-line tools, so an attacker with read access to the image layer still obtains the exact same long-lived secret. Storing it in the image merely adds a decoding step, providing zero security benefit and potentially hiding the risk from security review.

Least privilege for the production change account.

Why wrong: Least privilege limits the permissions granted to the production change account, but it does not introduce any independent human review or approval step. An administrator with just enough rights to modify the firewall can still both request and apply a change, so the same person retains unilateral control over the process. It is a useful defense-in-depth measure that reduces the blast radius of a compromised account, but it fails to address the need for a second person in the change workflow.

Job rotation for every engineer each quarter.

Why wrong: Job rotation can help expose fraud over time, but it does not directly enforce a second reviewer on each production change. It is an oversight practice, not an immediate control for the specific risk described.

Risk transference to the firewall vendor.

Why wrong: Risk transference, such as purchasing insurance or relying on vendor liability clauses, shifts the financial consequences of a firewall misconfiguration to an external party. It does not alter the internal change process, so a single individual can still authorize and implement a dangerous rule, and the organization remains operationally exposed even if indemnified. This control addresses post-incident fiscal impact, not the pre-incident procedural gap described by the network team.

Require a longer password on the shared account.

Why wrong: Requiring a longer password on the shared account only increases the difficulty of brute-force or credential-guessing attacks. It does nothing to separate the identities of the procurement team members; every approval is still logged as being performed by the same shared account. Longer passwords address authentication strength, but they do not provide individual attribution or prevent one team member from denying that they performed a specific approval, so the core accountability gap remains.

Store screenshots of approval screens in a shared folder.

Why wrong: Screenshots stored in a shared folder are simple image files with no cryptographic signature, reliable metadata, or chained timestamp. They can be easily edited, copied, or staged from manipulated UI states, and the shared folder does not prove who captured or uploaded a particular screenshot. As evidence, they are demonstrative artifacts rather than authoritative audit records, and they offer no mechanism to prevent a user from later denying that they approved a request.

Encrypt the approval database at rest.

Why wrong: Encrypting the approval database at rest protects the confidentiality of the data by making it unreadable without the appropriate decryption keys. It does not, however, bind an approval action to a specific individual or protect the database from modification by authorized users. Encryption is a data-protection control; it provides secrecy, not integrity, attribution, or resistance to repudiation, so it fails to address the accountability problem identified in the audit.

Using a single, comprehensive security solution to minimize complexity and management overhead

Why wrong: Relying on a single, comprehensive security solution is antithetical to defense in depth because it creates a single point of failure—if that solution is compromised or misconfigured, there are no compensating controls. No single product can address all attack vectors, and complexity is not eliminated but shifted into the vendor's unknowns. Defense in depth intentionally accepts management overhead in exchange for resilience, making this a misguided approach.

Disabling all logging and monitoring to reduce system resource consumption

Why wrong: Disabling logging and monitoring eliminates the detective controls that are essential for identifying attacks and enabling incident response. Without audit logs, organizations lose the ability to reconstruct events, perform forensic analysis, and meet regulatory compliance. The resource savings are negligible compared to the risk of undetected breaches, and this action directly undermines the visibility required for a robust defense in depth strategy.