How to Get a Cloud Security Engineer Job in 2026-27

What a cloud security engineer actually does, and the two jobs hiding under one title

The title covers two different jobs, and knowing which one a posting means is the difference between a focused interview and a vague one. Read the posting for whether it talks about building or about findings.

The first job is cloud security engineering as platform work. You own the paved road: the account or subscription or project factory, the baseline Terraform every workload inherits, the guardrails that make the insecure thing hard and the secure thing default, the CI pipeline checks, the admission policies on the Kubernetes clusters. Your users are other engineers. Success looks like a control that shipped without the platform team filing a complaint, and the skills are engineering skills applied to a security problem.

The second job is cloud security operations and posture. You own the CNAPP or CSPM tooling, triage what it finds, run attack-path analysis, chase down resource owners, build detections for cloud control-plane activity, and respond when an access key leaks. Your users are risk owners and incident responders. Success looks like a reduced and defensible backlog, and the skills lean toward investigation, detection engineering and negotiation.

Most real roles are mostly one of these with a slice of the other, and most companies do not say which in the posting. Three signals tell you. If the requirements list Terraform, Python and CI/CD before they list a vendor tool, it is the platform job. If they list Wiz, Prisma Cloud, Orca or Defender for Cloud in the first three bullets, it is the posture job. If the team reports to a director of platform engineering rather than to the CISO, it is the platform job regardless of what the bullets say.

Ask two questions on the hiring-manager call: who merges the Terraform that creates a new account, and who gets paged when a cloud detection fires at 2am. The answers place the role precisely, and the questions themselves read as someone who has done the job.

• Platform-flavoured role: landing zone and account factory, Terraform modules, SCPs or Azure Policy or GCP organization policy, OIDC federation for CI, admission control, secrets management, key management.
• Posture-flavoured role: CNAPP and CSPM operation, attack-path triage, exception management, cloud detection engineering, cloud incident response, evidence for audit.
• Both: identity design, network and data boundary design, logging architecture, and arguing a control through a platform team that did not ask for it.

Is this an entry-level job in 2026? No. The four routes in that actually work

Be clear with yourself about this before you spend six months on the wrong preparation. Cloud security engineer is a second or third job, not a first one. The reason is structural rather than snobbery: the work changes a production cloud estate, and the cost of a wrong change is an outage or an exposure. Hiring managers want someone who has already broken something in a cloud account and learned from it, and they test for that with scenario questions that someone who has only studied cannot answer convincingly.

Entry-level postings do exist, mostly at large consultancies, managed service providers and cloud-heavy enterprises that run graduate programmes. They are worth applying to and they are not the main supply. The main path is to be hired into an adjacent engineering job first and move across, which usually takes twelve to twenty-four months and is faster inside a company than between companies.

Route one, and the strongest: cloud, platform, DevOps or SRE engineer. You already write the Terraform and hold the pager. What you add is the security reasoning: how an identity gets abused, how data leaves, how you prove it did not. Internal moves from this seat are the single most common way the job gets filled, because the hiring manager has already watched you work.

Route two: systems administrator or infrastructure engineer with a real Azure or AWS estate. Common, under-rated, and strong in enterprises and in the public sector. Active Directory, Group Policy and a hybrid network map directly onto Entra ID, Conditional Access, Azure Policy and private connectivity. The gap to close is infrastructure as code and the pipeline.

Route three: SOC analyst or detection engineer. You bring investigation skill and the ability to reason about an attacker, which many platform people lack. The gap is build skill, and it is a real gap. Closing it means writing Terraform that someone else would merge, not reading about it. Expect the architecture round to probe hard here, because the stereotype is a security person who can describe a control and cannot deploy one.

Route four: software or application security engineer. You can code, which makes the automation half easy, and you understand review. The gap is the cloud control plane itself: IAM evaluation logic, network constructs, key management, and the operational reality of changing a running estate.

There is a fifth route people try and mostly fail with: straight from GRC or audit with certifications and no build evidence. It can be done, and the only thing that does it is a portfolio of working infrastructure code plus a willingness to take an engineer title and a sideways pay step for a year. If that is you, read the artifacts section and treat it as the entire plan.

