A module's unit tests must run in a CI job that has no cloud credentials at all, yet the module's resources have computed attributes, such as IDs and ARNs, that other resources and outputs reference. What should the test files use?
Select an answer to reveal the explanation.
Short Explanation
A mock provider is a stunt double for the real cloud. It plays the part, makes up believable IDs and ARNs, and never asks for credentials, so your CI job can test without touching an account.
Full Explanation
The Terraform test framework can replace a real provider with a mock_provider block. A mocked provider exposes the same schema as the real one, but instead of calling the remote API it sets values from configuration and generates fake data for computed attributes such as IDs and ARNs, so resources, data sources and outputs that reference those attributes evaluate normally. Because no API calls are made, no credentials are needed, which fits a CI job with no cloud access, and tests run quickly with no cost. Specific values can be supplied where generated data is not enough, through mock_resource or mock_data defaults or with override blocks. A provider configured with empty credentials still attempts to authenticate and call real APIs, so it fails or behaves unpredictably. Plan-mode runs still initialize the configured provider and contact it for refresh, data sources and planning logic, so command = plan alone does not remove the need for credentials. A variables block sets input variables only; it cannot assign values to computed resource attributes, which come from the provider. Exam caveat: mocks prove module logic, not real-world behavior, so keep a smaller integration suite that applies against a real account. Operational check: run terraform test in the credential-free CI job and confirm every run passes without any provider authentication errors.