Free VAULT-ASSOCIATE Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

An identity group is a collection of entities that share some common attributes. An identity group

can have one or more policies attached to it, which are inherited by all the members of the group. An

identity group can also have subgroups, which can further refine the policies and attributes for a

subset of entities.

One of the use cases of an identity group is to consistently apply the same set of policies to a

collection of entities. For example, an organization may have different teams or departments, such as

engineering, sales, or marketing. Each team may have its own identity group, with policies that grant

access to the secrets and resources that are relevant to their work. By creating an identity group for

each team, the organization can ensure that the entities belonging to each team have the same level

of access and permissions, regardless of which authentication method they use to log in to

Vault. Reference: Identity: entities and groups | Vault | HashiCorp Developer, vault_identity_group |

Resources | hashicorp/vault | Terraform | Terraform Registry

The statement is false. The Vault encryption key is not stored in Vault’s backend storage, but rather in

Vault’s memory. The Vault encryption key is the key that is used to encrypt and decrypt the data that

is stored in Vault’s backend storage, such as secrets, tokens, policies, etc. The Vault encryption key is

derived from the master key, which is generated when Vault is initialized. The master key is split into

unseal keys using Shamir’s secret sharing algorithm, and the unseal keys are distributed to trusted

operators. To start Vault, a quorum of unseal keys is required to reconstruct the master key and

derive the encryption key. The encryption key is then kept in memory and used to protect the data in

Vault’s backend storage. The encryption key is never written to disk or exposed via the

API. Reference: Seal/Unseal | Vault | HashiCorp Developer, Key Rotation | Vault | HashiCorp

Developer

Orphan tokens are tokens that are root of their own token tree. This means that they do not have any

parent token associated with them, and they do not expire when their parent token expires. Orphan

tokens are useful for scenarios where you need a short-lived and independent token, such as for

testing or debugging purposes. Orphan tokens can also be used to create temporary access tokens

for applications or services that need to communicate with Vault without using a long-lived root

token. Reference: Tokens | Vault | HashiCorp Developer, Vault cli: how to create orphan token with

role - HashiCorp Discuss

To create a new user named “sally” with password “h0wN0wB4r0wnC0w” and the power-users

policy, you would use the Vault userpass auth method mounted at auth/userpass. You would use the

following command: “vault write auth/userpass/users/sally password=h0wN0wB4r0wnC0w

policies=power-users”. This command would create a new user named “sally” with the specified

password and policy. Reference:

[Userpass Auth Method | Vault | HashiCorp Developer]

[Create Vault policies | Vault | HashiCorp Developer]

The command vault secrets enable transit enables the transit secrets engine at the transit path. The

transit secrets engine is a secrets engine that handles cryptographic functions on data in-transit, such

as encryption, decryption, signing, verification, hashing, and random bytes generation. The transit

secrets engine does not store the data sent to it, but only performs the requested operations and

returns the results. The transit secrets engine can also be viewed as “cryptography as a service” or

“encryption as a service”. The command vault secrets enable transit uses the default path of transit

for the secrets engine, but this can be changed by using the -path option. For example, vault secrets

enable -path=my-transit transit would enable the transit secrets engine at the my-transit

path. Reference: Transit - Secrets Engines | Vault | HashiCorp Developer, vault secrets enable -

Command | Vault | HashiCorp Developer

The policy shown in the image is:

path “secret/data/webapp1” { capabilities = [“create”, “read”, “update”, “delete”, “list”] }

path “secret/data/super-secret” { capabilities = [“deny”] }

This policy grants or denies access to the key/value v2 secrets engine mounted at secret/ according

to the following rules:

The path “secret/data/webapp1” has the capabilities of “create”, “read”, “update”, “delete”, and

“list”. This means that the policy allows performing any of these operations on the secrets stored

under this path. The data/ prefix is used to access the actual secret data in the key/value v2 secrets

engine5. Therefore, the policy permits the operation of vault kv get secret/webapp1, which reads the

secret data at secret/data/webapp16.

The path “secret/data/super-secret” has the capability of “deny”. This means that the policy denies

performing any operation on the secrets stored under this path. The policy overrides any other policy

that might grant access to this path. Therefore, the policy does not permit the operations of vault kv

