HFCP cheat sheet

Shared responsibility model: the provider secures the cloud (physical hosts, hypervisor, network fabric); the customer secures what runs in the cloud (identity, data, configuration, patching of guest workloads).

IaaS exposes compute, storage, and network primitives; PaaS adds managed runtimes and middleware; SaaS delivers the finished application. Terraform is most often used to provision IaaS and PaaS resources.

Elasticity vs. scalability: elasticity automatically matches capacity to load in both directions; scalability is the ability to grow capacity at all, manually or automatically.

Immutable infrastructure means replacing instances rather than mutating them in place; this makes deployments reproducible and rollbacks a matter of redeploying a prior artifact.

Declarative provisioning states the desired end state and lets a tool compute the diff; imperative provisioning lists the steps. Terraform is declarative, while shell scripts are imperative.

Provider APIs are the control plane; resource CRUD calls go to regional endpoints. A region contains multiple availability zones, and multi-AZ designs tolerate single-zone failure.

Managed services shift operational burden (backups, failover, patching) to the provider but still require customer-side configuration of access control, encryption, and network exposure.

Cost drivers: running instances are billed while stopped instances may still incur storage; egress traffic and managed-service tiers are common sources of unexpected spend.

Terraform workflow: terraform init (download providers, configure backend) → terraform plan (compute diff) → terraform apply (execute diff) → terraform destroy (remove managed resources).

State maps configuration addresses to real resource IDs. Remote backends (e.g., HCP Terraform, S3 with locking) enable team sharing and prevent concurrent applies via state locking.

Resource address format: <resource_type>.<local_name>, e.g., aws_instance.web. References such as aws_instance.web.id create implicit dependency edges in the graph.

meta-arguments: count and for_each create multiple instances; depends_on adds explicit ordering; provider selects a non-default provider configuration; lifecycle controls create_before_destroy, prevent_destroy, ignore_changes.

for_each requires a map or set of strings and yields stable keys, so removing one element does not re-index the rest; count uses integer indices and shifts on removal.

Variables: type, default, description, validation, sensitive, nullable. Precedence (low to high) is defaults, terraform.tfvars, *.auto.tfvars, -var/-var-file flags, and TF_VAR_ environment variables.

Modules package reusable configuration; a child module receives inputs via variables and returns outputs. The registry and local paths are both valid sources, and version constraints apply to registry sources.

terraform state mv and terraform import relocate or adopt existing objects without destroying them; terraform taint (or -replace in plan) forces recreation of a specific object.

Provisioners (local-exec, remote-exec, file) are a last resort because they are not reflected in the plan; prefer cloud-init, user_data, or provider-native mechanisms.

CIDR sizing: /24 = 256 addresses, /25 = 128, /26 = 64, /27 = 32, /28 = 16. Usable host count is 2^(32-prefix) minus reserved addresses, which vary by platform.

Security groups are stateful and allow-only; network ACLs are stateless and support allow and deny. Return traffic for stateful rules is automatic.

Least privilege: scope IAM policies to specific actions and resource ARNs; avoid wildcard actions like * on * resources, and prefer roles over long-lived access keys.

Terraform can automate security controls: define firewall rules, private subnets, VPC endpoints, and logging resources as code so the posture is versioned and reviewable.

Policy as code (Sentinel for HCP Terraform, OPA) evaluates plans before apply and can be advisory or hard-mandatory, blocking non-compliant changes.

Private connectivity options include VPC peering (non-transitive), transit gateways for hub-and-spoke, and private endpoints so traffic to managed services does not traverse the public internet.

DNS automation: records can be managed as Terraform resources, and service discovery can use provider DNS or Consul DNS for dynamic address resolution.

Encryption in transit uses TLS; enforce it with load balancer listeners that redirect HTTP to HTTPS and with policies that reject plaintext endpoints.

Vault core concepts: seal/unseal, storage backend, barrier encryption, auth methods, secrets engines, and policies. Unseal keys reconstruct the master key via Shamir secret sharing.

Auth methods (token, userpass, LDAP, OIDC, AppRole, Kubernetes, AWS IAM) authenticate an identity and issue a token bound to policies. AppRole uses role_id plus secret_id for machine auth.

