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.

EasyTechnical

44 practiced

Explain what SLOs (Service Level Objectives) and SLIs (Service Level Indicators) are and describe how you would derive appropriate SLOs and SLIs for a public API that promises both high availability and low latency. Include how you would determine acceptable error budgets and escalation paths when SLOs are at risk.

Sample Answer

SLOs are measurable targets for service quality (the goals you commit to); SLIs are the measurable signals that tell you how the service is performing (metrics). For a public API that must provide high availability and low latency:

- Choose SLIs that reflect user experience: - Availability SLI: successful request ratio (HTTP 2xx / total requests) measured per minute. - Latency SLI: p95 or p99 end-to-end request latency (client-observed) for successful requests. - Error-rate SLI: percentage of 5xx or failed requests. - Optionally, saturation SLI: CPU queue length or request queue depth.

- Derive SLOs from business requirements and customer tolerance: - Example: Availability SLO = 99.95% (monthly); Latency SLO = p95 < 200ms. - Convert SLO to error budget: Error budget = 1 - SLO. For 99.95% monthly availability, allowable downtime ≈ 22 minutes/month. For latency, budget is percentage of requests allowed to exceed threshold (e.g., ≤0.5% above 200ms).

- How to determine targets: - Consult stakeholders (sales/clients) for SLA expectations. - Analyze historical telemetry to pick realistic but aspirational targets. - Balance cost vs business value — tighter SLOs increase cost.

- Error budget policies and escalation: - Track burn rate daily and projected monthly burn. - Define thresholds and actions: - Green (burn < 1x): normal operations. - Yellow (burn 1–3x): notify product/ops, freeze non-critical releases, increase monitoring. - Red (burn > 3x or budget exhausted): immediate incident response, roll back risky changes, divert capacity, engage on-call SRE and customer success, and notify customers if SLA at risk. - Document runbooks per SLI, automated alerts for crossing thresholds, and postmortems for budget violations.

- Implementation considerations: - Use client-observed metrics where possible, consistent tagging, windows (rolling 28/30 days), and sampling for p99 accuracy. - Tie SLOs to contractual SLAs only after agreement; SLOs guide operational discipline and prioritization during outages.

This approach ensures SLOs are measurable, tied to business needs, and include clear escalation and remediation when budgets are burning.

HardTechnical

61 practiced

You inherit a cloud environment with runaway storage and compute costs and numerous orphaned resources. As a solutions architect, present an actionable three-month plan to reduce costs by 50% without risking production availability. Include discovery tactics, immediate cost-killers, automation for ongoing savings, policy and governance changes, and stakeholder communication strategy.

Sample Answer

Goal: Reduce cloud costs by 50% in 90 days while keeping production availability intact. Plan split into Rapid Discovery (weeks 0–2), Immediate Actions (weeks 1–4), Automation & Recovery (weeks 3–8), and Governance + Stakeholder Rollout (weeks 6–12).

Week 0–2 — Discovery- Inventory: Use cloud-native tools (Cost Explorer, Azure Cost Management, GCP Billing), Cloud Custodian and a few resource queries to list untagged/orphaned resources, idle VMs, unattached disks, oversized instances, old snapshots, and high-frequency storage classes.- Map spend to business owners via tags and billing account; where tags missing, reconcile with billing data and team leads.- Baseline KPIs: weekly spend, p95 compute usage, storage growth rate, % orphaned.

Weeks 1–4 — Immediate cost-killers (low-risk)- Delete verified orphaned resources after automated snapshot & record (unattached disks, idle NICs, old snapshots). Start with non-prod.- Implement aggressive lifecycle policies: move infrequently accessed data to cold storage, auto-delete snapshots older than policy.- Rightsize: apply automated suggestions with staged resize approvals; convert consistently underutilized instances to smaller families or burstable types.- Enable autoscaling and scale-to-zero for dev/test workloads; schedule shut-down windows for non-prod.- Purchase Reserved Instances/Savings Plans for steady-state production after verifying utilization (>70%) — phased buy to avoid locking mistakes.

