Scenario practice questions

During a security assessment, a penetration tester discovers that Vault's seal configuration uses a single master key stored in a file on the server. The attacker gains root access to the server and retrieves the unseal key. What is the best mitigation to prevent this scenario?

Trap 1: Restrict network access to the Vault server with a firewall

A firewall limits network reachability but does nothing once an attacker has root on the host, since the unseal key file remains readable locally. It is tempting because network segmentation is a genuine hardening control, and would be correct against remote attackers lacking server access.

Trap 2: Use Shamir's secret sharing to split the key across multiple files

Shamir's secret sharing splits the unseal key into shares, but storing all shares on the same server lets root read every one. It is tempting because Shamir is Vault's default unseal mechanism, and would be correct if each share were held by a separate operator off-host.

Trap 3: Encrypt the unseal key file with a strong password

Password-encrypting the key file still leaves the decryption material on the compromised host, so root access defeats it. It is tempting because encryption at rest is a real control, and would be correct against theft of the disk or backup rather than a live root compromise.

A
Restrict network access to the Vault server with a firewall
Why it fails: A firewall limits network reachability but does nothing once an attacker has root on the host, since the unseal key file remains readable locally. It is tempting because network segmentation is a genuine hardening control, and would be correct against remote attackers lacking server access.
B
Use a cloud auto-unseal mechanism such as AWS KMS
Cloud auto-unseal delegates the unseal key to an external KMS, so the root key never resides on the Vault server's filesystem. Root access alone then cannot retrieve it; the attacker would also need KMS credentials and permissions. This directly satisfies the stem's constraint of preventing unseal-key theft via server compromise.
C
Use Shamir's secret sharing to split the key across multiple files
Why it fails: Shamir's secret sharing splits the unseal key into shares, but storing all shares on the same server lets root read every one. It is tempting because Shamir is Vault's default unseal mechanism, and would be correct if each share were held by a separate operator off-host.
D
Encrypt the unseal key file with a strong password
Why it fails: Password-encrypting the key file still leaves the decryption material on the compromised host, so root access defeats it. It is tempting because encryption at rest is a real control, and would be correct against theft of the disk or backup rather than a live root compromise.

Question 2hardmultiple choice

An application uses a periodic token with period=24h. The application renews every 12h. After 48h, the token is still valid. After 72h, the token is still valid. What is the maximum lifetime of this periodic token?

Trap 1: 72h

A 72h maximum would have invalidated the token at the 72h check, but the stem confirms it was still valid at that point. It is tempting as three periods, and would be correct if renewal stopped extending the token's life after the third period.

Trap 2: 48h

A 48h maximum would have invalidated the token at the 48h check, yet the stem states it remained valid then. It is tempting as double the period, and would be correct if the token had been issued without renewal extending its life beyond two periods.

Trap 3: 24h

A 24h maximum would have invalidated the token at the first renewal boundary, contradicting its validity at 48h and 72h. It is tempting as the period value, and would be correct if the token were non-renewable and expired after a single period.

A
Unlimited (as long as it keeps renewing)
Periodic tokens have no fixed maximum lifetime; each renewal resets the validity window rather than counting toward an absolute expiry. Because the application renews every 12h against a 24h period, the token stays valid indefinitely, so the lifetime is effectively unlimited while renewals continue.
B
72h
Why it fails: A 72h maximum would have invalidated the token at the 72h check, but the stem confirms it was still valid at that point. It is tempting as three periods, and would be correct if renewal stopped extending the token's life after the third period.
C
48h
Why it fails: A 48h maximum would have invalidated the token at the 48h check, yet the stem states it remained valid then. It is tempting as double the period, and would be correct if the token had been issued without renewal extending its life beyond two periods.
D
24h
Why it fails: A 24h maximum would have invalidated the token at the first renewal boundary, contradicting its validity at 48h and 72h. It is tempting as the period value, and would be correct if the token were non-renewable and expired after a single period.

Question 3easymultiple choice

A developer wants to authenticate to Vault using a username and password without any external identity provider. Which authentication method should be enabled?

Trap 1: Token authentication

Token authentication issues tokens but provides no username-and-password credential store, so it cannot satisfy the developer's requirement without an external identity provider. It is tempting because tokens are Vault's core auth primitive, but the userpass method is the correct choice for direct username and password login.

Trap 2: LDAP authentication

