Infrastructure as Code and Configuration Management Questions

Infrastructure as Code and Configuration Management covers designing, implementing, and operating infrastructure defined as code and the practices that keep that infrastructure consistent and auditable. Topics include Infrastructure as Code principles and patterns, declarative versus imperative approaches, idempotency, state management, module and template design for reusable infrastructure, version control integration, testing and validation of infrastructure code, drift detection and remediation, safe rollout and rollback strategies, policy as code and Git operations for infrastructure, and how to scan and remediate infrastructure misconfigurations. This topic also encompasses integration points with system configuration tools and considerations for managing secrets and secure defaults within infrastructure definitions.

EasyTechnical

33 practiced

Compare configuration management systems (Ansible, Puppet, Chef) with IaC provisioning tools (Terraform, CloudFormation, Pulumi). From a Systems Administrator perspective, explain how to use them together in a coherent workflow and give one concrete example workflow that uses both.

HardTechnical

30 practiced

You must create a governance model for IaC modules across the organization. Propose rules for semantic versioning, an internal module registry, acceptance test requirements, release automation, how to manage breaking changes and deprecations, and how to enforce module usage while enabling team autonomy.

Sample Answer

**Overview (goal)** Establish a clear, low-friction governance model that ensures safe, discoverable, tested IaC modules while preserving team autonomy for deployments and experimentation.

**Semantic versioning rules** - Adopt SemVer 2.0.0: MAJOR for breaking API changes, MINOR for backward-compatible feature adds, PATCH for bugfixes. - Require CHANGELOG and upgrade notes for MINOR/MAJOR. - Enforce version pinning in environment manifests (no floating >= constraints in prod).

**Internal module registry** - Single organizational registry (e.g., private Terraform Registry, Artifactory). - Metadata: owner team, stability (alpha/beta/stable), supported platforms, compatibility matrix. - Searchable UI + CLI and automated vulnerability/secret scanning on publish.

**Acceptance test requirements** - Mandatory unit-style linting + integration acceptance tests (Terratest / Test Kitchen) run in ephemeral cloud accounts. - Test categories: basic apply/destroy, idempotency, security checks (IAM least-privilege), and compliance assertions. - Minimum: 1 integration test per module demonstrating intended use.

**Release automation** - CI pipeline triggers: PR -> run lint + unit tests; merge -> run integration tests against sandbox; on success, create release artifact and push to registry. - Use Git tags mapped to SemVer; signed artifacts and immutable storage. - Automate changelog generation from PRs and enforce PR template.

**Managing breaking changes & deprecations** - Breaking changes require MAJOR bump + migration guide and minimum 2 release cycles of deprecation warnings. - Deprecation label in registry + automated telemetry to report usage of deprecated versions. - Provide migration PR templates and optional compatibility shims where feasible.

**Enforcement while enabling autonomy** - Policy-as-code gate (OPA/Sentinel) in CI to enforce version pinning, approved registries, and require tests pass — blocks prod deployments but allows sandbox. - Empower teams: create a lightweight module onboarding checklist and designate module owners who can fast-track minor updates. - Offer a “lab” namespace for experimentation; only promote to org-registry after passing governance checks.

**Operational practices** - Quarterly review of module health, usage metrics, and owners. - Training, templates, and on-call support for module maintainers.

This balances safety (automated checks, policy gates) with speed (sandbox channels, clear ownership, automated releases) appropriate for systems administration teams managing cloud infrastructure.

EasyTechnical

31 practiced

What is configuration drift in IaC-managed environments? As a Systems Administrator, describe at least three practical methods to detect drift across cloud resources (including tooling or API approaches), and explain the trade-offs and operational cost of each method.

MediumTechnical

30 practiced

A critical RDS instance was created manually before you had IaC in place. As a Systems Administrator, describe the step-by-step process to import that RDS into Terraform state with minimal downtime: creating the resource block, running import, reconciling computed attributes, and validating the plan afterwards.

Sample Answer

**Overview / Goal**Import a manually-created RDS into Terraform state with no disruptive changes: create a matching resource block, import the existing instance id, reconcile computed attributes, run plan and apply only safe changes.

**Step-by-step**

