VA-003 Practice Test 37 — 15 Questions

Question 1

A company uses Vault Enterprise with Performance Replication across two data centers. The primary data center is in us-east-1 and the secondary is in eu-west-1. They have an application that writes secrets to the primary cluster, and those secrets are replicated to the secondary cluster for read access. Recently, they noticed that some secrets written to the primary are not appearing on the secondary even after several minutes. The latency between data centers is typically 50ms. The administrator checks the replication status and sees a 'merkle sync' in progress. What is the most likely reason for the delay?

Accepted Answer

The secondary cluster is experiencing write load that is causing replication to fall behind.. Performance Replication in Vault Enterprise uses asynchronous streaming of write-ahead log (WAL) entries to replicate data to secondary clusters. When a 'merkle sync' is in progress, it indicates that the secondary cluster has fallen behind and is performing a full tree comparison to reconcile differences. The most likely cause is that the secondary cluster is under write load, which can cause it to process replication WAL streams more slowly, leading to a backlog and triggering a merkle sync to catch up.

Answer

The replication token has expired.

Answer

The primary cluster is using a different seal type than the secondary.

Answer

Performance Replication only replicates data once per hour by default.

Question 2

A team is migrating from a monolithic application to microservices. Each microservice needs to authenticate to Vault using its own AppRole. The security team wants to enforce that each AppRole can only read secrets from its own dedicated path (e.g., service-a can only read from 'services/service-a/*', service-b from 'services/service-b/*'). They have created the AppRoles and policies. However, during testing, they notice that service-a can read secrets from service-b's path. The administrator checks the policy for service-a and sees it has a 'capabilities' list on 'services/service-a/*' and also 'services/service-b/*' by mistake. They correct the policy, but the issue persists. What is the most likely reason that service-a still has access?

Accepted Answer

The token was issued before the policy was corrected and still carries the old policy version; it must be replaced or renewed to get the updated permissions. Vault tokens are immutable once issued; they carry a snapshot of the policies at the time of creation. Correcting the policy on the Vault server does not retroactively update existing tokens. Service-a's token was issued before the policy fix and still contains the old policy that granted access to 'services/service-b/*'. The token must be replaced (revoked and re-issued) or renewed to pick up the updated policy permissions.

Answer

The policy still contains an error that grants access to the wrong path

Answer

The policy update has not been applied to the Vault cluster yet

Answer

The service-a token has a second policy attached that grants access to service-b

Question 3

A company runs a monolithic application that reads database credentials from Vault KV v2 secrets engine at path 'app/db'. The application authenticates using an AppRole with a periodic token that renews automatically. Recently, the application started failing with permission denied errors when reading the secret. The administrator checks the AppRole's secret-id and token but they are valid. The administrator then runs `vault token capabilities $(cat /tmp/token) app/db/data` and gets an empty list. The administrator knows that the token has the 'app-policy' policy attached. They also run `vault read sys/policy/app-policy` and see the policy rules. The policy allows explicit 'read' on 'app/db/data'. What could be the issue?

Accepted Answer

The policy path is incorrect because KV v2 requires granting access to 'app/db/data' but the policy might be written for KV v1 syntax. The issue is that KV v2 secrets engine requires a different policy path than KV v1. For KV v2, the data path is 'app/db/data', but the policy must grant access to 'app/db/data/*' or 'app/db/+/data' (depending on the version) because the actual secret is stored under 'app/db/data' and the policy path must match the full path including the 'data' prefix. The administrator's policy likely uses 'app/db/data' without the wildcard or correct syntax, causing the capabilities check to return an empty list despite the token being valid.

Answer

The secret at 'app/db/data' does not exist

Answer

The token has expired and needs to be renewed

Answer

The Capabilities command does not work with AppRole tokens

Question 4

A developer is troubleshooting an application that uses Vault's PostgreSQL secrets engine. The application successfully obtains a database credential from Vault, but after 30 minutes, the application starts receiving authentication errors from the database. The developer checks the Vault audit logs and sees that the lease for the credential was revoked. The lease was originally created with a TTL of 1 hour. The application is not renewing the lease. The developer wants to fix the issue so that the credential works for the full 1 hour. What should the developer do?

Accepted Answer

Modify the application to renew the lease before it expires using the lease ID.. Option B is correct because the application must actively renew the lease before it expires to maintain the database credential. Vault issues leases with a TTL, but the lease is not automatically extended; the client must call the renew endpoint using the lease ID. Since the application is not renewing, the lease is revoked at its TTL (1 hour) or earlier if the default lease duration is shorter, causing authentication errors after 30 minutes if the default lease TTL is 30 minutes.

Answer

Revoke the lease and request a new credential with a longer TTL.

Answer

Use the lease ID from the response to call sys/leases/renew periodically.

Answer

Increase the TTL of the database role to 2 hours.

Question 5

A company deploys Vault in a single data center with 3 nodes using Integrated Storage. The application team reports that secret reads are slow, with median latency of 200ms. The Vault cluster is under moderate load of 100 requests per second. The administrator checks the server metrics and sees that the Raft commit latency is low, but the HTTP request handling time is high. The Vault nodes are running on virtual machines with 4 vCPUs and 8GB RAM each. The administrator suspects that the bottleneck is due to resource contention. What should the administrator do to reduce read latency without compromising availability?

Accepted Answer

Add performance standby nodes to the cluster to handle read requests.. Adding performance standby nodes is the correct solution because they are specifically designed to handle read requests without participating in the Raft consensus protocol. Since the bottleneck is high HTTP request handling time (not Raft commit latency), performance standbys offload read traffic from the active cluster nodes, reducing latency without affecting write availability or requiring changes to the existing cluster topology.

Answer

Increase the CPU and memory of the existing Vault nodes.

Answer

Switch to a Consul storage backend with more Consul servers.

Answer

Add more Vault nodes to the cluster to distribute read load.

Question 6

A large enterprise runs Vault in a production environment with hundreds of applications. Each application uses a unique Vault token with a 30-day TTL. The tokens are created by a central CI/CD pipeline using Vault's token auth method. Recently, the security team noticed that several tokens with suspicious activity have been created with a 90-day TTL, and the tokens appear to be long-lived and not revoked after use. The CI/CD pipeline logs show no anomalies. The audit logs reveal that the tokens in question were created by a human user 'jdoe' using a token with the 'admin' policy. The 'admin' policy grants '*' capabilities on all paths. The Vault token accessor shows that the suspicious tokens have a 'creation_ttl' of 2160h (90 days) and 'explicit_max_ttl' of 0s. The Vault configuration uses a default lease TTL of 24h and a max lease TTL of 720h (30 days). Which action should the security team take to prevent such incidents in the future without breaking existing applications?

Accepted Answer

Create a dedicated token role with a max TTL of 720h (30 days) and restrict token creation to that role; revoke the 'admin' policy's create permission on auth/token/create.. Option C is correct because the root cause is that the 'admin' policy grants unrestricted token creation permissions, allowing a human user to bypass the intended CI/CD pipeline controls and create tokens with a 90-day TTL. By creating a dedicated token role with a max TTL of 720h (30 days) and revoking the 'admin' policy's create permission on 'auth/token/create', the team enforces a maximum TTL of 30 days for all tokens created via the token auth method, matching the system's max lease TTL and preventing long-lived tokens without breaking existing applications that use the CI/CD pipeline.

Answer

Remove the 'admin' policy from all human users and require them to use a different authentication method.

Answer

Implement a Sentinel policy that blocks token creation by any user except the CI/CD pipeline.

Answer

Reduce the system max lease TTL to 720h (30 days) and enforce that all tokens must have explicit_max_ttl set.

Question 7

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

Accepted Answer

The application is not specifying the key version in the decryption request, and Vault defaults to the latest key version which cannot decrypt data encrypted with the old version.. Option D is correct because when Vault rotates a key in the transit secrets engine, it creates a new key version but retains the old version for decryption of existing ciphertexts. By default, decryption requests that do not specify a key version use the latest version, which cannot decrypt data encrypted with an older version. The application must explicitly include the `?version=` parameter or use the ciphertext's embedded version information to target the correct key version for decryption.

Answer

The key rotation changed the encryption algorithm, making old ciphertexts incompatible with the new key.

Answer

The application's token has expired after the key rotation, requiring a new token with updated policies.

Answer

The application must use the 'rewrap' endpoint to re-encrypt all ciphertexts with the new key version before decryption.

Question 8

A financial services company runs a microservices architecture on Kubernetes. Each microservice needs to authenticate to Vault to retrieve database credentials. The security team mandates that no secrets (tokens, passwords, certificates) be stored in container images or Kubernetes secrets. They also require that each microservice can only access its own secrets. The platform team is evaluating authentication methods. They consider using AppRole, but are concerned about distributing the SecretID. They also consider Kubernetes auth, but are unsure how to restrict access per microservice. They test with a Kubernetes deployment and find that any pod in the namespace can authenticate to Vault. What should they do to meet all requirements?

Accepted Answer

Use Kubernetes auth, create a role per microservice, bind to specific service account names, and assign appropriate policies.. Option D is correct because Kubernetes auth allows Vault to authenticate pods via their service account tokens, and by creating a separate Vault role per microservice bound to a specific Kubernetes service account name, each pod can only authenticate to its designated role. This ensures that only pods with the correct service account can retrieve their own secrets, meeting the requirement that no secrets are stored in images or Kubernetes Secrets and that access is restricted per microservice.

Answer

Use Kubernetes auth with a single role for the namespace, and rely on token TTL to limit exposure.

Answer

Use AppRole with a unique RoleID and SecretID per microservice, distribute via Kubernetes secrets.

Answer

Use TLS cert auth, generate a certificate per microservice, and mount as a secret.

Question 9

A large enterprise runs a microservices architecture on Kubernetes. Each microservice authenticates to Vault using the Kubernetes auth method with a service account token. The Vault administrator configured a role 'microservice-role' with a TTL of 24h and a max TTL of 48h. The microservices renew their tokens every 12 hours via a sidecar. Recently, the security team noticed that some tokens are still valid after 72 hours, causing a security concern. The audit logs show that the tokens were renewed successfully multiple times. The administrator reviews the role configuration and sees that 'token_renewable' is set to true. What is the most likely reason the tokens are exceeding the intended 48h max TTL?

Accepted Answer

The Kubernetes service account token used for authentication is long-lived, allowing the Vault token to be renewed indefinitely. The Kubernetes auth method uses the service account token to authenticate and derive a Vault token. If the Kubernetes service account token is long-lived (non-bound), the Vault token can be renewed indefinitely as long as the Kubernetes token remains valid, because the renewal process re-authenticates against the Kubernetes API and obtains a fresh lease. The role's max TTL of 48h is enforced only if the underlying Kubernetes token expires or is revoked; otherwise, Vault's renewal mechanism can extend the token beyond the configured max TTL.

Answer

The sidecar renewal interval is too short, causing the token to be renewed before the max TTL is checked

Answer

The Kubernetes auth method's default TTL overrides the role's max TTL

Answer

The Vault role's max TTL is not propagated to the token because the token was created with a different policy

Question 10

A large enterprise runs Vault in a production environment with multiple secrets engines, including databases, AWS, and PKI. Recently, the operations team noticed that the number of active leases has grown significantly, causing performance degradation in Vault. The team suspects that many leases are orphaned or expired but not cleaned up. They run the vault lease tidy command regularly, but the issue persists. The vault audit logs show no errors during revocation. However, the team observes that the database credentials are being revoked correctly, but the PKI certificates are not being revoked when their leases expire. Additionally, some AWS IAM user leases seem to persist beyond their max TTL. What is the most likely cause of this issue?

Accepted Answer

The PKI and AWS secrets engines require explicit revocation of the underlying secret, which is not triggered by lease expiration alone.. For some secrets engines like PKI and AWS, lease expiration does not automatically revoke the underlying secret (certificate or IAM user). The revocation must be explicitly triggered by a revoke operation or by the backend's cleanup routines. The tidy operation only cleans up lease metadata, not the actual secrets. Therefore, even if leases expire, the certificates and IAM users remain. Option B correctly identifies this. Option A is false because tidy is effective for metadata but does not trigger revocation for all backends. Option C is possible but not the root cause if max_ttl is correctly set. Option D is unlikely given that database revocations work correctly.

Answer

The max_ttl setting for the PKI and AWS roles is set incorrectly.

Answer

The vault lease tidy command is not effective for PKI and AWS secrets engines.

Answer

The Vault server's clock is out of sync, causing lease expiration calculations to be inaccurate.

Question 11

A development team is using Vault to dynamically generate PostgreSQL credentials for their application. They configured a database role with a max_lease_ttl of 24 hours. However, credentials are becoming invalid after only 1 hour, causing application errors. The team has verified that the credentials are not being explicitly revoked. Which action should the Vault administrator take to resolve this issue?

Accepted Answer

Update the database role's default_lease_ttl to 24 hours.. The issue is that the default_lease_ttl on the database role is set to 1 hour, which causes credentials to expire before the max_lease_ttl. Adjusting the default_lease_ttl to match the desired lease duration allows credentials to last longer, up to the max_lease_ttl. Option A is correct because it directly addresses the discrepancy between the default and maximum TTLs. Option B is wrong because the max_lease_ttl is already 24 hours and not the cause. Option C is wrong because renewing does not change the underlying TTL configuration. Option D is wrong because the token TTL does not affect the credential lease TTL.

Answer

Extend the TTL of the token used to generate credentials.

Answer

Increase the database engine's max_lease_ttl to 48 hours.

Answer

Instruct the team to renew the lease every 30 minutes.

Question 12

An application uses Vault's KV v2 secrets engine to read a static secret (e.g., API key) at path 'secret/data/myapp/config'. The application initially reads the secret and uses the returned lease_id to successfully renew the lease every hour. After a maintenance window, the application starts failing to renew the lease, receiving an error that the lease is not renewable or does not exist. The secret data is still present and accessible via a new read. What is the most likely cause of this failure?

Accepted Answer

The lease expired during the maintenance window because the application did not renew it on time.. KV v2 secrets engine supports lease renewal for static secrets, but if the lease expires (the renewal interval was missed), the lease becomes invalid and cannot be renewed. The application must perform a fresh read to obtain a new lease. Option C correctly identifies that the lease has already expired. Option A is plausible but lease expiration is more common than token expiry in this context. Option B would cause read failures, not just renewal failures. Option D would affect reads altogether, which is not happening.

Answer

The token used to renew the lease has expired.

Answer

The secret was deleted and recreated under the same path.

Answer

The KV v2 engine was disabled and re-enabled.

Question 13

A company has deployed Vault with an LDAP auth method and has created entity aliases for all users. The company uses KV v2 secrets engine mounted at 'secret/'. Each team's secrets are stored under a path like 'secret/data/team_<team_name>/'. They have multiple teams (engineering, marketing, sales). Currently, an administrator manually creates a separate policy for each team, e.g., path "secret/data/team_engineering/*" { capabilities = ["read", "list"] }. This is becoming cumbersome as new teams are added. The administrator wants to create a single policy that dynamically grants read access to the secrets path corresponding to the user's team, which is stored in the entity's metadata as 'team'. The LDAP auth method is configured to sync group memberships and map to entity aliases, and the entity metadata is correctly populated. Which approach should the administrator take?

Accepted Answer

Create a policy using a templated path: path "secret/data/{{identity.entity.metadata.team}}/*" { capabilities = ["read", "list"] }.. Option B is correct because Vault's policy templating allows using {{identity.entity.metadata.team}} to dynamically insert the team name from the entity's metadata into the path. This creates a single policy that works for all teams without manual updates. Option A gives too broad access. Option C is not a valid policy mechanism. Option D is insecure and not scalable.

Answer

Create a policy using a wildcard alias for each team in the entity alias.

Answer

Create a policy that uses the 'default' policy to allow all reads and then restrict with ACL tokens.

Answer

Create a policy with path "secret/data/*" { capabilities = ["read", "list"] } and assign it to all users.

Question 14

A development team is using the Vault transit secrets engine to encrypt sensitive data in their application. They have created a policy that includes: path "transit/keys/*" { capabilities = ["encrypt", "decrypt"] } and attached it to their application tokens. However, when the application calls the '/v1/transit/encrypt/my-key' endpoint, it receives a permission denied error. The key 'my-key' exists in the transit engine. The team has verified that the token is not expired and has the correct policy attached. What is the most likely cause of the error?

Accepted Answer

The encrypt and decrypt capabilities must be applied to the specific encrypt/decrypt paths, not the key metadata path.. Option B is correct because the encrypt and decrypt operations are performed at the 'transit/encrypt/' and 'transit/decrypt/' endpoints, not at the 'transit/keys/' path which is used for key management (create, read, delete, etc.). The policy must grant the encrypt capability on 'transit/encrypt/my-key' or a wildcard under that path. Option A is not required for encryption. Option C is not a cause; token expiration was verified. Option D is incorrect; 'create' is not needed for encryption.

Answer

The policy also needs 'read' capability on 'transit/keys/*'.

Answer

The application token has expired.

Answer

The transit engine requires the 'create' capability on the key to perform encryption.

Question 15

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.

Accepted Answer

Increase the token TTL for the Kubernetes auth role to 1 hour.. 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.

Answer

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

Answer

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

Answer

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