Cloud & Infrastructure: SFIA levels and developer seniority

At this stage evidence is about following well, not deciding: notes or logs from runbooks you executed for a deploy, a foundational certification like AWS Cloud Practitioner, or a small deploy you completed with someone checking your steps.

Getting a foundational cloud certification is worth doing early, since it gives you the vocabulary the rest of the level depends on. Shadow a production deploy start to finish, and spend time in a sandbox account learning the practical difference between compute, storage, and networking rather than just the definitions.

The evidence shifts toward configuring things yourself: tickets where you set up a pre-defined cloud service, a dashboard or alert you built and maintained, or change requests you completed by following a documented procedure without needing to ask what came next.

A good next step is writing your first small infrastructure-as-code module for something you'd normally click through the console, taking ownership of one service's monitoring dashboard so it's clearly yours, and shadowing an incident end to end so you see how the pieces you configure actually fail.

Here the evidence is design, not just configuration: an infrastructure-as-code module or environment you designed and ran in production, a cost optimisation you found and shipped with the before-and-after numbers to prove it, or a security control, an IAM policy or network rule, you configured without being told to.

Owning an environment end to end, build, deploy, monitoring, and cost, together rather than separately, is usually what pushes this forward. Move away from console changes entirely and write infrastructure-as-code for everything you touch, and run a small cost or security audit on something you own just to see what you find.

At this level the evidence is a change you led, not just executed: a migration, a lift-and-shift or a move to Kubernetes, from plan to completion, a cloud architecture decision record with your name on it, or other engineers routing cloud questions to you by default.

Propose and lead a migration or a significant infrastructure change yourself rather than waiting to be assigned one. Set a cost or security standard your team actually follows, and write down the reasoning the next time you choose a cloud service, since that document is often more valuable than the decision itself.

The evidence here spans the organisation: a multi-cloud or FinOps programme you defined, a governance framework other teams adopted, or being the person other teams escalate to when a cloud strategy question comes up that nobody else can answer.

Write a cloud strategy document that spans more than one team, build a FinOps reporting process the organisation actually uses rather than one that sits in a wiki, and start mentoring other cloud leads, since at this level your impact is increasingly what other people do because of you.

At the top, the evidence is transformation at scale: an organisation-wide cloud shift you drove, external recognition through talks, published architecture, or certification design work, or a cloud roadmap for the whole company that traces back to your decisions.

From here, publish your cloud strategy thinking externally, own the organisation's cloud roadmap directly, and expect to spend more time representing infrastructure at the leadership table than writing infrastructure yourself.