Courseiva

CCNA Explain encryption as a service Questions

41 questions · Explain encryption as a service · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

An application stores ciphertext produced by a Vault transit key named `orders` in a database. The security team rotates the key with `vault write -f transit/keys/orders/rotate`. After rotation, the application reports that decryption of previously stored records fails. The key was never deleted or reconfigured. What is the most likely cause?

A.The application must re-encrypt all existing records with the new key version before decryption is possible.
B.The application stripped or altered the `vault:vN:` version prefix from the stored ciphertext.
C.The application is decrypting with the wrong key name because rotation renamed the key.
D.Rotation automatically deletes the previous key version, so old ciphertext can never be decrypted.
AnswerB

Transit ciphertext carries a version prefix such as `vault:v1:`. Vault uses that prefix to select the correct historical key version during decryption. If the application trimmed, truncated, or otherwise modified the stored ciphertext, Vault cannot identify the version and decryption fails even though all key versions are still present.

Why this answer

Transit ciphertext embeds the key version in a prefix like `vault:v1:`, and Vault relies on that prefix to choose which key version decrypts the data. Rotation adds a new version without invalidating old ones, so decryption normally continues to work. When it fails after rotation while the key still exists, the prefix has usually been stripped or corrupted in storage, removing Vault's ability to identify the correct version.

Exam trap

The trap here is blaming rotation for breaking decryption, when the real issue is treating the version prefix as disposable metadata.

Practice this question →
2
MCQeasy

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?

A.AWS
B.KV v2
C.Consul
D.Transit
E.PKI
AnswerD

The transit secrets engine provides encryption as a service, performing cryptographic operations while Vault holds and manages the keys. This satisfies the team's requirement to avoid managing encryption keys themselves, since plaintext is submitted to Vault and ciphertext returned, with no key material ever exposed to the application.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between a secrets engine that stores secrets (KV v2) and one that processes cryptographic operations (Transit), leading candidates to mistakenly choose KV v2 because they think 'storing encrypted data' is the same as 'encrypting data'.

How to eliminate wrong answers

Option A is wrong because the AWS secrets engine is used to generate dynamic AWS credentials (access keys), not to perform encryption operations. Option B is wrong because KV v2 is a key-value store for static secrets, not an encryption engine; it stores data as-is without providing encrypt/decrypt API endpoints. Option C is wrong because the Consul secrets engine generates Consul API tokens for service mesh access, not encryption services.

Option E is wrong because the PKI secrets engine generates X.509 certificates for TLS/SSL, not for encrypting arbitrary data.

Practice this question →
3
Multi-Selectmedium

A platform team is standardizing on the transit secrets engine for application-level encryption and wants to understand what the engine can and cannot do before rollout. Which TWO statements accurately describe transit engine behavior? (Choose two.)

Select 2 answers
A.The engine can generate a data key that returns both a plaintext key and a wrapped copy, so the caller may encrypt large payloads locally.
B.Deleting a transit key immediately makes all ciphertext ever produced with it permanently undecryptable in every deployment mode.
C.The engine stores the plaintext payloads it encrypts so that administrators can audit what data was protected.
D.Ciphertext produced by the encrypt endpoint includes the key version, so data encrypted before a rotation can still be decrypted afterward.
E.Encrypting the same plaintext twice with the same key always yields identical ciphertext, which is required for indexing.
AnswersA, D

The datakey endpoint returns a newly generated key in both plaintext and ciphertext-wrapped forms. The caller uses the plaintext to encrypt a large payload locally and stores the wrapped form alongside it, later asking Vault to decrypt the wrapped key. This pattern suits data too large to send through the encrypt endpoint efficiently.

Why this answer

Transit ciphertext carries a key version so rotation does not break decryption of existing data, and the datakey endpoint supports envelope encryption for payloads too large for the encrypt endpoint. The engine deliberately does not store plaintext or ciphertext, and its default encryption is randomized rather than deterministic, so the claims about audit retention and identical ciphertext do not hold.

Exam trap

The trap here is assuming transit encryption is deterministic by default, when identical plaintext normally produces different ciphertext unless convergent encryption is explicitly enabled.

Practice this question →
4
Multi-Selecthard

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

Select 2 answers
A.The encryption key is stored in the application's memory
B.Applications can encrypt/decrypt data without accessing the key material
C.Keys can be exported and used in external applications
D.Only the root token can manage keys
E.Key rotation is handled centrally without downtime
AnswersB, E

Transit performs cryptographic operations server-side, so applications submit plaintext or ciphertext and receive the result; the key material never leaves Vault. This satisfies the stem's benefit by removing key exposure from application memory, config files and host compromise.

Why this answer

Option B is correct because Vault's transit engine performs cryptographic operations on behalf of the client: the application sends plaintext (or ciphertext) to Vault's encrypt/decrypt endpoints, and Vault returns the result, so the application never handles or even sees the underlying key material. Option E is correct because the transit engine supports centralized key management, including key rotation via the `rotate` endpoint, which creates a new key version while retaining old versions for decryption, allowing rotation without application changes or downtime. Option A is incorrect because the whole point of the transit engine is that the key never leaves Vault's storage and is not held in application memory.

Option C is incorrect because transit keys are non-exportable by design (exportable keys must be explicitly enabled and are generally discouraged). Option D is incorrect because key management in the transit engine is governed by Vault policies and tokens with appropriate capabilities, not restricted solely to the root token.

Exam trap

HashiCorp often tests the misconception that 'encryption as a service' requires exporting keys to applications, but the transit engine's core benefit is that applications never touch the key material, ensuring centralized control and security.

Practice this question →
5
MCQhard

A security team encrypts records with a transit key and stores the resulting ciphertext. Months later they rotate the key several times. An application now needs to read old records, and the team also wants future writes to use only the newest key version without breaking decryption of the legacy rows. What is the accurate behavior of the transit engine in this situation?

A.Decryption of old ciphertext fails after rotation, so every stored record must be re-encrypted with the new key version.
B.The application must call the rewrap endpoint on every stored record before any decryption can succeed after a rotation.
C.Old ciphertext decrypts normally because the version prefix selects the correct key version, and new encrypt calls automatically use the latest version.
D.Rotation deletes older key versions by default, so only ciphertext produced after the most recent rotation can be decrypted.
AnswerC

The transit engine prefixes ciphertext with the key version, so decryption looks up the matching retained version automatically. After rotation, the newest version becomes the default for new encrypt operations, meaning legacy rows stay readable while fresh writes use the rotated key. This is the designed rotation model and requires no application-side version tracking.

Why this answer

Transit ciphertext carries its key version, and Vault keeps prior versions available for decryption by default. Rotation therefore changes which version new encryptions use while leaving existing data readable. Rewrapping is an optional forward-migration step, not a requirement, and rotation does not purge older versions.

Exam trap

The trap here is believing that rotating a key makes previously encrypted data undecryptable, when version retention is specifically designed to prevent that outcome.

Practice this question →
6
MCQeasy

A developer wants to encrypt data using Vault's transit engine with a key named 'payment-key'. The key already exists and is set to allow encryption. Which API path should the developer use to encrypt the data?

A.POST /v1/transit/decrypt/payment-key
B.POST /v1/transit/rewrap/payment-key
C.POST /v1/transit/keys/payment-key
D.POST /v1/transit/encrypt/payment-key
AnswerD

