How would you design secure access across a multi-account AWS platform used by several engineering teams?
A company has development, staging, and production workloads across six product teams. Teams need autonomy, but production access must be short-lived, centrally auditable, and constrained by organization-wide security guardrails.
Think before revealing the answer
Clarify requirements first. Name the most important failure, security, data, and cost assumptions. Then explain your architecture as a sequence of decisions instead of a list of AWS services.
A strong answer
I would start by separating organizational boundaries from application permissions. Use AWS Organizations to define account boundaries by workload, environment, or control objective; centralize human authentication through a trusted identity provider and short-lived sessions; use roles for cross-account access; and keep workloads on narrowly scoped execution roles instead of long-lived access keys. I would layer service control policies for organization-level guardrails, permission boundaries where delegated administration needs a ceiling, and resource policies only where the service model calls for them. Then I would design logging and detection centrally so CloudTrail, configuration changes, and high-risk identity events can be reviewed across accounts. The exact account model depends on team autonomy, regulatory boundaries, blast-radius goals, and how much platform governance is required.
Why this answer is strong
The important move is to separate identity proof, authorization, organizational guardrails, and workload credentials. A cloud architect should also explain why the account boundary exists: it changes blast radius, billing visibility, policy inheritance, and operational ownership. Naming IAM roles without discussing session duration, delegated administration, auditability, or break-glass access leaves the design incomplete.
Why interviewers ask this
This reveals whether the candidate understands AWS identity as an architecture problem rather than a list of IAM features. It also tests governance, blast-radius thinking, operational ownership, and the difference between guardrails and permissions.
Common weak answers
It normalizes long-lived credentials, broad privilege, weak rotation, and poor separation between human and workload identity. It also creates unnecessary credential-recovery and audit risk.
Simplicity can be useful, but the answer ignores blast radius, environment separation, delegated ownership, quotas, billing visibility, and the possibility that different workloads need different control boundaries.
Likely follow-up questions
- Where would you place security tooling and log aggregation, and how would member accounts deliver data to it?
- How would you handle emergency access without turning a break-glass role into an everyday administrator path?
- What would change if one workload had a stricter regulatory boundary than the others?
Review before your next attempt
Design a public API that should remain available during an Availability Zone failure. What decisions matter before you choose services?
An e-commerce API must continue serving checkout traffic if one Availability Zone becomes unavailable. The business accepts degraded nonessential features but not duplicate orders or lost confirmed payments.
Think before revealing the answer
Clarify requirements first. Name the most important failure, security, data, and cost assumptions. Then explain your architecture as a sequence of decisions instead of a list of AWS services.
A strong answer
I would first clarify the availability objective, acceptable latency, read/write pattern, statefulness, recovery expectations, and whether the requirement is only multi-AZ or also multi-region. For a regional multi-AZ design, I would distribute stateless request handling across multiple Availability Zones behind a regional load-balancing layer, make deployment capacity independent across zones, and choose a data tier that replicates across zones with failure behavior I understand. I would remove single-zone dependencies such as a lone NAT path, singleton worker, or stateful local disk. I would also define health signals carefully, test zone-loss behavior, protect downstream systems from retry storms, and make graceful degradation explicit. If the business needs regional disaster tolerance, that becomes a separate data-replication, routing, consistency, and recovery problem rather than simply adding more subnets.
Why this answer is strong
The architecture starts with failure-domain and recovery requirements, not with a service diagram. A strong answer distinguishes multi-AZ high availability from multi-region disaster recovery, identifies hidden single points of failure, and describes what users experience when dependencies fail. It also treats retries, health checks, and capacity as part of resilience rather than afterthoughts.
Why interviewers ask this
Interviewers want to see whether the candidate can translate an availability statement into measurable failure assumptions and then reason through compute, networking, data, capacity, and operational consequences.
Common weak answers
That only addresses one layer. The data tier, egress path, dependencies, capacity policy, deployment process, and health model can still create a single failure point.
Multi-region can be justified, but adding it without an RTO/RPO or consistency requirement introduces cost and operational complexity before the actual failure objective is understood.
Likely follow-up questions
- How would you avoid a retry storm when one dependency becomes slow rather than fully unavailable?
- What metrics would tell you the system is surviving a zone failure rather than merely returning HTTP 200 from the load balancer?
- How would the design change for write-heavy state that cannot tolerate conflicting updates across regions?
Review before your next attempt
A document platform stores uploaded files plus searchable metadata. How would you choose storage services and data boundaries?
A SaaS product stores millions of customer documents. Users search by owner, project, labels, and created date, while files may range from kilobytes to several gigabytes.
Think before revealing the answer
Clarify requirements first. Name the most important failure, security, data, and cost assumptions. Then explain your architecture as a sequence of decisions instead of a list of AWS services.
A strong answer
I would separate the binary object from the metadata and access model unless a requirement argues otherwise. Large immutable or versioned files fit object storage well because it gives durable blob storage, lifecycle controls, versioning options, and direct delivery patterns. Searchable transactional metadata belongs in a datastore chosen for its query, consistency, indexing, and update needs rather than because the file is stored nearby. I would define the object key strategy, ownership metadata, encryption, retention, deletion semantics, upload path, and how authorization is enforced before exposing download URLs. I would also decide whether metadata changes and object creation need compensating workflows because they are usually not one atomic transaction across services.
Why this answer is strong
A strong answer decomposes the problem by access pattern and consistency boundary. The difficult part is not saying “S3 for files”; it is explaining metadata ownership, authorization, transactional gaps, lifecycle, deletion, indexing, and failure recovery when two services represent one business object.
Why interviewers ask this
This tests whether the candidate designs around data behavior and failure boundaries instead of mapping every noun directly to an AWS product.
Common weak answers
It may work at small scale, but the answer ignores object size, delivery patterns, backup cost, database growth, and whether binary data actually benefits from the database transaction model.
Object storage does not automatically provide the rich query, relational integrity, or transactional update behavior that searchable application metadata may require.
Likely follow-up questions
- How would you recover from an object upload succeeding while the metadata write fails?
- How would you implement time-limited download access without making the bucket public?
- What changes if customers require legal hold or immutable retention for selected documents?
Review before your next attempt
How would you design an event-processing workload when traffic is bursty and cost matters as much as throughput?
An analytics pipeline receives a steady baseline of events with unpredictable ten-minute bursts at 30 times normal traffic. Processing can lag by several minutes, but duplicate effects are unacceptable.
Think before revealing the answer
Clarify requirements first. Name the most important failure, security, data, and cost assumptions. Then explain your architecture as a sequence of decisions instead of a list of AWS services.
A strong answer
I would characterize the burst shape first: event rate, payload size, ordering needs, maximum acceptable delay, retry semantics, and whether processing is CPU-, memory-, network-, or dependency-bound. I would normally decouple ingestion from processing so bursts can be absorbed without forcing every downstream component to scale instantly. Then I would choose a compute model based on execution duration, concurrency, startup behavior, operational ownership, and unit economics rather than assuming serverless or containers are automatically cheaper. I would make idempotency, dead-letter handling, backpressure, visibility timeouts, and observability explicit. Finally I would compare cost at normal and peak traffic, including idle capacity, data transfer, logging, retries, and managed-service request charges.
Why this answer is strong
Cost-aware architecture begins with workload shape and failure semantics. Queues or streams can turn a sudden burst into controlled work, but they introduce lag, retry, ordering, and poison-message concerns. A mature answer also compares cost across the whole request path instead of optimizing only the compute line item.
Why interviewers ask this
This shows whether the candidate can combine architecture, operations, and economics. It also reveals whether they understand that elasticity changes failure modes and billing models rather than making capacity planning disappear.
Common weak answers
Serverless can be cost-effective, but duration, concurrency, invocation rate, downstream limits, and steady-state volume can change the economics. “Serverless” is not a cost proof.
That may satisfy throughput but ignores idle cost, overprovisioning, scaling boundaries, and the possibility that a queue can absorb short bursts more economically.
Likely follow-up questions
- What would you monitor to distinguish healthy backlog absorption from a processor that is falling permanently behind?
- How would ordering requirements change your partitioning and concurrency choices?
- What would make you move from request-driven functions to long-running container workers?