Infrastructure as Code Tool Proficiency (Terraform/CloudFormation/Ansible) Questions

Deep proficiency in at least one IaC tool. For Terraform: understand resources, data sources, variables, outputs, local values, modules, state management, state locking, backend configuration (S3, Terraform Cloud), and best practices (remote state, sensitive variables, module organization). For CloudFormation: understand templates (YAML/JSON), stacks, parameters, conditions, mappings, resources, outputs, and intrinsic functions. For Ansible: understand playbooks, roles, inventory, variables, handlers, and idempotency. Write reusable, maintainable code: modules for Terraform, roles for Ansible. Understand code organization, naming conventions, and team collaboration practices.

HardTechnical

28 practiced

A new major version of the AWS Terraform provider introduces schema changes that could cause resource recreation during apply. Describe how you would plan, test, and roll out a provider upgrade across dev, staging, and production environments. Cover pinning provider versions, creating a canary environment, state backups, running terraform plan to detect changes, rollbacks, and communication with dependent teams.

Sample Answer

**Approach overview**I’d treat a provider-major upgrade as a controlled change: pin versions, run canaries, validate plans against state, and prepare automated rollback. Communication and runbooks are key.

**1) Pin provider versions**- In repo modules and roots pin current and target versions in terraform blocks. Example:

hcl

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.65"    # current pinned
    }
  }
}

- Create a branch that updates to the new version before merging.

**2) Back up state**- Before any apply: snapshot remote state (S3) and lock (DynamoDB).

bash

aws s3 cp s3://infra-terraform-state/prod.tfstate prod.tfstate.backup.$(date +%s)

- Export state and store in versioned, access-controlled bucket.

**3) Canary environment**- Create a small environment that mirrors prod critical resources (VPC, a few instances, DNS records). Use the upgrade branch to run there first.- Automate with CI pipeline job that runs `terraform init -upgrade` + `terraform plan`.

**4) Detect changes with plan**- Always run:

bash

terraform init -upgrade
terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json

- Parse plan.json to detect resource "replace" actions and notify owners. Reject changes that recreate critical resources.

**5) Testing and validation**- Apply in canary, run smoke tests and integration tests (health checks, failover, app sanity).- Monitor logs, metrics, and rollback triggers for X minutes/hours.

**6) Rollback strategy**- If undesired changes detected in plan, revert provider version and re-run plan.- If canary apply fails: restore state snapshot (copy backup over S3 key) and run `terraform apply` on the last known-good configuration.- Automate rollback steps in pipeline with a manual approval gate for prod.

**7) Progressive rollout**- After canary success: upgrade dev → staging → prod progressively, using feature flags and maintenance windows for high-risk components. Require approvals and runbooks at each stage.

**8) Communication**- Notify dependent teams before runs with expected windows, list of potentially impacted resources, and rollback plan.- Share plan outputs highlighting resource recreations, timelines, and contact points.- Post-mortem if anything unexpected.

Why this works: pinning prevents accidental upgrades; canary reduces blast radius; state backups and automated rollback restore reliability; explicit plans and communication align dependent teams.

MediumTechnical

26 practiced

Write a reusable Terraform module in HCL that provisions an AWS S3 bucket with optional versioning and server-side encryption, plus a lifecycle rule to remove noncurrent versions after 30 days. The module should accept variables: name_prefix (string), tags (map), enable_versioning (bool). It should output bucket_arn and bucket_id. Provide the core snippets for main.tf, variables.tf, and outputs.tf and explain your design choices for reusability and safety.

Sample Answer

**Answer (DevOps Engineer perspective)**

**Design summary**- Reusable module: parameterized name_prefix and tags, idempotent behavior, minimal defaults.- Safety: server-side encryption enabled by default (SSE-S3) and block public ACLs; versioning is optional via enable_versioning. Lifecycle rule to remove noncurrent versions after 30 days is only applied when versioning is enabled.

main.tf

hcl

resource "aws_s3_bucket" "this" {
  bucket_prefix = var.name_prefix
  tags          = var.tags

  acl = "private"

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }

  lifecycle_rule {
    id      = "expire-noncurrent-versions"
    enabled = var.enable_versioning

    noncurrent_version_expiration {
      days = 30
    }
  }

  versioning {
    enabled = var.enable_versioning
  }

  force_destroy = false
}