Vault's transit engine exposes encryption at /v1/transit/encrypt/<key-name>, so the named key 'payment-key' is appended as the final path segment. A POST to that endpoint submits plaintext and returns ciphertext, matching the existing key's encryption-allowed configuration.

Why this answer

The Vault transit engine exposes the `/v1/transit/encrypt/<key_name>` endpoint for encrypting plaintext data using a named encryption key. Since the key 'payment-key' already exists and is allowed to encrypt, a POST request to this path will perform the encryption operation and return the ciphertext.

Exam trap

HashiCorp often tests the distinction between key management endpoints (like `/keys/`) and cryptographic operation endpoints (like `/encrypt/`), trapping candidates who confuse managing the key with using the key to encrypt data.

How to eliminate wrong answers

Option A is wrong because `/v1/transit/decrypt/payment-key` is used for decryption, not encryption; it would attempt to reverse the encryption process. Option B is wrong because `/v1/transit/rewrap/payment-key` is used to re-encrypt existing ciphertext under a new version of the key, not to encrypt new plaintext. Option C is wrong because `/v1/transit/keys/payment-key` is used to manage the key itself (e.g., read configuration, rotate, or delete), not to perform cryptographic operations on data.

Practice this question →
7
MCQeasy

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

A.The ciphertext of "hello"
B.Both the key name and the ciphertext
C.A reference to the key
D.The plaintext "hello" in raw bytes
E.The plaintext "hello" as a base64 encoded string
AnswerE

The transit engine's encrypt endpoint requires the plaintext field to be base64-encoded, since the API transports binary-safe data. Sending the raw string "hello" is rejected; the base64 form is mandatory for the request to succeed.

Why this answer

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.

Exam trap

HashiCorp often tests the requirement for base64 encoding of plaintext in transit engine operations, trapping candidates who assume raw bytes or ciphertext are acceptable inputs.

How to eliminate wrong answers

Option A is wrong because sending ciphertext would be for decryption, not encryption; the transit engine encrypts plaintext, not ciphertext. Option B is wrong because the key name is required, but ciphertext is not sent for encryption—only plaintext is provided. Option C is wrong because a reference to the key is insufficient; the actual plaintext data must be included in the request.

Option D is wrong because raw bytes are not accepted; Vault requires base64 encoding to avoid issues with binary data in JSON.

Practice this question →
8
MCQmedium

An application stores user profile documents in a database and must encrypt field values with Vault's transit engine. A reviewer notes that anyone with the application's token could still send arbitrary ciphertext to the decrypt endpoint and read the result. The team wants to limit blast radius if the token leaks. Which transit engine capability best reduces this risk?

A.Set a short TTL on the transit key so it expires and can no longer decrypt.
B.Rely on the audit log to detect misuse after the fact and alert on decrypt calls from unexpected tokens.
C.Use a Vault policy that grants only 'encrypt' capability on the key path, and issue decrypt rights to a separate, more tightly scoped identity.
D.Enable 'exportable=true' so the team can move the key to a hardware security module and remove it from Vault.
AnswerC

Transit capabilities are separated by endpoint, so a policy can allow 'encrypt' on the key's encrypt path while denying decrypt entirely. If the application's token leaks, the attacker can only produce ciphertext, not recover plaintext. Splitting decryption to a distinct identity with its own policy enforces least privilege and directly shrinks the blast radius.

Why this answer

The transit engine authorizes each endpoint path independently, so a token can be given encrypt-only rights. That means a leaked application token cannot decrypt stored ciphertext, and decryption can be reserved for a separate identity. Exporting keys or relying on post-hoc auditing does not prevent the misuse the reviewer described.

Exam trap

The trap here is treating audit logging as a preventive control, when it only records activity after a token has already succeeded in decrypting data.

Practice this question →
9
MCQeasy

A DevOps team needs to encrypt sensitive configuration data before storing it in a version control system. They want to use Vault's encryption as a service to encrypt the data using a named encryption key. Which Vault path should they use to perform the encryption?

A.POST /v1/transit/encrypt/my-key
B.POST /v1/transit/sign/my-key
C.POST /v1/transit/hmac/my-key
D.POST /v1/transit/random
E.POST /v1/transit/decrypt/my-key
AnswerA

Vault's transit secrets engine exposes encryption as a service under the transit/ path, and the encrypt endpoint takes the key name as a path parameter. POST /v1/transit/encrypt/my-key submits plaintext to the named key my-key and returns ciphertext, satisfying the named-key requirement.

Why this answer

The correct path for encrypting data using Vault's encryption-as-a-service is POST /v1/transit/encrypt/my-key. The Transit secrets engine provides encryption as a service, and the /encrypt endpoint is specifically designed to encrypt plaintext data using a named encryption key. The key name 'my-key' in the path identifies which key in the Transit engine should be used for the encryption operation.

Exam trap

HashiCorp often tests the distinction between encryption (/encrypt), signing (/sign), and HMAC (/hmac) endpoints, and candidates frequently confuse the purpose of /encrypt with /sign or /hmac because all three involve cryptographic operations on data.

How to eliminate wrong answers

Option B is wrong because POST /v1/transit/sign/my-key is used for cryptographic signing (creating digital signatures), not encryption. Option C is wrong because POST /v1/transit/hmac/my-key is used to generate an HMAC hash for data integrity verification, not encryption. Option D is wrong because POST /v1/transit/random generates random bytes from the Vault's entropy source, not encryption of user-provided data.

Option E is wrong because POST /v1/transit/decrypt/my-key is the decryption endpoint, which reverses the encryption operation but does not perform encryption itself.

Practice this question →
10
MCQmedium

A development team is building a microservices application that needs to encrypt sensitive customer data before storing it in a shared database. They want to minimize changes to their existing code and avoid managing encryption keys themselves. Which Vault feature should they use?

A.Vault's Database secrets engine
B.Vault's PKI secrets engine
C.Vault's Transit secrets engine
D.Vault's Key Management Secrets Engine
AnswerC

The transit secrets engine offers encryption as a service, so applications call Vault's API to encrypt and decrypt while Vault manages and protects the keys. This minimises code changes and removes the burden of key management, satisfying both stated constraints.

Why this answer

The Transit secrets engine is designed for encryption-as-a-service, allowing applications to encrypt data without exposing encryption keys to the application code. It performs encryption and decryption operations on the Vault server, so the development team can minimize code changes and avoid managing keys themselves.

Exam trap

The trap here is that candidates confuse the Key Management Secrets Engine (KMSE) with encryption-as-a-service, but KMSE only distributes keys to external KMS providers and does not perform server-side encryption operations, which is the core requirement for minimizing code changes.

How to eliminate wrong answers

Option A is wrong because the Database secrets engine is used to dynamically generate database credentials, not to encrypt data. Option B is wrong because the PKI secrets engine generates X.509 certificates for TLS/SSL, not for encrypting arbitrary data. Option D is wrong because the Key Management Secrets Engine (KMSE) distributes encryption keys to external services like AWS KMS or Azure Key Vault, but still requires the application to manage the encryption operations, whereas the Transit secrets engine handles the cryptographic operations server-side.

Practice this question →
11
Multi-Selecthard

A platform team is designing an encryption-as-a-service layer with the transit secrets engine for several internal applications. They want to minimize the amount of sensitive data that reaches application memory and reduce the operational cost of rotating keys. Which TWO design choices align with how the transit engine is intended to be used? (Choose two.)

