HashiCorp Vault Associate VA-003 (VA-003) — Questions 151–225

Periodic tokens are designed for long-running processes like CI/CD pipelines. They have no maximum TTL and can be renewed indefinitely as long as the renewal occurs before the current token's TTL expires. By using a periodic token with a short period and enabling automatic renewal in the pipeline, the token stays valid without manual intervention, solving the expiration issue.

To issue dynamic IAM credentials with the AWS secrets engine, Vault needs AWS credentials with the right permissions and a role that defines what to create or assume. For assumed_role, the role specifies the target IAM role ARN and Vault calls sts:AssumeRole. AWS auth, sudo policies, and KV v2 storage are not prerequisites for this secrets engine workflow.

Vault leases govern Vault-side lifecycle, but the credential's validity in the target system is separate. If a database administrator rotates the password or removes the user outside Vault, the credential stops working even though the Vault lease is still active and renewable. This mismatch between Vault lease state and external system state is a common cause of premature credential failure.

Vault PKI separates consuming a role from managing it. Writing to the issue endpoint generates certificates, and writing to the revoke endpoint revokes them, so those two statements cover the operational needs. Role definitions, root generation, and mount configuration are administrative surfaces that must remain outside the team's policy to satisfy the stated restrictions.

`vault login -method=ldap username=john` is the standard Vault CLI command to authenticate using LDAP credentials. This command triggers the LDAP auth method, prompting the user for their password (or accepting it via `-password` flag) and returning a Vault token upon successful authentication against the configured LDAP server.

The error 'LDAP bind failed: invalid credentials' specifically indicates that the authentication attempt to the LDAP server using the configured binddn and bindpass failed. Since the LDAP server is reachable, the most direct cause is that the bind credentials stored in Vault's LDAP configuration do not match what the LDAP server expects. This is a configuration mismatch, not a connectivity or TLS issue.

The correct order is to first enable the Transit secrets engine, then create a key, use the key to encrypt and decrypt data, and finally rotate the key for security. Enabling creates the path, key creation provides the encryption material, and rotation updates the key without interrupting operations.

The `vault status` output shows that the Vault cluster is sealed. When a Vault cluster is sealed, it cannot process any API requests because the encryption key required to decrypt the data is not available in memory. This is the most common cause of unresponsiveness in a production Vault cluster that has been properly initialized.

Encryption as a service means the application sends plaintext to Vault and receives ciphertext, while the key stays inside Vault's barrier. The encrypt endpoint on the named key is the only listed call that performs the operation server-side without exposing key material, and it records the operation for auditing.

Cloud auth methods (AWS, Azure, GCP) enable authentication using existing cloud provider identities. For AWS, Vault uses the IAM principal's signed request to verify identity; for Azure, it validates managed identity tokens. This eliminates the need to distribute Vault-specific credentials and aligns with the hybrid cloud requirement.

The transit engine is designed for encrypting small data payloads (typically a few KB), not multi-GB files. The recommended approach is to use the `/transit/datakey/plaintext` endpoint to generate a data encryption key (DEK), encrypt the large file locally with that DEK using a symmetric algorithm like AES-256-GCM, and then wrap (encrypt) the DEK with Vault using the transit engine. This keeps the large file out of Vault while still leveraging Vault for key management and audit logging.

The token was created with a `-ttl=2h` but the token lookup output shows `max_ttl=1h`. The `max_ttl` is an upper limit enforced by the token's configuration or the system's maximum TTL setting. Even though the requested TTL was 2 hours, the token's effective lifetime is capped by the lower of the two values, so it expired after 1 hour.

The Vault transit secrets engine is designed to provide encryption and decryption as a service, allowing applications to encrypt and decrypt data without managing cryptographic keys directly. It offloads the cryptographic operations to Vault, which securely stores and rotates the encryption keys, ensuring that plaintext data never leaves the application unencrypted. This enables centralized key management and policy-based access control for encryption operations.

Encryption as a service means Vault performs the cryptographic operation and returns ciphertext while keeping the key inside Vault. The transit encrypt endpoint is the direct way to protect plaintext so it can later be recovered with decrypt. Endpoints like datakey, rewrap, and hmac serve different purposes such as envelope encryption, key rotation, or integrity checking.

