How should I use these Explain encryption as a service practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Explain encryption as a service questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Explain encryption as a service domain.

VA-003 · topic practice

Explain encryption as a service practice questions

The Encryption as a Service domain covers Vault's Transit secrets engine: encrypting and decrypting data without storing it, key rotation, datakey generation, and convergent encryption. Questions test when to use transit versus Vault's KV or PKI engines, how to handle large payloads, and the operational steps for rotating or rewrapping keys.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

20 questionsDomain: Explain encryption as a service

Practice 10 questions Browse domain →

What the exam tests

What to know about Explain encryption as a service

Be able to encrypt and decrypt via transit, generate and use datakeys for large files, and rotate keys with the correct endpoints. The critical point: transit never stores your plaintext, and rotation does not automatically re-encrypt existing data—use rewrap or datakeys.

Using the transit engine's encrypt, decrypt, and rewrap endpoints via API or CLI

Generating datakeys with the transit datakey endpoint for envelope encryption of large data

Rotating encryption keys with vault write -f transit/keys/<name>/rotate and setting min_decryption_version

Configuring convergent_encryption and derived keys for deterministic ciphertext on the same plaintext

Watch out for

Common Explain encryption as a service exam traps

▸Trying to send multi-GB files directly to the transit encrypt endpoint instead of using envelope encryption with a datakey.
▸Assuming key rotation re-encrypts existing ciphertext; old versions remain decryptable unless min_decryption_version is raised.
▸Confusing transit (encryption as a service, no plaintext storage) with KV (stores secrets) or PKI (issues certificates).

Practice set

Explain encryption as a service questions

20 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full Explain encryption as a service explanation →

A healthcare application needs to encrypt sensitive patient data before storing it in a legacy database that does not support encryption. The team wants to use Vault's encryption as a service. However, the application is running on a restricted network that cannot make outbound HTTP requests to Vault. Which solution should the team implement?

Trap 1: Set up Vault replication from a central Vault to a local Vault…

Replication does not eliminate the need for outbound calls.

Trap 2: Use Vault's HTTP API from the application to encrypt data directly.

The application cannot make outbound HTTP requests.

Trap 3: Enable the transit secrets engine and call Vault's encrypt endpoint.

Same network issue; requires outbound calls.

Study all Explain encryption as a service common traps →

A
Set up Vault replication from a central Vault to a local Vault instance.
Why it fails: Replication does not eliminate the need for outbound calls.
B
Deploy Vault Agent in sidecar mode with a configured encrypt stanza to handle encryption locally.
Vault Agent can process encryption locally via a Unix socket.
C
Use Vault's HTTP API from the application to encrypt data directly.
Why it fails: The application cannot make outbound HTTP requests.
D
Enable the transit secrets engine and call Vault's encrypt endpoint.
Why it fails: Same network issue; requires outbound calls.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full Explain encryption as a service explanation →

A DevOps team uses Vault's transit engine to encrypt secrets in CI/CD pipelines. They report that encryption operations are failing with 'permission denied' errors. The team has a policy granting 'create' and 'update' capabilities on the transit key path. What is the most likely missing capability?

Trap 1: The 'read' capability is missing.

Encryption against a transit key requires 'update' on the key path, which the policy already grants; 'read' governs key metadata retrieval, not encrypt operations. Read is the missing capability when a workload must inspect key configuration or versions.

Trap 2: The 'delete' capability is missing.

Deleting a transit key removes it entirely and is irrelevant to encrypt calls, which never invoke the 'delete' capability. The policy already supplies 'update', the capability Vault actually checks for encryption; 'delete' would only matter when rotating or destroying key material.

Trap 3: The 'list' capability is missing.

Encryption against a transit key is a read-style operation, so Vault checks the 'update' capability on the key path, which the policy already grants; 'list' only enumerates keys and is not consulted during encrypt calls. It would be required for listing key names, not performing cryptographic operations.

Study all Explain encryption as a service common traps →

A
The 'read' capability is missing.
Why it fails: Encryption against a transit key requires 'update' on the key path, which the policy already grants; 'read' governs key metadata retrieval, not encrypt operations. Read is the missing capability when a workload must inspect key configuration or versions.
B
The 'encrypt' capability is missing.
Vault's transit engine separates key management from cryptographic use. The policy grants create and update on the key path, which permits key administration, but the encrypt endpoint requires the distinct 'encrypt' capability on that path; without it, encryption calls return permission denied.
C
The 'delete' capability is missing.
Why it fails: Deleting a transit key removes it entirely and is irrelevant to encrypt calls, which never invoke the 'delete' capability. The policy already supplies 'update', the capability Vault actually checks for encryption; 'delete' would only matter when rotating or destroying key material.
D
The 'list' capability is missing.
Why it fails: Encryption against a transit key is a read-style operation, so Vault checks the 'update' capability on the key path, which the policy already grants; 'list' only enumerates keys and is not consulted during encrypt calls. It would be required for listing key names, not performing cryptographic operations.

Full breakdown with real-world context →

Question 3mediummulti select

Read the full Explain encryption as a service explanation →

