VA-003 Exam Questions and Answers

A DevOps team wants to authenticate to Vault using short-lived tokens without storing a secret in their CI/CD pipeline. Which authentication method best meets this requirement?

JWT/OIDC

Correct: JWT/OIDC allows token exchange without storing static secrets.

AWS IAM

AppRole

Username & Password

Why: JWT/OIDC authentication allows a DevOps pipeline to exchange a signed JSON Web Token (JWT) from an external identity provider (e.g., GitHub Actions, GitLab CI) for a short-lived Vault token. This eliminates the need to store a long-lived secret in the CI/CD pipeline because the JWT is dynamically generated by the CI platform and validated by Vault using the OIDC provider's public keys. The resulting Vault token has a configurable TTL, typically minutes, aligning with the requirement for short-lived credentials.

An organization uses Kubernetes pods to access Vault. They want to avoid hardcoding any secrets in the pod definition. Which authentication method should they use?

LDAP

Kubernetes

Kubernetes auth uses the pod's service account token, no hardcoded secrets.

Username & Password

AppRole

Why: The Kubernetes authentication method is correct because it allows pods to authenticate to Vault using their service account token, which is automatically mounted into the pod. This eliminates the need to hardcode any secrets in the pod definition, as Vault verifies the token against the Kubernetes API server and issues a temporary Vault token based on the pod's identity.

A security team notices that some Vault users are authenticating with the Userpass auth method, but they want to enforce password complexity and expiration. What is the best approach?

Migrate users to an external identity provider and use LDAP or OIDC auth.

External IDPs can enforce password policies; Vault can leverage them.

Switch to token-based authentication and issue tokens with TTL.

Use Vault's password policy plugin with Userpass.

Configure password policies in Vault's Userpass auth method.

Why: The Userpass auth method in Vault does not natively support password complexity or expiration policies. Migrating to an external identity provider (IdP) via LDAP or OIDC allows the organization to enforce these policies externally, where they are natively supported, and then federate authentication into Vault. This approach leverages the IdP's mature password management capabilities while maintaining Vault's authorization and audit controls.

A company has multiple AWS accounts and wants to allow EC2 instances to authenticate to Vault without storing any secrets on the instances. Which authentication method should they use?

OIDC

AWS

AWS auth uses instance metadata, no secrets stored.

TLS Certificates

AppRole

Why: Option B (AWS) is correct because the AWS authentication method in Vault allows EC2 instances to authenticate using their AWS instance identity documents and PKCS#7 signatures, without requiring any long-lived secrets to be stored on the instances. Vault verifies the instance's identity by calling the AWS EC2 API to validate the document and signature, then binds the instance to a Vault role. This eliminates the need to store tokens or credentials on the instance, meeting the requirement of secretless authentication.

An administrator configures AppRole with a RoleID and SecretID. They want to ensure that each SecretID can be used only once. Which configuration should they use?

Set token_num_uses=1 in the role.

Set bound_cidr_list to a specific IP.

Set secret_id_ttl=1s in the role.

Set secret_id_num_uses=1 in the role.

secret_id_num_uses limits the number of times a SecretID can be used.

Why: Option D is correct because setting `secret_id_num_uses=1` in the AppRole role configuration ensures that each SecretID can be used only once to obtain a token. Once the SecretID is used for login, it is automatically revoked and cannot be reused. This directly satisfies the requirement of single-use SecretIDs.

Which authentication method allows a user to authenticate using a one-time password (OTP) generated by an authenticator app?

Okta

Okta supports TOTP via the Okta API.

Userpass

GitHub

LDAP

Why: Okta supports Time-based One-Time Password (TOTP) as an authentication factor, which is the standard method used by authenticator apps like Google Authenticator or Microsoft Authenticator. TOTP generates a temporary code based on a shared secret and the current time, as defined in RFC 6238, and Okta's multifactor authentication (MFA) policies can require this OTP for user login. This makes Okta the correct choice for authenticating with an OTP from an authenticator app.

Want more Compare authentication methods practice?

All Assess Vault tokens questions

Domain 2: Assess Vault tokens

A DevOps team is using Vault tokens for authentication in CI/CD pipelines. They notice that tokens are often expired before the pipeline completes, causing failures. Which Vault feature should they use to address this without manual intervention?

Use batch tokens for better performance

Use periodic tokens with a short period and allow renewal

Periodic tokens can be renewed before expiration as long as they are within max TTL.

Create orphan tokens so they don't expire with the parent

Increase the default TTL on the token auth method

Why: Periodic tokens are designed for long-running processes like CI/CD pipelines. They have no maximum TTL and can be renewed indefinitely as long as the renewal occurs before the current token's TTL expires. By using a periodic token with a short period and enabling automatic renewal in the pipeline, the token stays valid without manual intervention, solving the expiration issue.

An application uses a Vault token with a policy that grants read access to secrets. The security team wants to ensure that if the application is compromised, the token cannot be used after a certain time even if the attacker has the token. What is the best approach?

Use a revocation script that runs periodically

Set explicit max TTL on the token

Use a periodic token with a long period

Set a short TTL on the token and do not allow renewal

A short TTL ensures the token expires quickly.

Why: Option D is correct because setting a short TTL on the token and disallowing renewal ensures that the token automatically expires after a fixed, short duration. Even if an attacker compromises the token, they cannot extend its lifetime, limiting the window of exposure. This directly meets the security requirement of preventing token use beyond a certain time without relying on external revocation mechanisms.

A developer created a token and wants to ensure that the token can only be used to read secrets from the 'secret/data/production' path. Which policy attachment approach should be used?

Set the token's metadata to restrict access

Use a root token and restrict its use via a policy

Create a policy with read capability on 'secret/data/production' and attach it to the token

Policies define access; attaching the policy grants the token those permissions.

Set the token type to service and it will automatically restrict access

Why: Option C is correct because Vault uses policies to define fine-grained access control, and the only way to restrict a token to read secrets from a specific path is to create a policy with the appropriate capabilities (e.g., 'read' on 'secret/data/production') and attach that policy to the token at creation time. Tokens themselves do not inherently carry path restrictions; they inherit permissions solely from attached policies.

