VA-003 Practice Test 3 — 30 Questions

Question 1

Drag and drop the steps to perform a Vault disaster recovery using the replication feature into the correct order.

Accepted Answer

Step 1: Initialize clusters, Step 2: Enable primary replication, Step 3: Generate secondary activation token, Step 4: Enable secondary replication, Step 5: Promote secondary to primary if needed. Initialize clusters, enable primary replication, generate token, enable secondary, promote if needed.

Answer

Step 1: Generate secondary activation token, Step 2: Enable primary replication, Step 3: Enable secondary replication, Step 4: Initialize clusters, Step 5: Promote secondary to primary if needed

Answer

Step 1: Enable primary replication, Step 2: Enable secondary replication, Step 3: Initialize clusters, Step 4: Generate secondary activation token, Step 5: Promote secondary to primary if needed

Answer

Step 1: Enable secondary replication, Step 2: Enable primary replication, Step 3: Initialize clusters, Step 4: Generate secondary activation token, Step 5: Promote secondary to primary if needed

Question 2

A Vault cluster is sealed. An operator attempts to renew a lease but gets an error. What is the most likely error?

Accepted Answer

Vault is sealed. When Vault is sealed, it cannot process any operations, including lease renewal. The error would indicate the sealed state.

Answer

Upstream error

Answer

Permission denied

Answer

Lease not found

Question 3

Which THREE API endpoints are valid for managing policies in Vault?

Accepted Answer

GET /v1/sys/policy/{name}. The GET, DELETE, and POST endpoints are valid for managing policies in Vault. GET retrieves a policy, DELETE removes it, and POST creates or updates a policy. These correspond to the standard CRUD operations supported by Vault's sys/policy API.

Answer

PUT /v1/sys/policy/{name}

Answer

PATCH /v1/sys/policy/{name}

Question 4

Drag and drop the steps to set up Vault's Transit secrets engine for encryption/decryption into the correct order.

Accepted Answer

Enable the transit secrets engine, create a key, encrypt data, decrypt data, rotate the key. The correct order is to first enable the Transit secrets engine, then create a key, use the key to encrypt and decrypt data, and finally rotate the key for security. Enabling creates the path, key creation provides the encryption material, and rotation updates the key without interrupting operations.

Answer

Create a key, enable the transit secrets engine, encrypt data, decrypt data, rotate the key

Answer

Enable the transit secrets engine, create a key, rotate the key, encrypt data, decrypt data

Answer

Enable the transit secrets engine, encrypt data, create a key, decrypt data, rotate the key

Question 5

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?

Accepted Answer

Configure the role with a ttl of 1h.. 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.

Answer

Set the mount's max_lease_ttl to 1h.

Answer

Ask each developer to set the TTL when requesting credentials.

Answer

Use a periodic token with a period of 1h.

Question 6

A Vault operator runs `vault status` and sees the output above. The Vault cluster is in production and currently unresponsive to API requests. What is the most likely cause of the unresponsiveness?

Accepted Answer

The Vault cluster is sealed.. The `vault status` output shows that the Vault cluster is sealed. When a Vault cluster is sealed, it cannot process any API requests because the encryption key required to decrypt the data is not available in memory. This is the most common cause of unresponsiveness in a production Vault cluster that has been properly initialized.

Answer

The cluster is not initialized.

Answer

The cluster does not have HA enabled.

Answer

The cluster has no active leader.

Question 7

An admin creates a token with TTL=48h and explicit_max_ttl=120h. The token is renewed every 24h. After 10 days, will the token still be valid?

Accepted Answer

No, because the total lifetime cannot exceed the explicit_max_ttl of 120h.. The token's total lifetime is capped by the `explicit_max_ttl` of 120 hours (5 days). Even though the token is renewed every 24 hours, the cumulative time since creation cannot exceed the explicit maximum TTL. After 10 days (240 hours), the token will have long surpassed the 120-hour limit and will be invalid.

Answer

Yes, because TTL refreshes to 48h on each renewal.

Answer

Yes, if renewed before TTL expires, it can persist indefinitely.

Answer

No, because tokens cannot be renewed more than 5 times.

Question 8

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

Accepted Answer

