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
consulprovider for objects, theconsul-k8sCLI plus Helm chart for Kubernetes (server.replicas,connectInject.enabled,ui.enabledvalues), 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 withconsul config write file.hclor manage them through Terraform'sconsul_config_entryresource. - ACL and KV bootstrap:
consul_acl_policy,consul_acl_role,consul_acl_token, andconsul_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.