Select 2 answers
A.Export the transit key and distribute copies to each application so they can encrypt without any runtime dependency on Vault.
B.Have applications call the encrypt and decrypt endpoints so plaintext never leaves the application but key material never reaches it.
C.Disable key versioning on all keys so that rotation does not create new versions that applications must track.
D.Generate a data key with the datakey endpoint, encrypt the payload locally with it, and store the wrapped key alongside the ciphertext.
E.Store the plaintext data key in the application's configuration file so services can reuse it across restarts and avoid extra Vault calls.
AnswersB, D

This is the core encryption-as-a-service pattern: the application submits plaintext to Vault and receives ciphertext, so the key stays protected inside Vault while the application retains control of its data. It also centralizes audit logging and lets policies govern which callers can encrypt or decrypt, which is exactly what the engine is designed to support.

Why this answer

The transit engine supports two complementary patterns: direct encrypt/decrypt calls that keep keys inside Vault, and envelope encryption using the datakey endpoint so bulk data is encrypted locally with a wrapped key stored alongside it. Both minimize key exposure and make rotation manageable. Exporting keys, disabling versioning, or persisting plaintext data keys all undermine those goals.

Exam trap

The trap here is assuming that reducing Vault round-trips justifies exporting or persisting key material, when the datakey endpoint already provides a safe way to encrypt locally.

Practice this question →
12
Multi-Selectmedium

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.)

Select 2 answers
A.Enabling the transit engine requires Vault to be sealed and then unsealed before any key can be created.
B.The transit engine supports key rotation while retaining prior versions so previously produced ciphertext remains decryptable.
C.The transit engine stores plaintext copies of all encrypted data for audit and recovery purposes.
D.The transit engine can perform cryptographic operations on data without the caller ever receiving the encryption key.
E.Transit keys are exportable by default so applications can cache them locally for offline encryption.
AnswersB, D

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.

Why this answer

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.

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.

Practice this question →
13
Multi-Selecteasy

Which TWO are benefits of using Vault's encryption as a service?

Select 2 answers
A.Enables encryption of data at rest in cloud storage
B.Allows applications to delegate encryption/decryption to Vault without handling keys
C.Provides automatic key rotation and versioning
D.Eliminates the need for any network connectivity to Vault
E.Supports only symmetric key algorithms
AnswersB, C

Vault's transit secrets engine performs cryptographic operations server-side, so applications send plaintext to Vault and receive ciphertext back without ever holding key material. This satisfies the stem's delegation benefit: encryption and decryption are offloaded, keys remain centrally managed, and no application-side key handling or storage is required.

Why this answer

Option B is correct because Vault's Encryption as a Service (via the transit secrets engine) lets applications send plaintext to Vault's encrypt/decrypt endpoints and receive ciphertext or plaintext back, so the app never stores or manages the cryptographic keys itself. Option C is correct because the transit engine natively supports automatic key rotation and key versioning, allowing old ciphertext to remain decryptable while new data uses the latest key version. Option A is not a benefit specific to Encryption as a Service, since encrypting data at rest in cloud storage is typically handled by storage-level or disk encryption rather than Vault's transit engine.

Option D is wrong because applications must have network connectivity to reach Vault's API for encryption and decryption operations. Option E is wrong because the transit engine supports both symmetric algorithms (such as AES-GCM) and asymmetric algorithms (such as RSA and ECDSA).

Exam trap

HashiCorp often tests the misconception that encryption as a service is for encrypting cloud storage at rest, when in fact it is for application-level data encryption without key management exposure.

Practice this question →
14
MCQmedium

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?

A.Yes, because min_decryption_version does not affect decryption.
B.Yes, because min_decryption_version is 1, which allows decryption with version 1 and higher.
C.No, because min_decryption_version is 1, so only version 2 and higher can decrypt.
D.No, because the data was encrypted with version 1 and min_decryption_version is 1, so decryption is blocked.
AnswerB

The key's min_decryption_version of 1 sets the lowest version Vault will accept for decryption, and version 1 meets that floor. Since the version remains above the minimum and has not been deleted, Vault decrypts the ciphertext successfully.

Why this answer

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.

Exam trap

The trap here is that candidates often misinterpret `min_decryption_version` as a minimum version that is required (i.e., only versions above that number are allowed), when in fact it means the minimum version that is still permitted — so version 1 is allowed if the value is 1.

How to eliminate wrong answers

Option A is wrong because `min_decryption_version` does affect decryption — it explicitly controls which key versions are permitted for decryption operations. Option C is wrong because a `min_decryption_version` of 1 allows decryption with version 1 and higher, not only version 2 and higher. Option D is wrong because setting `min_decryption_version` to 1 does not block decryption with version 1; it actually permits it.

Practice this question →
15
MCQeasy

A developer is writing a microservice that must encrypt a small JSON payload using the transit secrets engine's 'orders' key, but the service must never be able to read the key material itself. Which API call should the service use to obtain ciphertext?

A.POST /v1/transit/encrypt/orders with the base64-encoded plaintext in the request body.
B.PUT /v1/transit/keys/orders with the plaintext in the request body to have Vault store and encrypt it.
C.GET /v1/transit/keys/orders to retrieve the key, then encrypt with it in application code.
D.POST /v1/transit/datakey/plaintext/orders to obtain a data key and encrypt the payload locally.
AnswerA

The encrypt endpoint is the standard encryption-as-a-service path: the service submits base64 plaintext, Vault performs the cryptographic operation using the protected key, and returns ciphertext prefixed with the key version. The caller never sees key material, and every operation is recorded in the audit log, satisfying the requirement exactly.

Why this answer

Encryption as a service means the application sends plaintext to Vault and receives ciphertext, while the key stays inside Vault's barrier. The encrypt endpoint on the named key is the only listed call that performs the operation server-side without exposing key material, and it records the operation for auditing.

Exam trap

The trap here is confusing the datakey endpoint with the encrypt endpoint, when datakey deliberately hands key material back to the caller for local use.

Practice this question →
16
MCQeasy

A DevOps team needs to encrypt large files (several GB) using Vault's transit engine. What is the recommended approach?

A.Use Vault's batch encryption
B.Use Vault's seal-wrapping feature
C.Use Vault's datakey endpoint to get a data encryption key, encrypt locally, then wrap with Vault
D.Encrypt the file directly with Vault's transit encrypt API
E.Split the file into chunks and encrypt each chunk via transit
AnswerC

The datakey endpoint returns a plaintext data key plus its wrapped form; encrypting locally avoids sending gigabytes through Vault, then storing the wrapped key. This satisfies the constraint of handling large files without exhausting Vault's transit bandwidth.

Why this answer

The transit engine is designed for encrypting small data payloads (typically a few KB), not multi-GB files. The recommended approach is to use the `/transit/datakey/plaintext` endpoint to generate a data encryption key (DEK), encrypt the large file locally with that DEK using a symmetric algorithm like AES-256-GCM, and then wrap (encrypt) the DEK with Vault using the transit engine. This keeps the large file out of Vault while still leveraging Vault for key management and audit logging.

Exam trap

HashiCorp often tests the misconception that Vault's transit engine can handle large payloads directly, leading candidates to choose Option D, but the actual limitation is that transit encrypt/decrypt operations are designed for small data (e.g., database fields, tokens) and envelope encryption is required for large files.

How to eliminate wrong answers

