Ansible vs Terraform 2026: Infrastructure as Code und DevOps-Interviewfragen

Ansible vs Terraform gehört zu den häufigsten Vergleichsfragen in DevOps-Interviews, doch die Fragestellung selbst offenbart ein Missverständnis: Diese Tools lösen unterschiedliche Probleme. Ansible 2.20 übernimmt das Configuration Management und Application Deployment, während Terraform 1.15 Infrastrukturressourcen provisioniert. Das Verständnis, wann welches Tool glänzt, wo sie sich überschneiden und wie sie sich ergänzen, unterscheidet Senior DevOps Engineers von Berufseinsteigern.

Deklarativ vs Prozedural: Der fundamentale Unterschied

Terraform verwendet einen deklarativen Ansatz. Eine Konfigurationsdatei beschreibt den gewünschten Endzustand, und Terraform berechnet die notwendigen Änderungen, um diesen zu erreichen. Das funktioniert gut für Infrastruktur, die als Einheit erstellt, geändert oder zerstört werden muss.

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Die Ausführung von terraform apply erstellt beide Ressourcen, falls sie nicht existieren, oder aktualisiert sie entsprechend der Konfiguration. Eine erneute Ausführung ohne Änderungen erzeugt keine Operationen: Terraform vergleicht die Konfiguration mit seiner State-Datei und stellt fest, dass nichts zu tun ist.

Ansible verwendet einen prozeduralen Ansatz mit Tasks, die der Reihe nach ausgeführt werden. Während Ansible-Module oft idempotent sind (zweimalige Ausführung erzeugt dasselbe Ergebnis), beschreibt das Playbook selbst eine Abfolge von Aktionen statt eines Endzustands.

# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Jeder Task wird sequentiell ausgeführt. Das Notify/Handler-Pattern bietet ein gewisses deklaratives Verhalten: Der Handler läuft nur einmal am Ende, unabhängig davon, wie viele Tasks ihn auslösen.

State Management: Ein kritisches Interviewthema

Terraform pflegt eine State-Datei, die Konfiguration auf reale Ressourcen abbildet. Dieser State verfolgt Ressourcen-IDs, Abhängigkeiten und Metadaten. Ohne ihn kann Terraform nicht bestimmen, was existiert oder was geändert werden muss.

Ansible hat keine äquivalente State-Datei. Es verbindet sich mit Zielsystemen und führt Tasks aus, wobei es sich auf den aktuellen Systemzustand und die Modul-Idempotenz verlässt. Das macht Ansible einfacher für den Einstieg, aber schwieriger, um Änderungen über Zeit zu verfolgen.

Eine häufige Interviewfrage behandelt die State-Datei-Sicherheit. Terraform State kann sensible Daten enthalten: Datenbankpasswörter, API-Keys, Ressourcen-Identifikatoren. Produktions-Deployments speichern State remote (S3, Azure Blob, Terraform Cloud) mit Verschlüsselung und Zugriffskontrollen.

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Die DynamoDB-Tabelle bietet Locking und verhindert, dass zwei Entwickler gleichzeitig den State modifizieren.

Wann welches Tool einsetzen

Terraform glänzt bei der Provisionierung von Cloud-Infrastruktur: virtuelle Maschinen, Managed Databases, Load Balancer, IAM-Rollen, VPCs. Es handhabt Abhängigkeiten zwischen Ressourcen automatisch und unterstützt alle großen Cloud-Provider durch eine einheitliche HCL-Syntax.

Ansible glänzt bei der Konfiguration existierender Systeme: Installation von Paketen, Verwaltung von Benutzern, Deployment von Anwendungscode, Orchestrierung mehrstufiger Deployments. Es verbindet sich über SSH (oder WinRM für Windows) ohne Agents auf den Zielsystemen.

Die Überschneidungszone sorgt für Verwirrung. Beide können Software auf einer VM installieren. Terraform kann Provisioners nutzen, um Skripte nach der Ressourcenerstellung auszuführen. Ansible kann Cloud-Ressourcen über Module wie amazon.aws.ec2_instance erstellen. Aber die Verwendung jedes Tools außerhalb seiner Stärken führt zu Wartbarkeitsproblemen.

Der kombinierte Workflow in der Produktion

Die meisten Organisationen nutzen beide Tools zusammen. Terraform provisioniert die Infrastruktur und gibt Verbindungsdetails aus. Ansible konsumiert diese Outputs, um die Systeme zu konfigurieren.

# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}

Eine CI/CD-Pipeline führt zuerst Terraform aus, erfasst Outputs, generiert dynamisch ein Ansible-Inventory und führt dann Playbooks gegen die neue Infrastruktur aus.

# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"

Dieses dynamische Inventory fragt AWS direkt ab und gruppiert Instanzen nach ihren Tags. Keine manuelle IP-Verwaltung erforderlich.

OpenTofu: Der Fork, der die Landschaft veränderte