Weeks 3–8 — Automation for ongoing savings- Deploy tagging enforcement and automated remediation (Cloud Custodian/IaC): non-compliant resources flagged, quarantined, or stopped.- Implement automated rightsizing job weekly and cost anomaly detection with alerts.- CI/CD integration: prevent unchecked resource creation via IaC modules that enforce instance types, approved AMIs, size limits, and tagging.- Introduce spot/Preemptible use for batch jobs with checkpointing.

Weeks 6–12 — Policy, governance & communication- Policies: Budget alerts, soft/hard guardrails (deny policies for public IPs in dev, hard limits on volumes), approval workflow for exceptions.- Chargeback/showback: deliver weekly dashboards to engineering, product and finance, with cost per team and forecast.- Stakeholder plan: Kickoff with execs (risk/reward), weekly sprint updates for 8 weeks, runbook for change rollback, training sessions for dev teams.- Success metrics: Hit 25% reduction by week 4, 40–50% by week 12; maintain SLOs and <1% production incidents tied to cost actions.

Risk mitigation- Always stage in non-prod, automated backups before deletion, canary rightsizing, and approval gates for production changes. Use monitoring and automated rollback on detected regressions.

This plan balances aggressive savings with controls, automation, and transparent stakeholder engagement to sustainably cut costs by ~50% without risking production availability.

EasyTechnical

44 practiced

List the common cloud compute options (virtual machines, managed containers, serverless functions) and for each category name an example service on AWS, Azure and GCP. For each option explain the typical operational trade-offs, performance characteristics and a brief scenario where you would prefer that compute model.

MediumTechnical

39 practiced

Describe how to set up a secure CI/CD pipeline that enforces secure secrets handling, performs container image scanning, generates SBOMs for images, and automatically rolls back deployments when security gates fail. Include integration points with secret stores, artifact registries, and policy-as-code enforcement.

Sample Answer

Requirements & constraints:- Enforce secrets never in repo, generate SBOMs, scan images, gate releases on policies, and automated rollback on failures. Integrate with secret store, artifact registry, and policy-as-code.

High-level architecture:- CI (GitHub Actions/GitLab CI/Jenkins) for build + SBOM + image push- Artifact registry (ECR/GCR/Artifactory) for images and signed SBOMs- Image scanner (Trivy/Clair/Anchore) + SCA tools- SBOM generator (Syft) producing SPDX/CycloneDX stored alongside image- CD (ArgoCD/Flux/Spinnaker) for deployments with pre-sync hooks and policy checks- Secret store (HashiCorp Vault / AWS Secrets Manager / Azure Key Vault) integrated via ephemeral creds- Policy-as-code (OPA/Rego, Conftest, Kyverno) enforced as admission/controller and CI gate- Observability + audit logs + alerting (CloudWatch/Prometheus/ELK/Slack)

Pipeline flow (concrete steps):1. Developer pushes PR. CI runs lint/tests.2. Secrets: CI retrieves secrets via short-lived tokens from Vault (not env var files). Use OIDC or GitHub Actions OIDC to obtain role-bound creds.3. Build container image; sign image with in-pipeline cosign + store signature in registry.4. Generate SBOM with Syft; attach SBOM to registry or object store.5. Scan image & SBOM with Trivy/Anchore for vulnerabilities, malware, and vulnerable licenses.6. Policy-as-code: run OPA/Conftest checks on SBOM and scan results (e.g., no critical CVEs, allowed licenses, provenance). If policy fails, mark build failed.7. If pass, push image + SBOM + signature to artifact registry and promote tag (immutable digest).8. CD: ArgoCD detects new image tag/digest. Pre-sync: run admission-style policy checks (Kyverno/OPA Gatekeeper) against image SBOM and registry metadata.9. If CD policy fails, block sync and trigger automated rollback: ArgoCD will either not apply change or automatically restore last known good manifest. Also create incident (PagerDuty/Slack) and annotate event with scan+SBOM evidence.10. Post-deploy continuous scanning: periodic image rescans and SBOM delta checks; if new critical CVE emerges, trigger automated rollback via CD or create emergency patch pipeline.

