Cloud Job Roles

When one skill set becomes 5 different job titles

You finish the security domain of this course comfortable with IAM policies and the shared responsibility model, so you open a job board and search "cloud." The results come back as Cloud Engineer, Cloud Architect, DevOps Engineer, Site Reliability Engineer, and Cloud Security Engineer, and half of them list the same requirements: AWS or Azure, networking, IAM, some scripting. Nothing so far tells you which one to apply to.

The postings do not diverge on which cloud provider or which services they mention. They diverge on 2 things: what you would actually spend your day doing, and how much authority you would have over the overall design. Learn to read for those 2 signals and the job board stops looking like 5 versions of the same role.

Cloud Engineer: building and operating what the architecture specifies

A Cloud Engineer takes a design that already exists, in whole or in outline, and builds it: provisioning compute and storage, wiring up networking, writing the infrastructure-as-code scripts covered earlier in this course, and keeping the running system healthy afterward. This is usually the most common entry point into cloud work, since the day-to-day is concrete and closely tied to the services you have already studied.

A typical week looks like standing up a new VPC and subnet layout from a ticket, debugging why an Auto Scaling group is not launching new instances, or updating a Terraform script to add a database read replica. The work is hands-on and the decisions are mostly local: how to implement a piece of the system, not whether the system should look that way in the first place.

Cloud Architect: designing the system and owning the tradeoffs

A Cloud Architect works one level up. Instead of implementing a piece of the system, the architect decides what the whole system should look like: which services fit a set of business requirements, where redundancy and cost tradeoffs sit, and how the pieces connect. This role usually comes after several years of engineering experience, since the job is to anticipate consequences a less experienced engineer has not yet had the chance to see firsthand.

A cloud architect is like a building's architect. The architect draws the blueprint, decides where the load-bearing walls go (which is where the redundancy and scaling decisions live), and chooses the materials, which in a cloud system means choosing the services. The Cloud Engineer is the general contractor's crew: they pour the foundation, run the wiring, and build exactly what the blueprint specifies, then keep the finished building running. The analogy holds for the design-versus-build split, but it breaks in 1 place: a cloud architecture keeps changing after it ships, unlike a finished building, so the same engineer often moves back and forth between building and design decisions as the system evolves. The 2 roles are less cleanly separated in practice than they are on a real construction site.

Boundary: telling Architect and Engineer apart in a real posting

DevOps Engineer and Platform Engineer: treating operations as a software problem

You already met DevOps as a practice earlier in this course, as the culture and tooling that closes the gap between writing code and running it. DevOps Engineer is that same idea as a job title: someone who builds and maintains the CI/CD pipeline and the infrastructure-as-code automation that lets developers ship without a manual handoff to a separate operations team. Platform Engineer is a closely related, increasingly common title for the same underlying idea: building the internal tools and paved paths that let other engineers deploy safely on their own.

A concrete task looks like writing a GitHub Actions pipeline that runs tests, builds a container image, and deploys it to a staging environment automatically on every merge, with no one manually copying files to a server.

Site Reliability Engineer: the same idea, aimed at uptime

Google, which coined the term, describes Site Reliability Engineering directly: SRE is what happens when you ask a software engineer to design an operations function. An SRE spends the day building the monitoring, alarms, and automated remediation covered in the reliability domain of this course, the SLIs and SLOs that measure whether a system is healthy, and the automation that fixes an entire class of failure instead of hand-fixing each individual incident.

It is tempting to hear "SRE" and assume it is system administration with a more modern-sounding title. It is not. Traditional system administration responds to problems by hand, one at a time. SRE responds by writing software that prevents or automatically resolves the whole category of problem, which is a genuinely different skill set built on programming, not just operations experience.

Cloud Security Engineer: operationalizing the customer's side of shared responsibility

A cloud security engineer takes the shared responsibility model from earlier in this course and turns it into daily work: writing and auditing IAM policies, scanning for misconfigured storage buckets left open to the public, reviewing encryption settings on data at rest and in transit, and checking that governance and compliance controls are actually enforced, not just documented. This role exists at organizations of every size, since a misconfigured IAM policy or an open storage bucket is exactly as damaging at a 3-person startup as it is at a large enterprise.

How the roles line up

The demand behind these roles

The US Bureau of Labor Statistics does not track an occupation called "Cloud Engineer" directly, but its closest official category, Computer Network Architects, projects about 11,200 openings a year over the next decade, driven in large part by the continued expansion of cloud computing and the network redesigns that come with it. That single figure understates the real demand, since it excludes cloud-focused developer, administrator, and security roles entirely, but it is a useful, conservative signal that the underlying trend is real and government-tracked, not just industry marketing.

Getting in without years of production experience

It is tempting to assume every one of these roles requires years of prior on-premises experience before a company will consider you for cloud work. Entry-level cloud postings routinely accept a different kind of proof instead: hands-on lab work, personal projects you can describe in an interview, and a foundational certification. None of that requires a paid job first, which is exactly what the next lesson in this topic sets you up to build.

Where this leaves you

The 5 roles all draw on the same foundation of compute, storage, networking, and IAM you have built across this course; what separates them is scope (implementing versus designing), method (manual operations versus automated engineering), and focus (building, running, or securing). Knowing that map tells you which job postings actually match what you want to spend your day doing. The next lesson turns from knowing the map to proving you can do the work, using free hands-on practice instead of a paid job.