How I approach cloud engineering and DevOps projects
Strong engineering is not spinning up resources or getting Terraform to apply. It is leaving behind a system that is secure, reliable, repeatable, observable, scalable, and easy for the next person to troubleshoot. Here is how I think about each of those on a real project, and what I look for when I am the one hiring.
I have spent years in enterprise IT, the recent ones entirely on Azure, and the thing that separates the engineers I would hire again from the ones I would not has never been how fast they can stand something up. Almost anyone can get a virtual network, a database and an app running by Friday. The question is what it looks like six months later, at two in the morning, when it fails and they are on holiday. This article is the answer I give when someone asks how I work. If you are a hiring manager or a recruiter, it is what I mean when a résumé says production experience. If you are a cloud or DevOps engineer, it is the checklist I hold my own projects to, and the one the CAMPUX classes are written backwards from.
Secure means nothing reachable that need not be, and no secret a person can read. Reliable means it survives the failures you can name. Repeatable means the environment can be rebuilt from a repository, not a memory. Observable means the system tells you it is unwell before a customer does. Scalable means it grows with load and, more importantly, shrinks after. Maintainable means the next engineer can find the fault at two in the morning without ringing you.
Architecture: decide the boundaries before the resources
The first thing I draw is not a service. It is a line: what talks to what, and what is not allowed to. On Azure that line is a management group and subscription layout, a hub-and-spoke network, and a decision about which tier of the application is allowed to be public. The storefront is public. The API behind it is not. The database is reachable from the API subnet and nowhere else. Every later choice, from private endpoints to firewall rules to what the pipeline is permitted to deploy, follows from that drawing. Skipping it is the single most expensive mistake I see in projects I inherit, because an estate with no boundaries cannot be secured after the fact; it can only be rebuilt.
The second thing I decide is what I am not going to run. A managed database beats one on a virtual machine unless there is a specific, named reason. App Service beats a VM for a web tier nine times out of ten. Every layer I hand to the platform is a layer I do not patch, back up or wake up for. Good architecture is mostly a list of things you chose not to own.
Infrastructure as code: the repository is the truth, the portal is a view
I do not click. Not because clicking is beneath anyone, but because a click leaves no record of intent. Six months on, nobody can say why that subnet is a /24 or whether the firewall rule was deliberate or a debugging leftover. In Bicep or Terraform the answer is in the file, with a commit message and a reviewer's name next to it. On my projects the rule is simple: if it is not in the repository, it does not exist, and the portal is one way of looking at what the repository put there.
Two habits make this real rather than aspirational. First, what-if or terraform plan runs on every pull request and its output is read, not skimmed, before anything applies. Second, modules are small and boring. A module that creates a storage account with the right redundancy, private endpoint and diagnostic settings gets reused forty times; a clever module that does everything gets debugged forty times. Class 20 and Class 21 teach this the way I do it at work, including the state file, which is the part people learn the hard way.
CI/CD: a merge is the deployment, and nothing has a password
A pipeline is not a place to run scripts. It is the only door into production, which means it has to be the most carefully guarded thing in the estate. Mine follow a shape that has not changed in years: a pull request builds, tests and plans; a merge to main applies to the non-production environment; a promotion to production waits for an approval from a named person and a health check that actually exercises the application. Rolling back is a revert, not a hero.
The part I check first on someone else's pipeline is how it authenticates. If there is a service principal secret sitting in a variable, the project has a problem that no amount of scanning fixes. GitHub Actions and Azure DevOps both federate to Azure with OpenID Connect now, so the pipeline proves who it is with a short-lived token and there is no secret to leak, rotate or find in a log. Class 23 is that setup, end to end, and it is the one I would ask a candidate to explain at a whiteboard.
Monitoring: the system tells you before the customer does
Observability is not a dashboard. A dashboard is what you look at after someone has already told you it is broken. What I build is the chain that makes the phone ring for the right reason: every resource ships its diagnostic logs to one Log Analytics workspace that was designed on purpose, the application is instrumented with Application Insights so a slow dependency shows up as a slow dependency and not as a vague complaint, and a small number of alerts fire on symptoms customers would notice, routed to a person through an action group. Not forty alerts. Five or six that mean something, each with a runbook line saying what to do.
The test I apply is unglamorous. I break something small on purpose in the non-production environment and time how long until the alert lands and whether the message would let a stranger find the fault. If the answer is "it would not", the monitoring is decoration. Classes 28 to 30 are built around that test, and the KQL that answers it.
Security: least privilege, no secrets in reach, and a policy that says no
I treat security as a property of the design, not a phase at the end. Three rules do most of the work. Identity over secrets: applications use managed identities, and anything that must be a secret lives in Key Vault and is referenced, never copied. Least privilege that is actually least: Reader by default, a scoped role where a task needs it, and nobody holding Owner on a subscription day to day; privileged access is eligible, time-bound and approved. And guardrails as code: Azure Policy denying public IPs, unencrypted storage and untagged resources, so the mistake cannot be made rather than being found later by a scan.
Then the scan anyway. Dependencies and container images get checked in the pipeline before they ship, and Defender's secure score is read every week, not admired once. None of this is exotic. It is the difference between a project I would put my name on and one I would not, and it is why Class 31 and its two parts sit in the middle of the course rather than at the end.
Testing: prove the infrastructure, not just the code
Application tests are table stakes and I will not spend words on them. What most projects skip is testing the infrastructure and the operations around it. Does the private endpoint actually resolve privately? Run a lookup from inside the network in the pipeline and fail the build if it returns a public address. Does the backup restore? Restore it, to a scratch resource group, on a schedule, and delete it after. Does the failover work? Fail over, on purpose, in a window you chose. A control you have never exercised is a rumour.
The habit I try to build in people is to write the verification before the change. If you cannot say how you will prove the change worked, you are not ready to make it. Every lab in the labs library is written that way for that reason: a checkpoint you can run, and a teardown.
Scaling: up is easy; the discipline is down
Anyone can scale up. The bill and the discipline are in scaling back down when the load goes away, and in choosing a shape that scales at all. A stateless web tier on App Service with autoscale rules in both directions; a database sized for its steady state with a plan for its peak; queues between tiers so a burst becomes a backlog rather than an outage. I also decide early what will not scale and say so in the design: a licence pinned to a machine, a legacy dependency, a regional constraint. Pretending everything scales is how a November peak becomes a January post-mortem.
Cost is part of this, not a separate concern. A budget with an alert exists before the first resource does. Reservations are bought against a measured baseline, never a guess. And the person who designed the scaling reads the cost report, because the two are the same number viewed from different sides.
Troubleshooting: design for the two in the morning
Everything above is really in service of this one. A system is easy to troubleshoot when its boundaries are clear, its configuration is in a repository, its logs are in one place, its alerts say what is wrong, and its secrets are not in the way. When an incident comes, the sequence is fixed: detect, size the blast radius, mitigate first and fix second, communicate in plain words on a schedule, and write the postmortem without blame and with actions that get done. Rollback is always on the table because the pipeline made it cheap.
The measure I care about is not whether I can find the fault. It is whether the newest engineer on the team can, with the runbook, without ringing me. If they cannot, the system is not finished, however well it runs on a good day. Class 36 teaches the sequence; the rest of the course is what makes it possible to follow.
If you are hiring
Ask a candidate to walk you through a project against these six words, and listen for the second half of each sentence. "We used Terraform" is not an answer; "we used Terraform, plan ran on every PR, and state lived in a locked storage account with versioning" is. "We had monitoring" is not an answer; "we alerted on p95 latency and failed dependency calls, and the alert carried the runbook link" is. The certificates on the résumé tell you what they have read. The second halves tell you what they have run.
If you are learning
This is the standard the whole of CAMPUX is written to. The classes go in the order a real project goes: boundaries and identity first, then the network and compute, then the repository and the pipeline, then the observability, security and operations that make it something you would put your name on. The three capstones are the proof: repositories that pass this checklist, that you can put in front of a hiring manager and defend line by line. Read Class One to see the tone, or, if you are already certified and know the basics, start at Class 20, where the checklist begins to bite.
It worked for them.
Questions people also ask
What makes a cloud engineering project "production-grade"?
It is secure by design (least privilege, managed identities, no secrets in reach, policy that denies the obvious mistakes), reliable against the failures you can name, rebuildable from a repository, observable enough that an alert reaches a person before a customer notices, able to scale in both directions, and documented well enough that the newest engineer can troubleshoot it. A project that runs but cannot be rebuilt or diagnosed is a prototype, however long it has been live.
Should I learn Terraform or Bicep for Azure?
Learn one properly and be able to read the other. Bicep is the shortest path on Azure and has no state file to manage; Terraform is the one most employers list and the one that spans clouds. What matters more than the tool is the habit: a plan on every pull request, small reusable modules, and the repository as the only source of truth.
How do you keep secrets out of a CI/CD pipeline?
Federate the pipeline to Azure with OpenID Connect so it authenticates with a short-lived token instead of a stored service principal secret, keep any remaining secrets in Key Vault and reference them from the app rather than copying them into variables, and scope the pipeline's identity to the resource group it deploys, so a compromised pipeline cannot reach anything else.
What should I ask a DevOps engineer in an interview?
Ask them to describe one project against six properties: secure, reliable, repeatable, observable, scalable, maintainable. Then ask for the specific mechanism behind each claim: how the pipeline authenticated, where state lived, what the alerts fired on, how a rollback worked, what happened the last time it broke. Candidates who have run production answer in mechanisms; candidates who have watched it answer in tool names.