VA-003 Practice Test 12 — 15 Questions

Question 1

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?

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

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 2

Given the output from 'vault operator raft list-peers', which node(s) will become unavailable if node1 (leader) experiences a network partition away from all other nodes?

Accepted Answer

Only node1 becomes unavailable; the cluster remains operational with a new leader from node2 or node3. In a Raft-based Vault cluster, only the leader node becomes unavailable during a network partition that isolates it from the other nodes. The remaining nodes (node2 and node3) form a quorum (2 out of 3) and will elect a new leader, allowing the cluster to continue serving requests. Node1, being isolated, cannot participate in Raft consensus and will step down as leader, becoming unavailable for client operations.

Answer

All nodes become unavailable because node1 is the leader

Answer

No nodes become unavailable; node1 remains leader but cannot serve writes

Answer

Node1, node4, and node5 become unavailable

Question 3

A team wants to store configuration data such as feature flags in Vault. They need to be able to list all keys under a path. Which secrets engine supports listing?

Accepted Answer

KV v1. The KV v1 secrets engine stores key-value pairs and supports listing all keys under a path via the LIST operation (e.g., `vault list secret/`). This is because KV v1 maintains a flat, non-versioned directory structure that allows enumeration of keys. The team's requirement to list all keys under a path is directly satisfied by KV v1's inherent listing capability.

Answer

Transit

Answer

Cubbyhole

Answer

PKI

Question 4

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 5

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

A financial services company runs a microservices application on Kubernetes. Each service needs to authenticate to Vault using Kubernetes auth and then read secrets from a shared KV v2 engine mounted at 'shared-kv'. The security team requires that Service-A can only read secrets under 'shared-kv/team-alpha/*' and Service-B can only read secrets under 'shared-kv/team-beta/*'. The Vault administrator has already configured the Kubernetes auth method and created roles for each service with bound service account names. However, both services are currently able to read all paths under 'shared-kv/'. The administrator wants to enforce the least privilege access. Which course of action should the administrator take?

Accepted Answer

Review and update the policy attached to the Kubernetes auth roles to restrict capabilities to the specific paths, e.g., 'path "shared-kv/data/team-alpha/*" { capabilities = ["read"] }'.. The issue is that the policy attached to the Kubernetes auth roles grants read access to the entire 'shared-kv/*' path. By updating the policy to restrict capabilities to specific paths like 'shared-kv/data/team-alpha/*' and 'shared-kv/data/team-beta/*', the administrator enforces least privilege. The 'data' prefix is required for KV v2 engines to access secret data, and the wildcard ensures only the respective team's secrets are readable.

Answer

Configure the Kubernetes auth role to use 'token_policies' with a restrictive policy and ensure the bound service account names are correct.

Answer

Create a new secrets engine for each team and mount them at 'team-alpha' and 'team-beta', then assign each service to its respective engine.

Answer

Add a 'path_deny' capability in the policy for the disallowed paths.

Question 7

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?

Accepted Answer

Use periodic tokens with a short period and allow renewal. 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.

Answer

Use batch tokens for better performance

Answer

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

Answer

Increase the default TTL on the token auth method

Question 8

A company uses Vault to issue tokens for short-lived tasks. They have configured a token role with 'period' set to 30 minutes and 'explicit_max_ttl' set to 24 hours. Tokens are created using the role and are expected to be renewed every 30 minutes by the tasks. However, after a few renewals, the Vault audit logs show that a token was renewed but then immediately expired. The task that was using the token failed. What is the most likely reason for this behavior?

Accepted Answer

The token reached its 'explicit_max_ttl' of 24 hours, and renewal is no longer possible.. The token role has an 'explicit_max_ttl' of 24 hours, which sets an absolute hard limit on the token's lifetime regardless of the shorter 'period' of 30 minutes. When the token is renewed, its total lifetime cannot exceed the explicit_max_ttl. Once that limit is reached, Vault rejects any further renewal, causing the token to expire immediately and the task to fail.

Answer

The token was created by a root token and root tokens are not subject to periodic renewal.

Answer

The token was a batch token and batch tokens cannot be renewed at all.

Answer

The token was an orphan token and cannot be renewed more than a few times.

Question 9

Based on the exhibit, what is the maximum total lifespan of this lease?

Accepted Answer

