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.

Practice

1. What is the main purpose of a connection block in Terraform when using SSH?

easy

A. To specify the Terraform backend storage

B. To define how Terraform connects to remote machines for running commands or copying files

C. To configure the cloud provider credentials

D. To create a new SSH key pair automatically

Solution

1. Step 1: Understand the role of connection blocks

   Connection blocks specify how Terraform connects to remote machines, typically using SSH, to run commands or transfer files during provisioning.

2. Step 2: Differentiate from other configurations

   SSH key creation, cloud credentials, and backend storage are configured elsewhere, not in connection blocks.

3. Final Answer:

   To define how Terraform connects to remote machines for running commands or copying files -> Option B

4. Quick Check:

   Connection block purpose = Define SSH connection [OK]

Hint: Connection blocks set SSH details for remote commands [OK]

Common Mistakes:

• Confusing connection block with SSH key creation
• Mixing connection block with cloud provider config
• Thinking connection block manages backend storage

2. Which of the following is the correct syntax to specify an SSH connection block in Terraform?

easy

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

B. connection { protocol = "ssh" username = "ubuntu" address = self.public_ip key = file("~/.ssh/id_rsa") }

C. connection { ssh_user = "ubuntu" ssh_host = self.public_ip ssh_key = file("~/.ssh/id_rsa") }

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

Solution

1. Step 1: Recall Terraform connection block syntax

   The correct keys are user, host, and private_key. The type key is not required for SSH as it is the default.

2. Step 2: Identify the valid syntax

   connection { user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") } uses correct keys without unnecessary or incorrect ones like type or protocol.

3. Final Answer:

   connection { user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") } -> Option D

4. Quick Check:

   Correct keys = user, host, private_key [OK]

Hint: Use user, host, private_key keys in connection block [OK]

Common Mistakes:

• Adding unnecessary 'type' or 'protocol' keys
• Using wrong key names like ssh_user or username
• Omitting required keys like user or host

3. Given this Terraform snippet, what will happen when Terraform tries to connect?

connection {
  user = "admin"
  host = aws_instance.example.public_ip
  private_key = file("~/.ssh/id_rsa")
  timeout = "2m"
}

medium

A. Terraform will connect but ignore the timeout setting

B. Terraform will fail because timeout must be a number, not a string

C. Terraform will connect using SSH as user 'admin' with a 2-minute timeout

D. Terraform will connect using default user instead of 'admin'

Solution

1. Step 1: Analyze connection block fields

   The block correctly sets user, host, private_key, and timeout. Timeout accepts a duration string like "2m".

2. Step 2: Understand Terraform SSH connection behavior

   Terraform uses these values to connect via SSH as user 'admin' with a 2-minute timeout for connection attempts.

3. Final Answer:

   Terraform will connect using SSH as user 'admin' with a 2-minute timeout -> Option C

4. Quick Check:

   Timeout string '2m' is valid duration [OK]

Hint: Timeout accepts duration strings like '2m' for SSH connections [OK]

Common Mistakes:

• Thinking timeout must be numeric only
• Assuming default user is used ignoring 'user' key
• Believing timeout is ignored by Terraform

4. Identify the error in this Terraform connection block:

connection {
  user = "ec2-user"
  host = aws_instance.web.public_ip
  private_key = "~/.ssh/id_rsa"
}

medium

A. private_key should use file() function to read the key content

B. host should be a static IP, not a resource attribute

C. user must be 'ubuntu' for AWS instances

D. Missing 'type = "ssh"' in connection block

Solution

1. Step 1: Check private_key value type

   The private_key must contain the actual key content, not just the file path string. Using file("~/.ssh/id_rsa") reads the key content.

2. Step 2: Validate other fields

   Host can be a resource attribute, user can be 'ec2-user' for Amazon Linux, and 'type' defaults to SSH so it's optional.

3. Final Answer:

   private_key should use file() function to read the key content -> Option A

4. Quick Check:

   private_key needs file() to read key [OK]

Hint: Use file() to load private_key content, not just path string [OK]

Common Mistakes:

• Assigning private_key a file path string directly
• Assuming host cannot be a resource attribute
• Forcing user to 'ubuntu' regardless of OS

5. You want to run a remote command on an AWS instance using Terraform. Which connection block setup is best practice to ensure a reliable SSH connection?

hard

A. connection {
user = "ec2-user"
host = aws_instance.app.public_ip
private_key = file("~/.ssh/id_rsa")
timeout = "5m"
agent = true
}

B. connection {
user = "ec2-user"
host = aws_instance.app.public_ip
private_key = file("~/.ssh/id_rsa")
timeout = "1m"
agent = false
}

C. connection {
user = "ec2-user"
host = aws_instance.app.private_ip
private_key = file("~/.ssh/id_rsa")
timeout = "5m"
agent = true
}

D. connection {
user = "ubuntu"
host = aws_instance.app.public_ip
private_key = file("~/.ssh/id_rsa")
timeout = "30s"
agent = false
}

Solution

1. Step 1: Choose correct user and host

   For AWS Amazon Linux, user is usually 'ec2-user'. Public IP is needed for SSH from outside the VPC.

2. Step 2: Set appropriate timeout and agent

   A longer timeout like "5m" helps with slow connections. Using SSH agent forwarding (agent = true) can improve key management.

3. Step 3: Compare options

   connection { user = "ec2-user" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "5m" agent = true } uses correct user, public IP, sufficient timeout, and enables agent forwarding, matching best practices.

4. Final Answer:

   connection { user = "ec2-user" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "5m" agent = true } -> Option A

5. Quick Check:

   Public IP, correct user, timeout 5m, agent true = best practice [OK]

Hint: Use public IP, correct user, 5m timeout, and agent true for reliability [OK]

Common Mistakes:

• Using private IP when public IP is needed
• Setting too short timeout causing failures
• Disabling agent forwarding unnecessarily
• Using wrong user for the OS