Portfolio Projects for Cloud Engineer

Dein Cloud-Zertifikat bringt dich nicht zum Gespräch. Ich sehe das jede Woche: Bewerbungen mit AWS Solutions Architect, AZ-900 und drei weiteren Abzeichen, und trotzdem keine Rückmeldung. Der Grund ist simpel. Zertifikate zeigen, dass du eine Prüfung bestanden hast. Projekte zeigen, dass du Systeme bauen kannst, die kaputtgehen, und dass du sie wieder hinkriegst.

Genau das will ein Reviewer sehen. Nicht, dass du einem Tutorial gefolgt bist, sondern dass du Entscheidungen getroffen hast. Dazu kommen wir gleich.

Was Reviewer wirklich anschauen#

Wer auch immer deine Bewerbung öffnet, verbringt mit deinem Portfolio vielleicht zwei Minuten. In der Zeit wird nach drei Dingen gesucht.

Erstens: Hat diese Person Probleme gelöst oder nur Anleitungen kopiert? Ein Projekt mit 200 Zeilen Terraform und einem README, das nur "Deployment via terraform apply" sagt, ist ein Tutorial. Ein Projekt mit einer kurzen Entscheidungsdokumentation, warum du statt ECS Fargate lieber einen Lambda-basierten Ansatz gewählt hast, ist Ingenieurarbeit.

Zweitens: Versteht die Person Betrieb, nicht nur Setup. Das ist der häufigste Bruch. Viele Portfolios enden beim ersten grünen Deployment. Ein Reviewer will wissen: Was passiert bei Last? Was passiert, wenn ein Container stirbt? Wie merkst du das überhaupt?

Drittens: Passt das zum Job. Eine Bewerbung auf eine Stelle mit viel Kubernetes und Terraform, und im Portfolio steht ein Serverless-Tutorialprojekt, das ist vertane Zeit. Lies die Stellenanzeige genau. Unser kostenloser Stellenanzeigen-Entschlüsseler hilft dir, die echten Anforderungen aus der Ausschreibung herauszuziehen, bevor du dein Portfolio darauf ausrichtest.

Projekt 1: Eine mehrstufige Infrastruktur mit Terraform und CI#

Baue eine Infrastruktur, die über eine einzelne VM hinausgeht: Netzwerk, Datenbank, eine Anwendung, Monitoring. Alles als Code, alles versioniert. Der Clou ist nicht die Architektur, sondern der Weg dorthin.

Verwende Terraform mit Remote State und getrennten Umgebungen. Schreibe Module, kein Copy-Paste. Baue eine Pipeline, die bei jedem Pull Request einen Plan ausführt und bei Merge auf Staging deployt. Das ist der Teil, den die meisten weglassen, und genau der Teil, den Reviewer lesen.

Ein konkretes Beispiel für eine Resume-Zeile dazu:

Vorher: "Terraform-Projekt für eine Webanwendung erstellt."

Nachher: "Infrastruktur für eine Containeranwendung mit RDS, VPC und Auto-Scaling in Terraform modularisiert; Remote State in S3 mit Locking; CI-Pipeline führt bei jedem Pull Request terraform plan aus und reduziert fehlerhafte Deployments auf Staging."

Der Unterschied ist die Zahl und der Mechanismus. Wenn du keine echte Zahl hast, nimm die Anzahl der Ressourcen oder Module, das ist auch eine konkrete Größe.

Projekt 2: Eine Anwendung, die unter Last und Ausfällen überlebt#

Nimm eine simple Anwendung, eine API, ein Worker, eine Datenbank. Dann bring sie absichtlich an den Rand. Simuliere Datenbankausfall, simuliere Traffic-Spitzen, miss, was passiert. Und dokumentiere, was du danach geändert hast.

Das ist ein Projekt, das im Gespräch richtig glänzt, weil du aus Fehlern erzählen kannst. Ein Reviewer, der selbst betrieben hat, weiß: Systeme, die nie ausgefallen sind, wurden nie ernsthaft getestet.

Baue Health Checks, Retries mit Backoff, sinnvolle Timeouts. Richte Metriken und Alarme ein, keine bunten Dashboards ohne Handlungswert. Ein Alarm, der bei 3 Uhr nachts losgeht und sagt "Datenbank-Connections über Schwelle", ist mehr wert als zehn Diagramme.

