From Systems to Agentic DevOps

Infrastructure concepts become easier to explain when you can follow the same application across them. This journey uses MicroBank, a polyglot banking application using simulated data, to connect system behavior, delivery, platform capabilities, and agent-assisted operations.

Study at your own pace. Begin with the chapter that matches your current question, then use the linked learning bite or lab for the full explanation, prerequisites, exercise, and checkpoint. This page connects the existing curriculum; it does not replace its learning outcomes or mark an exercise complete.

Choose the next foundation

1. Systems Foundations
2. Cloud Foundations
3. DevOps Foundations
4. Production DevOps & SRE
5. Platform Engineering
6. Agentic DevOps

The cloud path develops the introductory context used in DevOps into an operating design. Production DevOps & SRE supplies deeper data and operations work. Agentic DevOps begins only after a supported platform workflow is defined.

Start with the application contract

The DevOps implementation guide pins MicroBank revision f75da680251eebeb38bf17bce3e49b2fea8385c0. In that reference, Accounts stores a request and its outbox event, a publisher sends through SNS/SQS, and Ledger later records the entry and balance. The optional browser is separate from the required local API check.

At that revision, Accounts can remain pending after Ledger records the operation because an Accounts settlement consumer is absent. The guide also identifies missing backend authorization, sample frontend notifications, and missing frontend Ledger-balance retrieval. These are version-specific observations. Inspect a newer application branch before carrying them forward as current findings.

Use synthetic data in the dedicated local environment. A health response, image build, or diagram answers a different question from a verified transaction. Retain the selected source revision, artifact identity, environment, case identifier, actual result, and remaining limitations.

Systems engineering

Learn to explain where the request goes, which process handles it, what the runtime isolates, and where data lives. The Systems foundations path supplies longer explanations and exercises. Its MicroBank readiness project collects the system map, local fixture, diagnostic, and startup/recovery evidence before the full application runs. The selected public observation URL is https://microbank.learnwithsk.dev/; a response there must be distinguished from backend transaction evidence.

| Concept | MicroBank example | Read and practise | | --- | --- | --- | | Follow one deposit | Use the topology and a prepared synthetic case. | Explanation and practice | | Code needs a process | In the prepared, dedicated local profile, record an Accounts health request, stop only Accounts, repeat it, then start Accounts and wait before retrying. | Explanation and practice | | What a container shares | Use an original labelled diagram of the Mac, Linux runtime environment, and two application containers. | Explanation and practice | | Read permissions first | Use the permission lab fixture rather than exposing runtime values. | Explanation and practice | | Whose localhost is this? | Compare the host-side Accounts URL with the container-side database hostname in the documented profile. | Explanation and practice | | Where does the data live? | Follow the restart checks in MicroBank 7 using an already verified case. | Explanation and practice | | Which change are we running? | Review one small non-schema change, record the actual commit, and compare it with the image record from the prepared lab. | Explanation and practice |

Cloud & DevOps

Use DevOps Foundations for the local implementation and the Production DevOps & SRE path for database, Kubernetes, GitOps, observability, and recovery depth. Floci models selected cloud APIs; its results do not establish real AWS authorization or managed-service behavior.

| Concept | MicroBank example | Read and practise | | --- | --- | --- | | Local cloud is a model | Highlight Floci in the actual topology and label every result local. | Explanation and practice | | Who made that cloud request? | Use the account-free identity exercise to map publisher → Publish → intended topic. | Explanation and practice | | Package the runtime | Walk through the guide’s Accounts image and Ledger multi-stage Dockerfile. | Explanation and practice | | Started is not ready | Trace the documented Compose → Terraform → Ansible → APIs sequence. | Explanation and practice | | Why a topic and a queue? | Trace the requested-event route from the Terraform configuration to the Ledger consumer. | Explanation and practice | | Save the work to publish | Inspect TransactionService and the outbox publisher at the pinned revision. | Explanation and practice | | Give resources one owner | Use the dedicated profile, inspect the nine-resource plan and apply only in the intended local emulator. | Explanation and practice | | Pass outputs into configuration | Use real local Terraform outputs and run the documented Ansible playbook twice. | Explanation and practice | | Verify the user outcome | Run the documented local-only probe against the prepared profile, preserve the new case file, and record the actual matching-entry and 1,000-cent balance result. | Explanation and practice | | What did the retry prove? | Capture the two sequential requests from the existing probe and the resulting identifiers. | Explanation and practice | | What a green build proves | Read the manual GitHub Actions workflow and pair each step with its claim. | Explanation and practice | | Promote the same artifact | Follow the reviewed artifact handoff from MicroBank 6. | Explanation and practice | | Keep a real recovery target | Rehearse the guide’s rollback only after retaining two real artifacts and a verified case. | Explanation and practice | | Follow the same operation | Use one saved synthetic case to construct an evidence timeline. | Explanation and practice | | Measure a complete result | Use the existing SLI calculator with labelled fixture outcomes or recorded local checks. | Explanation and practice | | Declare the workload | Complete the existing kind baseline first. | Explanation and practice | | GitOps needs a selected revision | Follow the existing manual-sync Argo CD lab. | Explanation and practice | | Detection is not correction | Use the documented Argo CD drift exercise with a harmless annotation. | Explanation and practice |

