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 hands-on cloud architecture design experience from Deloitte's Cloud Engineering position, featuring a mobile banking app modernization project.

德勤云工程师岗位真实面试经历，详解手机银行App云上现代化改造方案设计。

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.
准备面试时，别光顾着背各种云服务的名词了。多找几个真实的业务场景（比如电商、社交、游戏），自己动手，从零开始，在云上把它们搭出来。这个过程，会让你对云的理解，提升一个档次。