5 exercises — Practice platform engineering vocabulary in English: Internal Developer Platforms, golden paths, DORA metrics, cognitive load, and Team Topologies.
Core Platform Engineering vocabulary clusters
IDP concepts: Internal Developer Platform (IDP), golden path, paved road, scaffolding, service template, self-service portal, software catalogue
Team Topologies: stream-aligned team, platform team, enabling team, complicated-subsystem team, cognitive load, team API
Developer experience: DORA metrics (deployment frequency, lead time, change failure rate, MTTR), toil, developer joy, SPACE framework
Metrics: deployment frequency, lead time for changes, cognitive load reduction, toil percentage, platform adoption rate
0 / 10 completed
1 / 10
A platform engineer explains their team's mission: "We're building an Internal Developer Platform — an IDP. The goal is to give every engineering team a golden path: an opinionated, well-supported route to deploy a service. If you follow the golden path, you get security, observability, CI/CD, and infrastructure out of the box. You can deviate, but you're on your own." What is a golden path in platform engineering?
Golden path (also: paved road, happy path): an opinionated, well-maintained default way of building and deploying services. Reduces cognitive load by encoding best practices into templates and tooling. Platform vocabulary: IDP (Internal Developer Platform) — a curated set of tools, workflows, and self-service capabilities that platform teams build for application developers. NOT a portal — a platform. Self-service portal — the UI layer of an IDP where developers provision infrastructure, deploy services, view their service catalogue entry, etc. Service template / scaffolding — a starter project with the golden path already wired in (CI/CD, logging, tracing, auth). Software catalogue — a registry of all services, their owners, docs, and runbooks. Backstage (by Spotify) is the most widely used open-source software catalogue. Tech radar — a visual tool (ThoughtWorks model) categorising technologies into Adopt, Trial, Assess, Hold. In conversation: "We want 80% of new services to start from the golden path template — that way we know they're all instrumented correctly from day one."
2 / 10
An engineering director presents Team Topologies at an all-hands: "We're reorganising around four team types. Stream-aligned teams own end-to-end delivery of a product area. The platform team builds the internal platform that reduces cognitive load on stream-aligned teams. Enabling teams help stream-aligned teams adopt new capabilities. Complicated-subsystem teams own components that require deep specialist knowledge." What is the primary purpose of a platform team in Team Topologies?
Platform team: builds and operates an internal platform that stream-aligned teams consume as a service. The key value: reducing cognitive load so product teams can focus on user value. Team Topologies vocabulary (Matthew Skelton & Manuel Pais): Stream-aligned team — aligned to a flow of business value; owns a product area or customer journey end-to-end; the primary team type. Platform team — provides a compelling internal product that stream-aligned teams consume. Treats platform as a product. Enabling team — temporary team that helps stream-aligned teams acquire new capabilities (e.g., adopt Kubernetes, migrate to event-driven architecture) then dissolves or moves on. Complicated-subsystem team — owns a component requiring deep specialist knowledge (e.g., video processing, ML inference, cryptography). Cognitive load — the total mental effort a team must carry to do their job. Platform teams reduce cognitive load by abstracting away infrastructure complexity. Team API — how a team communicates its purpose, interaction modes, and services to other teams. In conversation: "The platform team's north star is developer experience — if stream-aligned teams need to understand Kubernetes internals to deploy, we've failed."
3 / 10
A VP of Engineering reviews platform metrics: "DORA metrics are the gold standard for measuring software delivery performance. We track four: deployment frequency, lead time for changes, change failure rate, and MTTR. Right now we're in the 'Medium' band — we deploy weekly, lead time is 1–2 weeks. The goal is to get to 'Elite' — multiple deploys per day, lead time under an hour." What does lead time for changes measure in DORA metrics?
Lead time for changes: the time from code commit to running in production. One of the four DORA metrics. DORA metrics vocabulary: Deployment frequency — how often the team deploys to production. Elite: multiple times per day. High: weekly–daily. Medium: monthly–weekly. Low: once per 6 months or less. Lead time for changes — commit → production. Elite: <1 hour. High: 1 day–1 week. Medium: 1–4 weeks. Change failure rate — % of deployments that cause a production failure requiring a fix, rollback, or hotfix. Elite: 0–5%. MTTR (Mean Time to Recovery) — how long to restore service after a failure. Elite: <1 hour. SPACE framework (GitHub Research) — Satisfaction, Performance, Activity, Communication/Collaboration, Efficiency. Wider developer productivity framework. Toil (Google SRE) — repetitive, manual, automatable operational work that scales with service growth. In conversation: "Our lead time is 3 weeks because of manual approval gates — automating those would move us to High performer."
4 / 10
A platform engineer explains their service template strategy: "Every new microservice starts from our Backstage scaffolder template. It comes pre-wired with structured logging, distributed tracing, Prometheus metrics, a Dockerfile, a Helm chart, a GitHub Actions CI pipeline, and a PagerDuty integration. The developer just answers a few questions and gets a repo with everything configured." What is scaffolding in the context of a developer platform?
Scaffolding: automated generation of a project's initial structure from a template. The output is a working skeleton with all standard integrations already wired in. Platform tooling vocabulary: Backstage — open-source developer portal by Spotify. Core features: software catalogue, TechDocs (docs-as-code), scaffolder (template-based project creation), plugins. Scaffolder template — a Backstage template (in YAML) that generates a new service repo with all golden-path integrations. Service catalogue — a single pane of glass showing all services, owners, dependencies, SLOs, and runbooks. Crossplane — Kubernetes-native infrastructure provisioning; platform teams use it to let developers self-serve cloud resources via CRDs. Port, Cortex — commercial alternatives to Backstage. Score.dev — a workload spec that abstracts away platform specifics so developers write platform-agnostic service definitions. In conversation: "When a developer creates a service from the scaffolder, they get 2,000 lines of infrastructure config they never have to write or maintain — that's the platform value."
5 / 10
A platform team lead defines success metrics for the quarter: "We measure platform adoption as the percentage of services using the golden path. We're at 60% — up from 30% last quarter. We also measure toil: the percentage of platform team time spent on repetitive, manual, non-engineering work. Our goal is to keep toil under 20% of our time so we can actually build the platform." In SRE/platform vocabulary, what is toil?
Toil (Google SRE definition): manual, repetitive, automatable work tied to running a service in production. Properties of toil: manual (requires human execution), repetitive (done again and again), automatable (a machine could do it), tactical (no enduring value — it's done and immediately needs doing again), scales with service growth (more services = more toil). Examples: manually restarting a crashed service, rotating secrets by copy-pasting, resizing a disk because autoscaling isn't set up, approving deployments in a ticket queue. Toil budget: Google SRE recommends keeping toil below 50% of an SRE's time. Platform teams track it to ensure they're building automation rather than becoming a human switchboard. Platform adoption metrics: Golden path adoption rate — % of services using the standard template. MTTR for platform issues. Developer satisfaction (DevEx survey NPS). Self-service rate — % of resource provisioning done without platform team intervention. In conversation: "If toil is above 50%, the team is an operations team, not a platform team — we need to automate our way out."
6 / 10
During a code review of a new service deployed via the IDP, Alice notices the service lacks proper error handling. Bob replies: 'Don't worry about it; we can add a try/catch block.' What does Bob's comment highlight regarding the importance of platform engineering principles?
Bob's comment demonstrates a misunderstanding of the 'golden path' concept. The IDP provides an opinionated configuration to reduce toil and ensure consistency; deviating from this requires explicit justification and carries greater responsibility for managing potential issues. Option A is irrelevant – automated testing should be part of the CI/CD pipeline, not a replacement for proper error handling.
7 / 10
In a Slack channel discussing the rollout of a new feature, Sarah (a platform engineer) receives a message from David (a developer): 'I've deployed this to staging and it's working great. Let me know if anything goes wrong.' What does David's statement indicate about his understanding of the IDP's observability features?
David's statement reveals a misunderstanding about the IDP's purpose. The platform provides tools (like Prometheus) to enable *self*-monitoring – David is responsible for actively checking on his deployment and reacting to any issues. The IDP doesn't automatically fix problems; it equips developers with the data they need to manage them.
8 / 10
A PR description for a change to the IDP's service template states: 'This update adds support for gRPC and improves performance.' What does this primarily represent from a platform engineering perspective?
This PR description highlights a strategic decision driven by the IDP's overall architecture. The platform team isn't just responding to individual requests; they are proactively updating the template to maintain its relevance and support modern technologies. Adding gRPC and improving performance directly contributes to the 'golden path' and reduces toil for developers.
9 / 10
During a standup meeting, Mark (a platform engineer) says: 'We're currently spending 30% of our time on tasks like setting up new developer environments and managing individual service configurations.' What does Mark describe?
Mark's statement directly identifies 'toil'. Toil represents the time spent on non-engineering activities that detract from building and improving the platform itself. Reducing toil is a key metric for measuring platform team efficiency and enabling them to focus on strategic initiatives.
10 / 10
The platform team's goal is to reduce service lead times from 2 weeks to under an hour. Which DORA metric would they primarily focus on improving?
Lead time for changes measures the total elapsed time from code commit to production. Reducing this directly impacts service delivery speed and aligns with the 'Elite' DORA band target of under an hour. While all metrics are important, lead time is the most immediate indicator of whether they're achieving their goal.
What does the "Platform Engineering & IDP Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to platform engineering & idp vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 6 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.