Persönliche Vorbereitung von Ali Chaghou — kein offizielles Nuvibit-Dokument.

Technical Interview · Vorbereitung

Ali Chaghou Nuvibit Technical Interview

AWS Landing-Zone-Showcase · Terraform · Multi-Account Architecture · Core Network

Ich habe dieses Showcase gebaut, um ein NARA-inspiriertes Landing-Zone-Konzept nicht nur oberflächlich zu kopieren, sondern an einem Kernbereich wirklich zu verstehen: dem Netzwerk-Hub mit Transit Gateway, Routing-Segmentierung und Account-übergreifender Bereitstellung.

Repository github.com/Ali-Chaghou/ntc-showcase

Was dieses Projekt ist — und was nicht

Das Projekt ist ein persönlicher Terraform-Showcase. Es ist kein produktives Deployment, keine vollständige NARA-Implementierung und kein fertiges Landing-Zone-Produkt. Der Schwerpunkt liegt auf erklärbarem Code, bewussten Architekturentscheidungen und klar dokumentierten Grenzen.

  • core-network: fmt + validate clean
  • organizations: validate clean (standalone)
  • account-factory: Ressourcen-Logik, root-gekoppelt
  • kein apply · kein Deploy · kein State-Backend in Betrieb

Der technische Kern: core-network

Ein zentraler Transit Gateway als Netzwerk-Hub, segmentiert über mehrere Route Tables und cross-account per RAM an die Workloads-OU geteilt. Jede dieser Zeilen steht als Code im Repo — kommentiert mit dem WARUM.

  • Transit-Gateway-Hub mit default_route_table_association und default_route_table_propagation bewusst disable — erzwingt explizite Segmentierung statt flachem Netz.
  • Eine Route Table pro Segment: hub · spoke-prod · spoke-dev · onprem.
  • Parametrisierbare VPC-Attachments: associated_route_table (genau eine) vs. propagate_to (Liste) — Association ≠ Propagation als Segmentierungswerkzeug.
  • Statische Routen inkl. Blackhole; n:m-Propagation in locals auf flache Keys ge-flattet.
  • RAM-Share an die Workloads-OU (nicht an Account-IDs), allow_external_principals = false.
  • ASN-Validierung, Feature-Flags und one(...)-Outputs, damit das Modul auch deaktiviert sauber bleibt.

Bewusst nicht vorgetäuscht

Ein Teil der Module ist bewusst als README-Stub dokumentiert. Das war keine Schwäche im Sinne von „vergessen", sondern eine Scope-Entscheidung: lieber einen Kernbereich tief erklären können, als viele Module oberflächlich anzudeuten.

  • vpc
  • ipam
  • route53
  • identity-center
  • log-archive
  • security-tooling
  • guardrails
  • parameters

Jeder Stub benennt Core-Account, die konkreten NARA-Ressourcen und die Cross-Account-Beziehungen — also die Schnittstelle, nicht die Fassade.

Entscheidungen, die ich erklären kann

  1. Ein Modul tief statt viele halb

    Lieber ein Modul, das ich Zeile für Zeile verteidigen kann, als elf abgeschriebene. Für ein Gespräch über Verständnis ist Tiefe mehr wert als Breite.

  2. Segmentierung über Routing, nicht über Security Groups

    Prod und Dev nutzen denselben Hub, sehen sich aber nicht — weil schlicht keine Route existiert, nicht weil eine Regel es verbietet. Vergessene Propagation = stiller Connectivity-Verlust statt versehentlicher Vollvermaschung.

  3. Network-Firewall-Inspection bewusst weggelassen

    Das Interface ist vorbereitet (network_firewall_enabled wird akzeptiert, aber ignoriert; appliance_mode_support pro Attachment schaltbar), die Inspection-VPC selbst nicht gebaut. Ehrlicher, als eine halbe Firewall zu zeigen.

  4. Kein apply, kein Deploy

    Der backend "s3"-Block ist Konfiguration auf dem Papier — kein bereitgestelltes State-Bucket. Alle Verify-Befehle laufen offline mit -backend=false.

  5. Was ich als nächsten Schritt bauen würde

    Eine Inspection-VPC am Hub (aws_networkfirewall_firewall), ein Inspection-Attachment im hub-Segment und 0.0.0.0/0-Default-Routen der Spokes auf dieses Attachment.

Wie ich das Projekt erklären möchte

  1. Scope ehrlich setzen — Showcase, kein Deployment.
  2. Architekturidee erklären — NARA Core Accounts, Hub-and-Spoke.
  3. core-network zeigen — TGW, Route Tables, Attachments.
  4. Route Tables / Segmentation erklären — Association ≠ Propagation.
  5. Stubs und Grenzen offen benennen.
  6. Den nächsten sinnvollen Schritt nennen — Inspection-Layer.

Fragen, die ich mitbringe

  • Wie unterscheidet ihr zwischen Standardmodul und kundenspezifischer Erweiterung?
  • Wie haltet ihr Landing-Zone-Governance über mehrere Kunden hinweg wiederverwendbar?
  • Wo endet Produktstandard und wo beginnt Projekt-/Consulting-Arbeit?
  • Wie dokumentiert ihr Architekturentscheidungen so, dass Teams sie später weitertragen können?
  • Welche Rolle spielt Terraform-Modulqualität im Alltag bei euch?
Privater Interview-Coach (Code-Reading-Runbook) →