Deloitte Cloud Engineer Interview: Questions, Experience & Prep (2026)

Deloitte is one of the Big Four consulting firms with a large cloud practice across India. As of mid-2026, knok jobradar tracked 444 open roles at Deloitte, with Cloud Engineer positions spread across Bangalore (13 openings), Delhi (13), Hyderabad (6), Pune (5), and Chennai (2).

The Deloitte Cloud Engineer interview typically spans multiple rounds. Candidates report a mix of technical depth questions, consulting-aptitude scenarios, and behavioural rounds. Roles sit within Deloitte's technology consulting or USI delivery arms, so interviewers want someone who can build solid cloud solutions and also explain trade-offs clearly to non-technical stakeholders.

Expect questions on AWS, Azure, or GCP architecture, infrastructure-as-code (IaC), DevOps tooling, and real project experience. Candidates also typically face a scenario question that tests structured, consulting-style thinking.

Candidates preparing for a Deloitte Cloud Engineer interview commonly report these questions across rounds:

1. Walk me through a cloud architecture you designed from scratch. What decisions did you make and why?
2. How do you approach cost optimisation on AWS or Azure for a large enterprise client?
3. Explain the difference between IaaS, PaaS, and SaaS with a real example from your own work.
4. How have you handled a major cloud outage or incident on a production system?
5. What is your experience with Terraform or CloudFormation? Walk me through how you structure your modules.
6. How do you design for high availability and disaster recovery in a multi-region setup?
7. Describe a time you had to convince a client or stakeholder to adopt a cloud-native approach they were resistant to.
8. How do you approach security and compliance in a cloud environment, especially for a regulated industry like BFSI?
9. What is your experience with Kubernetes and container orchestration? How did you handle scaling challenges?
10. Deloitte works across many client industries. How do you quickly ramp up on a new domain's cloud requirements?
11. How do you handle infrastructure drift in a live environment managed by Terraform?
12. Tell me about a time you had to balance speed of delivery with cloud best practices.

Q: How have you handled a major cloud outage or incident on a production system?

*Situation:* Our e-commerce client's AWS environment went down during a peak sale event, causing all traffic to drop.

*Task:* I was the on-call cloud engineer responsible for restoring service and communicating status to the client team.

*Action:* I checked CloudWatch alarms and identified that an Auto Scaling group had hit its instance limit because of a misconfigured scaling policy. I immediately raised the limit via the AWS console, corrected the policy, and documented the specific failure scenario in our runbook so it would not recur. I kept the client updated at regular intervals throughout the incident.

*Result:* Service was restored within a few hours. The post-incident review led us to add a proactive alarm for scaling limit thresholds, which prevented similar issues in later sale events.

---

Q: Describe a time you convinced a stakeholder to adopt a cloud-native approach they were resistant to.

*Situation:* A client's IT head wanted to lift-and-shift their on-prem Oracle database to a VM on Azure, citing familiarity and risk aversion.

*Task:* My job was to assess whether lift-and-shift was the right call or whether a managed service would serve them better long-term.

*Action:* I prepared a side-by-side comparison of total cost of ownership, operational overhead, and SLA commitments for both approaches, using publicly reported Azure pricing and the client's own usage data. I then ran a small proof-of-concept on Azure SQL Managed Instance to address their performance concerns directly.

*Result:* The client agreed to migrate to the managed service. They reduced their DBA overhead and improved their RTO compared to what the self-managed VM approach would have offered.

---

Q: How do you handle infrastructure drift in a live environment managed by Terraform?

*Situation:* During a routine Terraform plan on a production AWS environment, I noticed several resources had been manually changed outside our IaC pipeline.

*Task:* I needed to reconcile the drift without disrupting live workloads or discarding changes that turned out to be intentional hotfixes.

*Action:* I ran terraform plan to catalogue every discrepancy, then worked with the team to determine which changes were intentional and which were accidental. For intentional ones, I updated the Terraform code to match the live state. For accidental ones, we scheduled a maintenance window to revert them. I also introduced a drift-detection job in our CI pipeline that runs nightly.

