Cloud Migration Strategy and Execution Questions

Plan and execute cloud migrations with attention to minimizing customer impact and operational risk. Topics include the six R framework rehost replatform refactor repurchase retire and retain and criteria for choosing each path, inventory and dependency mapping, risk assessment and mitigation, wave planning and phased cutovers, automation and reproducibility using infrastructure as code and deployment pipelines, zero downtime techniques such as blue green and canary deployments, state transfer and database migration strategies, rollback and contingency plans, validation and smoke testing, and post migration optimization and cost and performance tuning.

HardTechnical

63 practiced

Design a migration plan for a healthcare application subject to HIPAA that stores ePHI. Address data residency, encryption, key management (customer-managed keys), BAAs with cloud providers, audit logging, role-based access controls, and validation steps to prove compliance during and after migration. Include ways to minimize downtime while meeting regulatory requirements.

Sample Answer

**Clarify scope & constraints**- ePHI in databases (RDS), object store (S3), backups, and logs. Must remain within permitted jurisdiction (data residency), use customer-managed keys (CMKs), BAA in place, minimal downtime.

**High-level approach**1. Prepare target cloud account with HIPAA controls.2. Sync data securely (encrypted in transit), validate, cut over in phased fashion (pilot → canary → full).

**Architecture & controls**- Data residency: choose cloud regions in permitted country/regions; restrict cross-region replication unless allowed.- Encryption & key management: use customer-managed CMKs (e.g., AWS KMS CMKs backed by CloudHSM). Envelope encryption for large objects; ensure keys are multi-AZ within allowed region.- BAAs: sign BAA with cloud provider and any SaaS vendors before processing ePHI.- Network: VPCs, private subnets, VPC endpoints (S3, KMS), strict Security Groups and NACLs.- RBAC: implement least-privilege with IAM roles, conditional policies (source IP, MFA), attribute-based access where possible.- Audit logging: enable immutable, centralized logs (CloudTrail, Config, GuardDuty); store logs in a write-once S3 bucket with KMS CMK and separate retention account.

**Migration plan & downtime minimization**- Prep: infra-as-code, hardened images, secrets in Secrets Manager with CMK, automated compliance checks.- Pilot: migrate non-production and a small patient subset using continuous replication (DMS for RDS with CDC).- Canary: bi-directional sync for a subset of production traffic; validate data integrity and performance.- Cutover: schedule brief maintenance window; perform final delta sync, switch DNS/load balancer. Use blue/green or traffic-shifting to rollback quickly.- Backups: take encrypted snapshots; retain until validation complete.

**Validation & evidence**- Pre-migration: policy inventory, threat model, BAA copy, KMS key policy docs.- During migration: checksums/hash comparisons, transactional counts, DMS validity reports, CloudTrail event sample.- Post-migration: run automated compliance tests (Config rules, CIS benchmarks), produce audit report with: - Data residency proof (resource ARNs in region) - KMS key genealogy & rotation logs - Access review (IAM roles used, last access) - Immutable audit logs (CloudTrail delivered, S3 object lock evidence) - Pen test/VA summary- Retain an audit pack for internal compliance and external auditors.

**Operational controls & monitoring**- Continuous monitoring: SIEM ingest of logs, alerting on anomalous access.- Key lifecycle: rotate CMKs per policy, emergency key-revocation procedure, split duties for key administration.- Change control: enforce CI/CD gating with approval flows.

**Rollback & contingency**- Maintain pre-migration snapshots and network configs; ability to redirect traffic back to source quickly; rehearse rollback in pilot.

This plan balances minimal downtime (CDC-based sync, blue/green) with HIPAA requirements (BAA, CMKs, RBAC, immutable logging) and provides clear validation artifacts for auditors.

HardSystem Design

49 practiced

Design canary deployment metrics and automated rollback triggers for releasing a new service to 10% of traffic initially. Specify primary metrics to monitor (system and business), statistical thresholds, sample size calculation to detect regressions at 99% confidence within a 30-minute window, and the automated workflow that shifts traffic and triggers rollback.

Sample Answer

**Clarify objective & constraints**- Release new service to 10% of traffic for a 30‑minute canary window, detect regressions with 99% confidence, and automate progressive rollout or rollback.

**Primary metrics to monitor**- System (observability): error rate (5xx or service errors), latency P50/P95/P99, CPU/memory OOMs, request throughput, saturation (queue length).- Business (user impact): conversion rate, checkout success rate, API success per user, revenue per minute.- Signal priority: Error rate and latency P95 are primary; business metrics secondary but tied to rollback if they degrade.

