Free HashiCorp Vault Associate Sample Questions

Correct answer: A — GitHub

• A. Correct. The GitHub auth method is specifically designed to allow users to authenticate to Vault using their GitHub personal access tokens. It integrates seamlessly with existing GitHub workflows by mapping GitHub organizations and teams to Vault policies, making it the most straightforward solution for this team.
• B. Incorrect. OIDC (OpenID Connect) is typically used for federated identity management and involves a browser-based login flow. While GitHub can act as an identity provider, it is more complex to set up than the native GitHub auth method and is not designed to consume existing personal access tokens directly for authentication.
• C. Incorrect. The Userpass auth method involves managing unique usernames and passwords within Vault itself. This would require the team to manage a second set of credentials rather than leveraging their existing GitHub tokens.
• D. Incorrect. AppRole is the primary method for machine-to-machine authentication, involving RoleIDs and SecretIDs. It is not intended for human users looking for a simple way to authenticate using their version control system credentials.

Correct answer: A — To map multiple authentication methods to a single logical user.

• A. Correct. An Entity represents a single logical user in Vault. It serves as a container that links multiple aliases from various authentication methods (such as LDAP, GitHub, or AppRole) to one identity, allowing for unified identity management and policy application.
• B. Incorrect. The task of authenticating against external identity providers is handled by Vault's various Authentication Methods (e.g., LDAP, OIDC). Entities are used to correlate these identities within Vault after authentication.
• C. Incorrect. The Identity secrets engine is for managing user and group identities. Static or dynamic database credentials are managed by the Database secrets engine or the Key/Value secrets engine.
• D. Incorrect. Token TTL (Time-To-Live) settings are governed by the authentication method configuration, mount-level tuning, or token roles, rather than the Identity Entity itself.

Correct answer: B — To verify a client's identity and issue a Vault token.

• A. Incorrect. Encrypting data in transit is handled by TLS/SSL, not by Vault authentication methods. Authentication methods focus on proving identity rather than transport-level security.
• B. Correct. The primary function of an authentication method in HashiCorp Vault is to verify a client's identity using a supported login mechanism and, upon successful verification, issue a Vault token that the client uses for subsequent requests.
• C. Incorrect. Defining access control rules and permissions is the role of the authorization process (policies), not the authentication method. While auth methods map identities to policies, they do not define the rules themselves.
• D. Incorrect. Storing static secrets like database passwords and API keys is the responsibility of secrets engines. Authentication methods are strictly used for identity verification and session establishment.

Correct answer: B — /sys/auth

• A. Incorrect. The /sys/mounts endpoint is used specifically for managing and listing secret engine mounts. It is not used for authentication methods.
• B. Correct. An authenticated GET request to the /sys/auth endpoint returns a list of all enabled authentication backends along with their configuration details, such as the mount point, type, and tuning information.
• C. Incorrect. /auth/catalog is not a valid Vault API endpoint. Vault manages system-level configurations, including authentication methods, under the /sys/ prefix.

Correct answer: B — POST request; parameters placed in the JSON request body.

• A. Incorrect. GET requests are unsuitable for authentication because sensitive credentials like `role_id` and `secret_id` would be exposed in URL query strings, which are frequently logged by web servers, proxies, and browser history.
• B. Correct. The AppRole authentication method via the HTTP API requires a POST request to the login endpoint (e.g., `/v1/auth/approle/login`). The `role_id` and `secret_id` must be securely transmitted within the JSON-formatted request body.
• C. Incorrect. Vault uses the POST method for AppRole login, not PUT. Furthermore, the login credentials should be provided in the request payload rather than in custom HTTP headers.
• D. Incorrect. While POST is the correct HTTP method, Vault's API specification for AppRole requires the credentials to be passed in the JSON body, not as URL query parameters.

Correct answer: A — True