• Fastest realistic timeline from a cloud or platform seat: six to twelve months of deliberate security work plus one specialty certification.
• From a SOC seat: twelve to twenty-four months, and the Terraform portfolio is not optional.
• Look for the internal move first. Volunteer for the security backlog items nobody on your platform team wants, then apply externally with those on the resume.

Depth in one cloud: what AWS, Azure or GCP security depth actually means in an interview

The most common self-inflicted wound in this market is the three-cloud resume. Listing AWS, Azure and GCP signals breadth to an automated screen and signals nothing to a hiring manager, who will pick whichever one their estate runs on and go three questions deep. Depth in one plus honest conversance in a second beats shallow coverage of three every time. Say it out loud in the interview: 'I am deep in AWS, I can read Azure and I have built small things in it, I have not run GCP in production.' That sentence buys credibility rather than spending it.

Depth means answering at the level of a specific field in a specific policy document, not at the level of a product name. Here is what that sounds like on each platform.

AWS. You can explain what decides whether an API call succeeds: an explicit deny anywhere wins, a service control policy must allow it, a resource control policy must allow it where your organisation has adopted them, a permission boundary and any session policy must allow it, the identity policy must allow it, and for a cross-account call the resource policy must allow it too, with the KMS key policy on top if the object is encrypted with a customer-managed key. You know why a role for a third party gets an external ID and which confused-deputy problem that solves. You can describe the SSRF-to-instance-credential chain and what actually stops it: requiring IMDSv2 so a simple server-side request forgery cannot read the credential, and binding credentials to the network with condition keys such as aws:SourceVpc, aws:SourceVpce or ec2:RoleDelivery so a stolen one is useless outside. The grown-up version of that idea is the data perimeter: aws:PrincipalOrgID on resource policies so only your own identities can reach your data, and the matching condition on identity policies so your identities can only reach your own resources. You know that an organization trail landing in a dedicated logging account is the baseline, that CloudTrail management events are cheap and data events are not, and that GuardDuty, Security Hub and IAM Access Analyzer each answer a different question.

Azure. You can place a control in the management group hierarchy and explain inheritance. You know Azure Policy effects and when each one is the right tool: audit to measure, deny to stop the next mistake, deployIfNotExists with a remediation task to fix the estate you already have, modify to repair tags and settings in place. You know the difference between RBAC and Azure Policy, which people confuse constantly: RBAC decides who may act, Policy decides what shape a resource may take. You know Entra ID properly, including Conditional Access evaluation, Privileged Identity Management for eligible rather than standing roles, managed identities (system-assigned and user-assigned) and workload identity federation so pipelines stop holding secrets. You know private endpoint versus service endpoint and why the first is the real answer when the concern is data leaving. You know Key Vault moved from access policies to Azure RBAC and what breaks during that migration.

GCP. You can explain the resource hierarchy (organization, folders, projects), that IAM allow policies are additive down it, and that IAM deny policies are the counterweight. You know organization policy constraints as the preventive layer and what the common ones do, including custom constraints. You know service account impersonation and Workload Identity Federation, and that long-lived service account keys are the first thing to eliminate. Above all you know VPC Service Controls: a perimeter around the API surface of services such as Cloud Storage and BigQuery, which is the control that actually stops data walking out of a project, and the one candidates most often have not heard of. You know Admin Activity audit logs are on by default and free, that Data Access logs are mostly off by default and cost money once enabled, and that BigQuery is the notable exception where some data access logging is on without you asking.

Kubernetes sits across all three and gets asked about constantly, because it is where cloud identity and workload identity meet. Know how a pod gets a cloud credential on your platform (IRSA or EKS Pod Identity, GKE Workload Identity Federation, AKS workload identity). Know the escalation path you are expected to describe, compromised pod to node to the node's own cloud identity to the rest of the account, and know what cuts each hop: block pod egress to the metadata endpoint or set the instance metadata hop limit to one, give nodes a minimal instance role and put workload permissions on the workload identity instead, turn off automatic service account token mounting where it is not needed, and keep privileged pods off nodes that hold anything worth stealing. Know that Pod Security Policy is gone and Pod Security Admission replaced it, know Kyverno or Gatekeeper for everything admission control needs to do beyond that, and know that a NetworkPolicy is a no-op unless the CNI in the cluster enforces it.