**Statistical thresholds & test**- Use hypothesis testing on proportions (error rate) and means (latency) with alpha = 0.01 (99% confidence), one‑sided for regressions.- Require both: (A) Statistically significant degradation at alpha=0.01 and (B) effect size above operational threshold (e.g., error rate +0.5% absolute or latency +30% P95).- Example triggers: - Error rate increase: p_new − p_baseline >= 0.005 AND p‑value < 0.01 - Latency: P95_new / P95_baseline >= 1.3 AND t‑test p‑value < 0.01

**Sample size calculation (proportions)**- Use two‑sample proportion formula to estimate required canary samples n per group to detect absolute delta at alpha and power.

text

n = [ ( z_{1-alpha} * sqrt(2*p*(1-p)) + z_{power} * sqrt(p0*(1-p0) + p1*(1-p1)) )^2 ] / delta^2

- Where p = (p0 + p1)/2, z_{1-alpha}=2.576 (99% conf), z_{power}=0.842 (80% power).- Example: baseline error p0=0.005, want detect p1=0.01 (delta=0.005): - p=0.0075 -> numeric n ≈ 7,000 requests per group. - To detect within 30 minutes require ~7k canary requests in 30 min => ~3.9 RPS to canary. If canary is 10% of total traffic, total product RPS must be >=39 RPS.

**Automated workflow (traffic shifting + rollback)**1. Prechecks: health checks green, infra metrics (capacity), synthetic smoke tests pass.2. Deployment: push new version to target group; set weighted routing (ALB / Route53 / Traffic Directors) to 10% to canary.3. Data collection: aggregate metrics in real time (CloudWatch, Prometheus, Datadog); compute rolling aggregates every 1 minute.4. Statistical engine: run scheduled tests (every 1–5 min) comparing canary vs baseline using the formulas above; require both statistical significance and effect size.5. Decision logic: - If no regression detected and required sample size not yet reached, keep canary at 10% until min sample/time reached (max 30 min). - If pass (no regression after 30 min and samples sufficient): incrementally shift to 50% then 100% with staged waits and rechecks. - If fail (significant regression + effect size exceeded OR safety metric breach): immediately rollback — set weight to 0% and kill canary instances.6. Rollback actions: weighted routing change, scale down new version, trigger runbook (PagerDuty), create incident with diagnostics (logs, traces, snapshots).7. Postmortem & automated safeguards: block auto‑promote for this build ID until manual investigation, store metric snapshots and raw request samples for debugging.

**Implementation notes & tooling**- Use AWS ALB/Route53 weighted routing or Traffic Director; use Lambda/Step Functions or Spinnaker for orchestration.- Metrics ingestion: Prometheus/CloudWatch + query engine to compute p‑values; use distributed tracing for root cause.- Safeguards: global kill switch, cool‑down between promotion steps, and synthetic canary probes independent of user traffic.

**Tradeoffs**- Short window increases false negatives; require balancing alpha/power and minimum traffic.- Use conservative thresholds for business metrics to avoid user impact; prefer rollback on system errors even if business metrics lag.

This design gives deterministic sample targets, clear automated decision rules, and an actionable rollback workflow tailored to cloud infrastructure (ALB/Route53, CloudWatch/Prometheus, Lambda/Step Functions).

HardTechnical

49 practiced

Create an automated runbook (describe steps, alerts, and sample scripts) to handle a failed cutover where API latency spikes and error rate exceed thresholds. Include automatic mitigations (traffic shift, circuit breaker), operator escalation steps, required logs/metrics to collect for RCA, and communications templates for stakeholders and customers.

Sample Answer

**Situation & Objective**Automated runbook to detect/mitigate failed cutover where API latency and error rate exceed thresholds, and to escalate, collect RCA data, and communicate to stakeholders.

**Automated Detection & Alerts**- Metrics & thresholds (CloudWatch/Stackdriver/Prometheus): - 95th pct latency > 800 ms for 5m - Error rate (5xx) > 3% for 2m - Request success rate drop > 5% vs baseline- Alerts: - P1 Pager duty (immediate) - Slack #oncall with runbook link - Email to SRE leads if persists > 10m

**Automatic Mitigations (run inline)**1. Circuit breaker: toggle Envoy/HAProxy or feature-flag to reduce retries & reject new requests- Sample feature-flag toggle (curl to LaunchDarkly API)

bash

# toggle feature flag to disable new traffic to v2
curl -X PATCH "https://app.launchdarkly.com/api/v2/flags/{proj}/{flag}" \
  -H "Authorization: Bearer $LD_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"environments":{"production":{"on":false}}}'

2. Traffic shift: rollback or weighted routing to previous stable service- AWS Route53 weighted update to shift traffic back to blue target

bash

aws route53 change-resource-record-sets --hosted-zone-id Z123 \
--change-batch '{
  "Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"api.example.com","Type":"A",
    "SetIdentifier":"stable","Weight":90,"TTL":60,
    "ResourceRecords":[{"Value":"1.2.3.4"}]
  }}]}'