• A. The statement is true because human authentication methods (such as OIDC, LDAP, or userpass) are optimized for manual user interactions involving credentials or multi-factor authentication, while system methods (such as AppRole, Kubernetes, or AWS) are designed for non-interactive, automated machine-to-machine workflows.
• B. The statement is false because system authentication methods are specifically engineered for machines and services to authenticate without human intervention, often using methods like API keys or service accounts, rather than interactive login flows intended for people.

Correct answer: B — By mapping the policies to an Identity Group and adding the developers' entity aliases to that group.

• A. Vault policies are managed within Vault itself, not the external OIDC provider. While identity providers handle authentication and provide identity assertions, the authorization logic and policy mapping are handled inside Vault's Identity engine.
• B. Using Vault's Identity Groups is the recommended and most scalable method for managing permissions centrally. By assigning policies to a group and adding developers' entity aliases to that group, permissions are automatically inherited, simplifying administration for large numbers of users.
• C. Distributing a single shared token is a critical security risk. It violates the principle of least privilege and makes it impossible to audit individual actions or revoke access for a single specific user without affecting everyone.
• D. Vault policies are independent API objects managed via the CLI, API, or UI and stored in Vault's persistent storage. They are not defined or attached within the server's main HCL configuration file.

Correct answer: A — It matches `secret/data/team/dev/config` but does not match `secret/data/team/dev/app/config`.

• A. Correct. In Vault path globbing, the `+` character matches exactly one path segment. In the path `secret/data/team/dev/config`, the string `dev` represents exactly one segment, making it a match. The path `secret/data/team/dev/app/config` fails because it has two segments (`dev/app`) where the policy only allows one.
• B. Incorrect. The `+` character matches only a single path segment, not an arbitrary directory depth. Recursive matching across multiple directories is not supported by the `+` operator.
• C. Incorrect. In the context of Vault policy paths, `+` is a special glob character and is not treated as a literal character unless escaped or used in a context where globbing is disabled.
• D. Incorrect. This reverses the correct logic. `secret/data/team/dev/config` matches because it has a single segment in the `+` position, while `secret/data/team/dev/app/config` does not match because it contains two segments.

Correct answer: B — app-secrets/data/db-credentials

• A. Incorrect. In the KV version 2 secrets engine, the secret payload is not accessed directly at the root path of the mount (which was the standard for KV version 1). A specific API subpath must be included between the mount point and the secret name.
• B. Correct. The KV version 2 secrets engine introduces a versioned API structure. To access the actual secret payload (the data itself), the path must include the 'data/' subpath. Therefore, the correct policy path is 'app-secrets/data/db-credentials'.
• C. Incorrect. The 'metadata/' subpath is used for administrative tasks related to the secret, such as listing versions, updating metadata settings, or deleting all versions. It does not grant access to the actual secret key-value pairs (the payload).
• D. Incorrect. There is no 'read/' subpath in the Vault KV version 2 API. Reading, writing, and updating a secret's payload are all performed through the 'data/' endpoint, with the specific action controlled by the policy capabilities (read, create, update).

Correct answer: B — vault policy list

• A. Incorrect. While Vault uses 'list' subcommands for many paths, the dedicated CLI command group for policies is 'vault policy'. The syntax 'vault list policies' does not map to a valid command.
• B. Correct. The 'vault policy list' command is the standard CLI tool to retrieve and display the names of all configured policies in the Vault cluster.
• C. Incorrect. The 'vault policy show' command is used to display the specific rules and contents of a single policy. It requires a policy name as an argument and cannot be used to list all policies.
• D. Incorrect. 'vault get' is not a valid command for policy operations. Vault organizes policy management under the 'vault policy' command group.

Correct answer: B — path "secret/data/app-config" { capabilities = ["read"] }

• A. Incorrect. This path is incorrect for a KV version 2 secrets engine. In KV v2, the path to read a secret requires an internal 'data/' prefix; accessing the path directly at the mount point is the behavior for KV version 1.
• B. Correct. In KV version 2, the actual secret data is accessed through the 'data/' path under the mount. Therefore, 'secret/data/app-config' is the correct policy path for reading the secret contents while adhering to the principle of least privilege.
• C. Incorrect. The 'metadata/' path in KV v2 is used for managing secret metadata (such as version history, creation times, and deletion status) but does not provide access to the actual secret key-value pairs.
• D. Incorrect. 'secret/read/app-config' is not a valid API path for the KV version 2 secrets engine. Vault uses specific reserved prefixes like 'data/', 'metadata/', and 'destroy/', but 'read/' is not one of them.

