Platform Engineer

# Golden paths ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Design safe defaults with escape hatches instead of forcing one workflow. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Templates, Backstage ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Templates] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Golden paths
TOOLS: Templates, Backstage

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Platform architecture ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Separate control plane, paved roads, service templates, and shared capabilities. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Architecture diagrams ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Architecture diagrams] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Platform architecture
TOOLS: Architecture diagrams

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Infrastructure modules ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Build composable network, identity, compute, and data modules with clear contracts. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Terraform ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Terraform] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Infrastructure modules
TOOLS: Terraform

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Kubernetes foundations ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Understand the API server, scheduler, controllers, pods, and reconciliation. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Kubernetes ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Kubernetes] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Kubernetes foundations
TOOLS: Kubernetes

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Helm and packaging ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Create configurable, versioned charts with safe defaults and upgrades. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Helm ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Helm] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Helm and packaging
TOOLS: Helm

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# GitOps reconciliation ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Make Git the auditable source of desired platform state. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Argo CD, Git ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Argo CD] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: GitOps reconciliation
TOOLS: Argo CD, Git

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Policy as code ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Enforce security, cost, and reliability rules close to the change. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools OPA, Kyverno ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[OPA] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Policy as code
TOOLS: OPA, Kyverno

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Identity and access ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Design workload identity, least privilege, tenancy, and break-glass access. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools IAM, OIDC ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[IAM] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Identity and access
TOOLS: IAM, OIDC

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Self-service environments ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Provision preview and ephemeral environments with cleanup and quotas. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Terraform, Kubernetes ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Terraform] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Self-service environments
TOOLS: Terraform, Kubernetes

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Platform observability ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Measure platform availability, provisioning time, failures, and adoption. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Prometheus, Grafana ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Prometheus] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Platform observability
TOOLS: Prometheus, Grafana

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Cost-aware platforms ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Expose cost drivers and add budgets, quotas, rightsizing, and chargeback signals. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools AWS, Kubecost ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[AWS] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Cost-aware platforms
TOOLS: AWS, Kubecost

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Upgrade operations ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Plan Kubernetes, provider, module, and dependency upgrades with rollback. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Kubernetes, Renovate ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Kubernetes] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Upgrade operations
TOOLS: Kubernetes, Renovate

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Platform roadmap ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Prioritize capabilities by developer impact, risk reduction, and operational cost. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Product metrics ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Product metrics] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Platform roadmap
TOOLS: Product metrics

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off

# Platform capstone ## Outcome By the end of this chapter you can explain and apply the core ideas in a small, testable lab. ## Explanation Build a golden path that creates, deploys, observes, and retires a service. Connect the concept to the user, operator, and failure-mode impact. Start with the smallest working example, then add validation, observability, and recovery. ## Tools Backstage, Argo CD ## Guided lab 1. Write down the input, expected behavior, and measurable success condition. 2. Build the smallest example and run it locally. 3. Introduce one realistic failure or invalid input. 4. Observe the result, fix the issue, and document the trade-off. ## Architecture ```mermaid flowchart LR User[User or operator] --> App[Platform Engineering] App --> Control[Backstage] Control --> Signal[Logs, metrics, tests] Signal --> Decision[Verify, recover, improve] ``` ## Checkpoint Explain the concept in your own words, show the lab result, and name one production risk before marking this tutorial complete.

GOAL: Platform capstone
TOOLS: Backstage, Argo CD

CHECKLIST
[ ] Define the inputs and success signal
[ ] Build the smallest working example
[ ] Validate failures and unsafe input
[ ] Add a log, metric, or test
[ ] Document rollback or recovery
[ ] Explain one trade-off