LDAP authentication delegates credential verification to an external directory server, which the scenario explicitly excludes. It is tempting because LDAP is the standard way to give existing directory users username-and-password access to Vault, and would be correct if an LDAP server were already available.

Trap 3: AppRole authentication

AppRole authenticates machines using RoleID and SecretID, not human username-and-password credentials. It is tempting because AppRole is Vault's recommended method for applications and CI pipelines, and would be correct for a service authenticating without an identity provider.

A
Userpass authentication
Userpass authentication stores credentials directly in Vault, letting the developer log in with a username and password alone. It satisfies the stem's constraint of requiring no external identity provider, unlike OIDC or LDAP methods that delegate verification to Microsoft Entra ID or another directory service.
B
Token authentication
Why it fails: Token authentication issues tokens but provides no username-and-password credential store, so it cannot satisfy the developer's requirement without an external identity provider. It is tempting because tokens are Vault's core auth primitive, but the userpass method is the correct choice for direct username and password login.
C
LDAP authentication
Why it fails: LDAP authentication delegates credential verification to an external directory server, which the scenario explicitly excludes. It is tempting because LDAP is the standard way to give existing directory users username-and-password access to Vault, and would be correct if an LDAP server were already available.
D
AppRole authentication
Why it fails: AppRole authenticates machines using RoleID and SecretID, not human username-and-password credentials. It is tempting because AppRole is Vault's recommended method for applications and CI pipelines, and would be correct for a service authenticating without an identity provider.

Question 4easymulti select

A DevOps team is setting up a Vault cluster for the first time. They plan to use AWS KMS for auto-unseal and Consul as the storage backend. As part of the architecture, which TWO components are essential for the Vault server to start and serve requests?

Trap 1: A public CA certificate

Vault serves requests over TLS, but a public CA certificate is not essential; an internal or self-signed certificate works, and the cluster can start without one. Public CA certificates suit externally facing endpoints where clients must trust the certificate chain without custom CA distribution.

Trap 2: A 4096-bit encryption key

A 4096-bit encryption key is not a startup prerequisite; Vault generates its own master and unseal keys, and AWS KMS supplies the auto-unseal wrapping key. Specifying key length is tempting because strong key sizes matter for cryptographic compliance, but key length is a configuration choice, not a component Vault requires to start.

Trap 3: A load balancer

A load balancer distributes client traffic but is not required for Vault to start or serve requests; a single node answers directly on its API port. Load balancers suit highly available multi-node clusters needing health-checked traffic distribution, which is an availability design choice rather than a startup dependency.

A
A public CA certificate
Why it fails: Vault serves requests over TLS, but a public CA certificate is not essential; an internal or self-signed certificate works, and the cluster can start without one. Public CA certificates suit externally facing endpoints where clients must trust the certificate chain without custom CA distribution.
B
A storage backend
Consul provides durable, highly available storage for Vault's encrypted data, and Vault cannot initialise or unseal without a configured storage backend. The stem specifies Consul as that backend, making it essential for the server to start and serve requests.
C
A configured seal mechanism
A configured seal mechanism is essential because Vault cannot start or serve requests while sealed. With AWS KMS auto-unseal, the seal stanza supplies the KMS key ID and region, letting Vault automatically unseal at startup without manual Shamir key entry, satisfying the stem's requirement for the server to start and serve requests.
D
A 4096-bit encryption key
Why it fails: A 4096-bit encryption key is not a startup prerequisite; Vault generates its own master and unseal keys, and AWS KMS supplies the auto-unseal wrapping key. Specifying key length is tempting because strong key sizes matter for cryptographic compliance, but key length is a configuration choice, not a component Vault requires to start.
E
A load balancer
Why it fails: A load balancer distributes client traffic but is not required for Vault to start or serve requests; a single node answers directly on its API port. Load balancers suit highly available multi-node clusters needing health-checked traffic distribution, which is an availability design choice rather than a startup dependency.

Question 5easymultiple choice

In a Vault HA cluster, which node is responsible for handling all write requests?

Trap 1: All nodes

Only the active node handles writes; standby nodes forward client requests to it. The option tempts because all nodes share the replicated storage backend and can serve reads, but Raft permits a single leader to commit write operations.

Trap 2: Standby nodes

Standby nodes hold replicated data but redirect writes to the active node; they never commit them. The option tempts because standbys appear active in the cluster and can take over after failover, yet only the elected leader processes write requests.

Trap 3: The node that receives the request