• Pick the cloud your target employers run, not the one you find most interesting. Postings in your city and sector tell you which.
• Be able to read a raw policy document out loud and say what it permits. Interviewers paste JSON and watch your eyes.
• Know the cost of every control you propose. An engineer who suggests enabling data-event logging everywhere without mentioning the bill loses the platform team in one sentence.
• Know one control you would not deploy and why. Judgement about exceptions is the senior signal.

Infrastructure as code is the job, not a bonus skill

If you remember one thing from this guide: a cloud security engineer who cannot write infrastructure code is applying for a job that mostly no longer exists. The console-only reviewer was a real role when estates were small and change was slow. Now the estate is defined in a repository, changes land through pull requests many times a day, and a control that is not in the pipeline is a control that lasts until the next apply.

Terraform is the common denominator and the thing postings name, with OpenTofu appearing in shops that moved after the licence change, and Pulumi, CloudFormation, Bicep and CDK in specific houses. Learn Terraform properly and the rest transfer. Properly means more than writing a resource block: modules with sane interfaces and pinned versions, remote state and why the state file is a secret (it holds plaintext values, which is why state buckets get their own encryption, access policy and audit trail), plan versus apply, drift, and recognising a destructive plan before it runs.

The security-specific layer on top is policy as code, and this is what separates a candidate from a hobbyist. You should be able to write a rule that fails a plan, run it in CI, and explain the rollout. Open Policy Agent with Rego, run through Conftest, is the vendor-neutral answer. Checkov and Trivy give you a large pre-written ruleset and are what most teams start with. Note that tfsec was folded into Trivy, so a resume naming tfsec as a current tool dates you by a couple of years. HashiCorp Sentinel appears where Terraform Enterprise or HCP Terraform is in use. On the Kubernetes side it is Kyverno or Gatekeeper, and Kyverno's YAML policies are the faster thing to demonstrate.

The pipeline question that gets asked almost every time: how does your CI authenticate to the cloud? The answer that earns points is OIDC federation rather than stored long-lived keys, and the detail that proves you have really done it is the subject claim. A trust policy that accepts any repository in the organisation, or wildcards the sub claim, hands every repository in that organisation the role. Pin it to the repository, and where it matters pin the branch or the deployment environment too. If your resume says you eliminated long-lived cloud credentials in CI by federating GitHub Actions with OIDC, you will be asked about exactly this, so have the trust policy in your head.

The philosophy employers want to hear is guardrails over gates. A gate is a human approving a pull request, and it does not scale and it makes you unpopular. A guardrail is a default that makes the insecure shape impossible or loud: an SCP that denies disabling CloudTrail, a module that only emits encrypted buckets with public access blocked, an admission policy that refuses a privileged container, a pipeline check that fails a plan opening a security group to the world. Say this in the interview with a specific example from your own work, and say what you deliberately left as a warning rather than a failure, because the engineer who blocks everything on day one gets their checks disabled in week two.

A word on Python. Most postings ask for Python or Go, and what they mean is scripting and automation rather than application development: calling the cloud SDK, writing a Lambda or Function that remediates something, parsing findings, stitching two tools together. You will not be asked to invert a binary tree. You may be asked to write twenty lines that list every IAM role with a wildcard action, or to explain how you would page through a paginated API without missing results.

• Must have: Terraform modules, remote state hygiene, CI/CD, Git, one policy-as-code tool, one Kubernetes admission tool.
• Strongly expected: OIDC federation for pipeline credentials, secrets in a managed store rather than in CI variables, a tested break-glass path.
• Nice to have: Go, a service catalog or account factory you helped build, experience operating a CNAPP at scale.
• Red flag to the interviewer: talking only about a dashboard and never about a pull request.

The five artifacts that get you interviews

Certifications get you past the filter. Artifacts get you the interview and give you something to talk about for sixty minutes. Build these in a personal account with a billing alarm set at a number you can afford to lose, put them in one public repository with a readme that explains the decisions rather than the commands, and link that repository at the top of your resume where a human will see it.

One. A small multi-account landing zone in Terraform. An organization with two or three OUs, a central logging account with an organization trail, a security tooling account, a baseline of org-level guardrails (deny disabling logging, deny leaving the organization, restrict regions), tags enforced, and a documented break-glass account with hardware MFA that nobody uses. Twenty resources is plenty. The readme should explain why each guardrail is there and what it would break if you dropped it into a live estate on a Friday afternoon.

