Cloud engineers
Cloud engineers decide what a system is built out of at the provider layer: which managed services are used, how networks and accounts are divided, who is permitted to do what, how the design survives a failure it did not choose, and what the resulting bill looks like. Those decisions are cheap to make and expensive to revisit. What follows covers the discipline, the situations that call for it, and how to assess depth in a field where certification is easy and judgement is not.
What does a cloud engineer do?
A cloud engineer designs, builds and operates the infrastructure a system runs on inside a cloud provider: the account and network topology, the identity and permission model, the choice between managed services and self-hosted components, the arrangements that keep the system available when a zone or region fails, and the spending all of it generates. The role is provider-facing — it concerns what the infrastructure is made of and how it is configured, rather than the pipeline that delivers software onto it or the internal tooling other engineers use to reach it.
Cloud providers are not interchangeable hosting. Each publishes several hundred services with distinct pricing, quotas, failure characteristics and security semantics, and the difference between a sound design and an expensive one is largely which were selected and how they were wired together. Much of the value lies in knowing what a managed service genuinely guarantees, what it quietly does not, and what leaving it later would involve.
The identity model is where the difficulty concentrates. Permissions granted early are rarely narrowed afterwards, and the damage a compromised credential can do is decided by how roles and trust relationships were designed. Each provider expresses that differently enough that experience does not transfer cleanly, so an engineer who can reason precisely about how a policy resolves, and about where one account genuinely stops, is working on the part of the estate that is hardest to correct later.
Cost belongs to engineering rather than to finance. Egress, cross-zone traffic, idle provisioned capacity, storage class, retention policy and the choice between always-on and request-priced compute are all settled in architecture and appear on an invoice much later. By then the decision is embedded in the design, and the common response is to negotiate a discount rather than change the architecture — which addresses the invoice and leaves the cause in place.
When teams need this capability
Cloud infrastructure is frequently assembled by application engineers solving the problem in front of them, which works until a structural decision is needed. These are the points at which the absence of provider depth starts to be expensive.
A migration is being planned rather than merely discussed
Moving an existing system forces a decision that is easy to defer: reproduce the current architecture closely, or re-shape it around managed services. Both are legitimate. Choosing by accident, service by service, produces the cost profile of the second with the operational burden of the first.
The account structure grew instead of being designed
Everything shares one account, environments are separated by naming convention, and several people hold credentials that can affect production. Nothing would contain a mistake, and adding a boundary afterwards means moving live resources, which is why it keeps being postponed.
Spending has become unpredictable and unattributable
The invoice rises faster than usage and nobody can say which team, feature or environment is responsible. Without attribution the only lever is a broad instruction to spend less, which lands on whoever is most cautious rather than on whatever is most wasteful.
Availability commitments have been written down for the first time
A customer contract or a regulator introduces explicit recovery objectives. Translating those into zone and region topology, replication choices, backup verification and a failover that has actually been performed is specialist work, and the gap between a documented plan and a tested one is where organisations find their real position.
Access has been granted far more often than it has been reviewed
Permissions accumulated during incidents, migrations and onboarding, and none were withdrawn. Nobody can currently say who is able to read the production database, and answering it means reading policy evaluation rather than a list of users.
A second provider or a regulated region is now in scope
Data residency rules, a customer demanding a particular jurisdiction, or an acquisition arriving with a different provider. Each raises questions about identity federation, network connectivity, data movement, and which abstractions keep two estates comprehensible.
Core capabilities
Provider architecture
Selecting compute models, storage classes and managed services against the actual shape of the workload — request volume, burstiness, data gravity, latency tolerance — and knowing where a provider’s abstraction stops matching what the application needs.
Network design
Address planning, subnet and routing structure, private connectivity to other estates, controlled egress and load balancing. Networks are among the hardest things to re-plan once workloads occupy them, so decisions here persist far longer than most.
Identity and access
Designing roles, policies and trust relationships so that permissions are least-privilege by construction rather than by review. This covers federation with a corporate directory, workload identity in place of stored keys, and knowing how an access decision resolves when several policies apply.
Managed service judgement
Deciding when to consume a provider service and when to run the component directly. Managed services reduce operational load and increase coupling, so the reasoning has to include what is guaranteed, what it costs at the volume expected, and what migrating away would involve.
Data storage and lifecycle
Choosing durable stores appropriate to access patterns, setting retention and archival policy deliberately, verifying that backups can be restored rather than merely taken, and understanding replication semantics well enough to know what is lost in a failover.
Resilience and recovery design
Expressing tolerance for downtime and data loss as explicit objectives, then designing zone and region topology to meet them and rehearsing the failure. A recovery procedure that has never been performed is a document, and documents behave differently from systems under load.
Provider security model
Encryption in transit and at rest, key management and rotation, secret storage, network isolation, and organisation-wide guardrails that prevent whole classes of misconfiguration. It also means knowing where the provider’s responsibility ends and the customer’s begins.
Estate visibility
Collecting provider metrics, flow logs, audit trails and configuration history into a form that answers questions after the fact: what changed, who changed it, what the resource looked like before. Native monitoring handles predefined questions well and unanticipated ones poorly, which is why audit history matters as much as dashboards.
Cost engineering
Tagging and allocation so spend can be attributed, right-sizing against observed rather than assumed load, choosing commitment instruments deliberately, and treating egress and cross-zone traffic as design inputs. The largest savings come from architecture rather than procurement.
Migration execution
Sequencing a move so the system stays usable throughout: dependency mapping, data transfer and reconciliation, cutover with a defined way back, and the unglamorous inventory of what nobody documented. Migrations fail on the undocumented parts far more often than the technical ones.
Technology ecosystem
Common technologies in cloud engineering are listed below. It describes the landscape of the discipline as it is practised, not a claim about any particular engineer’s toolkit. Because every provider names equivalent concepts differently, probing how someone reasons about networks, identity and failure is more informative than checking which of these names they recognise.
Providers
- AWS
- Google Cloud
- Microsoft Azure
- Alibaba Cloud
- Oracle Cloud
Compute and runtime
- EC2
- Compute Engine
- AWS Lambda
- Cloud Run
- Azure Functions
- EKS, GKE and AKS
Networking and edge
- VPC
- Route 53
- Cloud DNS
- CloudFront
- Transit Gateway
- Private Link
Identity and security
- AWS IAM
- Google Cloud IAM
- Microsoft Entra ID
- AWS Organizations
- KMS
- Secrets Manager
Data and storage
- S3
- Cloud Storage
- RDS and Aurora
- Cloud SQL
- DynamoDB
- BigQuery
Provisioning
- Terraform
- CloudFormation
- Bicep
- AWS CDK
- Pulumi
Governance and cost
- AWS Config
- Azure Policy
- Cost Explorer
- Billing export
- Infracost
- OpenCost
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
There is an unusually large gap here between credential and competence. Certifications are widely held and test recall of service names; the work rewards judgement about failure, permission and cost that no examination measures. These are the areas where that judgement becomes visible.
Depth in one provider before breadth across several
A candidate claiming equal fluency across three providers is usually describing familiarity. Real understanding of quotas, failure behaviour, pricing edges and policy evaluation is provider-specific and takes years, and depth in one transfers better than shallow coverage of all.
- Can describe a limit or quota that shaped a design, and how they found it
- Knows where their primary provider behaves badly, not only where it behaves well
- Distinguishes concepts that genuinely transfer from names that merely look similar
Reasoning about identity and permissions
Ask how they would grant one service access to one resource, then how they would verify nothing else gained the same access. The second question is where depth shows: weak answers describe attaching a policy, strong ones describe evaluation order, trust boundaries and confirming the outcome.
- Reaches for workload identity rather than a stored access key
- Can explain how conflicting permissions resolve on their primary provider
- Has audited existing permissions and can describe what they found
- Treats an account or project boundary as a security control, not an accounting one
Network design and its consequences
Networking is where inexperienced designs cause the most durable problems, because address ranges and connectivity are difficult to unwind once workloads depend on them. Ask about a network they planned and what they would lay out differently now.
- Plans address space with future connectivity and acquisition in mind
- Can explain how traffic leaves the estate and what that path costs
- Understands the difference between private connectivity and merely restricted access
Resilience that has been tested rather than documented
Ask when they last performed a failover or restored from a backup outside an emergency. The answer separates designs that were reasoned about from designs that were verified, and that gap is where recovery objectives turn out to have been aspirational.
- Has rehearsed a failover and can describe what went wrong during the rehearsal
- Restores backups periodically rather than trusting that they completed
- States recovery objectives in time and data terms rather than as adjectives
- Understands which provider failures a multi-zone design does not protect against
Cost treated as an architectural input
Ask how they would find out why a bill increased. Those who have owned this reach for allocation tags, usage reports and specific line items; those who have not suggest reserving capacity or asking teams to be careful, which does not survive contact with a growing estate.
- Can name a specific architectural change that reduced cost, and the mechanism
- Understands egress and cross-zone charges well enough to design around them
- Sets up attribution before the question is urgent rather than during a review
Operating through a provider incident
Provider failures are unavoidable and largely outside the customer’s control, so the interesting question is what the team does during one. Ask about a degradation they worked through and how they decided when to fail over rather than wait.
- Distinguishes a provider incident from an application fault quickly, with evidence
- Has a considered position on when failing over is riskier than waiting
- Contributed to a review that changed the design rather than blamed the provider
Knowing where provider responsibility ends
Managed services are frequently assumed to be secure and correct by default. Ask what a specific managed service does not do for you: precision here indicates someone who has read the documentation rather than inherited assumptions from a diagram.
- Can name a default configuration that is convenient rather than safe
- Knows which parts of a managed service still require patching or configuration
- Has caught a misconfiguration that automated scanning did not flag
Interview questions worth asking
Questions designed to distinguish provider judgement from provider vocabulary. Put them to work inside whatever selection process you already run: the requirements are yours to define, and so is the decision about who meets them.
Describe the account and network layout of an estate you designed. What would you structure differently if you started again?
What a strong answer shows
Whether they have lived with their own decisions. Strong answers explain the reasoning behind boundaries — isolation, blast radius, billing, compliance — and identify a specific regret, which is difficult to fabricate convincingly.
A service needs to read one storage bucket. Walk me through granting that, and then through proving nothing else gained access.
What a strong answer shows
Precision about permission evaluation. The grant is straightforward; the verification is not. Listen for identity rather than keys, scope narrowed to the specific resource, and a method of confirming the result.
How would you investigate a bill that increased sharply without a matching rise in traffic?
What a strong answer shows
Whether cost is something they diagnose or something they escalate. Expect allocation tags, usage breakdowns, a hypothesis about a specific charge type, and awareness that transfer and idle capacity often explain more than compute.
What are your recovery objectives on the last system you ran, and when did you last verify you could meet them?
What a strong answer shows
The distance between a documented plan and a tested one. Candidates who have genuinely rehearsed recovery answer with a date and a story about what failed during the rehearsal; the rest answer with an architecture diagram.
You are asked to migrate a system nobody fully understands. How do you approach the first month?
What a strong answer shows
Method under incomplete information. Strong answers begin with observation and inventory rather than target architecture: what talks to what, what runs on a schedule, what has undocumented dependencies.
When would you choose a managed database over running one yourself, and when would you decline?
What a strong answer shows
Whether they weigh operational load against coupling and cost. The answer should cover version and extension constraints, scaling behaviour, what the availability commitment actually covers, and the cost of eventually moving away.
Your provider is reporting degradation in the region you run in. How do you decide whether to fail over?
What a strong answer shows
Composure, and an understanding that failover carries its own risk. Look for evidence-gathering, awareness of replication lag and data consistency, and a decision rule agreed before the incident rather than improvised during it.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- An organisation running a growing estate on a single provider has reached the point where its early decisions constrain it. Environments share an account, permissions were granted more often than reviewed, spending cannot be attributed to any team, and a new customer commitment has introduced availability requirements the current topology was never designed to meet.
- Approach
- Extra infrastructure capacity joins the team under the architecture principles it has already set, working within its provisioning workflow, its account conventions and its change process. Design proposals are reviewed by the internal engineers who will live with them, and remediation is sequenced against the priorities the team has agreed.
- What this adds to the team
- Architectural authority and the security posture remain with the organisation, which gains room to address structural work that has been deferred. Which trade-offs are acceptable is judged by the people who carry the commercial consequences.
Related disciplines
Frequently asked questions
- What is the difference between a cloud engineer and a DevOps engineer?
- A cloud engineer specialises in the provider layer: how accounts and networks are structured, how identity is granted and evaluated, which provider services the system leans on, how it behaves when a zone or region fails, and what all of that costs. A DevOps engineer specialises in getting change onto whatever infrastructure exists — pipelines, deployment strategy, release automation, and the feedback that follows a release. One discipline is concerned with what the system is built from; the other with how change reaches it. Small organisations combine both in one person, and larger estates find the two kinds of depth stop fitting into a single job.
- Is a cloud engineer the same as a platform engineer?
- No, though the two are frequently confused because both sit below the application. Cloud engineering delivers infrastructure that satisfies a requirement: topology, permissions, resilience, spend. Platform engineering delivers an interface to infrastructure, built for internal engineers who could always assemble it themselves, and judged on whether they choose to adopt it. Platforms are generally layered on top of what cloud engineering has already established, which is why constructing one over an incoherent estate produces a tidy façade with every original problem intact behind it.
- Should we run on more than one cloud provider?
- Rarely by choice, and often by circumstance. Deliberate multi-cloud roughly doubles the surface an organisation must understand — two identity models, two network models, two sets of failure behaviour — in exchange for a stronger negotiating position and a portability option most organisations never exercise. It is justified by data residency rules, a customer mandate, an acquisition or a genuine regulatory obligation. It is rarely justified by provider outages, since the added complexity tends to cause more downtime than it prevents.
- How much do cloud certifications tell you?
- They confirm that someone has studied a provider’s service catalogue and can recall how the parts are meant to fit together, which is a genuine baseline and worth something early in a career. They do not indicate whether that person has designed a permission model that held up, watched a failover behave differently from the documentation, or traced an unexpected charge to its cause. Treat a certification as evidence of preparation rather than of judgement, and spend the interview on the judgement.
- Who is responsible for security in a cloud environment?
- The provider secures the underlying infrastructure; the customer is responsible for configuration, identity, network exposure, data protection and everything built on top. Nearly all publicised cloud data exposure falls on the customer side of that line — a permission wider than intended, storage reachable from the internet, a credential in a repository, a default that was convenient rather than safe. An engineer who cannot state where the boundary sits for the services they use is carrying a gap they may not be aware of.
- Can a cloud engineer bring our spending under control?
- Partly, and the limits are worth understanding before hiring for it. Real reduction usually requires architectural change — storage class and retention, traffic paths, moving idle capacity to request-priced compute, removing what nobody uses — and that needs engineering time from the teams who own the systems. Set the role up as a queue of cost tickets and access requests and it will produce a report each month and change very little. Allow it to make attribution visible and propose design changes, and it can move the underlying trend.
- How do cloud engineers work with an existing engineering team?
- Staff augmentation places the engineer within your team rather than alongside it. Your architecture principles, account conventions, security policies and sprint priorities govern the work, and your people decide what gets built and in what order. Talent.ID carries the employment side: employee benefits, payroll, talent administration, and the relationship with the employee as it continues.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.