Gitops Principles practice questions

Automated reconciliation

Why wrong: This refers to the controller's action, not the review process.

Continuous drift detection

Why wrong: Drift detection identifies discrepancies, it does not enforce the review process.

Declarative desired state

Why wrong: Declarative state defines the 'what', but not the workflow for approval.

Faster deployment of hotfixes directly to production

Why wrong: Hotfixes should still go through the GitOps pipeline.

Automated conversion of Docker images to YAML

Why wrong: This is not a function of Git.

Increased server-side storage capacity

Why wrong: Git is for configuration, not storage.

Grant the cluster node broad read access to all public repositories.

Why wrong: This is overly permissive and insecure.

Use an environment variable in the Argo CD container deployment manifest.

Why wrong: Environment variables are less secure than secrets and harder to manage for multiple repositories.

Hardcode the credentials in the Application manifest.

Why wrong: Hardcoding credentials violates security best practices.

Git commit hook triggers

Why wrong: Hooks run before or after events, they do not reconcile state.

Kubernetes admission controllers

Why wrong: Admission controllers validate or mutate requests, they don't reconcile drift.

Manual refresh button

Why wrong: This requires human interaction.

The developer's local kubectl client.

Why wrong: The developer should not have direct write access in a true GitOps workflow.

The CI/CD pipeline pushes updates to the cluster.

Why wrong: A push-based model would initiate from outside; pull-based initiates from within.

The Git server pushes changes to the cluster webhook.

Why wrong: Pushing to webhooks is a characteristic of push-based models.

The cluster ingress controller

Why wrong: Ingress controllers manage traffic, not state reconciliation.

The Argo CD API server

Why wrong: The API server handles requests from the CLI and UI but does not perform the reconciliation loop.

The Git webhook listener

Why wrong: The webhook listener only triggers syncs when a commit is pushed to Git.

The controller ignores the change until the next git commit.

Why wrong: GitOps controllers provide continuous reconciliation, not just event-driven updates.

The system issues an alert but does not modify the cluster.

Why wrong: GitOps controllers aim to actively reconcile, not just monitor.

The manual deletion is permanently synced to the Git repository.

Why wrong: GitOps ensures the repository is the source of truth, not the cluster state.

Manual approval is required for all production deployments

Why wrong: GitOps promotes automation, though manual gates are optional, they are not a core principle.

Software must be delivered using push-based CI/CD pipelines

Why wrong: GitOps emphasizes pull-based reconciliation over push-based deployment.

Running a pipeline to execute terraform apply on demand

Why wrong: While Infrastructure as Code, without persistent reconciliation, this is not GitOps.

Writing a bash script to update image tags on all clusters

Why wrong: This is an imperative approach.

Using kubectl edit to modify running pod replicas

Why wrong: This is manual, imperative intervention.

The repository pulls changes from the cluster.

Why wrong: The repository is the source, not the receiver.

The cluster is pulled into the development network.

Why wrong: This is a networking concept, not GitOps.

Developers push code to the cluster API.

Why wrong: That is a push-based model.

External systems pull logs from the cluster.

Why wrong: This relates to logging, not state management.

To increase the storage capacity of the cluster.

Why wrong: Immutability is for configuration integrity, not storage management.

To allow the cluster to delete resources at will.

Why wrong: Immutability prevents unauthorized changes to history.

To force developers to use a specific IDE.

Why wrong: GitOps does not mandate IDE usage.

The controller alerts the administrator but takes no action.

Why wrong: Most GitOps tools offer automated self-healing options.

The Git repository is updated to reflect the new cluster state.

Why wrong: The Git repository is the immutable source; it is never overwritten by cluster drift.

The cluster ignores the Git repository until a new commit is pushed.

Why wrong: Continuous reconciliation constantly checks against the source.

Role-Based Access Control (RBAC).

Why wrong: While RBAC helps, the fundamental GitOps feature for this is automated reconciliation.

External DNS.

Why wrong: External DNS manages domain records, not resource configurations.

CI/CD pipeline triggers.

Why wrong: Pipelines typically handle deployments, not runtime cluster drift.

Install a plugin that logs all kubectl commands.

Why wrong: Logging alerts you after the fact, it does not prevent the change.

Add a firewall rule to block kubectl.

Why wrong: Firewalls cannot easily distinguish between kubectl and controller traffic.

Disable the Kubernetes API server.

Why wrong: The API server is required for the controller to function.

Using an interactive terminal to manage resources.

Why wrong: Terminal usage is imperative and manual.

Providing a script to update resources.

Why wrong: Scripts are imperative, defining steps, not the state.

Requiring manual approval for every reconciliation.

Why wrong: Approval is a workflow choice, not a defining characteristic of declarative state.

Kubectl allows editing the live state without record.

Why wrong: While true, the key advantage is the Git history itself.

Git is faster than kubectl for large clusters.

Why wrong: Performance is not the primary reason for auditing benefits.

The cluster automatically emails admins when kubectl is used.

Why wrong: This is not a default feature of Kubernetes.

It sets the password for the Git repository.

Why wrong: Credentials are managed via Kubernetes secrets.

It configures the frequency of the container health checks.

Why wrong: Health checks are part of the resource status probes.

It determines which Git branch is used for the deployment.

Why wrong: Branch configuration is part of the application source, not the sync policy.

A tool that converts YAML to JSON.

Why wrong: This is a simple utility, not a GitOps operator.

A database that stores configuration history.

Why wrong: Git itself acts as the storage; the operator is the logic.

A human user who manually pushes Git commits.

Why wrong: Operators are software agents, not humans.

Improved auditability.

Why wrong: This is a major benefit of GitOps.

Faster recovery from disasters.

Why wrong: GitOps enables rapid reconstruction of the cluster state.

Standardized deployment processes.

Why wrong: This is a core benefit of GitOps.

An audit log from the cluster.

Why wrong: Logs are reactive observations, not intent.

A shell script that installs software.

Why wrong: Scripts are imperative; GitOps prefers declarative definitions.

A live running container.

Why wrong: The container is the actual state, not the desired definition.