Correct answer: B — False

• A. The statement is false because root tokens cannot be generated through standard token creation commands; creating a root token is a sensitive operation that requires a specialized workflow involving a quorum of unseal or recovery keys.
• B. The statement is false because if a root token is lost, it must be regenerated using the `vault operator generate-root` process, which mandates a threshold of unseal/recovery key holders to participate, ensuring that sudo-level permissions alone cannot bypass Vault's security model for root access.

Correct answer: B — -orphan

• A. Incorrect. The `-no-parent` flag is not a valid option for the `vault token create` command. While the name implies the intended behavior, HashiCorp Vault specifically uses a different flag for this functionality.
• B. Correct. The `-orphan` flag is the correct Vault CLI option used to create an orphaned token. An orphaned token has no parent, meaning it will not be revoked even if the token that created it is revoked.
• C. Incorrect. The `-detached` flag is not a valid option for the `vault token create` command. Vault uses the `-orphan` flag to signify a token that exists independently of its creator's lifecycle.

Correct answer: B — It minimizes the window of opportunity for an attacker if the token is compromised.

• A. Time-to-Live (TTL) defines the validity period of a token. While Vault eventually purges expired tokens from its backend, the primary purpose of TTL is access control duration, not storage optimization.
• B. A shorter TTL limits the duration for which a token is valid. This minimizes the 'window of opportunity' for an unauthorized user or attacker to utilize the token if it is compromised, which is a core security best practice.
• C. TTL determines how long a token remains valid, but it does not restrict the capabilities of the token. A valid token can still generate dynamic secrets if its associated policies allow it.
• D. Encryption in transit is a separate security layer handled by TLS/HTTPS. TTL only governs the expiration of the token itself and does not impact data encryption methods.

Correct answer: B — When Vault cannot reach the target system to revoke the credential, and the lease needs to be removed from Vault's tracking.

• A. Incorrect. The -force flag is not used to purge expired leases from audit logs. Vault handles expired leases through its internal lease management system automatically, and audit logs are append-only records of actions, not something managed via lease revocation.
• B. Correct. The -force flag is used when Vault encounters errors while trying to contact the target backend (e.g., AWS, a database) to revoke a credential. It allows Vault to remove the lease from its internal data store and stop retry attempts, even if it cannot confirm the secret was successfully revoked on the remote system.
• C. Incorrect. Static secrets typically do not utilize leases in the same way dynamic secrets do. The -force flag is specifically designed to handle failures in the dynamic revocation flow, not to distinguish between secret types.
• D. Incorrect. The -force flag is a functional parameter for the revocation command and does not bypass Vault's Access Control Lists (ACLs). An operator requires specific 'update' or 'sudo' permissions on the sys/leases paths to perform revocation regardless of the flags used.

Correct answer: A — vault lease revoke -prefix aws/creds/my-role

• A. Correct. The 'vault lease revoke' command supports a '-prefix' flag. This allows an administrator to revoke all leases matching a specific path prefix (e.g., 'aws/creds/my-role') in a single operation, which is the standard procedure when individual lease IDs are unknown or too numerous to handle individually.
• B. Incorrect. The 'vault token revoke -mode=path' command is specifically used for revoking authentication tokens associated with a certain path. It does not target dynamic secret leases managed by secrets engines like AWS.
• C. Incorrect. While disabling a secrets engine will revoke all associated leases, it is an extreme measure. It deletes the entire engine configuration and all roles defined within it, making it inappropriate for revoking credentials from a single compromised role.
• D. Incorrect. 'vault lease delete' is not a valid Vault command. To invalidate a lease and its associated credentials before they naturally expire, you must use the 'revoke' subcommand.