Option A is wrong because Vault does not have a 'batch encryption' feature; batch operations in Vault refer to token or request batching, not encryption. Option B is wrong because seal-wrapping is a mechanism to protect Vault's own master key or unseal keys, not a method for encrypting application data. Option D is wrong because the transit encrypt API has a payload size limit (typically 512 KB or less depending on the backend) and is not designed for multi-GB files.

Option E is wrong because splitting a file into chunks and encrypting each via transit would still require sending each chunk to Vault, incurring massive network overhead and hitting payload limits, making it impractical.

Practice this question →
17
MCQeasy

What is the primary purpose of the Vault transit secrets engine?

A.Encryption and decryption as a service
B.Token generation
C.Certificate management
D.Dynamic database credentials
E.Secure storage of secrets
AnswerA

The transit secrets engine performs cryptographic operations on data in transit without storing it, so Vault handles encryption and decryption as a centralised service. Keys remain inside Vault, satisfying the requirement that applications never handle raw key material directly.

Why this answer

The Vault transit secrets engine is designed to provide encryption and decryption as a service, allowing applications to encrypt and decrypt data without managing cryptographic keys directly. It offloads the cryptographic operations to Vault, which securely stores and rotates the encryption keys, ensuring that plaintext data never leaves the application unencrypted. This enables centralized key management and policy-based access control for encryption operations.

Exam trap

HashiCorp often tests the distinction between 'encryption as a service' (transit engine) and 'secure storage of secrets' (KV engine), leading candidates to mistakenly choose Option E because they conflate encrypting data at rest with storing secrets.

How to eliminate wrong answers

Option B is wrong because token generation is the primary function of Vault's token authentication method or the token helper, not the transit secrets engine. Option C is wrong because certificate management is handled by the Vault PKI secrets engine, which issues and manages X.509 certificates, not the transit engine. Option D is wrong because dynamic database credentials are provided by the database secrets engine, which generates temporary credentials for databases, not encryption services.

Option E is wrong because secure storage of secrets is the core purpose of Vault's generic KV (Key-Value) secrets engine or the overall Vault platform, while the transit engine specifically focuses on cryptographic operations.

Practice this question →
18
MCQeasy

An application team needs to encrypt short-lived session tokens before writing them to a Redis cache. They want to avoid handling or storing encryption keys in the application and need the ability to decrypt tokens later without re-encrypting. Which Vault transit secrets engine operation should they use to protect the data at write time?

A.transit/hmac/<key_name>
B.transit/encrypt/<key_name>
C.transit/datakey/plaintext/<key_name>
D.transit/rewrap/<key_name>
AnswerB

The transit encrypt endpoint accepts base64-encoded plaintext and returns ciphertext prefixed with vault:vN, never exposing the key material. This lets the application protect tokens without storing keys. The corresponding decrypt endpoint can later return the plaintext. This is the intended use of encryption as a service for data that must be recoverable.

Why this answer

Encryption as a service means Vault performs the cryptographic operation and returns ciphertext while keeping the key inside Vault. The transit encrypt endpoint is the direct way to protect plaintext so it can later be recovered with decrypt. Endpoints like datakey, rewrap, and hmac serve different purposes such as envelope encryption, key rotation, or integrity checking.

Exam trap

The trap here is assuming any transit endpoint can encrypt recoverable data, when datakey returns keys for local encryption and hmac is one-way.

Practice this question →
19
MCQhard

An application encrypts records with the transit engine and stores the ciphertext. A compliance requirement mandates rotating the encryption key every 90 days, but the existing records must remain readable and the application cannot be changed to re-encrypt them all at once. What should the operator do?

A.Rotate the key on schedule; existing ciphertext remains decryptable because old key versions are retained, and optionally rewrap records over time.
B.Export the key material, rotate it externally, then import the rotated key back so Vault can continue decrypting old records.
C.Create a brand-new transit key each quarter and update the application to reference the new key name for all reads and writes.
D.Delete the current key and recreate it with the same name so that the name stays stable while the underlying material changes.
AnswerA

Rotating a transit key creates a new version used for subsequent encryption while preserving earlier versions for decryption, so stored records stay readable with no application change. The rewrap endpoint can later migrate ciphertext to the newest version without exposing plaintext, letting the team satisfy the 90-day mandate incrementally rather than in a single bulk operation.

Why this answer

Rotating the existing transit key satisfies the 90-day requirement because encryption begins using a new key version while prior versions remain available for decryption, so existing records stay readable without application changes. Rewrap can then migrate stored ciphertext to the newest version at a controlled pace, avoiding a disruptive bulk re-encryption.

Exam trap

The trap here is creating a new key name to represent rotation, when true rotation keeps the same key name and adds a version so old ciphertext remains decryptable.

Practice this question →
20
MCQmedium

A financial services company uses HashiCorp Vault's transit engine to encrypt customer credit card numbers. The application sends each credit card number individually to Vault for encryption, and the response time is acceptable. However, during peak hours, the company needs to encrypt large batches of 10,000 credit card numbers. Users report that encrypting the entire batch takes several minutes, causing timeouts. The Vault cluster is healthy and not under high load. The security team wants to reduce the encryption time without changing the encryption algorithm or key strength. What should they do?

A.Enable key derivation on the transit key to allow parallel encryption.
B.Use the `batch_input` parameter to encrypt multiple plaintexts in one API call.
C.Enable convergent encryption to reuse ciphertexts.
D.Switch to an AES-256-GCM key for faster encryption.
AnswerB

The batch_input parameter lets the transit engine encrypt many plaintexts in a single API call, amortising network round trips and per-request overhead. This cuts the several-minute batch time without altering the encryption algorithm or key strength.

Why this answer

The `batch_input` parameter allows sending multiple plaintexts in a single API call to Vault's transit engine, significantly reducing the overhead of individual HTTP requests and TLS handshakes. This directly addresses the batch encryption timeout issue without changing the encryption algorithm or key strength, as the Vault cluster is healthy and not under load, indicating the bottleneck is network round-trips, not cryptographic computation.

Exam trap

The trap here is that candidates may confuse 'parallel encryption' (which Vault inherently supports via concurrent API calls) with reducing the number of API calls, or mistakenly think that changing the key type (Option D) or enabling convergent encryption (Option C) would improve performance, when the actual solution is batching input to minimize network overhead.

How to eliminate wrong answers

Option A is wrong because key derivation (enabled via `derived=true`) creates unique encryption keys per context but does not enable parallel encryption; Vault's transit engine already supports concurrent requests, and the bottleneck here is the number of API calls, not parallelism. Option C is wrong because convergent encryption reuses ciphertexts for identical plaintexts, which could reduce storage but does not speed up encryption of unique credit card numbers and may introduce security risks like frequency analysis. Option D is wrong because switching to AES-256-GCM (the default for transit keys) does not change the algorithm or key strength as per the requirement, and the issue is not cryptographic speed but API call overhead.

Practice this question →
21
MCQhard

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?

A.Rewrap
B.Rotate
C.Encode
D.Transform
E.Rekey
AnswerA

Rewrap decrypts ciphertext internally and re-encrypts it under the latest key version without returning plaintext to the caller. This satisfies the requirement to migrate ciphertext to a new key version after compromise while never exposing the underlying plaintext.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between key rotation (creating new key versions) and re-encrypting existing data (Rewrap), where candidates mistakenly choose Rotate thinking it automatically re-encrypts ciphertext.

How to eliminate wrong answers

