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 Vault-Associate Exam - Topic 7 Question 56 Discussion

Security requirements demand that no secrets appear in the shell history. Which command does not meet this requirement?
B) vault kv put secret/password value-itsasecret
A) generate-password | vault kv put secret/password value
C) vault kv put secret/password value=@data.txt
D) vault kv put secret/password value-SSECRET_VALUE

HashiCorp Vault-Associate Exam - Topic 7 Question 56 Discussion

Actual exam question for HashiCorp's Vault-Associate exam
Question #: 56
Topic #: 7
[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
Rosio
11 hours ago
Definitely, it hides the value.
upvoted 0 times
...
Quentin
6 days ago
Right, option C is safer.
upvoted 0 times
...
Jill
11 days ago
A good practice is to use files instead.
upvoted 0 times
...
Rosio
16 days ago
Exactly, we need to avoid that.
upvoted 0 times
...
Quentin
21 days ago
Shell history will expose it.
upvoted 0 times
...
Jill
26 days ago
I agree, it’s not secure at all.
upvoted 0 times
...
Rosio
1 month ago
Yeah, it shows the secret directly.
upvoted 0 times
...
Quentin
1 month ago
I think option B is the one.
upvoted 0 times
...
Yong
1 month ago
I’m surprised this is even a question, it seems obvious!
upvoted 0 times
...
Wayne
2 months ago
Option A is safe too, right? No secrets in the command line.
upvoted 0 times
...
Horace
2 months ago
Wait, are you sure about that? What about option D?
upvoted 0 times
...
Noah
2 months ago
Yeah, I agree, that one’s a no-go for security!
upvoted 0 times
...
Reita
2 months ago
I think option B shows the secret directly in the command.
upvoted 0 times
...
Junita
2 months ago
I’m confused, but I think B is the safest since it doesn’t seem to expose anything in the command line directly.
upvoted 0 times
...
Lina
2 months ago
I practiced a similar question, and I feel like D could be problematic because it looks like it directly includes a secret value.
upvoted 0 times
...
Iluminada
3 months ago
I'm not entirely sure, but I remember something about how using a file with the '@' symbol could be safer, so maybe C is okay?
upvoted 0 times
...
Paulina
3 months ago
I think option A might be the one that shows up in shell history since it uses a pipe.
upvoted 0 times
...

Save Cancel