Correct answer: A — vault token renew

• A. Correct. The `vault token renew` command is the standard CLI command for renewing tokens. When executed without a specific token ID provided as an argument, it automatically attempts to renew the token currently stored in the local environment or token helper (~/.vault-token).
• B. Incorrect. The `vault auth` subcommand is used for managing authentication methods (such as enabling, disabling, or tuning auth backends like GitHub or AppRole). It does not contain a `renew` command for token maintenance.
• C. Incorrect. While tokens are technically a form of lease in Vault's architecture, the CLI maintains a distinction between the two. `vault lease renew` is strictly used for leases generated by secret engines (dynamic secrets), whereas tokens must be renewed via the `token` subcommand.
• D. Incorrect. The `vault login` command is used to perform the initial authentication against a specific method to obtain a token. It does not have a `-renew` flag; existing tokens are renewed via `vault token renew`.

Correct answer: B — False

• A. The statement is false because dynamic secrets are designed to be ephemeral and unique to every request. While Vault stores metadata about the lease (such as the creation time and TTL) to manage revocation, it does not cache or store the actual credentials for the purpose of sharing them with other users or subsequent requests.
• B. The statement is false because the primary function of a dynamic secrets engine is to generate fresh, on-demand credentials for each requester. Vault acts as a broker rather than a persistent storage for these secrets; once a request is made, a new set of credentials is created specifically for that lease and is not reused for other requests even if they target the same role.

Correct answer: C — Cubbyhole

• A. The Transit secrets engine is used for cryptographic operations like encryption, decryption, and signing (encryption-as-a-service). It does not provide the storage mechanism for wrapped responses.
• B. KV Version 2 is a persistent key-value store with versioning capabilities. While it stores secrets, it is not the specialized ephemeral storage mechanism Vault uses to hold wrapped response tokens and their contents.
• C. The Cubbyhole secrets engine provides a private, per-token storage space. Under the hood, Vault utilizes Cubbyhole for response wrapping because it offers ephemeral storage tied specifically to the lifetime of the wrapping token, ensuring the data is only accessible to the token holder.
• D. The Identity secrets engine manages entities, aliases, and group membership for identity-based access control. It does not handle the temporary storage requirements of the response wrapping workflow.

Correct answer: C — Create credentials on the target system dynamically upon request

• A. Incorrect. Dynamic secrets engines are not characterized by plaintext storage or retrieval performance optimization. Instead, they focus on the on-demand generation of unique credentials that do not exist until requested.
• B. Incorrect. A key feature of dynamic secrets is that HashiCorp Vault manages their lifecycle. Vault automatically revokes these credentials when their lease expires, eliminating the need for manual cleanup on the target system.
• C. Correct. Unlike the KV engine which stores static data, dynamic secrets engines generate credentials on-the-fly on the target system (such as a database or cloud provider) when a client requests them. These credentials have an associated TTL and are unique to the requester.
• D. Incorrect. Dynamic secrets engines are designed for both human users and machine identities. In fact, they are highly beneficial for programmatic access (applications, CI/CD pipelines) to ensure temporary, limited-scope access with a clear audit trail.

Correct answer: B — Store the static API key in the Key/Value (KV) secrets engine.

• A. AppRole is an authentication method used by machines and applications to authenticate to Vault and obtain a token. It is not used for managing or generating third-party credentials like SaaS API keys.
• B. When a provider does not support dynamic credential generation via an API, Vault's Key/Value (KV) secrets engine is the standard tool for securely storing and managing access to static secrets. This allows the application to retrieve the static key while Vault controls access via policies.
• C. Building a custom dynamic secrets engine requires the target SaaS provider to have an API that supports programmatic creation and revocation of credentials. Since the provider in this scenario does not support this, a dynamic engine cannot be implemented.
• D. The Transit secrets engine provides 'Encryption as a Service' (performing cryptographic operations like encryption, decryption, and signing). It does not store static secrets or generate credentials for third-party providers.

