Career Hub
Cloud Engineering
Overview
Cloud engineers design, build, and run reliable systems on AWS, Azure, and GCP. They own infrastructure as code, networking, CI/CD pipelines, and production operations. The role sits at the intersection of software engineering and operations: you write code that creates infrastructure, then you keep that infrastructure alive. At most UK employers the title blurs into Platform Engineering or DevOps depending on team structure, but the core responsibilities are the same.
What does the Cloud Engineering role involve?
- Day to day you translate product requirements into cloud architecture, write Terraform or Pulumi to provision environments, build and maintain CI/CD pipelines, monitor costs and security posture, respond to production incidents, and reduce toil through automation.
- You pair with developers on containerisation and deployment configuration, and with security teams on least-privilege IAM and network controls.
- In smaller companies you own the full stack from DNS to Kubernetes cluster upgrades.
- In larger organisations you specialise into platform, SRE, or cloud security.
Skills Required
- Linux administration and bash scripting.
- Networking fundamentals: TCP/IP, DNS, load balancing, firewalls, VPC design.
- Infrastructure as code using Terraform.
- Container management with Docker and Kubernetes.
- CI/CD pipeline design with GitHub Actions, GitLab CI, or similar.
- Observability: metrics, logs, and distributed traces using Prometheus, Grafana, and OpenTelemetry.
- Cloud provider depth in at least one of AWS, Azure, or GCP.
- Cost optimisation and FinOps awareness.
- Security fundamentals: IAM, secrets management, network segmentation.
UK Salary Range
Entry level (0-2 years): £28,000 to £38,000 in most UK regions; £35,000 to £45,000 in London. Cloud support roles at the lower end, junior platform engineer or DevOps graduate roles at the higher end.
Mid-level (2-5 years): £45,000 to £65,000. Expectation of ownership over a domain (e.g. Kubernetes cluster, CI/CD platform, or cost management) and ability to mentor juniors.
Senior (5+ years): £65,000 to £95,000 employed. Principal engineers and staff engineers at large tech companies reach £100,000 to £130,000 with equity. Contractors with specialist Kubernetes or cloud security skills charge £450 to £650 per day.
Progression note: Cloud skills compound quickly. Engineers who publish open-source tooling, conference talks, or detailed technical blog posts accelerate into senior and principal roles faster than those who do not.
UK Job Market
- UK demand for cloud skills spans finance, public sector, scale-ups, and consultancies.
- AWS skills have the broadest coverage; Azure dominates large enterprise and government.
- Junior roles advertised in 2024 commonly pair IaC (Terraform specifically) with one cloud provider and strong written communication.
- Consultancies such as Accenture, Capgemini, and BJSS hire in cohorts and provide structured cloud training alongside client work.
- In-house roles at fintechs and SaaS companies expect more autonomy earlier.
- Contracting becomes viable after two to three years of demonstrable production experience, with day rates of £350 to £600 for mid-level engineers.
Who This Career Path Is For
- Career changers with a background in IT support, networking, or systems administration who want to move into automation and cloud.
- Developers who want ownership of production infrastructure rather than just application code.
- People with a logical, methodical approach to problem-solving who are comfortable reading documentation and debugging from first principles.
How to Get Started
Phase 1: Foundations (weeks 1-4)
- Linux command line and file system navigation.
- Networking: understand how a request travels from browser to server and back.
- Set up a home lab using free-tier AWS or a local VM.
- Learn bash scripting for file manipulation, process management, and basic automation.
Phase 2: Cloud and IaC (weeks 5-10)
- Pick AWS as your primary cloud.
- Work through IAM, EC2, VPC, S3, RDS, and load balancers by building something real rather than clicking through tutorials.
- Write Terraform to provision your lab environment.
- Destroy and recreate it until the process is reliable.
Phase 3: Containers and CI/CD (weeks 11-16)
- Containerise a small application with Docker.
- Deploy it to Kubernetes (start with k3s locally or EKS on free tier).
- Build a GitHub Actions pipeline that runs tests, builds a Docker image, and deploys on merge to main.
Phase 4: Production thinking (weeks 17-20)
- Add monitoring with Prometheus and Grafana.
- Write a runbook for a simulated incident.
- Rotate secrets using Vault or AWS Secrets Manager.
- Document your architecture with draw.io diagrams.
Deep guidance
Build Your Portfolio
What to include
- Three projects is enough if each is documented well.
- One strong project beats five shallow tutorial replicas.
Project 1: Multi-tier infrastructure on AWS with Terraform
- Provision a VPC, public and private subnets, an EC2 application server, an RDS database, and an application load balancer using Terraform only.
- No console clicks.
- Write a README that explains every architectural decision, the security group rules, and how to destroy cleanly.
- This demonstrates IaC fluency and networking understanding.
- Strong version: Parameterise the environment (dev/staging/prod) using Terraform workspaces or separate var files.
- Add a secrets manager reference instead of hardcoded credentials.
Weak version: A single EC2 instance with no explanation of why networking is structured as it is.
Project 2: Containerised application with CI/CD
- Take an existing open-source application or a simple API you have written.
- Containerise it with Docker.
- Write a GitHub Actions pipeline that runs tests, builds and pushes the image to ECR or Docker Hub, and deploys to a Kubernetes cluster or ECS task.
- Document the pipeline stages and what each does.
- Strong version: Add a rollback mechanism and a pipeline that blocks deployment if tests fail.
- Include a branch protection rule.
Project 3: Observability stack
- Deploy Prometheus and Grafana to your Kubernetes cluster.
- Instrument an application to emit a custom metric.
- Build a dashboard with four panels: request rate, error rate, p95 latency, and the custom metric.
- Write a one-page runbook for a simulated alert.
How to present it
- All three projects live in public GitHub repositories with descriptive READMEs.
- Link them from a personal site or a pinned LinkedIn post.
- The README must include: what problem it solves, architecture diagram, setup instructions, and what you would do differently with more time.
How to Apply
CV structure
- Keep it to two pages maximum.
- Lead with a two-line summary that names your target role, your cloud provider specialism, and one differentiator (e.g.
- background in network administration).
- List tools only in the context of projects, not as a standalone skills list.
- Hiring managers distrust skills lists that lack evidence.
- Example summary line: Junior cloud engineer with a background in Linux systems administration, focused on AWS and Terraform.
- Built and maintained multi-account IaC environments for a SaaS project.
Where to look
- LinkedIn jobs filtered to Cloud Engineer, Platform Engineer, DevOps Engineer — junior or graduate level
- Technojobs.co.uk and CWJobs for UK-specific listings
- AWS Job Board for roles at AWS Partners (consultancies)
- Otta for scale-up roles
- Government Digital Service (GDS) and NHS Digital for public sector roles
Application strategy
- Apply to 10 to 15 roles per week rather than spending three hours on one application.
- Tailor the first paragraph of your cover letter or the opening CV summary to the specific job description.
- Mirror the tools they list if you have used them.
- Do not apply to roles that require five years of experience; focus on graduate, associate, or junior titles.
Timeline expectation
- Expect 50 to 100 applications before a first offer if you are starting without prior cloud experience.
- Most people get interviews from roughly 5 to 10 percent of applications.
- Two to three rounds of interviews is typical: a technical screen, a practical task, and a culture fit interview.
Interview Preparation
Technical questions you will face
- "Walk me through what happens when you run terraform apply." Expected answer: Terraform reads the state file, computes a diff against the desired state in your .tf files, presents the plan, and on confirmation calls cloud provider APIs to create, update, or destroy resources.
- Mention idempotency.
- "Explain what a VPC is and why you would use private subnets." Expected answer: A VPC is a logically isolated network within a cloud provider.
- Private subnets have no direct internet gateway route.
- You place databases, internal services, and anything that should not be internet-accessible there.
- Public subnets host load balancers and NAT gateways.
- "How would you handle a secret that needs to be available to a Lambda function?" Expected answer: Store it in AWS Secrets Manager or Parameter Store (SecureString).
- Grant the Lambda execution role read access via IAM policy.
- Retrieve at runtime using the SDK rather than injecting into environment variables.
- Rotate on a schedule.
- **"A deployment caused a 500 error spike.
- Walk me through your investigation."** Expected answer: Check the deployment timestamp against the error timeline.
- Review application logs and CloudWatch metrics.
- Check if the error started on the new version only.
- Roll back if the error is confirmed.
- Write a post-mortem.
Behavioural questions
Prepare STAR format answers for: a time you broke something in production, a time you had to learn something quickly, a time a stakeholder disagreed with a technical decision.
Practical tasks
- Many companies give a 90-minute take-home: write Terraform for a given architecture, or debug a broken pipeline.
- Practise by recreating the broken states yourself.
- Always add comments explaining decisions.
Common Mistakes to Avoid
Mistake 1: Building without explaining
- Employers see dozens of "I deployed a web app to AWS" projects.
- The project that wins is the one where the candidate explains why they chose an Application Load Balancer over a Network Load Balancer, why they used Secrets Manager instead of environment variables, and what they would change.
- Add decision documentation to every project README.
Mistake 2: Skipping networking fundamentals
- Candidates who can deploy a container but cannot explain CIDR blocks, why you need a NAT gateway in a private subnet, or what a security group stateful rule means will fail technical screens.
- Spend a week on networking before touching any cloud provider.
Mistake 3: Collecting certifications instead of building
- A Solutions Architect Associate cert with no portfolio project behind it signals that you can pass an exam.
- Hiring managers want evidence you can apply the knowledge.
- Build first, certify second.
Mistake 4: Only using the AWS console
- Everything you build manually in the console should also exist as code.
- If you cannot reproduce your lab environment by running terraform apply from scratch, you have not demonstrated IaC competence.
Mistake 5: Applying to roles that require five or more years
- Many job descriptions are wish lists.
- Junior and associate titles are the right targets.
- If a role requires five years of Kubernetes experience it is not an entry-level role regardless of the salary listed.
Mistake 6: Ignoring cost and security
- Production engineers care about both.
- Show that you understand free tier limits, that you destroy unused resources, and that you do not leave S3 buckets publicly readable.
- A single insecure configuration in a portfolio project is a red flag.
