Utilize Vault CLI and API practice questions

vault kv put secret/data/team api_key=abc123

Why it fails: Incorrect because the mount path is 'secret/', so the full path becomes 'secret/team' (the 'data/' is automatically inserted by Vault).

vault write secret/data/team api_key=abc123

Why it fails: Incorrect; 'vault write' is not the recommended way for KV v2, and the path is redundant.

vault write secret/team api_key=abc123

Why it fails: Incorrect command; 'vault write' is generic and not recommended for KV v2. Also, the path should be 'secret/data/team'.

vault write auth/token/create policies=read-only ttl=1h

Why it fails: Incorrect. `vault write auth/token/create` uses the API endpoint and expects different parameter syntax (e.g., `policies=["read-only"]`).

vault create token -policy=read-only -ttl=1h

Why it fails: Incorrect. `vault create` is not a valid Vault command.

curl -X POST -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws/

Why it fails: Incorrect; trailing slash may cause issues; the correct path is without trailing slash.

curl -X PUT -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws

Why it fails: Incorrect; the correct HTTP method is POST for enabling auth methods.

curl -X POST -H "X-Vault-Token: s.abc" -d '{"method":"aws"}' https://vault:8200/v1/sys/auth/aws

Why it fails: Incorrect; the JSON key should be 'type', not 'method'.

vault auth -method=token token=s.abc

Why it fails: 'vault auth' is not a Vault CLI command; enabling an auth method is done with 'vault auth enable', while logging in uses 'vault login token=s.abc'. It is tempting because 'auth' genuinely appears in Vault's command set, just for configuration rather than authentication.

vault authenticate -method=userpass username=jdoe

Why it fails: Vault's CLI has no 'authenticate' subcommand; authentication is performed with 'vault login', which accepts '-method' and method-specific parameters such as username. The syntax looks plausible because '-method=userpass' and the username flag are genuine, so only the subcommand name is wrong.

Setting environment variable VAULT_AUTH=s.abc

Why it fails: Vault reads the token from VAULT_TOKEN, not VAULT_AUTH; no such environment variable exists, so the CLI would remain unauthenticated. It is tempting because environment variables are a legitimate way to supply credentials non-interactively, which is exactly what VAULT_TOKEN does in CI pipelines.

vault read -field=api_key secret/team

Why it fails: Incorrect; path should be 'secret/data/team' for KV v2.

vault read -field=api_key secret/data/team

Why it fails: Incorrect; api_key is nested under data, so you need 'data.api_key'.

vault read secret/data/team

Why it fails: Incorrect; this would output the full JSON, not just the api_key value.

Read only

Why it fails: Read only is incorrect because the default policy does not grant read permission on this path.

Create, read, update, delete, list

Why it fails: Create, read, update, delete, list is incorrect as the default policy grants no such permissions.

Read and list only

Why it fails: Read and list only is incorrect because the default policy does not grant read or list permissions on this path.

The developer's user entry is disabled. The admin should enable it using 'vault write auth/userpass/users/<username>/enable'.

Why it fails: Incorrect; the user entry is not disabled as per the scenario.

The developer's password has expired. The admin should update the password with a new one.

Why it fails: Vault's userpass auth method has no password-expiry mechanism, so an expired password cannot produce the 'invalid password' error, and resetting via the CLI already ruled out a stale credential; the audit log showing 'invalid password' for one user while others succeed points to a per-user policy or entity alias mismatch, not expiry. Password expiry is tempting because it is a familiar cause of authentication failure in directory services such as LDAP or Microsoft Entra ID, where credential lifetime policies are enforced.

The developer's password hash is corrupted. The admin should delete and recreate the user entry.

Why it fails: Incorrect; password reset worked, so hash is not corrupted.

vault kv put secret/data/app/config password=newpass

Why it fails: 'vault kv put' replaces the entire secret version, so the 'username' key is dropped and only 'password' remains. It is tempting because put is the standard KV v2 write command, and it would be correct when creating a new secret or intentionally overwriting all keys at the path.