Correct answer: B — Dynamic secrets are generated on-demand and unique to the client, whereas static secrets are pre-created and shared.

• A. Incorrect. Both dynamic and static secrets are protected by Vault using encryption at rest and encryption in transit (via TLS). Encryption is a core property of Vault and not the distinguishing factor between secret types.
• B. Correct. Dynamic secrets are generated only when requested (on-demand) and are typically unique to the specific client or lease. Static secrets (such as those in the KV engine) are pre-created, persistent, and are often shared across multiple users or applications until they are manually updated.
• C. Incorrect. All secrets in Vault, whether dynamic or static, can be accessed through the API, CLI, and the UI. The interface used to retrieve the secret does not define its classification.
• D. Incorrect. This statement is the opposite of how Vault works. Dynamic secrets rely on a lease system with a Time-To-Live (TTL) and are automatically revoked by Vault when the lease expires. Static secrets generally do not have a TTL and remain valid until manually changed or deleted.

Correct answer: B — -field=<key>

• A. The `-format=json` flag changes the output format to structured JSON, but it still returns the full response including metadata. It does not isolate and return only a single raw value.
• B. The `-field=<key>` flag is the correct Vault CLI option to extract only the value of a specific field. It strips away all table formatting, headers, and metadata, making it ideal for scripting or piping into environment variables.
• C. There is no `-extract` flag for the `vault kv get` command. Vault uses the `-field` flag for this functionality.
• D. `-value-only` is not a valid flag in the Vault CLI. The intended functionality is provided by the `-field` flag.

Correct answer: B — vault secrets enable aws

• A. Incorrect. The command 'vault enable aws' is missing the 'secrets' subcommand. Vault requires the 'vault secrets' command group to manage secrets engines.
• B. Correct. 'vault secrets enable aws' is the standard CLI command to enable the AWS secrets engine at its default path, which is 'aws/'. This follows the standard 'vault secrets enable <path>' syntax.
• C. Incorrect. 'vault mount' was used in legacy versions of Vault (pre-0.10.0). While it may exist as a legacy alias in some contexts, the current and official CLI syntax for the Vault Associate exam is 'vault secrets enable'.
• D. Incorrect. 'vault engine enable aws' is not a valid command. Vault does not use 'engine' as a top-level CLI subcommand for enabling secrets engines; it uses 'secrets'.

Correct answers: B, C — Generate a Data Encryption Key (DEK) using the /transit/datakey endpoint; Encrypt the large file locally within the application using the generated plaintext DEK

• A. The Transit secrets engine's /encrypt endpoint is not designed for very large files as it requires sending the entire payload to Vault. Furthermore, there is no large_file=true parameter available in the Transit API.
• B. Correct. The Transit /datakey endpoint is specifically designed for envelope encryption. It generates a high-entropy data encryption key (DEK) and returns both a plaintext version for immediate use and a ciphertext version (wrapped by Vault) for safe storage.
• C. Correct. In the envelope encryption pattern, the application uses the plaintext DEK to encrypt large files locally. This avoids the network overhead and memory constraints associated with sending large payloads to Vault, leveraging Vault strictly for key management.
• D. Storing a plaintext DEK alongside encrypted data defeats the purpose of encryption. Only the encrypted (wrapped) version of the DEK should be stored; the plaintext key should be used in memory and then discarded.
• E. The Transit /hash endpoint is used for generating cryptographic hashes (like SHA-256) to ensure data integrity, not for compressing files or reducing their size for encryption.

Correct answer: A — True

• A. The statement is true because convergent encryption is a mode where the encryption process is deterministic based on the provided context. By deriving the nonce from the context and the plaintext, Vault ensures that identical inputs result in identical outputs, which is particularly useful for tasks like data deduplication or searching encrypted records.
• B. The statement is false because while standard Transit encryption is non-deterministic (producing different ciphertexts for the same input to prevent frequency analysis), enabling convergent encryption specifically changes this behavior to produce deterministic results when the same context is applied.

