Spinning up cloud infrastructure has never been easier, and that is exactly why so many estates are in trouble. Teams that moved quickly now sit on a tangle of accounts, surprise data transfer charges and identity policies nobody fully understands, while AI workloads add GPU quotas and data location questions on top. The cloud architect and cloud engineer skills that companies want have shifted accordingly, away from knowing a long catalogue of services and towards governing an estate that many teams change at the same time.
The two jobs share most of a vocabulary, but they differ in what they are accountable for. An architect owns the decisions, and a cloud engineer owns the working result, so most skills below note what to expect from each. You will also find the working habits that matter, what is gaining and losing weight, a level matrix running from engineer to senior architect and an assessment plan.
Core technical skills for cloud architects and cloud engineers
Governance and guardrails
A guardrail should stop dangerous actions without stopping work. On AWS that means Organizations and service control policies, on Azure management groups and Azure Policy, and on Google Cloud organisation policies. Architects decide the structure, and engineers write and roll out the controls. How to check it: ask how they would handle a team that needs an exception to a region restriction for a vendor product. Good answers keep the guardrail intact, scope the exception narrowly, give it an owner and an expiry, and test policy changes on a sandbox unit first.
Cloud identity
Most serious cloud incidents involve identity somewhere. Both roles need to understand federation, role assumption, managed identities and short-lived credentials for workloads. How to check it: show an IAM role whose trust policy allows any principal in another account, or a wildcard, and ask what is wrong. An engineer should spot the risk and tighten it. An architect should go further and explain how the company would detect and prevent this pattern across every account.
Private connectivity and DNS
Hub-and-spoke designs with AWS Transit Gateway or Azure Virtual WAN are well understood. The everyday failures are subtler, and they usually involve DNS. How to check it: say a team created a private endpoint for a storage service, but the application still resolves the public address. Ask why. Experienced people go straight to private DNS zones, how those are linked to the network and how on-premises resolvers forward queries. It is a small test, and it separates people who have run these networks from those who drew them.
Failure domains and recovery
Resilience depends on what your recovery needs at the moment of failure. Strong architects think about static stability, meaning that a design should keep working without having to make changes during an outage. Engineers then build and rehearse it. In India, the major providers each run more than one region, which helps with in-country recovery, although newer regions do not always offer every service. How to check it: ask them to list everything a failover runbook needs from the region that has failed. Consoles, image registries, secrets and scaling capacity often appear on that list, and spotting those dependencies is the skill.
Migration assessment
Migrations fail on what nobody documented. Good practitioners find hidden dependencies, group applications into waves and choose an approach for each one, using tools such as Azure Migrate or AWS Transform MGN (formerly AWS Application Migration Service) where they fit. How to check it: describe an old application with no documentation and a vendor that no longer exists. Ask how they would discover what it talks to. Flow logs, connection tables, a period of observation and interviews with the people who use it are all good signs.
Cost diagnosis
Estimating a design is one skill, and finding out why a live bill changed is another. Engineers should be able to work through billing data, and architects should know how tagging, commitments and team accountability fit together. How to check it: say the monthly bill rose sharply while traffic stayed flat. Ask how they would trace it. Look for grouping by service and tag, then checks on NAT gateway processing, cross-zone transfer, forgotten storage and log ingestion.
Terraform across an estate
Most estates contain resources created by hand before anyone adopted code. Cloud engineers need to bring those under control, and architects need to set module and versioning standards. How to check it: ask how they would bring a hand-built production network under Terraform with no disruption. Strong answers use import blocks, then keep adjusting the code until the plan shows no changes, and they explain why applying before reaching that point would be risky.
Managed Kubernetes on real networks
EKS, AKS and GKE remove control plane work, but their networking still catches teams out. How to check it: say new pods are stuck in ContainerCreating and their events report that no IP addresses are available, although nodes have spare capacity. Ask what happened. On EKS with the default VPC CNI, pods draw addresses from the subnet, so a small subnet can run out. Candidates should suggest secondary ranges or prefix delegation, and an architect should have sized this from the start.
Working skills that separate good from average
- Writing decisions down. Good architects leave a record of what they chose, what they rejected and why. Good engineers read those records, and ask questions when reality disagrees.
- Saying what can wait. Early-stage companies do not need every control on day one. Strong architects can explain which decisions are expensive to reverse, and defer the rest.
- Talking to finance and audit. Cloud work increasingly reaches people outside engineering. The best practitioners can explain a commitment purchase or a control to a non-technical reviewer without jargon.
- Staying close to the build. Architects who never open a console produce designs that are awkward to run, and engineers who never question a design repeat its faults. Look for a healthy two-way relationship.
Cloud skills that matter more in 2026, and less
Mattering more. AI workloads have made GPU quotas, capacity reservations and the location of training data into architecture topics, with platforms such as Amazon SageMaker AI and Gemini Enterprise Agent Platform (formerly Vertex AI) now part of many estates. Data residency needs more attention, because sector regulators set their own rules and the Digital Personal Data Protection Act lets the government restrict transfers abroad, so people should know where each dataset lives. FinOps has moved from an occasional review to a standing duty. Generated infrastructure code means reviewers must catch overly broad permissions and public exposure before they ship. Platform thinking also matters, since architects now serve internal teams through reusable, self-service patterns.
Mattering less. Knowing every service by heart counts for little when assistants and documentation can answer that instantly. Building everything by hand in a console should now raise concern. Lift-and-shift as a whole strategy has lost its appeal, because it moves existing problems and adds a new bill. Multi-cloud as a default stance has also cooled, and many companies now favour depth on one provider, with portability only where a real business reason exists.
Cloud architect and cloud engineer skills matrix by level
| Skill area | Junior | Mid-level | Senior |
|---|---|---|---|
| Typical title | Junior cloud engineer | Cloud engineer | Cloud architect |
| Governance | Works within guardrails | Writes and rolls out policies | Designs organisation structure and controls |
| Identity | Requests least-privilege roles | Builds federation and workload identity | Sets the identity model |
| Networking | Subnets, routes, security groups | Private links and DNS | Owns address plan and hybrid design |
| Resilience | Runs documented recovery tests | Builds multi-zone services | Sets recovery targets with the business |
| Cost | Tags and cleans up resources | Diagnoses bill changes | Models design cost, advises on commitments |
| Infrastructure as code | Edits existing Terraform | Writes modules, imports estates | Sets reusable patterns and standards |
How to assess cloud skills in a hiring process
Architects and engineers need different tasks at this stage. The cloud architect job description explains how to adapt the role for either, and it holds the first-round questions. Take these further steps for shortlisted candidates.
- For architects, change a constraint mid-discussion. Give a real choice, such as managed Kubernetes against a simpler container service, and let the candidate settle on an answer. Then add a new limit, such as a data residency rule, and judge what they reopen and what still stands.
- For engineers, use a sandbox task. Ask them to fix a small Terraform project with a broken private endpoint and an overly broad role. Watch how they verify the result.
- Follow an old design into production. Pick one from their CV and ask what failed first after go-live, and what the next team changed. People who have lived with their decisions always have an answer.
- Bring in a neighbouring colleague. A security engineer or finance partner on the panel shows how the candidate explains themselves to people outside their field.
Red flags on a CV: “architect” with no decisions named; all three clouds at expert level; a pile of certificates with no estates behind them; migration claims with no count of applications or cutover story; and no mention of cost anywhere.
Frequently asked questions
Is multi-cloud experience worth paying extra for?
Only if your estate truly spans providers or an acquisition is coming. Otherwise depth on your own platform pays back faster. Someone who has run production on two clouds is useful for perspective, but do not pay for breadth you will not use.
What does a cloud engineer need to learn to become an architect?
Usually the jump is about judgement and communication. They need to own decisions with long consequences, weigh cost and risk for the business, and persuade teams they do not manage. Most have the technical base already.
How much security should these roles cover?
Both need solid identity, encryption and logging basics. A cloud security engineer goes deeper on posture tools, detection and response. Architects should design with that colleague involved, and should not treat security as a review at the end.
Do cloud architects need Kubernetes experience?
They need to know when it is the right choice and what it costs to run, along with its networking and identity implications. Hands-on depth matters most if containers are central to your estate. Many workloads do well on simpler managed services.
Zilo AI screens on the real foundations, Terraform and incidents candidates have handled. When you are ready to hire cloud architects in India, or cloud engineers on the same contract, contract-to-hire or permanent terms, tell us which estate needs attention, and browse neighbouring roles on the IT talent hub.