*Result:* Drift on that account dropped to near zero within a couple of weeks, and the nightly job now flags any out-of-band changes before they become a bigger problem.

For technical architecture questions, walk through requirements and constraints first (scale, latency, compliance), then describe the services you chose and why, then call out the trade-offs you considered. Deloitte interviewers appreciate candidates who frame choices in terms of client value, not just technical preference.

For behavioural questions, use the STAR format: Situation, Task, Action, Result. Keep the Situation and Task brief (two to three sentences each) and spend most of your time on Action and Result. Be precise about what *you* did versus what the broader team did.

For scenario or case questions, think out loud. Deloitte's consulting culture values structured thinking. State your assumptions, lay out the options, evaluate them, and give a clear recommendation. If you need more information, ask for it explicitly rather than guessing.

For cost and trade-off questions, anchor your answer to real constraints: budget, timeline, team skill set, and regulatory requirements. Avoid recommending the most sophisticated solution by default. Show that you can match the solution to the client's actual situation.

Deloitte Cloud Engineers work on client engagements, so interviewers typically look for a combination of cloud depth and consulting-ready communication skills.

Technical credibility matters most in early rounds. Be ready to go deep on at least one cloud platform (AWS, Azure, or GCP) and show hands-on experience with IaC, networking, security, and DevOps tooling. Vague answers like 'I used Terraform to manage infrastructure' are not enough; interviewers will ask follow-up questions until they find the edge of your knowledge.

Client-facing communication is valued heavily. Candidates who can explain a VPC peering setup in plain language for a finance client stand out. Practise translating technical decisions into business impact statements.

Problem-solving under ambiguity is tested through scenario questions. Deloitte projects often start with incomplete requirements. Show that you can ask the right clarifying questions and make reasonable assumptions when needed.

Ownership and accountability appear in behavioural questions. Interviewers want to see that you have taken responsibility for outcomes, including failures, and extracted clear learnings from them.

Step 1: Solidify your core cloud platform knowledge. Pick your strongest platform (AWS, Azure, or GCP) and be ready to go deep on compute, storage, networking, IAM, and monitoring. Review any certifications you hold and refresh the gaps.

Step 2: Practise IaC and DevOps tools. Terraform and Kubernetes come up frequently in candidate reports. If you have not worked with these recently, rebuild a small project to refresh your hands-on familiarity.

Step 3: Prepare five to six STAR stories. Cover at least one incident or outage, one stakeholder challenge, one cost-optimisation win, and one example of working under tight deadlines. Write them out and rehearse them so you can deliver each one in under three minutes.

Step 4: Study Deloitte's cloud practice areas. Deloitte works across BFSI, manufacturing, healthcare, and public sector. Read up on common cloud compliance requirements in these sectors, for example RBI cloud guidelines for banking. This helps you answer domain-specific scenario questions confidently.

Step 5: Prepare smart questions to ask. Good questions signal engagement. Ask about team structure on cloud engagements, the mix of greenfield versus migration projects, and how the team approaches knowledge transfer to clients. Avoid asking about things easily found on the Deloitte website.

Step 6: Tailor to the job description. Deloitte's Cloud Engineer roles vary by sub-practice and client vertical. Match your examples to the specific stack and industry mentioned in the JD you applied to.

Going too broad across cloud platforms. Claiming expertise in AWS, Azure, and GCP without depth on any of them is a red flag. Pick one or two and be ready to go deep.

Skipping the 'why' in architecture answers. Stating which services you used without explaining the trade-offs you considered makes answers feel shallow. Always connect your choices to the client's requirements.

Treating behavioural questions as an afterthought. Many candidates over-prepare for technical questions and under-prepare for STAR questions. Deloitte's consulting culture means behavioural rounds carry real weight.

Not asking clarifying questions in scenario rounds. Jumping straight to a solution without understanding constraints looks like poor consulting instinct. Ask about scale, budget, compliance, and timeline before proposing an architecture.

Using jargon without explanation. Interviewers from the consulting side may not be cloud specialists. Practise explaining technical concepts in plain language.

Overselling team achievements as personal ones. Interviewers will probe with 'What specifically did *you* do?' Be precise about your individual contribution in every STAR story.