New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

HashiCorp Vault-Associate Exam - Topic 2 Question 41 Discussion

Actual exam question for HashiCorp's Vault-Associate exam
Question #: 41
Topic #: 2
[All Vault-Associate Questions]

Security requirements demand that no secrets appear in the shell history. Which command does not meet this requirement?

Show Suggested Answer Hide Answer
Suggested Answer: B

The command that does not meet the security requirement of not having secrets appear in the shell history is B. vault kv put secret/password value-itsasecret. This command would store the secret value ''itsasecret'' in the key/value secrets engine at the path secret/password, but it would also expose the secret value in the shell history, which could be accessed by other users or malicious actors. This is not a secure way of storing secrets in Vault.

The other commands are more secure ways of storing secrets in Vault without revealing them in the shell history. A. generate-password | vault kv put secret/password value would use a pipe to pass the output of the generate-password command, which could be a script or a tool that generates a random password, to the vault kv put command, which would store the password in the key/value secrets engine at the path secret/password. The password would not be visible in the shell history, only the commands. C. vault kv put secret/password value=@data.txt would use the @ syntax to read the secret value from a file named data.txt, which could be encrypted or protected by file permissions, and store it in the key/value secrets engine at the path secret/password. The file name would be visible in the shell history, but not the secret value. D. vault kv put secret/password value-SSECRET_VALUE would use the -S syntax to read the secret value from the environment variable SECRET_VALUE, which could be set and unset in the shell session, and store it in the key/value secrets engine at the path secret/password. The environment variable name would be visible in the shell history, but not the secret value.


[Write Secrets | Vault | HashiCorp Developer]

Contribute your Thoughts:

0/2000 characters
Kindra
2 months ago
B seems fine to me, what's the issue?
upvoted 0 times
...
Paris
3 months ago
Totally agree, A is a no-go!
upvoted 0 times
...
Charlette
3 months ago
I thought D was the risky one, but I guess not.
upvoted 0 times
...
Carylon
3 months ago
Wait, how does C not show secrets?
upvoted 0 times
...
Sanjuana
3 months ago
A is the one that shows secrets in history.
upvoted 0 times
...
Malinda
3 months ago
I recall that using environment variables can help, but I’m not confident about which of these options does that. Could it be D?
upvoted 0 times
...
Jesse
4 months ago
I feel like option A might also expose the password in the history since it’s being generated right there.
upvoted 0 times
...
Rachael
4 months ago
I'm not entirely sure, but I remember practicing a question where using a file to input secrets was safer. Maybe option C is the right choice?
upvoted 0 times
...
Heidy
4 months ago
I think option B is the one that shows the secret directly in the command, so it might not meet the requirement.
upvoted 0 times
...
Kathryn
4 months ago
I think the key here is to find the option that doesn't store the password in the shell history at all. That's the one that meets the security requirement.
upvoted 0 times
...
Lavonna
4 months ago
I'm a bit confused by the different ways the password is being passed in these options. I'll need to research how each one affects the shell history.
upvoted 0 times
...
Lacey
5 months ago
Okay, let's see. The first option uses a pipe, which could potentially expose the password in the shell history. I'll need to double-check that.
upvoted 0 times
...
Denna
5 months ago
Hmm, this is a tricky one. I'll need to think carefully about how each of these commands interacts with the shell history.
upvoted 0 times
...
Brandon
7 months ago
Haha, Option A sounds like something a supervillain would do. 'Generate-password? More like give-away-password!'
upvoted 0 times
...
Annamae
7 months ago
I'd say Option D is the safest bet here. Keeping the secret value separate from the command is the way to go.
upvoted 0 times
Desirae
7 months ago
I agree, keeping the secret value separate from the command is a good practice to follow.
upvoted 0 times
...
Goldie
7 months ago
Option D is definitely the safest choice. Separating the secret value is crucial for security.
upvoted 0 times
...
Haydee
7 months ago
Yeah, keeping the secret value separate is definitely the best practice.
upvoted 0 times
...
Anthony
7 months ago
I agree, keeping the secret value separate from the command is crucial for security.
upvoted 0 times
...
Steffanie
7 months ago
Option D is definitely the safest choice. Separating the secret value is key.
upvoted 0 times
...
Willodean
7 months ago
I agree, Option D is the safest choice.
upvoted 0 times
...
...
Fernanda
8 months ago
I believe option A is also not secure because it generates a password that might be stored in the shell history.
upvoted 0 times
...
Jeannetta
8 months ago
Option B is definitely not the way to go. Putting a secret in the shell history is a big no-no.
upvoted 0 times
Cherrie
7 months ago
User 3: Definitely. We should use a different command to avoid putting secrets in the shell history.
upvoted 0 times
...
Bulah
7 months ago
User 2: Yeah, that's a major security risk. We need to be careful with that.
upvoted 0 times
...
Cordie
8 months ago
User 1: Option B is a big no-no. Can't have secrets in the shell history.
upvoted 0 times
...
...
Odette
8 months ago
I agree with Val. Option B is not secure because it exposes the secret in the shell history.
upvoted 0 times
...
Val
8 months ago
I think option B does not meet the security requirement because it includes the word 'secret' in the value.
upvoted 0 times
...

Save Cancel