3. Auto-scale temporary capacity: increase ALB target capacity or scale-out ECS tasks

**Operator Escalation Steps**1. Acknowledge alert; run automated mitigations (scripts above).2. If mitigations succeed (latency & errors normalize within 5m) — monitor 30m, postmortem.3. If not: escalate to Cloud Eng lead and Product Owner; open incident ticket; prepare rollback to previous release and DNS/route rollback.4. If partial outage persists >30m, engage Exec comms.

**RCA & Logs to Collect**- Aggregated traces (X-Ray / Jaeger) for 1h before/after cutover- Application logs (structured JSON) and stderr for affected services- ALB/NGINX access logs, 5xx entries, response times- Metrics: CPU/memory, GC, thread pools, DB latencies, connection counts- Deployment pipeline logs (CI/CD), feature flags, infra changes- Network flow logs (VPC flow / Cloud NAT), DNS change history

**Communications Templates**- Initial incident (Slack/Email) - Subject: P1 — API latency spike after cutover — Investigating - Body: Short summary, time, mitigation in progress (traffic shift/circuit breaker), expected updates every 15m, named on-call.- Customer status update - "We detected elevated API errors after today's cutover at 14:03 UTC. We have temporarily shifted traffic to the previous stable service and are monitoring. No data loss expected. Next update in 30 minutes."- Post-incident report - Timeline, root cause, mitigations executed, action items, owner, SLA impact.

**Runbook Testing & Ownership**- Automated chaos tests in staging to validate circuit-breaker and weighted routing- Weekly playbook drills; owner: Cloud Engineering Lead; maintain runbook in runbooks repo with executable scripts and CI-checks.

This runbook balances automation (fast mitigations) with clear escalation, ensures required telemetry for RCA, and provides ready-to-send communications.

MediumSystem Design

67 practiced

Design the network and DNS strategy for a migration that requires both low latency connectivity during cutover and the ability to rollback quickly. Cover options such as VPN vs Direct Connect/ExpressRoute, bandwidth planning, split-horizon DNS, TTL changes, weighted routing, and a sample DNS cutover sequence to ensure minimal packet loss and fast rollback.

Sample Answer

**Clarify goals & constraints**- Low latency during cutover (minutes), ability to rollback immediately, preserve in-flight sessions where possible, security/compliance for traffic, expected traffic surge during cutover.

**Connectivity choice**- Prefer Direct Connect / ExpressRoute for low, consistent latency and higher throughput; use VPN over the Internet as a temporary fallback or for parallel testing. For critical cutovers, provision Direct Connect and a resilient VPN for failover.

**Bandwidth & capacity planning**- Measure baseline egress/ingress and add 30–50% headroom for migration spikes. If using Direct Connect, provision multiple LAGs or circuits and enable jumbo frames/MTU tuning. Use QoS to prioritize cutover traffic.

**DNS strategy**- Use split-horizon (internal DNS -> private endpoints; public DNS -> public endpoints) so cutover affects only intended clients.- Lower TTLs well ahead (e.g., 300s or 60s depending on cache control) 24–48 hours before cutover.- Configure weighted routing (Route 53/Azure Traffic Manager/GCP Cloud DNS) to shift percentage of traffic to new endpoints. Use health checks.

**Sample DNS cutover sequence**1. 48h before: lower public TTL to 60–300s; ensure monitoring and health checks configured.2. Test: add new endpoints in weighted DNS set to 10% with health checks; verify telemetry.3. Gradual ramp: increase weight to 50% → 90% over short windows (monitor latency, errors).4. Final switch: set weight 100% to new endpoints; keep old endpoints online but remove from load balancer.5. Validate for one TTL period (60–300s) then decommission.

**Fast rollback**- Keep old endpoints and circuits active and registered in weighted DNS; rollback by restoring previous weight (e.g., 100% old) — takes one TTL to propagate.- If instant rollback needed, use short TTLs and an automation playbook to flip weights and BGP routes; for Direct Connect you can withdraw routes or adjust route prepending.

**Operational notes**- Automate DNS changes via IaC/CLI, tie to CI/CD runbooks.- Track DNS cache behavior for major CDNs; coordinate with partners.- Use packet capture and synthetic transactions to detect packet loss; truncate flows gracefully with TCP RST only if necessary.

This balances minimal latency, controlled traffic shifting, and near-instant rollback while keeping security and observability.

EasyTechnical

56 practiced

Outline a step-by-step approach to estimate the initial cloud migration cost for a small application with known CPU, memory, storage and network usage. Identify which metrics to collect, which cloud cost components to model (compute, storage, data transfer, licenses, labor), and how to present uncertainties to stakeholders.

Unlock Full Question Bank

Get access to hundreds of Cloud Migration Strategy and Execution interview questions and detailed answers.

Join thousands of developers preparing for their dream job.