Any node receiving a write forwards it to the active node, which alone commits it to the Raft log. The option tempts because clients can address any node, but the standby simply proxies the request rather than handling the write itself.

A
All nodes
Why it fails: Only the active node handles writes; standby nodes forward client requests to it. The option tempts because all nodes share the replicated storage backend and can serve reads, but Raft permits a single leader to commit write operations.
B
The active node only
Vault's integrated storage and HA design route all writes through a single leader. Standby nodes forward client requests to the active node, which alone holds the write lock on the barrier. This ensures consistency, so only the active node handles write requests.
C
Standby nodes
Why it fails: Standby nodes hold replicated data but redirect writes to the active node; they never commit them. The option tempts because standbys appear active in the cluster and can take over after failover, yet only the elected leader processes write requests.
D
The node that receives the request
Why it fails: Any node receiving a write forwards it to the active node, which alone commits it to the Raft log. The option tempts because clients can address any node, but the standby simply proxies the request rather than handling the write itself.

Question 6hardmultiple choice

A company requires that Vault data be continuously replicated from a primary data center to a secondary data center for disaster recovery. The secondary data center must be able to become writable in the event of a primary failure. Which Vault feature should they use?

Trap 1: Performance Replication

Performance Replication keeps secondaries read-only and forwards writes to the primary; it cannot be promoted to a writable primary. It tempts because it does replicate data continuously, but that is for read scaling across data centres, not disaster recovery takeover.

Trap 2: Consul as storage backend

Consul as storage backend provides HA within a single cluster, not cross-data-centre replication with promotion. It tempts because Consul spans data centres and stores Vault data, but it does not deliver Vault's DR replication or the ability to promote a secondary.

Trap 3: Performance Standby

Performance Standby nodes serve reads within one cluster while forwarding writes to the active node; they are not a cross-site replication or failover mechanism. It tempts because it improves read throughput, but it does not replicate data to a secondary data centre or allow promotion.

A
Performance Replication
Why it fails: Performance Replication keeps secondaries read-only and forwards writes to the primary; it cannot be promoted to a writable primary. It tempts because it does replicate data continuously, but that is for read scaling across data centres, not disaster recovery takeover.
B
Consul as storage backend
Why it fails: Consul as storage backend provides HA within a single cluster, not cross-data-centre replication with promotion. It tempts because Consul spans data centres and stores Vault data, but it does not deliver Vault's DR replication or the ability to promote a secondary.
C
Performance Standby
Why it fails: Performance Standby nodes serve reads within one cluster while forwarding writes to the active node; they are not a cross-site replication or failover mechanism. It tempts because it improves read throughput, but it does not replicate data to a secondary data centre or allow promotion.
D
Disaster Recovery Replication
Disaster Recovery Replication continuously ships data to a secondary that can be promoted to a writable primary, satisfying the stem's requirement for failover writability. Performance Replication secondaries remain read-only for most operations, so they cannot meet that constraint.

Question 7easymultiple choice

A developer needs to authenticate to Vault from a CI/CD pipeline running on an on-premises server. The pipeline cannot use cloud provider identities or Kubernetes. The security team wants to avoid embedding long-lived Vault tokens in the pipeline scripts. Which authentication method is most appropriate?

Trap 1: Username & Password auth method

Username & Password auth requires a static username and password stored in Vault. Embedding these in pipeline scripts would violate the requirement to avoid long-lived credentials. It also lacks the fine-grained control and secret_id TTL features of AppRole, making it less secure for CI/CD.

Trap 2: GitHub auth method

GitHub auth is for authenticating with GitHub credentials, which is not suitable for a CI/CD pipeline on an on-premises server that may not have GitHub integration. It would require the pipeline to have a GitHub token, which is a static secret, and does not align with the goal of avoiding long-lived credentials.

Trap 3: OIDC auth method

OIDC auth is for human users authenticating via an identity provider, not for machine-to-machine CI/CD pipelines. It requires an interactive browser flow or a JWT from an OIDC provider, which is not typically available on an on-premises server without additional infrastructure. It does not fit the pipeline scenario.