A Vault administrator wants to allow a CI/CD pipeline to create short-lived tokens for deployment jobs. The pipeline itself authenticates with a periodic token. Which token type should the pipeline use to create tokens for jobs, considering the jobs need to be independent and not affected by the pipeline token's lifecycle?

Service tokens with explicit max TTL

Orphan tokens

Orphan tokens are not revoked when the parent expires.

Periodic tokens

Batch tokens

Why: Orphan tokens are the correct choice because they allow the CI/CD pipeline to create child tokens that are not tied to the parent token's lifecycle. When a periodic token creates an orphan token, the child token remains valid even if the parent token is revoked or expires, ensuring deployment jobs are independent and not affected by the pipeline token's lifecycle.

An organization uses Vault with AWS IAM auth. After rotating the AWS IAM role credentials, users are unable to authenticate with Vault. The Vault audit logs show 'permission denied' for the AWS auth method. What is the most likely cause?

The IAM role trust policy was not updated after credential rotation

The trust policy must allow the new credentials to assume the role.

The Vault token TTL expired

The client token used for AWS auth is revoked

The AWS secret engine is disabled

Why: When AWS IAM role credentials are rotated, the trust policy attached to the IAM role must be updated to reflect the new credentials (access key and secret key) that Vault uses to call the AWS STS API. If the trust policy still references the old credentials, Vault's AWS auth method cannot validate the login request, resulting in a 'permission denied' error in the audit logs. This is the most likely cause because the rotation directly breaks the trust relationship between Vault and AWS.

A Vault user wants to check the capabilities of their token on a specific path. Which command should they use?

vault token list

vault token capabilities <path>

This shows what actions the current token can perform on the path.

vault policy capabilities <policy_name> <path>

vault token lookup <token>

Why: The `vault token capabilities` command is specifically designed to check what operations (e.g., read, create, update, delete, list) a given token is allowed to perform on a particular path. It evaluates the token's attached policies against the path and returns the effective capabilities, making it the correct tool for this task.

Want more Assess Vault tokens practice?

All Create Vault policies questions

Domain 3: Create Vault policies

A company wants to grant developers the ability to read and write secrets under the path 'secret/dev/*', but only they should be able to delete their own secrets. Which policy design best meets this requirement?

path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] }

path "secret/dev/*" { capabilities = ["read", "list"] }

path "secret/dev/+/{{identity.entity.name}}" { capabilities = ["create", "read", "update", "delete"] }

