Related Practices practice questions

Storing all configurations in a single large YAML file.

Why it fails: This is impossible to manage at scale.

Copying and pasting the entire manifest directory for each environment.

Why it fails: This creates maintenance nightmares and configuration drift.

Ignoring environment differences and using the same values for everything.

Why it fails: Environments often require different resource limits, replicas, or endpoints.

It automates the building of Docker images.

Why it fails: This is the job of the CI system.

It replaces the need for a Git repository.

Why it fails: The Git repository is essential for the operator to function.

It provides a user interface for cluster management.

Why it fails: That is an add-on, not the core function of the operator pattern.

Configure a CI pipeline to run terraform apply only when a manual approval is provided by the operations team.

Why it fails: Manual approvals introduce human bottlenecks and imperative execution, which contradicts the GitOps principle of automated reconciliation.

Execute a scheduled cron job that runs terraform apply.

Why it fails: Cron jobs are imperative and do not provide continuous reconciliation or drift detection.

Use a webhook to trigger a shell script that pulls the latest changes from the main branch.

Why it fails: Push-based webhooks are not inherently declarative and do not handle drift detection or reconciliation effectively.

Because Git stores all application logs.

Why it fails: Git holds declarative configuration and version history, not runtime telemetry; logs belong in a logging backend such as Loki or Cloud Logging. Git qualifies as source of truth because the desired cluster state is declared and versioned there, enabling reconciliation.

Because it is the only tool that supports branching.

Why it fails: Git's role as source of truth stems from storing the declarative desired state that controllers continuously reconcile, not from branching alone; many version control systems support branching. Branching is genuinely useful for feature isolation and pull-request review workflows, which is why it appears relevant, but it is not the mechanism that makes Git authoritative in GitOps.

Because Git automatically runs the applications.

Why it fails: Git stores desired-state manifests; it does not execute workloads. The tempting confusion is that GitOps controllers such as Argo CD or Flux reconcile cluster state from Git, but Git itself only versions and diffs declarative configuration, never runs applications.

To avoid using cloud provider dashboards.

Why it fails: Avoiding dashboards is a side effect, not the purpose; console access remains available for read-only inspection and troubleshooting. Infrastructure as Code exists to make infrastructure declarative, version-controlled and reproducibly deployed, so it is tempting because GitOps does route all changes through Git rather than manual console edits.

To generate cost reports for the finance department.

Why it fails: Cost reporting is the domain of billing tools such as AWS Cost Explorer or Kubecost, which read resource tags and usage data. Infrastructure as Code defines and versions the desired state of infrastructure declaratively, so it is tempting only because tagged resources happen to feed those reports.

To allow developers to log into servers and make changes.

Why it fails: Direct server logins and manual changes are precisely what GitOps prohibits, since they bypass version control and create undocumented drift. Infrastructure as Code is tempting here only because it does replace some hands-on administration, but its purpose is declarative, auditable, peer-reviewed change through Git.

Only when an auditor requests a security report.

Why it fails: Auditor-triggered reporting is periodic and manual, so insecure configuration reaches the cluster long before any scan runs. It is tempting because audit evidence is a genuine compliance requirement, and would be correct for attestation reporting, not for gating commits before they are deployed.

By running an automated script to delete pods that fail a security check.

Why it fails: Deleting failing pods is reactive remediation after the workload already reached the cluster, so insecure configuration is not prevented. It is tempting because automated cleanup enforces a security baseline continuously, and would be correct for handling drift or runtime violations once preventive scanning is already in place.

As a post-deployment check using a Kubernetes admission controller.

Why it fails: An admission controller runs after manifests are committed and synced, so it blocks at deploy time rather than preventing insecure configuration entering the repository. It is tempting because admission control genuinely enforces policy at the cluster boundary, and would be correct for runtime guardrails alongside, not instead of, pre-merge scanning.

Execute Terraform via a CI job that triggers Argo CD after completion.

Why it fails: A CI job triggering Argo CD keeps the dependency imperative and outside Git, so Argo CD's reconciliation loop cannot verify infrastructure readiness before syncing manifests. It tempts teams already using CI pipelines, which suits sequential build-test-deploy workflows where GitOps reconciliation is not the delivery model.

