When you take responsibility for a system you didn't build, the temptation is to begin by finding what's wrong with it.
That usually isn't difficult.
Every mature system contains things you wouldn't have designed yourself. There are old dependencies, strange naming conventions, permissions that seem broader than necessary, services nobody particularly likes and architectural decisions whose original rationale has disappeared.
Finding those things doesn't mean you understand the system yet.
The harder first question is why they're there.
This matters especially when inheriting cloud infrastructure because much of the machinery that would once have been physically visible has moved behind interfaces. Servers still fail. Networks still partition. Credentials still grant authority. Storage still has limits. People still make assumptions. Some responsibilities now appear as permissions instead of keys, dashboards instead of blinking lights, service agreements instead of spare hardware and invoices instead of electric bills.
The underlying operational questions haven't disappeared. Their boundaries have moved.
So I wouldn't spend my first day trying to improve anything.
I'd start by looking.
Identity and access are useful because they show who and what can change the environment. The network begins to reveal which components can communicate and where traffic enters and leaves. Running workloads tell me what the system is actually doing, which may differ considerably from the architecture diagram. Logs and monitoring show what previous operators considered worth observing. Billing can expose expensive workloads, forgotten resources and usage patterns that aren't obvious elsewhere.
None of these provides the whole picture.
Together they give me places to ask better questions.
The people already operating the system are usually the next source of information. I want to know what they worry about, what they avoid touching, what regularly wakes someone up at night and which apparently ugly component has survived three attempted replacements.
That last category is particularly interesting.
Sometimes ugly infrastructure is simply ugly infrastructure.
Sometimes it contains a lesson nobody documented.
A strange retry policy may exist because a vendor once behaved in an unexpected way. A manual deployment step may be needless friction, or it may be the remaining protection against an automation failure that caused an expensive incident five years ago. An apparently redundant database field may still support some customer workflow nobody remembered to mention.
I don't want to romanticize inherited complexity.
I want to recover the problem before deleting the solution.
That changes the tone of early technical conversations. Basic questions aren't accusations if they're genuinely questions.
What has to be true before we ship?
What happens if this service disappears?
Where does customer data go after it enters the application?
Who can read it?
Who can change production?
What happens if a vendor changes its API, pricing or availability?
Which failure have you already designed around?
Which failure do you know you haven't?
What part of this architecture would you least like to explain during an incident?
The answers gradually produce a working model of the system.
Some of that model is technical. Some isn't.
A perfectly redundant service may still depend on one employee who knows how to recover it. A database may have excellent backups nobody has restored recently. An application may tolerate the loss of three servers while depending completely on one external API. A sophisticated monitoring system may report hundreds of metrics without answering the question everyone actually asks during an outage.
This is why I find failure boundaries more useful than technology inventories.
Knowing that a system uses Kubernetes, PostgreSQL, Redis and a particular cloud provider tells me what it's made from.
Knowing what happens