Correct answers: A, B — Configure the key with the `auto_rotate_period` parameter set to a valid duration (e.g., 90d).; Ensure the Vault cluster remains unsealed, as auto-rotation relies on Vault's internal periodic tasks.

• A. The `auto_rotate_period` parameter is the native Transit secrets engine setting used to define the frequency of key rotation. Setting this to 90 days (e.g., '90d') allows Vault to manage the rotation schedule internally without external triggers.
• B. Vault's automatic key rotation is handled by internal background periodic tasks. These tasks only execute when the Vault cluster is unsealed and there is an active node available to process the schedule.
• C. Creating an external cron job is an unnecessary manual workaround. Vault's Transit secrets engine has built-in support for scheduled rotation via the `auto_rotate_period` parameter.
• D. The `min_encryption_version` parameter is used to phase out older key versions by enforcing that only newer versions are used for encryption; however, it does not trigger the creation of new key versions.
• E. Key rotation settings are managed per-key within the Transit secrets engine. There is no global `auto_rotate` flag in the `vault.hcl` server configuration file for this purpose.

Correct answer: B — Existing data remains encrypted with the old key, and only new or updated data uses the new key.

• A. Vault does not immediately re-encrypt all existing stored data when the encryption key is rotated. Bulk re-encryption would be resource-intensive and could lead to significant performance issues or downtime. Re-encryption typically happens lazily as data is accessed and rewritten.
• B. Correct. When Vault's barrier encryption key is rotated, a new key is generated and added to the keyring. All subsequent write operations use the new key, but existing data remains encrypted with the older key versions. Vault maintains a keyring of older keys to ensure it can still decrypt existing data when it is read.
• C. Rotating the encryption key is a standard administrative operation and does not cause Vault to enter a sealed state. Vault continues to function normally throughout the rotation process.
• D. Key rotation is a non-destructive process. The storage backend is never wiped or restored from backup during a rotation; Vault simply updates the keys it uses to manage data at the barrier level.

Correct answers: A, B — VAULT_CACERT; VAULT_SKIP_VERIFY

• A. Correct. VAULT_CACERT specifies the path to a PEM-encoded CA certificate file that the Vault CLI uses to verify the Vault server's SSL certificate, ensuring a trusted connection.
• B. Correct. VAULT_SKIP_VERIFY disables SSL certificate verification for the Vault CLI. While useful for troubleshooting or development environments with self-signed certificates, it is not recommended for production due to security risks.
• C. Incorrect. VAULT_IGNORE_TLS is not a valid environment variable for the Vault CLI; the standard variable to bypass verification is VAULT_SKIP_VERIFY.
• D. Incorrect. VAULT_SSL_CERT is not a documented Vault environment variable. To provide a client certificate for TLS authentication, VAULT_CLIENT_CERT is used instead.
• E. Incorrect. VAULT_CERT_PATH is not used by Vault. To specify a directory of CA certificates rather than a single file, the Vault CLI utilizes the VAULT_CAPATH variable.

Correct answer: B — restarted from the beginning

• A. Incorrect. Recovery tokens (or recovery keys in Auto-Unseal configurations) are used for specific recovery operations like generating a root token or authorizing certain system changes. They cannot be used to resume a partial unseal sequence that was interrupted by a server restart.
• B. Correct. Vault's unseal process is stateful and the partial key shares are stored in the server's memory. If the Vault process is restarted, the volatile memory is cleared, causing the unseal progress to be lost. Therefore, the sequence must be started again from the beginning by all required key holders.
• C. Incorrect. An administrator has no special bypass to complete the unseal process without satisfying the Shamir's Secret Sharing threshold. The cryptographic keys are required to decrypt the master key, and no administrative role can override this fundamental security mechanism.

Correct answer: B — You must manually demote the original primary and configure it as a secondary to the new primary.

