TF Associate 003 — Providers and HCP Terraform, Objectives 3 and 9

The two exam objectives that name the outer boundary — the door into the cloud, the door out of one laptop.

Objective 3 is the door into the cloud. Objective 9 is the door out of one operator's laptop. Learn both because both other lessons in today's trio press against them.

§ IFrame

The Terraform Associate 003 exam is fifty-seven objectives across nine domains, and today's cert lesson lands on the two that name the outer boundary of every Terraform installation. Objective 3, Terraform Basics, tests what a provider is and how the registry and the plugin protocol supply them. Objective 9, HCP Terraform Capabilities, tests what HashiCorp's managed backend adds when a team outgrows local state and single-user runs.

Both objectives sit at the edge of the daily craft. Objective 3 is the door into the cloud; Objective 9 is the door out of one operator's laptop. The other seven objectives ask what happens inside those doors, and the seven have been drilled already: state (Objective 4 and 5), the core workflow (Objective 6), modules and configuration (Objective 5 and 8). Today closes the perimeter with the two the earlier lessons deliberately left for later, precisely because both other lessons in today's trio press against them.

§ IIDomain Foundations — Objective 3, Understand Terraform Basics

Objective 3 is the smallest objective by attribute count and the largest by cross-cutting reach. Its subpoints ask you to explain how Terraform finds a provider, install one, describe the plugin architecture, and use a provider's data sources. Brikman opens the multi-provider chapter that grounds this section with the exact frame the exam repeats: Terraform Core knows the language and the workflow; providers know the clouds. Neither works alone.

Providers are separate binaries. Core and every provider ship independently, communicate over a gRPC plugin protocol, and version at their own pace. When Terraform needs to talk to AWS, Core does not have AWS knowledge compiled in. Core downloads the hashicorp/aws provider binary and calls its PlanResourceChange and ApplyResourceChange RPCs. This architecture is why new services arrive without a new Core release and why the exam expects you to know the split.

The registry is where providers come from. The default source is registry.terraform.io. A provider's fully-qualified source address has three parts: hostname, namespace, name. hashicorp/aws is shorthand for registry.terraform.io/hashicorp/aws. When you declare source = "hashicorp/aws", Terraform inflates it to the full address at init time. Third-party registries and private registries use the full form explicitly, example.com/team/aws, and this is where the exam tests you: can you read a required_providers block and know which registry Terraform will query, and can you explain how a private registry's URL is discovered through a .well-known/terraform.json file at the hostname.

Data sources read; resources write. Every provider exposes both. A resource declares desired state that Terraform will create, update, or delete. A data source declares a read from the provider that Terraform will perform every plan and hand back as attributes. data "aws_ami" "ubuntu" reads the latest Ubuntu AMI at plan time and hands its ID to any resource that references data.aws_ami.ubuntu.id. The exam asks you to distinguish the two, know that data sources do not appear in state as owned resources, and understand that a data source is refreshed every plan, which is why placing a slow data-source call in a hot module tax every apply.

§ IIIObjective 3 Flavor — Version Constraints, the Lockfile, and Aliases

The three sub-topics under Objective 3 that carry the most exam weight, and the ones today's Ops and Dev lessons both stand on, are constraints, lockfiles, and aliases.

Version constraints are declarative, not imperative. The required_providers block accepts operators: = 5.60.0 pins exactly; ~> 5.60 matches any 5.60.x; ~> 5.60.0 matches 5.60.x only; >= 5.60, < 6.0 matches any 5.x from 5.60 forward. Multiple operators separated by commas mean AND. The pessimistic operator ~> matches the rightmost released segment: ~> 3.0 matches 3.x but not 4.0, while ~> 3.1.0 matches 3.1.x but not 3.2. Know the pessimistic-operator rules exactly because at least one exam question turns on which upgrade path a constraint permits.

The dependency lockfile is .terraform.lock.hcl. It records the exact resolved version and the SHA256 checksum of every provider binary Terraform installs, per platform. It is created and updated on terraform init. It is checked into version control so every teammate and every CI runner installs the identical binary. Once the lockfile exists, terraform init refuses to install a different version even if the constraint would allow it; you must pass -upgrade to re-solve and update the lock. The exam asks the discipline question: what happens when a new team member clones a repo with a lockfile and runs terraform init? Answer: they install the exact versions the lockfile names, not the highest matching the constraint.

Provider aliases enable multiple configurations of the same provider. Declare an aliased instance with alias = "west" in a provider "aws" block. Reference it explicitly with provider = aws.west on a resource. Child modules cannot inherit aliased providers implicitly; the parent passes them via a providers = { aws.west = aws.west } argument on the module block, and the child declares them in its required_providers.aws.configuration_aliases list. The exam presents multi-region scenarios and asks which resource lands where; you answer by reading the resource's provider = argument, or the absence of one, which binds it to the module's default.

§ IVDomain Foundations — Objective 9, Understand HCP Terraform Capabilities

Objective 9 covers HCP Terraform (the managed platform HashiCorp formerly called Terraform Cloud) and its self-hosted twin, Terraform Enterprise. The exam does not test operating either; it tests knowing what each provides beyond CLI-with-local-state.

