HashiCorp Certified: Vault Operations Professional practice questions

Question 1

A platform team is rolling out a fintech Vault Enterprise cluster on EC2 with the AWS KMS auto-unseal seal block and the principal security engineer wants to know how Vault selects AWS credentials at unseal time. Per the AWS KMS seal documentation, which option matches the credential hierarchy Vault uses?

Accepted Answer

Vault implements a credential hierarchy using the official AWS SDK: explicitly provided configuration values take priority, followed by environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, then AWS CLI profile credentials, and finally IAM role or ECS task credentials.

Answer

Vault always reads AWS_SESSION_TOKEN from the systemd unit file first and falls back to a hardcoded developer access key compiled into the binary when no token is present on the instance at unseal time.

Answer

Vault requires that you mount an AWS Secrets Manager secret into /var/lib/vault/awskms.json before unseal, and it ignores any IAM role attached to the EC2 instance unless that secret file is also present.

Answer

Vault uses the AWS Cognito identity pool tied to the cluster name to obtain temporary credentials on every unseal call and refuses to start if an identity pool is not provisioned in the same region as the cluster.

Question 2

A department is standing up dashboards for its Vault cluster and wants to consume Vault's operational metrics with Prometheus and visualize them in Grafana. Per the Vault Prometheus and Grafana monitoring tutorial, how are the metrics exposed for Prometheus to scrape?

Accepted Answer

Vault returns telemetry from /sys/metrics, and adding format=prometheus yields Prometheus-formatted output

Answer

Vault pushes telemetry directly into Prometheus over remote_write once the prometheus sink stanza is enabled

Answer

Grafana scrapes Vault's audit log file and converts each log entry into a separate Prometheus metric value

Answer

Prometheus reads Vault metrics from /sys/leader, which returns counters in the Prometheus exposition format

Question 3

A production team is tasked with restoring write availability after losing three of five nodes in a Raft cluster during a regional outage on a government FedRAMP Vault deployment. Per the Raft cluster recovery documentation, which option matches?

Accepted Answer

When quorum is lost due to catastrophic failure, manual recovery involves creating a raft/peers.json configuration file specifying the surviving cluster members, which overrides the Raft peer set on the next server restart.

Answer

Quorum loss in Raft requires the operator to re-run vault operator init on every surviving node, which generates a new keyring and unseal key shares while preserving the existing data directory contents on the local disk of each surviving node.

Answer

When quorum is lost the cluster automatically rebalances itself by demoting voters until a new majority is formed from any remaining nodes, so no operator intervention is ever required on a healthy storage backend in a five-node Raft cluster.

Answer

Quorum loss is recovered by promoting an existing performance replication secondary to primary, which restores write availability by re-electing a leader from the secondary cluster while the original primary cluster remains permanently offline thereafter.

Question 4

An architect is tasked with briefing a government FedRAMP review board on why an attacker with direct read access to the storage backend cannot exfiltrate plaintext secrets from a Vault cluster. Per the Vault architecture documentation, which option matches?

Accepted Answer

Vault security model centers on the encryption barrier protecting all data at rest, and the storage backend resides outside the barrier and is considered untrusted, so Vault encrypts data before sending it to storage ensuring that direct access to underlying storage systems does not expose secret data.

Answer

Vault treats the storage backend as a trusted enclave and writes secrets in plaintext into it, relying on object-store ACLs and bucket policies to prevent any unauthorized direct read of those plaintext entries on disk.

Answer

Vault relies on filesystem-level dm-crypt encryption configured by the operator on every Vault host and writes secrets in plaintext to that encrypted volume, so the storage backend itself sees only ciphertext as a side effect of the underlying disk encryption.

Answer

Vault encrypts only audit log entries before they leave the process, while regular KV secrets are written to the storage backend as JSON documents whose values are base64-encoded but not encrypted to keep operational debugging straightforward.

Question 5

A platform team is rolling out AppRole authentication for a fleet of CI/CD runners and the security lead must justify fetching SecretIDs from Vault (Pull mode) rather than letting clients push their own (Push mode). Per the AppRole documentation, which justification is correct?

Accepted Answer

Pull mode is preferred because Push mode requires some other system to hold the full set of client credentials (RoleID and SecretID) to create the entry in Vault.

Answer

Push mode is preferred here because Vault itself mints both the RoleID and the SecretID together, so no external system ever has to hold any client credential at all.