Manually trigger Terraform runs before pushing new app manifests to Git.

Why it fails: Manual triggering breaks GitOps: the pipeline state lives outside Git, so Argo CD cannot reconcile infrastructure and app changes atomically, and drift goes undetected. It tempts teams wanting a human gate before provisioning, which suits change-controlled environments where approvals, not automation, govern releases.

Embed Terraform binary execution within a K8s deployment container.

Why it fails: Running Terraform inside a cluster container grants the pod cluster credentials and state access, violating least privilege and creating a circular dependency, since the cluster itself is provisioned by Terraform. It tempts those consolidating tooling into Kubernetes, which suits in-cluster operators managing resources that already exist.

Pushing binary artifacts to a server via SSH.

Why it fails: SSH artifact pushing describes traditional imperative deployment, which GitOps replaces; the CD tool instead pulls and reconciles manifests from Git against live cluster state. SSH delivery bypasses Git as the single source of truth, defeating the GitOps model.

Pushing images to a container registry after a build.

Why it fails: GitOps CD tools continuously reconcile cluster state against a Git-declared desired state; they do not push images. Registry pushes belong to the CI build stage, which is where this task correctly sits. The option confuses CI's artefact publication with CD's reconciliation role.

Generating test reports for the QA team.

Why it fails: Test reporting belongs to the CI stage, where builds and automated tests run; the CD tool's GitOps role is reconciling cluster state with the desired state declared in Git. Report generation never touches the deployment reconciliation loop.

The container registry is unreachable during a new image rollout.

Why it fails: An unreachable registry blocks image pulls during rollout, leaving pods in ImagePullBackOff, but the declared manifests still reconcile; drift concerns configuration divergence, not image availability. Registry connectivity is the right focus when diagnosing failed deployments, not when comparing live objects against Git.

The Git repository contains syntax errors in the YAML files.

Why it fails: Malformed YAML causes Flux's kustomize-controller to fail applying the manifests, so the cluster retains its previous state rather than drifting from a valid desired state. Syntax validation belongs in CI or pre-merge checks; drift specifically means applied configuration diverged from what Git declares.

The CI pipeline failed to run tests.

Why it fails: Flux reconciles cluster state from Git; a failed CI test pipeline halts nothing in the reconciliation loop, so drift persists regardless of test outcomes. CI pipelines are the right control for gating merges, not for explaining divergence between committed manifests and live cluster objects.

Conducting quarterly penetration tests.

Why it fails: Quarterly penetration testing is periodic assurance performed outside the delivery pipeline, so it cannot gate or secure individual commits and merges. It is tempting because penetration testing is a recognised security activity, and it would suit an annual compliance or assurance programme, but DevSecOps requires automated checks embedded in the pipeline itself.

Requiring a manual sign-off by a security officer for every deployment.

Why it fails: A manual security sign-off per deployment reintroduces a human gate that halts continuous delivery, contradicting the automated security checks DevSecOps embeds in the pipeline. It is tempting because segregation-of-duties approval is a valid control in regulated release processes, but it belongs to change-management workflows rather than GitOps automation.

Storing secrets in plain text in the Git repository.

Why it fails: Plain-text secrets in Git expose credentials to anyone with repository read access and persist in commit history, directly violating DevSecOps practice. It is tempting as a quick way to make pipeline variables available to runners, and it would only be defensible for genuinely non-sensitive placeholder values, never real deployment credentials.

Using bash scripts triggered by a Jenkins build job to update environment variables.

Why it fails: Bash scripts run by Jenkins perform imperative commands that mutate environment variables without recording a declarative desired state in Git, so drift cannot be reconciled. This approach suits legacy build automation, whereas GitOps requires committed manifests that an agent continuously enforces.

Directly editing deployments via the 'kubectl edit' command.

Why it fails: Directly editing live resources with kubectl edit mutates cluster state imperatively, bypassing Git as the single source of truth, so no desired-state definition is stored or reconciled. It is tempting for quick hotfixes, but GitOps requires committed manifests that an agent continuously reconciles.

Using an Ansible playbook to perform one-off configuration changes on existing servers.

