How do you approach designing for high availability and disaster recovery in the cloud?

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.

How do you manage cloud costs at scale without slowing down engineering teams?

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.

What is your approach to cloud security, and how do you implement a zero-trust model?

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.

How do you decide between a lift-and-shift migration versus a cloud-native re-architecture?

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.

Tell me about a complex cloud migration you led. What went wrong and how did you handle it?

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.

Describe a situation where you had to push back on a team that wanted to build something in a way you considered architecturally unsound.

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.

Give an example of how you have reduced cloud infrastructure costs significantly.

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.

How do you implement infrastructure as code across multiple environments and teams?

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.

How do you approach multi-cloud strategy, and when does it make sense?

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.

Walk me through how you would architect a globally distributed, low-latency application.

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.

Cloud Architect

Cloud Architect interviews tend to go broad and then deep: you'll cover AWS, GCP, and Azure to test range, and then get pushed on how you'd design specific systems with cost, security, and resilience constraints all in play. Interviewers also want to see that you've guided real organisations through migrations and understand infrastructure-as-code at production scale, not just certification-level theory. This guide covers the questions that come up most often and the answers that show you've actually done the work.

For general interview preparation tips, read our guide to common interview questions.

Prepare further

How to ace the behavioural interview (STAR method)How to prepare for a technical interview

Common Cloud Architect Interview Questions

Behavioural Interview Questions for Cloud Architect Roles

Technical Questions for Cloud Architect Candidates

What Hiring Managers Look for in Cloud Architect Interviews

What hiring managers really look for in Cloud Architect candidates:

Breadth across providers with real depth in at least one. You don't need to be an expert in all three simultaneously, but you need to be conversant in AWS, GCP, and Azure, with hands-on depth in your primary platform. Candidates who only know one well tend to struggle when the conversation shifts.
Business fluency alongside technical depth. The architects who land well translate infrastructure decisions into cost, risk, and revenue terms. Purely technical answers without business context feel academic in most interviews.
Security baked in from the start. Bring up SCPs, least privilege, and encryption early in your answers rather than waiting to be asked about security specifically. It signals how you actually think, not just what you know.
Real infrastructure-as-code experience at scale. Terraform is the de facto standard and candidates who haven't used it in production, with real state management, module governance, and drift detection, will struggle in most modern cloud teams.
Honest reasoning about trade-offs. Interviewers distrust architects who claim every problem has a clean answer. The candidates who stand out are the ones who can reason through uncertainty and make a defensible call.

Questions to Ask Your Interviewer

→What is the current cloud maturity of the organisation, and where are the biggest architectural gaps?
→How is the cloud architecture function structured: are architects embedded in teams, or do they operate as a central guild?
→What is the current state of IaC adoption, and what proportion of infrastructure is still managed manually?
→How does the organisation handle cloud cost governance, and how much visibility do individual teams have into their own spend?
→What are the biggest upcoming infrastructure challenges the team is planning for over the next 12 months?

Practise These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free on your first tracked role.

Related Roles

Available in Other Languages

Français Español