Ein Stück README, das hier gut ankommt, sieht so aus:

"Getestet mit 500 gleichzeitigen Requests über Locust. P95-Latenz lag initial bei 2,3 Sekunden. Ursache: fehlender Connection Pooling. Nach Einführung von PgBouncer P95 bei 180 ms. Ausfall der Datenbank wird nach 3 Fehlversuchen an den Client gemeldet, Alarm geht an das On-Call-Postfach."

Zahlen, Ursache, Fix. Das liest sich nach Arbeit.

Projekt 3: Ein kleines, aber ehrliches Observability-Projekt#

Viele Cloud Engineers können deployen. Wenige können erklären, wie sie merken, dass etwas kaputt ist. Ein eigenes Observability-Projekt hebt dich ab, weil es zeigt, dass du über den grünen Build hinausdenkst.

Nimm ein bestehendes Projekt von dir, am besten Projekt 2, und instrumentiere es. Traces, Logs, Metriken, korreliert. Richte SLOs ein, auch wenn du sie selbst definierst. Zeige einen konkreten Incident: Was hat der Alarm gesagt, wie hast du eingegrenzt, was war die Ursache.

Das Projekt braucht keine teure Cloud-Rechnung. Lokal mit Docker Compose, Prometheus, Grafana und einem OpenTelemetry-Collector reicht völlig. Was zählt, ist, dass du die Konzepte verstehst und erklären kannst, warum ein Trace mehr sagt als eine Logzeile.

So präsentierst du das auf GitHub#

Der README ist dein Lebenslauf. Wer ihn nicht liest, liest auch deinen Code nicht. Halte die ersten 30 Zeilen informativ: Was macht das Projekt, welches Problem löst es, wie starte ich es, welche Entscheidungen hast du getroffen.

Ein README-Start, der funktioniert:

"Kleine API-Infrastruktur auf AWS, komplett in Terraform. Deployment auf Staging automatisch bei Merge, Produktion manuell. Entscheidungen und Alternativen stehen in docs/decisions.md. Lokaler Start mit docker compose up, dauert etwa 90 Sekunden."

Dazu eine kurze Architekturskizze, ein Abschnitt zu Trade-offs und ein Abschnitt "Was ich anders machen würde". Der letzte Abschnitt wirkt kontraproduktiv, ist aber das Ehrlichkeitsignal, das Reviewer suchen. Niemand erwartet Perfektion. Alle erwarten Reflexion.

Halte das Repo sauber: kein generiertes Zeug im Commit, keine Secrets, eine sinnvolle Ordnerstruktur. Wenn du wissen willst, ob dein Lebenslauf überhaupt durch die erste Filterung kommt, wirf einen Blick auf unseren kostenlosen ATS-Check, der zeigt, ob deine Bewerbung technisch sauber strukturiert ist.

So schreibst du es in den Lebenslauf#

Dein Projektblock gehört unter die Projekterfahrung, nicht ganz ans Ende unter "Interessen". Behandle ihn wie eine Stelle: Zeitraum, Kontext, Ergebnis. Drei Zeilen pro Projekt reichen.

Für Projekt 1:

"Cloud-Infrastruktur-Projekt, 2025 bis heute. Aufbau einer mehrstufigen AWS-Infrastruktur in Terraform mit Remote State, Modultrennung und CI-gesteuerten Deployments. Ergebnis: reproduzierbare Umgebungen, manuelle Deployments entfallen."

Drei Zeilen. Keine Adjektive, keine Floskeln. Wenn du eine berufliche Lücke hast, positioniere die Projekte so, dass sie die Lücke füllen, und sei im Gespräch bereit, darüber offen zu reden. Ehrlichkeit schlägt hier jede Formulierung.

Fehler, die Projekte wie Tutorials aussehen lassen#

Der Klassiker: das Projekt heißt "terraform-aws-example" oder "k8s-demo". Benenne es nach dem Problem, nicht nach der Technologie. "Deployment-Pipeline für Container-Workloads" klingt nach Arbeit, "aws-eks-demo" klingt nach Copy-Paste.

Fehler zwei: das README besteht aus Installierungsanleitung und Screenshots. Kein Wort zu Alternativen, keine Begründung, keine Zahlen. Fehler drei: keine Versionshistorie. Ein Repo mit einem einzigen Commit wirkt, als wäre es an einem Nachmittag entstanden. Committe über Wochen, zeig Entwicklung.

