A large `terraform apply` keeps failing partway through with rate-limit errors from the cloud provider's API. What does Terraform's `-parallelism` option control, and how would you use it here?

## What the graph walk is doing After Terraform builds the dependency graph, apply is a concurrent walk over it: any node whose dependencies are already satisfied is eligible to run. Without a limit, a wide configuration — two hundred DNS records, fifty IAM policies, a big fan-out of subnets — would fire an enormous number of provider API calls at once. `-parallelism=n` caps how many of those operations are in flight simultaneously. The default is 10. ```bash terraform apply -parallelism=3 ``` ## What it does and does not affect It affects **concurrency only**. The graph is unchanged, the ordering constraints are unchanged, and the resulting infrastructure is identical: a run at `-parallelism=1` produces the same outcome as one at 10, just serialized and slower. It is also a *per-run* setting, not a global budget — it says nothing about other pipelines, other engineers, or other tools hitting the same API. Two runs at `-parallelism=5` are ten concurrent operations from the provider's point of view. It is likewise unrelated to state locking. Terraform prevents two applies from racing on the same state by holding a lock, which is a separate mechanism entirely; parallelism governs what happens *inside* one run. ## Why lowering it helps a throttled apply Cloud APIs enforce request rates, often per account, per region and per service. A wide apply is exactly the shape that trips those limits: many identical calls arriving in the same instant. Halving or quartering the concurrency spreads the same work over more seconds and typically drops the run under the threshold. It is the quickest lever because it needs no code change, no state surgery and no coordination — just re-running with a smaller number. The cost is time. If the graph is genuinely wide and the provider is fast, wall-clock time rises roughly in proportion. On a deep, chained graph the cost is far smaller, because dependencies were serializing most of the work anyway. ## Why raising it rarely helps The common misuse is bumping parallelism to speed up a slow apply. It usually does nothing, for two reasons. First, most slow applies are slow because of *dependency depth* or because individual resources take minutes to become ready — a database, a certificate, a load balancer — and more concurrency cannot shorten a chain or make a provisioning wait finish sooner. Second, pushing more calls at an API that is already near its limit converts a slow apply into a failing one. ## The complementary knobs - **Provider retries.** Providers implement their own backoff. The AWS provider, for instance, takes a `max_retries` argument in its provider block; raising it makes individual throttled calls retry rather than abort the whole run. Retries and parallelism solve different halves of the same problem — one absorbs the errors, the other stops causing them. - **`TF_CLI_ARGS_apply`.** If a repository must always run reduced, `TF_CLI_ARGS_apply="-parallelism=3"` in the pipeline environment applies the flag without editing every command line. - **Splitting the configuration.** The structural fix is fewer resources per root module. A state that manages so many objects that it saturates a provider API is also a state with a slow plan, a large blast radius and a long lock hold. ## What to say in an interview Name the default (10), say plainly that it is per-run concurrency over the graph walk and not a correctness knob, reach for lowering it as the incident-time lever, mention provider retries as the complement, and then say the structural thing: a configuration that reliably rate-limits the provider has outgrown its root module. The senior signal is not knowing the flag — it is knowing that the flag buys time and does not fix the shape of the estate.