VA-003 Flashcards — Free HashiCorp Vault Associate VA-003 Study Cards

JWT/OIDC

JWT/OIDC authentication allows a DevOps pipeline to exchange a signed JSON Web Token (JWT) from an external identity provider (e.g., GitHub Actions, GitLab CI) for a short-lived Vault token. This eliminates the need to store a long-lived secret in the CI/CD pipeline because the JWT is dynamically generated by the CI platform and validated by Vault using the OIDC provider's public keys. The resulting Vault token has a configurable TTL, typically minutes, aligning with the requirement for short-lived credentials.

Use periodic tokens with a short period and allow renewal

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.

path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/dev/{{identity.entity.name}}/*" { capabilities = ["delete"] }

Option D is correct because it grants full CRUDL access to 'secret/dev/*' for reading and writing, but then restricts delete to only the path 'secret/dev/{{identity.entity.name}}/*', which uses the entity's name to ensure developers can only delete secrets under their own sub-path. This leverages Vault's identity entity name templating to enforce per-developer delete scoping.

Configure the role with a ttl of 1h.

Option C is correct because the database secrets engine allows role-level TTL configuration that overrides the default lease duration for credentials generated from that role. By setting the role's `ttl` to 1h, the team enforces a 1-hour expiration for credentials created under that specific role without affecting the default lease TTL for all secrets or other roles. This directly meets the security policy requirement while maintaining flexibility for other secrets.

Use Vault Agent to renew the secret.

Option C is correct because Vault Agent is designed to automatically handle secret renewal and lifecycle management. It runs as a sidecar or daemon that periodically checks the lease duration and renews it before expiration, ensuring applications always have valid credentials without manual intervention or custom scripting.

vault kv put secret/team api_key=abc123

Option B is correct because the KV v2 engine automatically prefixes the path with 'data/' when using the 'vault kv put' command. The correct path for writing a secret to the KV v2 engine is 'secret/data/team', but the CLI command 'vault kv put secret/team api_key=abc123' handles this internally by appending '/data/' to the path. This is a key difference from the 'vault write' command, which requires the full path including 'data/'.

Vault Agent sidecar

Option C is correct because the Vault Agent sidecar runs alongside the application container in the same pod, automatically authenticating to Vault and retrieving a short-lived token. This eliminates the need for human intervention by handling the authentication lifecycle (e.g., using Kubernetes auth method) and renewing or re-authenticating as needed, ensuring the application always has a valid token.

Deploy Vault Agent in sidecar mode with a configured encrypt stanza to handle encryption locally.

Option B is correct because Vault Agent in sidecar mode runs alongside the application on the same host, handling encryption locally without requiring outbound HTTP requests. The encrypt stanza in the agent configuration allows it to proxy encryption operations to Vault's transit secrets engine, while the application communicates with the agent over a local loopback interface, bypassing network restrictions.