Which TWO capabilities are required in a Vault policy to allow a client to encrypt data using a key named 'app-key' in the transit engine? (Assume the key already exists.)

Trap 1: read on /transit/keys/app-key

The 'read' capability on `/transit/keys/app-key` is not required for encryption; it only allows reading key metadata, which is not necessary to perform the encrypt operation.

Trap 2: update on /transit/keys/app-key

The 'update' capability on `/transit/keys/app-key` allows modifying the key configuration, which is not needed for encryption.

Trap 3: create on /transit/keys/app-key

The 'create' capability on `/transit/keys/app-key` is for creating new keys, not for using existing ones for encryption.

Study all Explain encryption as a service common traps →

A
read on /transit/keys/app-key
Why it fails: The 'read' capability on `/transit/keys/app-key` is not required for encryption; it only allows reading key metadata, which is not necessary to perform the encrypt operation.
B
encrypt on /transit/encrypt/app-key
The 'encrypt' capability on `/transit/encrypt/app-key` is the specific permission needed to submit data for encryption with the named key.
C
update on /transit/keys/app-key
Why it fails: The 'update' capability on `/transit/keys/app-key` allows modifying the key configuration, which is not needed for encryption.
D
create on /transit/keys/app-key
Why it fails: The 'create' capability on `/transit/keys/app-key` is for creating new keys, not for using existing ones for encryption.
E
list on /transit/keys/app-key
Why it fails: The 'list' capability on `/transit/keys/app-key` is for listing keys, which is unrelated to performing encryption.

Full breakdown with real-world context →

Question 4hardmulti select

Read the full Explain encryption as a service explanation →

Which TWO statements are true about Vault's encryption as a service using the transit engine?

Trap 1: Encryption keys cannot be rotated once created.

Encryption keys can be rotated in the transit engine, so this statement is false.

Trap 2: Vault stores the plaintext data for audit purposes.

Vault does not store plaintext data; it only processes encryption/decryption requests.

Trap 3: Clients can provide their own key material when creating a key.

Clients cannot provide their own key material; Vault generates keys internally. Even exportable keys are generated by Vault.

Study all Explain encryption as a service common traps →

A
Encryption keys cannot be rotated once created.
Why it fails: Encryption keys can be rotated in the transit engine, so this statement is false.
B
Data encrypted with a key can be decrypted with a later version of the same key if the key is rotated.
When a key is rotated, Vault creates a new version but retains old versions for decryption, so data encrypted with an earlier version can still be decrypted.
C
The transit engine supports convergent encryption.
Convergent encryption is supported in the transit engine, allowing deterministic encryption for deduplication.
D
Vault stores the plaintext data for audit purposes.
Why it fails: Vault does not store plaintext data; it only processes encryption/decryption requests.
E
Clients can provide their own key material when creating a key.
Why it fails: Clients cannot provide their own key material; Vault generates keys internally. Even exportable keys are generated by Vault.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full Explain encryption as a service explanation →

A multinational corporation uses Vault Enterprise with the transit engine to encrypt sensitive financial data across multiple cloud regions. Each region has its own Vault cluster, and they use performance replication to synchronize transit keys. Recently, the team in the Asia-Pacific region reports that encryption operations are slower than in other regions. They also notice that some decryption requests for data encrypted with a key that was rotated in the primary region are failing with 'key version not found' errors. The transit key is named 'fin-key' and has been rotated three times. The Asia-Pacific cluster is up-to-date with replication according to the replication status dashboard. Which action should the operations team take to resolve the decryption failures?

Trap 1: Increase the performance standby count in the Asia-Pacific cluster.

Addresses performance, not decryption errors.

Trap 2: Manually copy the key material from the primary to the secondary…

Replication should handle this.

Trap 3: Re-encrypt all data encrypted with version 1 of 'fin-key' using the…

Re-encryption doesn't address missing key version.

Study all Explain encryption as a service common traps →

A
Verify that the policy in the Asia-Pacific cluster grants 'decrypt' capability on the key path for older key versions.
Policy might be missing decrypt on older versions.
B
Increase the performance standby count in the Asia-Pacific cluster.
Why it fails: Addresses performance, not decryption errors.
C
Manually copy the key material from the primary to the secondary cluster.
Why it fails: Replication should handle this.
D
Re-encrypt all data encrypted with version 1 of 'fin-key' using the current version.
Why it fails: Re-encryption doesn't address missing key version.

Full breakdown with real-world context →

Question 6mediummulti select

Read the full Explain encryption as a service explanation →

Which TWO statements correctly describe Vault's encryption as a service using the Transit secrets engine?

Trap 1: Ciphertext is stored within Vault for later retrieval.

Transit is encryption as a service: Vault performs the cryptographic operation and returns ciphertext to the caller, retaining no copy, so nothing is stored for later retrieval. It is tempting because Vault's KV secrets engine does persist data, and Transit would be the correct choice where Vault must hold the encrypted material itself.

Trap 2: Encryption always produces a unique ciphertext even with the same…

