VAULT-ASSOCIATE Practice Questions

To give a role the ability to display or output all of the end points under the /secrets/apps/* end

point, it would need to have the list capability set. The list capability allows a role to perform any

operation on any path in Vault, including reading, writing, deleting, and listing. The list capability is

required for roles that need to access sensitive data or perform administrative tasks in Vault. The

other capabilities are not relevant for this scenario, as they only allow specific operations on specific

paths or secrets engines. Reference: Policies | Vault | HashiCorp Developer, token capabilities -

Command | Vault | HashiCorp Developer

Running the second command in the GUI CLI will fail. The second command is vault kv put

secret/creds passcode=my-long-passcode. This command attempts to write a secret named creds

with the value passcode=my-long-passcode to the secret path, which is the default path for the kv

secrets engine. However, the kv secrets engine is not enabled at the secret path, as shown by the

first command vault secrets list, which lists the enabled secrets engines and their paths. The only

enabled secrets engine is the transit secrets engine at the transit path. Therefore, the second

command will fail with an error message saying that no secrets engine is mounted at the path

secret/. To make the second command succeed, the kv secrets engine must be enabled at the secret

path or another path, using the vault secrets enable command. For example, vault secrets enable -

path=secret kv would enable the kv secrets engine at the secret path. Reference: kv - Command |

Vault | HashiCorp Developer, vault secrets enable - Command | Vault | HashiCorp Developer

Thank you for your visit.

The correct answer is A because the lease ID is the unique identifier for the credential. The lease ID is

used to revoke the credential using the vault lease revoke command. This command will invalidate

the credential immediately and prevent any further renewals. It will also delete the access key and

secret key from AWS, rendering them useless1. The access key and secret key are not sufficient to

revoke the credential, as they are not recognized by Vault. The lease ID is composed of the path of

the secrets engine, the role name, and a random UUID. In this case, the path is aws/creds, the role

name is s3-access, and the UUID is f3e92392-7d9c-99c8-c921-57Sd62fe89d8.

Reference:

lease revoke - Command | Vault | HashiCorp Developer

The maximum time-to-live (TTL) for a token is defined by the lowest value among the following

factors:

The authentication method that issued the token. Each auth method can have a default and a

maximum TTL for the tokens it generates. These values can be configured by the auth method’s

mount options or by the auth method’s specific endpoints.

The mount endpoint configuration that the token is accessing. Each secrets engine can have a default

and a maximum TTL for the leases it grants. These values can be configured by the secrets engine’s

mount options or by the secrets engine’s specific endpoints.

A parent token TTL. If a token is created by another token, it inherits the remaining TTL of its parent

token, unless the parent token has an infinite TTL (such as the root token). A child token cannot

outlive its parent token.

System max TTL. This is a global limit for all tokens and leases in Vault. It can be configured by the

system backend’s max_lease_ttl option.

The client system that uses the token cannot define the maximum TTL for the token, as this is

determined by Vault’s configuration and policies. The client system can only request a specific TTL for

the token, but this request is subject to the limits imposed by the factors above.

Reference: https://developer.hashicorp.com/vault/docs/concepts/tokens3,

https://developer.hashicorp.com/vault/docs/concepts/lease2,

https://developer.hashicorp.com/vault/docs/commands/auth/tune4,

https://developer.hashicorp.com/vault/docs/commands/secrets/tune5,

https://developer.hashicorp.com/vault/docs/commands/token/create6

The namespace can be defined in the “Mount path” field in the “Advanced options” section of the

login screen. The mount path is the path where the auth method is enabled, and it can include a

namespace prefix. For example, if the LDAP auth method is enabled at the path ns1/auth/ldap,

where ns1 is the namespace, then the mount path field should be set to ns1/auth/ldap. This way, the

Vault UI will log in to the correct namespace and auth method. Alternatively, the namespace can also

be specified in the URL of the Vault UI, such as

https://vault.example.com/ui/vault/auth/ns1/auth/ldap/login.

Using a short-lived dynamic secrets can help limit the scope of a credential breach by reducing the

exposure time of the secrets. Dynamic secrets are generated on-demand by Vault and automatically

revoked when they are no longer needed. This way, the credentials are not stored in plain text or in a

static database, and they can be rotated frequently to prevent unauthorized access. Dynamic secrets

also provide encryption as a service, which means that they perform cryptographic operations on

data in-transit without storing any data. This adds an extra layer of security and reduces the risk of

data leakage or tampering. Reference: Dynamic secrets | Vault | HashiCorp Developer, What are

dynamic secrets and why do I need them? - HashiCorp

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

The Vault CLI command to query information about the token the client is currently using is vault

token lookup. This command displays information about the token or accessor provided as an

argument, or the locally authenticated token if no argument is given. The information includes the

token ID, accessor, policies, TTL, creation time, and metadata. This command can be useful for

debugging and auditing purposes, as well as for renewing or revoking tokens. Reference: token

lookup - Command | Vault | HashiCorp Developer, Tokens | Vault | HashiCorp Developer

This policy allows a user to read data about the secret endpoint identity. The policy grants the user

the ability to create, update, read, and delete data in the “secret/data/{identity.entity.id}” path.

Additionally, the user is allowed to list data in the “secret/metadata/{identity.entity.id}” path. This

policy is useful for users who need to access information about the secret endpoint identity.

The secret endpoint identity is a feature of the Identity Secrets Engine, which allows Vault to

generate identity tokens that can be used to access other Vault secrets engines or namespaces. The

identity tokens are based on the entity and group information of the user or machine that

authenticates with Vault. The entity is a unique identifier for the user or machine, and the group is a

collection of entities that share some common attributes. The identity tokens can carry metadata

and policies that are associated with the entity and group.

The “secret/data/{identity.entity.id}” path is where the user can store and retrieve data that is

related to the secret endpoint identity. For example, the user can store some configuration or

p

for the secret endpoint identity in this path. The “secret/metadata/{identity.entity.id}”

path is where the user can list the metadata of the data stored in the

“secret/data/{identity.entity.id}” path. For example, the user can list the version, creation time,

deletion time, and destroy time of the data in this path.

Reference:

[Identity - Secrets Engines | Vault | HashiCorp Developer]

[KV - Secrets Engines | Vault | HashiCorp Developer]

When unsealing Vault, each Shamir unseal key should be entered by different administrators each

connecting from different computers. This is because the Shamir unseal keys are split into shares that

are distributed to trusted operators, and no single operator should have access to more than one

share. This way, the unseal process requires the cooperation of a quorum of key holders, and

enhances the security and availability of Vault. The unseal keys can be entered via multiple

mechanisms from multiple client machines, and the process is stateful. The order of the keys does

not matter, as long as the threshold number of keys is reached. The unseal keys should not be

entered at the command line in one single command, as this would expose them to the history and

compromise the security. The unseal keys should not be encrypted with each administrator’s PGP

key, as this would prevent Vault from decrypting them and reconstructing the master key. Reference:

https://developer.hashicorp.com/vault/docs/concepts/seal3,

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