delete secret/super-secret and vault kv list secret/super-secret, which delete and list the secret data

at secret/data/super-secret respectively6.

The policy does not explicitly define any rules for the path “secret/metadata”. The metadata/ prefix is

used to access the metadata of the secrets in the key/value v2 secrets engine, such as the number of

versions, the deletion status, the creation time, etc5. By default, if the policy grants any of the

capabilities of “create”, “read”, “update”, or “delete” on the data/ path, it also grants the same

capabilities on the corresponding metadata/ path7. Therefore, the policy permits the operation of

vault kv metadata get secret/webapp1, which reads the metadata of the secret at

secret/metadata/webapp18.

Reference: 5(https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2),

[6]6, 7(https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2), [8]8

The vault lease renew command increments the lease time from the current time, not the end of the

lease. This means that the user can request a specific amount of time they want remaining on the

lease, termed the increment. This is not an increment at the end of the current TTL; it is an increment

from the current time. For example, vault lease renew -increment=3600 my-lease-id would request

that the TTL of the lease be adjusted to 1 hour (3600 seconds) from now. Having the increment be

rooted at the current time instead of the end of the lease makes it easy for users to reduce the length

of leases if they don’t actually need credentials for the full possible lease period, allowing those

credentials to expire sooner and resources to be cleaned up earlier. The requested increment is

completely advisory. The backend in charge of the secret can choose to completely ignore

it1. Reference:

Lease, Renew, and Revoke | Vault | HashiCorp Developer

The Vault seal configuration can be set in two ways: through the Vault configuration file or through

environment variables. The Vault configuration file is a text file that contains the settings and options

for Vault, such as the storage backend, the listener, the telemetry, and the seal. The seal stanza in the

configuration file specifies the seal type and the parameters to use for additional data protection,

such as using HSM or Cloud KMS solutions to encrypt and decrypt the root key. The seal

configuration can also be set through environment variables, which will take precedence over the

values in the configuration file. The environment variables are prefixed with VAULT_SEAL_ and

followed by the seal type and the parameter name. For example, VAULT_SEAL_AWSKMS_REGION

sets the region for the AWS KMS seal. Reference: Seals - Configuration | Vault | HashiCorp

Developer, Environment Variables | Vault | HashiCorp Developer

The Vault secret engine that can be used to build your own internal certificate authority is the PKI

secret engine. The PKI secret engine generates dynamic X.509 certificates on-demand, without

requiring manual processes of generating private keys and CSRs, submitting to a CA, and waiting for

verification and signing. The PKI secret engine can act as a root CA or an intermediate CA, and can

issue certificates for various purposes, such as TLS, code signing, email encryption, etc. The PKI

secret engine can also manage the certificate lifecycle, such as rotation, revocation, renewal, and CRL

generation. The PKI secret engine can also integrate with external CAs, such as Venafi or Entrust, to

delegate the certificate issuance and management. Reference: PKI - Secrets Engines | Vault |

HashiCorp Developer, Build Your Own Certificate Authority (CA) | Vault - HashiCorp Learn

In the HashiCorp Vault UI, secrets are organized in a tree-like structure. To view a secret located at

secret/my-secret, you would click on the “secret/” folder in the tree, then click on the “my-secret”

file. In this screenshot, the “secret/” folder is located at option C. This folder contains the secrets that

are stored in the key/value secrets engine, which is the default secrets engine in Vault. The key/value

secrets engine allows you to store arbitrary secrets as key/value pairs. The key is the path of the

secret, and the value is the data of the secret. For example, the secret located at secret/my-secret

has a key of “my-secret” and a value of whatever data you stored there.

Reference:

[KV - Secrets Engines | Vault | HashiCorp Developer]

The error was thrown because the policy code contains an invalid capability, “write”. The valid

capabilities for a policy are “create”, “read”, “update”, “delete”, “list”, and “sudo”. The “write”

capability is not recognized by Vault and should be replaced with “create”, which allows creating new

secrets or overwriting existing ones. The other statements are not correct, because the wildcard (*)

and the sudo capability are both valid in a policy. The wildcard matches any number of characters

within a path segment, and the sudo capability allows performing certain operations that require

root privileges.

Reference:

[Policy Syntax | Vault | HashiCorp Developer]

[Policy Syntax | Vault | HashiCorp Developer]