Answer

Pull mode and Push mode behave identically in practice, so the team should simply pick whichever one is least disruptive to wire into the existing CI/CD pipeline.

Answer

Push mode is preferred because it modernizes the App-ID auth method and removes any need to distribute the RoleID and SecretID over separate trusted paths.

Question 6

A developer is evaluating the vault agent generate-config command to bootstrap a Vault Agent config and must understand the documented limits before relying on it. Per the Vault CLI agent generate-config documentation, which option matches?

Accepted Answer

It supports only KV plugins and only env-variable templates, and the generated auto_auth uses the token_file method, which is not appropriate for production.

Answer

It supports every secrets engine and file-based templates, and the generated auto_auth uses the AppRole method, which makes it suitable for production rollouts.

Answer

It supports only database plugins and config-file templates, and the generated auto_auth uses the Kubernetes method for authenticating workloads in-cluster.

Answer

It supports only KV plugins but also generates a full caching and listener config, with auto_auth wired to the AWS iam method for cloud-hosted instances.

Question 7

An engineer is tasked with scaling a multi-region SaaS Vault cluster for very high Transit engine throughput and the principal security engineer wants the documented batch-token behavior. Per the Vault tokens documentation, which option matches?

Accepted Answer

Batch tokens function as encrypted stateless blobs containing sufficient information for Vault operations without requiring disk storage, beginning with the hvb prefix, and this lightweight design makes batch tokens extremely scalable for high-throughput operations.

Answer

Batch tokens are issued exclusively by performance replication primaries and Vault refuses to issue batch tokens on a standalone cluster or on any DR or performance secondary, which is why batch tokens are not used in non-Enterprise Vault deployments at all.

Answer

Batch tokens are simply service tokens that have been administratively flagged as batch via vault token tune so they continue to require storage backend I/O on every validation, but Vault batches the I/O across requests for slightly better throughput on the active node.

Answer

Batch tokens are stored in the encryption barrier with the same on-disk overhead as service tokens but use a shorter UUID encoding scheme that reduces network bandwidth by approximately 8 percent on every API response during steady-state operations.

Question 8

An architect is tasked with briefing a government FedRAMP audit team on how Vault changes behavior when an HSM is configured as the seal. Per the Vault HSM behavior documentation, which option matches the documented dual-key architecture?

Accepted Answer

When deploying Vault with Hardware Security Module support the system implements a fundamental architectural change using two sets of keys instead of one: unseal keys and recovery keys, where recovery keys maintain human oversight for sensitive operations like root token generation while unseal functionality becomes automated through HSM capabilities.

Answer

When deploying Vault with HSM support the unseal key is split into a primary share inside the HSM and a secondary share inside AWS KMS, requiring both services to be online simultaneously for any successful unseal or generate-root operation on the cluster.

Answer

When deploying Vault with HSM support the cluster uses three independent keyrings — barrier, audit, and recovery — and any one of them can be used interchangeably to decrypt either storage data or audit log entries on disk after a successful unseal operation.

Answer

When deploying Vault with HSM support the recovery keys are stored exclusively inside the HSM and operators do not receive any recovery key shares at init time, which is why generate-root requires a vendor-issued vendor reset token rather than recovery-key holders.

Question 9

A platform team is tasked with locking down the IAM policy attached to a Vault cluster's instance role and the principal security engineer wants the minimum KMS actions required for the AWS KMS seal to function. Per the Vault AWS KMS seal documentation, which option matches the required permissions?

Accepted Answer

The service requires three KMS permissions: kms:Encrypt, kms:Decrypt, and kms:DescribeKey, grantable through IAM policies, key policies, or KMS Grants.

Answer

The AWS KMS seal requires kms:CreateKey, kms:ScheduleKeyDeletion, and kms:PutKeyPolicy on the seal key because Vault rotates and re-creates the seal key on every unseal cycle and on every leader election.

Answer

The AWS KMS seal needs only kms:GenerateDataKey on the seal key and Vault never calls kms:Decrypt because it caches the decrypted root key forever after the first unseal of the cluster.

Answer

Vault requires kms:Sign and kms:Verify on the seal key because the AWS KMS seal uses asymmetric RSA signatures rather than symmetric envelope encryption for the root key.

Question 10

An architect is enabling the syslog audit device on a Vault deployment that includes some standby nodes and expects large audit payloads from certain operations. Per the Vault syslog audit device documentation, which TWO statements are accurate?