1 hour. The lease duration for a Vault lease is specified in seconds, and the exhibit shows a lease duration of 3600 seconds. Converting 3600 seconds to hours gives exactly 1 hour (3600 / 3600 = 1). This represents the maximum total lifespan of the lease before it expires or must be renewed.

Answer

2 hours

Answer

90 minutes

Answer

30 minutes

Question 10

Drag and drop the steps to configure Vault's database secrets engine with PostgreSQL into the correct order.

Accepted Answer

Enable the database secrets engine, then configure the PostgreSQL connection, then create a role, then generate credentials, and finally revoke the lease.. The correct sequence for configuring Vault's database secrets engine with PostgreSQL is: first enable the secrets engine, then configure the database connection, then create a role that defines the credential generation parameters, then generate credentials, and finally revoke the lease when done. This order ensures all prerequisites are met at each step.

Answer

Configure the PostgreSQL connection, then enable the database secrets engine, then create a role, then generate credentials, and finally revoke the lease.

Answer

Create a role, then configure the PostgreSQL connection, then enable the database secrets engine, then generate credentials, and finally revoke the lease.

Answer

Generate credentials, then create a role, then configure the PostgreSQL connection, then enable the database secrets engine, and finally revoke the lease.

Question 11

An administrator runs the commands shown in the exhibit. Later, they run 'vault kv delete kv-v2/secret' and then 'vault kv undelete -versions=1 kv-v2/secret' to recover the secret. Which command must the administrator run to verify that the secret is now readable?

Accepted Answer

vault kv get kv-v2/secret. 'vault kv get' is the standard command to read and display the latest version of a secret from a KV v2 secrets engine. After running 'vault kv undelete -versions=1', version 1 is restored from a deleted state, and 'vault kv get kv-v2/secret' will retrieve and show that version's data, confirming it is readable.

Answer

vault kv list kv-v2/secret

Answer

vault read kv-v2/data/secret

Answer

vault kv metadata get kv-v2/secret

Question 12

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

Accepted Answer

vault login -method=userpass username=jdoe. `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.

Answer

vault auth -method=token token=s.abc

Answer

vault authenticate -method=userpass username=jdoe

Answer

Setting environment variable VAULT_AUTH=s.abc

Question 13

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

Accepted Answer

Providing cryptographic offloading for applications running in untrusted environments. The Transit secrets engine performs encryption and decryption operations entirely on the server side, never exposing the encryption keys to the client. This allows applications running in untrusted environments to offload cryptographic processing securely, as the keys remain within Vault's encrypted storage and are never transmitted to or stored by the application.

Answer

Generating and managing TLS certificates for internal services

Answer

Storing and retrieving static secrets like API keys

Question 14

Which THREE architectural considerations are important when designing a multi-datacenter Vault deployment?

Accepted Answer

Use separate storage backends per datacenter. Each datacenter must maintain its own independent storage backend to avoid a single point of failure and ensure data isolation. Option D is correct because Performance Replication enables local reads by replicating data from the primary cluster to secondary clusters, reducing read latency. Option E is correct because Disaster Recovery Replication provides failover capability, replicating data asynchronously to a standby cluster for disaster recovery. Together, these three considerations ensure high availability, low latency, and resilience in a multi-datacenter Vault deployment.

Answer

Use a single storage backend across datacenters

Answer

Deploy a single Vault cluster spanning datacenters

Question 15

A new administrator is tasked with setting up a Vault development environment. They installed Vault and started the server in dev mode. They want to use the CLI to write and read a secret without authentication. They run `vault kv put secret/hello value=world` but get an error: 'Error writing data to secret/data/hello: Error making API request. URL: PUT https://127.0.0.1:8200/v1/secret/data/hello Code: 403. Errors: * permission denied'. What should they do first to resolve this?

Accepted Answer

Login with the root token that was output when the server started. Vault dev mode starts with an initial root token displayed in the output. The CLI and API require authentication for all operations, including writing secrets. The error 403 indicates the request lacks a valid token. Logging in with the root token via `vault login <root-token>` authenticates the CLI session, allowing subsequent `vault kv put` commands to succeed.

Answer

Use the API directly with curl instead of the CLI

Answer

Enable the KV secret engine at a different path

Answer

Change the path to 'secret/hello' without 'data'