Cloud Platform Fundamentals Questions

Comprehensive understanding of core public cloud services and the primary trade offs when selecting among them across major providers such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform. Candidates should know compute options including virtual machines, managed compute, containers and serverless functions; storage types including object, block and file storage and lifecycle and archival strategies; managed database offerings for relational, non relational, and data warehouse workloads; networking fundamentals including virtual private networks, subnets, routing, load balancing, content delivery networks, and private connectivity; messaging and integration services such as message queues and event streaming; identity and access management and secrets management; monitoring, logging, and observability; autoscaling, elasticity, high availability, and basic disaster recovery patterns; and cost and pricing considerations. The topic also covers the trade offs between managed services and self managed infrastructure in terms of consistency, latency, cost, operational overhead, and durability, and the ability to map common workload requirements to the right service categories.

MediumTechnical

50 practiced

Given a three-tier application (web, app, db) in a VPC, propose specific security group and network ACL rules that implement the principle of least privilege. Include ports, directions, and whether to use stateful SGs or stateless NACLs for each tier and explain your choices.

Sample Answer

**Approach (brief)** I’ll use stateful Security Groups (SGs) for host-level allowlists and stateless Network ACLs (NACLs) for coarse subnet-level filtering and extra defense-in-depth. SGs permit return traffic automatically; NACLs must include ephemeral port ranges for responses.

**Security Groups (stateful)**- Web SG (frontend) - Inbound: TCP 80,443 from 0.0.0.0/0 (or CDN IP list) — allow - Inbound: TCP 22 from admin CIDR (e.g., 10.0.0.0/24) — allow - Outbound: TCP 1024-65535 to App SG — allow (ephemeral for responses)- App SG (application) - Inbound: TCP 8080 (or 443) from Web SG — allow (reference SG) - Inbound: TCP 22 from admin CIDR — allow - Outbound: TCP 3306 to DB SG — allow- DB SG (data) - Inbound: TCP 3306 (MySQL) from App SG only — allow - Inbound: TCP 22 from admin CIDR — allow (or disable in prod) - Outbound: restrict to required services (e.g., backups) or deny all

Notes: Use SG references (not CIDRs) for east-west traffic to enforce least privilege. Deny all other inbound by default.

**Network ACLs (stateless, per subnet)**- Web subnet NACL - Rule 100 Allow TCP 80,443 from 0.0.0.0/0 - Rule 110 Allow TCP 1024-65535 to App subnet (for ephemeral client ports) — outbound/inbound as needed - Rule 120 Deny all (lower priority)- App subnet NACL - Rule 100 Allow TCP 8080 from Web subnet CIDR - Rule 110 Allow TCP 1024-65535 to Web subnet CIDR (return) - Rule 120 Allow TCP 3306 to DB subnet CIDR (outbound) - Rule 130 Deny all- DB subnet NACL - Rule 100 Allow TCP 3306 from App subnet CIDR - Rule 110 Allow TCP 1024-65535 to App subnet CIDR (return) - Rule 120 Deny all

Notes: Because NACLs are stateless, include both directions for ephemeral ranges (1024-65535) and explicit allow rules for both inbound/outbound pairs. Keep rule numbering consistent and explicit deny at the end.

**Why these choices**- SGs stateful + SG references give fine-grained, least-privilege controls between tiers and simplify rule maintenance.- NACLs add subnet-level protection and an extra block against misconfigured instances; being stateless forces explicit bi-directional rules (safer, explicit).- Restrict management (SSH) to admin CIDR or use bastion/SSO; avoid opening DB or internal ports to Internet.

**Operational recommendations**- Manage via IaC (Terraform/CloudFormation) to enforce reproducibility.- Rotate admin CIDRs, use bastion + session manager, enable logging (VPC Flow Logs), and monitor with alerts for unexpected allow patterns.

HardTechnical

46 practiced

Compare managed streaming services (e.g., Kinesis, Pub/Sub) and self-managed Kafka clusters. Discuss trade-offs across latency, throughput, operational overhead, multi-tenancy, exactly-once delivery, retention policies, and integration ecosystems. Give two scenarios where you would prefer each approach.

Sample Answer

**Overview — quick verdict**Managed streaming (Kinesis, Pub/Sub) reduces ops work and accelerates time-to-market; self-managed Kafka gives maximal control, tuning and ecosystem flexibility. Choice depends on scale, compliance, cost model and team expertise.

