Cloud Security Operations practice questions

Physical tamper protection in an HSM ranges from evidence of tampering to active detection and response that zeroizes keys.

The policy asks for an active reaction: detect the intrusion and destroy the keys first. That is tamper response with zeroization, which FIPS 140-3 associates with its higher physical security levels. Tamper evidence only proves later that the module was opened. Quorum and wrapped backups are sound controls, but they address insider misuse and key availability, not a physical attack on the hardware.

1. Identify the threat: physical intrusion into the module.
2. Separate detecting tampering afterwards from reacting to it in real time.
3. Pick the capability that erases keys when tampering is detected.

Exam tip: Tamper evident shows it happened; tamper responsive zeroizes the keys while it happens.

A FIPS 140-3 validation covers a module only when it is operated in the approved mode described by its security policy.

The validation certificate does not bless everything the hardware can do. The module's security policy defines an approved mode, and calling non-approved algorithms means operating outside it. The contract cares about the customer-data keys, so the clean design keeps them on a module that stays in approved mode and confines the legacy algorithm to a separate module that holds nothing in scope. Enabling the algorithm on the shared module mixes the two; exporting the key leaves the boundary entirely; wrapping a key does not change which algorithm the operation needs.

1. Find what the contract scopes: keys protecting customer data.
2. Recall that a validation applies only in the module's approved mode.
3. Look for the option that keeps scoped keys in approved operation and isolates the exception.
4. Reject options that move keys outside the boundary or mix modes.

Exam tip: A FIPS certificate covers the approved mode only; isolate non-approved needs on a module that holds nothing in scope.

Quorum, or M-of-N, authentication enforces dual control over sensitive HSM operations.

The requirement is prevention of solo action, which is dual control. M-of-N quorum makes a defined number of officers approve the operation. Role separation, MFA and logging are all sensible HSM configuration, but each still lets one properly authenticated officer complete the task alone; logging only detects it afterwards.

1. Restate the requirement as dual control.
2. Ask of each option whether one officer could still finish the task.
3. Choose the control that needs several people to approve.

Exam tip: No single person may do it: configure M-of-N quorum.

The layer that performs encryption is the last layer that sees plaintext; everything below it sees only ciphertext.

Hypervisor encryption, array encryption and key rotation all leave the hypervisor holding plaintext disk blocks. Only encryption performed inside the guest, with keys the provider never holds, keeps the virtual disk opaque to someone operating the hypervisor. A customer-managed key in the provider's service is a real improvement in key control, but the decryption still happens in the provider's layer.

1. Identify who must be kept out: people with hypervisor access.
2. Find where decryption happens in each option.
3. Pick the option where decryption happens above the hypervisor with keys outside the provider.

Exam tip: To hide data from a layer, encrypt above it with keys it never holds.

HSM key attributes set at generation control whether a key can ever leave the module.

The auditor's question is about plaintext exposure across the key's whole life. Generating the key inside the HSM means it never existed outside, and the non-extractable attribute means the module refuses to export it. Importing a wrapped key is common, but the plaintext existed elsewhere first. Replication and rotation are good practice that address availability and cryptoperiod, not exportability.

1. Note that the concern is plaintext exposure at any point in the key's life.
2. Ask where each key was born and whether it can be exported.
3. Choose generation inside the module with export disabled.

Exam tip: Born inside the HSM and non-extractable: the plaintext key never exists anywhere else.

HSM backups are normally exported as blobs encrypted under a wrapping key that only trusted HSMs hold.

Three requirements must hold together: recoverability, no plaintext outside an HSM, and sole customer control. A wrapped backup blob satisfies all three when the wrapping key lives only in HSMs the company controls. Provider-managed backups give recovery but hand the provider the key. Non-extractable keys with no backup give control but no recovery. Clear key components exported to officers keep control and allow recovery, but they are plaintext key material outside an HSM.

1. List the three requirements separately.
2. Test each option against all three, not just the first one it satisfies.
3. Keep the option where only the company's HSMs can unwrap the backup.

Exam tip: Back up HSM keys as wrapped blobs; whoever holds the wrapping key controls recovery.