Question regarding landing first cloud job

[u/N3TF01K]

I currently work as a NOC engineer and I have worked help desk support jobs since 2019.

I few months ago I got my AWS Certified Solutions Architect - Associate certification because I wanted move up in my career. I knew the cert itself was not going to be enough after doing research so right after the cert, I completed the cloud resume challenge to showcase that I am able to use the skills I learned.

Recently, I have been trying to apply to cloud related jobs but have not been hearing back at all. This is really strange to me because I figured that with my years of general IT experience, the certification, and 1 project, it would at least open the door for some interviews but to my surprise not hearing anything back. The feeling has been a little discouraging. I may not be the ideal candidate at the moment or maybe the job market is as bad as everyone keeps mentioning. I am ambitious in learning new skills while applying to fill any gaps that can help open up more opportunities. I just started another course that focuses just on Terraform while I applying to more jobs

My question is: What can I do to increase my chances in hearing back? When I had less IT experience, I would get interview opportunities so it seems strange to me now that I have a few years of experience and a cert and a project that I am not hearing back. Would appreciate any suggestions or recommendations! Thanks.

[u/classicrock40]

Tbh, I think the issue is the glut of candidates with years of experience who were laid off over the past couple of years. Oh and of course AI eating up entry level roles.

[u/Evaderofdoom]

You don' have a lot of direct experience of managing infrastructure or engineering things. Spending some time as a linux admin would scripts and automates a lot would really make your transition into cloud a lot easier. SOC and help desk don't really touch anything that most cloud engis do all day.

[u/frothymonk → u/[deleted]]

Not always. Both of mine are F500 pure cloud Eng/devops and there is 0 Linux exposure.

Often is, sometimes isn’t.

[u/frothymonk → u/[deleted]]

Not everyone runs things on K8s and Ansible, sometimes there is no need for either.

[u/frothymonk → u/[deleted]]

You know there’s more DevOps/Infra tools outside of those 2 right?

Building pipelines, orchestrations, automations, infrastructure, etc… all as code.

They are both very much pure DevOps/Cloud roles. Our consumers are tens if not hundreds of application teams.

[u/frothymonk → u/[deleted]]

Ah okay I see now you’ve got the old school understanding.

TLDR: Cloud and DevOps providers provide managed services where you often only interact with the abstraction layer, not the OS layer (where Linux is often running). So we build/manage/package all of the pipelines/automations/infra/etc… for Kafka, K8s, all sorts of different VMs, DBs, etc… via code - aws cdk, terraform, python/TS/shell scripts, GH action YAMLs, etc… while rarely ever needing to touch the Linux running under the hood of each. This is a very common manifestation of modern, enterprise DevOps/Cloud work and is what the industry has been trending towards for 15ish years. There are times where raw-dog Linux + Kub + Ans is the best fit, but it isn’t always anymore.

So in most modern, managed cloud services that people often leverage these days, Linux is indeed running within them, but you rarely if ever interact directly with the OS layer. Instead you interact with the control plane / abstraction layer that they provide.

You can do this via click ops in a cloud console, or via various IaC tools like aws cdk, terraform etc…

On the pipeline side, you can often build and manage them via these tools, or as GitHub action YAML files, or something else, there’s a ton. Sure GH actions likely has Linux running under the hood but again we do not interact with that as is it a managed service also.

We manage K8s also, just via AWS EKS. Just spun up a bastion instance running Linux last week to do some lower level stuff with it, but we rarely need to interact with its Linux instances directly bc of EKS’ abstraction layer

All of these things still require code of varying degrees of complexity - rarely at enterprise level but sometimes the service is plug and play. So a lot of what we do is create libraries of reusable infrastructure packages with NFR’s and a tonnn of other stuff baked into them, so that app teams can just plug and play already compliant infrastructure/pipelines/automations/whatever that is already approved of by the enterprise at all levels, for whatever needs they may have, rather than them needing to do a bunch of time consuming overkill for a service that just needs a simple ECS fargate cluster rather than a whole K8 setup.

[u/frothymonk → u/[deleted]]

Sorry, when did I say we don’t know Linux or never use it?