Cyber Security Quiz: Key Management
10 questions · exam conditions
0:00
Key ManagementQuestion 1 of 10

A payment service must generate long-lived AES-256 keys on virtual machines that may start simultaneously. The design must minimize the risk of predictable or duplicate keys without relying on a central administrator to supply key material.

Which key-generation approach BEST satisfies the requirement?

Hash each virtual machine's identifier and startup timestamp, then use the resulting 256-bit digest directly as the key.
Apply a password-based key derivation function to an administrator passphrase, using each virtual machine's identifier as the salt.
Request 256 bits from a properly seeded operating-system cryptographic random generator and maintain a separate identifier for the generated key.
Request 128 random bits from the operating system, duplicate those bits to reach 256 bits, and reject any repeated result.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Key Management

Practice Key Management 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 Key Management, 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 payment service must generate long-lived AES-256 keys on virtual machines that may start simultaneously. The design must minimize the risk of predictable or duplicate keys without relying on a central administrator to supply key material.

Which key-generation approach BEST satisfies the requirement?

  1. Hash each virtual machine's identifier and startup timestamp, then use the resulting 256-bit digest directly as the key.
  2. Apply a password-based key derivation function to an administrator passphrase, using each virtual machine's identifier as the salt.
  3. Request 256 bits from a properly seeded operating-system cryptographic random generator and maintain a separate identifier for the generated key. (correct answer)
  4. Request 128 random bits from the operating system, duplicate those bits to reach 256 bits, and reject any repeated result.
Explanation: When generating cryptographic keys, your primary concerns are unpredictability (entropy) and uniqueness. A key is only as strong as the randomness it's built from — and a 256-bit AES key is worthless if an attacker can reproduce it. The right approach here is C: requesting 256 bits from the OS cryptographic random number generator (CSPRNG). Modern OS CSPRNGs (like /dev/urandom or CryptGenRandom) gather entropy from hardware events, boot noise, and other unpredictable sources, making them properly seeded even across simultaneous VM startups. Maintaining a separate key identifier means you can reference and manage the key without ever exposing the key material itself. This approach requires no central administrator, satisfies the entropy requirement, and scales cleanly. A is dangerous because hashing deterministic inputs — a VM ID and timestamp — produces a deterministic output. If two VMs start at the same millisecond, they generate identical keys. Even if timestamps differ, an attacker who knows the VM ID and approximate startup time can brute-force the key space trivially. Hashing is not a source of entropy. B introduces a critical dependency: an administrator passphrase. Password-based KDFs like PBKDF2 are designed for low-entropy secrets and are intentionally slow to compensate. Using a human-chosen passphrase as the seed violates the "no central administrator" requirement and caps your entropy at password strength, not 256 bits. D duplicating 128 bits to fill 256 bits is a fatal flaw — you immediately halve the effective key space to 21282^{128} unique keys, and the second half carries zero additional entropy. Rejecting duplicates doesn't fix the structural weakness. Study tip: On crypto key-generation questions, always trace where the entropy actually comes from. If the input is deterministic or human-supplied, the output is never truly random — regardless of what mathematical operation you apply to it.

Question 2

A certificate-signing key is generated inside a hardware security module and marked non-exportable. The organization later discovers that failure of this single module would permanently prevent certificate issuance and validation of certain archived records.

Which design BEST improves availability without routinely exposing the private key in plaintext?

  1. Use an approved hardware security module cluster and create authenticated, encrypted recovery backups under separately controlled recovery keys. (correct answer)
  2. Export the private key in plaintext during maintenance windows and place copies in separate administrator password vaults.
  3. Generate an unrelated replacement key on each backup module and configure all modules to use the same certificate identifier.
  4. Store the module administrator credentials in multiple locations and rely on those credentials to reconstruct the private key after failure.
