A large configuration's plans intermittently fail with HTTP 429 throttling errors from the cloud provider's API. The team wants plans to finish reliably now, without ignoring drift, while they consider longer-term changes. What should they adjust first?
Select an answer to reveal the explanation.
Short Explanation
When a provider says 'slow down', you send fewer requests at once. Lowering -parallelism does exactly that. The trap is -refresh=false: fewer calls, sure, but you go blind to drift, which the stem rules out.
Full Explanation
During plan and apply, Terraform walks the dependency graph and runs up to a fixed number of operations concurrently, controlled by the -parallelism option, which defaults to 10. Each refresh or change is one or more provider API calls, so a large configuration at default concurrency can exceed a provider's request rate and receive throttling responses. Lowering the value reduces the number of simultaneous calls and usually lets plans complete at the cost of some speed. Splitting the configuration into smaller root modules is the longer-term remedy, because each plan then touches fewer resources. Raising parallelism increases simultaneous requests and makes throttling worse, not better. Disabling refresh does cut API calls, but the documentation warns that it makes Terraform ignore external changes, so it fails the requirement not to ignore drift. Disabling state locking removes the protection against concurrent writes and has nothing to do with the cloud API rate limit, since locking talks to the state backend rather than the provider API being throttled. Exam caveat: many providers also implement their own retry and backoff, which can be tuned in provider configuration, but those settings are provider-specific. Operational check: run the plan with a reduced -parallelism value, confirm the throttling errors stop, and record the setting in the pipeline so every run uses it.