Deployment · Cloud Infrastructure
Secure Terraform Remote State with GCS, S3 or Azure Blob
Terraform state holds resource identities and potentially sensitive values. Remote backends enable team access; locking prevents concurrent writes and authorization controls…
Technical review:
Architecture and operating model
Terraform state holds resource identities and potentially sensitive values. Remote backends enable team access; locking prevents concurrent writes and authorization controls readers/writers. Locks do not provide confidentiality or backup.
Provision the state bucket/container independently. Configure encryption, versioning and a scoped CI identity. Keep backend addresses in code and credentials in a secure environment. Before init -migrate-state, preserve a protected local copy and ensure no apply is active.
GCS and Azure backends support native locking; current S3 backend supports use_lockfile. Verify Terraform-version and IAM requirements in the backend documentation. Use force-unlock only after proving the lock owner is no longer active.
- 1Backend and identity
- 2State migration
- 3Locked plan/apply
- 4Versioning and audit
Design parameters
- State scope
- Separate environments/authorization domains into states while avoiding excessive dependency fragmentation.
- Identity
- Prefer short-lived workload identity; avoid leaking backend secrets into plan files.
- Recovery
- Enable versioning/audit; reconcile actual resources before reverting to older state.
Worked example
Run two CI jobs against one state. While the first holds a lock, the second should wait or fail predictably. Do not use -lock=false to make CI pass. After migration, inspect the plan for unexpected destruction/recreation.
Example commands: replace lab values and confirm permissions and software versions before use.
terraform {
backend "s3" {
bucket = "lab-terraform-state"
key = "lab/network.tfstate"
region = "eu-central-1"
use_lockfile = true
encrypt = true
}
}
# Choose one backend: GCS uses bucket/prefix; Azure uses account/container/key.
# Run terraform init -migrate-state only after protected backup and lock coordination.Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Lock cannot be acquired | Active job, insufficient permission or stale lock. | Compare lock identity/time with CI status. |
| Recreation after migration | Wrong state key/workspace. | Match state content and actual resource IDs. |
Acceptance checks
- Verify backend version support.
- Keep secrets out of code.
- Back up state securely.
- Test concurrent locking.
- Inspect the post-migration plan.
- Test version recovery in a pilot.
Related concepts
Locks, waits and deadlocks
Concurrent operations use locks or versioning to preserve integrity. Long transactions can block others; a deadlock forms a cycle of mutual waits. The database may terminate one participant, requiring safe application retries. Examine blocked and blocking queries together. Arbitrarily reducing isolation can change consistency guarantees. Test shorter transactions, consistent access order and suitable indexes under the same workload.
Encryption and key lifecycle
Encryption makes data difficult to read without its key; access control, deletion protection and backup address different needs. Identify which layer protects data in transit and data at rest. Key generation, protection, rotation and emergency recovery are part of the design. A key needed to restore a backup must not exist only on the server that could be lost in the incident. Test decryption and key-access recovery using a separate administrator in a lab, and keep real keys out of documentation and support messages.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the actual runtime user, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Durability and power loss
Survival of committed data depends on write guarantees across the database, OS, filesystem, controller and disks. Do not disable safety settings for speed without understanding caches and flush behaviour. Power-loss-protected storage helps but does not prove correctness of the entire chain. Run failure and recovery tests in a controlled lab, not production. Validate application records and supported consistency checks rather than merely opening a sample file.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.