Fehler vier: alles auf einmal. Drei Projekte mit je 20 Dateien sind besser als ein Monolith mit 400 Dateien. Fehler fünf: ignorierte Issues und veraltete Abhängigkeiten im eigenen Repo. Wenn du von anderen verlangst, saubere Software zu liefern, dann liefere sie auch.

So redest du im Interview darüber#

Erwarte die Frage "Erzähl mir von einem Projekt aus deinem Portfolio". Bereite eine Antwort von 90 Sekunden vor. Struktur: Problem, deine Rolle, die wichtigste Entscheidung, das Ergebnis, was du gelernt hast.

Ein Beispiel für Projekt 2:

"Ich habe eine API aufgebaut und wollte wissen, wie sie sich unter Last verhält. Ich habe mit Locust simuliert, P95-Latenz lag bei über zwei Sekunden, Ursache war fehlendes Connection Pooling. Ich habe PgBouncer eingeführt und die Latenz auf 180 ms gebracht. Was ich gelernt habe: Ich hätte von Anfang an Lasttests einbauen sollen, nicht erst am Ende."

Kurz, ehrlich, mit Zahl und Lektion. Keine Heldengeschichte.

Wenn eine Frage kommt, die du nicht beantworten kannst, sag das. "Das habe ich nicht ausprobiert, meine Vermutung wäre X, weil Y" ist eine starke Antwort. Gerade im Cloud-Bereich prüfen Interviewer oft, ob du ehrlich bleibst, wenn es eng wird. Unsere Übersicht zu aktuellen Cloud-Stellen zeigt dir, welche Fragen in welchen Rollen tatsächlich vorkommen, bevor du dich vorbereitest.

Zertifikate: nicht weglassen, aber richtig einordnen#

Zertifikate sind kein Ersatz für Projekte, aber sie schaden nicht. Ein AZ-104 oder AWS-SAA neben zwei soliden Projekten ist ein gutes Paket. Ein Stapel von fünf Zertifikaten ohne ein einziges eigenes Projekt wirkt, als hättest du Zeit und Geld statt Können investiert.

Setze Zertifikate in eine Zeile unter die Projekte, nicht darüber. Und wenn du ein Zertifikat anstrebst, wähle das, was zu deinen Projekten passt, nicht das, was gerade im Trend liegt. Mehr zu Zertifikaten und Karrierewegen im Cloud-Bereich findest du in unseren Artikeln auf dem jobrise-Blog.

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie viele Portfolio-Projekte brauche ich als Cloud Engineer?

Drei durchdachte Projekte reichen für die meisten Bewerbungen. Wichtiger als die Anzahl ist die Tiefe: Entscheidungen, Zahlen, Reflexion. Ein Projekt, das du im Detail erklären kannst, schlägt fünf, die du nur oberflächlich kennst.

Kann ich auch private Projekte für Bewerbungen verwenden?

Ja, private Projekte sind normal und werden akzeptiert. Nutze dann einen kurzen öffentlichen README oder eine Architekturskizze als Vorschau. Wichtig ist, dass der Reviewer in fünf Minuten versteht, was du gebaut hast und warum.

Was, wenn meine Projekte auf einer kostenlosen Cloud-Stufe laufen?

Völlig in Ordnung, das ist sogar realistisch für den Einstieg. Schreib transparent dazu, welche Limits du genutzt hast. Reviewer bewerten deine Entscheidungen, nicht deine monatliche Cloud-Rechnung.

Wie aktuell müssen die Technologien in meinen Projekten sein?

Sie müssen nicht brandneu sein, aber sie sollten zum Stellenprofil passen. Terraform, Kubernetes und gängige CI/Tools sind auch nach Jahren noch relevant. Sei bereit zu erklären, warum du eine Technologie gewählt hast, das wiegt schwerer als das Veröffentlichungsdatum.

Soll ich meine Projekte auch auf LinkedIn zeigen?

Ja, ein kurzer Post mit Architekturskizze und einer Lektion bringt Sichtbarkeit. Verlinke direkt auf das GitHub-Repo, nicht auf einen Blogpost darüber. Und halte deine Bewerbungsunterlagen aktuell, passende offene Stellen findest du in unserer Cloud-Jobs-Übersicht.