Compare GitOps and Kustomize vs Ansible for environment configs

Tests declarative vs imperative trade-offs. Contrast GitOps drift detection with Ansible's imperative flexibility. Note Kustomize overlays for K8s vs Ansible's broader reach.
What's really being asked
The interviewer wants to see if you understand the architectural and operational differences between declarative desired-state systems and imperative procedural automation. They care about your ability to match tooling to organizational constraints like team size, infrastructure heterogeneity, compliance requirements, and deployment frequency rather than treating tools as interchangeable or selecting based on hype alone. Specifically, they are looking for nuanced judgment about when immutable version control beats procedural scripts.
The full answer
First, define the GitOps model using Kustomize overlays as declarative and Kubernetes-native. Emphasize that all environment deltas live in Git, providing immutable audit trails, automatic drift detection via reconcilers like ArgoCD or Flux, and atomic rollbacks by reverting commits. Second, characterize Ansible as an imperative, agentless configuration management tool that excels across diverse infrastructure including virtual machines, network gear, and bare metal. Highlight its procedural flexibility for bootstrapping, ordered deployments, and ad-hoc operational tasks. Third, compare operational overhead directly: Kustomize overlays can create deep inheritance hierarchies that become brittle beyond three to four environments, while Ansible playbooks require careful variable precedence management and can suffer from idempotency gaps or hidden state. Fourth, discuss the skill matrix: GitOps demands strong Git fluency and Kubernetes expertise; Ansible requires YAML playbook mastery and SSH key management but no cluster-specific knowledge. Fifth, address blast radius and recovery patterns: GitOps changes are pulled by the cluster, limiting direct production access and enabling fast reversion, whereas Ansible pushes changes, which can be faster for emergency fixes but increases direct touchpoints and risk.
The mistakes people make
Claiming GitOps eliminates all configuration drift ignores that runtime secrets and external cloud state can still diverge from the repository. Saying Ansible cannot implement GitOps-style workflows is false; it simply lacks native continuous drift reconciliation. Advocating one tool for every layer without acknowledging that Kubernetes-only shops benefit from Kustomize while hybrid VM and container estates often need both tools in tandem. Ignoring the secret management gap in plain GitOps, which forces teams to adopt external secrets operators, sealed secrets, or vault integrations that add their own complexity. Failing to mention that Ansible push models can break down at thousands of nodes without careful fork tuning.
What usually comes next
How would you manage secrets in a GitOps workflow without storing plaintext in Git? Describe a scenario where an imperative Ansible playbook is safer than a declarative rollout. How do you prevent overlay sprawl when supporting ten or more environments? What is your strategy for testing Kustomize renders or Ansible playbooks before production deployment? When would you combine both approaches in a single platform? How do you handle secrets rotation in each model?
A concrete example
A platform team supporting five Kubernetes clusters across dev, staging, and production uses Kustomize bases and overlays stored in a single repository. A developer changes a replica count in the production overlay, opens a pull request, and a CI pipeline runs kustomize build to validate the rendered manifests. After merge, ArgoCD detects the drift and syncs the cluster within thirty seconds. For the underlying node OS hardening and NTP configuration, the same team uses Ansible because those tasks target virtual machine instances outside Kubernetes. They keep Ansible playbooks in a separate repository and run them via AWX on a weekly schedule to ensure compliance baselines, accepting that drift between runs is possible and detected by periodic scans. If a critical kernel parameter must change immediately, they use an Ansible ad-hoc command rather than waiting for the GitOps reconcile loop.
Interview question
A team needs continuous drift detection for Kubernetes and configuration management for VMs and network gear with immutable audit trails. Which approach fits best?
- a.Use Kustomize overlays for all infrastructure since GitOps eliminates all drift across VMs and external cloud state.
- b.Use Ansible for both Kubernetes and network gear to avoid brittle Kustomize inheritance hierarchies beyond three or four environments.
- c.Use Ansible for everything because it provides native continuous drift reconciliation and works agentlessly across all infrastructure types.
- d.Use GitOps with Kustomize for Kubernetes and Ansible for VMs and network gear.Correct
Why? this is the answer
The card states that hybrid VM and container estates often need both tools in tandem, using GitOps for Kubernetes drift detection and Ansible for diverse infrastructure. Option B is tempting because Kustomize overlays do become brittle beyond three to four environments, but abandoning GitOps sacrifices the required continuous drift detection and immutable audit trails for Kubernetes.
Just read this? Test yourself on what you have been reading.
Read the original → cloud.google.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on gitops — each one lists the topics its interview covers.
See open roles