Search
24 results for “terraform”
Search results
Terraform Basics
How Terraform's state model, providers, and plan/apply workflow make infrastructure reviewable like code, plus the state pitfalls that trip up teams.
Terraform Troubleshooting Guide: Fix the Errors Engineers Actually Hit
Diagnose Terraform initialization, validation, provider, authentication, state, drift, import, replacement, timeout, and CI failures with a safe workflow.
Terraform Azure VMSS: Load Balancer, Key Vault, and Monitor
Provision an Azure VM Scale Set with Terraform behind a Standard Load Balancer, then add managed identity, Key Vault RBAC, monitoring, and verification.
Terraform State Management: Remote, Secure, and Recoverable
Design secure remote Terraform state with locking, encryption, least privilege, version recovery, AzureRM and S3 patterns, migration, and restore drills.
Terraform Apply Stuck Acquiring State Lock
A safe Terraform state lock troubleshooting guide for stuck apply runs, stale locks, lock IDs, force-unlock, backend behavior, and CI pipeline guardrails.
Terraform on Azure: Resource Groups, VNets, NSGs, and VMs
Build a secure Azure resource group, VNet, subnet, NSG, public IP, NIC, and Linux VM with production-minded Terraform and validation steps.
Why does GitOps improve auditability compared to engineers running kubectl or terraform apply directly?
Every change to cluster state has to go through a Git commit, which means it inherits Git's existing history, authorship, and (if branch protection is configured) pull-request review, automatically. Direct `kubectl apply` access leaves no equivalent trail: two changes with the same effect are indistinguishable, there's no required review step, and reconstructing "who changed what and why" after an incident means digging through cluster event logs instead of reading a linear, reviewed commit history.
At what point in the Terraform workflow are Sentinel (or similar policy-as-code) checks evaluated, and why does that timing matter?
Policy checks evaluate against the plan, the output of `terraform plan`, before `terraform apply` actually provisions anything, which means a policy violation blocks the run from proceeding to apply at all. Evaluating against the plan rather than the already-applied state is what makes this a preventive control instead of a detective one; the non-compliant resource is stopped before it exists, not flagged for cleanup afterward once it's already live and potentially already been exploited or has already incurred cost.
Why is scanning IaC source (Terraform files) not sufficient on its own, without also checking the plan?
Static scanning can catch hardcoded insecure defaults but cannot see the complete result of runtime inputs, data sources, and module composition. A Terraform plan is the best prediction of the concrete resource changes Terraform is about to make, so plan policy sees substantially more than source scanning. It is not guaranteed to know every value before apply, however; security-sensitive unknown values need an explicit fail-closed or exception rule rather than being assumed safe.
What is Terraform state and why is it required?
State is a JSON file (by default `terraform.tfstate`) that maps every resource block in your configuration to the real-world object Terraform created for it (an AWS instance ID, a DNS record, etc.). Terraform is declarative, your config describes the desired end state, not the steps to get there, so on every run it needs state to compute a diff between what exists now and what the config says should exist. Without state, Terraform would have no way to know whether a resource already exists, needs updating, or was deleted outside of Terraform.
Why is storing Terraform state locally a problem for a team, and what is the standard fix?
Local state is a single file on one person's machine, so another engineer can apply against stale or missing state and create conflicting changes. The standard fix is a remote backend that stores state centrally and supports locking. For the S3 backend, current Terraform supports native lock files with `use_lockfile = true`; DynamoDB-based locking is deprecated. The backend should also encrypt state and keep recoverable versions because state can contain sensitive values.
What is the difference between terraform plan and terraform apply, and why does that separation matter?
`plan` computes and displays the diff between current state and desired config without changing anything; it is a dry run. `apply` executes that diff against real infrastructure. Separating them means a human (or a CI approval gate) can review exactly what will be created, changed, or destroyed before anything actually happens, which is the core safety mechanism that makes infrastructure-as-code safer than manually clicking through a cloud console, nothing changes without a reviewed, explicit plan.
How to Build a Production-Ready Azure Environment with Terraform
Build an Azure foundation with Terraform remote state, controlled outbound access, private endpoints, Key Vault, Storage, monitoring, verification, and cleanup.
How to Build a Zero-Downtime Terraform Pipeline with GitHub Actions
Build a guarded Terraform and GitHub Actions deployment pipeline with OIDC, concurrency, saved plans, approvals, rolling changes, verification, and rollback.
Deploy an Azure Windows VM with Terraform: Step-by-Step Guide
Deploy a private Azure Windows Server VM with Terraform, including its VNet, subnet, NSG, secure RDP access, state, validation, and cleanup.
Production-Ready AKS GitOps with Terraform and ArgoCD
The DevOps Project That Finally Made Kubernetes, GitOps, and Terraform Click
Auto-Scaling Azure VMSS with Modular Terraform
From Basic Terraform to Production IaC: Building an Auto-Scaling Azure Web App with Modular Terraform.
Infrastructure as Code Security
How plan-stage policy blocks unsafe AWS and Azure infrastructure before deployment, with practical policy testing and enforcement guidance.
What problem does policy-as-code solve that a manual infrastructure change review does not?
A manual review depends on a human noticing a specific misconfiguration, an open security group, an unencrypted storage bucket, in a plan diff that may span hundreds of resources, and that scrutiny has to be repeated consistently by every reviewer on every change. Policy-as-code encodes the same rule once as executable logic and runs it automatically against every plan, so an overly permissive security group is caught the same way on the hundredth change as the first, without depending on which reviewer happened to be paying attention that day.
The AWS Bill Spiked and Nobody Had Launched Anything New
Audit NAT Gateway data processing costs with Cost Explorer, CloudWatch, and VPC Flow Logs, then route same-Region S3 traffic through a free Gateway endpoint.
The Tiny Tool That Would Have Stopped a Production Deploy Gone Wrong
Use direnv to load project-specific environment variables on entry, restore prior shell state on exit, and reduce wrong-account Terraform deploys.
In a systemd unit, what is the practical difference between Type=simple and Type=forking, and why does that distinction matter for dependency ordering?
With Type=simple, systemd considers the unit started the moment the main process is forked off, it does not wait for the application to finish its own initialization, so anything depending on that unit might start before the service is actually ready to handle requests. Type=forking expects the traditional daemon pattern, the initial process forks and exits once it judges its own startup complete, so systemd marks the unit started as soon as that original process exits successfully, while the actual daemon keeps running as a separate, now-orphaned process. That only tracks the daemonization handoff, not genuine application readiness, a process can exit believing setup is done while it is still finishing initialization in the background, so Type=forking is a better signal than Type=simple but still not a readiness guarantee. Type=notify is the one that actually is readiness-safe: the service explicitly calls sd_notify to tell systemd exactly when it's ready, rather than systemd inferring readiness from process exit behavior at all.
What does the Kubernetes control loop actually do?
Every Kubernetes controller (Deployment, ReplicaSet, etc.) runs a reconciliation loop: it continuously compares the desired state (what you declared in a manifest, stored in etcd) against the observed actual state of the cluster, and takes action to close any gap. If you declared 3 replicas and only 2 Pods are running, the ReplicaSet controller creates one more. This is the same declarative, converge-toward-desired-state model as Terraform, but running continuously and automatically rather than on-demand.
What is the practical difference between ps -ef and ps aux, and why do they show different columns for the same processes?
`-ef` is UNIX-style syntax and `aux` is BSD-style syntax for the same underlying command, and they weren't designed as one consistent interface; mixing them can even be ambiguous depending on other options used. The manual is explicit that BSD-style options change the default output to include process state (STAT) and full command arguments (COMMAND) instead of just the executable name, and BSD-style selection also defaults to showing every process the invoking user owns across all terminals, while UNIX-style selection defaults to processes on the current terminal only. Neither is "more correct," they're two different historical option conventions layered onto the same command, which is why picking one and being consistent about it matters more than which one.