Why it fails: Ansible playbooks execute procedural tasks against existing servers, so one-off changes are imperative actions rather than a stored desired state reconciled from Git. Ansible suits configuration management or bootstrapping, but GitOps needs declarative manifests held in version control and continuously reconciled.

Deleting the Git repository after each deployment to prevent tampering.

Why it fails: Deleting the repository after each deployment destroys the declarative desired-state source that GitOps agents continuously reconcile against. It is tempting as a tamper-prevention measure, which suits immutable audit archives, but GitOps requires the repository to persist as the single source of truth for every environment.

Using a single 'main' branch that is pushed to all environments simultaneously.

Why it fails: A single main branch pushed to every environment simultaneously removes the per-environment state that GitOps reconciles, so promotion and rollback cannot be tracked. It is tempting because trunk-based development speeds integration, which suits a single environment or continuous delivery to one target, but not distinct environment states.

Creating a new repository for every single deployment.

Why it fails: Creating a new repository per deployment fragments the desired-state history, so GitOps controllers cannot diff or reconcile drift against a stable source. It is tempting because per-deployment isolation aids auditing, which suits one-off artefacts, but GitOps needs environment state held in persistent, versioned branches.

Having the CD operator pull the 'latest' tag directly from the registry.

Why it fails: Pulling 'latest' makes deployments non-deterministic: the operator cannot pin a digest, so rollbacks and audit trails fail, and cached layers may serve stale images. It is tempting because it removes tag-bump commits, and suits local development where reproducibility is not required.

Manually updating the YAML file with the new image tag and committing to Git.

Why it fails: Manual YAML edits break automation and auditability, and human commits cannot keep pace with frequent builds, inviting drift and errors. It is tempting because Git remains the source of truth and works fine for infrequent, hand-curated releases in small teams.

Triggering a shell script to update the cluster state directly from the CI pipeline.

Why it fails: Directly mutating cluster state from CI bypasses Git as the single source of truth, so the operator's reconciliation loop will revert the change or drift undetected. It is tempting because shell scripts feel immediate, and imperative deployment suits pipelines that own the cluster, not GitOps.

It eliminates the need for container registries.

Why it fails: Container registries remain essential for storing and distributing images regardless of deployment model; GitOps references image tags but does not replace registries. The pull-based operator's benefit is in-cluster reconciliation against Git as the source of truth. Eliminating registries would require a different artefact distribution mechanism entirely.

You can use fewer Git branches.

Why it fails: Branch count is unrelated to the pull versus push distinction; both models can use any branching strategy. Pull-based GitOps matters because the operator inside the cluster pulls desired state from Git, enabling drift correction and reduced external cluster credentials. Fewer branches suits trunk-based development, not GitOps.

The CI system runs faster.

Why it fails: Pull-based GitOps does not accelerate CI execution; the operator reconciles cluster state asynchronously from Git, so pipeline duration is unchanged. The actual benefit is continuous drift detection and reconciliation from a declarative source of truth. Faster CI is a goal of pipeline caching or parallelisation, not the pull model.

Store them in base64 encoded format in plain Git.

Why it fails: Base64 is reversible encoding, not encryption, so anyone with repository read access recovers the plaintext keys directly from Git history. It is tempting because committing encoded values keeps manifests self-contained and avoids external dependencies, which suits non-sensitive configuration data where secrecy is not required.

Leave them out of Git and manually inject them via kubectl.

Why it fails: Manual kubectl injection leaves credentials outside any declarative source, so the GitOps controller cannot reconcile or rotate them and drift goes undetected. It is tempting because it keeps secrets out of Git, and it would suit one-off imperative debugging, not a continuously reconciled pipeline.

Upload them to the cluster via the cloud provider's console.

Why it fails: Console uploads bypass Git entirely, so the declared state never reconciles with the cluster and secrets drift undetected on the next sync. It is tempting because the console offers a quick manual path for injecting values during initial bootstrap, which suits one-off lab clusters rather than declarative GitOps pipelines.

Configuration as Code is only for databases.

Why it fails: Configuration as Code applies to any system settings, including applications, servers and network devices, not databases alone. It is tempting because database schema and parameter management is a common use case, but that is one instance rather than the defining scope of the practise.

Config as Code is always written in YAML.

