Cloud Architect Interview Questions

High availability and disaster recovery are related but distinct concerns, and I design for them separately. For HA, I start with multi-AZ deployments as a baseline for any production workload: no single component should have a single point of failure within a region. I use managed services wherever they handle HA natively, such as RDS Multi-AZ, ECS with ALB, and S3. I define SLOs upfront (typically 99.9% or 99.95%) and work backwards to determine what redundancy level justifies the cost. For DR, I define RTO and RPO targets with stakeholders before touching infrastructure. A workload with an RTO of four hours looks very different from one with fifteen minutes: the former might use daily snapshots to a secondary region, while the latter needs near-real-time replication and a hot standby. I also schedule quarterly DR drills, because an untested recovery plan is not a plan.

Cost control at scale is an organisational problem as much as a technical one. On the technical side, I implement tagging policies enforced at account creation so every resource has a cost centre, team, and environment tag from day one. I use AWS Cost Explorer or GCP Billing with budget alerts per team, giving engineers visibility into what their workloads cost in near real time. I also run a weekly Trusted Advisor or Recommender check to surface underutilised resources, Reserved Instance coverage gaps, and right-sizing opportunities. The organisational side matters just as much: I advocate for a "you build it, you pay for it" model where teams own their cloud spend and have a monthly review. This creates accountability without requiring a central gatekeeper. I have seen well-run FinOps programmes cut cloud spend by 30 to 40% within six months without any performance regression.

Zero trust starts with the principle that no network location is inherently trusted, which means shifting from perimeter-based controls to identity and context-based ones. In practice this means replacing VPN-based access patterns with identity-aware proxies like Google BeyondCorp or AWS Verified Access, enforcing least-privilege IAM policies with regular access reviews, and encrypting data in transit and at rest by default. I use AWS SCPs or GCP Organisation Policies to enforce guardrails at the account level so that no individual team can accidentally open a public S3 bucket or disable CloudTrail. I also separate workloads into different accounts or projects by security boundary rather than just by environment, so a compromise in a dev environment cannot reach production resources even with valid credentials. Secrets management goes through Secrets Manager or Vault, with rotation policies that make long-lived credentials impossible.

This decision should be driven by business risk, timeline, and the eventual cost of running the workload in each state, not by a general preference for one approach. Lift-and-shift is the right first step when the primary goal is to exit a data centre on a fixed deadline, when the application is stable and low-change, or when the team lacks cloud-native expertise to re-architect safely. It is also the only viable approach for legacy workloads that cannot be containerised or where the source code is unavailable. Cloud-native re-architecture makes sense when the workload has variable load patterns that serverless or containerisation would serve better, when the operational cost of running the lifted version on cloud VMs is comparable to or higher than on-premise, or when the team has the capacity to do it alongside normal delivery. I typically recommend a phased approach: lift first, then re-architect the components where the cost or operational benefit is clearest, leaving stable low-traffic services as-is.

I led the migration of a legacy monolithic ERP system to AWS for a manufacturing client. The application had not been touched in seven years and had undocumented dependencies on network drives and local COM objects. We discovered these only during the pilot migration of our first business unit. Rather than trying to fix everything before migrating, I introduced a strangler-fig pattern: we lifted the monolith to an EC2 fleet behind an ALB, then identified the three most network-sensitive components and replaced them with managed AWS equivalents over twelve weeks while the rest ran on the lifted version. The second discovery was that the application wrote temporary files to a local path hardcoded in config: we caught this in staging because we had set up a network filesystem emulation layer as a safety net. The migration completed on time and the client saw a 22% infrastructure cost reduction in the first full quarter on cloud.

A development team wanted to store all session state in a single large ElastiCache cluster without any replication, as a cost-saving measure. The application was consumer-facing and the loss of that cache would log out all active users. I built a cost model showing that the difference between a single-node cluster and a replicated one was under $400 per month, against a projected revenue loss of roughly $12,000 per hour of downtime based on the application's transaction volume. I presented this not as an architecture opinion but as a risk/cost calculation, framing the replication question as a business decision for the product owner to make with full information. The team agreed to the replicated setup and we also added a graceful session expiry path so future cache failures would trigger a re-authentication flow rather than a hard logout.

I joined a team running about $180,000 per month in AWS spend. The first thing I did was pull a Cost Explorer breakdown by service and tag, which revealed that 34% of spend was on EC2 instances running at under 15% CPU utilisation on average. A further 12% was on data transfer fees caused by an architecture that routed all inter-service traffic through a NAT Gateway rather than using VPC endpoints for S3 and DynamoDB. I right-sized the underutilised instances using Compute Optimizer recommendations, reducing EC2 spend by 28%. I replaced the NAT Gateway routing with VPC endpoints, eliminating the data transfer cost entirely. I also converted on-demand spend for the stable baseline workloads to Compute Savings Plans, adding a further 22% saving on that portion. Total reduction was from $180,000 to approximately $98,000 per month within three months, with no performance degradation.

My standard approach is Terraform with a module-based architecture, where shared infrastructure primitives (VPCs, IAM roles, security groups) live in a central module library and individual teams consume them as dependencies rather than writing their own. I use Terragrunt to manage configuration across environments, keeping environment-specific values in YAML files and keeping the Terraform code itself environment-agnostic. State is stored in S3 with DynamoDB locking and a separate state bucket per environment and account. CI/CD runs terraform plan on every PR, posting the plan output as a comment for review before any apply. For teams new to IaC, I implement a policy-as-code layer with Open Policy Agent or Checkov to catch security misconfigurations before they reach code review. I enforce tagging and naming conventions at the module level so every resource in every environment is traceable by team, environment, and cost centre without additional effort.

Multi-cloud is often proposed as a risk-mitigation strategy but it introduces its own risks: operational complexity, skills fragmentation, and higher total cost of ownership. I advise clients to distinguish between genuine multi-cloud (active workloads on two or more providers simultaneously) and cloud portability (building in a way that does not create hard lock-in). For most organisations, cloud portability through containerisation and abstracted data layers is the right answer: it preserves optionality without paying the operational cost of running two cloud environments day to day. True multi-cloud makes sense in three scenarios: regulatory requirements mandating vendor diversity, acquisitions where integrating infrastructure would cost more than running two estates, and specific services where one provider is clearly superior for a particular workload. When I do implement multi-cloud I centralise identity with an external IdP, use a common monitoring layer, and keep the network boundary between clouds as narrow as possible.

The starting point is to map the latency budget: what is the maximum acceptable response time for the user-facing request, and how does that break down across network transit, compute, and storage? For a globally distributed application I would use a CDN like CloudFront or Fastly for static assets and edge-cacheable API responses, placing compute in three to four regions selected based on user geography and traffic volume. API routing goes through a global load balancer such as AWS Global Accelerator or GCP Global LB, directing requests to the nearest healthy region. For the data layer, the decision depends on consistency requirements: if eventual consistency is acceptable, DynamoDB Global Tables or Spanner provide low-latency reads globally with automatic replication. If strong consistency is required, I keep a single primary region with read replicas in secondary regions. I would also implement circuit breakers at the regional boundary so a single-region outage degrades gracefully rather than causing a global failure.