path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/dev/{{identity.entity.name}}/*" { capabilities = ["delete"] }

Correctly grants full access to the dev path, but delete is only allowed on the user's own sub-path using entity name.

Why: Option D is correct because it grants full CRUDL access to 'secret/dev/*' for reading and writing, but then restricts delete to only the path 'secret/dev/{{identity.entity.name}}/*', which uses the entity's name to ensure developers can only delete secrets under their own sub-path. This leverages Vault's identity entity name templating to enforce per-developer delete scoping.

Which TWO of the following are valid capabilities that can be specified in a Vault policy?

create

'create' is a valid capability.

write

sudo

rename

update

'update' is a valid capability.

Why: In Vault policies, capabilities define the allowed actions on paths. The `create` capability permits creating new data at a path without needing to read existing data, which is distinct from `update` that allows modifying existing data. Both `create` and `update` are valid, separate capabilities in Vault's policy system.

A DevOps team is managing secrets for a microservices application using Vault. They have created a policy named 'app-policy' that grants read access to secrets under the path 'secret/data/app/*'. The policy is assigned to an AppRole role. When a service authenticates with the role ID and secret ID, it receives a token but is unable to read secrets from 'secret/data/app/db-creds'. The token's identity metadata shows the policies associated with the token include 'default' and 'app-policy'. The Vault server logs show no errors. The service can successfully read other secrets from the same path, like 'secret/data/app/config'. What is the most likely cause of the issue?

The secret 'secret/data/app/db-creds' does not exist in Vault.

Other secrets work, so this specific secret likely does not exist.

The token does not have the 'app-policy' policy attached due to a misconfiguration in the role.

There is an explicit deny rule in the policy that denies access to 'db-creds'.

The token is periodic and does not have the correct capabilities for the path.

Why: Option A is correct because the most likely cause is that the secret 'secret/data/app/db-creds' does not exist in Vault. The token has the 'app-policy' policy attached, which grants read access to 'secret/data/app/*', and the service can successfully read other secrets under that path (e.g., 'secret/data/app/config'). The absence of Vault server errors indicates that the policy is correctly evaluated and the path is valid, but a read on a non-existent secret returns a 404 (or a permission-denied-like response) without logging an error. The token's metadata confirms the policy is present, ruling out policy assignment issues.

A security team wants to ensure that all Vault policies for applications follow the principle of least privilege. They have a policy 'app-kv' that grants read access to secrets under 'secret/data/app/*'. An auditor finds that a developer can also read secrets under 'secret/data/team/*'. The policy currently uses a path-based glob. Which change should the team make to restrict access to only the app path?

Change the path to 'secret/data/app/+' and use 'list' capability.

Change the path to 'secret/data/app/*' and add 'deny' capability for other paths.

Keep the path as 'secret/data/app/*' but add a policy with path 'secret/data/team/*' and 'deny' capability.

Change the path to 'secret/data/app/' (without glob) and ensure the policy only grants 'read' capability.

Using a concrete path with trailing slash (or no glob) restricts to that specific path prefix only.

Why: Option D is correct because removing the glob and using an exact path 'secret/data/app/' restricts access to only that specific path. In Vault, a trailing slash without a glob matches exactly that path and its immediate children when used with the appropriate capabilities, enforcing least privilege without granting unintended access to other paths like 'secret/data/team/*'.

A DevOps team is writing a Vault policy for a CI/CD pipeline that needs to authenticate using AppRole, read specific secrets, and write dynamic database credentials. Which THREE capabilities should be included in the policy to meet these requirements? (Choose three.)

write

create

'create' is needed to generate new database credentials.

read

'read' is required to read secret data.

sudo

update

'update' is needed to rotate or modify database credentials.

Why: Option B (create) is correct because the CI/CD pipeline needs to write dynamic database credentials, which requires the 'create' capability on the database secrets engine path (e.g., database/creds/my-role). The 'create' capability allows generating new credentials from a role, which is distinct from simply updating existing secrets. Without 'create', the pipeline cannot request fresh credentials from the database backend.

Refer to the exhibit. A developer reports that they cannot read secrets under 'secret/data/kv-v2/engineering/db-pass' using a token that has the above policy attached. What is the most likely cause?

The policy requires the 'sudo' capability for reading secrets.

The secret does not exist because the path is incorrect.

The token does not have the policy attached.

The policy itself looks correct; the most likely cause is that the token was not assigned this policy.

The path uses a glob that does not match the exact secret path.

Why: Option C is correct because the policy shown in the exhibit defines a path with a glob pattern (`secret/data/kv-v2/engineering/*`), which matches the secret path `secret/data/kv-v2/engineering/db-pass`. However, the developer reports they cannot read the secret, indicating the token likely does not have this policy attached. In Vault, a token must have a policy explicitly attached to it; merely having the policy defined in Vault does not grant permissions unless the token is associated with that policy.

Want more Create Vault policies practice?

All Manage Vault leases questions

Domain 4: Manage Vault leases

A DevOps team is using Vault's database secrets engine to generate dynamic credentials for a PostgreSQL database. They notice that the lease duration is set to 24 hours, but security policy requires that credentials expire after 1 hour. What should the team do to enforce the 1-hour expiration without changing the default lease TTL for all secrets?

Set the mount's max_lease_ttl to 1h.

Ask each developer to set the TTL when requesting credentials.

Configure the role with a ttl of 1h.

The role-level ttl overrides the default lease TTL.

Use a periodic token with a period of 1h.

Why: Option C is correct because the database secrets engine allows role-level TTL configuration that overrides the default lease duration for credentials generated from that role. By setting the role's `ttl` to 1h, the team enforces a 1-hour expiration for credentials created under that specific role without affecting the default lease TTL for all secrets or other roles. This directly meets the security policy requirement while maintaining flexibility for other secrets.

An organization uses Vault to issue certificates via the PKI secrets engine. They have set the default lease TTL on the PKI mount to 72h, and the role's ttl to 24h. A user requests a certificate with a requested TTL of 48h. What will be the actual TTL of the issued certificate?

The request will be rejected because the requested TTL exceeds the role's ttl.

48h

24h

The role's ttl is the effective TTL when it is lower than the mount default.

72h

Why: The correct answer is C (24h) because when a certificate request is made, Vault applies the most restrictive TTL among the role's configured `ttl`, the mount's default lease TTL, and the requested TTL. Here, the role's `ttl` of 24h is the shortest, so it overrides both the requested 48h and the mount default of 72h, resulting in a certificate with a 24-hour validity.

Which TWO of the following actions can reduce the number of active leases in Vault? (Select two.)

Reducing the default lease TTL

Shorter TTLs cause leases to expire faster, reducing count.

Revoking a lease

Revocation removes the lease immediately.

Creating a new lease

Increasing the max lease TTL

Renewing a lease

Why: Reducing the default lease TTL (time-to-live) shortens the maximum duration for which a lease can be issued without renewal. When existing leases expire sooner, the system automatically removes them from the active lease count, thereby reducing the number of active leases. This directly affects the lease lifecycle by forcing earlier expiration.

A developer runs the commands shown in the exhibit. After renewing the lease, the lease_duration remains 1 hour. What is the most likely reason?

The lease is not renewable.

The mount's max_lease_ttl is set to 1h.

The developer does not have permission to renew the lease.

The role's max_ttl is set to 1h.

The role max_ttl caps the lease duration.

Why: Option D is correct because the role's max_ttl overrides the lease duration when it is shorter than the requested TTL. Even if the lease is renewed, the effective TTL cannot exceed the role's max_ttl, which is set to 1 hour. This is a common Vault behavior where the role's maximum TTL acts as a hard cap on lease lifetimes.

A company runs a microservices application on Kubernetes. Each service authenticates to Vault using the Kubernetes auth method and obtains a short-lived token with a TTL of 15 minutes. The services use these tokens to read secrets from the KV v2 secrets engine. Recently, the operations team noticed that Vault's lease count has been steadily increasing, and some services are experiencing 'lease not found' errors when trying to renew their tokens. Investigation reveals that the services are not renewing tokens before they expire because the token TTL is too short to complete some long-running tasks. The team wants to fix the issue without compromising security. They are considering the following actions:

A. Increase the default lease TTL for the KV v2 mount to 1 hour. B. Increase the token TTL for the Kubernetes auth role to 1 hour. C. Implement a renewal loop in each service to renew tokens every 10 minutes. D. Use periodic tokens with a period of 1 hour for all services.

Increase the default lease TTL for the KV v2 mount to 1 hour.

Increase the token TTL for the Kubernetes auth role to 1 hour.

Token TTL directly addresses the token expiration issue.

Implement a renewal loop in each service to renew tokens every 10 minutes.

Use periodic tokens with a period of 1 hour for all services.

Why: Option B is correct because increasing the token TTL for the Kubernetes auth role to 1 hour directly addresses the root cause: the current 15-minute TTL is too short for long-running tasks, causing tokens to expire before services can complete their work. By raising the TTL to 1 hour, services have sufficient time to complete tasks and renew tokens, while still maintaining security through short-lived credentials. This approach does not require code changes and leverages Vault's built-in token lifecycle management.

A DevOps team uses Vault dynamic secrets for database credentials with a lease of 1 hour. They notice that applications are making excessive calls to renew leases, causing performance issues. The team wants to reduce the renewal frequency while maintaining security. What is the best approach?

Increase the default lease TTL to 8 hours and configure periodic tokens with a short TTL.

A longer lease reduces renewal frequency, and periodic tokens ensure the overall lifetime is bounded.

Remove the TTL entirely so that credentials never expire.

Decrease the default lease TTL from 1 hour to 30 minutes.

Increase the maximum TTL for the role to 24 hours.

Why: Option A is correct because increasing the default lease TTL to 8 hours reduces the frequency of lease renewals, directly addressing the performance issue. Configuring periodic tokens with a short TTL ensures that the token itself still rotates frequently, maintaining security by limiting the window of exposure if a token is compromised. This balances reduced renewal overhead with strong security posture.

Want more Manage Vault leases practice?

All Compare and configure secrets engines questions

Domain 5: Compare and configure secrets engines

A DevOps team uses Vault to store database credentials via the database secrets engine. They notice that after the default lease duration, applications receive errors when trying to connect. The team wants to ensure that applications automatically renew leases before expiration. What should they do?

Schedule a cron job to periodically read new credentials.

Set a longer default TTL on the role.

Use Vault Agent to renew the secret.

Vault Agent can automatically renew leases and manage secrets lifecycle.

Set a longer max TTL on the mount.

Why: Option C is correct because Vault Agent is designed to automatically handle secret renewal and lifecycle management. It runs as a sidecar or daemon that periodically checks the lease duration and renews it before expiration, ensuring applications always have valid credentials without manual intervention or custom scripting.

A security team wants to store static secrets like API keys in Vault. They need the secrets to be versioned and support rollback. Which secrets engine should they use?

Cubbyhole

KV v1

Transit

KV v2

KV v2 supports versioning and rollback of secrets.

Why: KV v2 is the correct choice because it is designed specifically for storing static secrets with built-in versioning and rollback capabilities. Unlike KV v1, which overwrites data without preserving history, KV v2 retains a configurable number of secret versions, allowing administrators to undelete or roll back to a previous version using the `vault kv rollback` command or API calls.

An organization uses the AWS secrets engine to generate IAM users dynamically. They notice that the generated IAM user is not immediately available for use in AWS. What is the most likely reason?

The Vault write operation failed due to network latency.

The TTL on the role is too short.

Vault must wait for the AWS secret key to be rotated before returning the user.

AWS IAM is eventually consistent and the user may take a few seconds to propagate.

AWS IAM has eventual consistency, causing a short delay.

Why: Option D is correct because AWS IAM is an eventually consistent system. When Vault uses the AWS secrets engine to create an IAM user via the CreateUser API call, the user is not immediately available across all AWS services due to propagation delays. This eventual consistency means the generated IAM user may take a few seconds to be fully usable, which is a known behavior of AWS IAM.

A company is using the PKI secrets engine to issue certificates for internal services. They want to ensure that certificates are automatically revoked if a service is decommissioned. What should they implement?

Implement certificate pinning in all services.

Use Vault's built-in lifecycle management and revocation capabilities.

Vault can revoke certificates via API or when lease expires.

Set a very short TTL on certificates so they expire quickly.

Configure a Certificate Revocation List (CRL) that clients check.

Why: Option B is correct because Vault's PKI secrets engine includes built-in lifecycle management that can automatically revoke certificates when a lease expires or when a secret is deleted via the API. This allows you to tie certificate validity to the service's lifecycle in Vault, ensuring decommissioned services have their certificates revoked without manual intervention.

A developer wants to use Vault to encrypt sensitive data before storing it in a database. They need to perform encryption and decryption operations without ever exposing the encryption key. Which secrets engine should they use?

PKI

KV v2

Transit

Transit provides encryption as a service without exposing keys.

Database

Why: The Transit secrets engine is designed specifically for encryption-as-a-service workflows, allowing applications to encrypt and decrypt data using keys managed entirely within Vault. The encryption key never leaves Vault, satisfying the requirement to avoid exposing the key. In contrast, other engines like KV v2 store raw secrets but do not perform cryptographic operations without exposing the key material.

A company has multiple Vault clusters in different regions. They want to use the replication feature to synchronise secrets across clusters. However, they want to exclude a specific secrets engine from replication for compliance reasons. What should they do?

Create a separate Vault cluster for that secrets engine.

Disable replication on that specific mount.

Use disaster recovery (DR) replication and exclude the mount.

Use performance replication and configure a mount filter.

Performance replication supports mount filtering with path_filter.

Why: Performance replication in Vault allows you to replicate secret data across clusters while using mount filters to include or exclude specific secrets engines. This is the correct approach because mount filters are designed precisely for this use case, enabling selective replication to meet compliance requirements without creating separate infrastructure.

Want more Compare and configure secrets engines practice?

All Utilize Vault CLI and API questions

Domain 6: Utilize Vault CLI and API

A DevOps engineer needs to write a new secret to the KV v2 engine at path 'secret/data/team' with key 'api_key' and value 'abc123'. Which Vault CLI command achieves this?

vault kv put secret/data/team api_key=abc123

vault kv put secret/team api_key=abc123

Correct command; 'vault kv put' writes to KV v2 engine at the specified path (mount path is 'secret/', the secret is 'team').

vault write secret/data/team api_key=abc123

vault write secret/team api_key=abc123

Why: Option B is correct because the KV v2 engine automatically prefixes the path with 'data/' when using the 'vault kv put' command. The correct path for writing a secret to the KV v2 engine is 'secret/data/team', but the CLI command 'vault kv put secret/team api_key=abc123' handles this internally by appending '/data/' to the path. This is a key difference from the 'vault write' command, which requires the full path including 'data/'.

An admin wants to list all enabled authentication methods using the Vault API. Which curl command is correct?

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auths

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth

Correct; GET to /v1/sys/auth returns all enabled auth methods.

curl -X POST -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/auth

Why: Option B is correct because the Vault API endpoint to list all enabled authentication methods is a GET request to `/v1/sys/auth`. This endpoint returns a map of all enabled auth methods, and the command uses the correct HTTP method (GET) and the required `X-Vault-Token` header for authentication.

A user wants to log in using the userpass auth method with username 'jdoe' and password 'p@ssw0rd'. What is the correct API endpoint and request?

GET /v1/auth/userpass/login/jdoe with header "password: p@ssw0rd"

PUT /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}

POST /v1/auth/userpass/login/jdoe?password=p@ssw0rd

POST /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}

Correct; standard userpass login API call.

Why: The userpass auth method in Vault requires a POST request to the login endpoint with the password provided in the JSON body. Option D correctly uses POST /v1/auth/userpass/login/jdoe with {"password":"p@ssw0rd"}, which matches the Vault API specification for authenticating against a userpass backend.

A security team needs to create a token with a custom TTL of 1 hour and associate it with a policy named 'read-only'. Which Vault CLI command accomplishes this?

vault token create -policy=read-only -ttl=1h

Correct; vault token create creates a token with the specified policy and TTL.

vault write auth/token/create policies=read-only ttl=1h

vault token create -policy=read-only -ttl 1h

vault create token -policy=read-only -ttl=1h

Why: Option A is correct because `vault token create -policy=read-only -ttl=1h` uses the correct Vault CLI syntax for creating a token with a custom TTL and associating it with a policy. The `-policy` flag specifies the policy name, and `-ttl=1h` sets the time-to-live to 1 hour, which is the standard format for duration in Vault CLI commands.

An operator wants to enable the AWS auth method at the default path. Which curl command is correct?

curl -X POST -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws/

curl -X PUT -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws

curl -X POST -H "X-Vault-Token: s.abc" -d '{"method":"aws"}' https://vault:8200/v1/sys/auth/aws

curl -X POST -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws

Correct; POST to /v1/sys/auth/aws with type 'aws' enables the AWS auth method.

Why: Option D is correct because enabling an auth method at the default path requires a POST request to the `/v1/sys/auth/aws` endpoint with a JSON payload containing the `type` field set to `"aws"`. The POST method is used to create a new mount, and the trailing slash is optional but accepted. The `X-Vault-Token` header provides the necessary authentication token.

Which TWO of the following are valid methods to authenticate to Vault using the CLI?

vault auth -method=token token=s.abc

vault login -method=userpass username=jdoe

Valid; userpass authentication via CLI.

vault authenticate -method=userpass username=jdoe

Setting environment variable VAULT_AUTH=s.abc

vault login -method=ldap username=jdoe

Valid; LDAP authentication via CLI.

Why: Option B is correct because `vault login -method=userpass username=jdoe` is the valid CLI command to authenticate using the userpass auth method, which prompts for the password interactively. Option E is correct because `vault login -method=ldap username=jdoe` is the valid CLI command to authenticate using the LDAP auth method, also prompting for the password. Both commands follow the standard `vault login -method=<type>` syntax required by the Vault CLI.

Want more Utilize Vault CLI and API practice?

All Explain Vault architecture questions

Domain 7: Explain Vault architecture

A DevOps team is deploying Vault in a Kubernetes cluster. They want to ensure that when a pod starts, it can obtain a short-lived Vault token without human intervention. Which Vault architecture component should they use?

Audit Device

Storage Backend (Consul)

Vault Agent sidecar

Automatically authenticates and injects tokens into pods.

Vault CLI with token helper

Why: Option C is correct because the Vault Agent sidecar runs alongside the application container in the same pod, automatically authenticating to Vault and retrieving a short-lived token. This eliminates the need for human intervention by handling the authentication lifecycle (e.g., using Kubernetes auth method) and renewing or re-authenticating as needed, ensuring the application always has a valid token.

During a performance test, Vault becomes unresponsive for several seconds when the storage backend experiences high latency. Which architectural change would best improve Vault's resilience to storage latency?

Configure Performance Standby nodes

Offloads read operations and reduces load on the active node.

Add more storage backend nodes

Disable storage replication

Increase the number of Vault nodes without replication

Why: Performance Standby nodes are designed to handle read requests and can serve as hot standbys that take over active duty if the primary node becomes unresponsive due to storage backend latency. They maintain a local copy of the data via replication, allowing them to continue serving requests without waiting for the slow storage backend, thus improving resilience to high-latency storage conditions.

A security engineer wants to ensure that all requests to Vault are logged for compliance. Which component must be configured?

Secrets Engine

Storage Backend

Audit Device

Logs all requests to Vault.

Auth Method

Why: An audit device is the Vault component responsible for logging all requests and responses to a specified destination (e.g., syslog, file, socket). It must be enabled and configured to meet compliance requirements for recording every interaction with Vault. Without an audit device, Vault does not generate any persistent logs of API calls.

A company is using Vault's Integrated Storage (Raft) for high availability. During a network partition, two Vault nodes become isolated from the third. What happens to the isolated nodes?

The two isolated nodes continue to serve requests, the third stops

The two nodes have quorum; the isolated third does not.

All three nodes automatically rejoin after partition

All three nodes continue to serve requests

The two isolated nodes stop serving requests

Why: In Vault Integrated Storage (Raft), a quorum of nodes (majority) is required to maintain cluster leadership and serve requests. During a network partition where two nodes are isolated from the third, the two nodes form a majority (2 out of 3) and can continue to serve requests, while the isolated third node loses quorum and stops serving requests to prevent split-brain. This behavior is enforced by the Raft consensus algorithm, which requires a majority for any write or read operations to ensure consistency.

An administrator notices that after a Vault unseal operation, the root token is no longer usable. The audit logs show no revocations. What is the most likely cause?

The root token's TTL expired during unseal

The root token was revoked during unseal

The root token's policy was removed

The root token was stored in memory only and lost on seal

Root tokens are often not persisted; they are lost when Vault seals.

Why: When a Vault node is sealed, all in-memory data, including the root token, is wiped. The root token is not persisted to storage by default; it is only stored in memory after initialization or unseal. If the token was not explicitly persisted (e.g., via a recovery key or a generated token with a storage backend), it is lost upon seal, making it unusable after a subsequent unseal operation.

Which Vault component is responsible for encrypting data before storing it in the storage backend?

Storage Backend

Audit Device

Barrier

Encrypts all data before storage.

Secrets Engine

Why: The Barrier (also known as the Security Barrier) is the Vault component responsible for encrypting all data before it is written to the storage backend. It wraps every entry with encryption using the master key, ensuring that data at rest is never stored in plaintext. This is a core architectural layer that provides a cryptographic boundary between Vault's internal operations and the underlying storage.

Want more Explain Vault architecture practice?

All Explain encryption as a service questions

Domain 8: Explain encryption as a service

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?

Set up Vault replication from a central Vault to a local Vault instance.

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.

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

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

Why: Option B is correct because Vault Agent in sidecar mode runs alongside the application on the same host, handling encryption locally without requiring outbound HTTP requests. The encrypt stanza in the agent configuration allows it to proxy encryption operations to Vault's transit secrets engine, while the application communicates with the agent over a local loopback interface, bypassing network restrictions.

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?

The 'read' capability is missing.

The 'encrypt' capability is missing.

Encrypt capability is required for encryption operations.

The 'delete' capability is missing.

The 'list' capability is missing.

Why: The Vault transit engine uses distinct capabilities for key management versus data operations. 'Create' and 'update' allow managing the key itself (e.g., creating or rotating the key), but encryption of data requires the 'encrypt' capability on the transit key path. Without 'encrypt', the API call to encrypt data fails with a 'permission denied' error, even if the key exists and is properly configured.

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?

POST /v1/transit/decrypt/payment-key

POST /v1/transit/rewrap/payment-key

POST /v1/transit/keys/payment-key

POST /v1/transit/encrypt/payment-key

Correct path for encryption.

Why: Option D is correct because 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.

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?

POST /v1/transit/datakey/plaintext/my-key

Returns both plaintext and ciphertext data key.

POST /v1/transit/encrypt/my-key

POST /v1/transit/decrypt/my-key

POST /v1/transit/datakey/ciphertext/my-key

Why: 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.

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

read on /transit/keys/app-key

Required to read key metadata.

encrypt on /transit/encrypt/app-key

Required to perform encryption.

update on /transit/keys/app-key

create on /transit/keys/app-key

list on /transit/keys/app-key

Why: Option A is correct because the 'read' capability on the policy path `/transit/keys/app-key` is required for the client to retrieve the public key information or verify the key exists before encryption. Option B is correct because the 'encrypt' capability on the path `/transit/encrypt/app-key` is the specific permission needed to submit data to the transit engine's encryption endpoint, which uses the named key to perform the encryption operation.

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

Encryption keys cannot be rotated once created.

Data encrypted with a key can be decrypted with a later version of the same key if the key is rotated.

Old versions are kept for decryption.

The transit engine supports convergent encryption.

Convergent encryption is supported.

Vault stores the plaintext data for audit purposes.

Clients can provide their own key material when creating a key.

Supported via 'exportable' keys.

Why: Option B is correct because Vault's transit engine supports key rotation while maintaining the ability to decrypt data encrypted with previous key versions. When a key is rotated, Vault creates a new version of the key, but the old version is retained for decryption purposes. This allows clients to decrypt ciphertext that was encrypted with an earlier key version, ensuring data remains accessible after rotation.

Want more Explain encryption as a service practice?

Browse all VA-003 questions Take a timed practice test

Frequently asked questions

How many questions are on the VA-003 exam?

The VA-003 exam has 57 questions and must be completed in 60 minutes. The passing score is 700/1000.

What types of questions appear on the VA-003 exam?

Scenario-based questions covering exam objectives with detailed answer explanations.

How are VA-003 questions organised by domain?

The exam covers 8 domains: Compare authentication methods, Assess Vault tokens, Create Vault policies, Manage Vault leases, Compare and configure secrets engines, Utilize Vault CLI and API, Explain Vault architecture, Explain encryption as a service. Questions are weighted by domain — higher-weight domains appear more on your actual exam.

Are these the actual VA-003 exam questions?

No. These are original exam-style practice questions written against the official HashiCorp VA-003 exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.

Ready to practice all 57 VA-003 questions?

Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.

HashiCorp · Free Practice Questions · Last reviewed May 2026

VA-003 Exam Questions and Answers

48real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.

57 exam questions

60 min time limit

Pass: 700/1000 / 1000

8 exam domains

Overview Domain Blueprint Study Guide All QuestionsSample by Domain

Domain 1: Compare authentication methods

All Compare authentication methods questions

A DevOps team wants to authenticate to Vault using short-lived tokens without storing a secret in their CI/CD pipeline. Which authentication method best meets this requirement?

JWT/OIDC

Correct: JWT/OIDC allows token exchange without storing static secrets.

AWS IAM

AppRole

Username & Password

An organization uses Kubernetes pods to access Vault. They want to avoid hardcoding any secrets in the pod definition. Which authentication method should they use?

LDAP

Kubernetes

Kubernetes auth uses the pod's service account token, no hardcoded secrets.

Username & Password

AppRole

A security team notices that some Vault users are authenticating with the Userpass auth method, but they want to enforce password complexity and expiration. What is the best approach?

Migrate users to an external identity provider and use LDAP or OIDC auth.

External IDPs can enforce password policies; Vault can leverage them.

Switch to token-based authentication and issue tokens with TTL.

Use Vault's password policy plugin with Userpass.

Configure password policies in Vault's Userpass auth method.

A company has multiple AWS accounts and wants to allow EC2 instances to authenticate to Vault without storing any secrets on the instances. Which authentication method should they use?

OIDC

AWS

AWS auth uses instance metadata, no secrets stored.

TLS Certificates

AppRole

An administrator configures AppRole with a RoleID and SecretID. They want to ensure that each SecretID can be used only once. Which configuration should they use?

Set token_num_uses=1 in the role.

Set bound_cidr_list to a specific IP.

Set secret_id_ttl=1s in the role.

Set secret_id_num_uses=1 in the role.

secret_id_num_uses limits the number of times a SecretID can be used.

Which authentication method allows a user to authenticate using a one-time password (OTP) generated by an authenticator app?

Okta

Okta supports TOTP via the Okta API.

Userpass

GitHub

LDAP

Want more Compare authentication methods practice?

All Assess Vault tokens questions

Domain 2: Assess Vault tokens

Use batch tokens for better performance

Use periodic tokens with a short period and allow renewal

Periodic tokens can be renewed before expiration as long as they are within max TTL.

Create orphan tokens so they don't expire with the parent

Increase the default TTL on the token auth method

Use a revocation script that runs periodically

Set explicit max TTL on the token

Use a periodic token with a long period

Set a short TTL on the token and do not allow renewal

A short TTL ensures the token expires quickly.

A developer created a token and wants to ensure that the token can only be used to read secrets from the 'secret/data/production' path. Which policy attachment approach should be used?

Set the token's metadata to restrict access

Use a root token and restrict its use via a policy

Create a policy with read capability on 'secret/data/production' and attach it to the token

Policies define access; attaching the policy grants the token those permissions.

Set the token type to service and it will automatically restrict access

Service tokens with explicit max TTL

Orphan tokens

Orphan tokens are not revoked when the parent expires.

Periodic tokens

Batch tokens

The IAM role trust policy was not updated after credential rotation

The trust policy must allow the new credentials to assume the role.

The Vault token TTL expired

The client token used for AWS auth is revoked

The AWS secret engine is disabled

A Vault user wants to check the capabilities of their token on a specific path. Which command should they use?

vault token list

vault token capabilities <path>

This shows what actions the current token can perform on the path.

vault policy capabilities <policy_name> <path>

vault token lookup <token>

Want more Assess Vault tokens practice?

All Create Vault policies questions

Domain 3: Create Vault policies

path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] }

path "secret/dev/*" { capabilities = ["read", "list"] }

path "secret/dev/+/{{identity.entity.name}}" { capabilities = ["create", "read", "update", "delete"] }

path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/dev/{{identity.entity.name}}/*" { capabilities = ["delete"] }

Correctly grants full access to the dev path, but delete is only allowed on the user's own sub-path using entity name.

Which TWO of the following are valid capabilities that can be specified in a Vault policy?

create

'create' is a valid capability.

write

sudo

rename

update

'update' is a valid capability.

The secret 'secret/data/app/db-creds' does not exist in Vault.

Other secrets work, so this specific secret likely does not exist.

The token does not have the 'app-policy' policy attached due to a misconfiguration in the role.

There is an explicit deny rule in the policy that denies access to 'db-creds'.

The token is periodic and does not have the correct capabilities for the path.

Change the path to 'secret/data/app/+' and use 'list' capability.

Change the path to 'secret/data/app/*' and add 'deny' capability for other paths.

Keep the path as 'secret/data/app/*' but add a policy with path 'secret/data/team/*' and 'deny' capability.

Change the path to 'secret/data/app/' (without glob) and ensure the policy only grants 'read' capability.

Using a concrete path with trailing slash (or no glob) restricts to that specific path prefix only.

write

create

'create' is needed to generate new database credentials.

read

'read' is required to read secret data.

sudo

update

'update' is needed to rotate or modify database credentials.

Refer to the exhibit. A developer reports that they cannot read secrets under 'secret/data/kv-v2/engineering/db-pass' using a token that has the above policy attached. What is the most likely cause?

The policy requires the 'sudo' capability for reading secrets.

The secret does not exist because the path is incorrect.

The token does not have the policy attached.

The policy itself looks correct; the most likely cause is that the token was not assigned this policy.

The path uses a glob that does not match the exact secret path.

Want more Create Vault policies practice?

All Manage Vault leases questions

Domain 4: Manage Vault leases

Set the mount's max_lease_ttl to 1h.

Ask each developer to set the TTL when requesting credentials.

Configure the role with a ttl of 1h.

The role-level ttl overrides the default lease TTL.

Use a periodic token with a period of 1h.

The request will be rejected because the requested TTL exceeds the role's ttl.

48h

24h

The role's ttl is the effective TTL when it is lower than the mount default.

72h

Which TWO of the following actions can reduce the number of active leases in Vault? (Select two.)

Reducing the default lease TTL

Shorter TTLs cause leases to expire faster, reducing count.

Revoking a lease

Revocation removes the lease immediately.

Creating a new lease

Increasing the max lease TTL

Renewing a lease

A developer runs the commands shown in the exhibit. After renewing the lease, the lease_duration remains 1 hour. What is the most likely reason?

The lease is not renewable.

The mount's max_lease_ttl is set to 1h.

The developer does not have permission to renew the lease.

The role's max_ttl is set to 1h.

The role max_ttl caps the lease duration.

Increase the default lease TTL for the KV v2 mount to 1 hour.

Increase the token TTL for the Kubernetes auth role to 1 hour.

Token TTL directly addresses the token expiration issue.

Implement a renewal loop in each service to renew tokens every 10 minutes.

Use periodic tokens with a period of 1 hour for all services.

Increase the default lease TTL to 8 hours and configure periodic tokens with a short TTL.

A longer lease reduces renewal frequency, and periodic tokens ensure the overall lifetime is bounded.

Remove the TTL entirely so that credentials never expire.

Decrease the default lease TTL from 1 hour to 30 minutes.

Increase the maximum TTL for the role to 24 hours.

Want more Manage Vault leases practice?

All Compare and configure secrets engines questions

Domain 5: Compare and configure secrets engines

Schedule a cron job to periodically read new credentials.

Set a longer default TTL on the role.

Use Vault Agent to renew the secret.

Vault Agent can automatically renew leases and manage secrets lifecycle.

Set a longer max TTL on the mount.

A security team wants to store static secrets like API keys in Vault. They need the secrets to be versioned and support rollback. Which secrets engine should they use?

Cubbyhole

KV v1

Transit

KV v2

KV v2 supports versioning and rollback of secrets.

An organization uses the AWS secrets engine to generate IAM users dynamically. They notice that the generated IAM user is not immediately available for use in AWS. What is the most likely reason?

The Vault write operation failed due to network latency.

The TTL on the role is too short.

Vault must wait for the AWS secret key to be rotated before returning the user.

AWS IAM is eventually consistent and the user may take a few seconds to propagate.

AWS IAM has eventual consistency, causing a short delay.

Implement certificate pinning in all services.

Use Vault's built-in lifecycle management and revocation capabilities.

Vault can revoke certificates via API or when lease expires.

Set a very short TTL on certificates so they expire quickly.

Configure a Certificate Revocation List (CRL) that clients check.

PKI

KV v2

Transit

Transit provides encryption as a service without exposing keys.

Database

Create a separate Vault cluster for that secrets engine.

Disable replication on that specific mount.

Use disaster recovery (DR) replication and exclude the mount.

Use performance replication and configure a mount filter.

Performance replication supports mount filtering with path_filter.

Want more Compare and configure secrets engines practice?

All Utilize Vault CLI and API questions

Domain 6: Utilize Vault CLI and API

A DevOps engineer needs to write a new secret to the KV v2 engine at path 'secret/data/team' with key 'api_key' and value 'abc123'. Which Vault CLI command achieves this?

vault kv put secret/data/team api_key=abc123

vault kv put secret/team api_key=abc123

Correct command; 'vault kv put' writes to KV v2 engine at the specified path (mount path is 'secret/', the secret is 'team').

vault write secret/data/team api_key=abc123

vault write secret/team api_key=abc123

An admin wants to list all enabled authentication methods using the Vault API. Which curl command is correct?

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auths

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth

Correct; GET to /v1/sys/auth returns all enabled auth methods.

curl -X POST -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/auth

A user wants to log in using the userpass auth method with username 'jdoe' and password 'p@ssw0rd'. What is the correct API endpoint and request?

GET /v1/auth/userpass/login/jdoe with header "password: p@ssw0rd"

PUT /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}

POST /v1/auth/userpass/login/jdoe?password=p@ssw0rd

POST /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}

Correct; standard userpass login API call.

A security team needs to create a token with a custom TTL of 1 hour and associate it with a policy named 'read-only'. Which Vault CLI command accomplishes this?

vault token create -policy=read-only -ttl=1h

Correct; vault token create creates a token with the specified policy and TTL.

vault write auth/token/create policies=read-only ttl=1h

vault token create -policy=read-only -ttl 1h

vault create token -policy=read-only -ttl=1h

An operator wants to enable the AWS auth method at the default path. Which curl command is correct?

curl -X POST -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws/

curl -X PUT -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws

curl -X POST -H "X-Vault-Token: s.abc" -d '{"method":"aws"}' https://vault:8200/v1/sys/auth/aws

curl -X POST -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws

Correct; POST to /v1/sys/auth/aws with type 'aws' enables the AWS auth method.

Which TWO of the following are valid methods to authenticate to Vault using the CLI?

vault auth -method=token token=s.abc

vault login -method=userpass username=jdoe

Valid; userpass authentication via CLI.

vault authenticate -method=userpass username=jdoe

Setting environment variable VAULT_AUTH=s.abc

vault login -method=ldap username=jdoe

Valid; LDAP authentication via CLI.

Want more Utilize Vault CLI and API practice?

All Explain Vault architecture questions

Domain 7: Explain Vault architecture

Audit Device

Storage Backend (Consul)

Vault Agent sidecar

Automatically authenticates and injects tokens into pods.

Vault CLI with token helper

Configure Performance Standby nodes

Offloads read operations and reduces load on the active node.

Add more storage backend nodes

Disable storage replication

Increase the number of Vault nodes without replication

A security engineer wants to ensure that all requests to Vault are logged for compliance. Which component must be configured?

Secrets Engine

Storage Backend

Audit Device

Logs all requests to Vault.

Auth Method

A company is using Vault's Integrated Storage (Raft) for high availability. During a network partition, two Vault nodes become isolated from the third. What happens to the isolated nodes?

The two isolated nodes continue to serve requests, the third stops

The two nodes have quorum; the isolated third does not.

All three nodes automatically rejoin after partition

All three nodes continue to serve requests

The two isolated nodes stop serving requests

An administrator notices that after a Vault unseal operation, the root token is no longer usable. The audit logs show no revocations. What is the most likely cause?

The root token's TTL expired during unseal

The root token was revoked during unseal

The root token's policy was removed

The root token was stored in memory only and lost on seal

Root tokens are often not persisted; they are lost when Vault seals.

Which Vault component is responsible for encrypting data before storing it in the storage backend?

Storage Backend

Audit Device

Barrier

Encrypts all data before storage.

Secrets Engine

Want more Explain Vault architecture practice?

All Explain encryption as a service questions

Domain 8: Explain encryption as a service

Set up Vault replication from a central Vault to a local Vault instance.

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.

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

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

The 'read' capability is missing.

The 'encrypt' capability is missing.

Encrypt capability is required for encryption operations.

The 'delete' capability is missing.

The 'list' capability is missing.

POST /v1/transit/decrypt/payment-key

POST /v1/transit/rewrap/payment-key

POST /v1/transit/keys/payment-key

POST /v1/transit/encrypt/payment-key

Correct path for encryption.

POST /v1/transit/datakey/plaintext/my-key

Returns both plaintext and ciphertext data key.

POST /v1/transit/encrypt/my-key

POST /v1/transit/decrypt/my-key

POST /v1/transit/datakey/ciphertext/my-key

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

read on /transit/keys/app-key

Required to read key metadata.

encrypt on /transit/encrypt/app-key

Required to perform encryption.

update on /transit/keys/app-key

create on /transit/keys/app-key

list on /transit/keys/app-key

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

Encryption keys cannot be rotated once created.

Data encrypted with a key can be decrypted with a later version of the same key if the key is rotated.

Old versions are kept for decryption.

The transit engine supports convergent encryption.

Convergent encryption is supported.

Vault stores the plaintext data for audit purposes.

Clients can provide their own key material when creating a key.

Supported via 'exportable' keys.

Want more Explain encryption as a service practice?