A Terraform config with a remote-exec provisioner works from a developer's laptop but times out when the same code runs on a CI runner. What is going wrong, and how would you fix it properly?

## Where the connection is made from The most common misconception here is that Terraform somehow asks the cloud to run the commands. It does not. `remote-exec` and `file` open an SSH or WinRM session **from the process running `terraform apply`** to the address in `connection.host`. Everything follows from that. Terraform Cloud/Enterprise workers, a container in a build cluster, and a laptop on the corporate VPN are three completely different network positions, and the same configuration behaves differently in each. ## The three preconditions, in diagnostic order **1. A route to the host.** If `host = self.public_ip` and the instance has no public IP (private subnet, no `associate_public_ip_address`), the attribute is empty and the connection goes nowhere. If it is `self.private_ip`, the runner needs to be inside the VPC — via VPN, Direct Connect, or peering — which a hosted runner is not. **2. An open path on the port.** Port 22 (or 5985/5986 for WinRM) must be reachable: security group ingress, network ACLs, and any host firewall in the image. Laptop success often means the security group allows the office CIDR, and the runner's egress address is not in it. **3. Credentials valid on the booted image.** `private_key = file("~/.ssh/id_rsa")` reads a file that exists on the developer's machine and does not exist on the runner. `agent = true` relies on an SSH agent the runner has not started. And the `user` must already exist in the image — a freshly booted AMI has one default account, not your developer usernames. ## The timing trap on top of those Even when all three hold, the resource is often "created" from the provider's point of view before the operating system has finished booting and sshd is listening. Terraform retries the connection until `connection.timeout` elapses (default five minutes), so this shows up as an intermittent failure that is worse on cold, larger images — and, per the failure semantics of provisioners, a timeout taints the instance and forces a replacement. ## The patches, and what they cost ```hcl connection { type = "ssh" user = "ubuntu" private_key = var.ssh_private_key host = self.private_ip bastion_host = var.bastion_public_ip bastion_user = "ec2-user" bastion_private_key = var.bastion_key timeout = "10m" } ``` That works. It also means: a jump box exists and is exposed; the pipeline holds a long-lived SSH private key as a secret; and a security group now permits the runner's address range. You have made three security concessions so that one imperative step can run inside the resource graph. An interviewer asking this question wants to hear you notice that. ## The proper fixes **Move the script to `user_data`.** The platform's own metadata service delivers it and cloud-init executes it locally at first boot. No inbound path, no key, no timing race. It also becomes a resource attribute, so a change shows in the plan diff — and on AWS you can set `user_data_replace_on_change = true` to make edits roll the fleet. **Bake it into the image.** Build the image ahead of time and reference it. Boot is faster and every instance is identical by construction. **Invert the direction.** Instead of Terraform pushing to the host, let the host pull: an agent, an instance-profile-authenticated fetch, or a separate config-management run after apply. Outbound connections from the instance need no inbound rules and no shared private key. **Use an agentless remote-command service where the platform offers one.** Where a managed remote-command channel exists, it authenticates with the same cloud credentials the pipeline already has and needs no open SSH port — the general shape being "reach the machine through the control plane, not through the network". ## How to answer Structure it as diagnosis then design. Diagnosis: connection originates on the Terraform host; check route, then port, then credential, then the sshd-readiness race. Design: every patch that makes it work in CI widens the attack surface, so the durable fix is to eliminate the inbound dependency entirely by having the machine configure itself at boot. Closing with "and this is exactly why HashiCorp calls provisioners a last resort" ties it back to the principle rather than leaving it as a networking anecdote.