The blueprint
A mock exam here has 60 questions in 90 minutes, split across the domains in the same proportions as the official exam guide. The official pass mark is 75%. FixOps scores practice against a target of 75%.
-
01
Argo Workflows
-
02
Argo CD
-
03
Argo Rollouts
-
04
Argo Events
Sample questions
Three of the 10 questions in the free diagnostic. Open one to see the answer and why.
The Workflow resource serves two functions in Argo Workflows. Which are they?
- It builds the container images, and it pushes them to the registry when they are ready
- It defines the workflow to be executed, and it stores the state of that workflow
- It installs the controller, and it upgrades the custom resource definitions
- It schedules pods onto nodes, and it mounts the volumes that the pods ask for
Answer: It defines the workflow to be executed, and it stores the state of that workflow. The Workflow defines the workflow to be executed and stores its state. Because of these dual responsibilities it should be treated as a live object: not only a static definition but also an instance of it.
A steps template is a list of lists. How are the outer and the inner lists executed?
- Both run in parallel, limited only by the size of the cluster
- Both run sequentially, in the order in which they are written
- Outer lists run in parallel; the steps of an inner list run sequentially
- Outer lists run sequentially; the steps of an inner list run in parallel
Answer: Outer lists run sequentially; the steps of an inner list run in parallel. The structure of a steps template is a list of lists: outer lists run sequentially and inner lists run in parallel. To run the inner ones one by one, the documentation points to the synchronization feature.
What is a WorkflowTemplate?
- A Helm chart that installs the workflow controller
- A definition of a Workflow that lives in the cluster and can be reused
- A pod template that the scheduler copies for every node
- A single step inside a Workflow, such as a container or a script
Answer: A definition of a Workflow that lives in the cluster and can be reused. WorkflowTemplates are definitions of Workflows that live in your cluster, which lets you create a library of frequently used templates. A template in lower case is a task within a Workflow, under the field templates.
Revision notes: Argo Workflows
The notes for one domain, free to read here and in the app. FixOps Pro has them for all 4 domains.
Argo Workflows runs each step of a workflow as a pod. Know what a Workflow and its templates are, how steps and DAGs order the work, how parameters and artifacts travel between steps, and how templates are reused and scheduled.
The Workflow and how it runs
- A Workflow both defines the workflow to be executed and stores its state, so it is a live object: a definition and an instance of it.
- The core of a Workflow spec is a list of templates and an entrypoint, which names the template that is executed first.
- With generateName, Kubernetes appends a random suffix, so the same manifest can be submitted again and again.
- Two Deployments make up the installation: the Workflow Controller, which does the reconciling, and the Argo Server, which serves the API and can be left out.
- Each step and each DAG task generates a pod; templates that only invoke other templates run no pod of their own.
- A workflow pod has three containers: main runs the user's image, init fetches artifacts and parameters, and wait saves parameters and artifacts afterwards.
- Workflow pods run with the service account in spec.serviceAccountName or, if that is omitted, the default service account of the namespace.
- argo submit sends a spec to the cluster; argo list, get, logs and delete inspect and remove workflows.
Template types
- Template definitions define work: container, script, resource, suspend, plugin, container set and HTTP.
- Template invocators call other templates and control execution: steps and dag.
- A script template is a container template with a source field: the script is saved to a file and executed.
- The standard output of a container or script is exported as the output parameter named result, up to 256 kb.
- A resource template gets, creates, applies, deletes, replaces or patches cluster resources; successCondition and failureCondition can decide its outcome.
- A suspend template pauses for a duration or until the workflow is resumed, for example with argo resume.
- A ContainerSet template runs several containers within a single pod, so they share a host and can share a workspace volume.
- Daemon containers run in the background and are destroyed when the workflow leaves the template scope that started them.
Steps, DAGs and control flow
- A steps template is a list of lists: the outer lists run in sequence, the inner lists run in parallel.
- A dag template lists tasks with their dependencies; tasks without dependencies run immediately, which allows maximum parallelism.
- depends takes terms such as task-1.Succeeded or task-2.Failed with boolean logic, and cannot be used together with dependencies in one task group.
- DAGs fail fast by default: after a failure no new tasks are scheduled, unless failFast is set to false.
- when runs a step only if its expression is true; a step whose condition is false is skipped.
- withItems loops over a list written in the spec, withParam over a JSON array (often the output of an earlier step), and withSequence over numbers.
- Templates may invoke each other recursively, as the coin-flip example does under a when condition.
- The default retryPolicy is OnFailure, which retries steps whose main container failed; OnError covers controller errors and failed init or wait containers.
- An exit handler, set with spec.onExit, is a template that always executes at the end of the workflow, whatever the result.
Parameters and artifacts
- Input parameters are read as {{inputs.parameters.NAME}}; in YAML the reference is enclosed in double quotes.
- Values under spec.arguments.parameters are global and read as {{workflow.parameters.NAME}}; argo submit -p name=value overrides them.
- An output parameter takes its value from the content of a file (valueFrom path), not from standard output.
- Outputs of earlier work are addressed with the steps prefix in a steps template and with the tasks prefix in a DAG.
- The output artifacts of one step can be the input artifacts of a later step, which needs an artifact repository such as an S3-compatible bucket.
- Artifacts are packaged as tarballs and gzipped by default; archive with none: {} stores the file as it is.
- A default artifact repository is set in the controller's configuration, or in a config map named artifact-repositories in the workflow's namespace.
Reuse, schedules and housekeeping
- A WorkflowTemplate is a definition of a Workflow that lives in the cluster, a library of templates for a namespace.
- templateRef on a step or task uses one template of a WorkflowTemplate; workflowTemplateRef in the spec creates a whole Workflow from it.
- A ClusterWorkflowTemplate is cluster-scoped and is referenced with clusterScope: true.
- A CronWorkflow runs a workflow on schedules; its concurrencyPolicy is Allow, Replace or Forbid.
- Parallelism can be limited in the controller's configuration and on a workflow or template; mutexes and semaphores are set under synchronization.
- Memoization stores the outputs of a template in a cache under a key, so a repeated step is not run again.
- podGC deletes completed pods, a TTL strategy deletes completed Workflows, and artifactGC deletes artifacts.
- The workflow archive saves completed workflows in a Postgres, MySQL or MariaDB database.
Easy to mix up
- A template (lower case) is one task inside a Workflow; a WorkflowTemplate is a cluster object that holds a reusable Workflow definition.
- result is the standard output of a script or container; an output parameter is read from a file. Larger data belongs in an artifact.
- activeDeadlineSeconds limits how long a workflow may run; a TTL strategy removes it after it has finished; podGC removes only the pods.
- templateRef borrows a single template; workflowTemplateRef takes the entire spec of a WorkflowTemplate.
- A sidecar runs next to the main container in the same pod; a daemon container is a step that keeps running while later steps use it.
- withItems is a list written in the manifest; withParam is a JSON array known only at run time, which is what makes a fan-out dynamic.