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.

EasyTechnical

25 practiced

Describe how to declare and use variables in Terraform (variable blocks, tfvars, environment variables). How do you mark variables as sensitive, and what are the consequences for plan output, logging, and state files? Compare storing secrets in Terraform variables vs using external secret stores like Vault or AWS SSM Parameter Store.

Sample Answer

**Declare and use variables**

- In variables.tf:

hcl

variable "db_password" {
  type      = string
  description = "Database admin password"
  sensitive = true
}

- Reference in resources:

hcl

resource "aws_db_instance" "db" {
  password = var.db_password
}

**Provide values**- tfvars file (terraform.tfvars):

hcl

db_password = "my-secret"

- CLI override:

bash

terraform apply -var="db_password=xxx"

- Environment variable:

bash

export TF_VAR_db_password="xxx"

**Marking sensitive & consequences**- `sensitive = true` prevents value from being shown in plan/apply output and CLI logs.- Sensitive values still appear in the Terraform state file (unless using remote state encryption) because state must store resource attributes; Terraform masks outputs but state contains secrets in plaintext by default.- Logging/telemetry from CI must avoid printing TF state or plan with sensitive content.

**Secrets: Terraform variables vs external secret stores**- Terraform variables (tfvars / env) are simple but risky: they can leak in state files, backups, CI logs.- External stores (Vault, AWS SSM Parameter Store, Secrets Manager) are recommended: - Provide access controls, rotation, auditing, and encryption-at-rest. - Terraform can fetch secrets at runtime via data sources or provider integrations, reducing secret exposure in tfvars/state (but note: if you inject secret into resource attributes, it may still end up in state).- Best practice: store secrets in a secret manager, retrieve them dynamically (use data source or template_file with rendering at apply) and minimize storing plaintext secrets in state (use provider features like AWS Secrets Manager integration or resource referencing where possible).

MediumSystem Design

31 practiced

Design a Terraform strategy to manage infrastructure across an AWS Organization of ~50 accounts: include recommended module boundaries (shared VPCs, IAM, platform services), how to structure remote state for each account, cross-account role assumption for automation, and CI/CD considerations (bootstrapping accounts, permissions, and promotion paths).

Sample Answer

**Clarify goal (one line)**Manage 50 AWS accounts in an Organization with safe, repeatable Terraform: clear module boundaries, per-account remote state, secure cross-account automation, and CI/CD promotion paths.

**Module boundaries**- Shared modules (reusable): VPC (shared or per-AZ subnets), networking primitives (TGW, route tables), IAM primitives (roles/policies), logging/monitoring (CloudWatch, GuardDuty), platform services (ECR, SSM parameters).- Account-level composition: each account repo/stack composes shared modules and account-specific resources (workloads).- OU-level overlays: small modules for OU-wide guardrails (SCPs, Config rules) applied by central management account.

**Remote state**- One S3 bucket per account+environment (e.g., tfstate-prod-123456789012) with server-side encryption (KMS CMKs) and DynamoDB table for state locking.- KMS keys created/owned by each account; grant decrypt/describe to central CI role via key policy.- Backend example:

hcl

terraform {
  backend "s3" {
    bucket = "tfstate-prod-123456789012"
    key    = "vpc/main.tfstate"
    region = "us-east-1"
    dynamodb_table = "tf-locks-123456789012"
    encrypt = true
  }
}

**Cross-account automation & bootstrapping**- Central CI/management identity lives in Org management account (or GitOps runner). Create an IAM role in each target account (e.g., terraform-executor) with a minimal assume-role trust from the central principal/role.- Bootstrap process (run once, by Org admin): create per-account S3 bucket, DynamoDB lock table, KMS key, and the terraform-executor role via CloudFormation/Control Tower or Terraform using org-level credentials.- Example trust policy (outline):

json

{
  "Effect":"Allow",
  "Principal":{"AWS":"arn:aws:iam::111111111111:role/ci-runner"},
  "Action":"sts:AssumeRole"
}

- Grant least-privilege permissions for the executor role scoped to the account’s resources and state bucket access.

