Vault Agent Configuration practice questions

ttl

Why it fails: The TTL is not a global parameter for the cache block.

expiry

Why it fails: This is not a valid configuration parameter.

cache_timeout

Why it fails: This parameter does not exist in the cache configuration.

render_interval

Why it fails: Vault Agent templates are reactive and do not rely on polling intervals.

dynamic_update

Why it fails: This is not a valid parameter for the template block.

force_refresh

Why it fails: This is not a valid parameter for the template block.

auth_method

Why it fails: This is not a top-level block for agent configuration.

vault_agent

Why it fails: The top-level configuration block is 'vault', not 'vault_agent'.

secrets

Why it fails: The secrets block is for managing secret engines, not authentication.

{{ get "kv/config" }}

Why it fails: The 'get' function is not a valid Vault template helper.

{{ vault_read "kv/config" }}

Why it fails: This is not a valid template helper.

$vault.read("kv/config")

Why it fails: This is not the correct syntax for Vault templates.

By setting 'shared_cache = true' in the configuration.

Why it fails: This parameter does not exist.

By mounting a shared volume.

Why it fails: The cache is not file-based.

By configuring a shared Redis backend.

Why it fails: Vault Agent cache is strictly in-memory per process.

The agent will attempt to re-authenticate immediately.

Why it fails: Re-authentication is only triggered if the token is revoked or expired.

The agent will disable template rendering.

Why it fails: Template rendering depends on the token, but the agent does not disable it.

The agent will stop and exit with an error.

Why it fails: The agent continues to run and re-creates the file.

service_account_token

Why it fails: This is not a configuration parameter.

jwt_path

Why it fails: This is not the correct parameter name.

token_file

Why it fails: The correct parameter is 'token_path'.

Use the 'raw' function.

Why it fails: This does not handle multiline indentation.

Use the 'base64' function.

Why it fails: Base64 encoding changes the format, not the structure.

It is not possible to render multiline secrets.

Why it fails: It is definitely supported.

Secret rotation

Why it fails: Secret rotation is a lifecycle event, not a caching feature.

Data encryption

Why it fails: Encryption is handled by the transport/transit engine.

command

Why it fails: Command is not a template block parameter; it is for 'change_mode'.

version

Why it fails: Version is not a valid parameter.

As an environment variable.

Why it fails: While Vault client supports it, Agent config prefers the config block.

In the 'cache' block.

Why it fails: The cache does not handle TLS CA configuration.

In the 'listener' block.

Why it fails: The listener is for the API, not the auto-auth connection.

method

Why it fails: Method is part of the auto-auth block.

role

Why it fails: Role is part of the auth method block.

encrypt

Why it fails: Encryption is not a template helper.

rotate

Why it fails: Rotation is not a template helper.

Configure a listener block of type tcp with address "127.0.0.1:8200" and no sink, relying on the default token file written to the agent's working directory.

Why it fails: Vault Agent does not write a token file unless an auto_auth sink of type file is declared, so no default token file exists. A tcp listener on loopback also requires binding a port, which may violate the host's hardening policy, and it does not by itself produce a file the child process can read at the required path.

Configure a listener block of type unix with address "/var/run/vault-agent/agent.sock" and an auto_auth sink of type file with config { path = "/var/run/vault-agent/token", mode = "0644" }.

Why it fails: The path is correct, but mode 0644 makes the token world-readable, which is a credential exposure on a hardened host. Vault Agent defaults the sink file mode to 0640 and the scenario calls for secure handling. The sink itself is the right mechanism; the overly permissive mode is the disqualifying error.

Configure a listener block of type unix with address "/var/run/vault-agent/agent.sock" and set the auto_auth method's config to write the token directly to /var/run/vault-agent/token.

Why it fails: The AppRole auth method configuration accepts role_id and secret_id options, not a token output path. Token persistence is the responsibility of an auto_auth sink, not the auth method. Without a file sink, the token stays in memory inside the agent and the child process cannot read it from disk as required.

Set exit_after_auth = true in the template stanza so the agent stops after rendering the first secret.

Why it fails: exit_after_auth is a top-level agent option that makes the agent exit once auto-auth succeeds, not a template stanza setting. It does not control whether templates rewrite files on rotation, and exiting the agent would prevent any subsequent rendering. It fails to address the requirement of writing once without rewriting on rotation.

Set error_on_missing_key = true in the template stanza so rendering fails if the secret key is absent.

Why it fails: error_on_missing_key only controls whether template rendering errors when a referenced key is missing from the secret data. It has no effect on how often the destination file is written. Enabling it would make rendering stricter but would not stop the agent from rewriting the file on each rotation.

Set change_mode = "noop" in the template stanza so the agent does not execute any command when the rendered file changes.

