VA-003 Practice Test 17 — 15 Questions

Question 1

Which TWO of the following are valid methods to enable a secrets engine at a non-default path in Vault?

Accepted Answer

vault write sys/mounts/my-aws type=aws. Option B is correct because writing directly to the sys/mounts/ endpoint with type= is the underlying API operation that enables a secrets engine at a custom path, so `vault write sys/mounts/my-aws type=aws` mounts the AWS engine at my-aws. Option C is correct because the CLI `vault secrets enable` command accepts the `-path` flag to specify a non-default mount path, so `vault secrets enable -path=my-aws aws` enables the AWS secrets engine at my-aws. Option A is incorrect because `-custom-path` is not a valid flag for `vault secrets enable`. Option D is incorrect because `-mount-path` is not a recognized flag; the correct flag is `-path`. Option E is incorrect because `vault secrets enable my-aws aws` passes my-aws as the engine type rather than a path, and the CLI does not accept a positional path argument in that form.

Answer

vault secrets enable -custom-path=my-aws aws

Answer

vault secrets enable -mount-path=my-aws aws

Answer

vault secrets enable my-aws aws

Question 2

An application is failing to decrypt data using the transit secrets engine. The ciphertext was generated with key 'my-key' version 3, but the engine currently shows key version 5. What is the most likely cause of the failure?

Accepted Answer

The min_decryption_version is set to 4, preventing decryption with version 3. The transit secrets engine allows configuring a minimum decryption version (`min_decryption_version`) for each key. If this value is set to 4, the engine will refuse to decrypt any ciphertext generated with key version 3, even if version 3 still exists in the key ring. This is the most direct and likely cause of the failure, as the ciphertext was created with version 3 but the engine now enforces a higher minimum version.

Answer

The ciphertext was generated by a different transit key

Answer

The key was rotated, and automatic data re-encryption is required

Answer

The application is using the wrong encryption algorithm

Question 3

A security architect is designing a secrets management solution with Vault. Which THREE secrets engines are most appropriate for dynamically generating credentials for external systems?

Accepted Answer

PKI secrets engine. The PKI secrets engine (A) is correct because it dynamically generates X.509 certificates and private keys on demand from configured roles, issuing short-lived credentials rather than storing static ones. The AWS secrets engine (C) is correct because it dynamically generates AWS IAM credentials (access key ID and secret access key) or STS tokens based on IAM policies, providing on-demand, lease-bound cloud credentials. The Database secrets engine (E) is correct because it dynamically creates unique database usernames and passwords for supported databases (e.g., MySQL, PostgreSQL) tied to a lease, eliminating shared static credentials. The KV v2 secrets engine (B) is not appropriate here because it only stores and versions static key-value secrets and does not generate credentials. The Transit secrets engine (D) is not appropriate because it provides encryption-as-a-service (encrypt/decrypt/sign/verify) and does not issue credentials for external systems.

Answer

KV v2 secrets engine

Answer

Transit secrets engine

Question 4

Which TWO of the following are benefits of using dynamic secrets engines (e.g., database, AWS) over static secrets?

Accepted Answer

Provides automatic rotation of credentials upon lease expiry. Option A is correct because dynamic secrets engines issue credentials with a defined lease/TTL, and when that lease expires (or is revoked), Vault automatically revokes and regenerates the credentials, delivering automatic rotation without manual intervention. Option E is correct because dynamic secrets are short-lived by design—each request generates unique, time-bound credentials—so any leaked credential has a limited window of usefulness, reducing the blast radius and risk of credential leakage. Options B, C, and D are incorrect: dynamic credentials do change (they are generated per lease and expire), they are not persistent or non-expiring, and Vault does not store dynamic secrets in plaintext in its data store—they are generated on demand and tracked by lease, not persisted as static plaintext values.

Answer

Simplifies the management of service accounts because credentials never change

Answer

Secrets are persistent and do not expire

Answer

Secrets are stored in plaintext in the Vault data store

Question 5

An operator needs to perform token lifecycle operations. Which THREE API endpoints are valid for token-related actions?

Accepted Answer

POST /v1/auth/token/renew. In HashiCorp Vault's token auth method, POST /v1/auth/token/renew (option B) is correct because token renewal is performed by submitting a token (and optional increment) to the renew endpoint, which extends the token's TTL. POST /v1/auth/token/create (option D) is correct because new tokens are minted by POSTing parameters such as policies, TTL, and renewable flags to the create endpoint. GET /v1/auth/token/lookup (option E) is correct because looking up a token's metadata (policies, TTL, display name) is a read operation against the lookup endpoint, typically using the X-Vault-Token header or the token as a parameter. Option A is wrong because token roles are managed under /v1/auth/token/roles using POST to create, GET to read, and DELETE to remove, not PUT. Option C is wrong because revoking a token is done with POST /v1/auth/token/revoke (or /revoke-self, /revoke-orphan), not DELETE.

