Enterprise Vault Icons Certification: Complete Guide 2026

Correct answer: A

• A. Correct.

  Correct. The Kubernetes auth method is designed for workloads running in Kubernetes. Vault can validate the pod's service account token with the Kubernetes API and map authenticated identities to Vault roles based on bound service account names and namespaces. This avoids embedding long-lived static credentials in images or Secrets and aligns with the requirement to verify pod identity using the cluster's service account token.

• B. Incorrect.

  Incorrect. AppRole is commonly used for machines and applications, but in this scenario it would require distributing RoleID and SecretID to the pod. That introduces credential management overhead and often results in static or semi-static credentials being stored or injected somewhere. It also does not natively use the Kubernetes service account token to verify pod identity.

• C. Incorrect.

  Incorrect. The userpass auth method is intended for human users authenticating with a username and password, not for Kubernetes workloads. Using userpass for applications would create unnecessary operational burden and would require storing passwords for pods, which conflicts with the requirement to avoid long-lived static credentials.

• D. Incorrect.

  Incorrect. Token auth allows a client to present an existing Vault token, but it does not solve the problem of how the pod securely obtains that token in the first place. Injecting a long-lived token into pods is specifically what the company wants to avoid because it creates static credential exposure and weakens identity assurance.

Correct answer: B

• A. Incorrect.

  Incorrect. AppRole is commonly used for machine authentication, but this option does not meet the stated requirement well because it relies on distributing a shared secret_id to instances. The scenario specifically asks for Vault to verify instance identity using AWS-provided metadata rather than a shared secret. While AppRole can be used securely in some workflows, using the same role_id and secret_id across all instances weakens identity assurance and secret management.

• B. Correct.

  Correct. The AWS auth method is designed for workloads running in AWS. It allows Vault to authenticate EC2 instances or IAM principals by validating AWS identity information. This aligns with the requirement to avoid long-lived Vault tokens in files and to let Vault verify the workload's identity using AWS mechanisms instead of a manually distributed shared secret.

• C. Incorrect.

  Incorrect. The userpass auth method is intended for human users authenticating with a username and password, not for ephemeral application instances. Creating and managing separate usernames and passwords for each EC2 instance is operationally poor and does not use AWS-native identity verification.

• D. Incorrect.

  Incorrect. Token auth can authenticate directly with a Vault token, but baking tokens into an AMI creates a long-lived credential distribution problem. Even periodic tokens still represent pre-issued Vault credentials stored on the instance image, which conflicts with the requirement to avoid storing long-lived Vault tokens in configuration or images and does not leverage AWS identity verification.

Correct answer: B

• A. Incorrect.

  Incorrect. AppRole is commonly used for machine authentication, but this option specifically describes embedding a shared SecretID in the deployment pipeline for all instances, which reintroduces the problem of distributing and storing long-lived shared credentials. While AppRole can be implemented more securely, this scenario asks for each instance to authenticate using its own identity without relying on shared static secrets.

• B. Correct.

  Correct. Cloud auth methods such as AWS or GCP auth are designed for workloads running on supported cloud platforms. Vault can verify instance identity based on metadata or signed identity documents from the cloud provider, allowing each instance to authenticate as itself and receive short-lived Vault tokens. This aligns with the requirement to avoid long-lived shared credentials and to give each workload its own identity.

• C. Incorrect.

  Incorrect. The userpass auth method is intended for human users, not application workloads. Managing usernames and passwords for individual application instances would be operationally difficult and less secure than using a workload identity-based auth method. It also does not match the requirement to avoid stored shared credentials in automation environments.

• D. Incorrect.

  Incorrect. The token auth method can authenticate directly with a token, but distributing a single token to all application instances creates a shared credential and weakens auditability and isolation. If one host is compromised, the shared token can be reused elsewhere. This does not provide per-instance identity or the strongest fit for the stated requirements.