State, import and drift, remote state, resilience and storage
Practice self-check. Answers stay in this page so you can grade yourself. This is not a scored exam.
Twelve scenario items on Terraform state and drift, remote state and locking, AWS resilience and scaling, and Kubernetes storage. Companion lab: ledger state and drift in Terraform.
Q1 · Terraform Advanced, resource lifecycle (TFA-1), drift and refresh-only
During an incident a teammate changed a tag on the Terraform-managed bucket aws_s3_bucket.ledger in the console. The team wants Terraform state to record the real tag value without changing any infrastructure, and wants to review the proposed state change before it is saved. Which command fits?
Answer: B. Refresh-only mode proposes only updates to state and root outputs to match real infrastructure, and you approve them before they are written. A plain terraform apply would change the bucket to put the tag back to the configured value, -replace destroys and recreates the bucket, and terraform state rm removes the resource from state instead of recording its real values. Source: Terraform CLI: plan command, refresh-only mode (https://developer.hashicorp.com/terraform/cli/commands/plan); apply command (https://developer.hashicorp.com/terraform/cli/commands/apply)
Q2 · Terraform Advanced, resource lifecycle (TFA-1), state show
An engineer wants to read every attribute Terraform has recorded in state for the single resource aws_s3_bucket.ledger. The configuration has not changed and no plan is needed. Which command should they run?
Answer: D.terraform state show prints all attributes recorded in state for one resource address. terraform state list prints only resource addresses, terraform output reads root module output values rather than resource attributes, and terraform graph emits a dependency graph, not recorded attribute values. Source: Terraform CLI: state show command (https://developer.hashicorp.com/terraform/cli/commands/state/show)
A pipeline produces a plan for a change, a reviewer inspects it, and then the pipeline must apply exactly the plan that was reviewed. Between review and apply, the real infrastructure or configuration could change. Which approach guarantees the reviewed plan is the one applied?
Answer: A. Applying a saved plan file executes that exact plan and does not generate a new one. Running terraform apply on a directory, with or without -auto-approve, creates a fresh plan, terraform validate only checks configuration syntax and consistency, and a plain apply after plan -target ignores the targeted plan. Source: Terraform CLI: plan command, -out option (https://developer.hashicorp.com/terraform/cli/commands/plan)
Q4 · Terraform Advanced, collaborative workflows (TFA-3), state lock timeout
Two CI jobs run against the same remote state. Whenever the first job is running, the second fails immediately with a state-lock error. The team wants the second job to wait up to five minutes for the lock before giving up, while keeping locking enabled.
Answer: C.-lock-timeout makes Terraform retry acquiring the state lock for the given duration instead of failing at once. -lock=false disables locking rather than waiting, -parallelism limits concurrent operations inside one run and does not coordinate two runs, and -refresh=false skips the refresh step but the run still needs the state lock. Source: Terraform CLI: plan command, -lock-timeout option (https://developer.hashicorp.com/terraform/cli/commands/plan)
A team on Terraform 1.11 stores state in an S3 backend and wants state locking, but does not want to create or manage a DynamoDB table. The bucket is already versioned and encrypted. Which backend setting provides locking without DynamoDB?
Answer: A. The S3 backend's use_lockfile argument enables native S3 locking with a lock object stored next to the state file. encrypt only controls server-side encryption of the state, workspace_key_prefix only changes where workspace states are stored, and Transfer Acceleration speeds up transfers without locking anything. Source: Backend Type: s3, State Locking (https://developer.hashicorp.com/terraform/language/backend/s3)
A CI runner was killed in the middle of terraform apply and left the remote state locked. No other run is active, and the lock error message shows a lock ID. The team needs to release the lock safely.
Answer: D.terraform force-unlock manually removes a lock on the state, identified by the lock ID, when a run failed to release it. Reconfiguring the backend does not release an existing lock, terraform state rm edits state contents and needs the lock itself, and deleting the state object destroys Terraform's record of the infrastructure. Source: Terraform CLI: force-unlock command (https://developer.hashicorp.com/terraform/cli/commands/force-unlock)
The S3 backend bucket and key differ for each environment and should not be hard-coded. A teammate writes bucket = var.state_bucket inside the backend "s3" block and terraform init rejects it. How should the values be supplied?
Answer: B. Backend blocks cannot reference variables, so the values are left out (partial configuration) and given at init time with -backend-config. A backend block cannot use input variables, however they are set (tfvars, TF_VAR_ environment variables or -var), and backend settings are needed during terraform init, before plan runs. Source: Backend block configuration overview, Partial configuration (https://developer.hashicorp.com/terraform/language/backend)
A production Amazon RDS database must survive the disruption of one Availability Zone with automatic failover. The application must keep using the same database endpoint, with no configuration change and no manual promotion step.
Answer: C. A Multi-AZ DB instance deployment keeps a synchronous standby in a different Availability Zone and fails over automatically behind the same endpoint. A read replica uses asynchronous replication, is not an automatic failover standby, and here sits in the same zone, a cross-Region snapshot restore is a slow manual recovery with a new endpoint, and a larger instance class adds capacity but no zone redundancy. Source: Multi-AZ DB instance deployments for Amazon RDS (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html)
An Auto Scaling group must run a bootstrap script on every new instance. A new instance must not be put into service and receive traffic until the script has finished. Which feature is designed for this?
Answer: A. A launch lifecycle hook pauses the new instance in a wait state until the custom action completes and the instance is then moved to InService. The default cooldown only delays further scaling activities, scheduled scaling changes capacity on a schedule without gating individual instances, and Instance Refresh replaces existing instances rather than holding new ones until a script finishes. Source: Amazon EC2 Auto Scaling lifecycle hooks (https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
A team wants a disaster recovery strategy in which a scaled-down but fully functional copy of the workload is always running in a second Region. At failover it can take traffic immediately at reduced capacity, and the team then scales it out to full production size.
Answer: D. Warm standby keeps a scaled-down, fully functional copy running that can handle traffic at reduced capacity immediately and is scaled out at failover. Backup and restore rebuilds the workload from backups, pilot light keeps the application servers switched off so it cannot serve traffic until started, and multi-site active/active already runs at full capacity serving production traffic. Source: Disaster recovery options in the cloud (warm standby) (https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
Q11 · CKA Storage, ReadWriteOncePod
A CSI-backed PersistentVolumeClaim holds the single writable copy of a ledger index. Only one Pod in the whole cluster may mount it read-write at any time, even if other Pods are scheduled onto the same node. Which access mode should the claim request?
Answer: B.ReadWriteOncePod restricts the volume to being mounted read-write by a single Pod across the whole cluster. ReadWriteOnce limits mounting to one node, so several Pods on that node can still use it, ReadOnlyMany does not allow writes, and ReadWriteMany allows many nodes and Pods to write. Source: Persistent Volumes, Access Modes (https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes)
Q12 · CKA Storage, default StorageClass
Developers create PersistentVolumeClaims without a storageClassName. The cluster admin wants every such claim to be provisioned from the existing StorageClass named fast, without editing each claim.