This policy would allow read permissions for all secrets at path secret/bar, as well as list permissions

for the secret/bar/ path. The list permission is required to be able to see the names of the secrets

under a given path1. The wildcard () character matches any number of characters within a single path

segment, while the slash (/) character matches the end of the path2. Therefore, the policy would

grant read access to any secret that starts with secret/bar/, such as secret/bar/foo or secret/bar/baz,

but not to secret/bar itself. To grant list access to secret/bar, the policy needs to specify the exact

path with a slash at the end. This policy follows the principle of least privilege, which means that it

only grants the minimum permissions necessary for the users to perform their tasks3.

The other options are not correct because they either grant too much or too little permissions.

Option A would grant both read and list permissions to all secrets under secret/bar, which is more

than what is required. Option B would grant list permissions to all secrets under secret/bar, but only

read permissions to secret/bar itself, which is not what is required. Option D would use an invalid

character (+) in the policy, which would cause an error.

Reference:

Policy Syntax | Vault | HashiCorp Developer

Policy Syntax | Vault | HashiCorp Developer

Policies | Vault | HashiCorp Developer

Shamir’s Secret Sharing is a cryptographic algorithm that allows a secret to be split into multiple

parts, called key shares, such that a certain number of key shares are required to reconstruct the

secret. The number of key shares and the threshold number are configurable parameters that

depend on the desired level of security and availability. Vault uses Shamir’s Secret Sharing to protect

its master key, which is used to encrypt and decrypt the data encryption key that secures the Vault

data. When Vault is initialized, it generates a master key and splits it into a configured number of key

shares, which are then distributed to trusted operators. To unseal Vault, the threshold number of key

shares must be provided to reconstruct the master key and decrypt the data encryption key. This

process ensures that no single operator can access the Vault data without the cooperation of other

key holders. Reference: https://developer.hashicorp.com/vault/docs/concepts/seal4,

https://developer.hashicorp.com/vault/docs/commands/operator/init5,

https://developer.hashicorp.com/vault/docs/commands/operator/unseal6

A web application that uses Vault’s transit secrets engine to encrypt data in-transit can benefit from

the following security features:

Even if the attacker was able to access the raw data, they would only have encrypted bits (TLS in

transit). This means that the attacker would need to obtain the encryption key from Vault in order to

decrypt the data, which is protected by Vault’s authentication and authorization mechanisms. The

transit secrets engine does not store the data sent to it, so the attacker cannot access the data from

Vault either.

The keys can be rotated and min_decryption_version moved forward to ensure this data cannot be

decrypted. This means that the web application can periodically change the encryption key used to

encrypt the data, and set a minimum decryption version for the key, which prevents older versions of

the key from being used to decrypt the data. This way, even if the attacker somehow obtained an old

version of the key, they would not be able to decrypt the data that was encrypted with a newer

version of the key.

The other statements are not true, because:

You cannot rotate the encryption key so that the attacker won’t be able to decrypt the data. Rotating

the key alone does not prevent the attacker from decrypting the data, as they may still have access to

the old version of the key that was used to encrypt the data. You need to also move the

min_decryption_version forward to invalidate the old version of the key.

The Vault administrator would not need to seal the Vault server immediately. Sealing the Vault server

would make it inaccessible to both the attacker and the legitimate users, and would require

unsealing it with the unseal keys or the recovery keys. Sealing the Vault server is a last resort option

in case of a severe compromise or emergency, and is not necessary in this scenario, as the attacker

does not have access to the encryption key or the data in Vault. Reference: Transit - Secrets Engines |

Vault | HashiCorp Developer, Encryption as a service: transit secrets engine | Vault | HashiCorp

Developer

The Vault’s auth method component is the component that performs authentication and assigns

identity and policies to a client. It verifies a client against an internal or external system, and

generates a token with the appropriate policies attached. The token can then be used to access the

secrets and resources that are authorized by the policies. Vault supports various auth methods, such

as userpass, ldap, aws, kubernetes, etc., that can integrate with different identity providers and

systems. The auth method component can also handle token renewal and revocation, as well as

identity grouping and aliasing. Reference: Auth Methods | Vault | HashiCorp

Developer, Authentication - Concepts | Vault | HashiCorp Developer