Capability evidence
Assess the workload boundary, not recall of provider product names.
A useful assessment includes ambiguous service ownership, two tenants, a privileged human and workload identity, overlapping networks, a public and private dependency, changing infrastructure, a managed database, a quota, a failed zone, a missing backup object, a restore with stale data, a cost anomaly, and a provider feature with no proven exit. It should show whether the person can make tradeoffs visible and recover the service without pretending the provider owns the whole system.
01Cloud and workload fit
Give the person users, tenant and data boundaries, service objectives, load shapes, latency and locality, dependencies, existing systems, team capability, provider and region constraints, security and privacy obligations, cost model, growth, recovery, portability and time horizon. Ask which service and deployment model fits and what should remain simpler or outside cloud.
Confirm: The person begins with workload requirements, distinguishes infrastructure, platform and software service responsibilities, challenges unnecessary distribution and managed-service complexity, identifies provider and region coupling, states tradeoffs across operation, security, reliability, performance, cost and sustainability, and can recommend on-premises, hybrid, multiple providers, one provider or no move without treating any pattern as maturity by itself.
02Tenancy, identity, network, and infrastructure boundaries
Present organizations and accounts or subscriptions or projects, shared services, environments, human and workload identities, federation, roles, policies, secrets, keys, certificates, public and private networks, DNS, ingress and egress, firewall rules, infrastructure code, state, provider defaults, drift, privileged changes, and an emergency path.
Confirm: The person creates boundaries from workload and risk needs, removes location-based implicit trust, uses authenticated identities and explicit authorization, separates administration from workloads, scopes and rotates access, protects infrastructure state and secrets, reviews generated plans and policy effects, detects drift, records exceptions, and preserves break-glass use without turning network placement or a managed identity into proof of safety.
03Runtime, data, resilience, and recovery
Use a workload spanning compute or containers, storage, a managed database, queues, object storage, caches, third-party APIs and background work. Add deployment, scaling, quota, instance and zone loss, regional control-plane limits, partial network failure, key or credential expiry, replication lag, corrupt data, backup loss, restore, failover, replay, rollback and reconciliation.
Confirm: The person separates application, platform and provider failure domains, connects health to user and data evidence, designs graceful degradation and bounded retries, tests load and quotas, states consistency and replication limits, distinguishes backup from restorable service, exercises recovery and dependency behavior, reconciles side effects, protects recovery identities, and can explain what one region or provider cannot survive.
04Operation, economics, and evolution
Review resource and ownership inventory, logs, metrics, traces, alerts, service objectives, incidents, support escalation, audit evidence, capacity, performance, quotas, reservations and rates, allocation, budgets, anomalies, unit cost, unused resources, provider changes, image and service updates, migration, export, lock-in, decommissioning, and knowledge spread.
Confirm: The person ties provider and application telemetry to a workload and release, states observation blind spots, builds actionable alerts and runbooks, makes cost and usage data timely and attributable, balances rate and usage changes with service risk, stages provider changes, keeps data and dependencies exportable where required, removes access and resources deliberately, and leaves the client able to operate or exit without private memory.