Transit uses AES-GCM with a random nonce by default, so identical plaintext and key produce different ciphertext each call; uniqueness is the default behaviour, not a universal guarantee, since convergent encryption with a derived nonce yields deterministic output. It is tempting because nonce-based randomness is the standard mode, and it would be correct where deterministic ciphertext is not required.

Trap 3: Key rotation is not supported; the key version is fixed.

Transit supports key rotation, and each key holds multiple versions so old ciphertext remains decryptable while new encryptions use the latest version. It is tempting because some encryption systems do pin a single immutable key, and that design would be correct where regulatory or hardware constraints forbid re-keying.

Study all Explain encryption as a service common traps →

A
Ciphertext is stored within Vault for later retrieval.
Why it fails: Transit is encryption as a service: Vault performs the cryptographic operation and returns ciphertext to the caller, retaining no copy, so nothing is stored for later retrieval. It is tempting because Vault's KV secrets engine does persist data, and Transit would be the correct choice where Vault must hold the encrypted material itself.
B
Data is encrypted and decrypted on the server side without the client having direct access to the encryption key.
Transit performs cryptographic operations server-side, so plaintext and keys never leave Vault; clients submit data and receive ciphertext. This satisfies the requirement that the client has no direct key access, centralising key custody and enabling rotation without application changes.
C
Encryption always produces a unique ciphertext even with the same plaintext and key.
Why it fails: Transit uses AES-GCM with a random nonce by default, so identical plaintext and key produce different ciphertext each call; uniqueness is the default behaviour, not a universal guarantee, since convergent encryption with a derived nonce yields deterministic output. It is tempting because nonce-based randomness is the standard mode, and it would be correct where deterministic ciphertext is not required.
D
Key rotation is not supported; the key version is fixed.
Why it fails: Transit supports key rotation, and each key holds multiple versions so old ciphertext remains decryptable while new encryptions use the latest version. It is tempting because some encryption systems do pin a single immutable key, and that design would be correct where regulatory or hardware constraints forbid re-keying.
E
The encryption key can be derived per context using key derivation, ensuring unique ciphertext per context.
Transit's key derivation generates a distinct derived key from a context value, so identical plaintext under different contexts yields different ciphertext. This satisfies the requirement for unique ciphertext per context, preventing correlation of encrypted values across tenants or purposes.

Full breakdown with real-world context →

Question 7mediummulti select

Read the full Explain encryption as a service explanation →

A DevOps team needs to implement encryption as a service for application data stored in a PostgreSQL database. They want to use Vault's transit secrets engine to encrypt sensitive fields before storage. Which TWO actions should the team take to ensure the encryption keys are rotated automatically and securely?

Trap 1: Set 'min_decryption_version' to the latest key version to force…

Setting min_decryption_version blocks decryption of ciphertext written under older key versions, so old data becomes unreadable rather than re-encrypted; re-encryption requires the rewrap endpoint. It is tempting because raising the minimum does force applications to rewrite data, but that is a migration tactic, not automatic rotation.

Trap 2: Disable key rotation and rely on manual key updates using the…

Disabling rotation contradicts the requirement for automatic key rotation; the key/rotate endpoint performs a single manual rotation and cannot schedule recurring ones. It is tempting when operators want tight control over key versions, but scheduled rotation is configured through the transit engine's rotation_period parameter.

Trap 3: Restrict access to the decryption capability to prevent adversaries…

Restricting decrypt capability is an authorisation control that limits who can use the key; it neither rotates keys nor changes their version, so it fails the automatic-rotation requirement. It is tempting because least-privilege decryption genuinely reduces exposure, but it addresses access, not rotation.

Study all Explain encryption as a service common traps →

A
Set 'min_decryption_version' to the latest key version to force re-encryption of old data.
Why it fails: Setting min_decryption_version blocks decryption of ciphertext written under older key versions, so old data becomes unreadable rather than re-encrypted; re-encryption requires the rewrap endpoint. It is tempting because raising the minimum does force applications to rewrite data, but that is a migration tactic, not automatic rotation.
B
Use a key derivation function with a unique context per application context to ensure each encryption produces distinct ciphertext.
Using a key derivation function with a unique context per application ensures distinct ciphertext for identical plaintext, defeating pattern analysis in the PostgreSQL fields. This satisfies the stem's requirement for secure encryption, though it addresses ciphertext uniqueness rather than the automatic key rotation the team also needs.
C
Disable key rotation and rely on manual key updates using the transit key/rotate endpoint.
Why it fails: Disabling rotation contradicts the requirement for automatic key rotation; the key/rotate endpoint performs a single manual rotation and cannot schedule recurring ones. It is tempting when operators want tight control over key versions, but scheduled rotation is configured through the transit engine's rotation_period parameter.
D
Restrict access to the decryption capability to prevent adversaries from learning the key material.
Why it fails: Restricting decrypt capability is an authorisation control that limits who can use the key; it neither rotates keys nor changes their version, so it fails the automatic-rotation requirement. It is tempting because least-privilege decryption genuinely reduces exposure, but it addresses access, not rotation.
E
Configure a key rotation period using the 'auto_rotate_period' parameter when creating or tuning the encryption key.
The transit secrets engine supports automatic key rotation through the auto_rotate_period parameter, which schedules rotation at a defined interval. Setting it when creating or tuning the key ensures encryption keys rotate securely without manual intervention, satisfying the team's rotation requirement.