Answer

PUT /v1/auth/token/roles

Answer

DELETE /v1/auth/token/revoke

Question 6

Which TWO of the following are valid uses of a token accessor? (Select exactly 2 options.)

Accepted Answer

Lookup token properties. A token accessor is a special value returned alongside a token in HashiCorp Vault that allows limited operations on that token without possessing the token itself. Option D is correct because the accessor can be used with commands like 'vault token lookup -accessor' to retrieve the token's properties (policies, TTL, metadata) without exposing the token string. Option E is correct because the accessor enables revoking the token via 'vault token revoke -accessor', which is a key use case for auditing and cleanup without handling the raw token. Options A, B, and C are not valid uses: wrapping a token is done via response wrapping, creating a child token requires the parent token itself (or a token with appropriate permissions), and renewing a token requires the token value, not just its accessor.

Answer

Wrap the token

Answer

Create a child token

Answer

Renew the token

Question 7

A company is deploying Vault in a Kubernetes environment. Which three components are essential for a production-ready Vault on Kubernetes? (Choose three.)

Accepted Answer

A persistent volume claim for each Vault pod for storage.. Option B is correct because Vault requires durable storage for its data (the integrated storage/Raft backend or a configured storage stanza), and in Kubernetes a PersistentVolumeClaim per Vault pod ensures data survives pod restarts and rescheduling. Option C is correct because Vault's Kubernetes auth method and auto-unseal/agent injector workflows need a ServiceAccount bound to RBAC roles so Vault can authenticate to and call the Kubernetes API (e.g., TokenReview, SubjectAccessReview). Option E is correct because Vault's Raft integrated storage requires stable pod identities and ordered startup, which a StatefulSet provides via stable network IDs (pod-0, pod-1) and persistent volume templates. Option A is not correct because unseal keys must never be stored in a ConfigMap; ConfigMaps are for non-sensitive configuration, and unseal keys are highly sensitive secrets handled via manual unseal, auto-unseal with a KMS, or secure secret stores. Option D is not correct because an Ingress controller is only needed to expose Vault externally and is not essential for a production-ready Vault cluster, which can be accessed via internal Services or port-forwarding.

Answer

A ConfigMap to store Vault configuration including unseal keys.

Answer

An Ingress controller to expose Vault externally.

Question 8

A security team wants to allow applications to authenticate to Vault without storing any secrets in configuration files. The applications run on AWS EC2 instances with an IAM role attached. Which Vault authentication method leverages the EC2 instance metadata to obtain credentials?

Accepted Answer

AWS IAM authentication. AWS IAM authentication (option D) is correct because it allows applications running on EC2 instances with an attached IAM role to authenticate to Vault without storing any secrets. The Vault client uses the EC2 instance metadata service (IMDS) to retrieve the instance identity document and its signature, which are then presented to Vault. Vault verifies these credentials against the AWS API, confirming the instance's identity and IAM role, thereby enabling secure, secretless authentication.

Answer

GCP IAM authentication

Answer

Userpass authentication

Answer

AppRole authentication

Question 9

An e-commerce application integrates with Vault's transit secrets engine to encrypt sensitive customer data before storing it in a database. The operations team regularly rotates the encryption key (my-key) for compliance. Recently, after a rotation, some old ciphertexts could not be decrypted, causing data retrieval failures. The team checked the key configuration and found that the key version used for encryption (version 2) is still present, but decryption fails with an error: 'decryption key version is not available for decryption'. They verified that the ciphertext includes the key version. What is the most likely cause and resolution?

Accepted Answer

The 'min_decryption_version' is set to 3, preventing decryption with version 2. Set it to 2 to allow decryption.. The error 'decryption key version is not available for decryption' indicates that the key version used to encrypt the data (version 2) is present but not allowed for decryption. In Vault's transit secrets engine, the `min_decryption_version` parameter controls the lowest key version that can decrypt data. If it is set to 3, version 2 ciphertexts cannot be decrypted. Setting `min_decryption_version` to 2 resolves the issue by permitting decryption with version 2.

Answer

The 'suppress_decryption' parameter was enabled on the transit mount, blocking decryption. Disable it.

Answer

