Cloud Platform Experience Questions

Personal account of hands on experience using public cloud providers and the concrete results delivered. Candidates should describe specific services and patterns they used for compute, storage, networking, managed databases, serverless and eventing, and explain their role in architecture decisions, deployments, automation and infrastructure as code practices, continuous integration and continuous delivery pipelines, container orchestration, scaling and performance tuning, monitoring and incident response, and cost management. Interviewees should quantify outcomes when possible with metrics such as latency reduction, cost savings, availability improvements or deployment frequency and note any formal training or certifications. This topic evaluates depth of practical experience, ownership, and the ability to operate and improve cloud systems in production.

HardTechnical

36 practiced

Design an AWS Step Functions state machine (provide JSON or YAML) for an order-processing workflow that performs payment authorization, inventory reservation, an asynchronous external fulfillment call, retries with exponential backoff for transient errors, and a human approval step for orders above a configurable dollar threshold. Include error handling, compensation steps for partial failures, and how you would persist long-running state.

Sample Answer

**Approach (brief)** Design a Step Functions Express/Standard state machine using callback pattern for async fulfillment and human approval, DynamoDB for persisted long-running state, and compensation branches on failure. Retries use exponential backoff; transient errors go to retries, non-retryable errors trigger compensation.

**High-level pieces**- PaymentAuthorization (Lambda)- ReserveInventory (Lambda)- HumanApproval (Task Token + external UI pushes token)- ExternalFulfillment (Task Token with callback)- CompensateRefund / ReleaseInventory (Lambda)- DynamoDB for order state, TTL and queryable progress

**State Machine (JSON)**

json

{
  "Comment":"Order processing with retries, callback, approval, compensation",
  "StartAt":"AuthorizePayment",
  "States":{
    "AuthorizePayment":{
      "Type":"Task",
      "Resource":"arn:aws:states:::lambda:invoke",
      "Parameters":{"FunctionName":"AuthorizePayment","Payload.$":"$"},
      "Retry":[{"ErrorEquals":["TransientError"],"IntervalSeconds":2,"BackoffRate":2,"MaxAttempts":5}],
      "Catch":[{"ErrorEquals":["AuthorizationFailed"],"Next":"DoneFailure"},{"ErrorEquals":["States.ALL"],"Next":"CompensateRefund"}],
      "Next":"ReserveInventory"
    },
    "ReserveInventory":{
      "Type":"Task","Resource":"arn:aws:states:::lambda:invoke",
      "Parameters":{"FunctionName":"ReserveInventory","Payload.$":"$"},
      "Retry":[{"ErrorEquals":["TransientError"],"IntervalSeconds":2,"BackoffRate":2,"MaxAttempts":5}],
      "Catch":[{"ErrorEquals":["InventoryUnavailable"],"Next":"CompensateRefund"},{"ErrorEquals":["States.ALL"],"Next":"CompensateRefund"}],
      "Next":"CheckApprovalNeeded"
    },
    "CheckApprovalNeeded":{
      "Type":"Choice",
      "Choices":[{"Variable":"$.order.amount","NumericGreaterThan":"$.config.approvalThreshold","Next":"HumanApproval"}],
      "Default":"ExternalFulfillment"
    },
    "HumanApproval":{
      "Type":"Task",
      "Resource":"arn:aws:states:::lambda:invoke.waitForTaskToken",
      "Parameters":{"FunctionName":"StartApprovalWorkflow","Payload":{"token.$":"$$.Task.Token","order.$":"$"}},
      "TimeoutSeconds":259200,
      "Catch":[{"ErrorEquals":["States.ALL"],"Next":"CompensateRefund"}],
      "Next":"ExternalFulfillment"
    },
    "ExternalFulfillment":{
      "Type":"Task",
      "Resource":"arn:aws:states:::lambda:invoke.waitForTaskToken",
      "Parameters":{"FunctionName":"InvokeFulfillmentProvider","Payload":{"token.$":"$$.Task.Token","order.$":"$"}},
      "Retry":[{"ErrorEquals":["TransientError"],"IntervalSeconds":5,"BackoffRate":2,"MaxAttempts":6}],
      "Catch":[{"ErrorEquals":["FulfillmentFailed"],"Next":"CompensateRefund"},{"ErrorEquals":["States.ALL"],"Next":"CompensateRefund"}],
      "Next":"DoneSuccess"
    },
    "CompensateRefund":{
      "Type":"Parallel",
      "Branches":[
        {"StartAt":"RefundPayment","States":{"RefundPayment":{"Type":"Task","Resource":"arn:aws:states:::lambda:invoke","Parameters":{"FunctionName":"RefundPayment","Payload.$":"$"},"End":true}}},
        {"StartAt":"ReleaseInventory","States":{"ReleaseInventory":{"Type":"Task","Resource":"arn:aws:states:::lambda:invoke","Parameters":{"FunctionName":"ReleaseInventory","Payload.$":"$"},"End":true}}}
      ],
      "Catch":[{"ErrorEquals":["States.ALL"],"Next":"DoneFailure"}],
      "Next":"DoneFailure"
    },
    "DoneSuccess":{"Type":"Succeed"},
    "DoneFailure":{"Type":"Fail"}
  }
}

