Vault Operations Professional: An Operator's View of the Advanced Exam Scope

Vault Operations Professional (Ops Pro) tests your ability to run Vault in production safely and without downtime. Building on the Associate-level foundation, it covers practical operational procedures including HA design, storage selection, seal/unseal, backup and recovery, monitoring, and Enterprise replication.

This article frames the advanced exam's positioning and scope around real operational decisions — which backend to choose, which procedures to standardize. We focus on concepts and procedures that are stable in the official documentation, avoiding version-dependent features.

Positioning as an Advanced Exam and Its Scope

Ops Pro is an advanced certification for operators responsible for keeping Vault available and recoverable. It tests design decisions (storage approach, unseal strategy, HA, backup/DR) and day-to-day operational SOPs (initialization, rotation, auditing, and handling maintenance windows).

The exam is multiple choice and verifies that you understand design intent and the effect of commands (operator family, raft, audit, sys/health response codes, and so on). Understanding of Enterprise features (DR/Performance Replication, Namespaces) is also sometimes assumed.

• Target roles: SRE/platform operations, security operations, infrastructure automation
• Main topics: storage and HA, Auto Unseal, initialization and key management, backup/recovery, auditing, upgrade strategy, Enterprise replication
• Question style: scenario-based best-practice selection, understanding the effects of CLI and configuration, prioritization during incidents

Examples of how to read scenario questions

Example: "Cloud KMS is available and we want to reduce external dependencies"
  -> Auto Unseal + Integrated Storage (Raft) as the primary choice.
Example: "Cross-region DR with minimum RTO"
  -> Enterprise DR Replication + regular snapshots.
Example: "Ops team wants to minimize sharing of the root key"
  -> Standardize Auto Unseal with Recovery Keys operations and M-of-N management.

Exam Domains and Frequent Tasks

The frequently tested areas are initialization/seal management, HA topology, storage selection, audit and observability, backup/recovery, and upgrade operations. Expect questions on CLI effects and return codes, key properties of config files, and the correctness of SOPs.

Questions on Enterprise features focus on whether you understand the concepts and operational responsibilities (for example, the difference in purpose between DR and Performance Replication, failover procedures, and authority boundaries).

• Initialization and key management: Shamir split, key-shares and key-threshold, rekey/rotate
• Auto Unseal: design and risks of automated unsealing with cloud KMS or HSM
• Storage: Integrated Storage (Raft) vs. Consul, and migration procedures
• HA/load balancing: active/standby, leader forwarding, health checks
• Auditing: enabling audit devices, format, and rotation strategy
• Backup/recovery: raft snapshots, consistency, and minimizing downtime

Drills for frequently used CLI

vault operator init -key-shares=5 -key-threshold=3
vault operator unseal <unseal_key_1>
vault operator rekey -init -key-shares=5 -key-threshold=3
vault operator rotate
vault audit enable file file_path=/var/log/vault_audit.log
vault status
curl -sSf http://127.0.0.1:8200/v1/sys/health

HA Architecture and Storage Selection

The primary production choice is generally Integrated Storage (Raft). It reduces external dependencies and lets Vault itself handle consistency and leader election. If you already have a robust Consul foundation, the Consul backend is also an option, but design it with the overall SLA that includes the dependency's SLA.

Auto Unseal uses cloud KMS or HSM to automate unsealing and reduces human operation. Shamir recovery keys remain important and should be stored safely as the last resort during disasters.

• Raft secures availability through majority voting, so odd-numbered clusters are the norm (for example, 3 or 5 nodes).
• For load balancing, design health checks that account for active detection and 429 (standby).
• Even with Auto Unseal, storing recovery keys and running periodic drills is mandatory.

A representative HA topology using Raft + Auto Unseal

Minimal server.hcl example (requires production-grade hardening)

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 0
  tls_cert_file = "/etc/vault.d/tls/cert.pem"
  tls_key_file  = "/etc/vault.d/tls/key.pem"
}

