🚨 ArgoCD Deployment Failed: agentic-platform-engineering-demo

[github-actions]

ArgoCD Deployment Failure

Application: agentic-platform-engineering-demo
Timestamp: 2026-03-12T02:47:51.985Z

Cluster Information

Field	Value
Cluster Name	msftgbb
Resource Group	agentic-platform-engineering
Namespace	default

Application Status

Field	Value
Health Status	Degraded
Sync Status	Synced
Revision	d07c9dc1167770604ffe50aacda024c46494718b
Repository	https://github.com/microsoftgbb/agentic-platform-engineering.git

Error Message

successfully synced (all tasks run)

Troubleshooting Commands

# Check application status in ArgoCD
argocd app get agentic-platform-engineering-demo

# Check pods in namespace
kubectl get pods -n default

# Describe failed pods
kubectl describe pods -n default

# Get pod logs
kubectl logs -n default <pod-name>

# Check events
kubectl get events -n default --sort-by='.lastTimestamp'

Quick Links

• ArgoCD UI
• Source Repository

---

This issue was automatically created by ArgoCD Notifications

[github-actions]

🤖 Cluster Doctor is on the case!

Work has begun on this issue. A GitHub Action has been spun up to analyze and diagnose the cluster.

🔗 View the running GitHub Action

[github-actions]

Cluster Doctor Analysis

I investigated Issue #31 using GitHub MCP plus AKS MCP.

What I verified

• The issue metadata points to AKS cluster msftgbb in resource group agentic-platform-engineering.
• az aks show confirms that cluster exists, is Running, and the control plane provisioning state is Succeeded.
• AKS resource-health/metric/diagnostic queries did not show a platform-side outage, which makes an AKS control-plane problem unlikely.
• The Argo CD application manifest in Act-3/argocd-test-app.yaml was targeting Act-3/argocd/apps, and that directory only contains the intentionally broken workshop manifest broken-aks-store-all-in-one.yaml.

Diagnosis

This is a GitOps manifest issue, not an AKS platform issue.

The repo was configured so the sample Argo CD app deployed the intentionally broken workshop manifest by default. That broken manifest contains multiple runtime-breaking changes, including:

• order-service image typo: ordr-service
• hardcoded RabbitMQ credentials for makeline-service
• altered/removed probe behavior

That explains the incident pattern: Argo CD can report Synced while the application is still Degraded because the YAML applies successfully, but the workloads do not become healthy.

Remediation

I created PR #32 to restore the live demo path while preserving the workshop exercise:

• Fix Act-3 ArgoCD demo deployment #32

PR #32:

• switches Act-3/argocd-test-app.yaml to deploy a healthy manifest directory
• adds Act-3/argocd/deploy/aks-store-all-in-one.yaml as the manifest Argo CD should reconcile
• leaves the intentionally broken manifest under Act-3/argocd/apps/ for workshop analysis

Validation performed

• kubectl apply --dry-run=client --validate=false -f Act-3/argocd-test-app.yaml
• kubectl apply --dry-run=client --validate=false -f Act-3/argocd/deploy/aks-store-all-in-one.yaml
• git diff --check

Notes on cluster access

I did not perform any in-cluster write actions. AKS MCP could verify the Azure-side cluster identity and health, but kubeconfig acquisition via MCP required admin access, so pod-level live inspection was limited in this run.

Suggested post-merge validation

After merging PR #32:

argocd app sync agentic-platform-engineering-demo
kubectl get pods -n default
kubectl get deployments -n default
kubectl get events -n default --sort-by='.lastTimestamp' | tail -n 50

Expected outcome: the app should reconcile from the healthy manifest set instead of the intentionally broken workshop file, allowing Argo CD health to recover.