• A. Vault Disaster Recovery (DR) does not automatically detect a change in topology or self-demote. Re-establishing the replication relationship after a failover requires explicit administrative intervention.
• B. This is the correct standard operating procedure. After a failover, the old primary remains in a 'primary' state but is orphaned from the new topology. To reintegrate it, you must demote it to a secondary and then point it to the current primary to resume replication and avoid a split-brain scenario.
• C. Restarting the Vault service does not change its replication role. If the original primary is restarted without being demoted, it will still attempt to act as a primary, which conflicts with the current promoted primary.
• D. Vault DR replication is strictly unidirectional (from primary to secondary). Bidirectional replication is not a supported feature, and merging split-brain states is managed by re-syncing the secondary from the authoritative primary.

Correct answer: B — Performance Standby Nodes

• A. Disaster Recovery (DR) Replication is used to create a secondary 'warm' cluster for failover purposes. DR secondaries do not serve any client traffic, making this feature unsuitable for scaling read throughput in an active cluster.
• B. Performance Standby Nodes are a Vault Enterprise feature that allows standby nodes to serve read-only requests. This offloads significant traffic from the active node, which is primarily responsible for write operations, thereby improving performance for read-heavy workloads.
• C. Integrated Storage Auto-Scaling is not a Vault cluster strategy feature designed for routing read-only requests. While storage capacity and Raft consensus are critical, they do not provide the mechanism to enable standby nodes to process client read requests.
• D. Vault Agent Caching is a client-side optimization that caches secrets and tokens to reduce the frequency of requests to the Vault server. While it reduces overall load, it is not a cluster-level feature that enables standby nodes to handle requests.

Correct answer: A — HashiCorp Virtual Network (HVN)

• A. The HashiCorp Virtual Network (HVN) is the dedicated, isolated cloud network managed by HashiCorp within the HashiCorp Cloud Platform (HCP). It provides a secure environment for deploying services like Vault and Consul, allowing for peering with the customer's own cloud infrastructure (VPC/VNet).
• B. A Transit Gateway is a cloud networking hub used to interconnect VPCs and on-premises networks. While HCP can integrate with AWS Transit Gateway for connectivity, the actual isolated network where the Vault cluster resides is specifically called the HVN.
• C. Private Link is a connectivity service (such as AWS PrivateLink or Azure Private Link) that allows users to access HCP services privately. It is a method of communication rather than the name of the isolated network environment hosting the Vault cluster.

Correct answer: B — `exit_after_auth = true`

• A. This parameter does not exist in the Vault Agent configuration schema. It is a common misconception, but the correct syntax is specific to the authentication lifecycle.
• B. Correct. The `exit_after_auth` parameter (defaulting to false) is used within the Vault Agent's `auto_auth` configuration block. When set to true, the Agent will perform authentication, write the acquired token to any configured sinks, and then terminate immediately. This is the recommended approach for short-lived batch jobs or CI/CD pipelines where a persistent background daemon is unnecessary.
• C. While 'run once' is a common concept in container orchestration (like Kubernetes Jobs), it is not a valid configuration parameter for the Vault Agent.
• D. Vault Agent does not use a `daemon` configuration parameter to control exiting after authentication. Its lifecycle behavior for ephemeral tasks is managed specifically through the `exit_after_auth` setting.

Correct answer: B — VaultStaticSecret

• A. VaultDynamicSecret is used for dynamic secrets that are generated on-demand by Vault (e.g., database credentials or cloud IAM keys) and have a limited lifespan. It is not the resource used for synchronizing existing static KV secrets.
• B. VaultStaticSecret is the custom resource specifically designed to synchronize static secrets, such as those stored in the KV-V1 or KV-V2 secrets engines, from Vault into a native Kubernetes Secret. This allows Kubernetes applications to consume the secrets as environment variables or files.
• C. VaultPKISecret is used for managing PKI (Public Key Infrastructure) data, such as certificates and private keys. It is not intended for general KV secret synchronization.
• D. VaultTransitSecret is associated with the Transit secrets engine, which handles encryption, decryption, and cryptographic operations. It does not synchronize KV-V2 secret data into Kubernetes Secrets.