HashiCorp hat Terraform im August 2023 unter die Business Source License (BSL) gestellt. Die Community reagierte mit einem Fork von Terraform 1.5 zu OpenTofu, das jetzt unter der Linux Foundation gehostet wird.

Stand August 2026 bleibt OpenTofu 1.11.6 für die meisten Terraform-Workflows ein Drop-in-Replacement. Dieselbe HCL-Syntax, dasselbe Provider-Ökosystem, dasselbe State-Format. OpenTofu hat Features hinzugefügt, die in Terraforms Open-Source-Binary nicht vorhanden sind: State-Verschlüsselung, Provider for_each und Early Variable Evaluation.

Für die Interviewvorbereitung ist das Verständnis der Lizenzunterschiede wichtig. BSL erlaubt interne Nutzung, beschränkt aber den Aufbau konkurrierender Produkte. Organisationen mit Bedenken bezüglich Vendor Lock-in oder spezifischen Compliance-Anforderungen bevorzugen möglicherweise OpenTofus MPL 2.0-Lizenz. HashiCorps Übernahme durch IBM im Dezember 2024 fügte den Diskussionen über Herstellerbeziehungen eine weitere Variable hinzu.

Häufige DevOps-Interviewfragen

Frage: Kann Ansible Terraform ersetzen?

Nicht effektiv. Ansible kann Cloud-Ressourcen erstellen, aber es fehlt das State Management. Das zweimalige Ausführen desselben Playbooks könnte doppelte Ressourcen erstellen. Terraforms State-Datei verfolgt, was existiert, und berechnet minimale Änderungen. Ansible für das nutzen, was es am besten kann: Configuration Management.

Frage: Wie werden Secrets in Terraform behandelt?

Niemals Secrets in die Versionskontrolle committen. Umgebungsvariablen, Vault-Integration oder Cloud-Provider Secret Manager nutzen. Variablen als sensitive markieren, um ihr Erscheinen in Logs zu verhindern:

# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}

Frage: Was ist Ansible-Idempotenz?

Eine idempotente Operation erzeugt dasselbe Ergebnis, egal ob sie einmal oder mehrmals ausgeführt wird. Das apt-Modul mit state: present installiert ein Paket, wenn es fehlt, und tut nichts, wenn es bereits installiert ist. Das Schreiben idempotenter Playbooks verhindert unbeabsichtigte Änderungen bei nachfolgenden Durchläufen.

Frage: Wie wird Infrastructure Code getestet?

Terraform: terraform validate prüft die Syntax, terraform plan zeigt Änderungen in der Vorschau, und Tools wie Terratest führen Integrationstests durch. Ansible: ansible-lint erkennt Probleme, --check-Modus führt Dry Runs durch, und Molecule testet Roles gegen Container.

Für eine tiefere Terraform-Interviewvorbereitung siehe Terraform Interview Questions: Infrastructure as Code Complete Guide. Praktische Übungen mit Terraform Basics und Ansible Configuration Management Modulen.

Versionskompatibilität und Ökosystem

Aktuelle stabile Versionen Stand August 2026:

Ansibles Collection-Architektur trennt Kernfunktionalität von providerspezifischen Modulen. Die amazon.aws-Collection erhält Updates unabhängig vom Ansible-Core. Das ist relevant für Version-Pinning in CI/CD-Pipelines.

Terraforms Provider-Versionierung folgt ähnlichen Prinzipien. Lock-Dateien (terraform.lock.hcl) stellen konsistente Provider-Versionen über Teammitglieder und CI-Systeme hinweg sicher.

# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

Zwischen beiden wählen: Ein Entscheidungsframework

Die Frage lautet selten Ansible oder Terraform. Die Frage lautet, welches Tool welche Verantwortung übernimmt.

Für ein vollständiges Bild, wie diese Tools in moderne Deployment-Workflows passen, siehe CI/CD Pipeline Interview Questions.

Was Senior Engineers über Ansible und Terraform wissen sollten

• Terraform verwaltet Infrastruktur-State deklarativ; Ansible konfiguriert Systeme prozedural. Die gemeinsame Nutzung beider erzeugt wartbare Infrastruktur.
• State-Datei-Sicherheit ist wichtig. Terraform State remote mit aktivierter Verschlüsselung und Locking speichern.
• OpenTofu bietet eine MPL-lizenzierte Alternative zu Terraform mit zusätzlichen Features. Die Migration ist für die meisten Workflows unkompliziert.
• Idempotenz ist nicht automatisch. Playbooks schreiben, die bei wiederholten Durchläufen konsistente Ergebnisse produzieren.
• Dynamisches Inventory eliminiert manuelle Host-Verwaltung. Cloud-Provider direkt nach aktueller Infrastruktur abfragen.
• Version-Pinning verhindert Überraschungen. Provider-Versionen in Terraform locken; Collection-Versionen in Ansible pinnen.
• Das Testen von Infrastructure Code erfordert unterschiedliche Ansätze: terraform plan für die Vorschau von Änderungen, --check-Modus für Ansible Dry Runs, Integrationstestframeworks für beide.