Gitops Patterns practice questions

Pod CPU usage

Why it fails: CPU usage is a resource metric, but Flagger typically focuses on service-level objectives like latency and error rates for rollbacks.

Number of running replicas

Why it fails: This relates to deployment scale, not the success of the traffic shift.

Git commit hash parity

Why it fails: Git commit parity is for synchronization, not for behavioral traffic analysis.

Hardcoding environment-specific image tags in the base templates

Why it fails: Hardcoding in the base violates the overlay principle.

Storing all environment manifests in a single monolithic flat directory

Why it fails: This leads to configuration drift and makes promotion difficult.

Duplicating all YAML files for every environment

Why it fails: Duplication violates the DRY principle and makes maintenance error-prone.

Use the 'ignoreDifferences' field for the child application manifests

Why it fails: IgnoreDifferences prevents synchronization rather than enabling discovery.

Set the sync policy to 'manual' and use a post-sync hook

Why it fails: Hooks are for orchestration, not for dynamic application discovery.

Configure a manual webhook trigger on the root application

Why it fails: Manual triggers defeat the purpose of automated GitOps workflows.

Manually update the container image using kubectl edit.

Why it fails: Manual changes bypass the GitOps reconciliation loop and will be overwritten.

Use a different container registry for production.

Why it fails: Registry location does not guarantee image consistency or content addressability.

Change the image tag to 'production' in the deployment manifest.

Why it fails: Mutable tags like 'production' can be overwritten, breaking GitOps immutability principles.

Store secrets in Git as plain text and use a private repository.

Why it fails: Storing secrets in plain text in Git is a major security violation.

Use Helm post-render hooks to inject secrets at runtime.

Why it fails: Post-render hooks are not designed for secure secret management and occur outside the GitOps state definition.

Enable 'AllowClusterResources' in the global configuration.

Why it fails: This broad permission would expose secrets to all clusters, violating the security requirement.

The parent application is not using a Helm chart source.

Why it fails: App-of-Apps pattern functions perfectly with Kustomize or standard YAML.

The Argo CD API server has exceeded its connection limit.

Why it fails: This would cause a 'Connection Refused' or '503' error, not a stuck sync state.

The parent application is missing the sync-policy configuration.

Why it fails: Missing sync policy results in no automatic sync, not a stuck sync.

Storing all YAML in a single massive monorepo.

Why it fails: A large monorepo creates performance issues for the Git provider and the controller.

Manual kubectl context switching.

Why it fails: This is not a GitOps pattern and is prone to human error.

Centralized Cluster Management.

Why it fails: This creates a bottleneck at the central controller level.

The need for a dedicated team just to write Dockerfiles.

Why it fails: Dockerfiles are typically handled by developers, not the GitOps team.

Increased dependency on internet speed.

Why it fails: GitOps syncs are usually small metadata fetches.

They replace the need for the CI/CD pipeline.

Why it fails: They complement, not replace, CI/CD.

They run as standard pods in the cluster.

Why it fails: They are managed as Jobs or Pods but are distinct from application pods.

Storing all secrets in plain text in the root folder.

Why it fails: This is a severe security violation.

Hardcoding all cluster IPs in a single global config.

Why it fails: This is not a tenant-based organization.

The root application lacks the 'self-heal' parameter in its SyncPolicy.

Why it fails: Self-heal on the root only synchronizes the Application objects themselves, not necessarily the child resources.

The root application is using a recursive sync interval that is too high.

Why it fails: Sync intervals affect frequency, not the ability to converge to a specific state.

Argo CD requires a Project-level permission override for nested applications.

Why it fails: Permissions are handled via AppProject objects, which are independent of the nesting level.

The 'syncPolicy' field.

Why it fails: SyncPolicy controls how the application is deployed, not how it is discovered.

The 'ignoreDifferences' field.

Why it fails: This field is for drift management, not path discovery.

The 'AppProject' filter.

Why it fails: AppProjects are for RBAC, not for generating application lists.

Git-Branch-Per-Environment

Why it fails: Git-Branch-Per-Environment stores environment configuration in divergent branches, so promoting a release requires merging rather than updating a single declarative source. It is tempting as a familiar branching model, but GitOps progressive delivery relies on one branch plus Kustomize or Helm overlays to keep environments synchronised.

Argo Workflows

Why it fails: Argo Workflows orchestrates general container pipelines, not the progressive rollout of application versions across environments. It is tempting because it runs inside Kubernetes alongside Argo CD, but progressive delivery needs Argo Rollouts' canary and blue-green strategies with metric analysis, which Workflows does not provide.

Disabling the GitOps controller on the management cluster.

Why it fails: The controller is required to manage the remote clusters.

Using the same Git repository for all clusters.

Why it fails: Using the same repo is a pattern, but does not provide isolation.

Enabling 'automated.prune' on all applications.

Why it fails: Pruning is for drift management, not isolation.

Use Kustomize remote bases to pull a shared chart from a Git repository and apply a patch that contains the hostname and replica count for each environment.

Why it fails: Kustomize remote bases can share configuration, but each preview environment still requires its own patch file containing the hostname and replica count. That reintroduces a per-environment artifact, which is exactly what the scenario asks to avoid. Kustomize also does not parameterize Helm values in the same way, so it does not meet the requirement for a single templated values source.

