How to assess · For hiring teams
How to Assess AWS Skills When Hiring
The test formats that actually work for AWS, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.
The short answer
Assess AWS with a task, not a conversation: architecture design with constraints, iam and security review, ai-scored assessment (e.g. cohesyve) or cost or incident investigation. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Applies least privilege in IAM and can write a policy that is scoped to a resource, not a wildcard
- Designs VPCs deliberately: public and private subnets, where the NAT sits, what the security groups actually allow
- Chooses services with reasons — when a queue, when a managed database, when a function versus a container
- Builds for at least one availability zone failing and can say what breaks if a region does
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
AWS has more than two hundred services, and no candidate knows them all. What matters is whether they can design and operate the dozen that most workloads use — compute, storage, networking, identity, databases and queues — with the judgement to keep it secure, affordable and recoverable. Certification lists and console familiarity tell you little about that. This page covers how to assess AWS skill as it is practised: architecture choices with reasons, IAM done properly, networking that is understood rather than copied, cost awareness, and the ability to diagnose a problem across services.
Why AWS is worth testing
AWS mistakes are quiet and expensive. An overly broad IAM policy is a breach waiting to happen; a public S3 bucket is a headline; an unmonitored NAT gateway is a five-figure bill; a single-AZ database is an outage. A candidate who has built things on AWS without operating them may have made all four without ever finding out. Testing reveals whether they think about security, cost and failure as part of design, or as things that happen later to someone else.
What strong AWS looks like
- Applies least privilege in IAM and can write a policy that is scoped to a resource, not a wildcard
- Designs VPCs deliberately: public and private subnets, where the NAT sits, what the security groups actually allow
- Chooses services with reasons — when a queue, when a managed database, when a function versus a container
- Builds for at least one availability zone failing and can say what breaks if a region does
- Knows what drives cost in a design and where the surprises hide (data transfer, NAT, provisioned capacity)
- Uses infrastructure as code and would be uncomfortable with a console-built environment
- Diagnoses across services with CloudWatch, CloudTrail and logs rather than guessing
Ways to assess AWS
Architecture design with constraints
Describe a workload — a web app with a database, background jobs and file uploads — with constraints on availability, budget and compliance. Ask for a design, the reasons for each choice, and what fails first.
Pros
Cons
Best for Mid and senior cloud and platform roles.
IAM and security review
Provide an IAM policy with `*` actions on `*` resources, a security group open to the world on port 22, and an S3 bucket policy that is public. Ask what is wrong and how to fix each with minimal blast radius.
Pros
Cons
Best for Any role with production access.
AI-scored assessment (e.g. Cohesyve)
Generate an AWS scenario from the job description — a design, a security review, a cost investigation — with a rubric. Each candidate receives a different variant; written reasoning is scored.
Pros
Cons
Best for Screening a large pool before architecture interviews.
Cost or incident investigation
Give a bill breakdown that jumped 60% in a month, or a symptom (requests timing out from one subnet), and ask how they would find the cause.
Pros
Cons
Best for Senior engineers with operational ownership.
Cohesyve
Run a AWS assessment on your next opening
Cohesyve generates a unique AWS task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
Identity and security
Whether access is scoped and the environment is not exposed.
Networking
Whether they understand where traffic flows and what blocks it.
Architecture and resilience
Whether designs survive failure and fit the workload.
Cost and operations
Whether they see cost and observability as part of design.
Sample AWS questions
What is the difference between a security group and a network ACL?
EntryLook for Stateful versus stateless, instance versus subnet level, and when they would use each.
An instance in a private subnet needs to download packages. What do you add?
EntryLook for A NAT gateway (or instance) in a public subnet and a route, with awareness of its cost.
Design a web application that survives the loss of an availability zone.
MidLook for Multi-AZ load balancer and compute, Multi-AZ database, stateless app tier, and a note on what still would not survive a region loss.
This IAM policy grants `s3:*` on `*`. Scope it for a service that writes reports to one prefix.
MidLook for Specific actions, a resource ARN with the prefix, and a condition if appropriate.
The monthly bill rose 60% with no new features. How do you find out why?
SeniorLook for Cost Explorer by service and tag, look at data transfer and NAT, check for unattached resources and provisioned capacity, correlate with changes.
Red flags
- Writes IAM policies with wildcards and does not see the problem
- Cannot explain the difference between a public and private subnet
- Designs single-AZ by default
- Has no idea what the last environment they built cost per month
- Built production infrastructure by hand in the console
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Security and identity | 30% | Least privilege by default; exposure is noticed and closed. |
| Architecture judgement | 25% | Service choices have reasons; failure modes are named. |
| Networking | 20% | Traffic flow is understood end to end. |
| Cost awareness | 15% | Knows what drives spend and designs accordingly. |
| Operations | 10% | Uses IaC, monitoring and audit trails as a matter of course. |
Mistakes hiring teams make
- Quizzing service names and limits instead of design judgement
- Treating certification as sufficient evidence
- Not including a security review — it is the most consequential skill
- Ignoring cost entirely in the assessment
- Accepting a design with no answer for "what fails first"
Roles that need AWS
Common questions
Are AWS certifications a good hiring signal?
They confirm familiarity with services and terminology. They do not confirm that someone has operated production on AWS through incidents and bills. Use them as a prerequisite, then test judgement with a design and a security review.
How do I assess AWS without giving console access?
Design questions, IAM policy and security group reviews, and cost or incident scenarios all work on paper. Reasoning is what you are assessing; hands-on fluency can be confirmed for finalists.
Which AWS services should a mid-level engineer know well?
IAM, VPC, EC2 or ECS, S3, RDS, SQS, Lambda, CloudWatch and CloudTrail. Depth in those matters far more than breadth across the catalogue.
Does AWS knowledge transfer from Azure or GCP?
The concepts — identity, networking, managed services, availability zones — transfer well. The specifics of IAM and VPC do not, and they are where mistakes are costly. Test AWS specifically if the role is AWS.
Cohesyve · Skill assessments for hiring
Test AWS before the first interview
Generate a role-specific AWS assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog