I have about one year of professional DevOps experience at a mid-sized service company in Mumbai. I'm currently the only DevOps-focused person on my team, so I handle a wide range of responsibilities independently.
AWS is my main area of work, including deploying and managing projects, maintaining infrastructure, troubleshooting, monitoring, and handling general delivery tasks. I've also started working on MLOps, helped set up AWS and Azure landing zones for clients, and am working closely with our CISO on implementing ISO 27001.
For the ISO work, I'm involved in taking things from almost zero to one: creating policies, implementing technical controls, preparing documentation, making infrastructure and security decisions, and completing the groundwork. We also have an external consultant involved, but I'm responsible for much of the technical implementation.
I recently completed the AWS Solutions Architect Associate certification and already have Azure Fundamentals and Azure AI Fundamentals certifications.
The confusing part is that my compensation is relatively low, while my responsibilities and exposure seem fairly broad for someone with one year of experience. I'm trying to understand whether I'm genuinely building valuable career capital or simply being pulled into miscellaneous work because I'm the only DevOps person available.
How valuable are experience with AWS, MLOps, landing zones, and ISO 27001 likely to be for my next role? Should I stay until the ISO certification is completed so I can point to a finished implementation, or should I start looking for a better opportunity now? Am I spreading myself too thin, or is this a reasonable way to develop early in a DevOps or SRE career?
If you were in my position, what would you focus on during the next 12 months? I'm less interested in a direct salary comparison and more interested in whether this experience demonstrates real ownership and depth.
5 Answers
Your employer may not price this exposure fairly, especially in a service company where one person can end up covering many unrelated needs. You do not need to wait for a formal raise before testing the market. Start preparing interview stories now, especially around the landing zone, AWS deployments, security controls, automation, and incidents you resolved.
Stay only as long as the remaining work is giving you meaningful learning or a clearly defined milestone. The best outcome is to leave with documented, measurable results—not simply a longer list of responsibilities. Breadth is not the issue; the issue would be having no area where you can demonstrate end-to-end ownership.
The most important distinction is whether you are automating and enabling engineering teams, rather than simply handling deployments and infrastructure tickets. Strong DevOps work usually includes improving the software delivery lifecycle, creating reusable platforms or self-service workflows, managing infrastructure as code, and partnering with developers and data teams.
For the next year, focus on a few concrete outcomes: a reliable deployment pipeline, reproducible infrastructure, centralized observability, documented access and security controls, and clear operational ownership. Those accomplishments will show more depth than the number of products or cloud services you have touched.
At one year, this sounds like solid exposure rather than a problem. Breadth is useful early on, and depth often comes from seeing the same production problems repeatedly and improving the systems each time. The key is to choose one or two areas to become known for instead of treating every responsibility as an equal priority.
AWS infrastructure and the ISO implementation seem like good candidates. Go deep enough to explain why decisions were made, how controls map to technical systems, how deployments are automated, and how the environment is operated after launch. MLOps and the other areas can remain secondary exposure for now.
You are getting valuable exposure, but being the only person responsible for everything also makes it difficult to tell how deep that experience really is. AWS infrastructure, landing zones, and ISO 27001 can each be substantial areas of work on their own. If you are handling all of them simultaneously, there is a risk that you are mostly firefighting or completing partial implementations rather than building repeatable expertise.
A useful test is whether you could take an empty AWS account and build a working environment from scratch using version-controlled Terraform, configuration management, and documented procedures, without relying on manual console steps or undocumented knowledge. Try rebuilding a less critical environment and record everything that still requires manual work. That list will show you where your real gaps are.
Also make sure you understand the reasoning behind your designs, not just the tools and commands. Being able to explain the trade-offs, security model, failure modes, and operational decisions will make the experience much more valuable in interviews.
I would try to remain through the ISO audit if it is genuinely close—roughly a few weeks or a couple of months away—and if you will be able to clearly document what you implemented and what the organization achieved. Being able to say that you implemented specific controls, built the supporting infrastructure, and helped the company complete the audit is a strong career story.
Do not stay indefinitely just waiting for a certification. Once the work is complete, or once you have a solid portfolio of measurable outcomes, start interviewing. Another fundamentals certification is probably less valuable right now than documenting projects, improving automation, and demonstrating ownership of systems in production.
For the ISO work, we do have a consultant helping with the policies and audit preparation. I’m responsible for most of the technical groundwork and implementation. I’m also deploying several client projects on AWS and have had the opportunity to design and build a complete landing zone. I can currently design and deploy infrastructure with security, automation, and documentation in mind, but I agree that I need to test how reproducible it is from a clean environment.