HashiCorp · Free Practice Questions · Last reviewed May 2026
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.
12% of exam · 6 sample questions below
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 runs alongside the application, authenticating to Vault and automatically renewing the database credential lease before expiry, so connections no longer fail at the default lease duration. This satisfies the requirement for automatic renewal without embedding renewal logic in application code.
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 stores secrets under a versioned key structure, retaining configurable historical versions so any prior value can be retrieved or rolled back. This directly satisfies the stem's versioning and rollback requirements for static API keys, unlike dynamic engines that generate short-lived credentials and keep no version history.
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 uses eventually consistent replication across its infrastructure. A newly created IAM user or access key may not be usable for several seconds until that change propagates, so immediate authentication attempts can fail even though the credentials were generated successfully.
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
The transit secrets engine performs cryptographic operations in Vault itself, so plaintext keys never leave the server. Applications submit data for encryption or decryption and receive only the ciphertext or plaintext, satisfying the requirement to never expose the encryption key.
Database
Which TWO of the following are valid use cases for the Transit secrets engine? (Select exactly 2.)
Signing and verifying data
The Transit secrets engine performs cryptographic operations on data in transit without storing it, so signing and verifying data is a core capability. It satisfies the stem's requirement for a valid use case by handling signing and verification through named encryption keys, keeping plaintext outside Vault entirely.
Encrypting data in transit without exposing the encryption key
The Transit secrets engine performs cryptographic operations server-side, so applications submit plaintext to Vault and receive ciphertext back without ever handling the encryption key itself. This satisfies the stem's requirement for encryption without key exposure, enabling centralised key management, rotation and audit logging across distributed services.
Storing encryption keys
Storing encrypted data at rest
Managing X.509 certificates
Which THREE of the following are true about the KV v2 secrets engine? (Select exactly 3.)
It does not support deletion of secrets.
It supports check-and-set operations for concurrent updates.
KV v2 implements check-and-set semantics: writes supply a version number, and Vault rejects the write if the stored version differs, preventing lost updates. This satisfies the concurrency requirement by detecting conflicting concurrent modifications rather than silently overwriting them.
It does not support undoing changes.
It supports metadata like created_time and deletion_time.
KV v2 stores per-version metadata including created_time and deletion_time, alongside custom metadata and version numbers. This satisfies the requirement by allowing administrators to audit when each secret version was written or soft-deleted without reading the secret data itself.
It supports versioning of secrets.
KV v2 retains multiple versions of each secret, allowing retrieval of previous values and rollback after accidental overwrites or deletions. This satisfies the versioning requirement, distinguishing it from KV v1, which stores only the latest value with no history.
Want more Compare and configure secrets engines practice?
Practice this domain13% of exam · 6 sample questions below
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
JWT/OIDC auth has the CI/CD pipeline present its platform-issued identity token, which Vault validates against the provider's signing keys. The resulting Vault token is short-lived, so no static secret is stored in the pipeline, meeting the requirement.
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
Vault's Kubernetes auth method validates the pod's projected service account token against the Kubernetes TokenReview API, mapping it to a Vault role and policy. No static credentials are embedded in the pod definition, satisfying the no-hardcoded-secrets constraint.
Username & Password
AppRole
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
The AWS auth method uses the EC2 instance identity document and AWS IAM role credentials, obtained from the instance metadata service, to prove identity to Vault. No static secret is ever stored on the instance, satisfying the no-secrets-on-instances constraint across multiple accounts.
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.
Setting secret_id_num_uses=1 makes each SecretID valid for a single authentication attempt, so a captured SecretID cannot be replayed. This directly satisfies the stem's constraint that each SecretID be usable only once, unlike TTL settings which limit time rather than use count.
A Vault administrator wants to allow users to authenticate using their corporate Active Directory credentials. Which authentication method should they enable?
Okta
AppRole
Userpass
LDAP
LDAP binds Vault directly to Active Directory, letting users authenticate with their existing corporate domain credentials rather than separate Vault tokens. This satisfies the stem's requirement for Active Directory-backed authentication, since LDAP queries AD as the identity source. Microsoft Entra ID would not meet the on-premises AD constraint here.
A company uses Vault for secrets management. They want to authenticate using GitHub tokens, but only for users who are members of a specific GitHub team. What must be configured?
Vault validates the token's scope.
Users must generate a personal access token with repo scope.
The GitHub token must include the team scope.
Map the GitHub team to a Vault policy in the auth method configuration.
Mapping the GitHub team to a Vault policy in the auth method configuration satisfies the team-membership constraint: Vault's GitHub auth method reads the user's team memberships from the GitHub API and assigns the mapped policy, so only members of that specific team receive the token's permissions.
Want more Compare authentication methods practice?
Practice this domain13% of exam · 6 sample questions below
Drag and drop the steps to create and use a periodic service token in Vault into the correct order.
Create role, generate token, use token, renew periodically
This is the correct order because you must first define the role with periodic settings, then generate a token from that role, use the token for authentication, and renew it before expiration to maintain access.
Generate token, create role, use token, renew periodically
Create role, use token, renew periodically, generate token
Generate token, use token, renew periodically, create role
A security administrator wants to create a policy that allows a service to renew its own token and list its own token capabilities, but not create new tokens. Which policy statements should be included?
path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["read"] }
Renewing a token maps to the update capability on `auth/token/renew-self`, while listing capabilities requires read on `auth/token/capabilities-self`. Both paths are self-scoped, so the service acts only on its own token, satisfying the constraint that it must not create new tokens.
path "auth/token/renew-self" { capabilities = ["create"] }; path "auth/token/lookup-self" { capabilities = ["read"] }
path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["update"] }
path "auth/token/renew" { capabilities = ["update"] }; path "auth/token/capabilities" { capabilities = ["read"] }
A Vault policy must allow a service to read secrets from "secret/data/app" and also be able to renew its own token. Which two policy statements are necessary and sufficient for this requirement? (Select two.)
path "secret/data/app" { capabilities = ["read"] }
Grants read capability on the exact KV v2 data path, satisfying the secret-retrieval half of the requirement. Without this statement the service cannot fetch credentials, so it is necessary; the token-renewal half is covered separately by the renew-self path.
path "auth/token/renew-self" { capabilities = ["update"] }
Renewing one's own token requires the update capability on the auth/token/renew-self endpoint, which satisfies the stem's self-renewal requirement. This path is distinct from token creation or revocation endpoints, so it grants precisely the minimum privilege needed without broader token management rights.
path "auth/token/renew" { capabilities = ["update"] }
path "secret/data/app/*" { capabilities = ["read"] }
path "sys/auth" { capabilities = ["read"] }
Refer to the exhibit. A user with this policy attempts to read the secret at path "secret/data/team-a/admin". What will happen?
The read fails because the path does not exist.
The read succeeds because the first path grants read.
The read succeeds because deny only applies to write operations.
The read is denied because the deny policy takes precedence.
Vault evaluates all matching policies together, and any matching deny rule overrides grants regardless of specificity or order. The deny on that path therefore blocks the read even if another policy grants it, so access is refused.
Refer to the exhibit. A user with this policy tries to write a new secret to "secret/data/production/db". What will happen?
The write succeeds if the secret already exists.
The write succeeds because the path matches.
The write fails because the policy only allows read on production.
The policy grants only read capability on the production path, so any write operation is denied by Vault's default-deny posture. Creating a secret at "secret/data/production/db" requires create or update capability on that exact path, which the policy omits, causing the write to fail.
The write fails because the user does not have list capability.
An administrator wants to create a policy that grants the ability to list all authentication methods enabled on the Vault server. Which path and capability are required?
path "sys/auth" { capabilities = ["list"] }
Listing enabled auth methods queries the sys/auth endpoint, which enumerates mounted authentication backends. The list capability on that path is the minimum privilege required; read or sudo would not permit enumerating mounts, and other paths expose unrelated secrets.
path "sys/auth" { capabilities = ["read", "list"] }
path "sys/auth" { capabilities = ["read"] }
path "auth/*" { capabilities = ["list"] }
Want more Create Vault policies practice?
Practice this domain13% of exam · 6 sample questions below
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 are exempt from the standard max TTL: they carry no absolute expiry and can be renewed indefinitely, provided each renewal occurs within the period. This satisfies the stem's requirement for unattended pipelines, where long-running jobs outlive fixed-TTL tokens and no operator is present to re-authenticate.
Create orphan tokens so they don't expire with the parent
Increase the default TTL on the token auth method
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 with renewal disabled forces Vault to revoke the token automatically once it expires, so a stolen token becomes useless after that window regardless of attacker possession. This directly satisfies the requirement that compromise cannot extend token usability.
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
Attaching a policy granting only read capability on 'secret/data/production' to the token scopes its permissions to that exact path, satisfying the least-privilege constraint. Vault evaluates the token's attached policies, so no broader capability is inherited.
Set the token type to service and it will automatically restrict access
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 have no parent, so they survive independently of the pipeline token's expiry or revocation. This satisfies the requirement that job tokens remain unaffected by the pipeline token's lifecycle, unlike child tokens, which are revoked with their parent.
Periodic tokens
Batch tokens
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>
`vault token capabilities <path>` queries the token's effective capabilities on that exact path, returning a permission list such as read, create or sudo. It satisfies the stem's constraint of checking one token against one specific path, unlike `vault capabilities`, which inspects the calling token only.
vault policy capabilities <policy_name> <path>
vault token lookup <token>
A security analyst discovers that a token used by a legacy application is still active long after the application was decommissioned. Which Vault feature should have been used to automatically expire tokens when the application is no longer running?
Enable token renewal to keep it alive
Use a periodic token and revoke it manually
Set a TTL on the token
A token TTL enforces a maximum lifetime, after which Vault automatically revokes the token regardless of whether the legacy application still runs. This directly satisfies the requirement to expire credentials without manual intervention, closing the exposure window left when a decommissioned application's token remained active indefinitely.
Use a batch token to limit its lifetime
Want more Assess Vault tokens practice?
Practice this domain13% of exam · 6 sample questions below
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.
Setting a ttl of 1h on the specific database role overrides the engine's default lease TTL for credentials issued through that role only, enforcing the one-hour expiry without altering global defaults for other secrets or roles.
Use a periodic token with a period of 1h.
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
Vault caps the issued certificate's TTL at the smallest applicable value. The role's ttl of 24h overrides both the mount's 72h default and the requested 48h, so the certificate is issued with a 24h TTL.
72h
Which TWO of the following actions can reduce the number of active leases in Vault? (Select two.)
Reducing the default lease TTL
Leases expire when their TTL elapses, so lowering the default lease TTL causes leases to be revoked sooner and reduces how many remain active at any moment. This directly decreases the count of outstanding leases Vault must track.
Revoking a lease
Revoking a lease immediately invalidates it and removes it from Vault's active lease set, rather than waiting for TTL expiry. This directly decreases the number of active leases, satisfying the stem's requirement to reduce them.
Creating a new lease
Increasing the max lease TTL
Renewing a lease
An organization uses Vault's AWS secrets engine to generate temporary IAM credentials. The Vault administrator has set the default lease TTL on the AWS mount to 15 minutes. A developer creates a role with role TTL of 30 minutes and explicit max TTL of 1 hour. Which TWO statements are true regarding the lease behavior for credentials generated under this role?
The initial lease duration will be 30 minutes (the role TTL).
The role TTL overrides the mount's default lease TTL, so credentials issued under this role receive an initial lease of 30 minutes rather than the mount's 15-minute default. The explicit max TTL of 1 hour caps renewal, not the initial issuance, satisfying the stem's role-level TTL constraint.
The lease can be renewed up to a total lifetime of 1 hour (explicit max TTL).
Renewal is capped by the role's explicit max TTL, so credentials can be renewed repeatedly until total lifetime reaches 1 hour, then Vault revokes them. The 30-minute role TTL governs each individual lease, while the 15-minute mount default is overridden.
The lease can be renewed indefinitely up to the system max TTL.
The initial lease duration will be 15 minutes (the default lease TTL).
The lease duration is the minimum of default lease and role TTL.
Drag and drop the steps to configure Vault's audit logging to a file into the correct order.
Enable audit device, then perform operations to generate log entries, then verify the audit log.
This is the correct order because the audit device must be enabled first so that Vault can record operations. Then, performing operations generates log entries. Finally, verification checks that the logs are being written correctly.
Perform operations to generate log entries, then enable audit device, then verify the audit log.
Verify audit log, then enable audit device, then perform operations to generate log entries.
Enable audit device, then verify the audit log, then perform operations to generate log entries.
Match each Vault term to its definition.
Secret: A piece of sensitive data stored in Vault
Correct: A secret is any sensitive data like passwords or API keys stored in Vault.
Token: A credential used to authenticate to Vault
Correct: Tokens are the primary method of authentication to Vault.
Policy: A method used to authenticate a user or machine to Vault
Auth Method: A set of rules defining access permissions in Vault
Want more Manage Vault leases practice?
Practice this domain12% of exam · 6 sample questions below
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
Listing enabled auth methods requires a GET to the sys/auth endpoint with a valid X-Vault-Token header. This command supplies the token and targets the correct path, satisfying the requirement to enumerate all enabled authentication methods through the Vault API.
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"}
The userpass auth method exposes a login endpoint scoped to the specific username, so the credential travels in the JSON body rather than the path. POST /v1/auth/userpass/login/jdoe satisfies the stem's requirement to authenticate jdoe with the supplied password, returning a Vault token on success.
Which THREE of the following are correct about using the Vault API to read a secret from KV v2 engine?
The response JSON contains a 'data' key with the secret values
Correct; the secret data is nested under 'data.data'.
The HTTP method used is GET
Correct; reading a secret uses GET.
The API path is /v1/secret/mysecret
The HTTP method used is POST
The API path is /v1/secret/data/mysecret
Correct; for KV v2, the path includes /data/.
Which TWO of the following Vault CLI commands can be used to write data to Vault?
vault set
vault put
vault push
vault write
`vault write` sends data to a specified path, storing it as a new secret version or creating the path if absent. It satisfies the stem's requirement to write data, accepting key-value pairs as arguments and returning the written metadata. This makes it one of the two valid commands for persisting data in Vault.
vault kv put
`vault kv put` writes secrets to the KV secrets engine, satisfying the stem's requirement to write data. It creates a new version at the given path, accepting key-value pairs as arguments or from a file, and returns the resulting version metadata. This is the canonical write operation for KV v1 and v2 mounts.
A company uses Vault to manage secrets for multiple applications. A new security policy requires that all human users authenticate using LDAP and that all machine-to-machine authentication uses AppRole. An administrator has configured an LDAP auth method at 'ldap/' and an AppRole at 'approle/'. The administrator creates a role 'web-app' with a secret ID TTL of 30 days and a token TTL of 1 hour. After deploying the web application, the application successfully logs in using the AppRole role ID and secret ID, retrieves a token, and reads secrets. However, after 1 hour, the application begins receiving 'permission denied' errors when trying to read secrets. The application logs show that it is using the same token obtained during initial login. Which action should the administrator take to resolve this issue?
Increase the secret ID TTL to 60 days so the application can re-authenticate less frequently.
Set the token TTL to 0 (unlimited) so the token never expires.
Have the application re-authenticate with the AppRole using the same secret ID after the token expires.
Configure the application to renew the token before it expires by calling the 'auth/token/renew' endpoint.
Renewing via `auth/token/renew` extends the existing token's lease without requiring re-authentication, matching the one-hour token TTL that caused the permission denied errors. The application must call this endpoint before expiry, since the token is renewable by default and the AppRole secret ID TTL of 30 days is irrelevant here.
Drag and drop the steps to set up Vault's Transit secrets engine for encryption/decryption into the correct order.
Enable the transit secrets engine, create a key, encrypt data, decrypt data, rotate the key
This is the correct order because the engine must be enabled first, then a key created, then encryption and decryption operations can be performed, and finally key rotation for security.
Create a key, enable the transit secrets engine, encrypt data, decrypt data, rotate the key
Enable the transit secrets engine, create a key, rotate the key, encrypt data, decrypt data
Enable the transit secrets engine, encrypt data, create a key, decrypt data, rotate the key
Want more Utilize Vault CLI and API practice?
Practice this domain12% of exam · 6 sample questions below
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
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.
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
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.
POST /v1/transit/encrypt/my-key
POST /v1/transit/decrypt/my-key
POST /v1/transit/datakey/ciphertext/my-key
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?
POST /v1/transit/encrypt/my-key
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.
POST /v1/transit/sign/my-key
POST /v1/transit/hmac/my-key
POST /v1/transit/random
POST /v1/transit/decrypt/my-key
After rotating the 'payment-key', Vault successfully decrypts data encrypted with the old key (v1). What is the most likely reason the decryption succeeded?
The old key version is retained and used for decryption when the ciphertext references that version.
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.
The old key version is automatically deleted after rotation, but the ciphertext contains the key version and is decrypted by the new key.
The ciphertext contains the original plaintext, so decryption simply extracts it.
The plaintext is stored in Vault during encryption, so decryption retrieves the stored plaintext.
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?
chacha20-poly1305
convergent-encryption
Convergent encryption derives the nonce from the plaintext and context, making output deterministic.
aes128-gcm96
aes-gcm
padding
A DevOps team needs to encrypt large files (several GB) using Vault's transit engine. What is the recommended approach?
Use Vault's batch encryption
Use Vault's seal-wrapping feature
Use Vault's datakey endpoint to get a data encryption key, encrypt locally, then wrap with Vault
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.
Encrypt the file directly with Vault's transit encrypt API
Split the file into chunks and encrypt each chunk via transit
Want more Explain encryption as a service practice?
Practice this domain12% of exam · 6 sample questions below
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
The Vault Agent sidecar runs alongside the application pod, authenticates via Kubernetes service account and writes a short-lived Vault token to a shared volume. This satisfies the requirement for automatic, non-interactive token acquisition at pod startup.
Vault CLI with token helper
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
Configuring an audit device satisfies the compliance logging requirement, since Vault only records requests once at least one audit device is enabled. Each device receives every request and response, writing them to its configured destination, such as a file or syslog. Without an enabled audit device, Vault logs nothing, so no other component fulfils this mandate.
Auth Method
Which Vault component is responsible for encrypting data before storing it in the storage backend?
Storage Backend
Audit Device
Barrier
The barrier performs cryptographic operations on data before it reaches the storage backend, deriving keys from the root key via the shamir seal. It sits between the storage layer and the outside world, ensuring plaintext never touches physical disk.
Secrets Engine
A Vault cluster uses Integrated Storage. During a planned upgrade, the administrator wants to minimize downtime. Which upgrade strategy should be used?
Upgrade all nodes at once
Perform a rolling upgrade one node at a time
Integrated Storage replicates data across all nodes, so a rolling upgrade drains and updates one node at a time while the remaining nodes maintain quorum and continue serving requests. This satisfies the requirement to minimise downtime during the planned upgrade.
Stop all nodes, upgrade, then start
Add new upgraded nodes then remove old ones
What is the purpose of the Seal/Unseal process in Vault architecture?
To delete old secrets
To rotate the encryption key
To back up the storage backend
To enable Vault to process requests
Vault starts sealed, holding the master key encrypted and unable to decrypt stored data. Unsealing reconstructs that key in memory, which is the prerequisite for servicing any API request; until unsealed, Vault returns errors and processes nothing.
Which TWO statements about Vault's Storage Backend are correct?
It stores encrypted data
Data is encrypted by the barrier before storage.
It logs all requests
It is abstracted and can be swapped
Vault supports multiple storage backends.
It handles authentication of clients
It is responsible for encrypting data
Want more Explain Vault architecture practice?
Practice this domainThe VA-003 exam has 57 questions and must be completed in 60 minutes. The passing score is 700/1000.
Scenario-based questions covering exam objectives with detailed answer explanations.
The exam covers 8 domains: Compare and configure secrets engines, Compare authentication methods, Create Vault policies, Assess Vault tokens, Manage Vault leases, Utilize Vault CLI and API, Explain encryption as a service, Explain Vault architecture. Questions are weighted by domain — higher-weight domains appear more on your actual exam.
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.
Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.