HashiCorp vault associate practice test

Answer:

D

Explanation:
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]

Answer:

A

Explanation:
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

Answer:

Explanation:
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.

Answer:

D

Explanation:
The transit secrets engine is not a good solution for binaries of this size, because it is designed to
handle cryptographic functions on data in-transit, not data at-rest. The transit secrets engine does
not store any data sent to it, so it would require sending the entire 2GB blob to Vault for encryption
or decryption, which would be inefficient and impractical. A better solution would be to use the
transit secrets engine to generate a data key, which is a high-entropy key that can be used to encrypt
or decrypt data locally. The data key can be returned in plaintext or wrapped by another key,
depending on the use case. This way, the transit secrets engine only handles the encryption or
decryption of the data key, not the data itself, and the data can be stored in any primary data
store. Reference:
Transit - Secrets Engines | Vault | HashiCorp Developer
,
Encryption as a service:
transit secrets engine | Vault | HashiCorp Developer

Answer:

D

Explanation:
The transit secrets engine relieves the burden of proper encryption/decryption from application
developers and pushes the burden onto the operators of Vault. The transit secrets engine provides
encryption as a service, which means that it performs cryptographic operations on data in-transit
without storing any data. This allows developers to delegate the responsibility of managing
encryption keys and algorithms to Vault operators, who can define and enforce policies on the transit
secrets engine. This way, developers can focus on their application logic and data, while Vault
handles the encryption and decryption of data in a secure and scalable manner. Reference:
Transit -
Secrets Engines | Vault | HashiCorp Developer
,
Encryption as a service: transit secrets engine | Vault
| HashiCorp Developer

Answer:

B

Explanation:
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

Answer:

B

Explanation:
AppRole is a machine-oriented authentication method that allows machines or applications to
authenticate with Vault using a role ID and a secret ID. The role ID is a unique identifier for the
application, and the secret ID is a single-use credential that can be delivered to the application
securely.
AppRole is designed to provide secure introduction of machines and applications to Vault,
and to support the principle of least privilege by allowing fine-grained access control policies to be
attached to each role1
.
Okta, GitHub, and Transit are not machine-oriented authentication methods.
Okta and GitHub are
user-oriented authentication methods that allow users to authenticate with Vault using their Okta or
GitHub credentials23
.
Transit is not an authentication method at all, but a secrets engine that
provides encryption as a service4
.
Reference:
AppRole Auth Method | Vault | HashiCorp Developer
Okta Auth Method | Vault | HashiCorp Developer
GitHub Auth Method | Vault | HashiCorp Developer
Transit Secrets Engine | Vault | HashiCorp Developer

Answer:

B

Explanation:
The command that does not meet the security requirement of not having secrets appear in the shell
history is B. vault kv put secret/password value-itsasecret. This command would store the secret
value “itsasecret” in the key/value secrets engine at the path secret/password, but it would also
expose the secret value in the shell history, which could be accessed by other users or malicious
actors. This is not a secure way of storing secrets in Vault.
The other commands are more secure ways of storing secrets in Vault without revealing them in the
shell history. A. generate-password | vault kv put secret/password value would use a pipe to pass the
output of the generate-password command, which could be a script or a tool that generates a
random password, to the vault kv put command, which would store the password in the key/value
secrets engine at the path secret/password. The password would not be visible in the shell history,
only the commands. C. vault kv put secret/password [email protected] would use the @ syntax to
read the secret value from a file named data.txt, which could be encrypted or protected by file
permissions, and store it in the key/value secrets engine at the path secret/password. The file name
would be visible in the shell history, but not the secret value. D. vault kv put secret/password value-
SSECRET_VALUE would use the -S syntax to read the secret value from the environment variable
SECRET_VALUE, which could be set and unset in the shell session, and store it in the key/value
secrets engine at the path secret/password. The environment variable name would be visible in the
shell history, but not the secret value.
Reference:
[Write Secrets | Vault | HashiCorp Developer]

Answer:

B

Explanation:
Not all storage backends support high availability mode for Vault. Only the storage backends that
support locking can enable Vault to run in a multi-server mode where one server is active and the
others are standby. Some examples of storage backends that support high availability mode are
Consul, Integrated Storage, and ZooKeeper.
Some examples of storage backends that do not support
high availability mode are Filesystem, MySQL, and PostgreSQL. Reference:
https://developer.hashicorp.com/vault/docs/concepts/ha1,
https://developer.hashicorp.com/vault/docs/configuration/storage2

Answer:

A

