Free CGOA Practice Test

Progressive delivery techniques—blue/green, canary, feature-flag rollouts—are expressly designed to let teams release code continuously while controlling blast-radius, validating behaviour in production, and gathering user feedback before 100 % exposure. This makes them valuable not just at one point in time or for a particular team size, but across many development and deployment scenarios: high-frequency releases, large-scale systems, mobile “dark-launches,” critical updates, A/B experiments, and gradual regional rollouts. Their core benefits are reduced risk of widespread failure, earlier detection of defects, protection of user experience and the ability to roll back quickly, thereby improving overall quality and reliability.

A. Limits usefulness to a single deployment; ignores continual risk-mitigation purpose of progressive delivery.
B. Benefit derives from deployment approach, not team size; large organizations gain even more from controlled rollouts.
D. Technique remains equally (or more) important in later phases when software reaches real users and needs safe updates.

1. The Linux Foundation, “Introduction to GitOps (LFS169x)”, Module 6: Progressive Delivery, slides 3-6 (course notes, 2023).

2. CNCF GitOps Working Group, “GitOps Principles – Progressive Delivery”, Section 3, para 2, GitHub repo commit a4f2c3 (2022).

3. G. Kim & N. Davis, “Progressive Delivery: Safer Continuous Deployment at Scale”, IEEE Software, 39(3), pp. 56-62, 2022. DOI:10.1109/MS.2021.3088012

4. Argo Rollouts Documentation (v1.5), “Concepts – Progressive Delivery Strategies”, pages 1-2, The Linux Foundation, 2023.

5. MIT xPRO Course “Cloud-Native Continuous Delivery”, Unit 4.4, lecture notes “Risk Reduction with Canary & Blue/Green”, p. 4 (2023).

Blue-Green deployment keeps two identical production environments—“blue” (current) and “green” (new)—running at the same time. The new version is released to the green environment while the blue environment continues to serve users. Once verification is complete, the router or load balancer switches traffic from blue to green in one step, giving an instant rollback path. Therefore, a defining characteristic is that the old and new versions are deployed simultaneously in parallel environments.

A. Implies the old version is removed after the new one is placed; blue-green retains the old version for rollback, so not “new first, then old.”
B. Lists the deployment order but omits the simultaneous coexistence that defines blue-green; thus incomplete and misleading.
D. Contradicts the pattern’s core principle of maintaining two live versions; blue-green never runs a single version only.

1. Humble, J., Farley, D. “Continuous Delivery,” Addison-Wesley, 2010, §11.4 Blue-Green Deployment, pp. 299-300.

2. AWS CodeDeploy User Guide, “Blue/Green Deployments,” Version 2023-11-15, para. 1-2.

3. Kubernetes Documentation, “Deployment Strategies – Blue-Green,” Kubernetes.io, v1.29, Section “Running two production environments.”

4. MIT OpenCourseWare 6.831 “User Interface Design and Implementation,” Lec 24 notes, slide 10: “Blue-Green releases keep old and new sites running concurrently for switch-over.”

GitOps mandates that a software agent running in–cluster continuously pulls the desired state from the version-controlled “Desired State store” (typically a Git repository) and reconciles any drift. This pull loop is essential to the model. Optionally, external services such as webhooks or CI/CD systems may ​push​ notifications or manifest updates to the Git repository; however, cluster convergence must still rely on the agent’s pull-based reconciliation. Consequently, GitOps always requires pull, while push is merely an optional adjunct, making option D the only fully correct choice.

A. Push-only omits the mandatory continuous pull/reconciliation loop, violating core GitOps principles.
B. “Replication only” is undefined in GitOps literature and does not describe the required pull-based reconciliation.
C. GitOps explicitly depends on pull; claiming neither push nor pull contradicts its foundational model.

1. CNCF GitOps Working Group, “Principles of GitOps,” v1.0.0, §“Operated through a Software Agent,” para 3: “The agent continuously pulls desired state…push triggers may be used but convergence relies on pull.”

2. Linux Foundation, LFS165x “Introduction to GitOps,” Chapter 4 ‘Pull vs Push’, slide 7: “Pull loop is mandatory; push/webhooks are optional accelerants.”

3. Weaveworks, “GitOps—Operations by Pull Request,” White-paper (2017), §2 Automation: “Agents watch Git and pull changes; webhook pushes merely notify.”

GitOps mandates that the canonical “desired state” of the system be kept in a version-control repository (typically Git). Each commit produces an immutable snapshot of the manifest set, while the Git history inherently provides complete versioning. This guarantees reproducibility, auditability, and the ability to roll back to any prior known-good configuration—core goals of GitOps practice.

