What is DevOps? A culture, not a job title
DevOps is a set of practices and a culture that shortens the time between writing code and running it reliably in production, by making development and operations a shared responsibility rather than two teams handing work over a wall. It is not a job title, a team name or a piece of software — though the industry uses the word for all three, which is exactly why it confuses people. At its core, DevOps combines technical practices (automation, continuous delivery, infrastructure as code, monitoring) with a cultural stance (shared ownership of what runs in production, fast feedback, learning from failure without blame). This guide explains where it came from, what the practices actually are, how it relates to neighbouring ideas like SRE, and where DevOps shows up in AWS certification study.
First, what DevOps is not
The most common misconception is worth killing on sight: DevOps is not a job title and not a tool. You will see “DevOps engineer” on job boards and “DevOps tools” in marketing, but the word properly names a way of working — a set of practices and a culture — and hiring one person called a DevOps engineer, or buying one product, does not give an organisation DevOps any more than buying running shoes makes it fit. When a company says it “does DevOps” but its developers still throw code over a wall to a separate operations team, it has adopted the vocabulary and skipped the substance.
That is not pedantry. The whole point of the movement was to dissolve a specific organisational failure, and understanding that failure is the fastest way to understand everything else about DevOps.
The problem it exists to solve
Traditionally, developers were rewarded for shipping changes and operations teams were rewarded for stability — two goals directly in tension. Developers finished features and handed them to an ops team who had no part in building them; ops, burned by past outages, defended production with change freezes and lengthy release processes. The result was slow, risky, infrequent releases: each deployment bundled months of changes, so each one was a high-stakes event, and when something broke, the two teams’ first instinct was to establish whose fault it was.
Add the manual toil — hand-configured servers, deployment checklists run by humans at 2 a.m., environments that differed in undocumented ways — and you get the world DevOps was a reaction against. The insight was that the wall itself was the problem: if the people who build software also share responsibility for running it, the incentives align, and if releases are small, frequent and automated, each one carries far less risk than a quarterly big bang.
The core practices
The technical half of DevOps is a set of mutually reinforcing practices:
- Continuous integration and continuous delivery (CI/CD) — code is merged, built and tested automatically, and can be deployed through an automated pipeline at any time, making releases routine instead of ceremonial.
- Automation — anything done more than once (builds, tests, deployments, environment setup) is scripted, removing manual toil and human error.
- Infrastructure as code — environments are defined in version-controlled files and built by tools, so they are repeatable and reviewable like any other code.
- Monitoring and observability — production is instrumented so teams can see how the system behaves, detect problems early, and feed what they learn back into development.
- Small, frequent releases — shipping little and often keeps each change easy to review, easy to test and easy to roll back.
- Blameless post-mortems — when things fail, the team examines the system and process that allowed the failure rather than hunting for a culprit, so problems get fixed instead of hidden.
The cultural half — the part tools can’t buy
Every practice above can be adopted mechanically and still fail, because DevOps is held together by culture. The load-bearing idea is shared ownership: the people who write a service care about — and are on the hook for — how it behaves in production, which changes how they build it. “You build it, you run it” is the compressed version of this. The second idea is feedback loops: production telemetry, user behaviour and incident learnings flow back to developers quickly, so the system that builds the software keeps improving alongside the software itself.
This is also why blameless post-mortems matter more than they first appear. In a blame culture, engineers hide mistakes and information stops flowing — which is fatal to a way of working built entirely on fast, honest feedback. The cultural half is harder than the technical half, and it is the part no vendor can sell you.
DevOps, SRE and platform engineering
You will meet two neighbouring terms, and the honest description is that they overlap heavily while emphasising different things. Site reliability engineering (SRE), which originated at Google, approaches the same goals from the reliability side: it treats operations as a software engineering problem and adds specific machinery — service-level objectives, error budgets that formally balance release speed against stability — to decide when to ship and when to stabilise. Platform engineering, the more recent term, focuses on building internal platforms and tooling so that product teams can deploy and operate their own services without each team reinventing pipelines and infrastructure; it is one practical way of scaling DevOps ideas across a large organisation.
None of these replaces the others, whatever the think-pieces say. A team can practise DevOps culture, use SRE techniques to manage reliability, and be served by a platform engineering team — the three describe emphases, not rival factions.
On tooling: the landscape is vast and interchangeable in general terms — version control, CI/CD pipelines, IaC tools, container platforms, monitoring stacks. On AWS specifically, the native CI/CD family includes CodePipeline (orchestrating release pipelines), CodeBuild (building and testing) and CodeDeploy (automating deployments), alongside CloudFormation for infrastructure as code and CloudWatch for monitoring. Knowing the categories matters more than memorising any vendor’s catalogue.
DevOps in AWS certification study
DevOps concepts are woven through the AWS certification path rather than confined to one exam. The Developer – Associate (DVA-C02) covers CI/CD pipelines, deployment strategies and the AWS developer tooling directly. The CloudOps Engineer – Associate (SOA-C03) approaches the same ground from the operations side — automation, monitoring, and managing environments as code. The dedicated credential is the AWS Certified DevOps Engineer – Professional, which assumes associate-level knowledge and tests the full discipline in depth; it is the natural destination if this way of working is the career you want. If you are earlier in the journey, the practical advice is simple: learn the concepts here, then let the associate exams give you the structured, hands-on depth — the culture makes far more sense once you have built and monitored a pipeline yourself.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.