Two. A CI role with no long-lived credentials. GitHub Actions or GitLab federated through OIDC into a role, with the trust policy pinned to one repository and one branch, plus a short note showing the wildcard version and exactly what it would allow. This is a five-file artifact that demonstrates the most common real-world cloud credential mistake and that you understand it.

Three. A policy-as-code library with tests. Six to ten rules in Rego or Kyverno that you wrote, each with a passing fixture and a failing fixture, wired into a pipeline so the repository itself shows a red run and a green run. Tests are the part nobody does and the part that signals you have worked on a real team.

Four. An attack-path writeup from a deliberately broken environment. CloudGoat and flaws.cloud for AWS, Stratus Red Team for emulating individual techniques across providers, Kubernetes Goat for clusters, AzureGoat and GCPGoat or Thunder CTF for the other two clouds. Then write it up the way an incident report reads: what the initial access was, what the privilege escalation chain was, what the blast radius turned out to be, which single control would have stopped it earliest, and what that control would have cost to deploy and operate. Two to three pages. This is the artifact that most reliably changes an interview, because it shows you reason about attackers and about trade-offs at the same time.

Five. A detection paired with the attack. Take one technique from the writeup, run it, and show the query that catches it: a CloudTrail search or Athena query, a Microsoft Sentinel KQL rule, a GCP log query. Include the false positives you hit and how you tuned them. A candidate who can both cause and catch the same event is unusual and gets remembered.

What is not an artifact: a list of courses completed, a wall of certification badges, a cloned repository with your name in the commit history, or a screenshot of a scanner dashboard showing a number going down.

• Set a budget alarm and a hard spending limit before you create anything. Free tiers end quietly.
• Destroy what you build and commit the teardown. An interviewer noticing you cleaned up is a small, real signal.
• Write every readme for a colleague who will inherit the thing, not for a recruiter. The tone difference is obvious, and the colleague tone is the one the job needs.

The resume a cloud security hiring manager actually reads

Two people read it. A recruiter spends perhaps fifteen seconds checking that the cloud named in the posting appears near the top and that your years roughly match. A hiring manager, usually the person you would report to, reads it properly and is looking for scope, ownership and evidence that you shipped. Write for both by putting the cloud and the scale in the first three lines and the evidence in the bullets.

Lead with scope in units. 'Security engineering for an AWS estate of 180 accounts and roughly 400 engineers' tells a manager more than a paragraph of adjectives. The units that mean something here are accounts, subscriptions or projects; engineers served; clusters; regions; services or workloads; and the volume of pull requests your checks run against. They are verifiable in conversation and they place your experience level immediately.

Write bullets as decisions with consequences, not as responsibilities. The shape that works is what you built, what it replaced, what changed, and what it cost. 'Replaced static IAM users in CI with OIDC federation across 40 repositories, removing 60 long-lived access keys, with a two-week dual-run so no pipeline broke.' The dual-run detail is what makes it believable, and a manager who has done this work knows it.

Name the services, not just the platform. 'AWS' is a keyword. 'Organizations, Control Tower, SCPs, IAM Identity Center, KMS, GuardDuty, Security Hub, VPC endpoints, EKS with IRSA' is a map of what you have actually touched, and it is what an applicant tracking system matches against too. Do the same for Azure (Entra ID, Conditional Access, PIM, Azure Policy, Defender for Cloud, Key Vault, private endpoints) and for GCP (Organization Policy, VPC Service Controls, Workload Identity Federation, Cloud KMS, Security Command Center).

Keep the file machine-readable. One column, no text boxes, no skills rendered as a graphic, dates in a consistent format, and a PDF unless the posting asks for something else. Parsers drop what they cannot read, and a two-column layout is the usual reason a strong resume arrives at the recruiter with half the experience section missing.

Put the certification on one line near the bottom, with the year. It is a filter token, not an achievement, and a block of badges at the top makes a manager assume the rest is thin.

What gets ignored or actively counts against you: a skills table of forty tool logos; 'passionate about cybersecurity'; findings counts with no context, since 'remediated 1,200 critical findings' invites the question of who actually changed anything and whether the drop was a tuning artefact; a list of frameworks you have 'exposure to'; three clouds claimed at equal depth; and any claim that evaporates under one follow-up question. Every line on the page is a question you have invited.

