Cloud Service Models Questions

Covers the three primary cloud service models and the responsibility boundaries for each: Infrastructure as a Service, Platform as a Service, and Software as a Service. Candidates should be able to define each model, explain which layers the cloud provider manages versus which layers the customer manages, and draw a responsibilities matrix across networking, virtualization, operating system, runtime, middleware, applications, and data. Provide concrete vendor examples for each model such as Amazon Web Services Elastic Compute Cloud, Microsoft Azure Virtual Machines, Google Cloud Platform Compute Engine for Infrastructure as a Service; Amazon Web Services Elastic Beanstalk, Microsoft Azure App Service, Google Cloud Platform App Engine for Platform as a Service; and Microsoft Office 365, Salesforce, and Google Workspace for Software as a Service. Be prepared to discuss trade offs when selecting a model including control and customization, operational overhead, time to market, scalability, cost model, security and compliance implications, and typical use cases where one model is preferred over the others. Interviewers may ask candidate to recommend a model given specific requirements and to justify that recommendation using the responsibilities and trade offs.

HardTechnical

21 practiced

You are asked to quantify vendor lock-in risk when selecting a PaaS offering. Propose a measurable rubric (3-6 metrics) that evaluates lock-in across API compatibility, data exportability, custom runtimes, operational processes, and vendor-specific tooling. Describe how you would score a vendor and how this would influence procurement decisions.

MediumTechnical

35 practiced

You are migrating a three-tier legacy application (web, application, database) from on-prem to cloud. The web tier can be redeployed, the app tier is monolithic with some third-party middleware, and the database is Oracle with strict uptime requirements. Propose a migration plan that decides which tier to move to IaaS vs PaaS vs SaaS first, justify each choice, and outline rollback and cutover steps to minimize downtime.

Sample Answer

**High-level decision**- Web tier → PaaS first (e.g., AWS Elastic Beanstalk / Azure App Service): redeployable, stateless, benefits from autoscaling, managed TLS, CI/CD integration.- App tier (monolithic + third‑party middleware) → IaaS (lift‑and‑shift) initially: preserves middleware compatibility and minimizes risk. Plan refactor to containers/PaaS after stabilization.- Database (Oracle, strict uptime) → Phased hybrid approach: keep primary on-prem with asynchronous/near‑sync replication to cloud IaaS Oracle RAC or cloud‑certified DB service (e.g., Oracle Cloud DB Systems / AWS RDS Custom for Oracle) and use Data Guard. Full DB SaaS only after validation and vendor support confirmed.

**Why**- Web → PaaS reduces ops and enables rapid cutover.- App → IaaS avoids breaking third‑party dependencies; allows parity with on‑prem OS/network config.- DB → risk of unsupported features and strict SLA demands mandates careful replication + tested HA on IaaS before any DBaaS move.

**Cutover plan (minimize downtime)**1. Prep: infra as code, networking (VPC/VNet peering, VPN/Direct Connect), IAM, security groups, monitoring, runbooks.2. Test: deploy web to PaaS in staging; deploy app on IaaS test instances; set up replication from on‑prem Oracle to cloud target; run full integration and load tests.3. Data sync: configure continuous replication (Data Guard/GoldenGate). Validate consistency with checksum and reconcile window.4. Cutover (low downtime window): - Blue/green for web: flip traffic to PaaS using weighted DNS/CDN (TTL low). - App: run parallel IaaS instances behind load balancer; switch traffic once smoke tests pass. - Database final failover: schedule brief maintenance window, perform controlled switchover to cloud replica, validate, promote to primary.5. Post‑cutover: monitor metrics, run acceptance tests, enable autoscaling.

**Rollback triggers & steps**- Predefined metrics (failed smoke tests, replication lag > threshold, error rate spike).- Rollback: revert DNS/ALB weights to on‑prem, reattach app sessions to on‑prem app servers, failback DB via Data Guard switchover to original primary.- Maintain rollback playbooks, automated scripts, and rehearsed runbook drills.