Explanation:
The vault kv put command writes the data to the given path in the K/V secrets engine. The command
requires the mount path of the K/V secrets engine, the secret path, and the key-value pair to store.
The mount path can be specified with the -mount flag or as part of the secret path. The key-value
pair can be given as an argument or read from a file or stdin. The correct syntax for the command is:
vault kv put -mount=secret my-secrets/my-password 53cr3t
or
vault kv put secret/my-secrets my-password=53cr3t
The other options are incorrect because they use the deprecated vault kv write command, or they
have the wrong order or format of the arguments. Reference:
https://developer.hashicorp.com/vault/docs/commands/kv/put3,
https://developer.hashicorp.com/vault/docs/commands/kv4

Answer:

C

Explanation:
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

Answer:

B

Explanation:
The environment variable VAULT_ADDR overrides the CLI’s default Vault server address. The
VAULT_ADDR environment variable specifies the address of the Vault server that is used to
communicate with Vault from other applications or processes. By setting this variable, you can avoid
hard-coding the Vault server address in your code or configuration files, and you can also use
different addresses for different environments or scenarios. For example, you can use a local
development server for testing purposes, and a production server for deploying your
application. Reference:
Commands (CLI) | Vault | HashiCorp Developer
,
Vault Agent - secrets as
environment variables | Vault | HashiCorp Developer

Answer:

A

Explanation:
The CLI command vault login -method ldap username=mitchellh generates a token that is response
wrapped. This means that the token contains a base64-encoded response wrapper, which is a JSON
object that contains information about the token, such as its policies, metadata, and expiration time.
The response wrapper is used to verify the authenticity and integrity of the token, and to prevent
replay attacks. The response wrapper also allows Vault to automatically renew the token when it
expires, or to revoke it if it is compromised. The -method ldap option specifies that the
authentication method is LDAP, which requires a username and password to be provided. The
username mitchellh is an example of an LDAP user name, and the password will be hidden when
entered. Reference:
Vault CLI Reference | Vault | HashiCorp Developer
,
Vault CLI Reference | Vault |
HashiCorp Developer

Answer:

C

Explanation:
The three policies that exist in Vault are:
admins: This policy grants full access to all secrets and operations in Vault. It can be used by
administrators or operators who need to manage all aspects of Vault.
default: This policy grants access to all secrets and operations in Vault except for those that require
specific policies. It can be used as a fallback policy when no other policy matches.
transit: This policy grants access only to the transit secrets engine, which handles cryptographic
functions on data in-transit. It can be used by applications or services that need to encrypt or decrypt
data using Vault.
These policies allow an organization to perform useful tasks such as:
Encrypting, decrypting, and rewrapping data using the transit engine all in one policy: This policy
grants access to both the transit secrets engine and the default policy, which allows performing any
operation on any secret in Vault.
Creating a transit encryption key for encrypting, decrypting, and rewrapping encrypted data: This
policy grants access only to the transit secrets engine and its associated keys, which are used for
encrypting and decrypting data in transit using AES-GCM with a 256-bit AES key or other supported
key types.
Separating permissions allowed on actions associated with the transit secret engine: This policy
grants access only to specific actions related to the transit secrets engine, such as creating keys or
wrapping requests. It does not grant access to other operations or secrets in Vault.

Answer:

A

Explanation:
The Google Cloud Secrets Engine is the best option for the DevOps team to provision VMs in GCP via
a CICD pipeline and integrate Vault to protect the credentials used by the tool. The Google Cloud
Secrets Engine can dynamically generate GCP service account keys or OAuth tokens based on IAM
policies, which can be used to authenticate and authorize the CICD tool to access GCP resources. The
credentials are automatically revoked when they are no longer used or when the lease expires,
ensuring that the credentials are short-lived and secure. The DevOps team can configure rolesets or
static accounts in Vault to define the scope and permissions of the credentials, and use the Vault API
or CLI to request credentials on demand.
The Google Cloud Secrets Engine also supports generating
access tokens for impersonated service accounts, which can be useful for delegating access to other
service accounts without storing or managing their keys1
.
The Identity Secrets Engine is not a good option for this use case, because it does not generate GCP
credentials, but rather generates identity tokens that can be used to access other Vault secrets
engines or namespaces2
.
The Key/Value Secrets Engine version 2 is also not a good option, because
it does not generate dynamic credentials, but rather stores and manages static secrets that the user
provides3
.
The SSH Secrets Engine is not a good option either, because it does not generate GCP
credentials, but rather generates SSH keys or OTPs that can be used to access remote hosts via SSH4
.
Reference:
Google Cloud - Secrets Engines | Vault | HashiCorp Developer
Identity - Secrets Engines | Vault | HashiCorp Developer
KV - Secrets Engines | Vault | HashiCorp Developer
SSH - Secrets Engines | Vault | HashiCorp Developer