Cloud Engineer Interview Questions

Summary

A region is a geographic area with several availability zones: isolated data centres with independent power and networking connected by low-latency links. Run production across two or three zones (load balancer, app instances, Multi-AZ databases) to survive a zone failure; use multiple regions only when RTO/RPO or regulation requires surviving a whole-region event.

Longer Answer

Zone redundancy is cheap and standard. Region redundancy adds data replication, failover automation and cost. Azure also has paired regions; Google Cloud VPC networks are global but resources are still zonal or regional.

Key Points

• Region = area; zone = isolated data centre(s).
• Multi-AZ for production by default.
• Multi-region when requirements demand it.
• Know which services are zonal, regional or global.

Deep dive: Cloud Computing Tutorial: Regions and Availability Zones

Summary

By default everything is denied. If any applicable policy (identity, resource, permission boundary, SCP, session policy) has an explicit Deny matching the request, it's denied. Otherwise it's allowed only if an Allow matches and every guardrail layer (SCPs, boundaries, session policies) also permits it.

Longer Answer

Resource policies can grant cross-account access, but the caller's account must also allow it. Conditions (source IP, MFA, tags, region) refine statements. Tools: IAM policy simulator and Access Analyzer.

Key Points

• Implicit deny by default.
• Explicit deny always wins.
• Allow needed, within all guardrails.
• Conditions refine; simulate to verify.

Deep dive: Cloud Computing Tutorial: How Policies Are Evaluated

Summary

People sign in through SSO with MFA (IAM Identity Center, Entra ID, Cloud Identity) and get temporary credentials; CI/CD uses OIDC federation to roles; workloads use roles, managed identities or attached service accounts. Then remove IAM users and keys, and block their creation with guardrails.

Longer Answer

Google Cloud has an organisation policy to disable service-account key creation; AWS SCPs can deny iam:CreateUser/iam:CreateAccessKey except for break-glass. Keep a monitored break-glass path.

Key Points

• SSO + MFA for people.
• OIDC for CI/CD.
• Roles / managed identities for workloads.
• Block key creation with guardrails.

Deep dive: Cloud Engineering in Production: The Key on GitHub

Summary

Enable account-level Block Public Access (and prevent disabling it with an SCP), keep ACLs disabled, serve public content through a CDN with a private origin (CloudFront origin access control), share private files with short-lived presigned URLs, separate buckets by data classification, and monitor with Access Analyzer and Macie. Azure: disallow anonymous blob access; Google Cloud: public access prevention and uniform bucket-level access.

Longer Answer

Public exposure usually comes from a quick fix that outlives its purpose, or from a bucket's contents changing while its policy doesn't.

Key Points

• Block public access at account level.
• CDN with private origin.
• Presigned URLs for private files.
• Separate data and monitor.

Deep dive: Cloud Engineering in Production: The Bucket Anyone Could List

Summary

Multi-AZ (zone-redundant HA) keeps a synchronous standby in another zone and fails over automatically: it's for availability. Read replicas are asynchronous copies for scaling reads and reporting, and can be promoted; they may lag. Neither replaces backups, because bad writes are replicated.

Longer Answer

Read-your-own-writes requires reading from the primary after writing. Cross-region replicas or global databases support DR.

Key Points

• Multi-AZ: synchronous, availability.
• Replicas: asynchronous, read scaling.
• Replication lag matters.
• Still need backups.

Deep dive: Cloud Computing Tutorial: Managed Relational Databases

Summary

Start with visibility (tags, cost per team, budgets, anomaly detection), remove waste (idle and unattached resources, old snapshots, logs kept forever), rightsize from metrics, then commit (savings plans/reservations) for the stable baseline, use spot for interruptible work, and address architecture (data transfer paths, storage tiers, Arm instances, serverless for spiky loads).

Longer Answer

FinOps is shared: engineers see what their services cost. Order matters: commit after rightsizing, or you lock in waste.