Vault uses a threshold-based unsealing mechanism where a minimum number of unseal keys (the threshold) must be provided to reconstruct the master key and decrypt the storage backend. Providing only a single key, even if it is valid, leaves the Vault sealed because the threshold has not been met. The administrator must continue providing distinct unseal keys until the threshold count is reached.

The `vault policy write` command is the standard Vault CLI command to create or update a policy from a file. The syntax `vault policy write <name> <path>` reads the HCL or JSON policy definition from the specified file and writes it to Vault's policy storage.

Federated login against an OIDC-capable identity provider is served by Vault's OIDC auth method, which consumes the provider's discovery document and validates ID tokens. The other methods either require a static bind credential, depend on an unrelated identity source, or duplicate credentials inside Vault, none of which satisfies least-overhead federation with Okta.

Stored policies are inspected with the dedicated policy read subcommand, which returns the server-side document as parsed, exposing any difference from the local HCL file. Listing policies only yields names, the raw sys endpoint returns an opaque string, and the capabilities subcommand requires a token and a path rather than a policy name.

Vault's Storage Backend is responsible for persisting encrypted data. Vault encrypts all data at the application layer before writing it to the storage backend, ensuring that the backend itself never sees plaintext secrets. This design means the storage backend is a 'sealed box' that only stores ciphertext, providing defense in depth even if the backend is compromised.

Rotating the existing transit key satisfies the 90-day requirement because encryption begins using a new key version while prior versions remain available for decryption, so existing records stay readable without application changes. Rewrap can then migrate stored ciphertext to the newest version at a controlled pace, avoiding a disruptive bulk re-encryption.

The `vault secrets enable` command with the `-path` flag allows you to mount the database secrets engine at a custom path. The syntax `vault secrets enable -path=db-creds database` correctly specifies the custom path and the engine type, enabling the database secrets engine at the desired location.

Token accessors are non-sensitive, randomly generated identifiers that are mapped one-to-one with actual Vault tokens. By logging the accessor instead of the token ID, administrators can audit token usage (e.g., lookup, renewal, revocation) without exposing the token itself, which could be used to authenticate. This approach satisfies the requirement of auditing without compromising security.