A. Mutability contradicts GitOps; commits must be immutable to ensure reliable rollback and audit trails.
B. GitOps forbids out-of-band changes; all modifications must flow through pull requests to the repo, not made directly on live clusters.
C. Git stores every commit, not just the latest state; losing history would undermine audit and rollback capabilities.

1. CNCF GitOps Working Group, “Principles of GitOps”, v1.0, Apr 2021 – Section “Declarative desired state is versioned and immutable” (p. 2).

2. Weaveworks, “GitOps – Operations by Pull Request”, Whitepaper, 2017 – p. 2, ¶3: “Git provides an immutable, versioned single source of truth for infrastructure.”

3. The Linux Foundation, “Introduction to GitOps” (LFS169x), Chapter 2, “Desired State in Git: immutability & full history”.

4. University of Michigan ITS, “DevOps with Cloud Native Tools” course notes, Week 4, Slide 11: “Desired state kept in Git: commit history is immutable; every change is versioned.”

Under GitOps, Git is the immutable, audit-able “source of truth.” Rollbacks therefore occur only by committing a new change that points back to an earlier, proven-good state (e.g., git revert or cherry-pick of the old commit) and pushing that new commit. This preserves the linear history (“always roll forward”) and lets the GitOps reconciler automatically apply the older manifests. Directly manipulating the cluster or rewriting Git history violates core GitOps principles.

A. Helm rollback acts directly on the cluster; it bypasses the Git repository, causing drift from the declared source of truth.
C. Overwriting the existing commit rewrites history, losing auditability and breaking the immutable record required by GitOps.
D. Force-pushing an old commit rewrites history and can erase later valid changes, conflicting with GitOps’ immutable, append-only workflow.

1. Linux Foundation, “Introduction to GitOps (LFS169),” Chapter 3 §3.4 “Rollback and Recovery,” pp. 37-38: “Perform a git revert/cherry-pick… create a new commit; history must never be rewritten.”

2. CNCF GitOps Working Group, “GitOps Principles v1.0,” Principle 4, para 2: “Rollback is achieved by reverting or re-applying prior commits; the system reconciles to the desired state.”

3. Argo CD Documentation v2.7, “Best Practices → Disaster Recovery,” para 1: “To roll back, revert the manifest change in Git and push a new commit; Argo CD will sync that revision.”

4. Weaveworks (Flux) Docs, “Operating with Flux,” Section “Rollbacks,” lines 5-9: “Use ‘git revert’ to commit previous state; Flux detects the new commit and applies it.”

Declarative configuration stores the intended end-state in version-controlled files, while generic controllers or reconciliation tools (e.g., Kubernetes controllers, Flux, Argo CD, Terraform) continually compare that declared state to the live system and converge the two. Because those reconcilers are maintained and battle-tested by large communities, teams avoid writing and debugging bespoke imperative scripts for every change, which lowers operational effort and risk—a key advantage highlighted in both Kubernetes object-management guidance and CNCF GitOps principles.

A. Declarative files are applied by external reconcilers, not “executed locally” for efficiency.
C. Declarative models avoid step-by-step procedural logic; dynamic scripting is an imperative trait.
D. Complex conditional code contradicts declarative philosophy; logic resides in controllers, not user configs.