Full breakdown with real-world context →

Question 8easymultiple choice

Read the full Explain encryption as a service explanation →

A financial technology company uses Vault Enterprise to manage encryption keys for its payment processing system. The system uses the transit secrets engine to encrypt credit card numbers before storing them in a legacy database. The security team mandates that all encryption keys must be automatically rotated every 30 days. The operations team configures the key 'payment-cards' with 'auto_rotate_period' set to 30 days. After the first rotation, the payment processing application starts failing with 'permission denied' errors when trying to decrypt previously encrypted data. The application uses a token with a policy that grants 'create' and 'update' capabilities on 'transit/decrypt/payment-cards'. The application does not use the 'rewrap' endpoint. The Vault audit logs show that the decryption requests are being made to the correct path. What is the most likely cause of the failure?

Trap 1: The key rotation changed the encryption algorithm, making old…

Transit key rotation generates a new key version while retaining prior versions for decryption, so ciphertexts remain decryptable and the algorithm is unchanged. It tempts because algorithm changes do break compatibility, and specifying a new key type during rotation would be the correct approach when migrating away from a deprecated cipher.

Trap 2: The application's token has expired after the key rotation,…

Token expiry is unrelated to key rotation and would produce a distinct 'permission denied' on every path, not one tied to the decrypt operation after rotation. It tempts because short-lived tokens are a genuine Vault security practise, and renewing or reissuing a token is correct when TTLs lapse.

Trap 3: The application must use the 'rewrap' endpoint to re-encrypt all…

Rewrap is optional; it re-encrypts existing ciphertext under the latest key version but is not required for decryption, which automatically uses the version recorded in the ciphertext. It tempts because rewrap is genuinely the right tool when you must upgrade stored ciphertexts to the newest key version for compliance.

Study all Explain encryption as a service common traps →

A
The key rotation changed the encryption algorithm, making old ciphertexts incompatible with the new key.
Why it fails: Transit key rotation generates a new key version while retaining prior versions for decryption, so ciphertexts remain decryptable and the algorithm is unchanged. It tempts because algorithm changes do break compatibility, and specifying a new key type during rotation would be the correct approach when migrating away from a deprecated cipher.
B
The application's token has expired after the key rotation, requiring a new token with updated policies.
Why it fails: Token expiry is unrelated to key rotation and would produce a distinct 'permission denied' on every path, not one tied to the decrypt operation after rotation. It tempts because short-lived tokens are a genuine Vault security practise, and renewing or reissuing a token is correct when TTLs lapse.
C
The application must use the 'rewrap' endpoint to re-encrypt all ciphertexts with the new key version before decryption.
Why it fails: Rewrap is optional; it re-encrypts existing ciphertext under the latest key version but is not required for decryption, which automatically uses the version recorded in the ciphertext. It tempts because rewrap is genuinely the right tool when you must upgrade stored ciphertexts to the newest key version for compliance.
D
The application is not specifying the key version in the decryption request, and Vault defaults to the latest key version which cannot decrypt data encrypted with the old version.
By default, Vault uses the latest key version for decryption. To decrypt with an older version, the ciphertext must include a version reference, or the application must use the 'rewrap' endpoint.

Full breakdown with real-world context →

Question 9mediumdrag order

Read the full Explain encryption as a service explanation →

Drag and drop the steps to configure Vault's AWS secrets engine to generate IAM credentials into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Enable the AWS secrets engine, then configure the root IAM…

This order is incorrect because you must create a role before generating credentials; the role defines the permissions for the generated credentials.

Trap 2: Enable the AWS secrets engine, then create a role, then configure…

This order is incorrect because you need to configure the root IAM credentials before creating a role, as the role configuration may depend on the root credentials.

Trap 3: Configure the root IAM credentials, then enable the AWS secrets…

This order is incorrect because you must enable the secrets engine before configuring any settings for it.

Study all Explain encryption as a service common traps →

A
Enable the AWS secrets engine, then configure the root IAM credentials, then create a role, then generate IAM credentials, then rotate root credentials.
This is the correct order because you must first enable the engine, then configure the root credentials to allow Vault to interact with AWS, then define a role for generating credentials, then generate the actual IAM credentials, and finally rotate the root credentials for security.
B
Enable the AWS secrets engine, then configure the root IAM credentials, then generate IAM credentials, then create a role, then rotate root credentials.
Why it fails: This order is incorrect because you must create a role before generating credentials; the role defines the permissions for the generated credentials.
C
Enable the AWS secrets engine, then create a role, then configure the root IAM credentials, then generate IAM credentials, then rotate root credentials.
Why it fails: This order is incorrect because you need to configure the root IAM credentials before creating a role, as the role configuration may depend on the root credentials.
D
Configure the root IAM credentials, then enable the AWS secrets engine, then create a role, then generate IAM credentials, then rotate root credentials.
Why it fails: This order is incorrect because you must enable the secrets engine before configuring any settings for it.

Full breakdown with real-world context →

Question 10mediummatching