Why it fails: YAML is a common serialisation format but not a requirement; Configuration as Code also appears as JSON, TOML, HCL or INI. It is tempting because GitOps examples frequently show YAML manifests, yet the defining characteristic is versioned declarative configuration, not the file syntax.

They are the same thing.

Why it fails: They are distinct: Infrastructure as Code provisions and manages infrastructure resources declaratively, while Configuration as Code manages application or system settings. It is tempting because both store declarative definitions in Git, yet conflating them ignores that they target different layers of the stack.

Terraform

Why it fails: Terraform manages infrastructure state declaratively but does not reconcile Kubernetes manifests or run Kustomize overlays natively; its Kubernetes provider applies resources without GitOps drift correction. It is tempting because both are declarative Git-stored tooling, yet Terraform targets infrastructure provisioning, not manifest reconciliation.

Ansible

Why it fails: Ansible executes imperative playbooks over SSH; it has no native Kustomize rendering or continuous reconciliation loop, so drift is not corrected automatically. It is tempting because Ansible can template manifests, but it suits configuration management and bootstrapping, not GitOps manifest synchronisation.

Jenkins

Why it fails: Jenkins runs imperative CI pipelines and shell steps; it has no native Kustomize or GitOps reconciliation controller, so drift is not continuously corrected. It is tempting because Jenkins can invoke kubectl and kustomize build, but that is scripted deployment, not native GitOps integration.

Delete the pods and let the operator recreate them.

Why it fails: Deleting pods only triggers the operator to recreate them from the same failing manifest, reproducing the fault. Pod deletion suits clearing crashed or stuck pods under a healthy revision; rollback requires reverting the Git commit so the operator reconciles to the prior working state.

Stop the GitOps operator to prevent it from correcting the state.

Why it fails: Stopping the operator halts reconciliation but leaves the broken revision deployed and the desired state unchanged in Git, so drift persists. Pausing an operator suits planned maintenance windows, not rollback; reverting the Git commit is what actually restores the previous working state.

Run 'kubectl rollout undo' on the deployment.

Why it fails: Running kubectl rollout undo mutates the cluster directly, so the GitOps operator reconciles the live state back to the failing manifest still declared in Git. Rollback belongs in Git by reverting the commit; imperative kubectl commands suit non-GitOps clusters without a reconciling controller.

It causes high latency in the cluster.

Why it fails: Polling adds registry query overhead, not cluster-wide latency; the actual risk is that 'latest' resolves to different digests, so deployments are non-reproducible and rollbacks unreliable. Latency is tempting because polling is periodic network I/O, and would be correct if the operator polled at an excessive interval against a slow registry.

The GitOps operator cannot detect changes.

Why it fails: Polling reads the registry tag and detects digest changes, so a moving 'latest' tag is precisely what it can observe; the real risk is non-deterministic, unreproducible deployments. Claiming detection failure is tempting because tags look immutable, and would be correct for a GitOps operator that reconciles only committed manifests without registry polling.

It consumes too much disk space.

Why it fails: Image polling compares registry digests, so a moving 'latest' tag triggers repeated pulls and redeployments; storage consumption is unaffected because layers are cached and deduplicated. Disk-space concerns are tempting when registries accumulate many tags, and would be correct if retention policies were the actual issue.

Secrets are encrypted in the Git repo.

Why it fails: Encrypting secrets in Git is expected practice, not a GitOps violation; sealed secrets and SOPS are standard. It is tempting to flag because plaintext credentials in a repository would break the declarative, auditable model, but encryption preserves the Git-as-source-of-truth workflow.

The cluster automatically reconciles changes pushed to Git.

Why it fails: Automatic reconciliation of Git commits is the defining GitOps pull-based mechanism, so it confirms adherence rather than deviation. It is tempting to flag because automation can look like uncontrolled drift, yet the controller continuously converges cluster state to the declared desired state in Git.

Developers use PRs to propose changes to the environment.

Why it fails: Pull requests are the standard GitOps change mechanism, so this indicates compliance rather than deviation. True GitOps breaks down when changes are applied directly to the cluster, bypassing the Git repository as the single source of truth. PR-based review would be expected in a correctly implemented GitOps workflow.