**Persistence & callbacks**- Persist order state and task tokens in DynamoDB (orderId PK). Lambdas update status for UI and retries. Use Step Functions task tokens for human/external callbacks. Use Standard SFN for long-running.

**Why this works**- Retries use exponential backoff for transient faults. Task token enables async humans/external systems. Compensation runs in Parallel to ensure refund and release. DynamoDB persists durable order state and supports recovery/visibility.

EasyTechnical

41 practiced

Explain the cloud service models IaaS, PaaS, and SaaS. For each model give one concrete example from AWS, Azure, and GCP, and describe a situation where you would choose that model over the others. Include operational trade-offs such as control, maintenance burden, scaling characteristics and cost implications.

MediumBehavioral

43 practiced

Describe a time you influenced cloud architecture decisions across multiple teams. Explain how you presented trade-offs (including cost/performance/security), built consensus, handled pushback, and measured outcomes. Mention any artifacts you produced (diagrams, cost models, prototypes) and how you tracked adoption.

HardTechnical

35 practiced

Critically evaluate the trade-offs of adopting a multi-cloud strategy versus standardizing on a single cloud provider. Discuss operational complexity, deployment pipelines, data gravity, networking and egress costs, SLA and regional coverage differences, vendor lock-in mitigation, and when multi-cloud provides real business value versus unnecessary cost.

Sample Answer

**Situation overview — what’s at stake**Adopting multi-cloud (using 2+ public providers) vs standardizing on one cloud is a trade-off between resilience/flexibility and operational cost/complexity. As a cloud engineer, weigh business goals (SLA, data sovereignty, vendor risk) against team capacity.

**Operational complexity**- Multi-cloud: increases tooling, IAM models, observability stacks, runbooks, and staff skill requirements. Example: maintaining Terraform modules, CI jobs, and IaC testing for AWS + GCP doubles maintenance surface.- Single-cloud: simpler onboarding, unified monitoring (CloudWatch/Azure Monitor), fewer edge cases.

**Deployment pipelines**- Multi-cloud: pipelines must build provider-specific artifacts, handle different service APIs, and test cross-cloud integration — higher CI/CD maintenance and test matrix.- Single-cloud: pipeline consistency enables faster delivery and less flakiness.

**Data gravity & networking / egress costs**- Data-intensive apps favor single-cloud where data stays local; cross-cloud egress and latency explode costs. Example: replicating petabytes between regions/providers incurs heavy egress and complexity.- Multi-cloud is viable for loosely-coupled services or when only metadata moves.

**SLA & regional coverage**- Multi-cloud can improve global resilience if providers have complementary regional presence or avoid provider-wide incidents.- But operationalizing failover across providers (DNS, data replication, config drift) is non-trivial.

