Free practice · No sign-up required
15 questions with answer explanations. Choose an answer below to begin.
What is the primary purpose of GitOps in modern application delivery?
Understand the foundational concept and goals of GitOps
0/15 answered · Bookmark questions to review later. Focus the practice area to use keys 1–9 and Enter.
Learn by doing
Use official documentation and hands-on labs to work through topics you missed.
Application examples from the Kubernetes project for practicing manifests and application behavior in a cluster.
Try it: Use a disposable cluster. Read a simple application's manifests, predict which Pods its Service selects, then change a label and use kubectl to diagnose the resulting connectivity problem.
Source is free. A local cluster uses your computer; hosted clusters may incur charges.
Guided tutorials for learning Kubernetes behavior and building practical skills beyond multiple-choice recall.
Try it: Complete a basic application tutorial. Repeat the task without the walkthrough, then explain the difference between declared configuration and observed cluster state.
Documentation is free. Your chosen cluster environment may have costs.
Prefer to read at your own pace? Work through each question below, then open its answer to check your reasoning. You can link directly to a question or print this reference.
What is the primary purpose of GitOps in modern application delivery?
To use Git as the single source of truth for declarative infrastructure and applications
To store build artifacts in a version-controlled repository
To replace continuous integration with continuous deployment
To manage secrets exclusively through version control
Correct answer
To use Git as the single source of truth for declarative infrastructure and applications
GitOps centers on using Git to declaratively define desired state and automate synchronization. This ensures consistency and traceability. The other options describe related practices but not the core purpose.
Which practice helps ensure that the cluster state matches the desired state defined in Git?
Automated reconciliation
Manual kubectl apply
Periodic backup restoration
Ad-hoc configuration changes
Correct answer
Automated reconciliation
Reconciliation is the process by which a GitOps operator continuously compares the cluster state to the declared state in Git and makes corrections. Manual actions and ad-hoc changes bypass the desired state control.
What is a common benefit of using pull-based deployment over push-based deployment in GitOps?
The operator runs inside the cluster and applies changes only when Git is updated
It requires fewer permissions to access the cluster
It eliminates the need for a version control system
It guarantees zero-downtime deployments automatically
Correct answer
The operator runs inside the cluster and applies changes only when Git is updated
Pull-based deployment uses an operator inside the cluster to monitor Git and apply changes, reducing external access needs. Push-based methods often require external tools to trigger cluster updates.
Which component is typically responsible for synchronizing the desired state from Git to the cluster?
GitOps operator
Container registry
CI pipeline
Monitoring agent
Correct answer
GitOps operator
The GitOps operator watches the Git repository for changes and reconciles the cluster state to match. Registries store images, CI runs tests, and monitoring observes runtime behavior.
Why is declarative configuration important in a GitOps workflow?
It defines the desired outcome rather than procedural steps
It ensures all configurations are written in the same programming language
It allows direct modification of live resources without review
It reduces the need for version control
Correct answer
It ensures all configurations are written in the same programming language
Declarative configuration describes the intended state, enabling automation and consistency. Procedural scripts are less suitable for automated reconciliation. Direct live edits violate GitOps principles.
What is a typical use case for GitOps in managing Kubernetes applications?
Managing the desired state of applications and infrastructure through Git
Replacing service meshes for traffic management
Storing application logs for long-term retention
Providing on-demand interactive debugging sessions
Correct answer
Managing the desired state of applications and infrastructure through Git
GitOps is commonly used to manage Kubernetes deployments by keeping configuration and desired state in Git. The other options describe functions outside the core scope of GitOps.
Which practice supports security and compliance in GitOps by tracking changes over time?
Git history and pull requests
Unrestricted cluster access
Manual configuration snapshots
Ad-hoc deployment scripts
Correct answer
Git history and pull requests
Git provides an immutable audit trail of who changed what and when, which is essential for compliance. Pull requests enable reviews before changes are applied to the desired state.
What does the desired state in GitOps typically include?
Deployment manifests, configuration maps, and secrets references
Only production environment settings
Live cluster metrics and performance data
Temporary troubleshooting scripts
Correct answer
Deployment manifests, configuration maps, and secrets references
The desired state includes all declarative definitions needed to run the application, such as deployments and config maps. Secrets may be referenced via approved sources, while live data is not part of the definition.
Which statement best describes the relationship between GitOps and CI/CD?
GitOps uses Git as the trigger and source of truth, while CI handles build and test automation
GitOps replaces the need for any CI/CD pipelines
CI pipelines are only used for building images, and GitOps handles everything else
GitOps and CI/CD are mutually exclusive approaches
Correct answer
GitOps uses Git as the trigger and source of truth, while CI handles build and test automation
In GitOps, CI pipelines build and test artifacts, while Git serves as the source of truth and trigger for deployment. They complement rather than replace each other.
What is a key advantage of using a Git repository as the source of truth?
Enables consistent, repeatable deployments and easy rollback
It allows runtime configuration changes to persist after restarts
It removes the need for any automation tools
It ensures all developers have direct cluster access
Correct answer
Enables consistent, repeatable deployments and easy rollback
Storing the desired state in Git provides versioning, collaboration, and the ability to revert changes easily. Runtime changes outside Git can cause drift and are not persistent through reconciliations.
Which tool pattern is commonly used to implement GitOps on Kubernetes?
An operator that watches Git and applies changes to the cluster
A script that manually edits live resources via the API
A database that stores runtime configurations
A firewall that restricts cluster access
Correct answer
An operator that watches Git and applies changes to the cluster
Operators or controllers are typical patterns for implementing GitOps by continuously syncing state. Manual edits and runtime config storage do not align with GitOps principles.
What is a potential risk if Git history is not protected in a GitOps workflow?
Unauthorized or accidental changes can be applied to the cluster
The cluster will automatically reject all deployments
Git storage costs will decrease significantly
Observability tools will stop collecting metrics
Correct answer
Unauthorized or accidental changes can be applied to the cluster
Without branch protection and review controls, any change can be merged and automatically applied, increasing risk. The other options are not typical consequences of unprotected history.
Which scenario best illustrates GitOps-driven recovery from a failed deployment?
Reverting the Git state to a previous known good commit and letting the operator reconcile
Manually editing resources on the cluster to match old settings
Restarting the cluster control plane services
Disabling the monitoring system to suppress alerts
Correct answer
Reverting the Git state to a previous known good commit and letting the operator reconcile
GitOps recovery involves restoring the desired state in Git and allowing automation to reconcile the cluster. Manual cluster edits introduce drift and are not part of the GitOps model.
What is a common prerequisite for implementing GitOps in an environment?
A Kubernetes cluster with appropriate access controls
A dedicated on-premises server for every microservice
Disabling all forms of observability
Using only imperative CLI commands for all operations
Correct answer
A Kubernetes cluster with appropriate access controls
GitOps requires a target cluster where the operator can apply changes, along with defined access policies. The other options contradict standard practices and operational needs.
Which practice helps prevent configuration drift in a GitOps setup?
Regular automated reconciliation and avoiding direct cluster changes
Allowing developers to apply changes directly with kubectl
Periodically deleting and recreating cluster resources
Using multiple Git repositories without synchronization
Correct answer
Regular automated reconciliation and avoiding direct cluster changes
Automated reconciliation ensures the cluster converges to the Git-defined state. Direct changes and ad-hoc recreation cause drift and inconsistency.
Recall the answer before opening each card.
To use Git as the single source of truth for declarative infrastructure and applications, ensuring consistency, traceability, and automated synchronization between the cluster state and the desired state.
Automated reconciliation, performed by a GitOps operator that continuously compares the cluster state to the declared state in Git and makes corrections.
An operator inside the cluster watches the Git repository and applies changes only when the repository is updated, reducing external access and ensuring changes are traceable.
The GitOps operator, which watches the Git repository for changes and reconciles the cluster state to match the declared configuration.
It describes the intended end state, enabling the operator to automatically determine the actions needed to achieve that state without specifying procedural steps, which prevents drift.
Managing the desired state of applications and infrastructure through Git, using an operator to automatically deploy and reconcile resources based on Git changes.
Git provides an immutable audit trail of who changed what and when, enabling compliance tracking. Combined with pull requests and branch protection, it prevents unauthorized changes.
Deployment manifests, configuration maps, and secrets references. Actual secrets are stored securely outside Git. It includes all declarative definitions needed to run the application.
CI handles build and test automation; GitOps uses Git as the source of truth and trigger for deployment. They complement each other—CI produces artifacts, GitOps deploys them.
Enables consistent, repeatable deployments and easy rollback by reverting to a previous commit. All changes are versioned and auditable, reducing configuration drift.
An operator or controller that watches a Git repository and automatically applies changes to the cluster to maintain the desired state.
Unauthorized or accidental changes can be merged and automatically applied to the cluster, leading to unstable or insecure deployments without review.
By reverting the Git state to a previous known good commit and letting the operator reconcile the cluster, restoring the stable state without manual cluster edits.
A Kubernetes cluster with appropriate access controls to host a GitOps operator that can manage and reconcile resources.
Through regular automated reconciliation that ensures the cluster converges to the Git-defined state, and by avoiding direct cluster changes that would introduce drift.
The continuous process where the operator compares the current cluster state against the desired state in Git and applies corrections to eliminate any differences.
Direct changes cause configuration drift and are overwritten during the next reconciliation. All changes must go through Git to maintain consistency and traceability.
They enable change review, approval, and audit before merging to the protected branch. This ensures only authorized changes are reconciled, enhancing security and compliance.
The operator periodically or via webhook checks the Git repository, then creates, updates, or deletes cluster resources to match the declared configuration, including pruning resources not in Git.
Revert the problematic commit in Git to a previous known good state. Push the revert; the operator automatically syncs the cluster back to that state, restoring stability.
Read the prompt, commit to an answer, then flip the card. Move through the deck at your own pace and repeat any topic that does not come back quickly.
Card 1 of 20
1 reviewed this session
Connect the concepts
Open a branch to connect a topic with its practice questions and explanations. Use the map to choose your next review topic.
This is an analysis of the practice bank, not a claim about the vendor's live exam blueprint. Use it to identify the knowledge, judgment, and recall patterns exercised here, then verify your coverage against the current official exam guide.
GitOps is centered on the principle of using Git as the single source of truth for declarative infrastructure and application configurations. This practice bank emphasizes that the primary purpose is to define the desired state in Git and automate synchronization, ensuring consistency and traceability. The questions test your understanding of why declarative configuration is crucial—it describes the intended state, enabling automated reconciliation. Imperative scripts or live edits violate this principle. The foundational goal is to eliminate drift by having the cluster always converge to what is defined in Git, making deployments repeatable and auditable.
Automated reconciliation is the process by which a GitOps operator continuously compares the cluster state to the declared state in Git and makes corrections. This practice bank highlights the pull-based deployment model, where an operator inside the cluster watches Git and applies changes only when the repository updates, reducing external access needs. Pushing changes directly to the cluster bypasses this control. The questions explore how reconciliation prevents configuration drift and what tools (operators) are typically used to implement this pattern. Understanding the difference between push and pull models is key.
GitOps leverages Git's history and pull request workflows to provide an immutable audit trail of all changes. The practice bank stresses that protecting Git history through branch protection and review controls is critical to prevent unauthorized or accidental changes from being applied. Without these, any merged commit can automatically trigger a reconciliation, increasing security risk. Compliance is enhanced because every change is tracked—who changed what and when—and reverting to a known good state is straightforward by reverting a commit. This section also covers that secrets should be referenced via approved external sources, not stored directly in Git.
GitOps complements CI/CD but does not replace it. CI pipelines handle build, test, and artifact creation, while GitOps uses Git as the trigger and source of truth for deployment. The practice bank clarifies that GitOps requires a Kubernetes cluster with appropriate access controls to host an operator that watches the repository. Recovery from failed deployments is done by reverting the Git state to a previous commit and letting the operator reconcile. The questions also address that tools like Argo CD or Flux are common operators, and that direct cluster modifications cause drift, undermining the GitOps model.
Study workflow
Create declarative manifests (Deployments, ConfigMaps, etc.) for your application and infrastructure. Store them in a Git repository under version control. Ensure all configurations are defined as code, avoiding any imperative scripts or runtime manual changes. This forms the foundation of your GitOps workflow.
Implement branch protection rules to require pull request reviews and status checks before merging. This prevents unauthorized changes from being automatically applied. Use signed commits if possible. Configure at least one protected branch (e.g., main or production) that triggers the reconciliation when updated.
Deploy a GitOps operator (such as Argo CD or Flux) into your Kubernetes cluster. Configure it to watch the Git repository branch you designated. The operator will periodically compare the cluster state to the desired state in Git and automatically apply any differences.
Set the operator to sync automatically when changes are detected in the watched Git branch. Define the synchronization frequency or use webhooks to trigger immediate reconciliation. Ensure the operator has appropriate permissions to update resources, and enable pruning to remove resources not defined in Git.
To recover from a failed deployment, revert the Git commit that introduced the change to a previous known good commit. Push the revert to the protected branch. The operator will automatically reconcile the cluster back to that state. Avoid making manual cluster edits; instead, always change state through Git.
FAQ
Clear boundaries on what the bank covers, how to use it, and where official vendor information still matters.
GitOps uses Git as the single source of truth for declarative infrastructure and applications. The primary purpose is to ensure that the cluster state is continuously reconciled with the desired state defined in Git, providing consistency, traceability, and automated deployment management.
In pull-based deployment, a GitOps operator inside the cluster monitors Git and pulls changes when the repository updates, reducing external access needs. Push-based deployment uses external tools to push changes directly to the cluster, which can increase security risk and bypass desired state control.
The GitOps operator is a software component (e.g., Argo CD or Flux) that runs in the cluster and watches a Git repository. It continuously compares the cluster state with the desired state in Git and automatically reconciles any differences by applying changes, handling drift detection, and managing synchronization.
Declarative configuration describes the intended end state, enabling automation and consistency. In GitOps, it allows the operator to determine what actions are needed without specifying steps. This contrasts with imperative scripts, which are less suitable for automated reconciliation and can cause drift.
Git provides an immutable audit trail of every change, including who made it and when. Combined with pull request reviews and branch protection, this prevents unauthorized or accidental alterations. For compliance, the full change history is available, and reverting to a previous state is as simple as reverting a commit.
Browse another free bank or use the study strategy guide to turn your misses into spaced review.
