If you could maintain only one architecture diagram, which would it be and why?

What is being tested

Editorial judgement about which artefact survives, which is the same skill as knowing what to document at all.

Why the context diagram

It almost never goes stale. External dependencies change far more slowly than internals. A container diagram is wrong within a quarter; a context diagram is usually still accurate in two years.

Every audience can read it. Executives, auditors, new joiners, incident responders. No other architecture diagram has that property.

It settles scope, which is what most disagreements are actually about. "Is that in our system?" is answered in one look.

It takes fifteen minutes, so the maintenance cost is negligible.

What to include that most people omit

• The direction of each dependency, and who initiates.
• What flows, in one phrase per arrow.
• What happens when each external dependency is unavailable — one line each. This turns a scope diagram into a resilience artefact, and it is where most of the value is.
• The nature of the relationship: synchronous call, batch file, event stream, human process.
• Everything outside your control — third parties, other teams' systems, the identity provider. Those omissions are exactly what causes surprise during a migration or an outage.

The general principle the question tests

Control altitude deliberately. The most common diagram failure is mixing levels — a database table next to a business capability next to a cloud region. The reader cannot tell what is important, and usually neither can the author.

Naming the level before drawing forces a decision about what belongs.

The diagram-quality rules worth stating

Every box labelled with its responsibility, not just its name. Every arrow labelled with what flows and how. A legend, always. A date and an owner — an undated diagram cannot be trusted and will not be.

Why the others rank lower

Container diagrams are valuable and go stale. Component diagrams are worth drawing only for a genuinely complex container. Deployment diagrams answer a specific and important question — what fails together — but serve a narrower audience and change with every infrastructure change.