Explain encryption as a service →mediumMultiple Select

VA-003 Explain encryption as a service Practice Question

A compliance team is evaluating the Vault transit secrets engine as encryption as a service for several internal applications. They want to confirm which statements accurately describe how the engine behaves. (Choose two.)

⚠ Common exam trap

The trap here is conflating encryption as a service with key export or plaintext retention, when transit keeps keys inside Vault and never stores plaintext.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The transit engine supports key rotation while retaining prior versions so previously produced ciphertext remains decryptable.

The transit engine performs cryptographic operations inside Vault and returns only protected output, keeping keys non-exportable. It supports versioned key rotation so old ciphertext still decrypts, which is essential for long-lived data. It does not store plaintext, does not require sealing to mount, and does not export keys by default, so those statements misrepresent its security model and operational behavior.

Answer analysis

Option-by-option breakdown

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

✗
Enabling the transit engine requires Vault to be sealed and then unsealed before any key can be created.
Why it's wrong here
Mounting a secrets engine is a normal write operation performed on an unsealed, active Vault. Sealing removes access to the barrier and would prevent any engine operation. There is no requirement to seal and unseal to enable transit, and doing so would disrupt all other engines and clients on the cluster.
✓
The transit engine supports key rotation while retaining prior versions so previously produced ciphertext remains decryptable.
Why this is correct
Rotation adds a new key version, and ciphertext carries a version prefix that decrypt uses to select the correct version. Older versions are retained, so existing data continues to work without re-encryption. This is a core operational feature that lets teams rotate regularly without breaking applications or requiring mass rewrites of stored ciphertext.
✗
The transit engine stores plaintext copies of all encrypted data for audit and recovery purposes.
Why it's wrong here
Transit never persists plaintext. It processes plaintext in memory to produce ciphertext and returns the result, keeping no copy of the input. Retaining plaintext would undermine the entire point of encryption as a service and would create a high-value target inside Vault that does not exist in this design.
✓
The transit engine can perform cryptographic operations on data without the caller ever receiving the encryption key.
Why this is correct
Transit keeps key material inside Vault's barrier and returns only ciphertext, signatures, or wrapped keys. Callers invoke encrypt or decrypt endpoints and never see the raw key. This is the defining property of encryption as a service and is why application compromise does not directly expose keys, provided the calling token's policy is narrowly scoped.
✗
Transit keys are exportable by default so applications can cache them locally for offline encryption.
Why it's wrong here
Transit keys are non-exportable by design, and exportability is an exceptional setting rather than a default. The engine exists precisely so keys stay inside Vault. Allowing applications to cache keys locally would defeat the security model and reintroduce key management burdens the engine is meant to remove.

Go deeper

VA-003 Explain encryption as a service Practice Question

Why each option matters

Option-by-option breakdown

Related to this question