Cert prep · Terraform Authoring and Operations Pro · AWS DevOps Engineer Pro (DOP-C02) · CKA
State, locking, provider aliases, HCP Terraform, rollbacks and kubeadm upgrades
Practice self-check. Answers stay in this page so you can grade yourself. This is not a scored exam.
Ten questions. Objectives: Terraform Pro 1, 3, 5 and 6; DOP-C02 tasks 1.4 and 2.1; CKA cluster architecture. Companion lab: Terraform lab 10, edge provider aliases.
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
During an incident, an engineer edited an ingress rule on the aws_security_group.edge group in the AWS console. The team wants Terraform's state to record the real remote settings without changing any infrastructure. Which approach does that?
Answer: C. A refresh-only plan shows the drift between state and the real remote object, and approving it updates only the state file, not the infrastructure. -replace destroys and recreates the group, terraform state rm drops the object from state so the next plan proposes creating a new group, and hand-editing state is error-prone and not the supported way to reconcile drift. Source: Terraform CLI: plan command, Planning Modes and Options (refresh-only mode), https://developer.hashicorp.com/terraform/cli/commands/plan
Q2 · Terraform Pro objective 3, collaborative workflows
A team keeps Terraform state in an S3 bucket and runs Terraform 1.11 or later. No DynamoDB table exists, and two engineers sometimes run terraform apply at the same moment. They want the second run to be blocked instead of risking corrupted state. What should they do?
Answer: A. The s3 backend supports native state locking through use_lockfile = true, which writes a lock file next to the state object and needs no DynamoDB table. Versioning and encryption protect and keep history of the state but do not lock it, a DynamoDB table is the older approach and no longer required, and the backend does not lock unless locking is configured. Source: Terraform backend type: s3, State Locking, https://developer.hashicorp.com/terraform/language/backend/s3
Q3 · Terraform Pro objective 3, collaborative workflows
A configuration declares the aws provider with version = "~> 6.71". The committed .terraform.lock.hcl records version 6.74.0. Since then, 6.80.0 and 7.1.0 have been published. A teammate clones the repository and runs terraform init with no extra flags. Which version do they get?
Answer: D. When a lock file exists, terraform init installs the recorded version if it still satisfies the constraint, and init -upgrade is how you select a newer allowed version. The constraint ~> 6.71 allows 6.71 and later 6.x but never 7.0, so 7.1.0 is excluded, and neither the newest nor the lowest allowed version is chosen while a valid lock entry exists. Source: Dependency Lock File (.terraform.lock.hcl), https://developer.hashicorp.com/terraform/language/files/dependency-lock; Provider Requirements, https://developer.hashicorp.com/terraform/language/providers/requirements
Q4 · Terraform Pro objective 5, providers
A root module manages the primary release bucket in us-east-1 through the default aws provider. The replica bucket must live in us-west-2, and its settings are packaged in a child module ./modules/replica that uses a single aws provider. How should the root module wire this up?
Answer: B. An additional provider configuration needs an alias, and a child module receives it only when the module block maps it with the providers argument. Two unaliased configurations for the same provider are not allowed, an input variable does not change which provider configuration a module uses, and modules inherit only default configurations implicitly, not aliased ones. Source: Providers Within Modules, https://developer.hashicorp.com/terraform/language/modules/develop/providers
Q5 · Terraform Pro objective 5, providers
A team runs Terraform for the aws provider both locally and from CI. Policy says the deployer IAM role edge-deployer must be used and that static access keys must not live in the configuration. Which setup meets this?
Answer: A. The AWS provider reads credentials from the environment or shared config and can assume a role through an assume_role block, which keeps static keys out of the configuration. The other options still place long-lived keys in a file or in command-line arguments, where they can leak through version control, shell history, or CI logs, and none of them configures the deployer role. Source: Terraform Registry, AWS Provider documentation, Authentication and Configuration, https://registry.terraform.io/providers/hashicorp/aws/latest/docs#authentication-and-configuration
Q6 · Terraform Pro objective 6, HCP Terraform
A team has an HCP Terraform workspace connected to a GitHub repository, tracking the main branch. An engineer opens a pull request that changes the bucket lifecycle rules. What does HCP Terraform do for that pull request?
Answer: D. For a VCS-connected workspace, a pull request triggers a speculative plan that shows the proposed changes and cannot be confirmed or applied. Pull requests do not trigger applies, they do trigger runs before merge in the form of speculative plans, and speculative plans do not lock the workspace or wait in the run queue for confirmation. Source: UI and VCS-driven Run Workflow, https://developer.hashicorp.com/terraform/cloud-docs/workspaces/run/ui
Q7 · Terraform Pro objective 6, HCP Terraform
An IAM OIDC identity provider for HCP Terraform and an IAM role that trusts it already exist in the AWS account. The team wants every run of a workspace to receive short-lived AWS credentials instead of stored access keys. What should they configure on the workspace?
Answer: C. Dynamic provider credentials for AWS are enabled by the TFC_AWS_PROVIDER_AUTH and TFC_AWS_RUN_ROLE_ARN workspace environment variables, so each run exchanges an OIDC token for temporary credentials. Static keys remain stored credentials even if rotated, AWS_ROLE_ARN alone does not make HCP Terraform exchange a token, and custom Terraform variables are not how HCP Terraform is told to generate dynamic credentials. Source: Dynamic Credentials with the AWS Provider, https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/aws-configuration
Q8 · DOP-C02 task 1.4, deployment strategies
A Lambda function is deployed through an alias with AWS CodeDeploy using CodeDeployDefault.LambdaCanary10Percent5Minutes. The team wants the new version rolled back automatically if the error rate rises while the canary traffic is flowing. What should they configure?
Answer: B. CodeDeploy stops the deployment and rolls back to the last known good version when a CloudWatch alarm attached to the deployment group fires and alarm-based rollback is enabled. A failure-only rollback does not watch metrics without an alarm, an all-at-once configuration shifts every request immediately and has no canary window, and alarms are attached to deployment groups, not to the application. Source: Redeploy and roll back a deployment with CodeDeploy, https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html; Monitoring deployments with CloudWatch alarms in CodeDeploy, https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring-create-alarms.html
Q9 · DOP-C02 task 2.1, reusable IaC
A platform team must deploy one baseline stack, an audit IAM role and a log bucket, to every account in the Workloads OU across three Regions. Accounts created in that OU later must receive the stack without anyone running a command. The team uses AWS Organizations and does not want to create IAM roles in each account by hand. What should they do?
Answer: D. Service-managed StackSets integrate with AWS Organizations, create the needed roles for you, target OUs and Regions, and with automatic deployment enabled they deploy to accounts that join the OU. Self-managed permissions require manual roles and do not provide automatic deployment to new accounts, nested stacks stay within one account and Region, and a scripted loop recreates by hand what StackSets already provide. Source: StackSets concepts, https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html; Create a StackSet with service-managed permissions, https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-associate-stackset-with-org.html
Q10 · CKA, cluster architecture
A kubeadm cluster has three control plane nodes behind a load balancer plus several worker nodes. The administrator must move the cluster to the next minor Kubernetes version. Which sequence matches the documented procedure for the control plane?
Answer: A. The documented flow upgrades kubeadm, uses kubeadm upgrade apply on the first control plane node only, uses kubeadm upgrade node on additional control plane nodes, and then upgrades kubelet and kubectl. Upgrading kubelet first reverses the documented order, additional control plane nodes use upgrade node rather than upgrade apply, and skipping minor versions is not supported even on HA clusters. Source: Upgrading kubeadm clusters, https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/