resource "aws_s3_bucket_public_access_block" "this" {
  bucket = aws_s3_bucket.this.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

variables.tf

hcl

variable "name_prefix" {
  type        = string
  description = "Bucket name prefix (module will create a unique name)."
}

variable "tags" {
  type        = map(string)
  description = "Tags to apply to the bucket."
  default     = {}
}

variable "enable_versioning" {
  type        = bool
  description = "Whether to enable S3 versioning and lifecycle for noncurrent versions."
  default     = false
}

outputs.tf

hcl

output "bucket_arn" {
  value       = aws_s3_bucket.this.arn
  description = "ARN of the created S3 bucket."
}

output "bucket_id" {
  value       = aws_s3_bucket.this.id
  description = "Name (ID) of the created S3 bucket."
}

Design choices / rationale- SSE-S3 by default enforces encryption at rest without extra customer-managed keys complexity; you can make it optional by adding an enable_sse variable if your org requires.- Conditional lifecycle_rule via enabled = var.enable_versioning prevents invalid lifecycle config when versioning is off.- force_destroy = false protects against accidental bucket deletion with objects; pipeline owners must explicitly set true when required for CI tear-down.- Public access block improves security posture by default.- Use bucket_prefix for safer unique names in multi-environment usage.

Edge notes- To support KMS keys, add parameter for kms_key_id and change sse_algorithm to "aws:kms".- Add lifecycle prevent_destroy or IAM policies as needed by org policies.

EasyTechnical

28 practiced

Explain idempotency in the context of Ansible playbooks. Provide a clear example of a non-idempotent task (for example using 'shell: echo >> /etc/myconfig') and show how to rewrite that task using Ansible modules or conditional checks to become idempotent. Mention how --check mode relates to idempotency.

Sample Answer

**Definition / Why it matters**Idempotency means running a playbook multiple times produces the same end state without unintended changes. For DevOps this ensures safe, repeatable automation and reliable --check (dry-run) results.

**Non-idempotent example**This appends unconditionally each run:

yaml

- name: Append config line (non-idempotent)
  shell: echo "SETTING=1" >> /etc/myconfig

Problem: every run appends duplicate lines.

**Idempotent rewrites**Preferred: use Ansible modules that ensure state (no duplicates):

yaml

- name: Ensure config line exists (idempotent)
  ansible.builtin.lineinfile:
    path: /etc/myconfig
    line: 'SETTING=1'
    create: yes
    state: present

Alternative with shell but safe:

yaml

- name: Append line only if missing
  ansible.builtin.shell: 'grep -qxF "SETTING=1" /etc/myconfig || echo "SETTING=1" >> /etc/myconfig'
  args:
    executable: /bin/bash
  changed_when: "'SETTING=1' not in lookup('file', '/etc/myconfig')"

**Notes**- Prefer modules (lineinfile, copy, template) and handlers for restarts.- --check relies on modules’ declared state; non-idempotent shell tasks often mislead --check. Using idempotent modules yields accurate dry-run results.

MediumTechnical

27 practiced

In a Terraform codebase where multiple modules create IAM roles and S3 buckets with similar names, explain how you would implement a consistent naming convention using variables and local values to guarantee uniqueness across environments, accounts, and teams. Provide example local value expressions or naming templates and explain how to enforce them in CI or pre-commit hooks.

Sample Answer

**Approach (short)** I would centralize naming in a single module or shared vars + locals file, derive names from environment, account, team, resource type and a short identifier, and enforce with linting/policy checks in CI and pre-commit hooks so names are predictable and unique.

**Example locals / naming templates**

hcl

# modules/common/locals.tf
variable "env"        { type = string }    # e.g., "prod", "stg", "dev"
variable "account"    { type = string }    # e.g., "123456789012"
variable "team"       { type = string }    # e.g., "billing"
variable "component"  { type = string }    # e.g., "etl", "api"
variable "short_id"   { type = string }    # human or ticket id, e.g., "01"

locals {
  name_parts = [
    substr(var.env, 0, 3),        # env short
    substr(var.team, 0, 6),       # team short
    substr(var.component, 0, 6),  # component short
    var.short_id
  ]
  normalized = [for p in local.name_parts : lower(replace(p, "/[^a-z0-9-]/", "-"))]
  resource_name = join("-", compact(local.normalized))
  s3_bucket_name = "${local.resource_name}-${var.account}" # ensure global uniqueness
  iam_role_name   = "${local.resource_name}-role"
}

Usage (module consumer):

hcl

module "etl_bucket" {
  source    = "../modules/common"
  env       = var.env
  account   = var.account_id
  team      = "billing"
  component = "etl"
  short_id  = "v2"
}
resource "aws_s3_bucket" "b" { bucket = module.etl_bucket.s3_bucket_name }
resource "aws_iam_role" "r" { name = module.etl_bucket.iam_role_name ... }

**Why this works**- Deterministic: same inputs → same name- Names include account to avoid global collisions (S3)- Shortening/normalization keeps within provider limits and character rules

**Enforcement in CI / pre-commit**- pre-commit hook: terraform fmt + terraform validate + a small shell/python check to assert naming pattern (regex) in generated plan: - run `terraform plan -out=plan.tfplan && terraform show -json plan.tfplan | jq` to extract resource names and assert regex.- Policy as code: use Conftest (OPA) or Sentinel to assert: - S3 buckets match regex ^[a-z0-9-]+-[0-9]{12}$ - IAM roles include team and env segments - No hard-coded names (must reference module/local)- TFLint with custom rules for naming conventions- CI gate: fail build on naming policy violations; include clear error messages with expected template

**Edge cases & best practices**- Reserve a stable short_id pattern (ticket, timestamp) for cross-deploy uniqueness- Document canonical var values in repo README- Add tests that generate plan for each env/account to catch collisions before apply

This pattern ensures consistent, unique, and enforceable names across environments, accounts and teams.

MediumTechnical

26 practiced

How do you prevent sensitive data such as API keys or database passwords from being leaked into Terraform state or plan output? Discuss using the 'sensitive' attribute on variables/outputs, state encryption at rest, avoiding interpolation of secrets in outputs, and integrating with external secrets managers like HashiCorp Vault or AWS SSM Parameter Store without placing secrets in cleartext in state.

Sample Answer

**Direct approach (summary)**As a DevOps engineer I protect secrets by: marking values sensitive in Terraform, encrypting and locking remote state, never interpolating secrets into outputs, and fetching secrets at runtime from external secret managers (Vault/SSM) without persisting cleartext in state.

**Techniques & rationale**- sensitive attribute - Mark variable and output blocks with sensitive = true so CLI plan/show redacts values and Terraform treats them as sensitive. - Example: outputs that would reveal secrets must be removed or flagged sensitive; but note: sensitive = true only masks CLI/display — it does not prevent storage in state.

- State encryption & access controls - Use remote backends with server-side encryption (e.g., S3 with SSE-KMS + DynamoDB locking, Terraform Cloud) and strict IAM policies. Enable workspace locking and MFA for state access. - Encrypt state at rest and restrict who/what can read the backend.

- Avoid interpolation into outputs or resources - Never put secret values into outputs or resource attributes that become visible (e.g., user_data, tags) because those values end up in state even if the output is sensitive. - If you must pass secrets to provisioners, do it outside Terraform (e.g., CI secrets injection or remote execution).

- Integrate with external secrets managers without leaking - Prefer pulling secrets at runtime via agents or platform-native mechanisms: - HashiCorp Vault: use Vault Agent/sidecar or templates to inject secrets into instances at boot; avoid terraform data sources that fetch secret_string into Terraform state. If using the Vault provider, mark retrieved values sensitive and avoid outputs — but better: use Vault for provisioning-time injection. - AWS SSM/Secrets Manager: fetch secrets in CI/CD or instance bootstrap using IAM role, not via data sources that store secret contents in state. - Alternative: use external data sources or null_resource with local-exec that reads secret from the environment (CI) and performs actions without storing them in Terraform state.

**Best practices checklist**- Mark variables/outputs sensitive = true.- Remove secrets from outputs and planable fields.- Use encrypted remote state, locking, tight IAM.- Inject secrets at runtime (Vault Agent / instance metadata / CI env vars) rather than through Terraform resources that persist them.- Audit access to state and rotate secrets regularly.

This combination minimizes leaks: sensitive masks CLI exposure, encryption+ACLs protect stored state, and runtime injection prevents secrets from ever being saved in the Terraform state.

Unlock Full Question Bank

Get access to hundreds of Infrastructure as Code Tool Proficiency (Terraform/CloudFormation/Ansible) interview questions and detailed answers.

Join thousands of developers preparing for their dream job.