Read the full Explain encryption as a service explanation →

Match each Vault response wrapping feature to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Lifetime of the wrapping token

Single-use token to unwrap response

Token-scoped storage for wrapped data

Retrieve the original response

Trap 1: Response Wrapping Token: A token that never expires and can be used…

Incorrect — response wrapping tokens are single-use and have an expiration (TTL).

Trap 2: Cubbyhole: A secret storage engine that replicates to all nodes in…

Incorrect — cubbyhole is per-token and does not replicate; it is local to the token.

Trap 3: TTL: The number of times a wrapped response can be unwrapped before…

Incorrect — TTL is a time duration, not a usage count.

Study all Explain encryption as a service common traps →

A
Response Wrapping Token: A single-use token that encapsulates a response, used to securely transfer secrets.
Response wrapping tokens are designed for one-time use to securely deliver secrets.
B
Cubbyhole: A space within the token's response that stores the secret, only accessible by the token holder.
Cubbyhole is a per-token secret storage that is automatically destroyed with the token.
C
TTL (Time-to-Live): The duration for which the wrapped response is valid before it expires.
TTL controls how long the wrapped response remains usable before expiration.
D
Response Wrapping Token: A token that never expires and can be used multiple times.
Why it fails: Incorrect — response wrapping tokens are single-use and have an expiration (TTL).
E
Cubbyhole: A secret storage engine that replicates to all nodes in a cluster.
Why it fails: Incorrect — cubbyhole is per-token and does not replicate; it is local to the token.
F
TTL: The number of times a wrapped response can be unwrapped before it expires.
Why it fails: Incorrect — TTL is a time duration, not a usage count.

Full breakdown with real-world context →

Question 11mediummultiple choice

Read the full Explain encryption as a service explanation →

An application needs to encrypt credit card numbers. The encryption must be deterministic for indexing purposes but also support key rotation. Which approach should be used?

Trap 1: Use Vault's cubbyhole

Cubbyhole is for temporary tokens, not long-term encryption.

Trap 2: Use Vault's transformations engine

Transformations are for formats like masking, not encryption with rotation.

Trap 3: Use datakey encryption

Datakey is for envelope encryption; it does not inherently enforce determinism.

Study all Explain encryption as a service common traps →

A
Use Vault's cubbyhole
Why it fails: Cubbyhole is for temporary tokens, not long-term encryption.
B
Use Vault's transformations engine
Why it fails: Transformations are for formats like masking, not encryption with rotation.
C
Use datakey encryption
Why it fails: Datakey is for envelope encryption; it does not inherently enforce determinism.
D
Use convergent encryption with key rotation
Convergent encryption derives the data key from the plaintext itself, producing identical ciphertext for identical card numbers, which satisfies the deterministic indexing constraint. Key rotation remains feasible because the wrapping key protecting the derived data keys can be rotated independently, without re-encrypting stored values.
E
Use standard encryption and re-encrypt all data on rotation
Why it fails: Re-encrypting all data is costly and requires access to plaintext.

Full breakdown with real-world context →

Question 12hardmultiple choice

Read the full Explain encryption as a service explanation →

A security policy requires that encryption keys used in transit must never leave Vault's memory. However, development teams need to perform encryption offline in CI/CD pipelines. How can this be accomplished?

Trap 1: Use exportable keys and export them

Exporting keys would expose them outside Vault, violating policy.

Trap 2: Use Vault's transit encrypt with context

Encrypting via API still requires online access to Vault.

Trap 3: Use Vault's ciphertext rewrap

Rewrap requires the original ciphertext and does not provide offline encryption capability.

Study all Explain encryption as a service common traps →

A
Use exportable keys and export them
Why it fails: Exporting keys would expose them outside Vault, violating policy.
B
Use Vault's transit encrypt with context
Why it fails: Encrypting via API still requires online access to Vault.
C
Use Vault's ciphertext rewrap
Why it fails: Rewrap requires the original ciphertext and does not provide offline encryption capability.
D
Use Vault's datakey endpoint to get a wrapped key that can be unwrapped offline
The datakey endpoint returns a plaintext data key plus a wrapped copy encrypted by Vault's key. CI/CD pipelines decrypt locally using the plaintext key, while the wrapping key never leaves Vault's memory, satisfying the offline encryption constraint.
E
It is not possible; keys must stay in Vault
Why it fails: Datakey provides a solution that keeps the transit key secure.

Full breakdown with real-world context →

Question 13mediummultiple choice

Read the full Explain encryption as a service explanation →

A user receives an error 'invalid ciphertext' when trying to decrypt data. The ciphertext was created by another Vault instance. What is the most likely issue?

Trap 1: Different key names

A different key name would usually result in a permission error, not invalid ciphertext.

Trap 2: The Vault instance is sealed

A sealed Vault would return a seal error, not invalid ciphertext.

Trap 3: Different key types

Key type mismatch might cause errors during encryption, but decryption with wrong key type would likely also say invalid ciphertext? Actually it might, but version mismatch is more common.

Study all Explain encryption as a service common traps →

