Consul Ops Pro study materials
Consul Ops Pro study resources

Consul Ops Pro: Automation, Infrastructure as Code, and Enterprise Features

Consul Ops Pro · Work through your exam, one topic at a time.

All guide sections

Automation, Infrastructure as Code, and Enterprise Features

Domain 8 covers repeatable operations: expressing Consul configuration as code, automating cluster lifecycle, and knowing which capabilities require an Enterprise licence. Questions typically ask which resource or config entry implements a requirement, and which features silently vanish in the community binary.

Configuration as code

Three layers are commonly automated:

  • Cluster provisioning: the Terraform consul provider for objects, the consul-k8s CLI plus Helm chart for Kubernetes (server.replicas, connectInject.enabled, ui.enabled values), and cloud-init or configuration management for VM agents.
  • Mesh configuration: config entries are the API surface - service-defaults, proxy-defaults, service-resolver, service-router, service-splitter, service-intentions, mesh, ingress-gateway, terminating-gateway, exported-services. Apply with consul config write file.hcl or manage them through Terraform's consul_config_entry resource.
  • ACL and KV bootstrap: consul_acl_policy, consul_acl_role, consul_acl_token, and consul_keys, with secrets pulled from Vault at apply time rather than committed to state in plaintext.

A healthy pipeline applies config entries through Terraform, registers services through service definition files or the Kubernetes CRDs, and treats hand-edited objects as drift - the next apply reverts them.

Enterprise-only capabilities

Namespaces partition services, KV and ACLs per tenant inside a datacenter; admin partitions go further, giving tenants separate catalogues and namespaces that span datacenters with partition-scoped tokens; redundancy zones add read replicas and a failover strategy; network segments isolate Serf traffic; SSO uses an auth_method with OIDC or SAML plus binding rules; audit logging, the snapshot agent, automated upgrades and read replicas are also licensed. Check licence state with consul license get and set it with consul license put or a licence file in configuration.

Worked example

Two tenants must share one datacenter, each with its own KV tree, services and ACL boundary, plus SSO login. Reasoning: namespaces (Enterprise) plus an OIDC auth_method and a binding rule mapping a tenant claim to a namespace-scoped token. Admin partitions are the answer only if tenants also need separated catalogues spanning datacenters with their own admin boundary - heavier, and every tool must be partition-aware. In the community edition neither exists, so the design must fall back to separate clusters.

Traps

Assuming namespaces exist in the community binary; managing config entries both in Terraform and by hand; storing the bootstrap token in Terraform state without a secret backend; and forgetting exported-services when the mesh spans admin partitions.