vault update secret/data/app/config password=newpass

Why it fails: Vault's CLI has no 'update' subcommand; the command fails outright rather than patching the key. It is tempting because 'update' matches the policy capability name and suggests a partial modification, and it would be correct only if such a subcommand existed for KV v2 writes.

vault write secret/data/app/config password=newpass

Why it fails: 'vault write' to a KV v2 data path also overwrites the full secret, removing 'username' unless every key is resupplied. It is tempting because write is the generic Vault API verb and works for many engines, correct for non-KV-v2 backends where partial writes are not required.

The Vault token has been revoked.

Why it fails: A revoked token returns a 403 permission denied response, not an API request failure; the engineer already confirmed the token is valid and unexpired. Revocation is the right diagnosis when Vault explicitly reports 'permission denied' or 'token is revoked' during authentication.

Network connectivity to Vault is intermittent, causing timeouts.

Why it fails: Intermittent connectivity would produce connection refused or TLS handshake failures, not a structured API error returned by Vault itself; the CLI reached the server and received a response. Network troubleshooting is the right path when errors are transport-level and vary between calls, which this consistent API response is not.

The secret engine at that path has not been enabled.

Why it fails: An unenabled secrets engine yields a 404 unsupported path error, and the CLI reports that distinctly rather than as a generic API request failure. Checking mount status is the correct step when the path itself is wrong, but the stem's error indicates the request reached an enabled endpoint that rejected it.

vault list database/creds/readonly

Why it fails: vault list enumerates existing credential paths or keys; it does not generate a dynamic credential. Listing is correct when you need to discover which roles exist under a database secrets engine path before reading credentials.

vault generate database/creds/readonly

Why it fails: Vault has no 'generate' subcommand; dynamic database credentials are issued with 'vault read database/creds/readonly', which requests a lease from the database secrets engine. The 'generate' verb is tempting because it suggests credential creation, but it belongs to PKI root/intermediate certificate generation, not database credential retrieval.

vault read database/creds/readonly

Why it fails: Incorrect. `vault read` retrieves static secrets but does not generate dynamic credentials. Using it on a dynamic credential path does not produce a new credential.

Use the Vault CLI with curl to wrap commands.

Why it fails: This approach is unnecessary; the Vault CLI is not installed, and curl can interact directly with the API without wrapping CLI commands. It adds complexity and does not satisfy the constraint of no binary installation.

Install Vault binary on the server and use CLI.

Why it fails: The scenario explicitly states the Vault binary cannot be installed, so CLI use is impossible; the HTTP API must be called directly. Installing the binary is tempting because CLI commands are the usual rotation method, but that approach suits servers where Vault tooling may be deployed, not this restricted host.

Use Vault Agent to handle rotation.

Why it fails: Vault Agent is a client daemon that requires the Vault binary to be installed, which violates the constraint. Additionally, Agent is typically used for tasks like caching and auto-authentication, not for direct database credential rotation in this scenario.

The value must be JSON-encoded.

Why it fails: Incorrect. Vault accepts plain text values; JSON encoding is not required for KV stores. The warning is about missing metadata, not about encoding.

The token lacks write capability on that path.

Why it fails: A missing-capability token returns a permission denied error, not a metadata warning; the write would fail outright. Capability checks are the right diagnosis when Vault rejects a request, but here the write succeeded, so the path likely sits outside the KV version 2 mount.

The secret engine is not enabled.

Why it fails: Incorrect. If the engine were not enabled, the command would fail with an error that the path is not found, not a warning about metadata.

The token was created with a period.

Why it fails: A periodic token renews indefinitely, but a token with a period still renews via token renew; the error stems from the API request itself, not the period setting. Periods are configured when you need a token that never expires as long as it is renewed within each period.

The token's policy denies renewal.