**Risk mitigations**- Keep incremental backups, point‑in‑time recovery, and hot standby.- Validate third‑party licenses/support for cloud.- Low DNS TTL, health checks, and phased traffic shifting reduce user impact.

HardTechnical

21 practiced

Design the architecture and responsibilities for a real-time streaming pipeline. Choose between a SaaS streaming product (Confluent Cloud), a PaaS managed streaming service, or self-hosted Kafka on IaaS. For your chosen option justify decisions on throughput, latency, operational burden, data retention, and security responsibilities (encryption, ACLs, monitoring).

Sample Answer

**Choice & summary**I would choose Confluent Cloud (SaaS) for a real-time streaming pipeline because it minimizes operational burden while providing enterprise features (multi-tenant scaling, connectors, schema registry) that speed time-to-value for a cloud engineering org.

**High-level architecture**- Producers (microservices, IoT, DB CDC) -> Confluent Cloud Kafka topics -> Stream processors (ksqlDB / consumer apps / Flink) -> Sinks (data lake, OLAP, search, alerting).- VPC peering / PrivateLink between cloud VPC and Confluent for private network traffic.- Schema Registry, REST Proxy, Connectors managed by Confluent; client apps in our accounts.

**Throughput & latency**- Provision throughput via Confluent capacity tiers (dedicated throughput units). For >1M msgs/sec choose provisioned/dedicated cluster; for bursty loads use auto-scaling tiers.- Expect 10s–100s ms end-to-end for basic producer->consumer patterns; tune partition count, client batching, linger.ms, and use dedicated clusters for lower jitter.

**Operational burden**- Provider responsibilities: broker lifecycle, patching, replication, Zookeeper/KRaft, scaling, backups, basic monitoring of cluster health.- Our responsibilities: client configuration, schema evolution, connector configuration, consumer lag management, alerting, cost management, IAM mapping.- Benefit: fewer on-call nights and no OS/VM maintenance compared to self-hosted.

**Data retention**- Use topic-level retention policies: short retention for hot streams, long retention or tiered storage (Confluent Cloud’s storage) for audit/replay. For regulatory needs export to S3/GCS via sink connectors and enforce immutability/versioning there.

**Security responsibilities**- Encryption: Provider handles encryption at-rest and in-transit by default. We enforce TLS, restrict listener endpoints to PrivateLink or VPC peering.- ACLs & auth: Use SASL/SCRAM or mTLS + RBAC (Confluent Cloud RBAC). We define least-privilege roles, manage service principals, rotate keys via automation.- Network: Restrict IPs, use VPC endpoints, and private networking.- Monitoring & logging: Provider supplies cluster metrics; we integrate with Datadog/Prometheus via Confluent metrics export and enable audit logs to our logging account (S3/CloudWatch). We monitor consumer lag, throughput, error rates, and security events; alert on threshold breaches.- Compliance: Use Confluent features + our cloud controls (KMS for key management, IAM policies, bucket encryption) to meet PCI/HIPAA/GDPR.

**Trade-offs**- Pros: Lower ops, faster features, built-in security and support.- Cons: Higher cost at scale and less deep control than self-hosted; for ultra-low latency or custom broker tuning, IaaS might be preferred.

**Operational checklist**- Define SLOs (latency, availability), capacity plan, runbook for failover, automated secret rotation, and CI for connector/config changes.

MediumTechnical

21 practiced

As a Cloud Engineer, how would you convince engineering teams to adopt PaaS for developer productivity while addressing concerns about vendor lock-in and operational visibility? Provide talking points, technical mitigations, and governance policies you would propose.

MediumTechnical

22 practiced

Draw (describe in text) a responsibilities matrix for a multi-tenant PaaS offering that provides container runtimes and middleware services to developers. Indicate who is responsible for container orchestration, image security scanning, runtime patching, tenant isolation, and logging. Discuss one operational challenge of the multi-tenant model.

Unlock Full Question Bank

Get access to hundreds of Cloud Service Models interview questions and detailed answers.

Join thousands of developers preparing for their dream job.