Question 1
Tommy has written an AWS Lambda function that will perform certain tasks for the organization
when data has been uploaded to an S3 bucket. Security policies for the organization do not allow
Tommy to hardcode any type of credential within the Lambda code or environment variables.
However, Tommy needs to retrieve a credential from Vault to write data to an on-premises database.
What auth method should Tommy use in Vault to meet the requirements while not violating security
policies?
- A. AWS
- B. Userpass
- C. Token
- D. AppRole
Answer:
A
Explanation:
Comprehensive and Detailed in Depth
A: AWS auth uses IAM roles, avoiding hardcoded credentials. Correct for Lambda.
B: Userpass requires username/password, violating policy. Incorrect.
C: Token requires a pre-generated token, often hardcoded. Incorrect.
D: AppRole needs RoleID/SecretID, typically hardcoded. Incorrect.
Overall Explanation from Vault Docs:
“The AWS auth method provides an automated mechanism to retrieve a Vault token for IAM
principals… no manual credential provisioning required.”
Reference:
https://developer.hashicorp.com/vault/docs/auth/aws#aws-auth-method
Comments
Question 2
What command would have created the token displayed below?
$ vault token lookup hvs.nNeZ2I64ALCxuO7dqQEJGPrO
Key: policies Value: [default dev], num_uses: 5, ttl: 767h59m49s
Key
Value
---
-----
accessor
mfvaVMFgOcXHIeqlRasroSOn
creation_time
1604610457
creation_ttl
768h
display_name
token
entity_id
n/a
expire_time
2024-12-07T16:07:37.7540672-05:00
explicit_max_ttl 0s
id
hvs.nNeZ2I64ALCxuO7dqQEJGPrO
issue_time
2024-11-05T16:07:37.7540672-05:00
meta
<nil>
num_uses
orphan
false
path
auth/token/create
policies
[default dev]
renewable
true
ttl
767h59m49s
type
service
- A. vault token create -policy=dev -use-limit=5
- B. vault token create -policy=dev -ttl=768h
- C. vault token create -policy=dev -policy=default -ttl=768h
- D. vault token create -policy=dev
Answer:
A
Explanation:
Comprehensive and Detailed in Depth
A: Matches dev policy and num_uses=5. TTL is system default (768h). Correct.
B: Missing num_uses. Incorrect.
C: Adds default policy explicitly, not needed as it’s implicit. Incorrect.
D: Missing num_uses. Incorrect.
Overall Explanation from Vault Docs:
“vault token create with -policy and -use-limit sets specific attributes… default policy is included
implicitly.”
Reference:
https://developer.hashicorp.com/vault/docs/commands/token/create#command-options
Comments
Question 3
You’ve set up multiple Vault clusters, one on-premises intended to be the primary cluster, and the
second cluster in AWS, which was deployed for performance replication. After enabling replication,
developers complain that all the data they’ve stored in the AWS Vault cluster is missing. What
happened?
- A. There is a certificate mismatch after replication was enabled since Vault replication generates its own TLS certificates to ensure nodes are trusted entities
- B. All of the data on the secondary cluster was deleted after replication was enabled
- C. The data was automatically copied to the primary cluster after replication was enabled since all writes are always forwarded to the primary cluster
- D. The data was moved to a recovery path after replication was enabled. Use the vault secrets move command to move the data back to its intended location
Answer:
B
Explanation:
Comprehensive and Detailed in Depth
A: Certificate issues don’t delete data. Incorrect.
B: Performance replication wipes the secondary’s data to sync with the primary. Correct.
C: Data isn’t copied to the primary; replication is one-way. Incorrect.
D: No recovery path exists; data is wiped. Incorrect.
Overall Explanation from Vault Docs:
“When replication is enabled, all of the secondary’s existing storage will be wiped… This is
irrevocable.”
Reference:
https://developer.hashicorp.com/vault/tutorials/enterprise/performance-replication
Comments
Question 4
Based on the screenshot below, how many auth methods have been enabled on this Vault instance?
- A. 1
- B. 2
- C. 4
- D. 3
Answer:
B
Explanation:
Comprehensive and Detailed in Depth
Token is enabled by default and cannot be disabled.
Userpass is explicitly enabled.
Total: 2 auth methods.
Overall Explanation from Vault Docs:
“Tokens are the default auth method… Additional methods like userpass increase the count.”
Reference:
https://developer.hashicorp.com/vault/docs/concepts/tokens
Comments
Question 5
Given the following policy, which command below would not result in a permission denied error
(select two)?
path "secret/*" { capabilities = ["create", "update"] allowed_parameters = { "student" = ["steve",
"frank", "jamie", "susan", "gerry", "damien"] } }
path "secret/apps/*" { capabilities = ["read"] }
path "secret/apps/results" { capabilities = ["deny"] }
- A. vault kv put secret/apps/results student03=practice
- B. vault kv put secret/apps/app01 student=bryan
- C. vault kv put secret/common/results student=frank
- D. vault kv get secret/apps/api_key
Answer:
C, D
Explanation:
Comprehensive and Detailed in Depth
A: Denied by secret/apps/results deny policy. Incorrect.
B: secret/apps/app01 only allows read, not create. Incorrect.
C: secret/common/results allows create with student=frank (allowed value). Correct.
D: secret/apps/api_key allows read. Correct.
Overall Explanation from Vault Docs:
“deny overrides any allow… allowed_parameters restricts values.”
Reference:
https://developer.hashicorp.com/vault/docs/concepts/policies#parameter-constraints
Comments
Question 6
Which of the following Vault policies will allow a Vault client to read a secret stored at
secrets/applications/app01/api_key?
- A. path "secrets/applications/" { capabilities = ["read"] allowed_parameters = { "certificate" = [] } }
- B. path "secrets/*" { capabilities = ["list"] }
- C. path "secrets/applications/+/api_*" { capabilities = ["read"] }
- D. path "secrets/applications/app01/api_key/*" { capabilities = ["update", "list", "read"] }
Answer:
C
Explanation:
Comprehensive and Detailed in Depth
This question requires identifying a policy that permits reading the secret at
secrets/applications/app01/api_key. Vault policies use paths and capabilities to control access. Let’s
evaluate:
A: path "secrets/applications/" { capabilities = ["read"] allowed_parameters = { "certificate" = [] } }
This policy allows reading at secrets/applications/, but not deeper paths like
secrets/applications/app01/api_key. The allowed_parameters restriction is irrelevant for reading
secrets. Incorrect.
B: path "secrets/*" { capabilities = ["list"] }
The list capability allows listing secrets under secrets/, but not reading their contents. Reading
requires the read capability. Incorrect.
C: path "secrets/applications/+/api_*" { capabilities = ["read"] }
The + wildcard matches one segment (e.g., app01), and api_* matches api_key. This policy grants
read access to secrets/applications/app01/api_key. Correct.
D: path "secrets/applications/app01/api_key/*" { capabilities = ["update", "list", "read"] }
This policy applies to subpaths under api_key/, not the exact path api_key. It includes read, but the
path mismatch makes it incorrect for this specific secret.
Overall Explanation from Vault Docs:
“Wildcards (*, +) allow flexible path matching… read capability is required to retrieve secret data.”
Option C uses globbing to precisely target the required path.
Reference:
https://developer.hashicorp.com/vault/tutorials/policies/policies
Comments
Question 7
You want to encrypt a credit card number using the Transit secrets engine. You enter the following
command and receive an error. What can you do to ensure that the credit card number is properly
encrypted and the ciphertext is returned?
$ vault write -format=json transit/encrypt/creditcards plaintext="1234 5678 9101 1121"
Error: * illegal base64 data at input byte 4
- A. The plain text data needs to be encoded to base64
- B. The token used to issue the encryption request does not have the appropriate permissions
- C. Credit card numbers are not supported using the Transit secrets engine since it is considered sensitive data
- D. The credit card number should not include spaces
Answer:
A
Explanation:
Comprehensive and Detailed in Depth
The error indicates a problem with the plaintext input format. Let’s analyze:
A: The Transit engine requires plaintext to be base64-encoded for safe transport, as it may include
non-text data. The error illegal base64 data occurs because "1234 5678 9101 1121" isn’t base64-
encoded. Correct: use plaintext=$(base64 <<< "1234 5678 9101 1121").
B: Permission errors would return a 403, not a base64 error. Incorrect.
C: Transit supports encrypting sensitive data like credit card numbers. Incorrect.
D: Spaces aren’t the issue; the format must be base64. Incorrect.
Overall Explanation from Vault Docs:
“When you send data to Vault for encryption, it must be base64-encoded plaintext… This ensures
safe transport of binary or text data.”
Reference:
https://developer.hashicorp.com/vault/docs/secrets/transit#usage
Comments
Question 8
Which of the following token attributes can be used to renew a token in Vault (select two)?
- A. TTL
- B. Token ID
- C. Identity policy
- D. Token accessor
Answer:
B, D
Explanation:
Comprehensive and Detailed in Depth
Token renewal extends a token’s TTL. Let’s evaluate:
A: TTL - Defines expiration time, not used for renewal. Incorrect.
B: Token ID - The token’s unique identifier; can be specified to renew it (e.g., vault token renew
<token-id>). Correct.
C: Identity policy - Relates to access control, not renewal. Incorrect.
D: Token accessor - A unique identifier for operations like renewal without exposing the token (e.g.,
vault token renew -accessor <accessor>). Correct.
Overall Explanation from Vault Docs:
“Tokens can be renewed with vault token renew using either the token ID or accessor… TTL is not an
attribute for renewal.”
Reference:
https://developer.hashicorp.com/vault/docs/commands/token/renew#token-renew
Comments
Question 9
When generating dynamic credentials, Vault also creates associated metadata, including information
like time duration, renewability, and more, and links it to the credentials. What is this referred to as?
- A. Secret
- B. Token
- C. Lease
- D. Secrets engine
Answer:
C
Explanation:
Comprehensive and Detailed in Depth
A: Secrets are the credentials themselves, not the metadata. Incorrect.
B: Tokens authenticate clients, not the metadata for credentials. Incorrect.
C: A lease is metadata tied to dynamic secrets, managing their lifecycle (TTL, renewability). Correct.
D: Secrets engines generate secrets, not the metadata. Incorrect.
Overall Explanation from Vault Docs:
“With every dynamic secret… Vault creates a lease: metadata containing TTL, renewability, etc.”
Reference:
https://developer.hashicorp.com/vault/docs/concepts/lease
Comments
Question 10
You are using an orchestrator to deploy a new application. Even though the orchestrator creates a
new AppRole secret ID, security requires that only the new application has the combination of the
role ID and secret ID. What feature can you use to meet these requirements?
- A. Have the application authenticate with the role ID to retrieve the secret ID
- B. Use response wrapping and provide the application server with the unwrapping token instead
- C. Use a batch token instead of a traditional service token
- D. Secure the communication between the orchestrator and Vault using TLS
Answer:
B
Explanation:
Comprehensive and Detailed in Depth
A: Exposes the secret ID, violating the requirement. Incorrect.
B: Response wrapping delivers the secret ID in a single-use token, ensuring only the application
unwraps it. Correct.
C: Batch tokens don’t address secret ID delivery security. Incorrect.
D: TLS secures communication but doesn’t restrict access to the secret ID. Incorrect.
Overall Explanation from Vault Docs:
“Response wrapping… wraps the secret in a single-use token, ensuring only the intended recipient
unwraps it.”
Reference:
https://developer.hashicorp.com/vault/tutorials/auth-methods/approle
Comments
Page 1 out of 28
Viewing questions 1-10 out of 285
page 2