Explanation: When you see a question about cryptographic key management, hold two competing goals in tension: confidentiality (the private key must never be exposed in plaintext) and availability (the system must survive hardware failure). The best solution satisfies both simultaneously. Option A does exactly this. HSM clustering allows multiple physical modules to share the same key material internally, maintaining the "non-exportable in plaintext" property while eliminating the single point of failure. Encrypted recovery backups, protected by separately controlled recovery keys, provide a break-glass restoration path without ever exposing the raw private key — even to administrators. This is the industry-standard pattern for high-availability PKI infrastructure, and it's why A is the correct answer. Option B is a textbook security failure: exporting the private key in plaintext — even during a maintenance window — permanently violates the confidentiality guarantee. Once a key exists in plaintext outside the HSM, the non-exportable protection becomes meaningless. "Maintenance window" language is a common distractor designed to make a bad practice sound controlled. Option C is technically incoherent. A replacement key is a different cryptographic key — sharing the same certificate identifier doesn't make modules interchangeable for validating signatures or archived records that were encrypted or signed with the original key. This would break historical validation entirely. Option D confuses authentication with key recovery. Administrator credentials grant access to the HSM interface; they don't reconstruct or contain the private key itself. Losing the hardware means losing the key, regardless of credential availability. Study tip: On HSM questions, "non-exportable" is a feature, not a limitation to work around — any answer that circumvents it in plaintext is automatically wrong.

Question 3

A vendor signs software packages with a private key. Customers may need to validate previously released packages for two years, but the signing key is rotated annually. Re-signing every historical package would disrupt existing deployment workflows.

Which rotation plan BEST preserves validation while limiting unnecessary use of the old private key?

  1. Replace the trusted public key when rotation occurs and remove the old public key from all validation systems immediately.
  2. Use the new private key for current packages but keep the old private key online so validators can check historical signatures.
  3. Distribute the new public key before switching, sign new packages with the new private key, and retain the old public key for historical validation. (correct answer)
  4. Delete both old keys during rotation and instruct customers to treat release timestamps as proof that historical packages are authentic.
Explanation: When a question involves key rotation and long-lived signatures, you should think about two separate concerns: signing (which needs the private key) and verifying (which only needs the public key). These two operations have completely different lifecycle requirements, and conflating them is exactly the trap this question sets. The best rotation strategy keeps these roles distinct. You distribute the new public key to validators before switching, so no one is caught off-guard. New packages get signed with the new private key, minimizing exposure of that key. Critically, you retain the old public key alongside the new one in validation systems — because old signatures made with the old private key can still be verified with the old public key without ever touching the old private key again. Option C executes this precisely: proactive distribution, clean signing transition, and backward-compatible verification. That's the right answer. Option A fails because removing the old public key immediately makes historical signatures unverifiable — customers can no longer validate packages signed under the previous key, breaking exactly the two-year validation requirement described. Option B is a serious security mistake: keeping the old private key online "so validators can check historical signatures" misunderstands the cryptography entirely. Validators only need the public key; leaving the private key active unnecessarily extends its attack surface. Option D is the most dangerous distractor — deleting both keys destroys all cryptographic integrity, and relying on timestamps as proof of authenticity provides no tamper-evidence whatsoever. Study tip: On key rotation questions, always ask yourself separately — "who needs the private key, and who needs the public key?" Public keys can safely outlive private keys, and that asymmetry is often the key to the correct answer.

Question 4

An organization needs an offline recovery method for a root key. Policy requires that no single custodian be able to recover the key and that recovery remain possible if up to two of five custodians are unavailable.

Which arrangement BEST satisfies both requirements?

  1. Create a three-of-five threshold-protected recovery package, give one share to each custodian, and reconstruct it only in an audited ceremony. (correct answer)
  2. Encrypt the root key with one recovery key held by a senior administrator, but require two managers to approve its use.
  3. Divide the textual encoding of the root key into five consecutive fragments and require every fragment during an audited ceremony.
  4. Give each custodian a complete encrypted root-key backup and rely on written policy to require three custodians for recovery.
Explanation: When you see a question about protecting cryptographic keys with custodian controls, think Shamir's Secret Sharing (SSS) — a mathematical scheme that splits a secret into n shares where any k shares reconstruct it, but fewer than k shares reveal nothing. The two policy requirements here are your checklist: (1) no single person can recover the key alone, and (2) recovery survives up to two unavailable custodians, meaning you need a 3-of-5 threshold — any three of five shares work, and losing two still leaves three available. Option A satisfies both requirements precisely. A cryptographic 3-of-5 threshold scheme means one share is useless alone (no single custodian wins), and any three shares reconstruct the key even if two custodians are absent. The audited ceremony adds proper procedural controls. This is the correct answer. Option B fails immediately on the first requirement — a senior administrator holding a single recovery key can unilaterally recover it. Requiring managerial approval is a policy control, not a cryptographic one, and policy can be bypassed or coerced. Option C is a common trap. Splitting the key into five consecutive fragments and requiring all five means losing even one custodian makes recovery impossible — this violates the second requirement entirely. Fragmentation also provides no cryptographic security guarantees that SSS does. Option D gives every custodian a complete encrypted backup, so any single custodian who obtains the decryption key could recover it alone. Written policy is not a technical enforcement mechanism. Study tip: On security exams, always distinguish between cryptographic enforcement and policy enforcement — if a control can be bypassed without breaking math, it's not a true technical control.