Key Points

• Visibility first.
• Remove waste, then rightsize.
• Commit to the baseline; spot for batch.
• Fix architecture-level costs.

Deep dive: Cloud Engineering in Production: The Resources Nobody Owned

Summary

RTO is the maximum acceptable downtime; RPO the maximum acceptable data loss in time. Strategies in increasing cost: backup and restore (hours), pilot light (core data replicated, minimal infra), warm standby (scaled-down full copy running), and multi-site active-active (near-zero RTO/RPO).

Longer Answer

Choose the cheapest strategy meeting each system's targets; test regularly, because untested DR rarely meets its RTO.

Key Points

• RTO = downtime; RPO = data loss.
• Backup/restore, pilot light, warm standby, multi-site.
• Cost rises with tighter targets.
• Test it.

Deep dive: Cloud Computing Tutorial: Reliability and Disaster Recovery

Summary

IaaS gives you virtual machines and networks (EC2, Azure VMs, Compute Engine) and you manage the OS upwards. PaaS runs your application on a managed platform (Elastic Beanstalk, App Service, App Engine). Serverless runs functions or containers on demand with scaling handled for you (Lambda, Azure Functions, Cloud Run). SaaS is a finished application (Microsoft 365, Salesforce).

Longer Answer

The trade-off is control versus operational burden: further up the stack you patch and scale less, but configure less. Most organisations mix models: managed databases (PaaS), containers on a managed orchestrator, functions for event glue.

Key Points

• IaaS: you manage OS and up.
• PaaS: you manage the app.
• Serverless: code or containers, scaling handled.
• SaaS: you configure a finished product.

Deep dive: Cloud Computing Tutorial: Cloud Computing Introduction

Summary

The provider secures the cloud itself (facilities, hardware, hypervisor, and for managed services the OS and engine patching); the customer secures what they put in it. For a managed database the customer owns network access rules, IAM and database users, encryption choices, backup retention settings, schema and data, and how applications connect.

Longer Answer

Most cloud incidents are on the customer side: public storage, leaked keys, over-privileged roles, unpatched VMs. The line moves up as you use more managed services, but identity and data are always yours.

Key Points

• Provider: security of the cloud.
• Customer: security in the cloud.
• Managed DB: you own access, data, config.
• Identity and data are always yours.

Deep dive: Cloud Computing Tutorial: The Shared Responsibility Model

Summary

An organisation-wide audit trail (CloudTrail / Activity Log / Cloud Audit Logs) to a protected log account, threat detection (GuardDuty / Defender for Cloud / Security Command Center), configuration rules and a security posture dashboard, guardrails (SCPs / Azure Policy / org policies), MFA and SSO, blocked public storage, default encryption, and budgets with anomaly alerts.

Longer Answer

Enable detection in all regions, including unused ones, since attackers favour them. Route findings to people who act on them.

Key Points

• Central, tamper-resistant audit logs.
• Threat detection in all regions.
• Guardrails and secure defaults.
• Cost anomaly alerts.

Deep dive: Cloud Computing Tutorial: A Cloud Security Baseline

Summary

Use AWS Organizations (Control Tower) with OUs for security (log archive, audit), infrastructure (network, shared services), production and non-production workloads, and sandboxes; one account per environment per workload or team; SSO with permission sets; SCP guardrails; central logging and security tooling with delegated administrators; account vending through code. Azure: management groups and subscriptions; Google Cloud: folders and projects.

Longer Answer

Accounts give the strongest blast-radius and billing boundaries. Keep the management account empty of workloads.

Key Points

• OUs by function and environment.
• Central security and log accounts.
• SSO and guardrails.
• Account vending as code.

Deep dive: Cloud Engineering in Production: A Landing Zone for a Regulated Start-up

Summary

