You inherit a cloud estate with one account, no tags, shared root credentials and no policy enforcement. What are your first three changes and in what order?

What is being tested

Prioritisation under real constraints. Everything here needs fixing; the question is what you do first and why.

First: identity

Eliminate shared and long-lived credentials. Federate to the existing identity provider, issue short-lived role-based credentials, enforce multi-factor authentication, and rotate then delete every static key.

This is first because it is the highest-severity, lowest-effort change. Shared credentials mean no attribution — you cannot tell who did anything — and one leaked key is total compromise. It can be substantially done in days without touching a single workload, which makes it uniquely tractable for a change of this impact.

Second: tags and cost attribution

Enforce mandatory tags at creation — owner, environment, cost centre, service — and run a campaign to tag what exists.

This is second because it is the enabler for everything else. Without ownership metadata you cannot identify who owns an expensive idle resource, cannot attribute spend, cannot decide what is safe to delete, and cannot even find the right person to ask. Every subsequent conversation stalls on "whose is this?"

It is also time-sensitive in a way the other work is not: the estate grows daily, and every untagged resource created today is more archaeology later.

Third: separate environments into accounts

Split production from non-production into separate accounts, starting with production.

This is third because it is the most valuable and the most disruptive. Account boundaries are the strongest available blast radius control — for security, for cost attribution, and for service limits, which are usually per account. A single account means a test job can exhaust a production limit, a compromised development credential reaches production, and no boundary exists at all.

It is third rather than first because it requires moving or rebuilding workloads, which needs the ownership information from step two to be safe.

Then, in the following months

• Preventive guardrails as policy — no public storage, encryption required, approved regions only — so violations become impossible rather than reported later.
• Centralised logging with retention, in an account nobody can write to.
• Infrastructure as code for everything new, with drift detection.
• A paved road: pre-approved modules that are the easiest path, so compliance is the default rather than an obstacle.

The judgement being demonstrated

Two things. First, security and attribution before optimisation — the tempting first move is to cut costs, because it is visible and popular, but you cannot safely delete anything when you do not know who owns it. Second, enablers before end states: tagging is not itself valuable, it is what makes everything after it possible.

What a strong answer adds

Naming what you do not do: adopt a full enterprise landing-zone topology immediately. Reference architectures encode genuinely hard-won knowledge about account structure and identity boundaries, and they are drawn for large regulated enterprises with many workloads. Adopt the parts that address problems you actually have, record why you excluded the rest, and revisit — rather than spending six months building a hub-and-spoke network for an estate whose real problem is shared credentials.