Quiz results are saved to your browser's local storage and will persist between sessions.
The apply model — what Terraform owns versus what it merely reads, what survives a failed apply, and how to decide between import and delete-and-recreate when reality and state disagree.
If a data block references a real cloud resource, and someone deletes that resource outside Terraform entirely, what happens on the next terraform plan?
Unlike resources, data sources are read-only and always re-fetch live on every plan/apply. If the real object is gone, there's nothing to read, so it errors rather than returning a stale value. This is also why data "google_client_config" is used for auth tokens specifically — access tokens expire hourly, and only a data source guarantees a fresh read every run.
During terraform apply, 6 of 7 planned resources succeed and 1 fails with an unrelated error (e.g. a network timeout on an external API call). What state are the 6 successful resources in afterward?
Terraform apply is NOT transactional. Each resource writes to state as it individually succeeds. A re-run after a partial failure only needs to create the remainder — direct, observable proof of this: a 7-resource apply that failed on resource #7 only showed "1 to add" on retry, not 7.
Compared to a resource block, which of the following is true of a data block?
A resource is fully owned by Terraform through its whole lifecycle (create/update/destroy) and tracked in state accordingly. A data block is purely read-only: Terraform never manages the underlying object's lifecycle, it just reads it — and unlike a resource, it re-verifies that read live on every plan/apply rather than trusting a cached state value.
A terraform apply fails partway through creating a cloud resource (e.g. a GKE cluster) due to an unrelated error. The next apply attempt fails with 'Already exists' because the resource is now real in the cloud but absent from Terraform state. What's the right general decision criterion for import vs delete-and-recreate?
import is right for a healthy resource that's simply missing from state. But a resource whose creation failed partway through may be in an inconsistent, half-built state — importing it risks fighting drift indefinitely. The deciding factor: does this resource hold anything you'd lose by deleting it? A minutes-old, broken, empty lab cluster has nothing to preserve, so delete-and-recreate beats reconciling.
terraform apply fails on a resource with a transient network error (e.g. TLS handshake timeout) on a follow-up API read, right after the resource's creation call. What should you check before deciding whether to retry, import, or delete-and-recreate?
A network timeout on a follow-up read is a different failure class from a creation that genuinely failed partway through. Checking the real resource's health directly, and whether it's already tracked in state, tells you whether this is a non-issue (just retry apply) or something that needs the import/recreate decision framework at all.