If you are converting from SOC, platform or sysadmin work, keep your real job titles and let the bullets do the arguing. Do not claim a cloud security engineer title you did not hold. The work you describe should read like the job you want, under whatever title you actually had.

• Top of page one: current cloud, years in it, estate scale, link to the repository.
• Four to six bullets per role, each with a verb, an artefact and an outcome.
• One line for certifications. One line for the stack. No badge wall.
• Two pages, one column, PDF. Mid-level cloud security resumes that run to four pages read as padded.

How the hiring process runs, and what the architecture interview really tests

There is no licensing body, no standardised exam and no union in this process. What there is, at most employers with an in-house recruiting function, is a sequence of four to six conversations over three to six weeks, run by a recruiter and a hiring manager who is usually a security engineering lead or a head of platform security.

Stage one, recruiter screen, twenty to thirty minutes. Filtering only: the cloud you name, years, location and work authorisation, salary expectation, notice period. Ask here which cloud dominates the estate, how big it is, and whether the team sits under security or under platform. Give a range rather than a number and ask for theirs.

Stage two, hiring manager, forty-five to sixty minutes. This is the stage most candidates underprepare. They want a narrative: what you own now, a control you shipped end to end, a time you were wrong, and how you handle an engineering team that does not want your change. Have three stories ready at the level of specific services and specific pushback.

Stage three, technical screen or take-home. Either a live session reading policy documents and Terraform, or a short exercise. Two to four hours is normal, and an employer asking for more than four is telling you something. Typical exercises: here is a Terraform module, find the problems and fix them; here are three IAM policies, does this call succeed; write a policy-as-code rule for this requirement; here is a CloudTrail extract, what happened.

Stage four, the cloud architecture and threat-modelling round, sixty to ninety minutes, usually on a whiteboard or a shared document. This is the round that decides the offer and the one people most misunderstand. It is not a service-naming quiz, and the interviewer is not waiting for you to say the name of a product. They are testing whether you reason about boundaries and blast radius, whether you ask about requirements before designing, whether you can sequence a rollout into a live estate, and whether you know where your own design is weak.

A good answer in this round starts by narrowing the problem. Ask who the users are, what the data classification is, which compliance regime applies, whether a landing zone already exists, who operates it, and what the appetite for breaking things is. Then design the identity model before the network, because in cloud the identity layer is the real perimeter. Then say how you would detect a failure of each control you proposed, because a control with no telemetry is an assumption. Then, unprompted, name the two weakest points in your own design and what you would do about them given another quarter. That last move is the clearest senior signal available in a sixty-minute conversation.

Stage five, cross-functional. A platform or infrastructure engineer, sometimes an SRE. They are deciding whether working with you would be miserable. The question underneath every question is whether you understand that their uptime is also a requirement. Answer accordingly: talk about migration paths, audit before enforce, exemptions that carry an owner and an expiry date, and who you would consult before enabling a deny.

Stage six, where it exists: a detection or incident scenario ('an access key for a production role appeared in a public repository twelve minutes ago, go'), or a values and leadership round. For cleared work in defence and government, add a background investigation and a clearance process that runs after the offer and takes months. You cannot sponsor your own clearance, so a posting demanding an active clearance is genuinely closed to you until an employer sponsors one.

• Design prompts that recur: build a secure multi-account landing zone for 300 engineers; a public API over a private data store; a data lake only some teams may read from; a multi-tenant Kubernetes platform; let a third party into one bucket safely; recover from a leaked long-lived credential.
• IAM questions that recur: walk me through what makes an API call succeed or fail; explain the confused deputy problem and external IDs; how do you give CI deploy rights without admin; how do you stop a stolen instance credential being used outside your network; permission boundary versus SCP, when do you reach for each.
• Data questions that recur: who can decrypt versus who can use the key; how do you stop an engineer copying a production dataset to a personal bucket; what actually enforces a network boundary on a managed data service.
• Kubernetes questions that recur: how does a pod get cloud credentials; the escalation path from pod to node to account; what admission control buys you that scanning does not.
• Operational questions that recur: how do you roll out an SCP without taking production down; how do you handle an exception request; what does your logging design cost per month.
• Questions you should ask: what is on fire right now; who owns the landing zone; what proportion of the estate is in Terraform; what is the exception process; when did you last change a control and break something.

