The more time I spent around Azure, the more I respected small checks.
Not the impressive parts first. The small ones.
Is public access enabled?
Is the resource named clearly?
Are diagnostic logs going somewhere useful?
Does the alert have an owner?
Is the backup actually restorable?
Is the service using managed identity or a secret someone will forget?
These questions do not look exciting. They are not the kind of things people usually put in big project summaries. But they are the checks that keep showing up when something goes wrong.
A cloud platform can look fine from a distance. The dashboard is green. The resource groups exist. The app is running. Then you look closer and find the tiny gaps.
Logs are enabled but not reviewed.
Tags exist but are inconsistent.
Alerts go to a mailbox nobody watches.
A storage account has a setting nobody remembers approving.
A service principal has more permission than it needs.
None of this means the team is careless. It usually means the team is busy.
That is why I like checklists. Not because checklists make someone a better engineer by themselves. They make it harder to forget the boring things when the work is moving quickly.
Azure has a lot of services and settings. It is easy to get drawn into the newest thing. But most environments still need the same basics: identity, network boundaries, logging, backups, cost awareness and clear ownership.
When those basics are weak, the advanced work becomes fragile.
I am learning to slow down and ask the simple questions first. They often reveal more than expected.