VA-003 Explain encryption as a service Practice Test 3 — 15 Questions

Question 1

An application needs to encrypt sensitive data before storing it in a database. The security team wants to use Vault's encryption as a service to avoid managing encryption keys. Which Vault secrets engine should they enable?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Transit. The Transit secrets engine is designed specifically for encryption as a service, allowing applications to encrypt and decrypt data without ever having direct access to the encryption keys. The keys are stored and managed entirely within Vault, which meets the security team's requirement to avoid managing encryption keys themselves.

Answer

AWS

Answer

KV v2

Answer

Consul

Answer

PKI

Question 2

A DevOps engineer is configuring Vault to encrypt data in transit for a microservice. They create a key in the transit engine and want to encrypt a base64-encoded plaintext. Which API path and operation should they use?

Accepted Answer

POST /v1/transit/encrypt/{key_name} with plaintext in payload. The Vault Transit Secrets Engine exposes a POST endpoint at `/v1/transit/encrypt/{key_name}` that accepts a JSON payload containing the `plaintext` field, which must be base64-encoded. This operation encrypts the provided plaintext using the named encryption key and returns the ciphertext. The POST method is required because the operation modifies state (encrypts data) and the plaintext is sent in the request body, not as a query parameter.

Answer

POST /v1/transit/encrypt/{key_name} with ciphertext in payload

Answer

GET /v1/transit/encrypt/{key_name} with query param

Answer

POST /v1/transit/sign/{key_name}

Answer

POST /v1/transit/hmac/{key_name}

Question 3

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?

Accepted Answer

The key must not have been archived. In Vault's transit engine, key rotation creates new key versions while preserving older ones. The ability to decrypt data encrypted with an older key version depends on whether that version is still available in the key's version history. Archiving a key removes all versions from the active key ring, making decryption of data encrypted with any version of that key impossible. Therefore, the key must not have been archived to allow decryption of data encrypted with an older key version, provided the key itself has not been deleted.

Answer

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

Answer

The key must have the `allow_plaintext_backup` setting enabled

Answer

The key must have a `deletion_allowed` set to false

Answer

The key's `latest_version` must be greater than 0

Question 4

An organization wants to encrypt sensitive fields in their database using Vault. They have multiple applications that need to encrypt different types of data. What approach should they take?

Accepted Answer

Create a separate transit key per application. The Vault Transit Secrets Engine provides encryption-as-a-service, allowing each application to have its own named encryption key. This ensures cryptographic isolation: if one key is compromised, only the data encrypted with that specific key is at risk. Using separate keys per application also simplifies key rotation and access control, as each application can only use its designated key.

Answer

Use the PKI engine to issue certificates for each application

Answer

Use the KV engine to store encryption keys

Answer

Use a single key for all applications to simplify management

Answer

Encrypt data in the database using a static key stored in Vault

Question 5

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?

Accepted Answer

The ciphertext is always base64 encoded, so the client must decode it after receiving. The Vault Transit Secrets Engine always returns ciphertext as a base64-encoded string, regardless of whether the input plaintext was base64-encoded or raw. The API specification requires the client to decode the base64 ciphertext after receiving it if the original plaintext was raw bytes. There is no parameter to disable base64 encoding of the ciphertext output.

Answer

Use the `/transit/encrypt` endpoint with `base64=false`

Answer

Set the `plaintext` parameter to the raw bytes

Answer

Use the `ciphertext` parameter

Answer

Use the `plaintext` parameter directly without base64 encoding

Question 6

A security engineer needs to ensure that if a key is compromised, previous ciphertext can be re-encrypted with a new key version without exposing the plaintext. Which Vault operation should they use?

Accepted Answer

Rewrap. The Rewrap operation in Vault allows a ciphertext to be decrypted with the current key version and re-encrypted with a new key version without exposing the plaintext to the caller. This ensures that if a key is compromised, previous ciphertext can be rotated to a new key version while maintaining data confidentiality.

Answer

Rotate

Answer

Encode

Answer

Transform

Answer

Rekey

Question 7

A compliance requirement states that encryption keys must be automatically rotated every 90 days. Which Vault feature can be used to enforce this?

Accepted Answer

Setting `auto_rotate` on the transit key. The Vault Transit Secrets Engine supports an `auto_rotate` parameter that can be set on a key to enforce automatic rotation every 90 days. When enabled, Vault automatically rotates the encryption key at the specified interval without manual intervention, directly meeting the compliance requirement for automated 90-day rotation.

Answer

Using Vault's cron-like scheduler

Answer

Periodic rotation using the transit engine's `min_decryption_version`

Answer

Key rotation schedule policy

Answer

Using a periodic token to call the rotate endpoint

Question 8

An application encrypts data using the transit engine and stores the ciphertext in a database. After a key rotation, the application can no longer decrypt the data. What is the most likely cause?