The key was exported and reimported, losing the version history. Re-create the key from scratch.

Answer

The ciphertext was corrupted during storage. The only solution is to re-encrypt all data with the current key version.

Question 10

What is the primary purpose of the Vault transit secrets engine?

Accepted Answer

Encryption and decryption as a service. The Vault transit secrets engine is designed to provide encryption and decryption as a service, allowing applications to encrypt and decrypt data without managing cryptographic keys directly. It offloads the cryptographic operations to Vault, which securely stores and rotates the encryption keys, ensuring that plaintext data never leaves the application unencrypted. This enables centralized key management and policy-based access control for encryption operations.

Answer

Token generation

Answer

Certificate management

Answer

Dynamic database credentials

Answer

Secure storage of secrets

Question 11

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

Accepted Answer

path "secret/data/app" { capabilities = ["read"] }. The policy must grant read access to the specific path 'secret/data/app' for the service to retrieve secrets. Option B is correct because renewing a token requires the 'update' capability on the 'auth/token/renew-self' endpoint, which allows the service to extend its own token's TTL without needing broader token management privileges.

Answer

path "auth/token/renew" { capabilities = ["update"] }

Answer

path "secret/data/app/*" { capabilities = ["read"] }

Answer

path "sys/auth" { capabilities = ["read"] }

Question 12

Which THREE of the following best practices should be followed when using Vault's encryption as a service with the transit engine?

Accepted Answer

Use a unique encryption key per application. Option B is correct because using a unique encryption key per application enforces cryptographic isolation, so a compromise or policy change in one app's key cannot decrypt another app's data, and it simplifies access control and auditing in Vault's transit engine. Option C is correct because enabling automatic key rotation (via the transit engine's rotation period or `vault write -f transit/keys/<name>/rotate`) limits the amount of data protected by any single key version, supporting compliance requirements and reducing the blast radius if a key is exposed. Option D is correct because the transit engine's encryption context is a non-secret, authenticated value that is cryptographically bound to the ciphertext, so decryption fails unless the same context is supplied, preventing ciphertext from being reused in an unintended application or tenant context. Option A is not a best practice because deleting transit keys is irreversible and destroys the ability to decrypt data encrypted with them, so keys should be disabled or rotated rather than deleted. Option E is not a best practice because hardcoding key names in application code reduces flexibility and complicates rotation, environment separation, and secret management; key references should come from configuration or a secrets manager.

Answer

Allow deletion of keys to clean up unused keys

Answer

Store the key name in the application code for easy access

Question 13

A token is created with policies 'default' and 'web-app'. Later, a parent token's policy is updated to add 'logging'. The child token's policies are not updated. What will happen when the child token is used?

Accepted Answer

The child token will still have only 'default' and 'web-app' policies. In Vault, child tokens inherit the policies of their parent at the time of creation, but subsequent changes to the parent's policies do not propagate to existing child tokens. The child token retains its original policy set ('default' and 'web-app') because policies are evaluated based on the token's own metadata, not the parent's current state. This behavior is by design to ensure token immutability and prevent unintended privilege escalation.

Answer

The child token will be automatically renewed to pick up the new policy

Answer

The child token will automatically gain the 'logging' policy

Answer

The child token will be invalidated due to policy mismatch

Question 14

Which TWO statements are true about batch tokens?

Accepted Answer

Batch tokens cannot be renewed or revoked. Option B is correct because batch tokens are designed as lightweight, self-contained tokens that cannot be renewed or revoked once issued; they simply expire at the end of their fixed TTL. Option C is correct because batch tokens are not persisted in Vault's storage backend—they are encrypted blobs whose validity is verified without a storage lookup, which is what makes them scalable and cheap to create. Option A is incorrect because batch tokens have a fixed lifetime and cannot be renewed, unlike service tokens. Option D is incorrect because batch tokens cannot be looked up via the lookup endpoint; lookup operations require a storage-backed token, which batch tokens are not.

Answer

Batch tokens can be renewed to extend their lifetime

Answer

Batch tokens can be looked up using the lookup endpoint

Question 15

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?

Accepted Answer

Map the GitHub team to a Vault policy in the auth method configuration.. Vault's GitHub auth method requires mapping GitHub teams to Vault policies. When a user authenticates with a GitHub personal access token, Vault checks the token's associated teams against the configured team-to-policy mappings. Only users belonging to a mapped team receive the corresponding Vault policy, enabling access control based on team membership.

Answer

Vault validates the token's scope.

Answer

Users must generate a personal access token with repo scope.

Answer

The GitHub token must include the team scope.