Platform Engineering

Use the Platform Engineering path to turn working operations into supported developer capabilities. Start with developer needs and ownership. A portal can expose the capabilities after their underlying workflows work.

| Concept | MicroBank example | Read and practise | | --- | --- | --- | | Start with developer friction | Use the platform contract lab to observe one manual MicroBank configuration change. | Explanation and practice | | Define what is supported | Complete the existing service-contract template from inspected values. | Explanation and practice | | Who owns this service? | Prepare service records for Accounts and Ledger using the catalogue lab. | Explanation and practice | | A golden path is supported | Trace the existing supported local configuration workflow and record its owner, prerequisites, checks, failure response, and version. | Explanation and practice | | A request is not a deployment | Use the Backstage capstone’s annotation-only request or equivalent Port contract. | Explanation and practice | | A name is not isolation | Render the existing local, EKS, and GKE overlays offline and record differences. | Explanation and practice | | Check where changes can fail | Run the existing Kyverno offline positive and negative fixtures. | Explanation and practice | | Trace private configuration | Inspect the local runtime-file and Secret handoffs without printing values. | Explanation and practice | | What permits promotion? | Construct an evidence record for one selected local candidate. | Explanation and practice | | Templates have a lifecycle | Use a harmless change in a versioned reusable workflow or documented template fixture. | Explanation and practice | | Support the exception | Use the policy exception fixtures or a design record based on actual resource measurements. | Explanation and practice | | Who cleans up the environment? | Review the existing scoped cleanup plan without deleting retained evidence. | Explanation and practice | | Did the platform help? | Repeat the Day 26 task after the supported workflow is available. | Explanation and practice |

Agentic DevOps

Extend the bounded-automation lesson with the design and evaluation sequence below. These are proposed exercises, not an installed agent integration. Begin with offline, clearly labelled fixtures before any authorized local execution.

| Concept | MicroBank example | Read and practise | | --- | --- | --- | | Give the agent a bounded job | Design a provider-neutral tool interface for the local synthetic case. | Explanation and practice | | Separate facts from hypotheses | Use labelled offline fixtures or a separately prepared local scale-to-zero exercise. | Explanation and practice | | Logs cannot grant permission | Insert a benignly labelled malicious instruction into an offline sanitized log fixture. | Explanation and practice | | Make the proposal reviewable | Generate a proposed patch against a fixed local Ledger Deployment fixture or the selected GitOps file. | Explanation and practice | | Approval belongs to one action | Test a fixed-target executor offline first: one matching approval succeeds in the fixture, altered target/revision and reused approval fail. | Explanation and practice | | Check the recovered outcome | Verify the intended revision, Ledger readiness, and the existing case through the local probe. | Explanation and practice | | Evaluate action and restraint | Use the six-case offline evaluation matrix before any controlled local execution. | Explanation and practice |

One controlled agent scenario

Prepare a local scenario in which a recorded configuration change sets the Ledger Deployment to zero replicas. Keep one saved synthetic transaction case. The agent first reads fixed-target evidence and distinguishes observations from hypotheses. It may then propose a narrow diff restoring the supported single replica, including its evidence and verification plan.

The proposal has no authority to execute. An independent execution component must bind human approval to the actor, target, exact parameters, reviewed revision, expiry, and replay state. Follow the existing delivery workflow, including the selected GitOps revision and manual synchronization rules. If verification fails, stop and escalate instead of improvising another change.

Evaluate healthy service, stopped Ledger, unavailable database, missing evidence, malicious instructions inside retrieved logs, and replayed approval. Score factual accuracy, justified escalation, unauthorized-action attempts, independently verified recovery, tool calls, elapsed time, and model cost. A correct no-change decision is a useful outcome.

OWASP agent security guidance explains tool scope, authorization outside the model, approval integrity, and adversarial testing.

GitOps details to retain

The existing Argo CD exercise pins a reviewed commit and uses manual synchronization. Merging another commit does not itself select or deploy it. Automatic correction of live drift also depends on the configured self-healing policy. Argo CD synchronization documentation

Flux provides another reconciliation model for declared resources. Study its source and reconciliation concepts as a comparison, and keep one reconciler responsible for a given workload. Flux concepts

Keep the evidence with the lesson

Explain one concept, perform one bounded example, and state what the result proves. Use the longer lab to prepare the environment and investigate failures. Keep measured results separate from diagrams, illustrative values, and proposed extensions.

Return to the Focused Study Workspace for the original module sequence, notes, completion tracking, and lab checkpoints.

Repository ownership

MicroBank owns application code and its application tests. Ship Boring Lab is the selected home for infrastructure as code, configuration management, bootstrap, GitOps, and Backstage configuration: infra/terraform/, infra/ansible/, and gitops/.

Keep ownership explicit. Terraform manages infrastructure resources; Ansible manages host configuration and bootstrap; the selected GitOps controller owns the handed-over Kubernetes desired state. Ansible and GitOps must not continually reconcile the same object. Record the actual repository revision and verification before describing a capability as implemented.

The existing infra/study examples in the pinned MicroBank guides are an isolated course fixture. They remain reproducible reference exercises, not a second authoritative owner for the operating platform. Adopt the relevant configuration into Ship Boring Lab deliberately, with separate state and a reviewed ownership handoff.