SY0-701 Security Architecture 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.

• ✗

  Trusted Platform Module (TPM)

  Why it's wrong here

  A Trusted Platform Module is a passive hardware root of trust that stores platform configuration measurements in PCRs and protects cryptographic keys, but it does not execute application logic or mediate memory access. It can attest to the integrity of the boot process via measured boot, yet it offers no runtime enclave in which a process can hide data from the OS. Even if the TPM is present, a compromised kernel can directly read the memory of any ordinary user-space process.

  When this WOULD be correct

  A question asking for a hardware root of trust to verify platform integrity at boot time, or to securely store encryption keys and perform platform attestation, would have TPM as the correct answer.

• ✗

  Hardware Security Module (HSM)

  Why it's wrong here

  A Hardware Security Module is a dedicated cryptographic appliance for generating, storing, and using keys, often with tamper protection, but it is not a general-purpose secure processor for running application code. It performs specific operations like signing, encryption, and key derivation, and it does not provide an isolated address space for the larger application's data. The host application must pass plaintext to the HSM, so the memory of the calling process remains exposed to the OS, hypervisor, or malware.

  When this WOULD be correct

  A question asking for a dedicated hardware device to securely store cryptographic keys and perform cryptographic operations (e.g., signing, encryption) for a payment processing system, especially when compliance with standards like FIPS 140-2 is required.

• ✓

  Secure enclave (e.g., Intel SGX)

  Why this is correct

  A secure enclave, such as Intel Software Guard Extensions (SGX), creates hardware-enforced encrypted regions of memory that protect code and data from access by the host OS, hypervisor, or other processes, even if those lower layers are compromised.

• ✗

  UEFI Secure Boot

  Why it's wrong here

  UEFI Secure Boot establishes a chain of trust only during the boot sequence: the firmware verifies the digital signature of the boot loader, and the boot loader verifies the OS kernel. Once the operating system is running, Secure Boot has no mechanism to enforce memory isolation or protect application code from the host OS or hypervisor. It cannot create a private execution context for sensitive data, so an attacker with kernel-level access would still have full visibility into the process's memory.

  When this WOULD be correct

  A question asks: 'Which technology prevents unauthorized operating systems or bootkits from loading during the boot process on a secure system?' In that context, UEFI Secure Boot is the correct answer because it verifies digital signatures of boot components.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SY0-701 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official SY0-701blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”