1. Inventory & backup- Note DB identifier, engine, instance class, subnet group, security groups, tags.- Take a final snapshot or enable automated snapshot.

2. Create terraform resource block (match names/types)

hcl

resource "aws_db_instance" "prod_db" {
  identifier         = "my-prod-db"
  instance_class     = "db.t3.medium"
  engine             = "postgres"
  allocated_storage  = 100
  username           = "admin"
  # Omit computed attributes like endpoint, address, password
  # Add subnet_group, vpc_security_group_ids, parameter_group_name as applicable
}

3. Initialize and import

bash

terraform init
terraform import aws_db_instance.prod_db my-prod-db

4. Reconcile computed/remote-only attributes- Run `terraform state show aws_db_instance.prod_db` to view attributes.- Copy required attributes (e.g., parameter_group_name, option_group_name, storage_encrypted, iam_database_authentication_enabled, monitoring_interval) into the resource block if you want Terraform to manage them.- Remove or mark sensitive/computed fields (endpoint, address, arn) from config.

5. Plan and review

bash

terraform plan -out=tfplan
terraform show -json tfplan | jq '.'   # inspect diffs

- Verify plan shows no destructive changes. If it proposes changes you don’t want, adjust config to match remote state or use lifecycle ignore_changes for fields that must remain unmanaged:

hcl

lifecycle { ignore_changes = [password, tags] }

6. Apply with minimal downtime- If plan is no-op, run `terraform apply tfplan`.- If changes required (e.g., instance_class), schedule during maintenance window or promote read-replica pattern: create read replica, switch, then apply.

7. Validate- Confirm DB accessible, tags set, monitoring enabled.- Run `terraform state list` and `terraform plan` again to ensure stable state.

**Notes / Best practices**- Use IAM role with limited permissions.- Test in staging first.- Keep sensitive data (password) out of config; use secrets manager.

MediumTechnical

25 practiced

You are responsible for managing shared Terraform state in AWS. Provide an HCL backend configuration example for an S3 backend with DynamoDB for state locking. Explain the purpose of each option (bucket, key, region, encrypt, dynamodb_table) and IAM permissions required for safe operation.

Sample Answer

**Backend HCL example**

hcl

terraform {
  backend "s3" {
    bucket         = "my-org-terraform-state"
    key            = "prod/vpc/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-locks"
  }
}

Purpose of each option- bucket: S3 bucket name that stores the remote state file. Central single source of truth.- key: Path/object name inside the bucket for this workspace's state (allows per-environment separation).- region: AWS region where the S3 bucket and DynamoDB table live; used by Terraform API calls.- encrypt: When true, Terraform requests server-side encryption (SSE-S3) for the stored state to protect secrets at rest.- dynamodb_table: DynamoDB table used for state locking and to implement optimistic concurrency to prevent simultaneous writes.

Required IAM permissions (least-privilege recommendations)- S3 permissions (on the bucket/key prefix): - s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket (List on prefix), s3:GetObjectVersion (if versioning)- S3 bucket-level for encryption metadata: - s3:GetBucketVersioning, s3:PutObjectAcl (if ACLs used) — avoid ACLs by default- DynamoDB permissions (on the lock table): - dynamodb:GetItem, dynamodb:PutItem, dynamodb:DeleteItem, dynamodb:UpdateItem- Optional: kms:Encrypt, kms:Decrypt, kms:GenerateDataKey if using KMS-managed SSE

Example minimal IAM policy snippet (conceptual)- Allow S3 actions limited to "arn:aws:s3:::my-org-terraform-state" and "arn:aws:s3:::my-org-terraform-state/prod/*"- Allow DynamoDB actions limited to "arn:aws:dynamodb:us-east-1:ACCOUNT_ID:table/terraform-state-locks"

Operational notes- Enable S3 bucket versioning to recover overwritten state.- Use a single DynamoDB table for locks across workspaces (different keys).- Rotate credentials and use IAM roles for automation (CI/CD) to avoid long-lived keys.

Unlock Full Question Bank

Get access to hundreds of Infrastructure as Code and Configuration Management interview questions and detailed answers.

Join thousands of developers preparing for their dream job.