Why it fails: Incorrect. Policy denial would typically produce a permission denied error, not a generic 'Error making API request'. The renewable flag is checked before policy evaluation.

The Vault server is unreachable.

Why it fails: An unreachable server would produce a connection refused or timeout error, not 'Error making API request' from a valid token renewal. Unreachability is the cause when the client cannot resolve or connect to the Vault address at all, such as a wrong VAULT_ADDR.

delete

Why it fails: Delete is not required for writing a new version; it allows deleting secrets.

list

Why it fails: List is not required; it allows listing secret paths.

read

Why it fails: Read is not required; it allows reading secret data.

create

Why it fails: Incorrect. 'Create' is only needed when the secret does not exist. Since the question specifies an existing secret, 'create' is not required.

The token cannot be renewed because the token type is service.

Why it fails: Service tokens are renewable by default, so 'vault token renew -self' succeeds and extends the TTL. It is tempting because periodic tokens and batch tokens have distinct renewal semantics, but service type alone does not prevent renewal; only a zero or non-renewable TTL would.

The token will be renewed, but TTL cannot exceed 72h from issue time.

Why it fails: Incorrect. While renewal does reset the TTL, it is not limited to 72h from the issue time; rather, it resets to 72h from the current renewal time, as long as it does not exceed the max TTL.

The token cannot be renewed because it is orphan.

Why it fails: Orphan tokens are renewable; orphaning only removes the parent link, not renewal capability. It is tempting because orphan tokens bypass parent revocation, which sounds restrictive, but renewal depends on the token's renewable flag and TTL, not on whether a parent exists.

LIST /v1/secret/data/myapp/

Why it fails: Listing is done on the metadata path, not data.

POST /v1/secret/metadata/myapp/

Why it fails: Listing requires GET, not POST.

GET /v1/secret/myapp/

Why it fails: This endpoint is for reading a secret at the data path, not listing.

A root token

Why it fails: A root token never expires and bypasses policy checks, so it cannot be renewed by Vault Agent and grants unlimited privilege, violating least privilege. Root tokens are tempting for uninterrupted long-running access, but they are intended only for initial setup and emergency recovery.

A service token with a short TTL

Why it fails: A short TTL forces frequent renewals, so any renewal failure or network interruption terminates the token and breaks the application. Short-lived service tokens are tempting for limiting credential exposure, but they suit brief workloads rather than long-running processes needing continuous availability.

A batch token

Why it fails: Batch tokens are lightweight and non-renewable, so Vault Agent cannot extend them and they expire at their fixed TTL, interrupting the application. Batch tokens are tempting for high-volume, short-lived workloads, but periodic service tokens are required for continuous renewal.

Raft integrated storage

Why it fails: Development mode stores everything in memory, discarding data on restart; Raft integrated storage is the production default for HA clusters. It tempts because Raft is Vault's recommended production backend, and it would be correct for a standard non-dev server configuration.

File system backend at /var/lib/vault

Why it fails: Development mode uses an in-memory backend, not the filesystem; the file backend is configured explicitly for single-node production use. It tempts because the file backend persists data to disk, which is desirable, and it would be correct when durability across restarts is required outside dev mode.

Consul backend

Why it fails: Dev mode uses an in-memory storage backend, so Consul's persistent key-value store is not engaged; data vanishes on restart. Consul is the right choice for a production HA cluster needing durable, replicated storage across nodes, which dev mode deliberately avoids.

PUT /v1/sys/policy/{name}

Why it fails: Vault uses POST, not PUT, for policy creation.

PATCH /v1/sys/policy/{name}

Why it fails: PATCH is not supported for policy management.

The configuration needs a 'region' parameter

Why it fails: Region is not required for the AWS auth method; credentials are needed.

The role name 'my-role' is invalid

Why it fails: The role name could be any valid role; the missing piece is credentials.

The method type should be 'iam' instead of 'aws'

Why it fails: 'aws' is the correct type for the AWS auth method.