**Trade-offs**- Latency - Managed: typically low-ms but some extra routing; Pub/Sub/Kinesis offer regional endpoints and SLA-backed latencies. - Kafka: potentially lower tail latency with tuned brokers, networking, and storage.- Throughput - Managed: scales easily (shards/throughput units) but costs rise; autoscaling limits per-account quotas. - Kafka: high throughput at lower cost when optimized (compression, batching, SSDs).- Operational overhead - Managed: minimal — no broker/OS/patching, automatic scaling/repairs. - Kafka: significant — cluster ops, Zookeeper/KRaft, upgrades, capacity planning.- Multi-tenancy - Managed: better isolation and quotas per project; provider handles noisy neighbor mitigation. - Kafka: requires careful namespace, ACLs, quota setup; risk of noisy tenants affecting brokers.- Exactly-once delivery - Managed: Pub/Sub/Kinesis provide at-least-once; some managed offerings add dedup or transactions but limited. - Kafka: supports exactly-once semantics (EOS) end-to-end with idempotent producers and transactions, but requires careful client and broker config.- Retention policies - Managed: simple TTL or archive-to-storage options; retention limits and cost. - Kafka: flexible retention by topic, tiered storage (with external tools), infinite retention possible.- Integration ecosystem - Managed: strong first-party integrations with cloud services (Lambda, Dataflow, Kinesis Firehose). - Kafka: rich open-source ecosystem (Connect, Streams, MirrorMaker) and vendor integrations but more wiring.

**Scenarios**- Prefer managed (Kinesis/Pub/Sub) 1) Small/lean DevOps team launching event-driven features quickly with tight SLA and minimal ops (use Kinesis + Lambda). 2) Multi-cloud teams needing built-in autoscaling, per-project quotas, and tight cloud integrations (Pub/Sub into BigQuery).- Prefer self-managed Kafka 1) Large-scale platform with predictable heavy throughput and need for EOS, custom retention tiers, and cost optimization. 2) Regulatory/compliance requirement for on-prem data residency, custom security controls, and bespoke connector ecosystem.

**Recommendation for DevOps**Choose managed to reduce toil and accelerate delivery; choose self-managed when control, cost at scale, or compliance demands justify sustained operational investment.

EasyTechnical

44 practiced

Describe pros and cons of using a managed relational database service (e.g., RDS/Azure Database/Cloud SQL) versus running your own database on VMs/containers. Consider patching, backups, performance tuning, extensions, licensing, and operational overhead.

Sample Answer

**Overview (DevOps perspective)**

Using a managed relational DB service (RDS/Cloud SQL/Azure DB) trades operational overhead for some loss of low-level control. Below I compare by topic.

**Patching & Maintenance**- Managed: Automatic OS/DB patching options, configurable maintenance windows — much lower operational burden and faster security fixes.- Self-managed: You control timing and can test patches in staging, but you must run patch pipelines, maintenance automation and rollback plans.

**Backups**- Managed: Built-in automated backups, point-in-time recovery, snapshot lifecycle management — easy to meet RTO/RPO.- Self-managed: Flexible (e.g., filesystem snapshots, WAL shipping), but requires scripting, monitoring, and tested restore procedures.

**Performance Tuning**- Managed: Good telemetry, presets, autoscaling (read replicas), but some knobs and kernel params are locked.- Self-managed: Full tuning freedom (kernel, I/O scheduler, custom storage drivers) — more work to maintain and observe.

**Extensions & Customization**- Managed: Limited extensions/plugins and restricted superuser access; some clouds offer “custom” flavors.- Self-managed: Install any extension, custom build, forked engine support.

**Licensing**- Managed: Often includes commercial DB licensing or offers license-included pricing — simpler but possibly more expensive.- Self-managed: Bring-your-own-license or open-source — potentially cheaper but adds compliance tracking.

**Operational Overhead**- Managed: Reduced on-call and admin effort; faster provisioning; easier HA.- Self-managed: Higher automation investment (IaC, backups, failover scripts), but necessary if you need specialized configs.

**When to choose which**- Choose managed for standard OLTP workloads, faster time-to-market, and to minimize ops.- Choose self-managed when you need nonstandard extensions, low-level tuning, specific licensing control, or regulatory requirements.

I would evaluate required extensions, compliance, cost model, and team capacity before deciding.

MediumTechnical

53 practiced

Design an autoscaling policy for a Kubernetes microservice that should scale horizontally based on CPU and a custom latency SLO. Describe how you'd implement it using the Kubernetes HorizontalPodAutoscaler (HPA), custom metrics (Prometheus adapter or KEDA), cooldowns, and how you'd prevent flapping and over-provisioning.

Sample Answer

**Clarify requirements & SLO**- Scale horizontally to meet 70% CPU target and a latency SLO (p95 < 200ms).- Min/Max pods, tolerate short bursts, avoid flapping and over-provisioning.

**High-level approach**- Use Kubernetes HPA v2 (metrics v2) with two metrics: resource (cpu) and a custom metric (p95_latency_ms) exposed via Prometheus Adapter or KEDA.- Add smoothing via HPA behavior (stabilization windows, policies), moving-average metric in Prometheus, and conservative min/max replicas.- Use VPA for requests/limits recommendations to reduce wasted capacity.