Why it fails: change_mode controls what action the agent takes after a template renders, such as restarting or signaling a process. The noop value means no command runs, but the file is still rewritten when the secret changes. The scenario requires preventing the rewrite itself, not just suppressing the post-render action.

set 'max_backoff' in the cache stanza to a higher value

Why it fails: The cache stanza's max_backoff parameter controls the maximum backoff for cache-related operations, such as revalidating tokens or renewing leases. It does not apply to the auto-auth process. Adjusting it would have no effect on the agent's ability to retry a failed authentication attempt, so the new instances would still not obtain a token.

increase the 'token_ttl' in the auto_auth method configuration

Why it fails: token_ttl is a parameter used when configuring an auth method to request a specific TTL for the issued token. It does not affect the agent's behavior when authentication fails. Even with a longer TTL, the initial authentication attempt would still fail if the IAM role is not recognized, and the agent would not retry, leaving the agent without a token.

set the 'exit_after_auth' parameter to false

Why it fails: The exit_after_auth parameter controls whether the agent exits after a successful authentication. It does not govern retry behavior when authentication fails; setting it to false simply keeps the agent running after auth succeeds, which is already the default. It will not cause the agent to retry a failed authentication attempt, so the new instances would still fail to obtain a token.

urlquery

Why it fails: The urlquery function escapes a string for safe placement in a URL query component. It encodes spaces as '+' and other characters differently than percent-encoding. While it can handle special characters, it is not the correct function for general URL encoding of a path segment or a value that will be embedded in a connection string where percent-encoding is expected. It may produce output that is not compatible with applications expecting standard percent-encoding.

base64Encode

Why it fails: base64Encode converts the input into a Base64-encoded string, which is not URL-safe and would change the password entirely. The application expects the original password, only URL-encoded. Using Base64 would result in an incorrect password and authentication failure. Base64 encoding is used for binary data or when explicitly required, not for URL encoding of text.

toJSON

Why it fails: toJSON converts a data structure into a JSON string. It does not perform any URL encoding. Applying it to a password would wrap it in quotes and escape certain characters for JSON, but would not encode characters like ':' or '@' for URL usage. The resulting string would not be a valid URL-encoded password and would likely break the connection string.

exec { command = "systemctl restart web" }

Why it fails: The exec block defines the command to run when change_mode triggers an action, but it does not set the trigger condition. Without change_mode = "restart", the exec command is not executed on secret changes. So defining exec alone leaves the agent using the default change_mode, which does not restart the service.

change_signal = "SIGUSR1"

Why it fails: change_signal specifies the signal sent to the process when change_mode is set to "signal". It does not by itself cause a restart. If the team sets only change_signal without change_mode, the default change_mode applies and no signal is sent. Therefore it cannot produce the desired restart behavior on content change.

error_on_missing_key = true

Why it fails: The error_on_missing_key parameter controls whether template rendering fails when a referenced key is absent. It has no effect on process restarts or change detection. Setting it would only alter error handling during rendering, not the behavior after a successful update, so it cannot satisfy the restart requirement.

template

Why it fails: The template block renders secrets to files or environment variables, but it does not proactively renew dynamic secrets. It retrieves the secret at render time and re-renders when the secret changes or the template is re-evaluated, which may not prevent the application from seeing an expired credential if renewal fails between renders.

cache

Why it fails: The cache block enables the agent's caching proxy for Vault API requests, but it does not proactively renew dynamic secrets. Caching can reduce load on Vault, yet a cached dynamic credential will still expire according to its lease, and the agent will not automatically renew it for the application.

auto_auth

Why it fails: The auto_auth block handles authenticating the agent to Vault and managing the client token, not the lifecycle of dynamic secrets consumed by applications. It ensures the agent has a valid Vault token, but it does not renew database credentials or keep them fresh for the application.

auto_auth { method { type = "aws" config { role = "app-role" } } }

Why it fails: Omitting the 'type' parameter defaults to unspecified behavior, which may not correctly select the IAM authentication flow. The AWS auth method requires explicit configuration of the credential type to ensure the agent uses the IAM role. Without it, the agent might fall back to EC2 metadata which could be disabled, leading to authentication failure.

auto_auth { method { type = "aws" config { role_id = "app-role" secret_id = "..." } } }

Why it fails: This configuration resembles AppRole authentication with role_id and secret_id, which is not applicable to AWS auth. The AWS auth method does not use role_id or secret_id; it relies on AWS credentials. Using these parameters would cause the agent to fail authentication because the AWS auth backend expects different fields.

auto_auth { method { type = "aws" config { role = "app-role" type = "ec2" } } }

Why it fails: Using 'ec2' as the credential type would require the agent to retrieve instance identity documents from the EC2 metadata service, but the scenario specifies IAM roles attached to the servers. While EC2 auth can work with IAM roles, the 'iam' type is the correct choice for signing with IAM credentials directly, and 'ec2' may fail if the metadata service is restricted.