Cloud keywords are on almost every IT CV these days. But what really counts is not, whether someone has "worked with AWS" - but How deep. Did the person simply create a few resources with a click in the console? Or was an entire cloud infrastructure built using code, including governance, cost control and a security concept? What is really important in cloud recruiting.
Many recruiters are unable to recognise this depth at first glance - and thus miss out on the best cloud architects. This article shows you how to accurately distinguish between buzzword bingo and real architectural responsibility.
1. not all clouds are the same: why buzzwords in CVs say nothing about depth
It says cloud - but what's inside? Candidates often write "Azure", "AWS" or "GCP" in their profiles, even though they have only worked with them marginally. For example:
-
a developer deploys code into an Azure App Service - without ever having to deal with networks, security or architecture.
-
an admin uses S3 storage in an existing AWS setup - without responsibility for its design or governance.
Such "cloud exposure" experiences are widespread, but they mean that No architectural expertise. This is exactly where your work as a recruiter begins: finding out whether you are dealing with a real cloud architect.
2 Cloud Exposure vs. Cloud Ownership: A decisive difference
The most important difference lies in the responsibility:
| Cloud Exposure | Cloud ownership |
|---|---|
| Utilisation of existing resources | Structure & design of the cloud environment |
| Access via GUI or web console | Use of Infrastructure as a Code (e.g. Terraform) |
| No influence on architectural decisions | Selection of architecture patterns, tools and structures |
| Focus on utilisation | Focus on operational security, scalability, governance |
| Column 1 Value 5 | Column 2 Value 5 |
Interview questions: Cloud Recruiting
"Did you develop the architecture yourself or did you work with an existing system?"
"How did you solve security, network and access control?"
"How was your infrastructure rolled out - manually or via IaC?"
3. find technical evidence: GitHub, Terraform & certificates - recognise what counts even without an IT background
Many recruiters shy away from looking at GitHub profiles or Terraform code. But you need not a tech professional to recognise indications of in-depth expertise.
GitHub - how to find public cloud expertise:
-
Go to github.com and search for the name of the candidate.
-
Look out for repositories with terms such as:
-
terraform -
landing zone -
azure-bicep -
cloudformation
-
-
Take a look at the folder structure:
-
Is there
main.tf,variables.tf,README.md? That points to Infrastructure as Code.
-
-
Is the code commented or professionally structured? Then the person has probably contributed real project experience.
π Tip: If you don't have a GitHub profile, ask actively. Many experienced architects have private repos or provide reference examples on request. Cloud Recruiting
Certificates - what recruiters should consider:
-
Note level: Associate β Professional. AWS Certified Solutions Architect - Professional is much more demanding.
-
Validity: Many certificates expire after 2-3 years. Certificates from 2018 are usually irrelevant.
-
Tool certificates: Terraform, Kubernetes, Azure Architect Expert - all signalling real hands-on experience.
If you are unsure: Ask in the interview for a specific project in which the knowledge was applied.
4 TOGAF, architectural patterns and landing zones: how to recognise real architects
Cloud architecture is more than just technical implementation - it means strategic thinking. Those who have a say here know frameworks such as TOGAF, think in domains and use standardised patterns for scaling, security and operation.
How you can recognise whether someone really "thinks" architecture:
-
The person can explain why they have opted for a hub-and-spoke model - and when they prefer to use flat networking.
-
She knows terms like Landing Zones, Shared Responsibility Model or Guardrails - and can fill them with examples.
-
She doesn't just think about technology, but also about compliance, scaling, costs and teams.
π§ Question:
"How have you mapped governance, costs and security in your architecture?"
5. sourcing strategies for cloud architects - beyond LinkedIn
You will find many top people not with classic LinkedIn searches. Why is that? Because they are not very active there - or are deliberately understated. Here are better ways:
π§βπ» GitHub & GitLab:
-
Search specifically for repositories with
terraform,cloud,bicep,landing zone. -
Tools like octohunt.com or X-ray pools (e.g.
site:github.com "terraform landing zone") will help you find relevant profiles.
π§Ύ Certification directories:
-
Microsoft, AWS & Google maintain official lists of their certified professionals.
-
Use this as a starting point for sourcing, e.g. in combination with location.
π€ Events & speaker sourcing:
-
Check out meetups or conferences (e.g. DevOpsCon, CloudLand, KubeCon) to see who is speaking.
-
These people usually have in-depth knowledge and a good network - ideal for active sourcing.
π‘ Use LinkedIn differently:
-
Boolean search for
("cloud architect" OR "solutions architect") AND (terraform OR TOGAF)delivers better results than simple keyword scanning.
Do you want to find cloud architects who are really deep in the subject?
We not only help you to understand - we also take over the targeted search for cloud experts who really have responsibility: with technical analyses, tool research, active sourcing on GitHub & Co. and clear evaluation of skills.
If you want, we can do the recruiting for you - accurately, technically sound and fast.
π₯ Download our free PDF guide with a practical checklist, interview questions and sourcing tips here:
π "Reading cloud architects correctly - cheatsheet for recruiters"