**Vendor lock-in mitigation**- Multi-cloud reduces dependency on single-provider-managed services, but true portability requires using portable tech (Kubernetes, PostgreSQL, Terraform) — which often sacrifices provider-specific efficiencies and cost savings.

**When multi-cloud adds real business value**- Regulatory requirements, geopolitical risk, or needing provider-specific strengths (e.g., AI services on GCP, enterprise AD on Azure) justify it.- High-availability for critical global services where outage risk must be diversified.

**When it’s unnecessary cost**- Early-stage products, data-heavy platforms, or teams with limited cloud expertise should standardize to optimize cost, speed, and operational maturity.

**Recommendation**- Default to single-cloud for most workloads; adopt multi-cloud selectively for clear business cases. Invest in abstraction (IaC, CI, observability) and automation only where ROI justifies complexity.

MediumTechnical

44 practiced

Explain a secure VPC/networking design in AWS for multiple environments (dev/staging/prod). Cover subnet layout (public/private), route tables, NAT gateways, bastion hosts, security groups vs NACLs, shared services VPC, VPC peering vs Transit Gateway, and strategies for CIDR planning and IP address management across many accounts.

Sample Answer

**High-level approach**I design each AWS account for a single environment (dev/staging/prod) or use OU-based accounts, with a centrally-managed Shared Services VPC. Focus: least-privilege, availability per AZ, and clear CIDR/IPAM.

**Subnet layout & route tables**- Per AZ: public subnet (/24), private app subnet (/24), private DB subnet (/24). Public subnets have IGW and a route table pointing 0.0.0.0/0 → IGW. Private subnets use route table 0.0.0.0/0 → NAT Gateway in same AZ.- DB subnet has no internet route; use VPC endpoints or NAT for outbound if required.

**NAT Gateways & high availability**- One NAT Gateway per AZ to avoid cross-AZ data transfer and single point of failure. Use autoscaling + route table per AZ.

**Bastion hosts**- Prefer SSM Session Manager + Systems Manager endpoints in private subnets; avoid public SSH. If bastion required, place in public subnet with strict security group allowing only corporate IPs and MFA, and use logging.

**Security Groups vs NACLs**- Security Groups: primary control, stateful, per-resource, least-privilege (allow-list).- NACLs: stateless, subnet-level, used for coarse controls (e.g., deny known-bad ranges), extra layer for prod.- Enable VPC Flow Logs and GuardDuty.

**Shared Services VPC**- Host DNS, Active Directory, logging (centralized ELK/CloudWatch), S3 endpoints, and proxy/inspection appliances. Share via Transit Gateway or Resource Access Manager.

**VPC Peering vs Transit Gateway**- VPC Peering: simple, low-latency, good for a few VPCs; no transitive routing.- Transit Gateway: recommended at scale (many accounts/environments) — supports transitive routing, central route management, integration with TGW Connect for on-prem, and routing policies. Use route tables per attachment to segment access between dev/staging/prod.

**CIDR planning & IPAM**- Use /16 per environment or per AWS account and subdivide into /24s per AZ/subnet. Example: 10.0.0.0/16 for prod, 10.1.0.0/16 for staging, 10.2.0.0/16 for dev.- Use AWS IP Address Manager (IPAM) for centralized allocation, tracking, and overlap prevention across accounts and regions.- Reserve pools for future growth, endpoints, and VPN/CIDR for on-prem.

**Operational controls**- Enforce VPC endpoint for S3/Secrets Manager, use endpoint policies.- Centralize logging, IAM least privilege, automated drift detection, and IaC (Terraform/CloudFormation).- Test failover (NAT, AZ), and regularly review CIDR utilization.

This design balances security, availability, and manageability for multi-environment AWS deployments.

Unlock Full Question Bank

Get access to hundreds of Cloud Platform Experience interview questions and detailed answers.

Join thousands of developers preparing for their dream job.