Integration & security controls:- Secrets: OIDC + short-lived tokens (no long-lived secrets in CI). Use sealed secrets for k8s, and CSI driver for runtime secrets pulling from Vault.- Artifact registry: enforce immutability, image signing with cosign, and repo-level IAM policies.- Policy-as-code: store Rego/Conftest policies in git, reviewed via PR. Use same policies in CI and admission controllers to avoid drift.- SBOM: store in registry metadata or S3 with signed linkage to image digest; require SPDX/CycloneDX format for tooling compatibility.- Auditability: central logs of who triggered build, token issuance, scan results, and policy decisions.

Rollback mechanics & reliability:- Use declarative CD (ArgoCD) with automated sync + rollback enabled. On gate failure, trigger automated revert to previous commit/image digest.- Keep health checks and progressive rollouts (canary or blue/green); require policy gates pass before promoting to production.

Operational considerations:- Performance: parallelize scans; cache base image scan results.- False positives: define CVE thresholds and exception workflow with expiring exceptions tracked in policy repo.- Testing: run policy tests in local/pre-merge pipelines; run SBOM/scan validators in dev environment.- Compliance: retain SBOMs and signed artifacts for audits and supply-chain traceability.

This design enforces secrets safety, verified SBOMs, continuous scanning, policy-as-code across CI/CD, and automatic rollback when security gates fail—while preserving traceability and minimizing operational overhead.

EasyTechnical

37 practiced

Given a simple web application with static assets and an API backend, outline a minimal high-availability cloud architecture that supports continuous delivery. Specify storage choices for static assets, compute choices for the API, basic networking and security boundaries, CDN usage, and a simple CI/CD flow an architect would propose to the customer.

Sample Answer

Situation: Customer needs a minimal highly-available architecture for a static-front + API web app with continuous delivery.

High-level design:- Static assets: store in highly-available object storage (e.g., S3, Azure Blob, GCS) configured for versioning and lifecycle rules. Serve via a CDN (CloudFront/Azure CDN/Cloud CDN) with origin pointing to the bucket; enable compression, TTLs, and invalidation API.- API compute: use a managed, multi-AZ service for HA — either serverless functions behind API Gateway (AWS Lambda + API Gateway) for minimal ops, or container tasks with autoscaling (ECS/Fargate or EKS with HPA) fronted by an Application Load Balancer (ALB) across multiple AZs.- Storage for API data: managed DB (RDS/Aurora with Multi-AZ or Cloud SQL) or DynamoDB for serverless workloads; enable automated backups and read replicas if needed.

Networking & security:- VPC with public subnets for ALB and NATed private subnets for compute and DB; multi-AZ placement.- Security groups: least privilege — ALB allows 443 from internet, compute allows ALB, DB allows compute only.- TLS termination at CDN or ALB with ACM-managed certs.- WAF at CDN/ALB for basic protection, rate-limiting, and bot rules.- IAM roles for services, encrypted secrets in AWS Secrets Manager/Parameter Store or equivalent.- Logging/monitoring: centralized logs (CloudWatch/Stackdriver), health checks, alerts, and metrics.

CDN usage:- CDN caches static assets and can cache API GETs when safe. Configure cache-control headers, origin failover to bucket, and use signed URLs if assets are private.

CI/CD flow (minimal, production-safe):- Source: Git repo (GitHub/GitLab).- Pipeline: GitHub Actions/CodePipeline/GitLab CI: - PR build & unit tests, static analysis. - On merge to main: build static site artifact -> upload to object storage and invalidate CDN paths (or use atomic bucket versioning + origin pointer swap). - Build container image for API -> push to registry (ECR/GCR). - Deploy via blue/green or rolling deploy to Fargate/ECS or update Lambda with traffic shifting (use feature flags or canary deployments). Run integration tests and health checks post-deploy.- Infrastructure-as-code (Terraform/CloudFormation) for repeatable environments.- Secrets, config via environment variables/secrets store; restrict pipeline credentials with least privilege.

Trade-offs & rationale:- Serverless minimizes operational overhead; containers give more control for long-running workloads.- CDN + object storage gives cost-effective global HA for static assets.- Multi-AZ managed services provide straightforward HA without complex ops.

This architecture is minimal, HA by design, secure with clear boundaries, and supports automated, safe continuous delivery.

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.