seal "awskms" {
  region     = "ap-northeast-1"
  kms_key_id = "arn:aws:kms:...:key/..."
}

api_addr     = "https://vault-1.example.com:8200"
cluster_addr = "https://vault-1.example.com:8201"
ui = true

SOPs for Initialization, Seal Operations, and Backup

When initializing, design Shamir's key-shares/key-threshold to match the organization's separation of duties. With Auto Unseal, operational unsealing is automated, but recovery keys are still essential for disaster recovery.

Use Raft snapshots for backups to capture consistent point-in-time state. The safest recovery path follows version compatibility and the cluster's state (restore on a single node, then rejoin).

• Seal and store the root token immediately after init, and conduct day-to-day operations through process-driven means (such as OIDC).
• Store snapshots on confidential channels and rehearse recovery procedures regularly.
• Take a snapshot before upgrading and define rollback criteria.

Representative operational commands

# Initialization and unseal (recovery keys are still distributed/stored even with Auto Unseal)
vault operator init -key-shares=5 -key-threshold=3 > init.out
vault operator unseal <unseal_key_1>

# Take and restore a Raft snapshot
vault operator raft snapshot save /backup/vault.snap
vault operator raft snapshot restore /backup/vault.snap

# Step down the leader (do this proactively before maintenance)
vault operator step-down

# Re-split / rotate keys
vault operator rekey -init -key-shares=5 -key-threshold=3
vault operator rotate

Key Points of Security Operations and Enterprise Features

Audit logs only appear once auditing is enabled. Design with format, storage, rotation, and access control in mind. Define policies in HCL following the principle of least privilege, and require a review/apply process for changes.

Enterprise DR Replication is for disaster recovery, while Performance Replication is primarily for scaling reads. Understand correctly the authority and procedures for failover/promotion, and the boundaries of the replication topology (write responsibility). Namespaces are used to isolate tenant boundaries.

• Always enable at least one audit device and understand the behavior when writes fail (the Fail Open/Close choice).
• DR and Performance Replication have different purposes; do not substitute one design for the other.
• Bake policies and auth methods (OIDC, AppRole, etc.) into the operational automation pipeline.

Basic operations for auditing, policies, and auth methods

# Enable audit logging (example)
vault audit enable file file_path=/var/log/vault_audit.log mode=0640

# Apply a policy (least-privilege example)
cat <<'POL' > team-read.hcl
path "kv/data/team/*" {
  capabilities = ["read", "list"]
}
POL
vault policy write team-read team-read.hcl

# Enable an auth method (example: OIDC) and a template for its configuration
vault auth enable oidc
vault write auth/oidc/config oidc_discovery_url="https://accounts.example.com" default_role="team"

Monitoring, SLA Design, and Troubleshooting

Interpret the health check API's response codes correctly and reflect them in LB routing and SLA metrics. Metrics are the primary source of truth for the health of storage and replication. When troubleshooting, start by isolating leader status and storage consistency.

Build operational SOPs around two pillars: planned maintenance (step-down, rolling restart) and emergencies (seal, node isolation, recovery).

• Main sys/health codes: 200 = active, 429 = standby, 501 = uninitialized, 503 = sealed.
• Raft health: confirm raft peer membership, resolve lagging nodes, and verify snapshot consistency.
• LB health checks should prefer active nodes; allow 429 for standby and understand its forwarding behavior.

Practical commands for monitoring and isolation

# Health check and status
curl -s -o /dev/null -w "%{http_code}\n" http://vault.service:8200/v1/sys/health
vault status

# Check Raft peers
vault operator raft list-peers

# Check logs and audit (adjust the destination to your environment)
journalctl -u vault --since "-5m"
tail -n +1 /var/log/vault_audit.log

# Step down the leader proactively before maintenance
timeout 10s vault operator step-down || true

Check Your Understanding

Frequently Asked Questions