A
Different key names
Why it fails: A different key name would usually result in a permission error, not invalid ciphertext.
B
The Vault instance is sealed
Why it fails: A sealed Vault would return a seal error, not invalid ciphertext.
C
Different key types
Why it fails: Key type mismatch might cause errors during encryption, but decryption with wrong key type would likely also say invalid ciphertext? Actually it might, but version mismatch is more common.
D
The ciphertext includes key version info that doesn't match
Vault's transit secrets engine embeds the key version in the ciphertext prefix, so decryption requires that exact version to exist in the receiving instance. Because the ciphertext originated from a different Vault cluster, its version reference cannot be resolved locally, producing the 'invalid ciphertext' error.
E
The user lacks permissions to decrypt
Why it fails: Permission errors are explicit, not 'invalid ciphertext'.

Full breakdown with real-world context →

Question 14easymultiple choice

Read the full Explain encryption as a service explanation →

Which Vault API path is used to encrypt data with the transit engine?

Trap 1: /v1/transit/enc/

Path uses 'enc' instead of 'encrypt'.

Trap 2: /v1/transit/encrypt/

Missing keyname in path.

Trap 3: /v1/transit/encryption/

Uses 'encryption' instead of 'encrypt'.

Study all Explain encryption as a service common traps →

A
/v1/transit/enc/
Why it fails: Path uses 'enc' instead of 'encrypt'.
B
/v1/transit/encrypt/
Why it fails: Missing keyname in path.
C
/v1/transit/encrypt/{keyname}
The transit secrets engine exposes encryption at `/v1/transit/encrypt/{keyname}`, where `{keyname}` identifies the named encryption key created within the engine. Plaintext is submitted in the request body and returned as ciphertext, with Vault handling key versioning and rotation internally, so the stem's requirement for the transit engine's encrypt path is met exactly.
D
/v1/transit/encryption/
Why it fails: Uses 'encryption' instead of 'encrypt'.
E
/v1/transit/encryption/{keyname}
Why it fails: Uses 'encryption' instead of 'encrypt'.

Full breakdown with real-world context →

Question 15hardmultiple choice

Read the full Explain encryption as a service explanation →

An organization wants to ensure that even Vault administrators cannot see the plaintext of data encrypted with the transit engine, but they want to use Vault for key management. What feature should be enabled?

Trap 1: Seal wrapping

Seal wrapping protects Vault's own barrier key material at rest, not tenant plaintext held by the transit engine. It is tempting as a hardening control, and it would be correct when securing the storage backend against offline disk compromise rather than restricting administrator visibility.

Trap 2: Convergent encryption

Convergent encryption is designed for deduplication by deriving the encryption key from the plaintext itself. It does not prevent Vault administrators from seeing the plaintext because the key is derived client-side and Vault still manages the storage; administrators could potentially access the key material or the encrypted data.

Trap 3: Key deletion prevention

Deletion prevention only blocks destruction of keys; administrators with policy access can still call decrypt and read plaintext. It is tempting as a data-protection control, and it would be correct when the requirement is retaining keys for compliance or preventing accidental or malicious removal.

Study all Explain encryption as a service common traps →

A
Seal wrapping
Why it fails: Seal wrapping protects Vault's own barrier key material at rest, not tenant plaintext held by the transit engine. It is tempting as a hardening control, and it would be correct when securing the storage backend against offline disk compromise rather than restricting administrator visibility.
B
Convergent encryption
Why it fails: Convergent encryption is designed for deduplication by deriving the encryption key from the plaintext itself. It does not prevent Vault administrators from seeing the plaintext because the key is derived client-side and Vault still manages the storage; administrators could potentially access the key material or the encrypted data.
C
Client-side encryption with datakey
Client-side encryption with a datakey allows the application to encrypt data locally using a key obtained from Vault. The plaintext key is never stored by Vault, so administrators cannot see the plaintext. This meets the requirement.
D
Key deletion prevention
Why it fails: Deletion prevention only blocks destruction of keys; administrators with policy access can still call decrypt and read plaintext. It is tempting as a data-protection control, and it would be correct when the requirement is retaining keys for compliance or preventing accidental or malicious removal.
E
Key derivation
Why it fails: Key derivation produces new keys from a base key for isolation between tenants or purposes; it does not prevent an administrator holding decrypt capability from recovering plaintext. It is tempting because it segments cryptographic material, and it would be correct when separate keys per application are needed.

Full breakdown with real-world context →

Question 16hardmulti select

Read the full Explain encryption as a service explanation →

An application uses transit encryption with convergent encryption enabled. Which THREE statements are true about convergent encryption? (Choose three.)

Trap 1: It requires a separate key for each context.

The same key can be used; context varies per encryption.

Trap 2: It is typically slower than non-convergent encryption.

Performance is similar; the overhead of nonce derivation is minimal.

Study all Explain encryption as a service common traps →

