Cisco®
CompTIA
Checkpoint
ISC
EC-Council
EXIN
Fortinet
ITIL®
Juniper
Microsoft
VMware
Avaya
SAP
Google
Salesforce
Amazon
Palo Alto Networks
ISC2
All Vendors
  2. Home
  3. Exams
  4. HashiCorp
  5. HCVA0-003

Free HashiCorp HCVA0-003 Exam Questions (page: 14)

Page 14 of 73
PDF with 285 Questions

What is the difference between the TTL and the Max TTL (select two)?

  1. The TTL defines when the token will expire and be revoked
  2. The TTL defines when another token will be generated
  3. The Max TTL defines the timeframe for which a token cannot be used
  4. The Max TTL defines the maximum timeframe for which a token can be renewed

Answer(s): A,D

Explanation:

Comprehensive and Detailed in Depth
Vault tokens have two key time attributes: TTL (Time-To-Live) and Max TTL (Maximum Time-To-Live), governing their lifecycle. Let's dissect each option:
Option A: The TTL defines when the token will expire and be revoked The TTL is the current lifespan of a token before it expires. For example, a token with a TTL of 24h (vault token create -ttl=24h) expires 24 hours from creation unless renewed. Upon expiry, Vault revokes it automatically. This is a fundamental property of TTL, making this statement accurate.
Correct.
Vault Docs Insight: "The TTL defines when the token will expire... if it reaches its TTL, it will be revoked by Vault." (Core definition.)
Option B: The TTL defines when another token will be generated TTL governs expiration, not token generation. New tokens are created explicitly (e.g., vault token create) or via auth methods, not automatically by TTL. This misunderstands TTL's role--it's about expiry, not regeneration. Incorrect.
Vault Docs Insight: "TTL is the duration until expiration... New tokens are not generated by TTL." (No generation link.)
Option C: The Max TTL defines the timeframe for which a token cannot be used This is backwards. Max TTL sets the upper limit a token can exist through renewals, not a period of inactivity or unusability. A token with a Max TTL of 72h can be renewed up to 72 hours from creation, after which it's revoked. This option inverts the concept. Incorrect. Vault Docs Insight: "Max TTL defines the maximum timeframe for which the token can be renewed...
not a usage restriction." (Opposite meaning.)
Option D: The Max TTL defines the maximum timeframe for which a token can be renewed Max TTL caps the total lifespan of a token, including renewals. For example, a token with TTL=24h and Max TTL=72h (vault token create -ttl=24h -explicit-max-ttl=72h) can be renewed twice (24h + 24h + 24h = 72h) before hitting the limit. Beyond 72h, renewal fails, and it expires. This is the precise definition of Max TTL. Correct.
Vault Docs Insight: "The Max TTL defines the maximum timeframe for which the token can be renewed... Once reached, it cannot be renewed further." (Exact match.) Detailed Mechanics:
TTL is dynamic, decreasing as time passes (e.g., vault token lookup shows ttl: 23h59m50s after 10 seconds). Renewal (vault token renew) resets TTL to its original value (e.g., 24h), but only up to Max TTL from creation. System defaults (768h/32 days) apply unless overridden. Periodic tokens (- period=24h) renew indefinitely within their period, ignoring Max TTL unless explicitly set.
Real-World Example:
Create: vault token create -ttl=1h -explicit-max-ttl=3h. After 1h, TTL=0, renewable. Renew at 2h total, TTL=1h again. At 3h total, Max TTL hits--revoked. Contrast with TTL-only: vault token create -ttl=1h, renewable up to system Max TTL (768h).
Overall Explanation from Vault Docs:
"The TTL defines when the token will expire... If it reaches its TTL, it will be immediately revoked by Vault. The Max TTL defines the maximum timeframe for which the token can be renewed... Once the Max TTL is reached, the token cannot be renewed any longer and will be revoked." These attributes ensure controlled token lifecycles.


Reference:

https://developer.hashicorp.com/vault/docs/concepts/tokens#token-time-to-live- periodic-tokens-and-explicit-max-ttls