Option B (Rotate) is wrong because Rotate creates a new key version but does not re-encrypt existing ciphertext; it only affects future encryption operations. Option C (Encode) is wrong because Encode is a generic data transformation (e.g., base64) and does not involve key management or re-encryption. Option D (Transform) is wrong because Transform applies a cryptographic function (e.g., tokenization, masking) but does not re-encrypt ciphertext under a new key version.

Option E (Rekey) is wrong because Rekey changes the master key or encryption key for the entire Vault cluster, not for individual ciphertexts, and does not provide a per-ciphertext re-encryption operation.

Practice this question →
22
MCQhard

A team wants to store encrypted backups in object storage and needs the ability to rotate the wrapping key over time without re-uploading every backup object. They also want the plaintext data key to be used only in memory by the backup agent. Which combination of Vault transit operations best fits this design?

A.Use transit/datakey/plaintext to obtain a data key, encrypt the backup locally, store the wrapped key alongside the object, and later use transit/rewrap on the wrapped key when rotating.
B.Use transit/encrypt on each backup and store only the returned ciphertext.
C.Use transit/sign to sign the backup, then store the signature as the encryption key.
D.Use transit/hmac to derive a key from the backup contents and store that digest with the object.
AnswerA

Datakey returns a plaintext key for local encryption plus a wrapped copy protected by the transit key. Storing the wrapped key with the object allows rewrap to update the wrapper without touching the large backup payload. This is the standard envelope encryption pattern and satisfies both rotation and in-memory key handling.

Why this answer

Envelope encryption keeps large payloads out of Vault: datakey supplies a plaintext data key plus a wrapped copy, the agent encrypts locally, and only the wrapped key is stored with the object. Rewrap then rotates the wrapper under a new transit key version without re-uploading data. This separates the bulk ciphertext from the key-protection layer and meets the in-memory requirement.

Exam trap

The trap here is sending whole objects through transit encrypt instead of using datakey to obtain a data key for local envelope encryption.

Practice this question →
23
Multi-Selectmedium

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

Select 3 answers
A.Allow deletion of keys to clean up unused keys
B.Use a unique encryption key per application
C.Enable key rotation automatically
D.Use encryption context to bind encrypted data to its intended use
E.Store the key name in the application code for easy access
AnswersB, C, D

Isolating each application to its own named transit key confines blast radius: a compromised app or leaked ciphertext cannot be decrypted using another app's key, and per-key rotation, policy scoping and audit trails stay independent rather than shared across tenants.

Why this answer

Option B is correct because using a unique encryption key per application enforces cryptographic isolation, so a compromise or policy change in one app's key cannot decrypt another app's data, and it simplifies access control and auditing in Vault's transit engine. Option C is correct because enabling automatic key rotation (via the transit engine's rotation period or `vault write -f transit/keys/<name>/rotate`) limits the amount of data protected by any single key version, supporting compliance requirements and reducing the blast radius if a key is exposed. Option D is correct because the transit engine's encryption context is a non-secret, authenticated value that is cryptographically bound to the ciphertext, so decryption fails unless the same context is supplied, preventing ciphertext from being reused in an unintended application or tenant context.

Option A is not a best practice because deleting transit keys is irreversible and destroys the ability to decrypt data encrypted with them, so keys should be disabled or rotated rather than deleted. Option E is not a best practice because hardcoding key names in application code reduces flexibility and complicates rotation, environment separation, and secret management; key references should come from configuration or a secrets manager.

Exam trap

HashiCorp often tests the misconception that key deletion is a safe cleanup practice, but in the transit engine, deletion is irreversible and can cause data loss, whereas disabling or archiving keys is the correct approach.

Practice this question →
24
MCQeasy

A developer needs to encrypt a short configuration string with the Vault transit secrets engine. The transit engine is mounted at `transit/` and a key named `app-config` has already been created. Which single CLI command correctly sends the plaintext to Vault for encryption?

A.vault write transit/app-config/encrypt plaintext=config.txt
B.vault write transit/encrypt/app-config plaintext=$(base64 -w0 config.txt)
C.vault encrypt transit/app-config plaintext=config.txt
D.vault write transit/encrypt/app-config plaintext=config.txt
AnswerB

The transit encrypt endpoint is `transit/encrypt/<key-name>`, and the `plaintext` parameter must be base64-encoded before it is submitted. Using `base64 -w0` produces a single-line base64 value suitable for the request, so this command reaches the correct key and supplies a valid payload.

Why this answer

The transit engine exposes encryption at `transit/encrypt/<key-name>`, and the payload's `plaintext` field must be base64-encoded. Supplying the correctly ordered path along with a base64-encoded value is what allows Vault to return a `ciphertext` field. The other candidates fail because they either misuse the CLI, reverse the path structure, or omit the required base64 encoding.

Exam trap

The trap here is forgetting that transit plaintext must be base64-encoded before it is sent, not passed as a raw string or filename.

Practice this question →
25
MCQmedium

A developer wants to encrypt a password before storing it in a database. The encryption must be deterministic so that the same plaintext always produces the same ciphertext. Which encryption mode should be used in the transit secrets engine?

A.chacha20-poly1305
B.convergent-encryption
C.aes128-gcm96
D.aes-gcm
E.padding
AnswerB

Convergent encryption derives the nonce from the plaintext and context, making output deterministic.

Why this answer

The transit secrets engine in Vault supports convergent encryption, which is a deterministic encryption mode where the same plaintext and context always produce the same ciphertext. This is achieved by using the plaintext itself as part of the encryption key derivation, ensuring repeatable output. The question specifically requires deterministic encryption, making convergent encryption the correct choice.

Exam trap

HashiCorp often tests the misconception that any AES-GCM mode is deterministic, but in practice, AES-GCM requires a unique nonce for each encryption, making it non-deterministic unless combined with convergent encryption or a fixed nonce (which would break security guarantees).

How to eliminate wrong answers

Option A is wrong because chacha20-poly1305 is an authenticated encryption algorithm, not a mode that provides deterministic output; it uses a nonce, so the same plaintext produces different ciphertexts each time. Option C is wrong because aes128-gcm96 is an AEAD algorithm that requires a unique nonce for each encryption, making it non-deterministic. Option D is wrong because aes-gcm is a generic algorithm that, without a fixed nonce, produces different ciphertexts for the same plaintext; Vault's transit engine does not support deterministic AES-GCM without convergent encryption.

Option E is wrong because padding is a data transformation technique, not an encryption mode, and does not provide deterministic encryption by itself.

Practice this question →
26
MCQmedium

A security architect is designing a service that uses the Vault transit engine to encrypt records. The architect wants to limit the blast radius if an application token is stolen. The application only ever writes new encrypted records and never needs to read them back. Which transit policy capability set should be granted to the application token?

A.encrypt only on the transit key path
B.read on the transit key path and encrypt capability
C.encrypt and decrypt on the transit key path
D.sudo on the transit key path
AnswerA

Restricting the token to encrypt means a stolen token can only produce new ciphertext, not reveal existing plaintext. This directly limits blast radius for a write-only application. Vault policies are capability based, so listing encrypt without decrypt on the key path enforces this separation cleanly.

Why this answer

Vault policies separate capabilities per path, so a write-only application should receive only encrypt on the specific transit key. Withholding decrypt means compromised credentials cannot expose stored plaintext. Least privilege for encryption as a service is expressed by granting exactly the capabilities the client needs on the narrowest path, rather than bundling decrypt or administrative capabilities.

