HashiCorp HashiCorp Certifications VAULT-ASSOCIATE Questions & Answers

• Question 21:

  Which of the following is a machine-oriented Vault authentication backend?

  A. Okta

  B. AppRole

  C. Transit

  D. GitHub

  Correct Answer: B

  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 aunique 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. References: AppRole Auth Method | Vault | HashiCorp Developer Okta Auth Method | Vault | HashiCorp Developer GitHub Auth Method | Vault | HashiCorp Developer Transit Secrets Engine | Vault | HashiCorp Developer

• Question 22:

  When looking at Vault token details, which key helps you find the paths the token is able to access?

  A. Meta

  B. Path

  C. Policies

  D. Accessor

  Correct Answer: C

  When looking at Vault token details, the policies key helps you find the paths the token is able to access. Policies are a declarative way to grant or forbid access to certain paths and operations in Vault. Policies are written in HCL or JSON and

  are attached to tokens by name. Policies are deny by default, so an empty policy grants no permission in the system. A token can have one or more policies associated with it, and the effective policy is the union of all the individual policies.

  You can view the token details by using the vault token lookup command or the auth/token/lookup API endpoint. The output will show the policies key with a list of policy names that are attached to the token. You can also view the contents of

  a policy by using the vault policy read command or the sys/policy API endpoint. The output will show the rules key with the HCL or JSON representation of the policy. The rules will specify the paths and the capabilities (such as create, read,

  update, delete, list, etc.) that the policy allows or denies. References:

  https://developer.hashicorp.com/vault/docs/concepts/policies4, https://developer.hashicorp.com/vault/docs/commands/token/lookup5, https://developer.hashicorp.com/vault/api-docs/auth/token#lookup-a- token6,https://

  developer.hashicorp.com/vault/docs/commands/policy/read7, https://developer.hashicorp.com/vault/api-docs/system/policy8

• Question 23:

  Which of these is not a benefit of dynamic secrets?

  A. Supports systems which do not natively provide a method of expiring credentials

  B. Minimizes damage of credentials leaking

  C. Ensures that administrators can see every password used

  D. Replaces cumbersome password rotation tools and practices

  Correct Answer: C

  Dynamic secrets are generated on-demand by Vault and have a limited time-to-live (TTL). They do not ensure that administrators can see every password used, as they are often encrypted and ephemeral. The benefits of dynamic secrets are: They support systems that do not natively provide a method of expiring credentials, such as databases, cloud providers, SSH, etc. Vault can revoke the credentials when they are no longer needed or when the lease expires. They minimize the damage of credentials leaking, as they are short-lived and can be easily rotated or revoked. If a credential is compromised, the attacker has a limited window of opportunity to use it before it becomes invalid. They replace cumbersome password rotation tools and practices, as Vault can handle the generation and revocation of credentials automatically and securely. This reduces the operational overhead and complexity of managing secrets. References: https:// developer.hashicorp.com/vault/tutorials/getting-started/getting-started- dynamic-secrets1, https://developer.hashicorp.com/vault/docs/concepts/lease2

• Question 24:

  What is a benefit of response wrapping?

  A. Log every use of a secret

  B. Load balanc secret generation across a Vault cluster

  C. Provide error recovery to a secret so it is not corrupted in transit

  D. Ensure that only a single party can ever unwrap the token and see what's inside

  Correct Answer: D

  Response wrapping is a feature that allows Vault to take the response it would have sent to a client and instead insert it into the cubbyhole of a single-use token, returning that token instead. The client can then unwrap the token and retrieve the original response. Response wrapping has several benefits, such as providing cover, malfeasance detection, and lifetime limitation for the secret data. One of the benefits is to ensure that only a single party can ever unwrap the token and see what's inside, as the token can be used only once and cannot be unwrapped by anyone else, even the root user or the creator of the token. This provides a way to securely distribute secrets to the intended recipients and detect any tampering or interception along the way5. The other options are not benefits of response wrapping: Log every use of a secret: Response wrapping does not log every use of a secret, as the secret is not directly exposed to the client or the network. However, Vault does log the creation and deletion of the response-wrapping token, and the client can use the audit device to log the unwrapping operation6. Load balance secret generation across a Vault cluster: Response wrapping does not load balance secret generation across a Vault cluster, as the secret is generated by the Vault server that receives the request and the response- wrapping token is bound to that server. However, Vault does support high availability and replication modes that can distribute the load and improve the performance of the cluster7. Provide error recovery to a secret so it is not corrupted in transit: Response wrapping does not provide error recovery to a secret so it is not corrupted in transit, as the secret is encrypted and stored in the cubbyhole of the token and cannot be modified or corrupted by anyone. However, if the token is lost or expired, the secret cannot be recovered either, so the client should have a backup or retry mechanism to handle such cases. References: 5(https://developer.hashicorp.com/vault/docs/concepts/response- wrapping), 6(https://developer.hashicorp.com/vault/docs/secrets), 7(https://developer.hashi corp.com/vault/docs/secrets), (https://developer.hashicorp.com/vault/ tutorials/secrets- management/cubbyhole-response-wrapping)

