CAS-004 Security Engineering Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  To speed up the boot process.

  Why it's wrong here

  PCRs hold cumulative hashes that enable attestation of boot integrity, not performance tuning; they add no measurable speed benefit. The temptation is that measured boot records each stage, so it appears related to boot behaviour, but PCR extension is a cryptographic evidence mechanism, and speeding boot would instead involve firmware or OS configuration.

• ✗

  To provide a root of trust for storage (sealed storage).

  Why it's wrong here

  Sealed storage is PCR-bound key release, a separate TPM capability; measured boot's PCRs record integrity measurements for attestation, not storage-root sealing. It is tempting because sealing does consume PCR values, and would be correct when protecting data keys until a known-good configuration is verified.

• ✗

  To encrypt the bootloader.

  Why it's wrong here

  PCRs hold hash digests of boot components; they do not encrypt the bootloader, which is protected by BitLocker or Secure Boot signature checks. It is tempting because PCR values gate key release, and would be correct if the goal were binding disk-encryption keys to boot state.

• ✓

  To enable remote attestation of the system's boot state.

  Why this is correct

  PCRs hold cumulative hashes of boot components, and their values can be signed by the TPM's attestation key. A remote verifier compares these quotes against known-good values, confirming the system booted untampered — the core mechanism enabling remote attestation of boot state.