GitOps: Your Git Repo is the Single Source of Truth
GitOps makes a Git repo the single source of truth for your infrastructure's desired state. An automated process makes production match what's declared in Git, enabling continuous deployment.
Why it exists
GitOps was created to manage the complexity of continuous deployment for cloud-native applications. Instead of relying on fragile, manually triggered scripts, it provides a reliable, auditable, and developer-centric way to operate infrastructure by using tools developers already know and trust, like Git.
The mental model
Think of GitOps as cruise control for your application infrastructure. You don't manually deploy; you declare a desired state in a Git repository. An automated system then constantly works to make the live environment match that state. Your Git history becomes a complete, auditable transaction log of every change ever made to your production environment.
How it works
The system revolves around a Git repository that contains declarative descriptions of your desired infrastructure, such as Kubernetes YAML files. An automated agent constantly compares the state described in the repo's main branch to the actual state of the live environment. When a difference is detected (like a merged pull request), the agent takes action to reconcile the two. This process can be implemented in two ways. A push-based approach uses a traditional CI/CD pipeline to push changes into the cluster. The preferred pull-based approach uses an agent running inside the cluster to pull changes from the repository, which is more secure as it avoids exposing cluster credentials externally.
When to use it
Use GitOps for faster, more frequent, and safer deployments in cloud-native environments. It provides powerful benefits like easy rollbacks (simply 'git revert' a commit), simplified credential management (developers don't need direct cluster access), and self-documenting systems where the repo provides a perfect audit trail. This transparency also helps share infrastructure knowledge across the entire team.
When not to use it
GitOps depends entirely on declarative configuration. If your system's state cannot be described in files and stored in Git, GitOps is not a good fit. Additionally, be cautious with the push-based deployment model. While possible with tools like Jenkins or CircleCI, it's a weaker pattern that requires giving your CI system powerful, high-risk credentials to access your production environment. The pull-based model is strongly preferred for its superior security posture.
One canonical example
A developer needs to update a service's container image. They open a pull request in the environment configuration repository, changing the image tag in the relevant Kubernetes deployment manifest. After code review, the PR is merged to the main branch. An agent running inside the Kubernetes cluster detects the change in the Git repo. It automatically pulls the updated manifest and applies it, causing Kubernetes to perform a rolling update of the service. The entire operation—from PR to deployment—is versioned and auditable in Git.
Interview question
Which of the following is the primary security benefit of adopting a pull-based GitOps deployment model?
- a.It prevents the exposure of production cluster credentials to external CI/CD pipelines or systems.Correct
- b.It eliminates the need for any external CI/CD system to interact with the production cluster.
- c.It allows for easier rollback of changes by simply reverting a commit in the Git repository.
- d.It ensures that all infrastructure changes are thoroughly reviewed via pull requests before deployment.
Why? this is the answer
The card states that the pull-based model is more secure as it "avoids exposing cluster credentials externally," contrasting it with the push-based model that "requires giving your CI system powerful, high-risk credentials." Option D describes a general benefit of using Git for configuration, not a specific security advantage of the pull-based model.
Just read this? Test yourself on what you have been reading.
Read the original → gitops.tech
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 git — each one lists the topics its interview covers.
See open roles