Store the rendered Kubernetes manifests for each preview environment directly in Git and apply them with kubectl from a CI pipeline.

Why it fails: Committing fully rendered manifests for each ephemeral environment creates a large number of static files and abandons the declarative templating benefit of Helm. Applying with kubectl from CI is a push model, not a GitOps pull reconciliation, so it does not continuously enforce the desired state. This does not achieve the goal of avoiding a separate values file per environment.

Create a separate Helm chart for each preview environment, with the hostname and replica count hard-coded in the chart templates.

Why it fails: Duplicating the entire chart for every preview environment multiplies maintenance and drift risk. A change to the application template must be repeated in every chart, and hard-coded values are not reusable. This approach does not use a shared chart with parameterization, so it fails to reduce the number of artifacts that must be maintained as environments are created and destroyed.

Set up Argo CD notifications to alert the team when a sync fails, and manually revert the Git commit.

Why it fails: Notifications and manual revert rely on human intervention, which does not provide automatic rollback. This approach is error-prone and slow, contrary to the requirement for automatic rollback. It also does not enforce approval before deployment, as the sync would already have occurred.

Use Argo CD's automated sync policy with self-heal enabled to automatically revert manual changes and reconcile to the desired state.

Why it fails: Automated sync with self-heal ensures the cluster state matches Git, but it does not provide a review and approval gate before deployment. It also does not automatically roll back on health failure; it will continuously try to sync. This option addresses drift correction, not the approval or rollback requirements.

Enable Argo CD's automated sync with the 'prune' option and a retry strategy to handle transient failures.

Why it fails: Prune and retry help manage resource cleanup and transient errors, but they do not enforce approval gates or automatic rollback on health failure. Retry will attempt to sync again, but if the application is unhealthy, it may not roll back to a previous version. This does not meet the stated requirements.

Modify the global ConfigMap in the Argo CD namespace

Why it fails: The argocd-cm ConfigMap holds global Argo CD settings, not per-cluster credentials, so editing it does not register a remote cluster. It is tempting because ConfigMaps configure Argo CD behaviour, but cluster access requires a dedicated secret containing the server URL and authentication token.

Add the cluster URL to the Git repository manifest

Why it fails: A Git manifest cannot authenticate to a cluster; Argo CD reads credentials from a Kubernetes secret in its own namespace, not from repository YAML. It is tempting because GitOps declares desired state in Git, but cluster registration requires a secret object, not a manifest entry.

Manually create a Kubernetes secret in the remote cluster

Why it fails: Argo CD stores remote cluster credentials in its own namespace, not the remote cluster, so a secret created there is never read. It is tempting because Kubernetes secrets hold credentials, but Argo CD requires a cluster secret in its namespace containing the API server URL and token.

The analysis template lacks the 'weight' parameter

Why it fails: The weight parameter belongs to canary analysis traffic splitting, not to the promotion step that switches the primary service selector. It is tempting because weight controls how much traffic reaches the canary, which is the correct answer when the canary receives no traffic during analysis rather than after completion.

The Flagger controller is in 'paused' mode

Why it fails: Paused mode halts analysis and promotion entirely, so the analysis would never complete successfully in the first place. It is tempting because pausing is a real Flagger control that freezes rollout progress, and it would be the correct answer if the symptom were a stalled canary analysis that never advances.

The canary resource is missing a 'host' definition

Why it fails: The host field configures ingress routing for the canary, not the primary service selector that Flagger updates on promotion. It is tempting because a missing host leaves external requests unroutable, which is the correct answer when traffic fails to reach the canary through an ingress controller rather than the primary after analysis.

Install Argo CD control plane components on every edge cluster

Why it fails: Hub-and-spoke runs the Argo CD control plane only on the hub; edge clusters need just a ServiceAccount and RBAC for the hub to deploy into them. It is tempting because each cluster does need credentials, but installing full control planes per edge is the opposite of this pattern.

Configure the 'server.enable.proxy' flag in the hub cluster

Why it fails: No such server.enable.proxy flag exists in Argo CD; hub-and-spoke uses the cluster secret's proxy URL or the argocd cluster add command. It is tempting as a plausible-sounding toggle, but the actual mechanism is registering spoke API server endpoints as cluster secrets.

Hardcoding environment names inside the main deployment file

Why it fails: Hardcoding environment names into the shared deployment file couples staging and production to one manifest, so promotion cannot vary values per environment without editing that file. It is tempting because embedding literals works for a single-environment deployment, where no per-environment substitution is required.

Dynamic shell scripting in the CI pipeline

Why it fails: Shell scripting in the CI pipeline mutates configuration outside Git, so the applied state diverges from the declared manifests and cannot be audited or reverted through commits. It is tempting because pipelines already run commands, which works when configuration is generated rather than declared.

multiple_choice

Why it fails: Invalid question type provided.

Copy-pasting YAML files across folders

Why it fails: Copy-pasting YAML across folders duplicates manifests, so drift between staging and production goes undetected and no single source of truth drives promotion. It is tempting because manual copying appears to separate environments, which suffices only when configurations never change after the initial copy.