Deloitte UK Cloud Engineering Interview: Building Cloud-Native Solutions

德勤英国云工程师面试：云原生解决方案设计实战

4 January 2025

3 min read

Anonymous Candidate

2025 Deloitte UK Cloud Engineer Interviewee

摘要 Summary

A practical account of Deloitte UK Cloud Engineering Interview: Building Cloud-Native Solutions. It explains what the round actually tested, how the interview unfolded, and what to prepare before interview day.

这是一篇围绕《德勤英国云工程师面试：云原生解决方案设计实战》整理的实用复盘。它会先讲清楚这场面试看什么、流程怎么走，以及面试前最该优先准备的部分。

This guide is for candidates preparing for Deloitte UK Cloud Engineering Interview. The short answer is that the round usually tests three things at once: whether you understand the role, whether you can explain your thinking clearly, and whether your examples or solutions still hold up when the interviewer keeps digging.

这篇文章适合正在准备德勤英国云工程师面试的同学。先说结论：这类面试通常不会只看你会不会答题，而是同时看岗位理解、表达结构，以及你的案例或解法在连续追问下能不能站得住。

If your time is limited, read the opening sections and the FAQ first. They will tell you what to revise first, which mistakes show up most often, and how to spend your next few hours on preparation more efficiently.

如果你时间有限，先看开头和文末 FAQ 就够了。读完这两部分，你基本就能判断自己该先补案例表达、框架思维，还是技术细节，不用一上来就把时间花在低优先级内容上。

Interview Overview| 面试概述

Just finished Deloitte's Cloud Engineering interview, and it felt like participating in a 'cloud architect' live exercise. The interviewer didn't bother with textbook questions—instead, they gave me a real business scenario and had me design a cloud-native solution on the spot.

刚面完Deloitte的Cloud Engineering岗，感觉自己像是参加了一场「云上架构师」的实战演习。面试官不怎么问八股文，而是直接给你一个真实的业务场景，让你现场设计一套云原生的解决方案。

The Scenario| 面试场景

The client is a traditional UK retail bank. Their mobile banking app currently runs in an old, on-premise data center. The system is slow, unstable, and every new feature takes months to launch. The bank's CTO is determined to migrate the entire mobile banking app to public cloud and modernize it. As the Cloud Engineer, how would you design this new cloud architecture?

假设客户是一家传统的英国零售银行。他们现在的手机银行App，是跑在一个老旧的本地数据中心里的。这个系统又慢又不稳定，每次想上线一个新功能，都要花好几个月。现在，银行的CTO下定决心，要把整个手机银行App迁移到公有云上，并进行现代化改造。你作为Cloud Engineer，会怎么设计这个新的云上架构？

My Architecture Blueprint| 我的架构设计蓝图

This is a typical 'Application Modernization' project. I decided to explain my design approach from four layers: Infrastructure, Application Architecture, Data Architecture, and DevOps.

这是一个典型的「应用现代化」项目。我决定从「基础设施」、「应用架构」、「数据架构」和「DevOps」四个层面，来阐述我的设计思路。

Part 1: Infrastructure Layer - Embracing Infrastructure as Code| 第一部分：基础设施层 - 拥抱基础设施即代码

First, we need to choose a suitable 'home' for the app. Given banking's high security and compliance requirements, I would choose a mainstream public cloud provider like AWS or Azure, and build a secure, isolated Landing Zone that meets financial regulatory requirements.

首先，我们要为App选择一个合适的「家」。考虑到银行对安全和合规的高要求，我会选择一个主流的公有云厂商，比如AWS或Azure，并在上面搭建一个符合金融监管要求的、安全隔离的Landing Zone。

All infrastructure—including network (VPC), compute resources (EC2/VM), and storage (S3/Blob)—won't be configured manually. We'll use Infrastructure as Code tools like Terraform or CloudFormation for unified definition and management. This enables version control for infrastructure, rapid replication of multiple environments (dev, test, prod), and ensures environmental consistency.

所有的基础设施，包括网络（VPC）、计算资源（EC2/VM）、存储（S3/Blob），都不会手动去点点点。我们会用Terraform或CloudFormation这样的IaC工具来统一定义和管理。这样做的好处是，我们可以对基础设施进行版本控制，可以快速地复制多套环境（开发、测试、生产），而且能确保环境的一致性。

Part 2: Application Layer - From Monolith to Microservices| 第二部分：应用架构层 - 从巨石到微服务

The old mobile banking app is likely a Monolithic Application with all functionality (user login, transfers, bill checking) coupled together. Our job is to decompose it into independent Microservices.

老的手机银行App，很可能是一个「巨石应用」，所有的功能（用户登录、转账、查账单）都耦合在一起。我们要做的，就是把它拆分成一组组独立的「微服务」。