• Question 25:

  How many Shamir's key shares are required to unseal a Vault instance?

  A. All key shares

  B. A quorum of key shares

  C. One or more keys

  D. The threshold number of key shares

  Correct Answer: D

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

• Question 26:

  A web application uses Vault's transit secrets engine to encrypt data in-transit. If an attacker intercepts the data in transit which of the following statements are true? Choose two correct answers.

  A. You can rotate the encryption key so that the attacker won't be able to decrypt the data

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

  C. The Vault administrator would need to seal the Vault server immediately

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

  Correct Answer: BD

  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. References: Transit Secrets Engines | Vault | HashiCorp Developer, Encryption as a service: transit secrets engine | Vault | HashiCorp Developer

• Question 27:

  You are using Vault's Transit secrets engine to encrypt your data. You want to reduce the amount of content encrypted with a single key in case the key gets compromised. How would you do this?

  A. Use 4096-bit RSA key to encrypt the data

  B. Upgrade to Vault Enterprise and integrate with HSM

  C. Periodically re-key the Vault's unseal keys

  D. Periodically rotate the encryption key

  Correct Answer: D

  The Transit secrets engine supports the rotation of encryption keys, which allows you to change the key that is used to encrypt new data without affecting the ability to decrypt data that was already encrypted. This reduces the amount of content encrypted with a single key in case the key gets compromised, and also helps you comply with the NIST guidelines for key rotation. You can rotate the encryption key manually by invoking the /transit/keys//rotate endpoint, or you can configure the key to automatically rotate based on a time interval or a number of encryption operations. When you rotate a key, Vault generates a new key version and increments the key's latest_version metadata. The new key version becomes the encryption key used for encrypting any new data. The previous key versions are still available for decrypting the existing data, unless you specify a minimum decryption version to archive the old key versions. You can also delete or disable old key versions if you want to revoke access to the data encrypted with those versions. References: https://developer.hashicorp.com/vault/docs/secrets/transit1, https://developer.hashicorp.com/vault/api-docs/secret/ transit2

• Question 28:

  The vault lease renew command increments the lease time from:

  A. The current time

  B. The end of the lease

  Correct Answer: A

  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. References: Lease, Renew, and Revoke | Vault | HashiCorp Developer

• Question 29:

  A developer mistakenly committed code that contained AWS S3 credentials into a public repository. You have been tasked with revoking the AWS S3 credential that was in the code. This credential was created using Vault's AWS secrets engine and the developer received the following output when requesting a credential from Vault.

  

  Which Vault command will revoke the lease and remove the credential from AWS?

  A. vault lease revoke aws/creds/s3-access/f3e92392-7d9c-99c8-c921-57Sd62fe89d8

  B. vault lease revoke AKIAI0WQXTLW36DV7IEA

  C. vault lease revoke f3e92392-7d9c-O9c8-c921-575d62fe80d8

  D. vault lease revoke access_key-AKIAI0WQXTLW36DV7IEA

  Correct Answer: A

  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. References: lease revoke - Command | Vault | HashiCorp Developer

• Question 30:

  You are performing a high number of authentications in a short amount of time. You're experiencing slow throughput for token generation. How would you solve this problem?

  A. Increase the time-to-live on service tokens

  B. Implement batch tokens

  C. Establish a rate limit quota

  D. Reduce the number of policies attached to the tokens

  Correct Answer: B

  Batch tokens are a type of tokens that are not persisted in Vault's storage backend, but are encrypted blobs that carry enough information to perform Vault actions. Batch tokens are extremely lightweight and scalable, and can improve the throughput for token generation. Batch tokens are suitable for high-volume and ephemeral workloads, such as containers or serverless functions, that require short-lived and non-renewable tokens. Batch tokens can be created by using the type=batch flag in the vault token create command, or by configuring the token_type parameter in the auth method's role or mount options. Batch tokens have some limitations compared to service tokens, such as the lack of renewal, revocation, listing, accessor, and cubbyhole features. Therefore, batch tokens should be used with caution and only when the trade-offs are acceptable. References: https://developer.hashicorp.com/vault/tutorials/tokens/batch-tokens1, https://developer.hashicorp.com/vault/docs/commands/token/create2, https://developer.hashicorp.com/vault/docs/concepts/tokens#token-types3