The plaintext "hello" as a base64 encoded string. E is correct because Vault's transit engine requires plaintext to be base64-encoded before encryption. The API endpoint expects the plaintext as a base64-encoded string in the `plaintext` field of the request body. This ensures binary-safe transmission and consistent encoding across different systems.

Answer

The ciphertext of "hello"

Answer

Both the key name and the ciphertext

Answer

A reference to the key

Answer

The plaintext "hello" in raw bytes

Question 9

A security team wants to ensure that tokens can be revoked immediately if a compromised token is detected, even if the token ID is unknown. Which token feature should they use?

Accepted Answer

Token accessors. Token accessors allow revocation of a token without knowing the token ID. They are specifically designed for this purpose.

Answer

Periodic tokens

Answer

Batch tokens

Answer

Orphan tokens

Question 10

An application using a service token fails to renew it, receiving an error 'permission denied'. The token has policies that include 'path "auth/token/renew-self" { capabilities = ["update"] }'. The token is not expired and has remaining TTL. What is a likely cause?

Accepted Answer

The token has reached its explicit max TTL. The token's explicit max TTL has been reached, preventing any further renewals even though the token still has remaining TTL. Option A is incorrect because num_uses=0 means unlimited uses, not that it has reached zero. Option B is incorrect because a batch token cannot be renewed at all, but the token's policy includes renew-self capability, indicating it is a service token. Option C is incorrect because if the parent token were revoked, the token itself would be revoked and invalid, not just failing to renew with a permission denied error.

Answer

The token's num_uses has reached zero

Answer

The token is a batch token

Answer

The token's parent was revoked

Question 11

Which three characteristics are true about Vault's storage backend and seal mechanisms? (Choose three.)

Accepted Answer

The Shamir seal requires multiple unseal keys to be entered before Vault can operate.. The Shamir seal splits the master key into multiple key shares, requiring a threshold number of these shares to be entered during the unseal process before Vault can decrypt its data encryption key and become operational. This ensures that no single individual can unseal Vault, providing a distributed trust model.

Answer

Auto-unseal using a cloud KMS eliminates the need for unseal keys entirely.

Answer

Consul as a storage backend requires Consul's own gossip protocol for leader election.

Question 12

Refer to the exhibit. Based on the output from 'vault status', which statement is true?

Accepted Answer

The unseal configuration uses 5 key shares with a threshold of 3.. The 'vault status' output shows 'Sealed: false', 'Key Shares: 5', and 'Key Threshold: 3'. This indicates that Vault is unsealed and uses a Shamir seal configuration with 5 key shares, requiring any 3 of them to unseal. Option B correctly states this unseal configuration.

Answer

The storage backend is a file backend.

Answer

Auto-unseal is enabled using Consul as the seal provider.

Answer

Vault is not configured for high availability.

Question 13

An application needs to read a secret using the Vault API after authenticating with an AppRole RoleID and SecretID. The application has already obtained a Vault token. Which API endpoint should be called to read a secret at 'secret/data/myapp' with the token?

Accepted Answer

GET /v1/secret/data/myapp. After authentication, the application already has a Vault token and needs to read a secret from the KV v2 secrets engine. The correct API endpoint for reading a secret from the KV v2 engine is GET /v1/secret/data/myapp, where 'secret' is the mount path and 'data' is the sub-path for KV v2 operations. The token is passed in the X-Vault-Token header, not in the URL.

Answer

GET /v1/secret/metadata/myapp

Answer

POST /v1/auth/approle/login

Answer

GET /v1/secret/myapp

Question 14

A user forgets to renew their token before it expires. What happens to the token and its associated leases?

Accepted Answer

The token is revoked and all its leases are revoked. When a Vault token expires, it is immediately revoked by the system, and all associated leases (e.g., dynamic secrets, wrapped responses) are also revoked. There is no grace period for renewal after expiration; the token must be renewed before its TTL expires. This behavior is enforced by Vault's lease management system, which ties secret lifetimes directly to token validity.

Answer

The token becomes invalid but can be renewed within a grace period

Answer

The token is automatically renewed for another period

Answer

The token remains active but read-only

Question 15

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?

Accepted Answer

Set a short TTL on the token and do not allow renewal. 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.

Answer

Use a revocation script that runs periodically

Answer

Set explicit max TTL on the token

Answer

Use a periodic token with a long period

Question 16