Vault's token accessor endpoint requires the 'read' capability on the token's accessor path (auth/token/accessor or the token's own accessor path). A token cannot use its own accessor to read itself unless it explicitly has that capability; by default, tokens lack the capability to read their own accessor, so the request is denied. The policy shown does not grant accessor read rights, resulting in a permission denied error.

Audit devices are specifically designed to log every request and response that passes through Vault. They support multiple backends and include HMAC hashing to protect sensitive values while still allowing verification. Enabling at least one audit device is a best practice for production, and it is the only component that provides the described logging and tamper-evidence.

`vault token lookup` without arguments queries the token auth method's lookup-self endpoint and returns metadata for the token in use, including accessor, policies, TTL, and creation time. It deliberately omits the token's secret value, so an operator can audit the active session safely. Other token subcommands perform renewal, capability checks, or creation instead.

Setting `secret_id_num_uses=1` in the AppRole role configuration ensures that each SecretID can be used only once to obtain a token. Once the SecretID is used for login, it is automatically revoked and cannot be reused. This directly satisfies the requirement of single-use SecretIDs.

Revocation is the only operation that immediately invalidates a token before its TTL elapses. Using vault token revoke with the specific token ID destroys that token and its descendants, so subsequent requests fail and the token no longer appears in token listings. Renewal extends life, self-revocation targets the caller, and lookup is read-only.

The token was created with a TTL of 12h and an explicit max TTL of 24h. After 20 hours, only 4 hours remain before the max lifetime is reached, so Vault renews the token for the remaining 4h and then it expires. Vault caps any renewal at the explicit max TTL, so the token cannot be extended beyond 24h total.

OIDC auth method enables authentication via an external OIDC identity provider, allowing employees to use corporate credentials without local Vault users. It supports standard OIDC flows and JWT validation, making it the right choice for integrating with an OIDC-capable IdP.

The `auth/token/revoke-accessor` endpoint is specifically designed to revoke a token when only its accessor is known. The accessor is a non-sensitive identifier that Vault uses to perform token operations without exposing the actual token ID, making this endpoint the appropriate choice for revocation by accessor.

The mount's max_lease_ttl defines the absolute cumulative lifetime of a lease, and renewal cannot push a lease past that boundary. The application's renewals succeeded until the lease reached two hours, at which point renewal failed and the credential expired. The correct remediation is for the application to request a new credential when renewal is no longer granted.

Dynamic database credentials are generated by reading from the 'creds' endpoint of the database secrets engine for a specific role. The 'vault read database/creds/app-role' command triggers Vault to execute the role's creation statements and return a new username and password. Other commands either configure the role, target static roles, or use the wrong secrets engine.

The `vault token capabilities` command is specifically designed to check what operations (e.g., read, create, update, delete, list) a given token is allowed to perform on a particular path. It evaluates the token's attached policies against the path and returns the effective capabilities, making it the correct tool for this task.

The issue is that the policy attached to the Kubernetes auth roles grants read access to the entire 'shared-kv/*' path. By updating the policy to restrict capabilities to specific paths like 'shared-kv/data/team-alpha/*' and 'shared-kv/data/team-beta/*', the administrator enforces least privilege. The 'data' prefix is required for KV v2 engines to access secret data, and the wildcard ensures only the respective team's secrets are readable.

The `batch_input` parameter allows sending multiple plaintexts in a single API call to Vault's transit engine, significantly reducing the overhead of individual HTTP requests and TLS handshakes. This directly addresses the batch encryption timeout issue without changing the encryption algorithm or key strength, as the Vault cluster is healthy and not under load, indicating the bottleneck is network round-trips, not cryptographic computation.

The capabilities endpoint is designed to answer exactly this question: it returns the set of actions the current token may perform on a specified path. Running vault token capabilities against secret/data/payments reveals whether update is allowed, without reading the secret or requiring administrator involvement.

The most likely root cause is that the group mapping in Vault does not match the AD group names due to case sensitivity or syntax differences. Vault's LDAP auth method performs exact string matching when mapping LDAP groups to Vault policies; if the group names in the Vault configuration (e.g., 'Domain Admins') differ from the actual AD group names (e.g., 'Domain Admins' with a trailing space or different case), the mapping fails, resulting in no policy assignment and thus no permissions.

Token accessors allow revocation of a token without knowing the token ID. They are specifically designed for this purpose.

(AWS) is correct because the AWS authentication method in Vault allows EC2 instances to authenticate using their AWS instance identity documents and PKCS#7 signatures, without requiring any long-lived secrets to be stored on the instances. Vault verifies the instance's identity by calling the AWS EC2 API to validate the document and signature, then binds the instance to a Vault role. This eliminates the need to store tokens or credentials on the instance, meeting the requirement of secretless authentication.

The token's TTL was set to 1 hour with a max TTL of 24 hours. After the first renewal at 55 minutes, the token's TTL resets to 1 hour, but the max TTL remains 24 hours from creation. Once 24 hours have passed from creation, the token reaches its max TTL and expires permanently; it cannot be renewed because the max TTL is a hard upper limit enforced by Vault's token lifecycle logic.

The Rewrap operation in Vault allows a ciphertext to be decrypted with the current key version and re-encrypted with a new key version without exposing the plaintext to the caller. This ensures that if a key is compromised, previous ciphertext can be rotated to a new key version while maintaining data confidentiality.

The Transit secrets engine is designed specifically for encryption-as-a-service workflows, allowing applications to encrypt and decrypt data using keys managed entirely within Vault. The encryption key never leaves Vault, satisfying the requirement to avoid exposing the key. In contrast, other engines like KV v2 store raw secrets but do not perform cryptographic operations without exposing the key material.

Vault allows a single database mount (e.g., `database/`) to manage multiple database connections, and within that mount, you can define multiple roles. Each role can specify different credential generation parameters (e.g., username template, default TTL, max TTL, and allowed roles) for distinct databases or application servers. This minimizes the number of mounts while still providing fine-grained access control and isolation of credentials.

The correct sequence for setting up Vault's Kubernetes auth method is: enable the auth method, configure it with the Kubernetes API server details, create a role that binds to a service account, deploy a pod using that service account, and finally verify login. This order ensures that each prerequisite is fulfilled before the subsequent step can function correctly.

Vault authorization is the union of every policy attached to the token, and a single matching statement anywhere in that set is enough to allow a request. A policy scoped to the hr prefix cannot grant finance access by itself, so the presence of extra policies, including the default policy, is the logical explanation. Auditing the token's complete policy list confirms it.

Envelope encryption keeps large payloads out of Vault: datakey supplies a plaintext data key plus a wrapped copy, the agent encrypts locally, and only the wrapped key is stored with the object. Rewrap then rotates the wrapper under a new transit key version without re-uploading data. This separates the bulk ciphertext from the key-protection layer and meets the in-memory requirement.

In the Transit secrets engine, decryption is invoked as a write operation, so the policy must grant update on the transit/decrypt/<key> path. This allows the application to decrypt without granting capabilities on key creation or rotation paths, which are separate and can be restricted independently.

To allow a user to revoke their own token, the policy must grant the 'update' capability on the 'auth/token/revoke-self' endpoint. Vault's token revocation for self uses the update capability on that specific path, not write or the general revoke endpoint.

Creating a token role in Vault requires a PUT request to the /v1/auth/token/roles/<role_name> endpoint, and the default_ttl parameter must be specified as a string with a time suffix (e.g., '24h'). The PUT method is used for creating or updating a role, and the path must include 'roles' (plural) followed by the role name.

Correct matches: Secret is sensitive data; Token is an authentication credential. Common confusions: Policy vs. Auth Method — policies control access, auth methods authenticate users.

Revoking a token causes Vault to revoke the leases created by that token, providing precise containment for a compromised identity. This targets only the credentials spawned by the leaked token while leaving unrelated leases intact. More disruptive actions such as revoking the mount or sealing the cluster are unnecessary and cause collateral impact.

The KV secrets engine version 2 (v2) requires the '/data/' segment in the API path for reading secret data. The pipeline is calling 'v1/secret/team-a/app-config', which omits the mandatory '/data/' prefix, causing a 404 Not Found error. The CLI command 'vault kv put' automatically handles this path translation, but the direct API call does not.

To revoke a single lease, the admin should run `vault lease revoke <lease_id>` without any additional flags. This command targets exactly that lease and triggers the appropriate secrets engine to revoke the underlying credential. Using `-prefix` would revoke multiple leases, while `-all` and `-force` are either invalid or overly broad.

Vault tokens have both a TTL (time-to-live) and a max_ttl (maximum time-to-live). When a token is renewed, its TTL is reset to the original TTL (10 minutes) but only if the cumulative lifetime has not exceeded the max_ttl. If the max_ttl is reached, renewal fails, the token expires, and subsequent operations using that token return 'permission denied' errors, even though the policy itself grants the required capabilities.

Revoking a token in Vault triggers a cascading revocation of all its child tokens. This behavior ensures that compromised or expired parent tokens do not leave valid child tokens that could be used for unauthorized access. The accessor allows revocation without knowing the token ID, but the effect on children remains the same.

Batch tokens are designed to be lightweight and self-contained, meaning they are not persisted in Vault's storage backend. This makes them suitable for ephemeral use cases where the token will not be renewed or revoked. The key limitation is that they cannot be renewed or revoked individually, which is acceptable for a one-time operation.

The KV v2 secrets engine supports versioning, allowing retrieval of previous versions and rollback capabilities. This directly meets the requirement to store an API key and revert to an older version if needed. KV v1 does not support versioning, while Transit and Database engines serve different purposes (encryption and dynamic credentials, respectively).

The correct sequence for initializing and unsealing a Vault server for the first time is: start the server, initialize Vault (which generates unseal keys), distribute the unseal keys to key holders, unseal the Vault using a threshold of keys, then verify the Vault is unsealed. This ensures proper security and operational readiness.

The AWS secrets engine can be configured with a dedicated IAM user that has limited permissions, and by using the 'iam_user' credential type, Vault dynamically creates a new IAM user for each application. This approach adheres to the principle of least privilege by ensuring each application gets a unique set of credentials scoped to its specific needs, without sharing or reusing static keys.

The Kubernetes authentication method allows the CI/CD pipeline to authenticate to Vault using its Kubernetes service account token, which is automatically mounted into the pod. This eliminates the need for managing long-lived credentials because Vault verifies the token against the Kubernetes API server and issues a short-lived Vault token in return.

Performance Replication replicates mounts/policies (not secrets) for read scaling; DR Replication replicates everything for failover. Common confusions include swapping the two or inventing non-existent types like Snapshot or Local Replication.