1️⃣ What Is the Argo CD Dashboard?

The Argo CD Dashboard is the visual control plane of GitOps.

It answers one critical question continuously:

❓ Does the Kubernetes cluster match what is defined in Git?

If the answer is NO, Argo CD reacts.

This dashboard is not just UI — it is a live view of Git vs Kubernetes state reconciliation.

2️⃣ What the Dashboard Represents Conceptually

Before understanding buttons and fields, must understand what Argo CD really is.

Argo CD is:

• A continuous reconciliation engine
  


• A GitOps controller
  


• A Kubernetes-native CD system
  

Argo CD is NOT:

• Not CI


• Not kubectl


• Not a build tool


• Not Helm (but works with Helm)

3️⃣ Dashboard Layout Overview

The dashboard is divided into three logical areas:

1. 
   Left Sidebar – Control & navigation


2. 
   Top Toolbar – Application management


3. 
   Application Tiles – Real-time GitOps state

🔹 PART 1: LEFT SIDEBAR (ARGO CD CONTROL PLANE)

3.1 Applications (Most Important Section)

This section lists all GitOps-managed applications.

Key idea:

One Argo CD Application = One Git → One Kubernetes desired state

Each application:

• Points to a Git repo


• Points to a cluster


• Points to a namespace


• Continuously reconciles state

If an application is not here → Argo does not manage it.

3.2 Settings

This is where platform-level configuration lives.

Includes:

• Repositories


• Clusters


• Projects


• RBAC


• Accounts

Real-world meaning:

• Platform team controls what repos can deploy
  


• Controls which clusters are allowed
  


• Controls who can deploy to prod
  

In production, most engineers never touch Settings.

3.3 User Info

Shows:

• Logged-in user


• Permissions

In real companies:

• Integrated with SSO (GitHub, Okta, Azure AD)


• No shared admin passwords

3.4 Application Filters (Left Bottom)

You see filters like:

• Synced


• OutOfSync


• Healthy


• Degraded


• Progressing

Why this matters:

This allows operators to answer instantly:

“Is production stable right now?”

If OutOfSync > 0, something changed outside Git.

🔹 PART 2: TOP TOOLBAR (APPLICATION MANAGEMENT)

4.1 Create Application (+)

This button allows manual creation of applications.

But in advanced GitOps:

• Applications are created via YAML


• Stored in Git


• Managed declaratively

This is already what you did, which is advanced.

4.2 Refresh Button

Forces Argo to:

• Re-pull Git


• Re-check cluster state

Important concept:

Argo normally polls Git automatically — refresh is just manual trigger.

4.3 Search Bar

Used in large environments:

• Hundreds of apps


• Microservices


• Multi-team platforms

🔹 PART 3: APPLICATION TILE (CORE OF THE DASHBOARD)

Now we explain everything inside one tile, because this is where GitOps becomes real.

5️⃣ Application Tile Explained (grade-api)

5.1 Application Name

Example:

grade-api

This is a logical GitOps object.

It represents:

• Git repository


• Kubernetes namespace


• Deployment ownership

Deleting this application deletes everything it manages.

5.2 Project

Project: default

Projects are security and governance boundaries.

In production:

• dev-project


• staging-project


• prod-project

Each project can:

• Restrict namespaces


• Restrict clusters


• Restrict Git repos

5.3 Status (MOST IMPORTANT FIELD)

Example:

Status: Healthy | Synced

This is the heart of GitOps.

🟢 Synced

Means:

• Git desired state == Kubernetes live state


• No drift


• No manual changes

If someone runs kubectl edit:

• Status becomes OutOfSync
  

🟢 Healthy

Means:

• Kubernetes resources are functioning correctly


• Pods running


• No CrashLoopBackOff


• Readiness probes passing

Very important distinction:

5.4 Repository

https://github.com/jumptotechschooldevops/grade-api-gitops

This proves:

• Argo deploys from Git
  


• Not from laptop


• Not from CI artifacts

5.5 Target Revision

main

Means:

• Argo tracks main branch


• Any commit to main becomes desired state

This is why:

• Branch protection


• Pull request reviews

Are critical in GitOps.

5.6 Path

Path: .

Means:

• Kubernetes manifests are at repo root

In real systems:

/dev

/stage

/prod

Each path can map to different Argo applications.

5.7 Destination (Cluster)

Destination: in-cluster

Means:

• Argo deploys to the same cluster it runs in

In enterprises:

• Argo deploys to multiple remote clusters (EKS, AKS, GKE)

5.8 Namespace

Namespace: grade

This is where:

• Pods run


• Services exist

Argo created it automatically because:

CreateNamespace=true

5.9 Created / Last Sync Time

Shows:

• When the application was created


• Last reconciliation time

This provides:

• Auditability


• Deployment history


• Compliance evidence

5.10 Sync / Refresh / Delete Buttons

SYNC

• Manually apply Git → cluster


• Used when auto-sync is disabled

REFRESH

• Re-check Git and cluster


• Does not deploy anything

DELETE

⚠️ Very dangerous in production.

Deletes:

• Deployment


• Pods


• Services


• ConfigMaps


• Secrets
  (Everything owned by the app)

🔹 PART 4: WHAT THIS DASHBOARD PROVES

This dashboard proves five production-level truths:

✅ 1. Git Is the Source of Truth

No Git change → no deployment.

✅ 2. Humans Cannot Permanently Change Prod

Manual kubectl changes are reverted.

✅ 3. Drift Is Detectable

Any mismatch is visible immediately.

✅ 4. Rollbacks Are Git-Based

git revert = production rollback.

✅ 5. Kubernetes Is Declarative

Desired state is enforced continuously.

🔹 PART 5: ONE-SENTENCE SUMMARY

“The Argo CD dashboard shows whether Kubernetes is obeying Git — and if not, Argo forces it to.”

🔹 PART 6: COMMON INTERVIEW QUESTIONS FROM THIS DASHBOARD

Q: What does Synced mean in Argo CD?

A: Git and live cluster state match.

Q: What happens if someone edits prod manually?

A: Argo detects drift and reverts it.

Q: Can Argo deploy without CI?

A: Yes — CI only builds artifacts, Argo deploys from Git.

Q: Is Argo replacing Kubernetes?

A: No — Argo controls desired state, Kubernetes executes it.