**CI/CD considerations & promotion paths**- Git structure: mono-repo with directories per account/env or separate repos. Use PRs for changes; pipeline runs plan on PR.- Pipeline flow: - Dev branch -> automatic plan + apply in dev account (auto-apply allowed). - Merge to staging -> pipeline assumes staging role, runs plan; requires approvals to apply. - Merge to main/prod -> plan + manual approval + apply in prod with multi-person approval.- Authentication: prefer OIDC or short-lived credentials; CI assumes central role which then sts:AssumeRole to target account role.- Security: store only minimal secrets. KMS key policies allow CI role access; restrict S3 bucket policies to account + CI principal.- Promotion gating: automated Plan artefact stored, signed; promotion uses same plan or re-run plan with diff check to avoid drift.- Drift detection: scheduled runs in CI to plan and report drift.

**Trade-offs & best practices**- Centralized state locking per account isolates blast radius.- Per-account buckets increase management but improve security. Use automation to bootstrap them.- Use modules for reuse, but keep composition in account stacks to allow account-specific overrides.- Enforce policies with SCPs/Config from management account; use Terraform only where appropriate.

This design balances security (KMS, per-account state, least privilege), scalability (module reuse + OU overlays), and safe promotion (PRs, plans, approvals).

EasyTechnical

32 practiced

Write an Ansible playbook (YAML) that targets hosts in the 'web' inventory group, installs nginx on Ubuntu, deploys a template file to /etc/nginx/nginx.conf, ensures nginx is enabled and running, and restarts nginx only if the configuration template changed. Keep tasks idempotent and include the handler(s).

Sample Answer

**Approach (brief)**

- Target group: web- Use apt to install nginx on Ubuntu (idempotent)- Deploy template with notify so handler restarts nginx only when template changed- Ensure service enabled and running

**Playbook (YAML)**

yaml

- name: Install and configure nginx on web servers
  hosts: web
  become: true
  vars:
    nginx_conf_src: nginx.conf.j2

  tasks:
    - name: Ensure apt cache is up-to-date (Ubuntu)
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Deploy nginx configuration from template
      template:
        src: "{{ nginx_conf_src }}"
        dest: /etc/nginx/nginx.conf
        owner: root
        group: root
        mode: '0644'
      notify: Restart nginx

    - name: Ensure nginx is enabled and running
      service:
        name: nginx
        state: started
        enabled: yes

  handlers:
    - name: Restart nginx
      service:
        name: nginx
        state: restarted

**Key points / reasoning**

- template + notify ensures restart only when file changed (idempotent).- apt with update_cache avoids stale package lists.- service task ensures desired running/enabled state even if handler was not triggered.- As a Cloud Engineer, keep templates in repo and parametrize via vars for multi-environment deployments.

MediumTechnical

42 practiced

Design a secure pattern for handling secrets used by Terraform and Ansible in AWS deployments. Cover secret retrieval (such as AWS SSM Parameter Store, Secrets Manager, or HashiCorp Vault), avoiding secret leakage in state or CI logs, and how to integrate short-lived credentials and rotation into CI/CD workflows.

Sample Answer

**Approach summary**Design secrets flow where secrets are never checked into VCS or plain CI logs, are fetched at runtime with short-lived credentials, and stored encrypted in remote state/backends.

**Secret storage options (recommended)**- AWS Secrets Manager / SSM Parameter Store (SecureString): store application/config secrets; use rotation Lambda for RDS/API keys.- HashiCorp Vault: for dynamic secrets (DB creds, AWS IAM) and central policy-based access.

**Terraform best practices**- Use remote backend (S3 + DynamoDB) with SSE-KMS; restrict access via IAM.- Mark sensitive outputs and variables (sensitive = true) and avoid terraform output printing.- Use provider data sources that read secrets at plan/apply time (e.g., aws_secretsmanager_secret_version) or integrate Vault provider for dynamic creds.- Prevent secrets in state: avoid resources that embed secret plaintext; if unavoidable, encrypt the state with KMS and limit access.

**Ansible best practices**- Use Ansible Vault for playbook-level secrets when needed, but prefer runtime retrieval from Vault/SSM via lookup plugins.- Set no_log: true for tasks handling secrets to avoid CI logs.- Do not register or debug-print secret variables.

**CI/CD integration**- Use OIDC federation (GitHub Actions/GitLab) to assume short-lived IAM roles — no long-lived cloud keys in CI.- CI fetches secrets at runtime from Vault/Secrets Manager; inject into ephemeral environment variables only for the step and ensure masking.- For Vault: CI authenticates with OIDC or Kubernetes auth to obtain a Vault token with limited TTL/leases; fetch dynamic creds that auto-expire.

