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.