Accepted Answer

It is only supported on Unix systems and should not be enabled if a standby node does not also support it

Accepted Answer

Because some audit messages can exceed one UDP packet, you should configure a TCP listener where possible

Answer

It supports a configurable remote syslog destination, so you can forward audit logs to a central collector

Answer

It automatically compresses oversized audit messages so each one fits within a single maximum-size packet

Question 11

An administrator is tasked with making a Vault Raft cluster automatically drop nodes that have been unreachable longer than the configured threshold, but after setting dead-server-last-contact-threshold the failed nodes are never removed. Which detail explains why the threshold is being ignored?

Accepted Answer

The threshold takes effect only when cleanup_dead_servers is set, so dead-server removal stays off until that option is enabled.

Answer

The threshold only governs performance replication secondaries, so it never affects the local Raft voter membership of the cluster.

Answer

The threshold is merely the default of 24h, so any unreachable node must wait a full day before the cluster can prune it away.

Answer

The threshold applies only to standby nodes holding the active lock, so the leader node is exempt from dead-server cleanup.

Question 12

A platform team is migrating a Vault cluster to Transit auto-unseal, where a central Vault provides the unwrap key, and the principal engineer must configure the authentication token so the seal does not break unexpectedly. Per the Transit seal configuration documentation, which TWO characteristics should the token used to authenticate to the Transit key have?

Accepted Answer

It should be an orphan token, so the seal does not break if a parent token expires or is revoked.

Accepted Answer

It should be a periodic token with no explicit max TTL, so it does not eventually stop being renewable.

Answer

It should be a batch token, so it is never persisted to storage and avoids any lease tracking overhead.

Answer

It should hold the sudo capability on sys/seal, so it can reseal the whole cluster during maintenance.

Question 13

A platform team is tasked with requiring two senior engineers to approve any delete operation on a fintech compliance secret path and the principal security engineer wants the documented Vault Enterprise feature. Per the Vault Enterprise control groups documentation, which option matches?

Accepted Answer

When a control group is required, instead of returning requested data, the system issues a limited duration response wrapping token that can be passed to authorizers, and only after all required approvals does the token unwrap to process the original request.

Answer

Control groups are evaluated only on unauthenticated paths and reject every authenticated client request that targets a path with a control group attached, which is why HashiCorp recommends using them only for paths that never need fine-grained authorization.

Answer

Control groups enforce multi-party authorization by requiring every authorizer to share their static personal Vault token with the requester so the requester can stitch the tokens together into a multi-signature blob before the secret is released by the cluster.

Answer

Control groups are an alias for Sentinel RGPs and require no additional approval at runtime, which is why they are implemented exclusively in audit-log policy advisories without any control-plane enforcement during the request lifecycle.

Question 14

An engineer is being asked to pick between the ec2 and iam authentication types when wiring Vault Agent auto-auth on EC2 instances, and the principal security engineer wants the documented recommendation and its rationale. Per the Vault Agent AWS auto-auth documentation, which option matches?

Accepted Answer

Prefer the iam type when possible, because the Trust On First Use model used by the ec2 type adds complexity that the iam type does not have.

Answer

Prefer the ec2 type, because it persists its reauthentication value to disk and that lets the Agent survive restarts without contacting Vault again.

Answer

Prefer the ec2 type, because like the AppRole method it reads a role ID and a secret ID from files and then caches them safely for later reuse.

Answer

Prefer the iam type only on Kubernetes pods, since the ec2 type is the required choice for any workload that runs directly on EC2 instances.

Question 15

An organization is designing a disaster recovery topology with a Vault Enterprise DR secondary in a second region and the architect wants to confirm whether applications can read or write secrets directly from that DR secondary during normal operation. Per the Vault Enterprise Disaster Recovery Replication documentation, which option matches?

Accepted Answer

DR secondaries do not forward service read or write requests until they are elected and become a new primary cluster.

Answer

DR secondaries actively serve read requests locally while transparently forwarding any write requests onward to the primary cluster.

Answer

DR secondaries serve both reads and writes independently, giving the second region a fully active-active Vault deployment setup.

Answer

DR secondaries serve only Transit and KV reads but reject token and lease operations until a manual promotion is triggered.

HashiCorp Certified: Vault Operations Professional

Sample questions

Sources

Similar exams