Declarative vs Imperative Resource Management Concepts

Welcome back. In this lesson we compare declarative and imperative approaches to resource management — how resources are defined, provisioned, and maintained under each paradigm. These concepts are foundational for platform engineering, GitOps-driven platforms, and reproducible infrastructure. If you’re already familiar with them, skip ahead to the examples and best practices. Why this matters

Many teams still rely on manual, procedural operations (imperative), which can cause drift and poor auditability.
Modern platform strategies emphasize GitOps, versioned automation, and self-service to improve reproducibility.
Using step-by-step commands as the long-term source of truth increases risk, reduces reusability, and makes auditing harder.

Imperative: Tell the system how

Imperative operations are procedural: you issue explicit commands that execute steps in sequence. This gives direct control and immediacy, but you must manage idempotency, state checks, and guards to avoid duplicates when re-running commands. Imperative workflows are useful for quick intervention and debugging, but they do not scale well for repeatable platform operations.

Common imperative actions:

Running cloud provider CLI commands (for example: aws ec2 run-instances).
Creating resources ad hoc with kubectl create commands.
Clicking through a cloud console to configure a VM or security group.

Imperative kubectl example These imperative commands create and update a Kubernetes Deployment and check rollout status:

kubectl create deployment frontend --image=sparkle-pony:v2.1 --replicas=3
kubectl expose deployment frontend --port=80 --target-port=8080
kubectl scale deployment frontend --replicas=5
kubectl rollout status deployment/frontend

Drawbacks of imperative workflows

Not inherently repeatable unless you capture and version the commands.
Limited auditability compared to version-controlled manifests.
Higher risk of configuration drift when changes are made manually.

Declarative: Tell the system what you want

Declarative workflows express the desired state: you describe the end goal and a reconciler (control loop) ensures the system reaches and maintains that state. Re-applying the same manifest is idempotent — it will not create duplicates if the desired state already exists. Declarative approaches are the backbone of GitOps and platform-as-a-product.

Examples of declarative formats

Kubernetes YAML manifests
HashiCorp HCL (Terraform) — a popular declarative tool for cloud resources
CloudFormation / ARM templates

CloudFormation-style example (declarative) The following declarative YAML snippet (CloudFormation-style) defines a security group and an EC2 instance associated with that security group:

Resources:
  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: web-sg
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0

  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-12345
      InstanceType: t3.medium
      SecurityGroupIds:
        - !Ref WebSecurityGroup

Benefits of declarative manifests

Version-controlled, repeatable, and auditable.
Easy to roll back to previous revisions.
Prevents ad-hoc manual steps that can be forgotten or misapplied.

Kubernetes declarative example A Deployment manifest declares the desired number of replicas and the container spec. Editing replicas and reapplying the manifest causes the cluster reconciler to converge to the desired scale.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
        - name: frontend
          image: sparkle-pony:v2.1
          ports:
            - containerPort: 8080

Re-applying after changing replicas: 5 will cause Kubernetes to scale the Deployment to five replicas. These manifests are easily reviewed, shared, and integrated into GitOps workflows.

A presentation slide titled "Declarative Applications: Kubernetes Manifests" showing five colorful gear icons numbered 01–05 under the heading "Advantages." Each gear lists a benefit: Version-controlled manifests, Enables GitOps workflows, Repeatable deployments, Consistent application state, and Easier collaboration.

Quick comparison

Aspect	Imperative	Declarative
Approach	Step-by-step commands	Desired-state manifests
Idempotency	Must be managed manually	Built-in when reapplying manifests
Auditability	Limited unless logged	High (version control + review)
Best for	One-off tasks, debugging, emergency fixes	Long-lived platform management, GitOps
Examples	`aws`, `az`, `gcloud`, `kubectl create`	Kubernetes YAML, Terraform HCL, CloudFormation

Platform engineering best practices (favor declarative)

Store manifests in Git for versioning, code review, and history.
Use continuous reconciliation (GitOps) to detect and correct drift between Git and live systems.
Maintain audit trails for repository changes and observed cluster state.
Treat the platform as a product: expose self-service APIs and portals so teams can deploy safely.

When to use imperative

Imperative commands remain valuable in specific scenarios:

Debugging and incident response (quick fixes, live troubleshooting).
Emergency hotfixes or emergency scaling when immediate intervention is required.
Experimenting interactively before codifying a change as a manifest.

Common imperative debug commands:

Purpose	Command
Inspect logs	`kubectl logs <pod-name>`
Describe resource	`kubectl describe pod <pod-name>`

Use imperative commands for short-term intervention and troubleshooting. Any permanent or repeatable change should be captured back into the declarative repo so Git remains the source of truth.

Strategic use of imperative within a declarative platform

Teams should let the platform hide complexity and favor automation via declarative manifests and GitOps. For example, within a platform team (e.g., Sparkle Pony Ranch), developers and platform engineers should:

Use declarative, version-controlled manifests for day-to-day deployments.
Rely on automated reconciliation to ensure consistency and fix drift.
Use imperative commands sparingly for emergency changes, rollbacks, or experiments — and then record those changes back in Git to avoid long-term drift.

A presentation slide titled "Platform Engineering – Strategic Use of Imperative" with a "Sparkle Pony Ranch" tag. It shows avatars labeled Swati, Alan, and Phuong alongside notes about using imperative commands for quick fixes and scaling, rollbacks to stabilize issues, and making temporary changes followed by declarative updates.

Summary

Declarative approaches (desired-state manifests, GitOps) are preferred for platform engineering because they provide repeatability, auditability, and automated drift correction.
Imperative approaches are useful for immediate control and troubleshooting but should be used sparingly and reconciled back into the declarative workflow.
Choose the right tool: declarative for long-term, repeatable platform management; imperative for short-term diagnostics and emergency response.

A presentation slide titled "Declarative vs Imperative Infrastructure." It shows two side-by-side panels comparing imperative (command-driven, direct resource changes, can cause inconsistencies) and declarative (desired-state, managed as code, ensures consistency and supports version control) approaches.

Pre-requisites

Domain 1 - Platform Engineering Core Fundamentals

Domain 2 - Platform Observability, Security, and Conformance

Domain 3 - Continuous Delivery & Platform Engineering

Domain 4 - Platform APIs and Provisioning Infrastructure

Domain 5 - Internal Developer Platforms & Developer Experience

Domain 6 - Measuring Your Platform

Mock Exams & Final Prep

Declarative vs Imperative Resource Management Concepts

Imperative: Tell the system how

Declarative: Tell the system what you want

Quick comparison

Platform engineering best practices (favor declarative)

When to use imperative

Strategic use of imperative within a declarative platform

Summary

Watch Video

​Imperative: Tell the system how

​Declarative: Tell the system what you want

​Quick comparison

​Platform engineering best practices (favor declarative)

​When to use imperative

​Strategic use of imperative within a declarative platform

​Summary

Watch Video

Imperative: Tell the system how

Declarative: Tell the system what you want

Quick comparison

Platform engineering best practices (favor declarative)

When to use imperative

Strategic use of imperative within a declarative platform

Summary