- Which rotation procedure BEST meets the policy while minimizing operational impact?
Answer: Create a new key-encryption key, unwrap and rewrap each data-encryption key, then retire the old key after verifying migration.
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.
- Which key-generation approach BEST satisfies the requirement?
Answer: Request 256 bits from a properly seeded operating-system cryptographic random generator and maintain a separate identifier for the generated key.
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 2128 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. - Which rotation plan BEST preserves validation while limiting unnecessary use of the old private key?
Answer: Distribute the new public key before switching, sign new packages with the new private key, and retain the old public key for historical validation.
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.
- Which lifecycle configuration BEST addresses both retention and the auditor's concern?
Answer: Use the new key for encryption and place historical keys in a restricted decrypt-only state with audited access until retention ends.
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.
- Which arrangement BEST satisfies both requirements?
Answer: Create a three-of-five threshold-protected recovery package, give one share to each custodian, and reconstruct it only in an audited ceremony.
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.
- Which design BEST improves availability without routinely exposing the private key in plaintext?
Answer: Use an approved hardware security module cluster and create authenticated, encrypted recovery backups under separately controlled recovery keys.
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.
- Which provisioning strategy BEST supports this requirement?
Answer: Generate a unique random key for each sensor, provision it securely, and protect server-side copies in a managed key vault.
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.
- Which action is necessary for this crypto-shredding design to achieve its objective?
Answer: Remove every wrapped, cached, and plaintext copy of the tenant's data-encryption key after confirming no required recovery dependency remains.
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.
- Which alternative provides the strongest key-management improvement while preserving the certificate-enrollment process?
Answer: Generate the key pair in the service's hardware-backed key store and send only a certificate signing request containing the public key.
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.
- Which response most completely addresses the key-management implications of the suspected compromise?
Answer: Generate a replacement key, migrate still-sensitive ciphertext and snapshots where feasible, then revoke the old key after recovery dependencies are resolved.
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.