A
AppRole auth method
AppRole is designed for machine-to-machine authentication and is ideal for CI/CD pipelines. It uses a role_id and secret_id, which can be delivered securely and have short TTLs. This avoids embedding long-lived tokens. The pipeline can retrieve a secret_id dynamically (e.g., from a trusted orchestrator) and authenticate to get a short-lived Vault token.
B
Username & Password auth method
Why it fails: Username & Password auth requires a static username and password stored in Vault. Embedding these in pipeline scripts would violate the requirement to avoid long-lived credentials. It also lacks the fine-grained control and secret_id TTL features of AppRole, making it less secure for CI/CD.
C
GitHub auth method
Why it fails: GitHub auth is for authenticating with GitHub credentials, which is not suitable for a CI/CD pipeline on an on-premises server that may not have GitHub integration. It would require the pipeline to have a GitHub token, which is a static secret, and does not align with the goal of avoiding long-lived credentials.
D
OIDC auth method
Why it fails: OIDC auth is for human users authenticating via an identity provider, not for machine-to-machine CI/CD pipelines. It requires an interactive browser flow or a JWT from an OIDC provider, which is not typically available on an on-premises server without additional infrastructure. It does not fit the pipeline scenario.

Question 8hardmultiple choice

A security engineer is comparing the AppRole and Kubernetes auth methods for a containerized application. The application runs in a Kubernetes cluster and needs to authenticate to Vault. The engineer wants to minimize the risk of secret leakage and avoid manual secret rotation. Which statement best describes the advantage of Kubernetes auth over AppRole in this scenario?

Trap 1: Kubernetes auth automatically rotates the Vault token every 24…

Kubernetes auth does not automatically rotate Vault tokens; token TTLs are configured in the Vault role. The service account token is rotated by Kubernetes, but Vault tokens have their own TTL and renewal behavior. This statement conflates the two and is incorrect about automatic rotation.

Trap 2: AppRole is always more secure because it supports CIDR binding,…

AppRole supports CIDR binding, but Kubernetes auth also supports binding to service account names, namespaces, and even pod labels. More importantly, AppRole requires storing a secret_id, which is a static secret. Kubernetes auth avoids that, so it is not inherently less secure. The statement overgeneralizes security.

Trap 3: Kubernetes auth requires a secret_id that is stored in a Kubernetes…

Kubernetes auth does not use a secret_id; it uses the service account token. Storing a secret_id in a Kubernetes Secret would reintroduce a static secret and manual rotation, which is exactly what the engineer wants to avoid. This statement misrepresents how Kubernetes auth works.

A
Kubernetes auth automatically rotates the Vault token every 24 hours without any configuration.
Why it fails: Kubernetes auth does not automatically rotate Vault tokens; token TTLs are configured in the Vault role. The service account token is rotated by Kubernetes, but Vault tokens have their own TTL and renewal behavior. This statement conflates the two and is incorrect about automatic rotation.
B
AppRole is always more secure because it supports CIDR binding, while Kubernetes auth does not.
Why it fails: AppRole supports CIDR binding, but Kubernetes auth also supports binding to service account names, namespaces, and even pod labels. More importantly, AppRole requires storing a secret_id, which is a static secret. Kubernetes auth avoids that, so it is not inherently less secure. The statement overgeneralizes security.
C
Kubernetes auth uses a service account token that is automatically mounted and rotated by Kubernetes, eliminating the need to store a static secret_id.
Kubernetes auth leverages the pod's service account token, which Kubernetes automatically mounts and rotates. This eliminates the need to store a static secret_id as with AppRole. The application does not manage any long-lived secret, reducing leakage risk and manual rotation overhead. This directly addresses the engineer's goals.
D
Kubernetes auth requires a secret_id that is stored in a Kubernetes Secret and manually rotated.
Why it fails: Kubernetes auth does not use a secret_id; it uses the service account token. Storing a secret_id in a Kubernetes Secret would reintroduce a static secret and manual rotation, which is exactly what the engineer wants to avoid. This statement misrepresents how Kubernetes auth works.

Question 9mediummultiple choice

An application team is using a batch token to authenticate to Vault for a long-running data processing job. The token was created with a TTL of 8 hours and no explicit max TTL. After 4 hours, the application attempts to renew the token but receives an error. What is the most likely reason for the renewal failure?

Trap 1: The token's max TTL is less than 8 hours.

If the token had a max TTL shorter than the requested TTL, it would have been issued with that shorter TTL, but renewal would still be possible until the max TTL is reached. However, batch tokens cannot be renewed at all. The scenario does not indicate a max TTL constraint; the failure is due to the token being a batch token.

Trap 2: The token's TTL has already expired.

The token was created with an 8-hour TTL, and the renewal attempt occurs after only 4 hours. Therefore, the TTL has not expired. While an expired token would indeed cause renewal to fail, that is not the case here. The failure is due to the token type, not expiration.

