HashiCorp Vault Associate (003) Question 15
Single answer1b Choose an authentication method based on use caseA company runs Vault in AWS and wants to let applications on EC2 instances authenticate without distributing long-lived credentials in AMIs or environment variables. The security team also wants each instance to prove its identity to Vault using AWS-native metadata at login time. Which authentication method is the best fit for this use case?
- A
Enable the AWS auth method and have the application authenticate using the EC2 or IAM login flow
- B
Enable the Userpass auth method and store a shared username and password on each EC2 instance
- C
Enable the Token auth method and bake a periodic root token into the AMI for all instances
- D
Enable the AppRole auth method and place the RoleID and SecretID in instance user data for every server
Show answer and explanation
Correct answer: A
Explanation
The best choice is the AWS auth method because the scenario is specifically about applications running on EC2 that should authenticate by proving AWS identity rather than by receiving pre-shared static credentials. In Vault, the AWS auth method supports AWS-based workload authentication patterns such as EC2 and IAM, allowing Vault to validate the caller against AWS identity data. This aligns with HashiCorp best practices to choose an auth method that matches the platform's native identity system whenever possible. By contrast, Userpass is meant for human users, Token auth with a baked root token is insecure and operationally dangerous, and AppRole is useful for machines but does not inherently leverage AWS-native instance identity in the way this use case requests. See Vault documentation for the AWS auth method and general authentication method guidance on selecting auth methods based on trusted identity sources and minimizing static secret distribution.
- A. Correct.
Correct. The AWS auth method is designed for workloads running in AWS. It allows Vault to verify instance or IAM identity using AWS-native information rather than relying on manually distributed static secrets. For EC2-based workloads, this is a strong fit when the goal is to avoid embedding long-lived credentials and to let instances prove identity dynamically at login.
- B. Incorrect.
Incorrect. Userpass is intended for human users authenticating with a username and password, not for cloud workloads. Storing a shared password on many EC2 instances creates a static secret distribution problem and weakens auditability because multiple machines may authenticate as the same identity.
- C. Incorrect.
Incorrect. The token auth method can authenticate with an existing Vault token, but baking a root token into an AMI is a serious security anti-pattern. Root tokens are highly privileged and should be tightly controlled, not shared broadly across application instances. This option also does not satisfy the requirement to use AWS-native identity proof during login.
- D. Incorrect.
Incorrect. AppRole is commonly used for machine authentication, especially outside a specific cloud identity provider, but this scenario explicitly asks for AWS-native metadata-based identity proof and to avoid distributing long-lived credentials. Putting both RoleID and SecretID into user data still involves secret distribution and is less aligned with the stated requirement than AWS auth.