Policies are HCL documents with path patterns and capabilities: create, read, update, delete, list, sudo, deny. Deny takes precedence; default policy is attached to all tokens.

KV v2 stores versions under /data/; the API path differs for metadata (/metadata/). Reading a version is done with ?version=N.

Dynamic secrets engines (database, AWS, PKI) generate short-lived credentials on demand and revoke them at lease expiry; leases have TTL and max TTL.

Transit secrets engine provides encryption as a service: keys never leave Vault, and clients call encrypt/decrypt with a named key. It supports key rotation and rewrapping.

Token lifecycle: tokens have TTL, can be renewed up to an explicit max TTL, and can be revoked with their children. Batch tokens are lightweight but not renewable or root-capable.

Vault Agent and Agent Injector handle auto-auth and template rendering so applications receive secrets as files without embedding Vault logic in code.

Audit devices log every request and response (with HMAC of sensitive values) to a file or syslog; at least one audit device should be enabled in production.

Service discovery maps a logical service name to healthy instance addresses; Consul provides DNS and HTTP interfaces and health checks that remove failing instances from results.

Consul catalog holds registered nodes and services; the agent runs on each node, performs health checks, and syncs with servers via gossip (LAN/WAN) and RPC.

Consul Connect (service mesh) uses sidecar proxies for mutual TLS between services. Intentions define which source services may connect to which destinations, replacing broad network allow rules.

In mesh mode, upstreams are declared per service (e.g., local_bind_port) so the sidecar exposes a stable localhost address for the dependency.

Service mesh data plane carries traffic through sidecars; the control plane distributes certificates, intentions, and configuration. mTLS identities are SPIFFE-style service identities, not IP-based.

Consul supports multiple datacenters with WAN federation; prepared queries and failover policies let consumers reach a service in a remote datacenter when local instances are unhealthy.

Consul KV stores configuration data with ACL enforcement; it is not a secrets store-use Vault for sensitive values and reference them via templates.

Consul on Kubernetes uses the Helm chart, with connect-inject enabling sidecar injection via an admission controller and sync-catalog registering k8s services into Consul.

HCP is a managed platform offering services such as HCP Terraform, HCP Packer, HCP Consul, and HCP Vault; each is provisioned per organization and region.

HCP Terraform organizes work into organizations, projects, and workspaces. A workspace binds configuration (VCS or CLI-driven) to variables, state, and run history.

Run workflow: plan → policy check → cost estimate → apply, with manual or auto-apply modes. Speculative plans run on pull requests without applying.

Remote runs execute in HCP Terraform agents by default; self-hosted agents run in your network for private resources. The CLI-driven workflow uses terraform login and a cloud block.

Variable sets share variables across multiple workspaces; workspace-specific variables override set values. Sensitive variables are write-only in the UI.

State is stored remotely with versioning; state versions can be downloaded or rolled back. Run triggers chain workspaces so one apply can start another.

HCP Vault clusters are deployed into a provider network (HVN) with a public or private endpoint; peering connects the HVN to your VPC for private access.

HCP service principals and API tokens scope automation access; organization owners manage teams, SSO, and audit logging for the platform.

CI/CD stages: validate (fmt, validate) → plan → policy check → apply. Plans should be reviewed before apply, and applies should be gated to the main branch.

terraform fmt -check and terraform validate catch formatting and syntax errors without contacting the provider API; they are fast and belong in every pipeline.

Terraform Cloud/Enterprise API and CLI (terraform plan/apply with cloud block) enable pipeline integration; run triggers and webhooks connect stages across workspaces.

Sentinel policies enforce organizational rules at plan time; policy sets are applied to workspaces or globally, and results can be advisory, soft-mandatory, or hard-mandatory.

VCS-driven workspaces run plans automatically on commits to the tracked branch and can auto-apply; PR workflows produce speculative plans for review.

Secrets in pipelines should come from a secrets manager (Vault, HCP) at runtime, not from committed files; use short-lived tokens and OIDC federation to avoid static credentials.

Collaboration features: teams and RBAC, comments on runs, run history with diffs, and notifications (Slack, webhooks, email) on run state changes.

Drift detection compares real infrastructure to state on a schedule; detecting drift does not fix it-a new plan/apply reconciles it.