Question 5

A records system rotates its encryption key each year. New records use the current key, but records from prior years must remain readable for seven years. An auditor objects to leaving every historical key enabled for unrestricted encryption and decryption.

Which lifecycle configuration BEST addresses both retention and the auditor's concern?

  1. Use the newest key for all operations and delete each historical key immediately after the annual rotation completes.
  2. Keep every historical key fully active because any restriction could prevent access to records during an investigation.
  3. Use the new key for encryption and place historical keys in a restricted decrypt-only state with audited access until retention ends. (correct answer)
  4. Derive each new annual key from the previous key so that retaining only the newest key permits recovery of every historical key.
Explanation: When you see a question about encryption key management, think about two competing requirements that must both be satisfied: data accessibility over time and the principle of least privilege. A well-designed key lifecycle lets you read what you need without granting more capability than necessary. The configuration in C threads this needle precisely. Historical keys are placed in a decrypt-only state, meaning they can still unlock archived records for the full seven-year retention window, but they cannot encrypt new data. Audited access adds an accountability layer, directly satisfying the auditor's concern that unrestricted keys create unnecessary risk. This reflects a mature key management practice: retire a key's encryption permission while preserving its decryption permission only as long as legally required. A fails immediately on the retention requirement. Deleting a historical key means any record encrypted under that key becomes permanently unreadable — a compliance disaster when records must be accessible for seven years. B addresses retention but ignores the auditor entirely. Keeping every historical key "fully active" means each one can still encrypt new data, which is precisely the unrestricted access the auditor objected to. More capability than needed is a security violation, not a feature. D sounds technically clever but introduces serious cryptographic risk. Key derivation chains create a single point of failure: compromise the newest key and an attacker can potentially reconstruct every prior key, undermining the entire rotation strategy. A useful study tip: on key management questions, always ask yourself what permissions does each key actually need at this point in its lifecycle? Rotation exists to limit exposure — restriction without deletion is often the right answer when retention obligations apply.

Question 6

Investigators believe a database data-encryption key may have been copied by an attacker 30 days ago. The same key protects current records and several retained snapshots. The organization wants to limit continued exposure while preserving required recovery capabilities.

Which response most completely addresses the key-management implications of the suspected compromise?

  1. Restrict access to the key-management account and continue using the existing key because its cryptographic strength has not changed.
  2. Assign a new version number to the existing key and update the database metadata without changing the underlying key material.
  3. Rotate only the key-encryption key that wraps the database key, then retain the potentially copied database key for all records.
  4. Generate a replacement key, migrate still-sensitive ciphertext and snapshots where feasible, then revoke the old key after recovery dependencies are resolved. (correct answer)
Explanation: When a cryptographic key is suspected of being compromised, the core principle to apply is containment followed by continuity — you must neutralize the attacker's advantage while preserving legitimate operational needs. The question tests whether you understand that a compromised key's cryptographic strength is irrelevant once confidentiality of the key material itself is lost. Option D is correct because it addresses all three dimensions of the problem: generating new key material eliminates the attacker's ability to decrypt future or migrated data; re-encrypting accessible sensitive ciphertext and snapshots closes the exposure window; and deferring revocation until recovery dependencies are resolved ensures you don't destroy the organization's ability to restore from older backups. This is textbook key rotation under compromise conditions. Option A fails because it conflates algorithm strength with key secrecy. A 256-bit AES key is worthless for confidentiality once an adversary possesses it — its bit length no longer matters. Restricting account access is a useful hardening step but doesn't address the already-copied key material. Option B is cosmetic. Updating metadata and assigning a new version number changes nothing about the underlying key material. The attacker still holds a working copy of the exact same key, so this provides zero security benefit. Option C partially helps by protecting the key-encryption key layer, but it leaves the actual database key — the one the attacker copied — still in use and still valid. Wrapping a compromised key more securely doesn't un-compromise it. Study tip: On key-management questions, always ask: "Does this response actually replace the exposed key material?" If not, it's almost certainly a distractor.