Exam trap

The trap here is treating encrypt and decrypt as an inseparable pair, when Vault policies allow granting only encrypt for write-only clients.

Practice this question →
27
Multi-Selectmedium

A company uses Vault transit to encrypt secrets. They want to periodically rotate the encryption key to comply with compliance requirements. Which TWO actions should be taken? (Choose two.)

Select 2 answers
A.Update the min_decryption_version to the newest version immediately.
B.Export the key and re-encrypt all data manually.
C.Rewrap all existing ciphertext with the new key version.
D.Delete old key versions after rotation.
E.Rotate the key using Vault's key rotation endpoint.
AnswersC, E

Rewrapping re-encrypts existing ciphertext under the new key version without exposing plaintext, satisfying the compliance requirement that data previously encrypted with the retired version remains readable. Vault's `rewrap` endpoint decrypts with the old version and re-encrypts with the latest, so historical ciphertext stays accessible after rotation.

Why this answer

Option E is correct because Vault's transit secrets engine supports key rotation via the `rotate` endpoint (e.g., `vault write -f transit/keys/<key_name>/rotate`), which creates a new key version while retaining older versions for decrypting existing ciphertext. Option C is correct because after rotation, existing ciphertext still references older key versions, so `rewrap` (e.g., `vault write transit/rewrap/<key_name> ciphertext=<...>`) re-encrypts the data under the latest key version without exposing the plaintext, satisfying periodic rotation compliance. Option A is wrong because immediately setting `min_decryption_version` to the newest version would make ciphertext encrypted with older versions undecryptable, breaking access to existing data.

Option B is wrong because exporting the key defeats the purpose of Vault transit (keys never leave Vault) and manual re-encryption is unnecessary since `rewrap` handles it. Option D is wrong because deleting old key versions would render existing ciphertext undecryptable and is not required for rotation.

Exam trap

HashiCorp often tests the misconception that you must delete old key versions immediately after rotation, but the correct practice is to keep them until all ciphertext is rewrapped to avoid data loss.

Practice this question →
28
MCQhard

A platform team must let a batch job encrypt large files, up to several gigabytes each, using Vault transit. Sending entire files to Vault would exhaust request size limits and add latency. Which approach correctly uses the transit engine while keeping key material inside Vault?

A.Enable `exportable=true` on the transit key, export it, and use the exported key material to encrypt files locally.
B.Generate a data key with `transit/datakey/plaintext/<key>`, encrypt the file locally with that data key, and store the returned wrapped key alongside the ciphertext.
C.Use `transit/rewrap` to convert the plaintext file into ciphertext in a single call.
D.Call `transit/encrypt/<key>` once per file and pass the file bytes base64-encoded in the request body.
AnswerB

The `datakey` endpoint returns a high-entropy data key in plaintext and wrapped form. The application uses the plaintext data key locally for symmetric encryption of the file, then discards it and stores only the wrapped key. Because the wrapping key never leaves Vault, the data key can later be unwrapped via `transit/decrypt` to recover the file.

Why this answer

For large payloads, Vault recommends envelope encryption: the transit engine generates a data key, the application encrypts the file locally with that data key, and only the wrapped data key is stored or transmitted. The wrapping key remains inside Vault and is used later to unwrap the data key for decryption. Sending whole files to transit, exporting key material, or misusing rewrap all fail the size, security, or correctness requirements.

Exam trap

The trap here is treating the transit encrypt endpoint as a general-purpose file encryptor instead of recognizing that large data belongs in an envelope-encryption pattern.

Practice this question →
29
MCQhard

A security architect is designing a system where one microservice writes encrypted records and a separate reporting microservice reads them. The architect wants the writer to be unable to decrypt anything, while the reader can decrypt but cannot create new ciphertext. Which Vault policy design achieves this with the transit engine?

A.Grant both services a shared token with a policy allowing update on transit/encrypt/orders and transit/decrypt/orders.
B.Grant the writer update on transit/encrypt/orders and the reader update on transit/decrypt/orders.
C.Grant both services update on transit/keys/orders and let the application decide which operation to call.
D.Grant the writer read on transit/encrypt/orders and the reader read on transit/decrypt/orders.
AnswerB

Transit operations are authorized per endpoint path, so a policy granting update on transit/encrypt/orders lets the writer encrypt but not decrypt, and update on transit/decrypt/orders lets the reader decrypt but not encrypt. This creates the least-privilege split the architect wants, since neither identity can perform the other's operation on that key.

Why this answer

Transit authorizes each operation by path, so splitting update on the encrypt path for the writer and update on the decrypt path for the reader enforces the desired asymmetry. The writer can only produce ciphertext and the reader can only recover plaintext, neither gaining the other's ability. Managing keys or sharing a combined token would grant broader capability than the design intends.

Exam trap

The trap here is granting read instead of update on transit encrypt and decrypt paths, because these data operations are POST requests that require the update capability.

Practice this question →
30
MCQmedium

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?

A.The kv secrets engine storing the encryption key as a versioned secret so the application can retrieve and use it locally.
B.The pki secrets engine issuing client certificates so the application can establish its own TLS session and encrypt payloads.
C.The transit secrets engine's encrypt endpoint, where Vault performs the cryptographic operation and returns ciphertext to the caller.
D.Vault's key/value version 2 engine with response wrapping, which protects the key while it is delivered to the application.
AnswerC

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.

Why this answer

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.

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.

Practice this question →
31
MCQmedium

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?

A.Use the PKI engine to issue certificates for each application
B.Use the KV engine to store encryption keys
C.Create a separate transit key per application
D.Use a single key for all applications to simplify management
E.Encrypt data in the database using a static key stored in Vault
AnswerC

Separate transit keys per application enforce cryptographic isolation: each key's material and rotation schedule stay independent, so one application's compromise cannot decrypt another's ciphertext. This satisfies the stem's requirement that multiple applications encrypt different data types, since Vault's transit engine never exposes key material and supports per-key rotation and policy scoping.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between secret storage (KV engine) and encryption-as-a-service (Transit engine), leading candidates to incorrectly choose Option B because they confuse storing keys with performing encryption operations.

How to eliminate wrong answers

Option A is wrong because the PKI engine is used for issuing X.509 certificates for TLS/mTLS authentication, not for encrypting data fields in a database. Option B is wrong because the KV (Key-Value) engine is designed for static secret storage, not for performing encryption operations; it cannot encrypt data on demand. Option D is wrong because using a single key for all applications violates the principle of least privilege and creates a single point of failure; if that key is compromised, all encrypted data is exposed.

Option E is wrong because storing a static key in Vault and using it outside Vault for encryption defeats the purpose of Vault's encryption-as-a-service; the Transit engine should perform the encryption/decryption operations, not just store a key.

Practice this question →
32
MCQmedium

A security engineer is building an application that must encrypt records before writing them to an external SaaS ticketing system. The application must never receive or store the encryption key material, and the same plaintext must always produce the same ciphertext so records can be looked up by their encrypted value. Which transit engine configuration should be used?

A.Create a transit key with `derived=true` and supply a per-tenant context on every encrypt and decrypt call.
B.Create a standard transit key and call the `datakey` endpoint for every record before encrypting it.
C.Create a transit key with `type=aes256-gcm96` and set `exportable=true` so the application can perform its own encryption.
D.Create a transit key with `convergent_encryption=true` and enable `derived` so a context is required.
AnswerD