Trap 3: The token does not have a renewable flag set.

Batch tokens are always non-renewable by design, regardless of any renewable flag. While service tokens can be made non-renewable by omitting the renewable flag, batch tokens do not support renewal at all. The absence of a renewable flag is not the root cause here; the token type itself is the issue.

A
The token's max TTL is less than 8 hours.
Why it fails: If the token had a max TTL shorter than the requested TTL, it would have been issued with that shorter TTL, but renewal would still be possible until the max TTL is reached. However, batch tokens cannot be renewed at all. The scenario does not indicate a max TTL constraint; the failure is due to the token being a batch token.
B
The token's TTL has already expired.
Why it fails: The token was created with an 8-hour TTL, and the renewal attempt occurs after only 4 hours. Therefore, the TTL has not expired. While an expired token would indeed cause renewal to fail, that is not the case here. The failure is due to the token type, not expiration.
C
The token is a batch token, which cannot be renewed.
Batch tokens are designed to be lightweight and stateless; they do not support renewal. Once issued, they remain valid until their TTL expires, but they cannot be extended. In this scenario, the application's attempt to renew a batch token fails because batch tokens are inherently non-renewable, regardless of the remaining TTL.
D
The token does not have a renewable flag set.
Why it fails: Batch tokens are always non-renewable by design, regardless of any renewable flag. While service tokens can be made non-renewable by omitting the renewable flag, batch tokens do not support renewal at all. The absence of a renewable flag is not the root cause here; the token type itself is the issue.

Question 10hardmultiple choice

A security engineer is comparing two machine-oriented auth methods for workloads running outside Kubernetes. The workloads cannot use cloud instance identity and must not store a long-lived credential on disk. The engineer wants a method where the workload proves possession of a one-time-use credential that can be issued with a very short TTL and limited use count. Which auth method best fits?

Trap 1: Userpass, with each workload assigned a dedicated username and a…

Userpass relies on a static username and password pair stored in Vault. Even with weekly rotation, the workload must hold a usable password at all times, which contradicts the requirement not to store a long-lived credential on disk. It also lacks the one-time-use semantics and short TTL granularity that the scenario demands.

Trap 2: Token auth, by pre-generating a periodic token with a long period…

A pre-generated periodic token is itself a long-lived credential: it renews indefinitely as long as it is used within its period. Distributing it to workloads means the token persists on disk and, if leaked, remains valid until explicitly revoked. This is the opposite of a one-time-use credential with a very short lifetime.

Trap 3: Cert auth, by issuing each workload a client certificate from the…

Cert auth authenticates using a TLS client certificate and maps it to a role via CA or allowed common names. A one-year certificate is a long-lived credential stored on disk, and there is no native one-time-use or num_uses concept. It fails both the no-long-lived-secret requirement and the short-TTL, limited-use requirement.

A
Userpass, with each workload assigned a dedicated username and a randomly generated password rotated weekly.
Why it fails: Userpass relies on a static username and password pair stored in Vault. Even with weekly rotation, the workload must hold a usable password at all times, which contradicts the requirement not to store a long-lived credential on disk. It also lacks the one-time-use semantics and short TTL granularity that the scenario demands.
B
Token auth, by pre-generating a periodic token with a long period and distributing it to each workload.
Why it fails: A pre-generated periodic token is itself a long-lived credential: it renews indefinitely as long as it is used within its period. Distributing it to workloads means the token persists on disk and, if leaked, remains valid until explicitly revoked. This is the opposite of a one-time-use credential with a very short lifetime.
C
AppRole, using a secret ID with num_uses set to 1 and a short secret_id_ttl, paired with the role ID.
AppRole splits authentication into a role ID (semi-public identifier) and a secret ID (sensitive, one-time-use credential). Setting num_uses to 1 makes the secret ID invalid after a single login, and a short secret_id_ttl bounds its lifetime. This lets a workload retrieve the secret ID at runtime without persisting a long-lived secret, satisfying the possession-of-one-time-credential requirement.
D
Cert auth, by issuing each workload a client certificate from the organization's internal CA with a one-year validity.
Why it fails: Cert auth authenticates using a TLS client certificate and maps it to a role via CA or allowed common names. A one-year certificate is a long-lived credential stored on disk, and there is no native one-time-use or num_uses concept. It fails both the no-long-lived-secret requirement and the short-TTL, limited-use requirement.