Linux Foundation Certified Argo Project Associate

A workflow runs containers as steps on Kubernetes. You write a first workflow, pass parameters between steps, choose template types, and watch execution in the UI and the command line.

• The Workflow resource and its entrypoint
• Container, script and resource templates
• Steps, in sequence and in parallel
• Parameters and passing outputs between steps
• Watching, logging and resubmitting runs
• Retry strategies and timeouts

You build A multi-step workflow that passes values between steps and retries a flaky one.

Reuse keeps workflows maintainable. You read the workflow spec closely, factor common steps into WorkflowTemplates, run work on a schedule with CronWorkflows, and set limits and cleanup rules.

• Reading the workflow spec field by field
• WorkflowTemplates and ClusterWorkflowTemplates
• Calling a template from another workflow
• CronWorkflows and schedules
• Resource limits, volumes and service accounts
• Time-to-live and garbage collection

You build A library of reusable workflow templates and a scheduled workflow that uses them.

Real jobs have dependencies and files. You describe tasks and their dependencies as a DAG, fan work out and back in, pass files as artifacts through an artifact repository, and process data in parallel.

• DAG templates, tasks and dependencies
• Fan-out and fan-in with loops
• Input and output artifacts
• Configuring an artifact repository
• Parallelism limits and resource control
• A data processing job split across many pods

You build A DAG workflow that splits a dataset, processes the parts in parallel and merges the results through artifacts.

Argo CD keeps a cluster matching what Git says. You define an Application, point it at a source and a destination, sync manually and automatically, and read its health and status.

• GitOps with Argo CD in outline
• The Application resource: source and destination
• Manual and automated sync
• Prune and self-heal options
• Health status and sync status
• Sync waves and hooks

You build An Application that deploys a sample service from Git and heals itself after a manual change.

Most real applications are packaged. You deploy Helm charts and Kustomize overlays through Argo CD, set values per environment, and manage many applications at once.

• Helm charts as an Argo CD source
• Overriding Helm values per environment
• Kustomize overlays as a source
• The app-of-apps pattern
• ApplicationSets for many clusters or environments
• Choosing between Helm and Kustomize

You build One Helm-packaged service deployed to development and production with different values, from a single definition.

Reconciliation is Argo CD’s core job, and it needs rules. You read diffs, decide what to ignore, recognize common reconciliation patterns, and limit who can deploy what with projects and RBAC.

• How Argo CD compares live and desired state
• Reading a diff and resolving out-of-sync
• Ignoring fields that controllers change
• Rollback and history
• Projects and RBAC for teams
• Notifications for sync results

You build A project definition that restricts a team to its repositories and namespaces, with sync notifications.

A Deployment replaces pods, while a Rollout releases them with care. You write canary and blue/green strategies, pause and promote releases, and shift traffic gradually through an ingress or a mesh.

• Why Rollouts instead of Deployments
• Canary steps, weights and pauses
• Blue/green with preview and active services
• Traffic management with ingress and mesh
• Promoting, aborting and rolling back
• Watching a rollout in the CLI and dashboard

You build A canary Rollout with weighted steps and a manual approval before full promotion.

A rollout can judge itself. You define AnalysisTemplates that query metrics, run them as AnalysisRuns during a release, and let their results promote or abort it.

• AnalysisTemplates and the metrics they query
• Success conditions and failure limits
• Inline and background analysis
• Using Prometheus as a metric provider
• How a failed AnalysisRun aborts a rollout
• Designing metrics that detect a bad release

You build A rollout that queries error rate and aborts itself when an AnalysisRun fails.

Things happen outside the cluster, and Argo Events turns them into actions. You wire event sources to sensors through an event bus, and trigger workflows and other resources from what arrives.

• The Argo Events architecture
• EventSources: webhooks, repositories and calendars
• The EventBus and how events flow
• Sensors, dependencies and filters
• Triggers: starting workflows and other resources
• Securing and debugging event flows

You build An event source and sensor that start a workflow whenever a repository receives a push.

Join all four projects in one flow. A push raises an event, a workflow builds and tests, Argo CD syncs the new version, and a rollout releases it step by step while analysis watches.

• Designing the end-to-end flow
• Triggering with Events and building with Workflows
• Syncing the release with Argo CD
• Releasing with Rollouts and analysis
• Handling failure at each stage
• Reviewing the flow and its permissions

You build A working flow in which a commit triggers a build, a sync and an analyzed canary release.