Argo CD / Desired state and evidence foundations / Lesson 2

Application identity and desired-state specification

Read an Application as a source, generation, project, destination, and policy contract.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Identify metadata identity separately from managed workload identity.
Review source and destination fields without creating an Application.

The Application is a control object

An Argo CD Application custom resource describes how desired resources are obtained and where they are compared and synchronized. Its metadata name and namespace identify the control object; they do not necessarily equal every managed resource’s name or namespace. Parcel’s Application can live in an Argo CD control namespace while managing resources in parcel-lab. Application placement and applications-in-any-namespace support depend on installation configuration. Do not generalize one example namespace into a complete tenancy architecture or assume naming alone grants access.

Read a concrete non-runnable declaration

The YAML below identifies a synthetic Git source, path, project, and destination. example.invalid is a reserved nonworking teaching domain, and lab-reviewed-ref is a declared label rather than a real verified commit. No repository, project, namespace, or cluster is created. The in-cluster server address is standard illustrative syntax but is never contacted. A real definition requires reviewed source identity, configured destination access, supported CRDs, and an AppProject policy that permits the requested operation.

yaml An illustrative Git-backed Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: parcel-lab
  namespace: argocd
spec:
  project: parcel-lab
  source:
    repoURL: https://example.invalid/parcel-config.git
    targetRevision: lab-reviewed-ref
    path: apps/parcel
  destination:
    server: https://kubernetes.default.svc
    namespace: parcel-lab

This declaration has no automated sync policy and is not applied. Omitted fields use version- and installation-specific behavior; the example is not proof of permissions, source availability, generated objects, or readiness.

Resolve the actual input identity

repoURL identifies a repository location, path selects configuration within a Git source, and targetRevision selects the requested revision according to the source type. A branch or tag can move. Record the resolved immutable revision and relevant rendering inputs when establishing release evidence. A chart source uses different source fields and version semantics than a Git directory. An Application name that stays constant can therefore point to different desired bytes over time. Review spec changes as executable delivery decisions rather than harmless labels.

A namespace field is not a complete boundary

The destination identifies a configured cluster through supported server or name selection and a namespace context. It does not override explicit namespaces on every generated object or make cluster-scoped kinds namespaced. AppProject policy and the destination credential’s Kubernetes permissions still matter. Managing the Argo CD control namespace itself can carry elevated consequences. Treat source, target, resource kind, and allowed operation together. A technically valid resource document can still be unacceptable for a particular project or tenant.

Keep control and managed identities distinct

The complete local model below compares a declared Application identity with one managed resource identity. It demonstrates that different namespace and kind fields are expected rather than automatically an error. It does not parse Kubernetes discovery, apply defaults, validate the CRD, or compute Argo CD ownership. Actual resource identity includes group, kind, namespace where applicable, and name. Preserve that tuple when selecting differences or reviewing deletion candidates; a friendly resource name alone can match unrelated objects in another namespace.

python A synthetic control-versus-workload identity model

application = ("argoproj.io", "Application", "argocd", "parcel-lab")
managed = ("apps", "Deployment", "parcel-lab", "parcel")
print(application == managed)
print(application[2])
print(managed[2])

Expected output

False
argocd
parcel-lab

Only tuples are compared. No CRD, cluster discovery, Argo CD ownership record, or live object is read.

Common errors and fixes

The Application namespace is assumed to be every workload namespace.

Why it happens: Control-object placement was confused with generated resource identity.
How to fix it: Inspect destination context and each generated resource’s scope.
Prevent it next time: Record control and managed identities separately.

A branch label is reported as an immutable release revision.

Why it happens: A movable source selector replaced resolved content identity.
How to fix it: Retain the actual resolved revision and render inputs.
Prevent it next time: Review source changes and mutable selectors explicitly.

A destination namespace is treated as permission to manage all kinds.

Why it happens: Namespace context was confused with project and Kubernetes authorization.
How to fix it: Review permitted resource kinds, destinations, and credential scope.
Prevent it next time: Evaluate source, scope, and operation as one policy decision.

Check your understanding

1. Can one Application manage a Deployment named parcel even though the Application is named parcel-lab?

Show worked solution

Yes under an appropriate valid configuration. The control object and generated resources have separate identities. Verify the source output, ownership, project policy, and destination rather than demanding identical names.

2. Why is the YAML not presented as a complete runnable setup?