Workspaces are the unit of state. In HCP Terraform, one workspace holds one state file, one set of variables, and one lineage of runs. A workspace corresponds to what a local project holds in a single terraform.tfstate. The value is that state lives on the server, encrypted at rest, versioned automatically, and readable through an API without ever being copied to a laptop. Brikman's team-Terraform chapter, which grounds this section, opens with exactly the migration story: five people sharing one terraform.tfstate in an S3 bucket, versus five people whose workspace lives in HCP Terraform and whose state is accessed only through runs.

Runs are the unit of change. A run consists of a plan and an optional apply, executed on HCP-hosted or self-hosted workers rather than a developer's laptop. Runs are triggered by a git push (VCS-driven workflow), a CLI-driven upload, or an API call. Runs serialize per workspace, so two developers cannot apply against the same state simultaneously; the second run queues behind the first. The exam asks you to name the two run modes (VCS-driven and CLI-driven), know that runs are recorded in an audit log, and understand that variable sets provide shared variables across multiple workspaces.

Sentinel and OPA policies are the guardrail. HCP Terraform Team & Governance and higher tiers offer Sentinel (HashiCorp's policy-as-code language) or OPA (Rego). Policies run between plan and apply and can block the apply or issue warnings. A common policy: refuse any plan that creates an S3 bucket without encryption enabled. Know that policy enforcement modes are advisory (warn only), soft-mandatory (require override), and hard-mandatory (block absolutely).

Private module and provider registries. HCP Terraform hosts private registries so teams can publish internal modules and internal providers behind their organization boundary. The registry surface is the same URL shape as public Terraform Registry, exposed under the org's HCP Terraform hostname, and modules and providers are referenced from HCL exactly the same way as public ones. The exam asks whether private modules require authentication (yes, via HCP Terraform's token), and whether they support versioning (yes, via git tags of the module repo).

§ VCross-Objective — Where 3 and 9 Meet

The two objectives meet at the workspace variable. A provider block in HCL says region = var.region. Where does var.region come from in an HCP Terraform workspace? From the workspace's variables page (or the API call today's Dev lesson wrote), where region is defined as a Terraform variable of category terraform. If instead the provider reads a credential from an environment variable like AWS_ACCESS_KEY_ID, the workspace variable is category env. The category axis is where Objective 3's provider configuration and Objective 9's workspace variables interlock.

The other meeting point is version pinning. The lockfile from Objective 3 is written by terraform init locally, checked into VCS, and read by HCP Terraform on every remote run. The workspace does not re-solve versions; it installs the versions the lockfile names. This is the same discipline as local development, extended to a shared server, which is why the exam expects you to reason about the lockfile's contents in both contexts.

§ VIConnection to Today's Ops and Dev Lessons

This lesson's Objectives 3 and 9 are the exam-tier picture of what today's Ops lesson wrote in HCL and today's Dev lesson wrote in Python. The Ops lesson's provider block, version constraint, lockfile discipline, and alias pattern are Objective 3 laid down as day-one code. The Dev lesson's workspace enumeration, variable upsert, and state-version read are Objective 9 called from a Python client. Read the three together and you have one narrative crossing three altitudes: the concept, the code, and the exam-tier framing.

§ VIIPractice Questions

§ VIIIQuestion Resolutions

Answer 1. Terraform installs 4.60.5 only. ~> 4.60.0 is the pessimistic operator with three segments given, which means match any 4.60.x version. 4.61.0 violates the 4.60 anchor. 4.60.10-beta is a pre-release and pre-release versions are excluded unless the constraint explicitly permits them. 5.0.0 violates both.

Answer 2. Terraform installs exactly 5.62.0, the version the lockfile records. The lockfile takes precedence over the constraint once it exists. The version 5.68.3 that the registry offers is ignored because terraform init without -upgrade respects the lock. To install 5.68.3, the developer runs terraform init -upgrade, which re-solves the constraint against the registry, installs the highest matching version (5.68.3), updates the lockfile to record it, and produces a diff to commit.

Answer 3. The resource binds to the default provider in us-east-1. Any resource without an explicit provider = argument binds to the un-aliased instance of its provider type. The aliased west instance is invisible unless a resource names it explicitly.

Answer 4. The data-source query is executed against AWS during every terraform plan (which is also what runs at the start of every terraform apply). Terraform must re-read data sources on each plan to detect whether the read value has changed and whether downstream resources need to be updated as a result. This is why slow data-source calls tax every apply, not just the first one.

Answer 5. The variable must be category terraform. HCL variables declared as variable "region" and read as var.region are Terraform variables, mapped to workspace variables of category terraform. Category env is for environment variables like AWS_ACCESS_KEY_ID that the provider reads through its own credential-loading logic outside HCL. A mismatched category writes to the wrong scope silently: setting region as env puts it into the process environment but leaves var.region unset.

Answer 6. Advisory: the policy failure prints a warning but the apply proceeds. Soft-mandatory: the failure blocks the apply, but an authorized user can override with a written justification and proceed anyway. Hard-mandatory: the failure blocks the apply absolutely; no override is available. Choose the mode by asking whether the policy is a suggestion, a checkable rule with an escape hatch, or an invariant.