What is true about the output of the following command (select three)?

  1. The admin never sees all the unseal keys and cannot unseal Vault by themselves
  2. All three users, Jane/John/Student01, will receive all unseal keys and can unseal Vault
  3. The admin will receive the unseal keys and be able to unseal Vault themselves
  4. The keys will be returned encrypted
  5. Each individual can only decrypt their own unseal key using their private PGP key

Answer(s): A,D,E

Explanation:

Comprehensive and Detailed in Depth
The command initializes Vault, splitting the master key into 3 shares (threshold 2) and encrypting each with PGP keys for Jane, John, and Student01. Let's analyze:
Option A: The admin never sees all the unseal keys and cannot unseal Vault by themselves With -pgp-keys, Vault encrypts each share with a user's public PGP key. The admin (initializer) sees only encrypted outputs (e.g., Key 1: <encrypted>), not plaintext keys. Since 2 shares are needed and no single entity gets all, the admin can't unseal alone. Correct. Vault Docs Insight: "The initializer receives encrypted keys... never sees all plaintext keys, enhancing security." (Directly stated.)
Option B: All three users, Jane/John/Student01, will receive all unseal keys and can unseal Vault Each user gets one encrypted share (e.g., Jane gets Key 1, John Key 2). No user receives all shares-- only one, decryptable with their private key. Unsealing requires collaboration (2 of 3), so this is false.
Incorrect.
Vault Docs Insight: "Each PGP key encrypts one share... No single user gets all keys." (Distribution is per-user.)
Option C: The admin will receive the unseal keys and be able to unseal Vault themselves Without PGP, the admin gets plaintext keys. With -pgp-keys, they get encrypted keys they can't decrypt (lacking private keys). Threshold=2 means collaboration is required. Incorrect. Vault Docs Insight: "Using PGP keys ensures the initializer cannot unseal alone..." (Security feature.) Option D: The keys will be returned encrypted
The -pgp-keys flag encrypts each share with the corresponding public key. Output shows encrypted blobs (e.g., base64-encoded PGP ciphertext), not plaintext. Correct. Vault Docs Insight: "Vault will generate the unseal keys and encrypt them using the given PGP keys..." (Explicit behavior.)
Option E: Each individual can only decrypt their own unseal key using their private PGP key Each share is encrypted with one user's public key (e.g., Jane's key encrypts Key 1). Only Jane's private key decrypts it. This ensures secure distribution. Correct. Vault Docs Insight: "Only the owner of the corresponding private key can decrypt the value..." (PGP security.)
Detailed Mechanics:
Command: vault operator init -key-shares=3 -key-threshold=2 -pgp- keys="jane.pgp,john.pgp,student01.pgp". Vault generates 3 shares via Shamir's Secret Sharing, encrypts each (Key 1 with jane.pgp, etc.), and outputs encrypted strings. Unsealing requires 2

decrypted shares combined via vault operator unseal. PGP ensures the admin can't access plaintext, enforcing split knowledge.
Real-World Example:
Output: Key 1: <encrypted-jane>, Key 2: <encrypted-john>, Key 3: <encrypted-student01>. Jane decrypts Key 1 with gpg -d, John decrypts Key 2. They submit via UI or CLI to unseal.
Overall Explanation from Vault Docs:
"Vault can optionally be initialized using PGP keys. In this mode, Vault will generate the unseal keys and immediately encrypt them using the given users' public PGP keys. Only the owner of the corresponding private key is able to decrypt the value... The initializer never sees all plaintext keys and cannot unseal Vault alone." This enhances security by distributing trust.


Reference:

https://developer.hashicorp.com/vault/docs/commands/operator/init#pgp-keys



How can Vault be used to programmatically obtain a generated code for MFA, somewhat similar to Google Authenticator?

  1. Cubbyhole
  2. The random byte generator
  3. TOTP secrets engine
  4. The identity secrets engine

Answer(s): C

Explanation:

