Connection blocks for SSH in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the correct SSH connection block for Terraform

Which connection block will successfully configure SSH access to a Linux VM with user 'admin' and private key at '~/.ssh/id_rsa'?

A

connection {
  type        = "ssh"
  user        = "admin"
  private_key = file("~/.ssh/id_rsa.pub")
  host        = self.public_ip
}

B

}
pi_cilbup.fles =        tsoh  
)"asr_di/hss./~"(elif = yek_etavirp  
"nimda" =        resu  
"hss" =        epyt  
{ noitcennoc

C

connection {
  type        = "ssh"
  user        = "admin"
  private_key = "~/.ssh/id_rsa"
  host        = self.public_ip
}

D

connection {
  type        = "ssh"
  user        = "admin"
  private_key = file("~/.ssh/id_rsa")
  host        = self.public_ip
}

💡 Hint

The private_key must be loaded as file content, not as a path string or public key.

Option D correctly uses 'user' (not 'username'), loads the private key file content with file(), and uses the public IP as host. Option D uses 'username' which is invalid. Option D assigns the path string directly instead of file content. Option D uses the public key file instead of the private key.

❓ service_behavior

intermediate

Effect of missing SSH connection block in Terraform provisioner

What happens if you run a Terraform provisioner that requires SSH but omit the connection block entirely?

A Terraform will fail with an error indicating no connection details were provided.

B Terraform will skip the provisioner and continue applying other resources.

C Terraform will use default SSH credentials from the local machine automatically.

D Terraform will connect using HTTP instead of SSH.

💡 Hint

Terraform needs explicit connection info to connect via SSH.

Terraform requires explicit connection blocks for SSH provisioners. Without it, Terraform cannot connect and will error out. It does not guess credentials or skip provisioners silently.

❓ Architecture

advanced

Choosing the best SSH connection method for a private subnet VM

You have a VM in a private subnet without a public IP. Which connection block setup allows Terraform to SSH into this VM securely?

A Use 'type = "winrm"' instead of SSH in the connection block.

B Set 'host' to the private IP and omit any proxy settings.

C Use a bastion host with 'proxy_command' in the connection block to tunnel SSH through it.

D Assign a public IP to the VM and connect directly.

💡 Hint

Private subnet VMs need a jump host or proxy to access via SSH.

Option C correctly uses a bastion host with SSH proxy to reach private subnet VMs. Option C fails because private IPs are not reachable from Terraform's machine. Option C uses a different protocol (WinRM) not applicable here. Option C changes architecture and may not be allowed.

❓ security

advanced

Security best practice for SSH private keys in Terraform connection blocks

Which practice improves security when specifying SSH private keys in Terraform connection blocks?

A Hardcode the private key path directly in the connection block for simplicity.

B Use environment variables or Terraform variables to inject private key content instead of hardcoding paths.

C Use the public key file in the private_key field to avoid exposing private keys.

D Store private keys in the Terraform state file for easy access.

💡 Hint

Avoid hardcoding sensitive data directly in code.

Option B follows best practice by injecting private keys securely via variables or environment variables. Option B risks exposing keys in code. Option B is invalid because public keys cannot be used for SSH authentication. Option B exposes sensitive data in state files, which is insecure.

🧠 Conceptual

expert

Understanding SSH connection block behavior with dynamic host IP changes

If a Terraform-managed VM's public IP changes after initial deployment, what happens to the SSH connection block referencing 'self.public_ip' during subsequent apply runs?

A Terraform uses the updated public IP automatically because 'self.public_ip' reflects current state.

B Terraform continues using the old IP cached from the first apply, causing connection failures.

C Terraform prompts the user to manually update the IP in the connection block.

D Terraform disables SSH provisioners until the IP is manually refreshed.

💡 Hint

Terraform references resource attributes dynamically during each apply.

The 'self.public_ip' attribute always reflects the current resource state, so Terraform uses the updated IP automatically. It does not cache old IPs or require manual updates for connection blocks.