Consider runtime length and pattern, operational capacity and control needs. Spiky, event-driven, short tasks suit functions; long-running HTTP services and workers suit containers (Cloud Run, ECS on Fargate, Container Apps, or Kubernetes for platforms); VMs fit legacy software, special OS/kernel needs or licensing. Cost depends on utilisation: functions are cheap at low or spiky load, containers/VMs at steady high load.

Longer Answer

Check limits: function timeouts (15 minutes on Lambda), payload sizes, cold starts, and database connection behaviour under high concurrency.

Key Points

• Functions: event-driven, spiky, short.
• Containers: services and workers.
• VMs: special needs.
• Model cost by utilisation.

Deep dive: Cloud Computing Tutorial: Containers in the Cloud

Summary

Statelessness, idempotency (events can be delivered more than once), timeouts and payload limits, cold starts (small packages, initialisation outside the handler), concurrency limits and their effect on downstream systems such as databases, and observability with structured logs and tracing.

Longer Answer

Use queues to buffer and control concurrency, reserved concurrency for critical functions, and proxies (RDS Proxy) or HTTP-based data APIs for relational databases.

Key Points

• Stateless and idempotent.
• Limits and cold starts.
• Concurrency vs downstream capacity.
• Observability built in.

Deep dive: Cloud Computing Tutorial: Serverless Functions

Summary

Object storage (S3, Blob, Cloud Storage) holds files behind an HTTP API, scales without limits and is cheapest; block storage (EBS, Managed Disks, Persistent Disk) is a disk for one VM in one zone, used for databases and OS volumes; file storage (EFS, Azure Files, Filestore) is a shared network file system for several servers.

Longer Answer

Use object storage for most application data, backups and media; block for low-latency single-server needs; file for legacy shared-file workloads. Snapshots of block volumes are incremental and can be copied across regions.

Key Points

• Object: API, cheap, unlimited.
• Block: disk for one VM, zonal.
• File: shared NFS/SMB.
• Pick by access pattern.

Deep dive: Cloud Computing Tutorial: Block and File Storage

Summary

Assume at-least-once delivery: make consumers idempotent, set the visibility timeout longer than processing time (or extend it), use dead-letter queues after a few attempts and alert on them, batch where possible and handle partial batch failures. Use FIFO queues or ordering keys only when order matters.

Longer Answer

SQS default visibility timeout is 30 seconds; messages not deleted in time reappear. Pub/Sub has ack deadlines and Service Bus has lock durations with the same semantics.

Key Points

• At-least-once: idempotent consumers.
• Visibility timeout > processing time.
• Dead-letter queues with alerts.
• Ordering only when needed.

Deep dive: Cloud Computing Tutorial: Queues, Topics and Events

Summary

Deploy every component in the request path across zones (including NAT gateways, caches, brokers), pre-provision enough capacity in the remaining zones to absorb the loss without launching anything (static stability), use managed multi-AZ services, keep traffic zone-aware, and practise zonal shifts and failure game days.

Longer Answer

Hidden singletons (one NAT gateway, one Redis instance, a cron server) are the usual weak point.

Key Points

• Multi-AZ for every component.
• Static stability: pre-provisioned capacity.
• Managed HA services.
• Practise zone failures.

Deep dive: Cloud Engineering in Production: The Zone Outage We Didn't Survive

Summary

Define RPO/RTO, centralise backups with policies applied by tag, copy them to another account and region, make them immutable (vault lock), monitor backup jobs and recovery-point age, and run automated restore tests plus periodic full recovery drills that measure real RTO.

Longer Answer

Restores need configuration too (parameter groups, replicas, secrets, connection strings); keep them in code.

Key Points

• Policies by tag.
• Cross-account, cross-region, immutable.
• Monitor jobs.
• Test restores regularly.

Deep dive: Cloud Engineering in Production: The Backup That Didn't Restore

Summary

A VPC (VNet, VPC network) from a central address plan, public subnets only for load balancers and NAT, private subnets for compute and data across zones, security groups by tier, VPC endpoints for cloud services, centralised egress where needed, and flow logs. Connect networks through a transit hub rather than many peerings.