Convergent encryption makes identical plaintext produce identical ciphertext, which is exactly what enables lookup by encrypted value. Vault requires derived mode to be enabled when convergent encryption is used, and the supplied context scopes the convergence so different tenants do not collide. This combination meets both the deterministic and key-isolation requirements.

Why this answer

Deterministic ciphertext for lookup is provided by convergent encryption, and Vault requires derived mode to be enabled alongside it so that a context scopes the convergence. This keeps each tenant's converged values separate while still allowing exact-match searches on ciphertext. Derived mode without convergence, envelope data keys, or exportable keys all fail either the determinism requirement or the requirement that key material never leave Vault.

Exam trap

The trap here is assuming that derived mode alone produces deterministic ciphertext, when convergence is a separate setting that must also be enabled.

Practice this question →
33
MCQmedium

A platform team enables the transit engine and creates a key named orders. After several months the team rotates the key. A batch job that had stored ciphertext produced before the rotation now needs to read the original data. What must happen for the batch job to recover the plaintext?

A.The ciphertext must be decrypted using the old key version, which requires exporting that version first.
B.The batch job should call transit/decrypt with the ciphertext, and Vault will use the key version encoded in the ciphertext prefix.
C.The key must be rotated back to the previous version so the batch job can decrypt the stored ciphertext.
D.The batch job must first call transit/rewrap on each record to convert it to the new key version before decrypting.
AnswerB

Transit ciphertext carries a vault:vN prefix identifying the key version used. Decrypt reads that prefix and applies the matching retained version, so pre-rotation ciphertext still decrypts without any re-encryption. This is why rotation does not break existing data, and why decrypt alone is sufficient for the batch job.

Why this answer

Rotation in the transit engine adds a new key version while retaining older versions. Ciphertext records the version that produced it, and decrypt automatically selects the correct version. Applications therefore keep working across rotations without re-encrypting data, and rewrap is only needed when the goal is to migrate stored ciphertext to the newest version for policy or performance reasons.

Exam trap

The trap here is believing rotation invalidates old ciphertext or requires exporting keys, when Vault retains prior versions and reads the version from the ciphertext.

Practice this question →
34
MCQmedium

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?

A.POST /v1/transit/encrypt/{key_name} with ciphertext in payload
B.GET /v1/transit/encrypt/{key_name} with query param
C.POST /v1/transit/encrypt/{key_name} with plaintext in payload
D.POST /v1/transit/sign/{key_name}
E.POST /v1/transit/hmac/{key_name}
AnswerC

The transit engine's encrypt endpoint accepts a base64-encoded plaintext value in the JSON payload and returns the resulting ciphertext. POST to /v1/transit/encrypt/{key_name} is the documented path, satisfying the requirement to encrypt data using the named key.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between the input field names (`plaintext` vs `ciphertext`) and the correct HTTP method (POST vs GET) for state-changing operations, leading candidates to confuse the encrypt endpoint with the decrypt endpoint or to incorrectly assume a GET request can be used.

How to eliminate wrong answers

Option A is wrong because the payload should contain `plaintext`, not `ciphertext`; the ciphertext is the output of the encryption operation, not an input. Option B is wrong because the encrypt operation requires a POST request, not a GET; GET requests are idempotent and cannot carry a request body for the plaintext. Option D is wrong because `/v1/transit/sign/{key_name}` is used for digital signing, not encryption; it computes a signature over the input data.

Option E is wrong because `/v1/transit/hmac/{key_name}` is used for HMAC-based message authentication, not encryption; it produces a hash-based message authentication code.

Practice this question →
35
Multi-Selectmedium

Which THREE are appropriate use cases for Vault's Transit secrets engine?

Select 3 answers
A.Providing cryptographic offloading for applications running in untrusted environments
B.Generating and managing TLS certificates for internal services
C.Storing and retrieving static secrets like API keys
D.Performing signing and verification operations (e.g., for digital signatures)
E.Encrypting sensitive fields in a database without exposing encryption keys to the application
AnswersA, D, E

Vault's Transit secrets engine performs encryption and decryption operations centrally, so plaintext keys never leave Vault. Applications in untrusted environments send data to Vault for cryptographic processing, satisfying the offloading requirement without exposing key material locally. This directly addresses the constraint of operating where local key storage cannot be trusted.

Why this answer

Option A is correct because the Transit secrets engine performs encryption/decryption as a service, so applications in untrusted environments can offload cryptographic operations to Vault without ever handling or storing the encryption keys themselves. Option D is correct because Transit supports signing and verification operations, allowing Vault to hold the signing key while the application submits data to be signed or verified. Option E is correct because Transit's encrypt/decrypt endpoints let an application encrypt sensitive database fields while the key material remains inside Vault, so the application never sees the encryption key.

Option B is not a Transit use case; generating and managing TLS certificates is handled by the PKI secrets engine. Option C is not a Transit use case; storing and retrieving static secrets such as API keys is the role of the KV (Key/Value) secrets engine.

Exam trap

HashiCorp often tests the distinction between Transit (encryption as a service) and other secrets engines like PKI (certificates) and KV (static secrets), so candidates mistakenly associate Transit with any cryptographic task, including certificate management or secret storage.

Practice this question →
36
MCQhard

After rotating the 'payment-key', Vault successfully decrypts data encrypted with the old key (v1). What is the most likely reason the decryption succeeded?

A.The old key version is retained and used for decryption when the ciphertext references that version.
B.The old key version is automatically deleted after rotation, but the ciphertext contains the key version and is decrypted by the new key.
C.The ciphertext contains the original plaintext, so decryption simply extracts it.
D.The plaintext is stored in Vault during encryption, so decryption retrieves the stored plaintext.
AnswerA

Vault's key ring retains prior key versions after rotation. Ciphertext stores the version used at encryption, so decryption retrieves that retained version rather than the new key, which is why data encrypted under v1 still decrypts successfully.

Why this answer

A is correct because Vault uses key versioning: when a key is rotated, the old key version (v1) is retained for decryption purposes. The ciphertext includes metadata referencing the key version used for encryption, so Vault automatically selects the correct old key version to decrypt data encrypted before rotation. This ensures backward compatibility without re-encrypting existing data.

Exam trap

HashiCorp often tests the misconception that key rotation invalidates old ciphertext, but the trap here is that candidates assume the old key is deleted or replaced, when in fact Vault retains it for decryption based on ciphertext metadata.

How to eliminate wrong answers

Option B is wrong because Vault does not automatically delete the old key version after rotation; it retains it for decryption, and the new key cannot decrypt data encrypted with the old key due to different cryptographic material. Option C is wrong because ciphertext does not contain the original plaintext; it contains encrypted data that requires the correct key and algorithm to decrypt. Option D is wrong because Vault does not store plaintext during encryption; it only stores ciphertext and metadata, and decryption is a cryptographic operation, not a retrieval of stored plaintext.

Practice this question →
37
MCQmedium

Refer to the exhibit. What is the purpose of the -field=ciphertext flag in this command?

A.It sets the ciphertext field for encryption.
B.It enables field-level encryption.
C.It specifies the encryption key name.
D.It outputs the command result to a file named ciphertext.
E.It instructs Vault to only return the ciphertext field from the response.
AnswerE

The `-field=ciphertext` flag filters Vault's JSON response to return only the ciphertext value, suppressing metadata such as key version and lease details. This satisfies the scenario's requirement for extracting the encrypted payload directly, enabling clean scripting without parsing the full response structure.

