4) Technical and professional questions (the ones that decide the offer)
This is where US interviews separate “knows the services” from “can run the system.” You’ll get questions that force you to pick tradeoffs, explain failure modes, and show you can automate repeatability. Expect AWS Engineer / Azure Engineer / GCP Engineer angles depending on the company’s stack.
Q: Walk me through how you design a secure IAM model for a multi-team cloud environment.
Why they ask it: IAM mistakes are the #1 way teams accidentally create breaches.
Answer framework: Principle-of-least-privilege ladder — identity source → roles → boundaries → auditing.
Example answer: “I start with a clear identity source—SSO with MFA—and map roles to job functions, not individuals. Then I use short-lived credentials and role assumption, with permission boundaries or SCPs to prevent privilege creep. For teams, I prefer reusable roles tied to CI/CD and workload identity rather than long-lived keys. Finally, I enable centralized logging and periodic access reviews so we can prove who had access to what and when.”
Common mistake: Talking only about ‘admin vs read-only’ and ignoring boundaries, auditing, and key hygiene.
Q: In AWS, how would you choose between ECS, EKS, and Lambda for a new service?
Why they ask it: They want to see decision-making, not service trivia (AWS Engineer signal).
Answer framework: Tradeoff matrix — workload shape, ops burden, latency, scaling, team maturity.
Example answer: “If it’s event-driven with spiky traffic and simple dependencies, I’ll consider Lambda for speed and low ops. If we need containers but want simpler operations, ECS is often a strong default. If the org already runs Kubernetes well and needs portability or advanced scheduling, EKS can make sense—but I’m honest about the operational tax. I’d also factor in observability, deployment model, and how on-call will work.”
Common mistake: Defaulting to EKS because it’s ‘industry standard’ without acknowledging complexity.
Q: In Azure, how do you implement private connectivity to PaaS services?
Why they ask it: Azure networking is a frequent failure point (Azure Engineer signal).
Answer framework: Pattern explanation — private endpoints, DNS, routing, and access controls.
Example answer: “For Azure PaaS like Storage or SQL, I prefer Private Endpoints so traffic stays on the Microsoft backbone. Then I set up Private DNS zones and link them to the right VNets so name resolution works without hacks. I lock down public network access, validate NSGs and UDRs, and test from the workload subnet. Finally, I document the DNS flow because that’s where teams get stuck later.”
Common mistake: Saying ‘use a VPN’ and skipping Private DNS and public access disablement.
Q: In GCP, how do you structure projects and IAM for separation of duties?
Why they ask it: They’re checking governance maturity (GCP Engineer signal).
Answer framework: Org → folders → projects → service accounts — explain boundaries and billing.
Example answer: “I separate environments into distinct projects under folders, with centralized billing and logging. IAM is assigned at the narrowest scope possible, and I use service accounts per workload with Workload Identity where applicable. For separation of duties, I keep security/admin roles limited and use groups, not individuals. This structure makes audits and blast-radius control much easier.”
Common mistake: Putting everything in one project and trying to ‘fix it’ with ad-hoc IAM bindings.
Q: Explain how you’d build Terraform modules that teams actually use (and don’t fork).
Why they ask it: They want scalable infrastructure practices, not one-off IaC.
Answer framework: Product mindset — interface, versioning, guardrails, and documentation.
Example answer: “I treat modules like internal products: a small, stable interface with sensible defaults. I version them, publish changelogs, and enforce formatting and tests in CI. I also bake in guardrails—like encryption and logging—so teams get security by default. And I write examples that mirror real use cases, because adoption lives or dies on copy-paste clarity.”
Common mistake: Over-engineering modules with dozens of variables and no tests.
Q: What’s your approach to observability in cloud: metrics, logs, and traces?
Why they ask it: They need someone who can shorten MTTR and prevent alert fatigue.
Answer framework: “Golden signals” + correlation — latency, traffic, errors, saturation; then link to traces/logs.
Example answer: “I start with SLOs and the golden signals, then build alerts that page only when user impact is likely. Metrics tell me ‘what,’ traces help me find ‘where,’ and logs explain ‘why.’ I standardize correlation IDs and structured logging so we can pivot quickly during incidents. The goal is fewer alerts, faster diagnosis, and clear ownership.”
Common mistake: Listing tools (Datadog, CloudWatch, Prometheus) without explaining alert strategy.
Q: How do you design for multi-region disaster recovery, and how do you test it?
Why they ask it: DR is easy to promise and hard to prove.
Answer framework: RTO/RPO-first — define targets, pick architecture, automate failover, run game days.
Example answer: “I start by agreeing on RTO and RPO with the business, because that drives cost. Then I pick a DR pattern—active/active, active/passive, or pilot light—and design data replication accordingly. I automate failover steps and keep DNS and secrets ready. Most importantly, we test: scheduled game days with real runbooks and clear success criteria.”
Common mistake: Saying ‘we have backups’ as if backups equal DR.
Q: What would you do if your CI/CD pipeline starts deploying broken infrastructure changes?
Why they ask it: They’re testing safety mechanisms and rollback thinking.
Answer framework: Safety stack — stop the bleeding, isolate, verify, prevent recurrence.
Example answer: “First I’d pause the pipeline and revoke deploy permissions if needed to stop further damage. Then I’d identify the last known good state and roll back using versioned Terraform state or a previous release artifact. Next I’d add or tighten controls: plan/apply separation, policy checks, and integration tests in a staging environment. Finally, I’d write a short postmortem so the fix becomes a system improvement, not tribal knowledge.”
Common mistake: Manually hot-fixing in the console and leaving IaC/state inconsistent.
Q: How do you handle secrets management for cloud workloads?
Why they ask it: Secrets leaks are common, and US companies are sensitive to audit findings.
Answer framework: Lifecycle model — store, access, rotate, audit.
Example answer: “I keep secrets in a managed store like AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager, not in env files or CI variables long-term. Workloads should access secrets via identity—roles/service accounts—so we avoid static keys. I set rotation where feasible and log access for audits. And I design for least privilege: a service gets only the secrets it needs.”
Common mistake: Treating base64 in Kubernetes as ‘encryption.’
Q: Which US compliance frameworks have you worked with, and how did they change your cloud design?
Why they ask it: They need to know you can build systems that pass audits (SOC 2, HIPAA, PCI DSS).
Answer framework: Control mapping — pick one framework, name 2–3 controls, show implementation.
Example answer: “I’ve supported SOC 2 readiness. Practically, that meant centralized logging, access controls with MFA and least privilege, and change management evidence via CI/CD approvals. We also enforced encryption in transit and at rest and documented incident response procedures. The biggest shift was making ‘auditability’ a design requirement, not paperwork at the end.”
Common mistake: Name-dropping frameworks without explaining concrete controls.
Q: Explain a networking outage you’ve debugged in the cloud. What signals did you look at first?
Why they ask it: This is an insider question—cloud networking breaks in non-obvious ways.
Answer framework: Layered isolation — DNS → routing → security rules → service health.
Example answer: “I start with DNS resolution and basic connectivity tests from the workload subnet. Then I check routing: VPC/VNet routes, NAT, and whether traffic is hairpinning through the wrong path. Next I validate security controls—SG/NSG rules, NACLs, firewall policies—and compare against a known-good environment. I also check cloud provider health dashboards to rule out regional issues.”
Common mistake: Jumping straight to ‘it must be the app’ without proving network layers.