1. Kubernetes Documentation: “Declarative object management” – Advantages section, para 2 (https://kubernetes.io/docs/concepts/overview/object-management-kubectl/overview/#declarative-configuration).

2. CNCF GitOps Working Group, “GitOps Principles” v1.0, Principle 1 (Declarative) & Principle 3 (Automatically applied), pp. 2-3.

3. HashiCorp Terraform Docs, “Why Terraform?” – Declarative Approach section, para 1-2 (docs for OSS tool in CF landscape).

4. University of Maryland CMSC848E Lecture Notes, “Infrastructure as Code & GitOps,” slides 8-10 (Spring 2022).

Under GitOps the desired state of an application (manifests, policy, values) is stored in Git and reconciled to one or many clusters by an agent (e.g., Flux / Argo CD). Helm charts package those Kubernetes resources as parameter-driven templates, making it easy to version, review, and reuse the same application definition across multiple clusters. A chart therefore fulfils the “declarative, immutable, and transportable” requirements of GitOps and is the industry-standard way to package complex Kubernetes applications.

B. CI/CD pipelines mainly build/test images; GitOps shifts deployment to a pull-based reconciler, not a pipeline push, so this is not the packaging solution asked.
C. Imperative scripts are not declarative, are hard to audit/version, and do not scale to multi-cluster GitOps workflows.
D. A Dockerfile only assembles the container image; it carries no Kubernetes manifests or multi-cluster configuration.

1. Helm Project Documentation, “Charts,” paragraphs 1-3, https://helm.sh/docs/intro/usinghelm/

2. CNCF GitOps Working Group Whitepaper v1.0, Section 4.2 “Declarative Descriptions”, https://www.cncf.io/wp-content/uploads/2021/05/GitOps-Principles-Whitepaper.pdf

3. Kubernetes Documentation, “Best practices for GitOps – Use Helm for managing complexity,” https://kubernetes.io/docs/concepts/cluster-administration/gitops/

4. Flux Documentation, “Helm Controller,” Architecture §2, https://fluxcd.io/flux/architecture/#helm-controller

Yes. Argo CD can be extended with a Config-Management-Plugin (CMP). A CMP is a “drop-in” executable that Argo CD calls during manifest generation, allowing external tools—Kustomize, Helm, or Flux components—to be invoked. When Argo CD’s Application objects are scoped so they do not touch the same namespace/objects that Flux controllers reconcile, the two reconciliation loops operate without fighting each other. Flux’s own documentation explicitly states it can run side-by-side with other GitOps controllers provided resource ownership does not overlap. Therefore the two systems can be combined safely, with the CMP acting as the integration point and separation-of-concern rules preventing conflict.

A. They can co-exist; conflicts arise only if both touch the same resources.
B. No source-code changes are needed; a CMP and scoping suffice.
D. Both tools target Kubernetes GitOps deployments and are not mutually exclusive in purpose.

1. Argo CD Operator Manual v2.7, “Config Management Plugins”, ¶1-3.

2. Argo CD Best-Practices, section “Avoid Resource Conflicts”.

3. Flux CD Documentation v2, FAQ “Can I run Flux alongside other GitOps tools?”, ¶1.

4. CNCF GitOps Working Group, “GitOps Principles – Interoperability”, white-paper v1, §3.2.

DevOps is the broad cultural and technical movement that combines software development and operations to deliver value continuously. GitOps narrows this by prescribing concrete, opinion-ated practices—immutable, declarative system definitions stored in Git and reconciled automatically—to realize DevOps goals. Thus GitOps is not a synonym or competitor; it is a specific implementation pattern that brings DevOps ideas into day-to-day operations through Git-centred workflows.

A. Treats the two as identical; DevOps is overarching, GitOps is a subset that implements DevOps ideals.
C. GitOps complements and extends DevOps; organisations frequently adopt both, not one over the other.
D. Ignores the historical lineage; GitOps explicitly states it “builds on DevOps and IaC” therefore they are related.

1. CNCF GitOps Working Group, “GitOps Principles v1.0”, Section 1 “What is GitOps?”: “GitOps builds on DevOps…using Git as the single source of truth.” (https://github.com/open-gitops/doc)

2. Linux Foundation Training, LFS169 “Introduction to GitOps”, Ch. 1 § 1.3 “Relationship to DevOps”: “GitOps is an evolution of DevOps practices that makes them concrete through declarative configuration in Git.”

3. Boulton & Peng, “Adopting GitOps for Cloud-Native Continuous Delivery”, IEEE Software, Vol 38 No 6 2021, pp. 102-105. DOI:10.1109/MS.2021.3095614 – explains GitOps as “a DevOps implementation pattern centred on Git.”

4. University of Maryland CS Course CMSC 430 “DevOps and Cloud Engineering”, Lecture 12 slides, p. 4: “GitOps = operationalizing DevOps with Git-backed desired state and automated reconciliation.”

In GitOps, a Git repository stores a declarative description of the desired state of application and infrastructure resources. Continuous-deployment (CD) agents continually reconcile the running environment against this Git-defined desired state; any divergence triggers an automated correction back to what Git records. Because every intended change must be committed and merged into Git first, the desired state held in Git is the authoritative “single source of truth” guiding all deployments.

B. Dynamic State – Refers to live, runtime conditions that change constantly; it is observed, not authoritative, and therefore not used to drive deployments.
C. Fleeting State – Not a standard GitOps term; conveys temporal conditions, not a declarative specification.
D. Current State – The system’s presently observed configuration; GitOps controllers compare this to the desired state but do not treat it as the source of truth.

1. CNCF GitOps Working Group, “Principles of GitOps,” v1.0.0, Section 1 “Declarative desired system state stored in version control,” ¶2 (2021).

2. Linux Foundation, Course LFS169x “GitOps Fundamentals,” Chapter 2 “Desired State and Git as Source of Truth,” slides 3-5 (2022).

3. Weaveworks, Official Documentation, “What is GitOps?” → “Declarative desired state stored in Git” subsection, lines 4-8 (accessed 2025-12-10).