Deal of The Day! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

HashiCorp Exam Vault-Associate 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:

Rachael
5 days 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
11 days 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
16 days 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
22 days 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
27 days 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
1 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
4 months ago
Haha, Option A sounds like something a supervillain would do. 'Generate-password? More like give-away-password!'
upvoted 0 times
...
Annamae
4 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
3 months ago
I agree, keeping the secret value separate from the command is a good practice to follow.
upvoted 0 times
...
Goldie
3 months ago
Option D is definitely the safest choice. Separating the secret value is crucial for security.
upvoted 0 times
...
Haydee
3 months ago
Yeah, keeping the secret value separate is definitely the best practice.
upvoted 0 times
...
Anthony
3 months ago
I agree, keeping the secret value separate from the command is crucial for security.
upvoted 0 times
...
Steffanie
3 months ago
Option D is definitely the safest choice. Separating the secret value is key.
upvoted 0 times
...
Willodean
3 months ago
I agree, Option D is the safest choice.
upvoted 0 times
...
...
Fernanda
4 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
4 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
3 months ago
User 3: Definitely. We should use a different command to avoid putting secrets in the shell history.
upvoted 0 times
...
Bulah
4 months ago
User 2: Yeah, that's a major security risk. We need to be careful with that.
upvoted 0 times
...
Cordie
4 months ago
User 1: Option B is a big no-no. Can't have secrets in the shell history.
upvoted 0 times
...
...
Odette
5 months ago
I agree with Val. Option B is not secure because it exposes the secret in the shell history.
upvoted 0 times
...
Val
5 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