CI/CD and Automation Workflows
TERRAFORM-PRO-002 · 43 questions
- A team is designing a pipeline for a Terraform repository. Reviewers must approve exactly the changes that will be applied, and syntax or formatting problems should fail early. Which stage order meets these requirements?
- Pipeline jobs that run terraform plan sometimes hang until they time out. The logs show Terraform waiting for a value for a variable that has no default and that the job did not supply. How should the team make these jobs fail immediately instead of waiting?
- A team wants merge requests to be blocked automatically when any .tf file anywhere in the repository, including module subdirectories, is not in canonical HCL format. The check must not modify files in the job. Which command should the pipeline run?
- A pipeline saves a plan with terraform plan -out=tfplan. Reviewers want a human-readable rendering of exactly that plan posted to the pull request, and a policy tool needs a machine-readable version of the same plan. Which approach provides both?
- An HCP Terraform workspace is connected to a VCS repository. Each pull request gets a plan linked from the pull request, but reviewers with apply permission find no way to apply those plans. What explains this behaviour?
- A workspace in HCP Terraform uses the CLI-driven workflow, and the configuration contains a cloud block naming it. A developer runs terraform plan on their laptop and wonders where the plan actually executes and which variable values it uses. Which description is correct for this workspace's default remote execution mode?
- A company's in-house release orchestrator must start HCP Terraform runs. It communicates only over HTTP APIs, cannot run the Terraform CLI, and the configuration is assembled at release time rather than stored in a supported VCS repository. Which workflow fits?
- Every job in a busy CI system downloads the same providers again during terraform init, which slows runs and hits rate limits. The repository already commits .terraform.lock.hcl. Which change addresses this in a supported way?
- HCP Terraform must manage resources in a private data center network that has no inbound access from the internet, and security forbids opening inbound firewall rules. Runs must stay governed by the workspace's permissions, policies and run history. Which approach meets these requirements?
- A pipeline runs terraform test for a shared module, and the CI dashboard displays test results only from JUnit XML report files. The team still wants the normal human-readable test output in the job log. Which command meets both needs?
- A lint job must run terraform validate on every pull request. The configuration uses a remote backend, but the lint runner has no credentials for that backend and should never touch state. Which command sequence works?
- A web service runs on instances behind a load balancer. A new machine image must be rolled out, and changing the image forces replacement of the instances. The release must not cause an outage, and rollback must be fast if the new version misbehaves. Which deployment strategy fits?
- A shared networking module has released a new major version with breaking changes. Dev, staging and prod each call the module from their own root configuration with an exact version pin. The team wants the new version to reach production gradually and to be easy to roll back. Which approach fits?
- Fifty application instances are declared with count, and each image change makes Terraform replace them, which takes the service down. Cloud quotas do not allow doubling capacity, and the team wants replacement in health-checked batches. Which change best meets these goals?
- Dev and prod are separate HCP Terraform workspaces connected to the same repository. The team wants dev to apply automatically after a merge, while prod changes must wait for a person with apply permission to approve the plan. Which configuration achieves this?
- In HCP Terraform, an app workspace reads values produced by a network workspace. Whenever the network workspace successfully applies a change, the app workspace should automatically queue a new run so it picks up the new values. Which feature provides this?
- A team is choosing how to lay out dev, staging and prod in one Terraform repository. One proposal uses a long-lived Git branch per environment with the same file layout on each, and the other uses a directory per environment on a single main branch, each calling shared modules. Which assessment is accurate?
- A configuration change that broke a production service was applied an hour ago through the normal pipeline. The team wants to restore the previous infrastructure settings safely and keep state consistent with reality. Which rollback approach is appropriate?
- A new feature adds a queue and its access policy to a shared configuration that serves dev, staging and prod. The team wants these resources created only in dev until the feature is approved, without maintaining separate copies of the code. Which approach fits?
- A platform team must deploy the same set of networking, cluster and application components to many regions. They want one shared definition, each region planned and approved separately, and changes rolled out region by region, managed as a unit in HCP Terraform. Which approach fits these goals?
- An organization's separation-of-duties rule says developers who write Terraform code must not apply it to production, but they must still be able to queue plans in the prod HCP Terraform workspace and read the results. A separate operations team performs production applies. Which team access configuration meets the rule?
- A platform team uses remote-exec provisioners on awsinstance resources to install packages and push configuration after boot. Over months, servers built from the same configuration have drifted apart because package mirrors and scripts changed between runs, and failed provisioners leave instances tainted mid-setup. Which deployment strategy best addresses the root cause?
- A security review of an HCP Terraform organization finds AWSACCESSKEYID and AWSSECRETACCESSKEY stored as sensitive environment variables in dozens of workspaces. The CISO wants no long-lived AWS credentials stored in HCP Terraform at all, with every run receiving short-lived credentials instead. What should the platform team implement?
- An IAM role used by HCP Terraform dynamic credentials has a trust policy with StringEquals on app.terraform.io:aud and StringLike on app.terraform.io:sub matching organization:acme:. An auditor notes that any workspace in the acme organization could assume this production role. Only the prod-network workspace in the Networking project, in both plan and apply phases, should be trusted. What change meets this requirement?
- A security team requires that HCP Terraform plans in the payments workspace run with an AWS role that can only read resources, while applies use a separate role that can modify them. The workspace already uses dynamic provider credentials with TFCAWSRUNROLEARN. How should the team configure this?
- The data-platform project in HCP Terraform contains fifty workspaces that all deploy to one AWS account using the same IAM role through dynamic provider credentials. Workspaces added to the project later must pick up the settings automatically, and workspaces in other projects must not receive them. What is the most maintainable approach?
- A single HCP Terraform workspace must create a VPC in an application AWS account and a Route 53 record in a separate shared-services account in the same apply, using two aws provider blocks, one of them aliased. Both accounts already trust HCP Terraform's OIDC provider, and static keys are not allowed. How should the workspace supply credentials to both providers?
- An Azure team using HCP Terraform currently stores ARMCLIENTSECRET as a sensitive workspace variable. They want the same no-stored-secrets model the AWS teams use with dynamic provider credentials, covering both the plan and apply phases. What setup achieves this?
- A GCP team using HCP Terraform stores a service account JSON key in a sensitive GOOGLECREDENTIALS variable. Security wants keyless authentication for every run, and only tokens from the company's own HCP Terraform organization may be accepted. Which configuration meets both requirements?
- A security team already runs Vault with the AWS secrets engine and wants every HCP Terraform run to receive AWS credentials generated by that engine, so Vault remains the single place where cloud credential issuance is audited and leases are revoked. No Vault token or AWS key may be stored in HCP Terraform. Which feature fits?
- A workspace using AWS dynamic provider credentials was moved from the Default Project to a new Platform project in HCP Terraform. Its next run fails because the AWS role could not be assumed with web identity. No IAM policies or workspace variables changed. What is the most likely cause?
- A team runs terraform plan and apply directly in GitHub Actions with an S3 backend, not through HCP Terraform. Long-lived AWS access keys are stored as repository secrets, and security wants them removed. What is the recommended replacement?
- Two teams share an HCP Terraform organization, and each team owns its own project. Team A's dynamic credential variables currently live in a global variable set, so Team B's workspaces can also assume Team A's AWS role. How should the platform team isolate the credentials?
- A root module directory contains terraform.tfvars setting instancetype = "t3.small" and prod.auto.tfvars setting instancetype = "m6i.large". A pipeline runs terraform plan with no -var or -var-file options and no TFVAR environment variables. Which value does the plan use?
- During an incident, an engineer runs terraform apply -var="replicacount=6" in a root module directory where scaling.auto.tfvars sets replicacount = 3 and terraform.tfvars sets replicacount = 2. Which value is applied?
- An HCP Terraform workspace using the VCS-driven workflow has a workspace Terraform variable region = "us-east-2". A developer commits region.auto.tfvars with region = "eu-west-1" to the tracked branch. No variable sets define region. Which value does the next run use?
- A project-scoped variable set defines the Terraform variable allowedregions, and one workspace in that project also defines allowedregions as a workspace variable with a different value. The governance team wants the variable set's value to win in every workspace in the project. What should they do?
- A CI job runs terraform plan in a root module directory that contains dev.tfvars, staging.tfvars and prod.tfvars, but the plan uses each variable's default instead of the staging values. The three environment files must stay side by side in that directory. What is the correct fix for the staging job?
- An internal service generates the variable values for each deployment as a JSON object whose top-level keys are variable names. The team wants Terraform to load the file automatically on every plan in the root module, with no command-line options added. How should the generated file be named?
- terraform.tfvars sets tags = { owner = "platform", costcenter = "1234", env = "dev" }. A later-loaded prod.auto.tfvars sets tags = { env = "prod" }, intending to change only the env key. After apply, the resources have lost their owner and costcenter tags. Why?
- A CI job exports TFVARtags='{"team":"payments","tier":"gold"}' before running terraform plan in a root module whose tags variable is declared as map(string). The plan instead shows the tags defined in the directory's terraform.tfvars file. Why did the environment value not apply?
- After a module refactor removed the variable legacysubnet, a shared common.auto.tfvars file still assigns legacysubnet. Meanwhile, one engineer's script still runs terraform plan -var="legacysubnet=10.0.9.0/24". How does Terraform treat these two assignments?
- An HCP Terraform workspace variable allowedcidrs holds ["10.0.0.0/16", "10.1.0.0/16"]. The configuration declares the variable as list(string), but runs fail because the value arrives as a single string. How should the workspace variable be fixed?