**Implementation (example HPA using Prometheus custom metric)**

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mysvc-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mysvc
  minReplicas: 3
  maxReplicas: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: External
    external:
      metric:
        name: p95_latency_ms
        selector:
          matchLabels:
            service: mysvc
      target:
        type: AverageValue
        averageValue: "200"
  behavior:
    scaleUp:
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60
      stabilizationWindowSeconds: 30
    scaleDown:
      policies:
      - type: Percent
        value: 20
        periodSeconds: 300
      stabilizationWindowSeconds: 300

**Prometheus adapter / KEDA**- Prometheus Adapter: configure a query that computes a rolling p95 (e.g., histogram_quantile(0.95, rate(...[5m]))) and expose as custom metric name p95_latency_ms.- KEDA alternative: create ScaledObject using external Prometheus trigger; KEDA can also use cooldowns and more flexible scaling triggers.

**Prevent flapping & over-provisioning**- Use moving-average p95 over 3–5m in PromQL to smooth transient spikes.- Conservative scaling policies (limits on percent-per-period) and long scaleDown stabilization to avoid rapid down/up cycles.- Set minReplicas > 1 to maintain capacity; maxReplicas to bound cost.- Ensure Pod readinessProbe + startupProbe so HPA counts only ready pods.- Use VPA (recommendation mode) to right-size requests so CPU-based scaling is meaningful.- Optionally add a buffer: target p95 slightly below SLO (e.g., 180ms) to reduce risk.

**Observability & testing**- Dashboards (Grafana) for CPU, p95, replica count, queue-length.- Run chaos tests and synthetic load tests to validate scale-up time and SLO compliance.- Iterate thresholds and stabilization windows based on observed time-to-scale and request patterns.

HardSystem Design

56 practiced

Design a secure CI/CD pipeline for infrastructure (Terraform) and applications in a regulated environment. Requirements: immutable artifacts, artifact signing, least-privilege service accounts, multi-stage approval gates for production, and automated rollbacks. Describe secrets handling, artifact storage, and how to verify the integrity of deployed artifacts.

Sample Answer

**Clarify requirements**- Immutable, signed artifacts for both infra (Terraform modules/state) and apps (container images/binaries)- Least-privilege service accounts + short-lived creds- Multi-stage approvals before production- Automated rollback on failure- Auditable, verifiable integrity

**High-level architecture**- CI builds produce immutable artifacts (OCI images, zip blobs). Push to an artifact registry (ECR/GCR/Artifact Registry/S3 with object lock + versioning).- Sign artifacts with supply-chain signing (cosign/sigstore) and publish attestations to transparency log (Rekor).- Terraform modules stored in an immutable module registry (private module registry or S3 with object lock). Terraform state in encrypted, versioned backend (S3 + DynamoDB locking) and signed state snapshots archived.

**Pipeline flow**1. CI: run tests, produce artifact, compute content-addressable digest, sign artifact: - Use ephemeral CI identities via OIDC to assume minimal IAM role. - Store signatures and attestations in registry + Rekor.2. CD (Spinnaker/GitOps): retrieve artifact by digest (not tag), verify signature/attestation before deploy.3. Pre-prod / staging: automatic promotion through canary tests and observability checks.4. Prod gate: multi-person approval (Spinnaker manual judgement or GitHub protected branch + signed release PR). Only after approval does pipeline assume prod-only role to deploy.

**Least-privilege & credentials**- Short-lived credentials: OIDC + STS / workload identity; no long-lived secrets in CI.- Service accounts scoped to actions (deploy infra vs app).- Use IAM permissions modelled per resource with deny-by-default and RBAC in orchestration tools.

**Secrets handling**- Central secrets manager (HashiCorp Vault or cloud KMS+Secrets Manager) with dynamic secrets for DB and cloud APIs.- CI/CD retrieves secrets at runtime via authenticated OIDC identity; no secrets checked into repo.- Audit logging and TTLs for dynamic credentials. Use Transit engine for signing secrets/keys.

**Artifact storage**- OCI registry for images (immutable tags by digest), enable immutability policy and scanning.- Registry + Rekor store signatures/attestations.- Terraform modules/state in encrypted, versioned backend with object lock and restricted ACLs.

**Integrity verification**- CD verifies: - Signature validity with cosign: verifies public key or root-of-trust. - Attestation presence and transparency log entry (Rekor). - Digest matches expected value (deploy by digest).- For Terraform: verify module checksum and signed module metadata before applying. Keep signed plan artifacts: CI generates and signs terraform plan; deployment applies only signed plan.

**Automated rollback**- Canary + health checks; if metrics/alerts breach SLO, automated rollback to previous signed digest via orchestration (Spinnaker rollbacks or Kubernetes controller that reverts to previous ReplicaSet).- For infra, use signed and reviewed terraform apply plans; have automated destroy/rollback by applying previous signed state or running restorative plan.

**Audit & compliance**- Store all audit logs: CI run, signature verification, approval records, secrets access. Use centralized SIEM.- Retain attestations and signed plans for compliance.

This design enforces immutability, cryptographic verification, least privilege, human approval for production, and automated safe rollback while keeping auditable provenance for regulated environments.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.