Question 7

A team is requesting a public certificate for an internet-facing service. An administrator proposes generating the key pair on a laptop, emailing the private key to the server team, and sending the public key to the certificate authority.

Which alternative provides the strongest key-management improvement while preserving the certificate-enrollment process?

  1. Generate the key pair at the certificate authority and ask it to send both keys to the service through an encrypted email attachment.
  2. Generate the key pair in the service's hardware-backed key store and send only a certificate signing request containing the public key. (correct answer)
  3. Generate the key pair on the laptop, divide the private-key file into two archives, and send each archive through a different channel.
  4. Generate the key pair on the server, upload both keys to the certificate authority, and request deletion after the certificate is issued.
Explanation: When you see a question about certificate enrollment and private key handling, anchor your thinking to one core principle: a private key should never leave the system that generated it. The moment a private key travels across a network or sits in someone's inbox, every system it touched becomes a potential point of compromise. The strongest improvement here is answer B — generating the key pair inside the service's hardware-backed key store (such as an HSM or TPM). The private key is created and remains protected within tamper-resistant hardware, never exported. The enrollment process is preserved because you still send a Certificate Signing Request (CSR) to the CA — the CSR contains only the public key and identifying information, so the CA can issue a certificate without ever seeing the private key. This is exactly how modern, secure certificate enrollment is designed to work. A is dangerously wrong: having the CA generate your private key and email it to you defeats the entire trust model. Now both the CA and the email channel have had access to your private key. C is security theater — splitting the private key into two archives and sending them separately reduces the attack surface only marginally, and the original private key still existed unprotected on a laptop. Both halves can be reassembled by an attacker who intercepts either channel. D compounds the original mistake: uploading a private key to any third party (including the CA) is a fundamental violation of key confidentiality, and "requesting deletion" provides no verifiable assurance. For exam strategy, remember: CSRs exist precisely so private keys never have to travel. Any answer that moves a private key off the generating system is almost always wrong.

Question 8

An object-storage platform encrypts every object with a unique data-encryption key. Each data-encryption key is stored only after being wrapped by a key-encryption key held in a key management service. Policy requires quarterly rotation of the key-encryption key, but rewriting millions of large objects would cause unacceptable disruption.

Which rotation procedure BEST meets the policy while minimizing operational impact?

  1. Generate new data-encryption keys and rewrite every object, but continue wrapping those keys with the existing key-encryption key.
  2. Create a new key-encryption key, unwrap and rewrap each data-encryption key, then retire the old key after verifying migration. (correct answer)
  3. Create a new key-encryption key and update its alias, while leaving all existing wrapped data-encryption keys unchanged indefinitely.
  4. Delete the old key-encryption key immediately and rewrap each data-encryption key the next time its object is accessed.
Explanation: When you see a question about key rotation in an envelope encryption system, think in two layers: the data-encryption keys (DEKs) that protect actual data, and the key-encryption key (KEK) that wraps those DEKs. Rotating the KEK doesn't require touching the objects themselves — only the wrapped DEK blobs need updating. The correct approach, B, threads this needle perfectly. You generate a new KEK, then iterate through your stored wrapped DEKs: unwrap each one using the old KEK, rewrap it with the new KEK, and save the updated blob. The objects themselves are never rewritten — only small key-material records change. Once you've verified every DEK has been migrated, you retire the old KEK. This satisfies the rotation policy with minimal disruption because you're moving kilobytes of key material, not petabytes of object data. A gets the layers backwards. Generating new DEKs means rewriting every object (to re-encrypt with those new keys), which is exactly the "unacceptable disruption" the scenario warns against. Keeping the old KEK also defeats the purpose of rotation. C is a dangerous shortcut. Updating an alias to point to a new KEK while leaving old wrapped DEKs unchanged means those DEKs are still encrypted under the old KEK — the old key must remain active indefinitely, so you've achieved no real rotation. D creates a catastrophic availability gap. Deleting the KEK immediately orphans all wrapped DEKs before they can be migrated, potentially causing permanent data loss. Your study tip: in envelope encryption questions, always trace which key unlocks what. KEK rotation only requires rewrapping DEKs — never re-encrypting the underlying data.