A
It requires a separate key for each context.
Why it fails: The same key can be used; context varies per encryption.
B
It produces the same ciphertext for the same plaintext and context.
Convergent encryption derives the nonce deterministically from the plaintext and context, so identical inputs always yield identical ciphertext. This deterministic output is the defining property that distinguishes it from standard transit encryption, which uses random nonces.
C
It is typically slower than non-convergent encryption.
Why it fails: Performance is similar; the overhead of nonce derivation is minimal.
D
It can be used for deduplication of encrypted data.
Convergent encryption derives the data encryption key from the plaintext itself, so identical plaintext blocks always yield identical ciphertext. This determinism lets the storage layer recognise and merge duplicate ciphertexts, directly satisfying the stem's deduplication requirement while transit encryption remains in force.
E
It uses a nonce that is derived from the plaintext.
Convergent encryption replaces the random nonce with one derived deterministically from the plaintext and context. This derivation is what forces identical plaintexts to produce identical ciphertext, distinguishing it from the randomised nonce used in standard transit encryption.

Full breakdown with real-world context →

Question 17hardmultiple choice

Read the full Explain encryption as a service explanation →

Refer to the exhibit. Based on this policy, which actions can the associated token perform? (Assume all paths exist.)

Exhibit

path "transit/keys/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "transit/encrypt/*" {
  capabilities = ["update"]
}
path "transit/decrypt/*" {
  capabilities = ["update"]
}

Trap 1: Only encrypt and decrypt data.

It has additional key management permissions.

Trap 2: Create and read keys, encrypt and decrypt data.

It also allows update and delete on keys.

Trap 3: Only manage keys, not encrypt/decrypt.

It also has encrypt/decrypt capabilities.

Study all Explain encryption as a service common traps →

A
Only encrypt and decrypt data.
Why it fails: It has additional key management permissions.
B
Create and read keys, encrypt and decrypt data.
Why it fails: It also allows update and delete on keys.
C
Only manage keys, not encrypt/decrypt.
Why it fails: It also has encrypt/decrypt capabilities.
D
Create keys only.
Why it fails: It has read, update, delete, and encrypt/decrypt as well.
E
Create, read, update, delete keys; encrypt and decrypt data.
The policy grants the token full capabilities across the keys path, permitting create, read, update and delete on keys, plus encrypt and decrypt on the datapath. All listed actions fall within those granted capabilities, so the token can perform every one.

Full breakdown with real-world context →

Question 18easymultiple choice

Read the full Explain encryption as a service explanation →

Refer to the exhibit. What does min_decryption_version = 1 indicate?

Exhibit

$ vault read transit/keys/my-key
Key                       Value
---                       -----
allow_plaintext_backup    false
deletion_allowed          false
derived                   false
exportable                false
keys                      map[1:...]
latest_version            2
min_available_version     0
min_decryption_version    1
min_encryption_version    0
name                      my-key
supports_encryption       true
supports_decryption       true
supports_derivation       true
supports_key_rotation     true
type                      aes256-gcm96

Trap 1: Data encrypted with version 1 can only be decrypted with version 1.

Higher versions can also decrypt if min_decryption_version ≤ version used.

Trap 2: Only data encrypted with version 1 or higher can be decrypted.

This is about decryption version, not encryption version.

Trap 3: All ciphertext must be rewrapped to version 1.

Rewrapping is not forced by this parameter.

Study all Explain encryption as a service common traps →

A
Data encrypted with version 1 can only be decrypted with version 1.
Why it fails: Higher versions can also decrypt if min_decryption_version ≤ version used.
B
Only data encrypted with version 1 or higher can be decrypted.
Why it fails: This is about decryption version, not encryption version.
C
Version 1 is the minimum version that can be used for decryption.
Setting `min_decryption_version = 1` on a key vault key permits decryption with any key version from 1 upward, blocking only version 0 or unversioned operations. It satisfies the stem's constraint by defining the lowest permitted decryption version, so version 1 becomes the floor for cryptographic use.
D
All ciphertext must be rewrapped to version 1.
Why it fails: Rewrapping is not forced by this parameter.
E
Version 1 keys are not allowed for decryption.
Why it fails: Version 1 is allowed; versions below 1 are not.

Full breakdown with real-world context →

Question 19hardmultiple choice

Read the full Explain encryption as a service explanation →

An organization uses the transit engine with key rotation. They want to ensure that data encrypted with an older key version can be decrypted by Vault, but only if the key has not been deleted. Which of the following must be true?

Trap 1: The key's `min_decryption_version` must be set to 1

Setting to 1 allows all versions, but this is not required; the default (0) allows all versions. More importantly, if the version is archived, it still won't decrypt.

Trap 2: The key must have the `allow_plaintext_backup` setting enabled

This setting is for backing up key material, not for decryption availability.

Trap 3: The key must have a `deletion_allowed` set to false

This prevents deletion of the entire key, but does not affect decryption of existing ciphertext.

Study all Explain encryption as a service common traps →

A
The key's `min_decryption_version` must be set to 1
Why it fails: Setting to 1 allows all versions, but this is not required; the default (0) allows all versions. More importantly, if the version is archived, it still won't decrypt.
B
The key must have the `allow_plaintext_backup` setting enabled
Why it fails: This setting is for backing up key material, not for decryption availability.
C
The key must have a `deletion_allowed` set to false
Why it fails: This prevents deletion of the entire key, but does not affect decryption of existing ciphertext.
D
The key's `latest_version` must be greater than 0
Why it fails: This is always true if key exists, but doesn't ensure older versions are available.
E
The key must not have been archived
Archived key versions are removed from the decryption set and cannot be used.

Full breakdown with real-world context →

Question 20easymultiple choice

Read the full Explain encryption as a service explanation →

A developer wants to encrypt data using Vault's transit engine but does not want to base64 encode the ciphertext after encryption. What is the recommended way to handle this?

Trap 1: Use the `/transit/encrypt` endpoint with `base64=false`

No such parameter exists.

Trap 2: Set the `plaintext` parameter to the raw bytes

The API expects base64-encoded input.

Trap 3: Use the `ciphertext` parameter

That would be for decryption.

Study all Explain encryption as a service common traps →

A
The ciphertext is always base64 encoded, so the client must decode it after receiving
Transit always returns ciphertext as a base64-encoded string prefixed with the key version, regardless of client preference. The engine offers no raw binary output, so the client must decode after receiving, satisfying the stem's constraint.
B
Use the `/transit/encrypt` endpoint with `base64=false`
Why it fails: No such parameter exists.
C
Set the `plaintext` parameter to the raw bytes
Why it fails: The API expects base64-encoded input.
D
Use the `ciphertext` parameter
Why it fails: That would be for decryption.
E
Use the `plaintext` parameter directly without base64 encoding
Why it fails: Input must be base64-encoded.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Explain encryption as a service sessions

Start a Explain encryption as a service only practice session

Every question in these sessions is drawn from the Explain encryption as a service domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Explain encryption as a service questions →Mixed VA-003 session

Frequently asked questions

What does the VA-003 exam test about Explain encryption as a service?: Be able to encrypt and decrypt via transit, generate and use datakeys for large files, and rotate keys with the correct endpoints. The critical point: transit never stores your plaintext, and rotation does not automatically re-encrypt existing data—use rewrap or datakeys.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Explain encryption as a service questions in a focused session?: Yes — the session launcher on this page draws every question from the Explain encryption as a service domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other VA-003 topics?: Use the topic links above to move to related areas, or go back to the VA-003 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the VA-003 exam covers. They are not copied from any real exam or dump site.

Explain encryption as a service only

10 questions 20 questions 30 questions 50 questions

Mixed VA-003 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All VA-003 questions Explain encryption as a service domain overview VA-003 exam guide

Exam traps to avoid

▸Trying to send multi-GB files directly to the transit encrypt endpoint instead of using envelope encryption with a datakey.
▸Assuming key rotation re-encrypts existing ciphertext; old versions remain decryptable unless min_decryption_version is raised.
▸Confusing transit (encryption as a service, no plaintext storage) with KV (stores secrets) or PKI (issues certificates).

Explain encryption as a service practice questions

What to know about Explain encryption as a service

Common Explain encryption as a service exam traps

Explain encryption as a service questions

A DevOps team uses Vault's transit engine to encrypt secrets in CI/CD pipelines. They report that encryption operations are failing with 'permission denied' errors. The team has a policy granting 'create' and 'update' capabilities on the transit key path. What is the most likely missing capability?

Which TWO capabilities are required in a Vault policy to allow a client to encrypt data using a key named 'app-key' in the transit engine? (Assume the key already exists.)

Which TWO statements are true about Vault's encryption as a service using the transit engine?

Which TWO statements correctly describe Vault's encryption as a service using the Transit secrets engine?

Drag and drop the steps to configure Vault's AWS secrets engine to generate IAM credentials into the correct order.

Match each Vault response wrapping feature to its description.

An application needs to encrypt credit card numbers. The encryption must be deterministic for indexing purposes but also support key rotation. Which approach should be used?

A security policy requires that encryption keys used in transit must never leave Vault's memory. However, development teams need to perform encryption offline in CI/CD pipelines. How can this be accomplished?

A user receives an error 'invalid ciphertext' when trying to decrypt data. The ciphertext was created by another Vault instance. What is the most likely issue?

Which Vault API path is used to encrypt data with the transit engine?

An organization wants to ensure that even Vault administrators cannot see the plaintext of data encrypted with the transit engine, but they want to use Vault for key management. What feature should be enabled?

An application uses transit encryption with convergent encryption enabled. Which THREE statements are true about convergent encryption? (Choose three.)

Refer to the exhibit. Based on this policy, which actions can the associated token perform? (Assume all paths exist.)

Exhibit

Refer to the exhibit. What does min_decryption_version = 1 indicate?

Exhibit

An organization uses the transit engine with key rotation. They want to ensure that data encrypted with an older key version can be decrypted by Vault, but only if the key has not been deleted. Which of the following must be true?

A developer wants to encrypt data using Vault's transit engine but does not want to base64 encode the ciphertext after encryption. What is the recommended way to handle this?

Track your progress over time

Start a Explain encryption as a service only practice session

Related VA-003 topic practice pages

Compare and configure secrets engines practice questions

Compare authentication methods practice questions

Create Vault policies practice questions

Assess Vault tokens practice questions

Manage Vault leases practice questions

Utilize Vault CLI and API practice questions