We can have a 'User Service', an 'Account Service', a 'Payment Service'. Each service is an independent unit that can be developed and deployed independently.
我们可以有一个「用户服务」，一个「账户服务」，一个「支付服务」。每个服务都是一个独立的、可以独立开发、独立部署的单元。
Small changes to one service won't require redeploying the entire app.
这样一来，某个服务的小改动，就不需要整个App都重新发布一遍了。
We'll containerize these microservices using Docker, then orchestrate and manage them with Kubernetes (K8s). K8s helps us achieve auto-scaling, self-healing, greatly improving system resilience and reliability.
这些微服务，我们会用Docker把它们容器化，然后用Kubernetes来进行编排和管理。K8s可以帮我们实现服务的自动扩缩容、故障自愈，大大提高系统的弹性和可靠性。

Part 3: Data Layer - Polyglot Persistence| 第三部分：数据架构层 - 多语言持久化

In a microservices architecture, we can't use a single, massive relational database anymore. We'll choose the most suitable database for each type of data—this is called Polyglot Persistence.

在微服务架构下，我们不能再用一个单一的、巨大的关系型数据库了。我们会为每种数据，选择最适合它的数据库，也就是所谓的「多语言持久化」。

Core transaction data: Continue using relational databases like Amazon RDS or Azure SQL for ACID compliance.
用户的核心交易数据：继续使用关系型数据库，比如Amazon RDS或Azure SQL，因为它们能保证数据的一致性（ACID）。
Login info and session data: Use in-memory databases like Redis for speed.
用户的登录信息、Session数据：用Redis这样的内存数据库，因为速度快。
Product catalogs and unstructured data: Use NoSQL databases like MongoDB or DynamoDB.
产品目录、用户评论这些非结构化数据：用MongoDB或DynamoDB这样的NoSQL数据库。

Part 4: DevOps & Automation - Building a Software Factory| 第四部分：DevOps与自动化 - 构建软件工厂

Good architecture alone isn't enough—we need an efficient 'software production line'. We'll build a complete CI/CD pipeline.

光有好的架构还不够，我们还得有一套高效的「软件生产线」。我们会建立一套完整的CI/CD流水线。

When a developer pushes code to the Git repository, Jenkins or GitLab CI will automatically trigger the pipeline. It will automatically compile code, run unit tests, perform security scans, package the code into a Docker image, and finally auto-deploy it to our K8s cluster.

当一个开发人员把代码推送到Git仓库后，Jenkins或GitLab CI会自动地触发这个流水线。流水线会自动地进行代码编译、单元测试、安全扫描，然后把代码打包成一个Docker镜像，最后自动地把它部署到我们的K8s集群里。

The entire process, from code commit to production, should be automated. Our goal is to reduce new feature deployment from months to days, even hours.
整个过程，从代码提交到上线，都应该是自动化的。我们的目标是，让新功能的上线，从过去的几个月，缩短到几天，甚至是几小时。

Key Takeaways| 面试心得

Deloitte's Cloud Engineering interview really values your hands-on ability and architectural design thinking. They're looking not for a bookworm who only knows AWS certifications, but for a 'cloud architect' who can understand client business pain points and design elegant, robust, scalable solutions using cloud-native technology.

Deloitte的Cloud Engineering面试，非常看重你的实际动手能力和架构设计思想。他们要找的，不是一个只会考AWS认证的书呆子，而是一个能理解客户的业务痛点，并能用云原生技术，为客户设计出一套优雅、健壮、可扩展的解决方案的「云上建筑师」。

When preparing, don't just memorize cloud service terminology. Find some real business scenarios (e-commerce, social media, gaming) and build them from scratch on the cloud yourself. This process will elevate your cloud understanding to a whole new level.
准备面试时，别光顾着背各种云服务的名词了。多找几个真实的业务场景（比如电商、社交、游戏），自己动手，从零开始，在云上把它们搭出来。这个过程，会让你对云的理解，提升一个档次。

常见问题 FAQ

What does Deloitte UK Cloud Engineering Interview usually test?

德勤英国云工程师面试通常会重点看什么？

Most rounds in this guide test a mix of role understanding, structured communication, and follow-up resilience. For technical or case-heavy roles, you also need to show how you break a problem down instead of jumping straight to a memorized answer.

从这篇文章覆盖的内容来看，这类面试通常会同时看岗位理解、表达结构和追问下的稳定性。技术或案例占比更高的岗位，还会额外看你能不能把问题拆开，而不是只会背现成答案。

How should I use this guide if I only have a few days before the interview?

如果距离面试只剩几天，这篇文章应该怎么用？

Use the opening sections to identify the main signals first, then focus on the recurring examples, frameworks, or technical topics that the article highlights. The FAQ and summary help you decide what deserves practice time and what can stay secondary.

先用开头部分抓住这场面试最核心的判断标准，再回头练文中反复出现的案例、框架或技术点。摘要和 FAQ 的作用，就是帮你判断哪些内容值得优先练，哪些可以先放一放。

What mistake causes candidates to underperform most often in Deloitte UK Cloud Engineering Interview?

准备德勤英国云工程师面试时，最容易拉低表现的错误是什么？

The most common problem is giving answers that sound prepared but do not survive follow-up questions. Interviewers usually notice when the structure is there but the underlying judgment, numbers, or trade-offs are missing.

最常见的问题，是答案表面上很完整，但一到追问就露出底子不够。面试官通常很快就能听出来：你的结构在，判断、数据和取舍却没有真正想清楚。