TL;DR: In push, CI runs the deploy, so CI holds credentials for every cluster it can reach. In pull, an in-cluster agent reconciles from Git and the cluster reaches out, so CI can avoid holding cluster credentials. CI access to the trusted Git branch or artifact registry still provides a route to production; protect promotion and artifact integrity separately.
How to approach it
Give the credential direction in one sentence, since it is the mechanical difference. Then be honest about what pull costs, because an answer with no downside reads as advocacy.
A strong answer
Push is the conventional model. The pipeline builds, then runs kubectl apply or helm upgrade. For that it needs a kubeconfig with rights to change the cluster, stored in the CI system's secret store. Multiply by environments and clusters and your CI platform now holds the keys to every environment you operate.
That concentration is the problem. CI systems execute arbitrary code from your repositories by design, which makes them a high-value target and a large attack surface: a malicious dependency in a build script, a compromised action, a pull request from a fork that triggers a privileged workflow. If any of those succeed, the attacker has production credentials rather than merely a build environment.
Pull inverts the direction. An agent per cluster can reconcile Git using local permissions. Central Argo CD installations can also manage remote clusters, in which case the central controller holds their access credentials. With the per-cluster model, the agent connects outward to Git and CI needs no route to the cluster API. CI can build an artifact and propose a digest update, but unrestricted writes to the deployment branch still allow it to deploy malicious workloads. Require trusted promotion reviews and restrict the controller’s resource permissions.
Three further consequences worth naming.
Continuous reconciliation, not one-time apply. A push pipeline applies once and stops caring, so a manual change made during an incident survives silently. A pull agent detects drift according to its watch or refresh interval and configured reconciliation policy, which means the repository stays a true description of the cluster rather than a description of the last deploy.
Multi-cluster stops scaling badly. Push requires credentials per cluster held centrally. Pull adds an agent per cluster pointing at the same repository, and adding the fiftieth cluster is the same work as the second.
Audit becomes ordinary. The desired state has a Git record. Enforced branch rules supply review; a commit alone proves neither approval nor the identity of the runtime actor. Correlate Git history with controller and cluster audit logs to establish who requested a change and what actually executed.
Now the costs, honestly. There is an indirection: a merge does not deploy, a controller notices and then deploys, so the feedback loop is longer and debugging spans two systems. Secrets need a separate answer, because they cannot sit in Git in plaintext, so you add External Secrets, Sealed Secrets or SOPS. Deleting resources requires pruning to be enabled deliberately, and enabling it carelessly is how people delete production. And promotion between environments becomes a repository workflow you have to design, which both push and pull deployments must define explicitly.
What interviewers probe next
"How do you handle emergency changes?" Break glass by editing the repository, which is still fast. Direct cluster access exists for genuine emergencies and is audited and time-limited, not routine.
"Argo CD or Flux?" Argo CD for the UI and multi-tenancy features, Flux for a lighter, more composable, controller-per-concern design. Either is defensible; having a reason is what matters.
"Does the agent's own permission concern you?" Yes, it is powerful within its cluster. Scope it per namespace where you can, and treat the repository it watches as production-critical, because write access to that repository is now write access to the cluster.
Common mistakes
Answering "Git is the single source of truth" without the credential argument, which is the concrete security benefit.
Ignoring the secrets problem, which every real adoption meets in the first week.
Enabling automated pruning without understanding it, which turns a bad merge into a deletion.