**Rotation & short-lived creds**- Prefer dynamic credentials: Vault issues DB/AWS creds with TTL and automatic revocation.- For Secrets Manager, enable automatic rotation where supported (Lambda).- CI pipelines should retry and handle 401/expired token errors; refresh tokens via OIDC/STS.

**Leak prevention checklist**- No secrets in repo or Terraform state outputs; KMS-encrypt state; limit IAM/S3 access.- Mask secrets in CI logs and use no_log.- Audit: enable CloudTrail, Vault audit logs, and monitor for anomalous secret access.

This pattern gives centralized control (Vault/Secrets Manager), runtime retrieval with short-lived creds, encrypted state, and CI that never holds long-lived secrets.

MediumSystem Design

45 practiced

Design a CI/CD pipeline for Terraform deployments (choose a runner like GitHub Actions, GitLab CI, or Jenkins) that enforces: terraform fmt, linting (tflint), a terraform plan on PRs with plan output posted to the PR, policy-as-code checks (OPA or Checkov), and manual approval gates for production applies. Explain credentials handling and separation between plan and apply stages.

Sample Answer

**Overview / Requirements Clarification**I’d use GitHub Actions as the runner. Pipeline must: run terraform fmt, tflint, terraform plan on PRs with plan posted to PR, run policy-as-code (OPA/Checkov), and require manual approval for production apply. Keep plan and apply separated; use short-lived creds for applies.

**High-level flow**- On PR (push/PR): fmt -> init -> validate -> tflint -> terraform plan -> policy checks -> post plan as PR comment.- On merge to non-prod branch: plan job (same checks) then automatic apply with CI role.- On merge to prod branch: plan job creates plan artifact and requires a manual approval (workflow_dispatch or environment protection) before apply.

**Credentials & Secrets**- Use OIDC with GitHub Actions to assume cloud IAM roles (AWS/GCP) per environment — no long-lived secrets.- Store minimal GitHub Secrets for tooling configs (e.g., TFLint rules) only if needed.- Separate IAM roles: ci-plan role (read-only/state access), ci-apply role (creates/updates infra). Apply role restricted by environment and assumed only in protected workflow run (enforced via GitHub Environments + required reviewers).

**Plan vs Apply separation**- Plan jobs produce a saved binary/text plan artifact and a drift-safe JSON plan output.- Apply job must explicitly consume the plan artifact; apply only if plan checksum matches current repo state to prevent replay attacks.- For prod: apply job gated by GitHub Environment with required approvals or a manual approval step (workflow_run or environment protection).

**Policy-as-code**- Run Checkov/OPA against Terraform source and the generated plan (Checkov plan scan).- Fail pipeline if policy violations found; include results in PR comment.

**Posting plan to PR**- Use terraform plan -out=plan.binary and terraform show -json plan.binary > plan.json- Use a small action/script to summarize plan (counts of add/change/destroy) and post plan JSON or a link to artifact via GitHub REST API.

**Sample GitHub Actions snippets**

yaml

name: terraform-pr
on: [pull_request]
jobs:
  fmt-lint-plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
      - name: terraform fmt
        run: terraform fmt -check
      - name: tflint
        uses: terraform-linters/tflint-action@v1
      - name: terraform init
        run: terraform init -backend-config=...
      - name: terraform plan
        env:
          AWS_ROLE_ARN: ${{ secrets.CI_PLAN_ROLE_ARN }}
        run: |
          # assume via OIDC or aws sts to get creds
          terraform plan -out=tfplan
          terraform show -json tfplan > tfplan.json
      - name: run checkov
        uses: bridgecrewio/checkov@v2
        with:
          framework: "terraform"
      - name: post plan to PR
        uses: actions/github-script@v6
        with:
          script: |
            const fs = require('fs');
            const plan = fs.readFileSync('tfplan.json','utf8');
            github.issues.createComment({owner, repo, issue_number: context.issue.number, body: 'Plan JSON...'})

**Security & Best Practices**- Use OIDC and short-lived role assumption per job.- Enforce branch protections and GitHub Environment approvals for prod.- Use remote state with locking (S3+Dynamo/Cloud Storage) and restrict access to state.- Validate plan artifact checksum in apply job to prevent mismatches.

This design enforces formatting, linting, policy checks, PR visibility of plans, strict credential separation, and manual approval for production applies.

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.