Pay, titles, and the shape of the 2026-27 market

Do not trust a salary figure in an article, including this one. The honest answer is where to look. There is no US Bureau of Labor Statistics occupation called cloud security engineer; the nearest official series is Information Security Analysts, SOC code 15-1212, in the Occupational Employment and Wage Statistics, and it blends analyst seats and engineering seats together, so treat it as a floor rather than a market rate. The numbers that actually reflect this role come from three places: posted ranges in states with pay-transparency laws, levels.fyi for large technology employers where the equity component is the part that varies, and the recruiter on the first call, who will usually tell you the band if you ask directly.

Three things move the number more than your certification count. Cloud security roles inside large technology companies and financial services pay well above the same title at a mid-sized company. Sectors carrying regulatory weight (payments, healthcare, defence) pay for compliance fluency as much as for engineering. And a security clearance, where the work requires one, is worth a premium and is also a lock-in, because the market for cleared work is geographically narrow.

On titles: the same job is posted as cloud security engineer, cloud security architect (usually more senior and more design-weighted), DevSecOps engineer (usually more pipeline-weighted), infrastructure security engineer, platform security engineer, product security engineer with a cloud emphasis, and increasingly just security engineer with cloud in the first requirement bullet. Searching only the exact title under-reports your market badly. Search the stack instead: Terraform plus security, Kubernetes plus security, AWS plus IAM, Entra plus Conditional Access.

The 2026-27 market in plain terms. Security hiring is not uniformly strong, and the recurring industry claim about millions of unfilled cybersecurity jobs is a vendor talking point that does not match what applicants experience at the entry level. What is true is that the mid-level cloud security seat, meaning someone who can write infrastructure code and reason about identity, is one of the harder roles for employers to fill, because it needs an engineer, and most security candidates are not engineers while most engineers have not done security. Demand comes from three directions: estates growing faster than any review process can scale, consolidation onto cloud-native application protection platforms creating work to operate them, and AI workloads arriving in production accounts with new identity and data-movement questions attached.

Practical consequence for your search: competition for a cloud security engineer role is thinner than for a SOC analyst role, but the bar is a step higher and it is a build bar. Applications are not the constraint. Evidence is.

• Ask the band on the recruiter call. It costs nothing and saves three weeks.
• Compare total compensation, not base. Equity vesting schedules and on-call compensation differ enormously between a technology employer and an enterprise.
• If a posting hides the range in a state that requires one, that is information about the employer.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Cloud security engineer
• Cloud security
• AWS security
• Azure security
• Google Cloud security
• GCP security
• Identity and Access Management (IAM)
• IAM policy
• Service control policy (SCP)
• Resource control policy (RCP)
• Permission boundary
• AWS Organizations
• AWS Control Tower
• IAM Identity Center
• AWS KMS
• Amazon GuardDuty
• AWS Security Hub
• CloudTrail
• VPC endpoint policy
• Data perimeter
• Microsoft Entra ID
• Conditional Access
• Privileged Identity Management (PIM)
• Azure Policy
• Microsoft Defender for Cloud
• Azure Key Vault
• Private endpoint
• Managed identity
• GCP Organization Policy
• VPC Service Controls
• Workload Identity Federation
• Security Command Center
• Terraform
• OpenTofu
• Infrastructure as code (IaC)
• Policy as code
• Open Policy Agent (OPA)
• Rego
• Conftest
• Checkov
• Trivy
• Kyverno
• OPA Gatekeeper
• Kubernetes security
• CKS
• Pod Security Admission
• IRSA
• EKS Pod Identity
• CI/CD
• GitHub Actions OIDC
• Least privilege
• Zero trust
• Cloud security posture management (CSPM)
• CNAPP
• Cloud workload protection
• Attack path analysis
• Threat modelling
• Secrets management
• Encryption key management
• Cloud incident response
• Non-human identity
• Workload identity
• AWS Certified Security Specialty
• AZ-500
• Google Professional Cloud Security Engineer
• CCSP
• Python
• Go
• SOC 2
• ISO 27001
• FedRAMP
• PCI DSS
• NIST AI Risk Management Framework
• ISO/IEC 42001

Mistakes that cost people this job

Questions people ask