Free HashiCorp HCVA0-003 Practice Exam with Questions & Answers | Set: 10

Comprehensive and Detailed In-Depth Explanation:

Dynamic credentials are tracked by leases, revocable via vault lease revoke. The Vault documentation states:

" The vault lease revoke command is used to revoke a lease/secret created by a Vault secrets engine. Each lease that is created is tracked using a unique lease ID, which can be used to renew or revoke a lease.

You can revoke an individual lease using the command vault lease revoke < lease_id >

You can also revoke ALL leases from a secrets engine using the -prefix flag, such as vault lease revoke -prefix azure/

You can also revoke leases created from a specific role by using the -prefix flag but specifying the path all the way to the role like this: vault lease revoke -prefix azure/creds/ < role_name > " — Vault Commands: lease revoke

B : Correct. vault lease revoke -prefix azure/ revokes all leases under azure/.

C : Correct. vault lease revoke azure/creds/bryan-krausen/9eed0373-ca92-99b6-b914-779b7bb0e1d9 targets the specific lease ID.

E : Correct. vault lease revoke -prefix azure/creds/bryan-krausen revokes all leases for that role.

A : Incorrect; lacks the -prefix flag, making it invalid syntax.

D : Incorrect; lacks the -prefix flag and isn’t a full lease ID.

Comprehensive and Detailed In-Depth Explanation:

Vault Enterprise supports two replication types: Performance Replication and Disaster Recovery (DR) Replication. The key requirement here is that applications must continue interacting with Vault without re-authenticating during a failover from the primary to the secondary cluster. DR Replication is designed for this exact scenario. It replicates all data, including tokens and leases, from the primary cluster to the secondary cluster. When the secondary is promoted to primary during a failover, the existing tokens remain valid, allowing applications to seamlessly continue operations without re-authentication.

Performance Replication, while improving scalability and performance by replicating data across clusters, manages its own tokens and leases on each secondary cluster. Tokens from the primary are not replicated, so a failover would invalidate existing tokens, requiring applications to re-authenticate—failing the requirement. Integrated Storage is a storage backend, not a replication type, and doesn’t address failover behavior. The Vault Secrets Operator is a Kubernetes tool for secret management, unrelated to cluster replication. According to Vault’s DR Replication documentation, it ensures continuity of token validity, making it the correct choice.

Comprehensive and Detailed In-Depth Explanation:

Assuming the screenshot shows a KV secrets engine at developers/ with version 5 of a secret and options for delete/create:

C : KV v2 is indicated by versioning (version 5 and four previous versions). KV v1 doesn’t support versioning, per the KV v2 documentation.

D : The path developers/ is the mount point, as secrets are accessed under this path, consistent with Vault’s mount structure.

E : Four previous versions (v1–v4) exist if v5 is current, a feature of KV v2’s versioning.

F : Delete and create options in the UI imply permissions beyond list and read, such as delete and create or update, per Vault’s UI behavior reflecting policy capabilities.

A : KV v1 lacks versioning, so this is incorrect.

B : The delete option’s presence suggests permission exists, though UI visibility isn’t a definitive policy check—still, it’s typically indicative.

Comprehensive and Detailed In-Depth Explanation:

The token auth method is foundational to Vault. The Vault documentation states:

" Tokens are the core method for authentication within Vault. It is also the only auth method that cannot be disabled. If you’ve gone through the getting started guide, you probably noticed that vault server -dev (or vault operator init for a non-dev server) outputs an initial ' root token. ' This is the first method of authentication for Vault. All external authentication mechanisms, such as GitHub, map down to dynamically created tokens. "

— Vault Concepts: Tokens

A , B , C : Correct per the above.

D : Incorrect; tokens can be used directly:

" Tokens can be used directly or auth methods can be used to dynamically generate tokens based on external identities. "

— Vault Concepts: Tokens

Comprehensive and Detailed In-Depth Explanation:

AppRole is optimal for machine authentication. The Vault documentation states:

" AppRole is an auth method that is better suited for machine-to-machine authentication. The AppRole auth method allows machines or applications to authenticate with Vault using a role-specific secret ID and role ID. "

— Vault Auth: AppRole

D : Correct. Ideal for dynamic Oracle credentials:

" AppRole is the best auth method to use in this scenario because it allows machines or applications to authenticate with Vault. "

— Vault Auth: AppRole

A , B , C : Human-oriented, not machine-suited.

Comprehensive and Detailed In-Depth Explanation:

The Transit secrets engine in Vault is designed for encryption as a service, allowing applications to encrypt data without managing keys locally. After enabling the engine, two critical steps are required before encryption can begin: creating an encryption key and defining a policy to allow its use.

Option C: You must create an encryption key using a command like vault write -f transit/keys/ < key_name > . This key is stored in Vault and used for encryption/decryption operations. Without it, no encryption can occur, as the Transit engine relies on named keys to perform cryptographic operations.

Option D: A policy must be written to grant the application permissions to use the key, such as path " transit/encrypt/ < key_name > " { capabilities = [ " update " ] } and path " transit/decrypt/ < key_name > " { capabilities = [ " update " ] }. Vault’s access control ensures that only authorized entities can perform encryption, making this step essential.

Option A (exporting the key) contradicts Vault’s security model, as keys should remain in Vault, not be exported to application servers. Option B (enabling the Transit API) is unnecessary, as enabling the engine automatically exposes its API endpoints. The official Transit documentation confirms that key creation and policy configuration are the next steps post-enablement.

Comprehensive and Detailed In-Depth Explanation:

Vault supports multiple auth methods by default. The Vault documentation states:

" Auth methods are the components in Vault that perform authentication and are responsible for assigning identity and a set of policies to a user. Available auth methods include AppRole, JWT/OIDC, Kubernetes, LDAP, and more. "

— Vault Auth Methods

B : Kubernetes is supported:

" Kubernetes authentication method in Vault allows Kubernetes service accounts to authenticate with Vault. "

— Vault Auth: Kubernetes

D : LDAP is supported:

" LDAP authentication method allows users to authenticate against an LDAP directory. "

— Vault Auth: LDAP

E : AppRole is supported:

" AppRole authentication method in Vault allows machines or applications to authenticate with Vault. "

— Vault Auth: AppRole

F : JWT is supported:

" JWT authentication method in Vault allows users to authenticate using JSON Web Tokens (JWT). "

— Vault Auth: JWT

A : SSH is a secrets engine, not an auth method.

C : VMware is not a default auth method.