Why this answer

The `-field=ciphertext` flag in a Vault command instructs the CLI to extract and return only the value of the `ciphertext` key from the JSON response object. This is a standard Vault output filtering mechanism that allows users to isolate a specific field without parsing the full response, which is especially useful in scripting and automation.

Exam trap

HashiCorp often tests the distinction between output filtering (`-field`) and actual encryption configuration, leading candidates to confuse the flag with setting encryption parameters or enabling field-level encryption.

How to eliminate wrong answers

Option A is wrong because the flag does not set or configure the ciphertext field for encryption; it filters the output to show only that field. Option B is wrong because field-level encryption is a separate concept involving encrypting individual data fields within a record, not a CLI output filter. Option C is wrong because the encryption key name is specified via a different parameter (e.g., `-key` or `key_name`), not the `-field` flag.

Option D is wrong because the `-field` flag does not redirect output to a file; file output is achieved with shell redirection (`>`) or the `-output` flag.

Practice this question →
38
MCQhard

A team has set up automatic key rotation on a transit key. After rotation, encrypted data that was encrypted with the previous key version can no longer be decrypted. What is the most likely cause?

A.The key was deleted
B.The key's min_decryption_version is set too high
C.The key's min_encryption_version is set too high
D.The team used the 'rewrap' operation incorrectly
E.The key is not exportable
AnswerB

Setting min_decryption_version above the previous key version's number causes the transit engine to refuse decryption with older versions. Vault retains old versions but enforces this floor, so raising it past the version that encrypted the data blocks access, matching the stem's post-rotation decryption failure.

Why this answer

The `min_decryption_version` setting on a transit key in Vault's transit secrets engine controls the minimum key version that can be used to decrypt ciphertext. If this value is set too high (e.g., to the current version), older key versions are effectively disabled for decryption, causing any data encrypted with a previous key version to become undecryptable. This is a common misconfiguration when automating key rotation without properly managing version policies in Vault.

Exam trap

Vault often tests the distinction between `min_encryption_version` and `min_decryption_version` in the transit engine, trapping candidates who confuse the two or assume that key rotation automatically invalidates old decryption capabilities.

How to eliminate wrong answers

Option A is wrong because deleting the key would make all data encrypted with any version of that key permanently undecryptable, not just data encrypted with the previous version. Option C is wrong because `min_encryption_version` controls which key version can be used for new encryption operations, not decryption of existing ciphertext. Option D is wrong because the `rewrap` operation (e.g., `ReEncrypt` in AWS KMS) is used to re-encrypt data under a new key version without exposing plaintext; using it incorrectly would not cause decryption failures for data encrypted with the previous version.

Option E is wrong because the exportability of a key affects whether the key material can be exported from the service, not whether ciphertext can be decrypted using the key versions stored within the service.

Practice this question →
39
Multi-Selectmedium

A security team is evaluating the Vault transit secrets engine as an encryption-as-a-service platform for several applications. They want to understand which capabilities the transit engine actually provides. (Choose two.)

Select 2 answers
A.It can validate the integrity of data by generating and verifying HMAC signatures.
B.It can perform cryptographic operations on data without persisting that data.
C.It can serve as a transparent proxy that encrypts traffic between microservices on the network.
D.It can generate and manage database credentials for PostgreSQL and MySQL.
E.It can dynamically issue X.509 certificates from an internal certificate authority.
AnswersA, B

Transit keys can produce HMACs through the `hmac` endpoint and verify them through `hmac/verify`, allowing applications to detect tampering without exposing key material. This supports integrity checks alongside encryption, which is a documented capability of the transit engine.

Why this answer

The transit engine provides cryptographic services over its API without persisting the data it processes, and it can generate and verify HMACs in addition to encrypting and decrypting. Dynamic database credentials, X.509 certificate issuance, and network traffic proxying belong to other secrets engines or external components, so they are outside the transit engine's scope.

Exam trap

The trap here is conflating the transit engine with other secrets engines, assuming it issues credentials or certificates because it lives inside the same Vault server.

Practice this question →
40
MCQeasy

An organization wants to encrypt data at rest in a cloud storage bucket. They plan to use Vault's transit engine to generate a data key and then encrypt the data locally. Which transit endpoint should they use to get a data key?

A.POST /v1/transit/datakey/plaintext/my-key
B.POST /v1/transit/encrypt/my-key
C.POST /v1/transit/decrypt/my-key
D.POST /v1/transit/datakey/ciphertext/my-key
AnswerA

The datakey endpoint returns a newly generated plaintext data key plus its wrapped ciphertext, letting the caller encrypt data locally while Vault retains the wrapping key. This satisfies the requirement to obtain a data key for local encryption.

Why this answer

The correct endpoint to retrieve a data key that can be used for local client-side encryption is POST /v1/transit/datakey/plaintext/my-key. This endpoint returns both the plaintext data key (for local encryption) and the ciphertext version of the key (for secure storage alongside the encrypted data). The 'plaintext' in the path indicates that the response includes the key in plaintext form, which is necessary for performing encryption locally.

Exam trap

HashiCorp often tests the distinction between 'datakey/plaintext' and 'datakey/ciphertext' endpoints, where candidates mistakenly choose the ciphertext-only endpoint thinking it provides the key for local encryption, but it actually omits the plaintext key required for that purpose.

How to eliminate wrong answers

Option B is wrong because POST /v1/transit/encrypt/my-key is used to encrypt an existing piece of data using Vault's transit engine, not to generate a new data key. Option C is wrong because POST /v1/transit/decrypt/my-key is used to decrypt ciphertext that was previously encrypted by the transit engine, not to generate a data key. Option D is wrong because POST /v1/transit/datakey/ciphertext/my-key returns only the ciphertext version of the data key, not the plaintext key needed for local encryption; this endpoint is used when the client only needs to store the key and does not need to perform local encryption.

Practice this question →
41
Multi-Selectmedium

Which THREE are valid operations in the Vault transit secrets engine? (Choose three.)

Select 3 answers
A.issue
B.revoke
C.rewrap
D.decrypt
E.encrypt
AnswersC, D, E

Rewrap decrypts ciphertext with an existing key version and re-encrypts it under the latest version, without exposing plaintext to the caller. This satisfies the stem's requirement for a valid transit operation, alongside encrypt and decrypt, by enabling key-version upgrades.

Why this answer

The Vault transit secrets engine is a cryptographic service that performs encryption/decryption operations on data in transit without storing the data itself, so option E (encrypt) is valid because it lets clients submit plaintext and receive ciphertext using a named encryption key, and option D (decrypt) is valid because it reverses that operation to recover plaintext from ciphertext. Option C (rewrap) is also valid: it decrypts ciphertext with an older key version and re-encrypts it with the latest key version in a single operation, which is useful for key rotation without exposing plaintext to the client. Options A (issue) and B (revoke) are not transit operations; issuing and revoking credentials are functions of secrets engines such as PKI (issue/revoke certificates) or the various dynamic secrets engines (e.g., database, AWS), not the transit engine, whose API endpoints are encrypt, decrypt, rewrap, datakey, hmac, sign, verify, and related key-management paths.

Exam trap

HashiCorp often tests candidates by mixing terms from different Vault secrets engines (e.g., PKI 'issue/revoke' with transit 'encrypt/decrypt') to see if you can distinguish the specific operations each engine supports.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Explain encryption as a service questions.

Start 20-question session