Longer Answer

See the networking interview pack and course for depth: overlapping CIDRs, NAT port exhaustion, MTU and DNS.

Key Points

• Planned, non-overlapping ranges.
• Public vs private subnets across zones.
• Security groups by tier.
• Endpoints, hubs, flow logs.

Deep dive: Cloud Networking in Production

Summary

Terraform (or OpenTofu) for multi-cloud with provider-specific modules behind consistent interfaces; native tools (CloudFormation/CDK, Bicep, Google Infrastructure Manager) when staying on one cloud. Keep state remote and locked, pin versions, plan in CI, apply the reviewed plan, and split state by component.

Longer Answer

Don't try to abstract all clouds into one module; share conventions (naming, tagging, structure) instead.

Key Points

• Terraform for multi-cloud.
• Native tools for single-cloud.
• Remote locked state, CI plans.
• Share conventions, not abstractions.

Deep dive: Terraform in Production

Summary

Use STAR: the situation and baseline numbers (monthly cost, incidents, RTO), the specific actions you took (tagging, rightsizing, commitments, multi-AZ fixes, restore tests), trade-offs and who you involved, and the measured result (cost per month, availability, recovery time), plus how it was sustained.

Longer Answer

Interviewers look for ownership and evidence: numbers you can explain, what didn't work, and lasting process changes.

Key Points

• STAR structure.
• Baseline and result numbers.
• Trade-offs and stakeholders.
• Sustained change.

Deep dive: Behavioral & STAR interview questions

Summary

Store them in a secret manager (AWS Secrets Manager or SSM Parameter Store, Azure Key Vault, Google Secret Manager), grant access to workload identities only, rotate automatically where supported, avoid putting them in images, code, environment files in Git or logs, and prefer secretless authentication (IAM database auth, managed identities) where possible.

Longer Answer

In Kubernetes sync secrets from the manager (External Secrets Operator, CSI driver) and restrict access with RBAC.

Key Points

• Secret manager, not code.
• Workload identity access.
• Automatic rotation.
• Prefer secretless auth.

Summary

AWS has six: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability; Azure and Google Cloud frameworks cover the same themes. Use them to review workloads before launch and periodically, record risks and decide which to accept or fix.

Longer Answer

The value is in the conversation and the tracked improvement plan, not in a score.

Key Points

• Six AWS pillars.
• Similar frameworks on Azure and GCP.
• Review before launch and periodically.
• Track risks.

Deep dive: Cloud Computing Tutorial: Well-Architected Design

Summary

Start from requirements: existing skills and contracts, Microsoft or Google ecosystem integration, required managed services (data, AI, regions, compliance), pricing and credits, and support. Most companies standardise on one primary cloud for depth and use others for specific needs; avoid multi-cloud for its own sake.

Longer Answer

Keep portability where cheap (containers, Terraform, open-source databases) rather than building lowest-common-denominator abstractions.

Key Points

• Requirements and skills first.
• One primary cloud.
• Multi-cloud for specific reasons.
• Cheap portability, not abstraction.

Deep dive: Cloud Computing Tutorial: Cloud Computing History & Milestones

Summary

Spare capacity at a large discount that the provider can reclaim with short notice (two minutes on AWS, about 30 seconds on Azure and Google Cloud). Use them for interruptible, retryable work (batch, CI, stateless workers), diversify instance types and zones, handle interruption notices with checkpointing, and mix with on-demand for a guaranteed baseline.

Longer Answer

Kubernetes node groups and Karpenter can blend spot and on-demand capacity with interruption handling.

Key Points

• Big discount, can be reclaimed.
• Interruptible workloads only.
• Diversify and checkpoint.
• Mix with on-demand baseline.

Deep dive: Cloud Computing Tutorial: Cloud Pricing Models