Cert prep · Terraform Authoring and Operations Pro · AWS DevOps Engineer Pro (DOP-C02) · CKA
State, 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 questions. Objectives: Terraform Pro 1 and 3; DOP-C02 tasks 3.1, 3.2 and 3.3; CKA storage. Companion lab: Terraform lab 11, import and remote state.
Lab download.Starter is the tree you edit. Worked answer is a separate file; open it after the starter passes. Terraform exactly 1.10.5 and one download of hashicorp/aws 6.71.0. Mock provider: no credentials and no cloud spend. All lab requirements.
Q1 · Terraform Pro objective 1, resource lifecycle and state
A teammate created the S3 bucket edge-releases-prod by hand in the console, and it now has to be managed by Terraform. No resource block exists for it yet, and you want Terraform to write the first draft of the configuration. Which approach does this?
Answer: B. An import block with no matching resource block lets terraform plan -generate-config-out write draft configuration to a new file, which you review before applying. The terraform import command does not generate configuration and needs the resource block to exist first, -refresh-only does not import unmanaged objects, and -generate-config-out fails if the target file already exists. Source: Generating configuration (import blocks, -generate-config-out), https://developer.hashicorp.com/terraform/language/import/generating-configuration
Q2 · Terraform Pro objective 1, resource lifecycle and state
During a refactor the team renames aws_s3_bucket.releases to aws_s3_bucket.artifacts in code only. The next plan shows the old bucket being destroyed and a new one created. You want the plan to show the existing bucket moving to the new address instead. What do you add?
Answer: D. A moved block with from and to tells Terraform the object at the old address now belongs at the new one, so the plan shows a move instead of a replacement. create_before_destroy only changes the order of a replacement and still replaces the bucket, -refresh-only does not change resource addresses, and -replace forces recreation rather than preserving the object. Source: Refactor modules (moved blocks), https://developer.hashicorp.com/terraform/language/modules/develop/refactoring
Q3 · Terraform Pro objective 1, resource lifecycle and state
The platform team wants Terraform to stop managing the S3 bucket aws_s3_bucket.legacy, but the bucket must keep running. The change has to go through code review and be applied by CI, so running state commands by hand is not an option. Using Terraform 1.7 or later, what is the correct change?
Answer: A. A removed block with lifecycle { destroy = false } removes the resource from state without destroying the real object, and it can be reviewed and applied like any other change. Deleting the block alone makes the plan destroy the bucket, prevent_destroy makes the plan error instead of forgetting the object, and count = 0 plans to destroy the instance. Source: Remove a resource from state, https://developer.hashicorp.com/terraform/language/state/remove; resource block reference, lifecycle prevent_destroy, https://developer.hashicorp.com/terraform/language/resources/syntax
Q4 · Terraform Pro objective 3, collaborative workflows and remote state
Terraform state for the edge service sits in one S3 bucket and has to move to a new bucket with tighter access controls. You have edited the bucket argument in the backend block. Which command copies the existing state to the new location?
Answer: C.terraform init -migrate-state reconfigures the backend and migrates the existing state to the new location. -reconfigure uses the new configuration and does not migrate state, so the new bucket starts empty; -upgrade only updates provider and module versions; apply does not copy state between backends. Source: Command: init (backend initialization, -migrate-state and -reconfigure), https://developer.hashicorp.com/terraform/cli/commands/init
Q5 · Terraform Pro objective 3, collaborative workflows and remote state
An application configuration reads the networking configuration's state with a terraform_remote_state data source. The reference data.terraform_remote_state.network.outputs.subnet_ids fails because subnet_ids is only defined as an output inside module.vpc of the networking configuration. What is true about this data source?
Answer: B.terraform_remote_state retrieves only the root module output values from the other configuration's latest state snapshot, so nested values must be re-exported as root outputs. It does not expose arbitrary resource attributes, it reads the state snapshot rather than a plan file, and it does not evaluate the other configuration against providers. Source: The terraform_remote_state data source (Root Outputs Only), https://developer.hashicorp.com/terraform/language/state/remote-state-data
Q6 · DOP-C02 task 3.1, highly available solutions
The primary edge endpoint is a public web server addressed by IP. When its health check fails, DNS should answer with a static maintenance site hosted separately, or a second-Region endpoint, and return to the primary once it is healthy again. The records live in Route 53. Which configuration meets this active-passive requirement?
Answer: A. With failover routing, Route 53 answers with the primary record while its health check passes and with the secondary record when it fails. Latency records have no primary or secondary role, a simple routing record has no secondary role, and a CNAME record cannot be created at the zone apex. Source: Active-active and active-passive failover, https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-types.html
Q7 · DOP-C02 task 3.1, highly available solutions
The team wants release artifacts in a bucket in us-east-1 replicated to a bucket in eu-west-1 with an S3 replication rule, and S3 will assume an IAM role to copy objects. Which condition must be true before the replication rule can be created?
Answer: D. S3 replication requires versioning to be enabled on both the source bucket and the destination bucket. Transfer Acceleration is not a replication prerequisite, replication is supported across accounts, and the destination buckets cannot be configured as Requester Pays buckets. Source: Requirements and considerations for replication, https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-requirements.html; Setting up live replication overview, https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-how-setup.html
Q8 · DOP-C02 task 3.3, recovery processes
A disaster recovery plan keeps the database continuously replicated to a second Region, with networking and other core infrastructure already provisioned there. The application servers in that Region are not running and are started or scaled up only during failover. Which DR strategy does this describe?
Answer: C. In pilot light, data is replicated and core infrastructure exists in the recovery Region, but the application servers are not running until failover. Backup and restore does not keep continuously replicated data or provisioned infrastructure ready, warm standby keeps a scaled-down copy running, and active/active serves traffic from both Regions. Source: Disaster recovery options in the cloud (pilot light, warm standby), https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html
Q9 · CKA, storage
In a cluster that spans three zones, a Pod stays Pending. Its PVC bound at once and dynamically provisioned a volume in zone-a, but the scheduler picked a node in zone-b for the Pod. Which StorageClass setting prevents this by provisioning the volume only after a Pod that uses the claim is created?
Answer: A.WaitForFirstConsumer delays binding and dynamic provisioning until a Pod using the PVC is created, so the volume is provisioned where the scheduler places the Pod. Immediate is the default and provisions as soon as the PVC is created, which causes the problem; reclaimPolicy and allowVolumeExpansion do not control where a volume is placed. Source: Storage Classes, Volume binding mode, https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode
Q10 · CKA, storage
A dynamically provisioned PersistentVolume backs the PVC for the release index, and its StorageClass uses the default reclaim policy. The team must delete the PVC during a migration, but the data on the volume has to survive. What should you do before deleting the PVC?
Answer: B. Dynamically provisioned volumes inherit the StorageClass reclaim policy, which defaults to Delete; setting Retain on the PV keeps the volume and its data after the PVC is deleted. Access modes and volume mode describe how a volume is used and do not change what happens to it when the claim is deleted, and a ReadWriteMany claim does not retain data. Source: Persistent Volumes, Reclaiming, https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming; Change the Reclaim Policy of a PersistentVolume, https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/
Q11 · CKA, storage
A PVC named index-data requests 10Gi from a StorageClass that sets allowVolumeExpansion: true. The service needs more room, and the data must stay in place. What is the supported way to get a larger volume?
Answer: C. With allowVolumeExpansion: true, you request more space by editing the PVC spec.resources.requests.storage to a larger value, and shrinking is not supported. Expansion is requested on the PVC and not by editing the PV capacity, a newly created PVC provisions a new volume instead of growing the old one, and Pod container limits do not resize volumes. Source: Persistent Volumes, Expanding Persistent Volumes Claims, https://kubernetes.io/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims
Q12 · DOP-C02 task 3.2, scalable solutions
An EC2 Auto Scaling group runs the edge service behind an Application Load Balancer, and traffic is unpredictable. The team wants capacity to follow request load without creating or tuning CloudWatch alarms themselves. Which scaling approach fits?
Answer: D. A target tracking policy with the predefined ALBRequestCountPerTarget metric keeps load near the target value, and Amazon EC2 Auto Scaling creates and manages the CloudWatch alarms for it. Scheduled scaling is time-based and not metric-driven, and step scaling and simple scaling both require you to create the alarm yourself, with simple scaling also applying a cooldown. Source: Target tracking scaling policies for Amazon EC2 Auto Scaling, https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html