A development team wants to authenticate to Vault using a method that does not require storing secrets in source code and supports automatic rotation of credentials. Which authentication method best meets these requirements?

Accepted Answer

AWS IAM authentication. AWS IAM authentication allows Vault to authenticate using AWS IAM credentials (access key/secret key or instance metadata) without storing any secrets in source code. It supports automatic credential rotation by leveraging AWS IAM roles and STS to generate temporary credentials, which Vault can validate via the AWS API. This eliminates the need for long-lived secrets in code and enables seamless rotation.

Answer

Token authentication

Answer

LDAP authentication

Answer

Userpass authentication

Question 17

A developer has a policy that grants 'create' capability on path 'secret/data/team/*'. They successfully create a new secret using 'vault kv put secret/data/team/db', but when they try to update the same secret with new data, they get a permission denied error. What is the most likely cause?

Accepted Answer

The policy does not include the 'update' capability, which is required for modifying existing secrets.. In Vault, the 'kv put' command performs a 'create' operation when the secret does not exist, but an 'update' operation when it does. The policy only grants 'create' capability on 'secret/data/team/*', which allows the initial write but not subsequent modifications. To update an existing secret, the policy must also include the 'update' capability on the same path, as Vault's ACL system enforces separate capabilities for creating and updating secrets.

Answer

The developer does not have the 'create' capability on the parent path.

Answer

The policy needs the 'list' capability on the path.

Answer

The developer's token lacks the 'sudo' capability for updates.

Question 18

A finance company runs a microservices architecture on Kubernetes. Each microservice has its own service account and uses Kubernetes auth to authenticate to Vault and read secrets. Recently, a new microservice 'payment' was deployed in the 'prod' namespace with service account 'payment-sa'. The team created a Vault role with bound_service_account_names=['payment-sa'] and bound_service_account_namespaces=['prod']. The microservice can authenticate and obtains a token, but when it tries to read the secret at path 'secret/data/payments/db', it gets a permissions error. Other microservices in the same namespace with similar roles work fine. The Vault policy for the role includes read access to 'secret/data/payments/*'. What is the most likely issue and correct action?

Accepted Answer

Update the Vault role to include the policy 'payments-read' in the token_policies parameter.. The Vault role is configured with `token_policies` that grant read access to `secret/data/payments/*`, but the role itself does not include that policy in its `token_policies` parameter. When the microservice authenticates via Kubernetes auth, the token issued by Vault only carries policies explicitly attached to the role. Without the policy being listed in `token_policies`, the token lacks the necessary permissions to read the secret, even though the policy exists. Updating the role to include the policy in `token_policies` resolves the permissions error.

Answer

Increase the TTL of the Vault token to give more time for the secret read.

Answer

Add the microservice's service account to the bound_service_account_names of an existing role that works.

Answer

Change the authentication method to AppRole for the payment microservice.

Question 19

A Vault administrator is configuring Consul as the storage backend. The Consul cluster will span three data centers with low latency links. Which Consul deployment is recommended for Vault to ensure data safety?

Accepted Answer

5 Consul servers in a single datacenter. Vault requires a strong consistency guarantee for its storage backend, and Consul achieves this via the Raft consensus protocol, which requires a majority of servers to be available. A single datacenter with 5 Consul servers provides the necessary fault tolerance and quorum (3 out of 5) to survive failures while maintaining data safety. Spreading servers across datacenters with low latency links still introduces network partitions and higher latency, which can break Raft's stability and lead to split-brain scenarios or degraded performance.

Answer

3 Consul servers across 3 datacenters (1 per DC)

Answer

3 Consul servers in each datacenter (total 9)

Answer

3 Consul servers in one datacenter with agents in others

Question 20

A DevOps engineer needs to create a token with a specific policy attached using the Vault API. Which API endpoint and request should they use?

Accepted Answer

POST /v1/auth/token/create with JSON body {"policies":["my-policy"]}. The Vault API endpoint for creating tokens with specific policies is POST /v1/auth/token/create, and the JSON body must include the 'policies' key as an array of strings. This endpoint is part of the token auth method and allows attaching policies at token creation time.

Answer

POST /v1/auth/token/create-orphan with JSON body {"policies":["my-policy"]}

Answer

POST /v1/token/create with JSON body {"policy":"my-policy"}

Answer

POST /v1/sys/token with JSON body {"policy":"my-policy"}