Argo CD Mock Interview Pack
Figure: Argo CD security interview map.
Intro: This pack uses GitOps scenarios to test whether the candidate understands that Argo CD is not just a convenient deploy UI. It is a trust broker between Git, cluster permissions, and operational automation.
What this page includes
- five scenario-based Argo CD security tasks
- structured solutions and interviewer notes
- emphasis on AppProjects, ApplicationSets, RBAC, and safe automation boundaries
Working assumptions
- strong answers describe how Git trust, Argo trust, and cluster trust align or break apart
Task 1 - Everything still deploys under the default project
Scenario
Most applications in Argo CD still use the default project. The project has broad repository access, broad destination access, and little restriction on cluster-scoped resources.
Prompt
Explain the risk and outline a safer target model.
Reveal the worked answer
Step-by-step solution
- Explain that AppProjects define the effective deployment trust boundary.
- Break workloads into projects aligned to team, environment, or risk boundary.
- Restrict trusted repositories, destination clusters and namespaces, and allowed resource kinds.
- Move high-risk resources such as RBAC or cluster-wide objects behind stricter project boundaries.
- Review project roles and map them to real team identities.
Explanation
If the default project is too broad, Argo CD can become a platform-wide privilege bridge. A compromise in Git, repo credentials, or Argo permissions can then affect far more than one application.
Common mistakes
- assuming namespace separation alone is enough;
- creating many projects but keeping them all effectively identical;
- forgetting project roles and RBAC after project creation.
Task 2 - ApplicationSet with templated project field
Scenario
An ApplicationSet uses a Git generator and templates the project field. Many developers can submit pull requests to the source repository.
Prompt
What is the security concern and how would you respond?
Reveal the worked answer
Step-by-step solution
- Explain that a templated project field can let users generate applications under more privileged projects.
- Restrict who may create or modify ApplicationSets.
- Ensure the source of truth for templated project assignment is admin-controlled.
- Require high-trust review for changes affecting generator behavior and project selection.
- Prefer simpler, less privilege-sensitive generation models where possible.
Detailed explanation
ApplicationSet is powerful precisely because it can create many Applications quickly. That same power means project selection, generator source, and repository credentials must be treated as privileged design elements, not mere convenience knobs.
Common mistakes
- letting any repo maintainer change generator logic;
- focusing only on Git webhook authentication while ignoring generator privilege;
- assuming Argo CD RBAC alone offsets an overpowered ApplicationSet design.
Task 3 - Overly broad repo credentials and repo trust
Scenario
Argo CD stores credentials that can read many repositories, including ones that should not all be equally trusted. Repo credentials are reused broadly for convenience.
Prompt
How would you reduce the risk?
Reveal the worked answer
Step-by-step solution
- Inventory which repositories each project actually needs.
- Reduce credential scope and avoid unnecessary shared credentials.
- Align trusted repositories with AppProject boundaries.
- Review whether repository sources are mutable or floating in unsafe ways.
- Treat repo credential changes as privileged administrative actions.
Why it matters
If repo access is too broad, compromise of one trust path may expose manifest sources or automation inputs that affect many applications. GitOps is only as trustworthy as the repositories and credentials behind it.
Common mistakes
- assuming “read-only” repo access is harmless;
- keeping one credential for many unrelated trust domains;
- forgetting to review floating refs or unreviewed source changes.
Task 4 - Local admin user and weak default RBAC
Scenario
Argo CD still relies heavily on the built-in admin user. The default RBAC policy gives authenticated users more access than intended, and SSO mapping is incomplete.
Prompt
Walk through a better identity model.
Reveal the worked answer
Step-by-step solution
- Limit use of the built-in admin user to initial setup or tightly controlled break-glass situations.
- Configure SSO or well-governed local users with explicit roles.
- Reduce the default authenticated role to the minimum practical permission set.
- Bind Argo roles to real team identities and project ownership.
- Log and review privileged access regularly.
Explanation
Argo CD identity weakness often hides in defaults: a powerful built-in admin, over-broad default policy, or local users with vague ownership. A mature answer recognizes that GitOps security includes the control plane identity path, not only repo trust.
Common mistakes
- leaving default policy broad because SSO rollout is incomplete;
- using local users as permanent admin convenience;
- ignoring the need for project-scoped roles.
Task 5 - Auto-sync into production with no safety window
Scenario
Production applications use automated sync with broad rights. There are no sync windows or controlled pauses for change-sensitive periods.
Prompt
How would you introduce safer release control without abandoning GitOps?
Reveal the worked answer
Step-by-step solution
- Distinguish low-risk reconciliation from high-impact production changes.
- Use project design and RBAC to limit who can alter production sources.
- Introduce sync windows or equivalent release timing controls for sensitive environments.
- Preserve rollback and emergency override procedures.
- Ensure that Git review, Argo permissions, and cluster permissions are consistent with the new release model.
Why it matters
GitOps should reduce unsafe manual drift, but it should not erase the idea of production change control. The goal is disciplined automation, not uncontrolled automation.
Common mistakes
- disabling automation completely rather than shaping it;
- using manual sync as the only safety mechanism;
- forgetting that repo change authority is part of production authority.