What does declaring `mock_provider "aws"` in a Terraform test file change about how the tests execute, and what stops being tested?

## The problem mocking solves The native test framework's default behaviour is honest and expensive: `command = apply` runs use the real provider and create real infrastructure. That makes a suite slow, credentialed, and unable to run on a fork's pull request. Provider mocking, added in Terraform 1.7, keeps the whole evaluation path while removing the network. ```hcl mock_provider "aws" { mock_resource "aws_s3_bucket" { defaults = { arn = "arn:aws:s3:::test-bucket" } } mock_data "aws_ami" { defaults = { id = "ami-0123456789abcdef0" } } } ``` Declared at file level (or per run), this substitutes the provider entirely. Terraform builds the same graph, evaluates the same expressions, resolves the same `for_each`, and runs your `assert` conditions — but any attribute the provider would have computed is filled in with a generated value, or with the `defaults` you specified when a test depends on a particular shape. ## Targeted overrides Mocking the entire provider is the blunt instrument. Three finer tools exist: - `override_resource` — replace one resource's computed values while everything else behaves normally; - `override_data_source` — return canned data for a lookup, which is the common case: a data source that would need a real VPC or a real AMI in the account; - `override_module` — stub out an entire child module, useful when the module under test composes something slow or expensive. Each carries a `values` map, and each can be declared at file level or inside a single `run` block, so one file can mix a fast mocked run with a real one. ## What is still genuinely tested More than people expect. Mocking removes the API, not the configuration language, so a mocked suite still catches: - naming and string composition logic; - `count` and `for_each` producing the wrong number of instances, or the wrong keys; - conditional resources that appear or vanish for the wrong input; - outputs wired to the wrong attribute, or not exported at all; - input rejection, via `expect_failures`; - module inputs plumbed to the wrong variable. That set is the bulk of the defects a module actually ships, and catching it in seconds on every pull request is the point. ## What silently stops being tested Everything whose only judge is the provider or the API: - an IAM policy document that is syntactically fine but rejected as malformed; - a value that violates a service constraint the schema does not encode — a name too long, a character class the service forbids, a region where the resource type is unavailable; - permissions, quotas, and service limits; - the real shape of computed values: your mocked ARN is whatever you typed, so code that parses or slices an ARN can pass against a mock and fail in production; - provider-side plan behaviour such as an unexpected forced replacement. There is a second, slower failure mode: mocks rot. A `defaults` map is a hand-written snapshot of what a provider returns. Providers change, attributes are added, and nothing in the test suite notices. A green mocked suite is a statement about your configuration logic, never a statement about the cloud. ## The shape teams settle on A broad mocked suite that runs on every commit — fast, free, credential-free — plus a small unmocked suite exercising one or two representative paths, run on a schedule or before a release, in an isolated account. The mocked tests protect refactoring; the real ones prove the module still works against the provider as it exists today. Deciding where that line sits for a given module is the judgment the question is really probing. ## Answering it well State the mechanism first — the provider is replaced, computed attributes become generated values, apply creates nothing — then be specific about the lost coverage rather than saying "it is less realistic". Naming a concrete escape, such as an IAM policy the API would reject or an ARN whose real format your code parses, is what makes the answer credible.