Vault Agent is a client daemon that provides the following features:

 - Auto-Auth - Automatically authenticate to Vault and manage the token renewal process for locally-retrieved dynamic secrets.

 - Caching - Allows client-side caching of responses containing newly created tokens and responses containing leased secrets generated off of these newly created tokens.

 - Templating - Allows rendering of user supplied templates by Vault Agent, using the token generated by the Auto-Auth step.

https://www.vaultproject.io/docs/agent

This is false. A token can be renewed up until the max TTL as long as the token has not expired. If the token expires (hitting the TTL), the token is revoked and is no longer valid. Therefore, there is actually no token to renew since Vault revokes the token if the TTL is reached.

https://www.vaultproject.io/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls

The token for authentication is set directly as a header for the HTTP API. The header should be either X-Vault-Token: <token> or Authorization: Bearer <token>.

https://www.vaultproject.io/docs/auth/token#authentication

Vault's storage backend is inherently untrusted, therefore Vault manages the encryption and decryption of the data when reading or writing to disk.

https://www.hashicorp.com/resources/how-does-vault-encrypt-data

Ryan has enabled two secrets engines, AWS and database. In any Vault instance, Cubbyhole is a default secrets engine that is enabled by default. In addition, since Ryan is running in dev mode, the secret/ KV v2 secrets engine is enabled by default. Therefore, there are two secrets engines enabled by default, two secrets engines that Ryan enabled.

Hint: If you're not running dev mode, Vault no longer enables a default KV secrets engine like it used to.

https://www.vaultproject.io/docs/secrets/cubbyhole

https://www.vaultproject.io/docs/concepts/dev-server#properties

If Suzy needs to create AND replace values (update), she needs both "create" and "update" capabilities. Create to initially create new KV pairs, and then update to update the values of those KV pairs.

https://www.vaultproject.io/docs/concepts/policies

The default and root policy cannot be deleted. You don't have to use them, but you can't delete them. For the default policy, you can instruct Vault to not assign new tokens the default policy by tuning the Vault configuration by issuing the following command:

$ vault token create -no-default-policy

https://www.vaultproject.io/docs/concepts/policies#built-in-policies

secret/departments/certification/api is not permitted since certification does not equal training as part of the path

secret/business/training is not permitted since the wildcard is AFTER training, and not ON the training path (tricky)

secret/departments/training/vault is permitted since the + allows for any value where departments is part of the path, and vault is in place of where the * is placed in the path

secret/cloud/training/test/exam is permitted since + allows for cloud and * allows for test/exam as part of the path

https://www.vaultproject.io/docs/concepts/policies#policy-syntax

Vault Enterprise offers additional features that allow HA nodes to service read-only requests on the local standby node. Read-only requests are requests that do not modify Vault's storage. This feature is called Performance Standby nodes.

https://www.vaultproject.io/docs/enterprise/performance-standby

This one is tricky and the policy command trips me up sometimes. For one, there is no update command, only write. So when you need to update a Vault policy, you just write it again using the same name as the policy that already exists. Personally, I mix this up with create all the time but create is NOT a valid command.

https://www.vaultproject.io/docs/commands/policy/write