Explain encryption as a service →mediumMultiple Choice

VA-003 Explain encryption as a service Practice Question

A payment processing team needs an application to encrypt transaction payloads without ever handling the raw encryption key material. The application will call Vault over mTLS, and the security team insists that the plaintext never leave the application process. Which Vault capability best satisfies this requirement?

⚠ Common exam trap

The trap here is assuming that storing the key in Vault and reading it back is equivalent to encryption as a service, when the defining property is that Vault performs the cryptographic operation and the key never leaves.

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 secrets engine's encrypt endpoint, where Vault performs the cryptographic operation and returns ciphertext to the caller.

Encryption as a service means the cryptographic operation happens inside Vault, so key material never leaves the trusted boundary. The transit engine's encrypt endpoint accepts plaintext, applies the named key, and returns ciphertext, letting the application satisfy the requirement without ever seeing the key. Static secret storage, certificate issuance, and response wrapping all leave the application responsible for the actual encryption step.

Answer analysis

Option-by-option breakdown

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

✗
The kv secrets engine storing the encryption key as a versioned secret so the application can retrieve and use it locally.
Why it's wrong here
The kv engine only stores static secrets; it does not perform cryptographic operations. If the application retrieves the key and encrypts locally, the key material leaves Vault and must be handled by the application process, directly violating the stated requirement. kv also provides no key rotation semantics for cryptographic use, so rekeying would be a manual, error-prone process.
✗
The pki secrets engine issuing client certificates so the application can establish its own TLS session and encrypt payloads.
Why it's wrong here
The pki engine issues X.509 certificates for TLS authentication and encryption in transit, not for encrypting arbitrary application payloads at rest. Using it here would conflate transport security with data encryption, and the application would still need to manage its own symmetric keys for the payload, which is exactly what the team wants to avoid.
✓
The transit secrets engine's encrypt endpoint, where Vault performs the cryptographic operation and returns ciphertext to the caller.
Why this is correct
The transit engine is encryption as a service: the caller submits base64-encoded plaintext to the encrypt endpoint and receives ciphertext, while the key material stays inside Vault and is never exported. This matches the requirement that the application not handle raw keys, and because the operation happens server-side over mTLS, the plaintext is only in transit between the application and Vault.
✗
Vault's key/value version 2 engine with response wrapping, which protects the key while it is delivered to the application.
Why it's wrong here
Response wrapping protects a secret in transit via a single-use token, but once unwrapped the application still holds the raw key and performs encryption itself. That still requires the application to handle key material, and wrapped tokens are consumed on first read, making repeated encryption operations impractical. It solves delivery, not encryption as a service.

Go deeper

VA-003 Explain encryption as a service Practice Question

Why each option matters

Option-by-option breakdown

Related to this question