Question 9

A manufacturer is designing authentication for thousands of field sensors. The security requirement states that extracting secret material from one sensor must not allow an attacker to impersonate any other sensor.

Which provisioning strategy BEST supports this requirement?

  1. Generate one high-entropy fleet key, store it in every sensor, and rotate it whenever any individual sensor is replaced.
  2. Hash each sensor's public serial number and use the resulting digest as that sensor's authentication key.
  3. Derive sensor keys from a master key and store both the master key and the derived key on every sensor for recovery.
  4. Generate a unique random key for each sensor, provision it securely, and protect server-side copies in a managed key vault. (correct answer)
Explanation: When designing authentication for large device fleets, the guiding principle is key compromise isolation — if one device is breached, the damage should be contained to that device alone. Ask yourself: "If an attacker extracts secrets from a single sensor, what else can they reach?" Generating a unique random key per sensor, as in D, is the only strategy that achieves true isolation. Each sensor holds credentials that are cryptographically unrelated to every other sensor's credentials. Compromise of one key reveals nothing about the others, and a well-managed key vault with access controls, auditing, and rotation policies ensures the server-side copies are protected without creating systemic risk. A fails immediately because a single shared fleet key is a single point of failure — extracting it from any sensor gives an attacker the ability to impersonate every sensor. Rotation after replacement still leaves all unrotated sensors exposed during the window of compromise. B is dangerously flawed because serial numbers are often public or predictable, and a hash of public data is reproducible by anyone — an attacker who knows the formula can derive authentication keys for sensors they've never physically touched. C is a subtle trap: storing the master key on every sensor defeats the purpose of hierarchical key derivation entirely. Now every sensor is a potential path to the master, which is worse than the shared-key problem in A. Study tip: On questions about IoT or fleet authentication, watch for any answer that links device secrets together — shared keys, derivable keys, or master keys on endpoints are all variations of the same anti-pattern.

Question 10

A multitenant service encrypts each tenant's data with a unique data-encryption key. The ciphertext remains in replicated storage, while each data-encryption key is stored only in wrapped form. The service wants tenant deletion to make the retained ciphertext cryptographically unrecoverable.

Which action is necessary for this crypto-shredding design to achieve its objective?

  1. Delete the tenant's key identifier from the production database and rotate the shared key-encryption key so that existing wrapped copies become inaccessible.
  2. Remove every wrapped, cached, and plaintext copy of the tenant's data-encryption key after confirming no required recovery dependency remains. (correct answer)
  3. Rotate the shared key-encryption key and rewrap the tenant's data-encryption key under the new version to break the original encryption chain.
  4. Overwrite the first and last portions of each ciphertext replica while retaining the tenant's data-encryption key in escrow for audit investigations.
Explanation: Crypto-shredding is a data destruction technique that renders ciphertext permanently unrecoverable by destroying the encryption key rather than the data itself. When you see a question about this pattern, ask yourself: what must be completely eliminated for the ciphertext to become permanently indecipherable? The answer is always the key — and every copy of it. For crypto-shredding to work, the data-encryption key (DEK) must be irretrievably destroyed. In a wrapped-key architecture, the DEK exists in multiple forms: wrapped (encrypted) copies in storage, cached plaintext versions in memory or key managers, and potentially plaintext copies held temporarily during operations. If any copy survives, an attacker — or a subpoena — can recover it and decrypt the ciphertext. Answer B correctly identifies that all wrapped, cached, and plaintext copies must be confirmed deleted before the objective is met. This is the only path to guaranteed cryptographic unrecoverability. Answer A fails because deleting a key identifier from a database doesn't destroy the key material itself — wrapped copies may persist in backups, HSMs, or replicas. Rotating the shared key-encryption key (KEK) doesn't help either, since existing wrapped copies were encrypted under the old KEK version, which may still be accessible. Answer C actually preserves the tenant's DEK by rewrapping it under a new KEK — this explicitly keeps the key alive in a new form, defeating the entire purpose. Answer D is doubly wrong: partial ciphertext overwriting is not cryptographic shredding, and retaining the DEK "in escrow" means the data remains recoverable. Remember: crypto-shredding lives or dies by total key destruction. If any copy of the DEK survives anywhere, the design has failed — the ciphertext is still recoverable.