Comprehensive and Detailed in Depth
Vault can generate time-based one-time passwords (TOTP) for multi-factor authentication (MFA), mimicking apps like Google Authenticator. Let's evaluate:
Option A: Cubbyhole
Cubbyhole is a per-token secret store, not a TOTP generator. It's for temporary secret storage, not MFA code generation. Incorrect.
Vault Docs Insight: "Cubbyhole stores secrets tied to a token... no TOTP functionality." (Different purpose.)
Option B: The random byte generator
Vault's /sys/tools/random endpoint generates random bytes, not time-based codes synced with a clock (TOTP requirement). It's for generic randomness, not MFA. Incorrect. Vault Docs Insight: "Random bytes are not time-based... unsuitable for TOTP." (Unrelated feature.) Option C: TOTP secrets engine
The TOTP engine generates and validates TOTP codes (e.g., 6-digit codes every 30s) using a shared secret, just like Google Authenticator. You create a key (vault write totp/keys/my-key) and fetch codes (vault read totp/code/my-key). Perfect for programmatic MFA. Correct. Vault Docs Insight: "The TOTP secrets engine can act as a TOTP code generator... replacing traditional generators like Google Authenticator." (Exact match.)
Option D: The identity secrets engine
The Identity engine manages user/entity identities and policies, not TOTP codes. It's for identity management, not MFA generation. Incorrect.
Vault Docs Insight: "Identity engine handles identity data... no TOTP generation." (Different scope.)

Detailed Mechanics:
Enable: vault secrets enable totp. Create key: vault write totp/keys/my-key issuer=Vault. Get code:
vault read totp/code/my-key returns {"data":{"code":"123456"}}. Codes sync with time (RFC 6238), usable in APIs or apps.
Overall Explanation from Vault Docs:
"The TOTP secrets engine can act as a TOTP code generator... It provides an added layer of security since the ability to generate codes is guarded by policies and audited."


Reference:

https://developer.hashicorp.com/vault/docs/secrets/totp



From the options below, select the auth methods that are better suited for machine-to-machine authentication (select five):

  1. Kubernetes
  2. GitHub
  3. TLS
  4. Token
  5. AppRole
  6. AWS
  7. LDAP
  8. OIDC

Answer(s): A,C,D,E,F

Explanation:

Comprehensive and Detailed in Depth
Machine-to-machine (M2M) auth methods in Vault enable automated systems to authenticate without human interaction. Let's assess:
A: Kubernetes - Uses service account tokens for pods. Correct. Vault Docs Insight: "Kubernetes auth... ideal for workloads in Kubernetes clusters."
B: GitHub - User-focused, requires human GitHub login. Incorrect. Vault Docs Insight: "GitHub auth... typically for human users."
C: TLS - Certificate-based, perfect for M2M. Correct.
Vault Docs Insight: "TLS auth uses certificates... suited for machine authentication."
D: Token - Pre-generated tokens for automation. Correct. Vault Docs Insight: "Token auth... can be used by machines with proper management."
E: AppRole - RoleID/SecretID for apps. Correct.
Vault Docs Insight: "AppRole is designed for machine-to-machine authentication..."
F: AWS - IAM roles for AWS resources. Correct.
Vault Docs Insight: "AWS auth... automated for AWS-based machines."
G: LDAP - User directory-based, human-oriented. Incorrect. Vault Docs Insight: "LDAP... commonly for human user authentication."
H: OIDC - User SSO, not M2M. Incorrect.
Vault Docs Insight: "OIDC... for human single sign-on." Overall Explanation from Vault Docs:

"Examples of machine auth methods include AppRole, AWS, Kubernetes, TLS, and Token... Human auth methods include LDAP, GitHub, OIDC."


Reference:

https://developer.hashicorp.com/vault/docs/auth



Viewing page 14 of 73
Viewing questions 53 - 56 out of 285 questions



Post your Comments and Discuss HashiCorp HCVA0-003 exam prep with other Community members:

HCVA0-003 Exam Discussions & Posts