Accepted Answer

The `min_decryption_version` was set to a value higher than the old key version. The `min_decryption_version` parameter in Vault's transit engine specifies the minimum key version that can be used for decryption. After a key rotation, if this value is set higher than the old key version, the engine will refuse to decrypt data encrypted with that older version, even if the old key data is still present in the key ring. This is a common misconfiguration that leads to decryption failures post-rotation.

Answer

The ciphertext was generated with a different key

Answer

The token used for decryption has been revoked

Answer

The key was rotated and the old version was automatically deleted

Answer

The transit engine was disabled

Question 9

A developer wants to encrypt a string "hello" using Vault's transit engine. What must they send in the API request?

Accepted Answer

The plaintext "hello" as a base64 encoded string. E is correct because Vault's transit engine requires plaintext to be base64-encoded before encryption. The API endpoint expects the plaintext as a base64-encoded string in the `plaintext` field of the request body. This ensures binary-safe transmission and consistent encoding across different systems.

Answer

The ciphertext of "hello"

Answer

Both the key name and the ciphertext

Answer

A reference to the key

Answer

The plaintext "hello" in raw bytes

Question 10

Which TWO of the following are valid uses of the Vault transit secrets engine?

Accepted Answer

Signing arbitrary data for verification. The Vault transit secrets engine can sign arbitrary data using a managed key, allowing verification of the signature's authenticity without exposing the key. This is a core encryption-as-a-service feature, enabling data integrity and non-repudiation for external systems.

Answer

Generating random bytes for cryptographic salt

Answer

Exporting the encryption key for use outside Vault

Answer

Storing static secrets like API keys

Question 11

Which THREE of the following best practices should be followed when using Vault's encryption as a service with the transit engine?

Accepted Answer

Use a unique encryption key per application. Using a unique encryption key per application ensures cryptographic isolation: if one application's key is compromised, other applications' data remains secure. Vault's transit engine supports this by allowing you to create and manage multiple named keys, each with its own policy and rotation schedule, preventing cross-application data exposure.

Answer

Allow deletion of keys to clean up unused keys

Answer

Store the key name in the application code for easy access

Question 12

Which TWO of the following are benefits of using Vault's transit engine for encryption as a service?

Accepted Answer

Applications can encrypt/decrypt data without accessing the key material. Vault's transit engine enables applications to encrypt and decrypt data without ever having access to the underlying key material (Option B). Additionally, key rotation is handled centrally by Vault without any application downtime, as applications continue to use the same API calls and Vault manages the rotation transparently (Option E).

Answer

The encryption key is stored in the application's memory

Answer

Keys can be exported and used in external applications

Answer

Only the root token can manage keys

Question 13

Refer to the exhibit. A DevOps engineer runs `vault read -format=json transit/keys/mykey` and receives the output shown. A microservice attempts to decrypt data that was encrypted with version 1 of the key. Will the decryption succeed?

Accepted Answer

Yes, because min_decryption_version is 1, which allows decryption with version 1 and higher.. The `min_decryption_version` parameter in Vault's transit secrets engine specifies the lowest key version that can be used for decryption. In the exhibit, `min_decryption_version` is set to 1, meaning any version from 1 upward is allowed. Since the data was encrypted with version 1, decryption will succeed. This parameter does not block decryption with version 1; it only prevents decryption with versions lower than the specified value.

Answer

Yes, because min_decryption_version does not affect decryption.

Answer

No, because min_decryption_version is 1, so only version 2 and higher can decrypt.

Answer

No, because the data was encrypted with version 1 and min_decryption_version is 1, so decryption is blocked.

Question 14

Refer to the exhibit. An application token has the above policy. Which operation will fail?

Accepted Answer

Listing keys in the transit engine. The policy shown in the exhibit grants 'create', 'update', 'delete', and 'deny' capabilities on the transit engine, but it does not include a 'list' capability. In Vault's transit secrets engine, listing keys requires the 'list' capability on the engine path. Without it, the operation will fail due to insufficient permissions, even though other key management operations are allowed.

Answer

Rotating the key mykey

Answer

Decrypting data using the key mykey

Answer

Encrypting data using the key mykey

Answer

Deleting the key mykey

Question 15

Refer to the exhibit. A developer receives this error when attempting to decrypt data. What is the most likely cause?

Accepted Answer

The ciphertext provided is not valid base64. The error indicates that the ciphertext provided is not valid base64. Vault's transit engine expects ciphertext to be base64-encoded; if the input is malformed or not properly encoded, the decryption operation fails with this specific error. This is the most direct cause given the error message.

Answer

The ciphertext is encrypted with a different key

Answer

The Vault server is not configured with the transit engine

Answer

The key mykey does not exist

Answer

The token used does not have permission to decrypt