DUY PHAM — INTERVIEW STORY BANK & CLOUD LANDING ZONE CHEAT SHEET 2026
Purpose: interview preparation for Cloud Engineer / Cloud Platform Engineer / Azure/AWS Architect / DevOps / Security-oriented roles.
How to use this file: Do not memorize every sentence. Memorize the story spine, technical concepts, and key phrases. Answer from your real experience and clearly separate what you personally implemented from what the wider team designed[cite: 1].
PART I — INTERVIEW STORY BANK
How to use STAR
S — Situation → What was happening?
T — Task → What was your responsibility?
A — Action → What did YOU actually do?
R — Result → What changed?
For technical interviews, add:
Decision / Trade-off → Why did you choose that approach?
Lesson → What did you learn or change afterward?[cite: 1]
STORY 1 — Large Mailbox Migration
Tags: Changing requirements · Problem-solving · Customer communication · Pressure
Interview story
Situation
One situation I remember was during an Exchange-to-cloud migration at Dinotronic[cite: 1].
We were migrating users in batches, and during one migration we discovered that one user's mailbox was much larger than what our standard migration process was designed for. If we followed the normal process, there was a risk that this one mailbox could delay the whole migration batch[cite: 1].
Task
My priority was to keep the overall migration schedule on track while making sure the user could continue working normally[cite: 1].
Action
Instead of waiting and hoping the migration would eventually finish, I raised the issue immediately with our customer-success team and discussed the options with them[cite: 1].
We agreed on an interim approach. We restructured the mailbox folders so the user could continue working with the current emails, while the older emails were handled separately with support from Microsoft's backend team[cite: 1].
That allowed us to separate the user's immediate business needs from the technical migration problem[cite: 1].
Result
The main migration stayed on schedule, and the user had no disruption to their current email workflow[cite: 1].
After that, we also changed our planning process. For future migrations, we started identifying unusually large mailboxes earlier and communicating the potential impact to customers before the migration started[cite: 1].
Lesson
When an unexpected technical problem appears during a project, I don't try to hide it or solve everything silently. I raise it early, separate the immediate business impact from the technical root cause, and work with the relevant stakeholders on a practical solution[cite: 1].
STORY 2 — Azure WAF / OWASP Disagreement
Tags: Customer disagreement · Security trade-offs · Communication · Stakeholder management
Interview story
Situation
A good example of handling disagreement with a customer was when we implemented Azure WAF with OWASP rules for an internet-facing application[cite: 1].
After we went live, some legitimate requests started getting blocked. The application was relatively old and some of its requests didn't fully follow the patterns expected by the OWASP rules[cite: 1].
Task
The challenge was to restore the legitimate traffic without simply weakening the WAF protection[cite: 1].
Action
I explained the situation to the customer in non-technical terms. I used an analogy of a security guard checking IDs: the WAF was doing its job, but some legitimate people were being rejected because they didn't match the expected pattern[cite: 1].
I presented two options.
The first was to modify the application so that it followed the security rules properly. The second was to create a narrowly scoped exception for the specific rule that was causing the problem[cite: 1].
The customer explained that changing the application wasn't feasible at that time, so we chose the scoped exception and made sure they understood the security trade-off[cite: 1].
Result
The application became accessible again, while the rest of the WAF protection remained in place[cite: 1].
More importantly, the customer made the decision with a clear understanding of the security implications rather than simply asking us to disable the WAF[cite: 1].
Lesson
Security isn't only about saying "no". It's about understanding the business requirement, explaining the risk clearly, and finding the smallest possible exception when a full remediation isn't immediately practical[cite: 1].
STORY 3 — Azure Landing Zone Design / Implementation
Tags: Cloud architecture · IaC · Reusability · Terraform/CDKTF · Regional scaling
Important positioning
Do not claim that you were the sole architect of the entire landing zone if that was not your role[cite: 1].
Your strongest and most accurate positioning is:
I was heavily involved in implementing the landing zone architecture through Terraform/CDKTF, and I understood how the modules fitted into the overall architecture.[cite: 1]
Project context
The exact structure varied by customer, but typically: - Test and production environments - Regions such as EMEA, America and Asia - Regional hub structures - Shared services such as firewall, DNS and Bastion - Workloads separated into appropriate spokes / environments[cite: 1]
Interview story
Situation
One of the cloud architecture projects I worked on was an Azure landing zone for a German enterprise customer moving workloads from on-premises to Azure[cite: 1].
The environment was organized by region, such as EMEA, America and Asia, and we generally had separate test and production environments depending on the customer's requirements[cite: 1].
Task
My main responsibility was implementing the landing zone architecture through Terraform/CDKTF[cite: 1].
I wasn't the sole architect of the entire landing zone, but I needed to understand how the architecture was structured and how networking, shared services, environments and workload resources fitted together[cite: 1].
Action
I worked mainly on Terraform/CDKTF modules and the configuration connecting those modules[cite: 1].
The landing zone used a hub-and-spoke pattern, with shared services such as firewall, DNS, Bastion and centralized security controls in the shared layer, while workload environments were separated appropriately[cite: 1].
When a new region was required, we didn't build everything from scratch. We first checked which resources were actually required for that region, referenced the existing Terraform modules, provided the region-specific configuration and deployed them[cite: 1].
Result
The architecture became reusable across regions and environments. Adding a region was mainly a matter of selecting the required resources, composing the existing modules and providing the appropriate configuration rather than creating a completely new implementation[cite: 1].
Lesson
For me, Terraform was the implementation mechanism. The real value of the landing zone was having a standardized and reusable architecture that could be consistently extended across environments and regions[cite: 1].
STORY 4 — DNS Mistake Caught in PR Review
Tags: Mistake · Attention to detail · Process · Honesty
Interview story
Situation
One example of a mistake I made was during a bulk DNS change[cite: 1].
I had to update a large number of DNS records in our code repository[cite: 1].
Task
The goal was to make all the required DNS changes accurately and deploy them safely[cite: 1].
Action
While preparing the changes, I accidentally entered the wrong value for one of the records[cite: 1].
I submitted the pull request, and fortunately one of my teammates caught the mistake during the review before it was merged or deployed[cite: 1].
I corrected the record and continued with the change[cite: 1].
Result
There was no customer impact because the mistake was caught during the review process[cite: 1].
The experience reinforced something that became more concrete for me: repetitive bulk changes are exactly where small mistakes can easily slip through[cite: 1].
Since then, I pay extra attention to those changes before opening a PR and use the review process as an actual quality gate, rather than treating it as just a formality[cite: 1].
Lesson
The important part isn't saying that I never make mistakes. It's having a process that catches mistakes before they become incidents, and learning how to reduce the chance of making the same mistake again[cite: 1].
STORY 5 — Terraform Key Vault Soft-Delete Blocker
Tags: Teamwork · Technical blocker · Azure · Terraform · Collaboration
Interview story
Situation
We had a deployment where Terraform was managing an Azure Key Vault, and we needed to redeploy a vault using the same name[cite: 1].
The problem was that Azure's soft-delete behavior meant we couldn't immediately recreate the vault with the same name[cite: 1].
Task
We needed to find a solution without missing the deployment schedule agreed with the customer[cite: 1].
Action
I worked through the problem together with a teammate[cite: 1].
We considered several options: purging the existing vault if our permissions allowed it, temporarily using another name, or waiting until the retention period allowed us to recreate it[cite: 1].
Rather than immediately choosing the first workaround, we discussed the impact of each option and found an approach that fit within our timeline[cite: 1].
Result
We kept the deployment on schedule without a customer-facing delay[cite: 1].
Lesson
Collaboration is especially useful when dealing with cloud platform constraints. Sometimes the fastest solution isn't about knowing the answer immediately. It's about getting another engineer involved early, looking at the constraints together, and finding an option that is technically safe and practical[cite: 1].
STORY 6 — SonarQube CI/CD Modernization
Tags: Automation · Docker · CI/CD · Terraform · Initiative
Interview story
Situation
At ZOI, we had a SonarQube deployment process that was mostly manual[cite: 1].
The engineer had to build the Docker image manually, upload it to Azure Web App, and follow a sequence of steps that wasn't properly documented[cite: 1].
That meant the process depended heavily on whoever happened to perform the deployment[cite: 1].
Task
I wanted to make the deployment repeatable and reduce manual work and operational risk[cite: 1].
Action
I rebuilt the process as a CI/CD pipeline[cite: 1].
The process now starts with a version update in the repository. The pipeline automatically: 1. Builds the container image 2. Pushes it to the container registry 3. Runs a Terraform plan for review and approval 4. Backs up the database 5. Deploys the new container version[cite: 1]
The remaining manual decision is checking version compatibility[cite: 1].
Result
The deployment became repeatable and no longer depended on someone remembering a manual sequence of steps[cite: 1].
It also introduced a proper review point through the Terraform plan before infrastructure changes were applied[cite: 1].
Lesson
Automation isn't about automating everything. The real value is removing repetitive manual steps where human error adds no value, while keeping human approval where a decision or validation is actually important[cite: 1].
STORY 7 — AWS Config Cost Optimization
Tags: AWS · Cost optimization · FinOps · Proactive improvement
Interview story
Situation
At ZOI, we were using AWS Config for compliance monitoring[cite: 1].
While reviewing the configuration, I noticed that we were evaluating resources that didn't actually need to be covered by the compliance checks[cite: 1].
Task
I wanted to reduce unnecessary AWS Config costs without reducing the compliance coverage that was actually required[cite: 1].
Action
I reviewed which resource types and rules were genuinely relevant to the customer's compliance requirements[cite: 1].
I then excluded resources that didn't need to be monitored and removed rules that weren't providing meaningful compliance value[cite: 1].
Result
We reduced unnecessary AWS Config costs while keeping the compliance coverage that actually mattered[cite: 1].
Lesson
Cloud cost optimization should be connected to technical requirements. Instead of simply trying to reduce usage, I first looked at what the customer actually needed and then removed the unnecessary parts[cite: 1].
STORY 8 — GDPR / Retention Policy
Tags: Security · Compliance · GDPR · Data retention
Interview story
Situation
At Dinotronic, we had to deal with two different retention requirements[cite: 1].
On one side, GDPR required us to minimize the retention of personal data. On the other side, certain legal and financial requirements required backup data to be retained for up to ten years[cite: 1].
Task
The challenge was to implement controls that satisfied both requirements without treating them as if they were the same requirement[cite: 1].
Action
For active personal data, we implemented a one-year retention policy[cite: 1].
For sensitive data such as HR data, we also used sensitivity labels to restrict access automatically[cite: 1].
Separately, we maintained the longer retention period for backup data where it was required for legal or financial reasons[cite: 1].
The key was separating the requirements instead of applying one retention policy to everything[cite: 1].
Result
We had clear and auditable controls covering both requirements[cite: 1].
Lesson
Compliance requirements often come from different sources. Instead of treating "compliance" as one big requirement, I try to understand exactly what data is involved, why it needs to be retained, who needs access to it, and which regulation or business requirement drives the control[cite: 1].
STORY 9 — Managing Dinotronic + ZOI
Tags: Transparency · Time management · Multiple environments · Prioritization
Interview story
Situation
Since 2022, I have worked with Dinotronic AG and ZOI at the same time, with both arrangements being transparent and agreed with the respective employers[cite: 1].
The two roles were different in terms of customers and responsibilities[cite: 1].
Task
The challenge was making sure that working across two environments didn't affect delivery quality or create conflicts[cite: 1].
Action
I kept the responsibilities clearly separated[cite: 1].
Dinotronic was my primary full-time role, focused mainly on ongoing operations and enterprise customer support[cite: 1].
At ZOI, the work was structured around defined part-time hours and focused more on infrastructure-as-code, Terraform and cloud projects[cite: 1].
I treated the time commitments separately and made sure there was no overlap between customer environments or confidential information[cite: 1].
Result
I was able to work successfully across both environments without customer impact or conflicts[cite: 1].
Lesson
Transparency and prioritization are important when managing multiple responsibilities. Clear expectations and clear separation of responsibilities make the arrangement manageable[cite: 1].
STORY 10 — Vietnam to European Cloud Engineering
Tags: Career progression · Adaptability · Remote collaboration · European enterprise customers
Interview story
Situation
I started my career in Vietnam working mainly with network and security infrastructure[cite: 1].
Later, I joined Dinotronic AG and started supporting Swiss customers who were running technologies such as Hyper-V and Citrix[cite: 1].
Over time, the company moved more of its infrastructure toward Azure, and my role evolved with that change[cite: 1].
Task
I needed to continuously adapt my skills while delivering enterprise-level infrastructure and cloud services for European customers remotely from Vietnam[cite: 1].
Action
I gradually moved from traditional infrastructure operations into cloud engineering, including Azure, infrastructure as code, migrations and cloud operations[cite: 1].
I worked remotely with European customers for several years and also had opportunities to travel to Switzerland and Germany[cite: 1].
In 2026, I made the next step and relocated with my family to Helsinki[cite: 1].
Result
The transition wasn't a complete career restart[cite: 1].
I already had several years of experience delivering infrastructure and cloud work for European enterprise customers remotely[cite: 1].
Now I am building on that experience by working closer to the European technology market and continuing to grow in cloud, platform engineering and security[cite: 1].
Lesson
My career has been less about following one fixed technology path and more about adapting as the infrastructure around me changed[cite: 1].
STORY QUICK REFERENCE
| Interview question | Story |
|---|---|
| Mistake / failure | DNS |
| Changing requirements | Large Mailbox |
| Customer disagreement | WAF / OWASP |
| Architecture | Azure Landing Zone |
| Teamwork | Key Vault |
| Automation | SonarQube |
| Cost optimization | AWS Config |
| Compliance | GDPR |
| Multiple priorities | Dinotronic + ZOI |
| Career transition | Vietnam → Europe |
PART II — AZURE LANDING ZONE CHEAT SHEET
1. What is an Azure Landing Zone?
30-second answer
An Azure landing zone is a standardized foundation for running workloads in Azure.
It defines things like how environments and regions are organized, networking and connectivity, security controls, governance, identity, monitoring and shared services.
In my project, Terraform/CDKTF was used to codify those patterns and make them reusable across environments and regions[cite: 1].
Mental model
Landing Zone
├── Organization / Management
├── Identity & Access
├── Governance
├── Networking
├── Security
├── Monitoring / Operations
└── Workload foundations
2. Why use a Landing Zone?
Five keywords:
Consistency → Security → Governance → Isolation → Scalability[cite: 1]
3. Azure Hub-and-Spoke
Azure Hub-and-Spoke Diagram
HUB
┌──────────┼──────────┐
│ │ │
Firewall DNS Bastion
│
─────┼─────────────────────
│ │
Spoke 1 Spoke 2
│ │
Workload Workload
Hub
Typical shared services can include: - Firewall - DNS - Bastion - Shared connectivity - Centralized security controls[cite: 1]
Spoke
Used for: - Workload isolation - Application environments - Controlled connectivity to shared services[cite: 1]
4. Your actual Azure project
Based on your current recollection: - Customer structure varied - Typically test + production - Regions could include EMEA, America and Asia - Each region had a hub structure - Shared services included firewall, DNS, Bastion and security controls - Your main hands-on responsibility was Terraform/CDKTF module implementation[cite: 1]
5. Your role
Best answer
My main responsibility was implementing the landing zone architecture through Terraform/CDKTF[cite: 1].
I wasn't the sole architect of the entire landing zone, but I needed to understand how networking, shared services, environments and workload resources fitted together in order to implement the modules correctly[cite: 1].
6. Terraform / CDKTF
Why Terraform?
- Infrastructure as Code
- Repeatability
- Reusable modules
- Version control
- Consistency
- Easier regional expansion[cite: 1]
7. New region
Key phrase
Configuration and module composition rather than rebuilding from scratch.[cite: 1]
8. Landing Zone vs Terraform
Landing Zone vs Terraform flow
Landing Zone
↓
Architecture / operating model
↓
Networking / security / governance / identity / operations
↓
Terraform / CDKTF
↓
Implementation mechanism
9. Architecture vs implementation
Q: Did you design the architecture?
Best answer:
I was primarily on the implementation side, particularly the Terraform/CDKTF modules. However, I had to understand the architecture and dependencies because the modules had to fit into the overall landing zone design[cite: 1].
10. Troubleshooting mental model
Workload cannot reach Internet
Workload
↓
NSG
↓
Route
↓
Subnet
↓
Spoke
↓
Hub / connectivity
↓
Firewall / outbound path
↓
Internet
Workload cannot reach another workload
Source
↓
NSG
↓
Route
↓
Peering / connectivity
↓
Firewall
↓
Destination
PART III — AWS LANDING ZONE CHEAT SHEET
1. AWS equivalent mental model
AWS Landing Zone Structure
Cloud Landing Zone
│
├── Organization / Account structure
├── Identity & Access
├── Governance
├── Networking
├── Security
├── Logging / Monitoring
├── Cost management
└── Workloads
2. Azure vs AWS terminology
| Concept | Azure | AWS |
|---|---|---|
| Organization structure | Management Groups | AWS Organizations |
| Workload boundary | Subscription | AWS Account |
| Identity | Microsoft Entra ID | IAM / IAM Identity Center |
| Access control | Azure RBAC | IAM policies / roles |
| Governance | Azure Policy | SCPs + Config + other controls |
| Network | VNet | VPC |
| Regional design | Azure Region | AWS Region |
| Availability | Availability Zones | Availability Zones |
| Central networking | Hub / Hub-Spoke | Transit Gateway / centralized networking patterns |
| Firewall | Azure Firewall | AWS Network Firewall |
| DNS | Azure DNS / Private DNS | Route 53 / Route 53 Resolver |
| Bastion | Azure Bastion | No direct 1:1 equivalent; commonly SSM or bastion architecture |
| Secrets | Key Vault | Secrets Manager / SSM Parameter Store |
| Monitoring | Azure Monitor / Log Analytics | CloudWatch |
| Security posture | Defender for Cloud | Security Hub / GuardDuty / Inspector etc. |
| IaC | ARM/Bicep/Terraform/CDKTF | CloudFormation/CDK/Terraform |
| Cost | Cost Management | AWS Cost Explorer / Budgets |
| Audit | Activity Log | CloudTrail |
3. AWS Organizations
AWS Organization Structure
AWS Organization
│
├── Management Account
│
├── Organizational Units
│ │
│ ├── Security
│ ├── Infrastructure
│ ├── Workloads
│ └── Sandbox
│
└── AWS Accounts
├── Security
├── Log Archive
├── Network
├── Shared Services
├── Dev
└── Prod
4. AWS Hub-and-Spoke equivalent
AWS Centralized Networking Diagram
NETWORK / HUB
│
┌─────────┼─────────┐
│ │ │
Firewall DNS Shared
│ Services
─────────┼────────────────────────
│
Transit Gateway
/ centralized connectivity
│ │ │
VPC VPC VPC
Dev Prod Shared
5. SCP vs IAM
IAM
Controls what a principal can do inside an account, subject to other authorization controls[cite: 1].
SCP
Sets the maximum permissions boundary available to accounts / principals within an AWS Organization or OU[cite: 1].
SCP vs IAM Mental Model
SCP
↓
Maximum allowed boundary
IAM
↓
What the identity is actually allowed to do
6. Centralized logging
Centralized model
Account A ─┐
Account B ─┼──→ Central Log Archive
Account C ─┘
Benefits: - Central audit - Security investigation - Compliance - Incident response - Reduced risk of logs being modified/deleted locally[cite: 1]
7. AWS security model
Security Layer Framework
Identity
↓
Preventive controls
↓
Network controls
↓
Detection
↓
Logging
↓
Response
8. AWS new-region expansion
Conceptual Expansion
Existing modules
↓
Region-specific configuration
↓
Required resources
↓
Deployment
9. AWS Landing Zone troubleshooting
Workload cannot reach Internet
EC2
↓
Security Group
↓
Subnet
↓
Route Table
↓
NAT Gateway / IGW
↓
Network Firewall if applicable
↓
Internet
VPC-to-VPC Troubleshooting
Source
↓
Security Group
↓
Route
↓
VPC
↓
Transit Gateway / peering
↓
Destination route
↓
Security Group
↓
Destination
10. Azure ↔ AWS architectural translation
Cross-Cloud Translation Diagram
CLOUD LANDING ZONE
│
┌────────────┴────────────┐
│ │
AZURE AWS
│ │
Management Groups Organizations
│ │
Subscriptions Accounts
│ │
VNets VPCs
│ │
Hub/Spoke Transit Gateway / VPC patterns
│ │
Azure Policy SCP / Config
│ │
Entra ID / RBAC IAM / Identity Center
│ │
Key Vault KMS
│ │
Azure Monitor CloudWatch
│ │
Defender Security Hub / GuardDuty
PART IV — LANDING ZONE INTERVIEW FRAMEWORK
When asked any architecture question, use:
1. Why?
What business / technical problem are we solving?[cite: 1]
2. Boundary?
What is the isolation boundary?[cite: 1]
3. Network?
How does traffic flow?[cite: 1]
4. Security?
Where are preventive and detective controls?[cite: 1]
5. Governance?
Who can deploy what, where and under which policies?[cite: 1]
6. Operations?
How do we monitor, log, backup and troubleshoot?[cite: 1]
7. Automation?
How do we reproduce it?[cite: 1]
8. Scale?
What happens when we add an application, environment, account, or region?[cite: 1]
9. Trade-offs?
What are we gaining and what complexity are we introducing?[cite: 1]
PART V — COMMON LANDING ZONE QUESTIONS
Architecture
Q1. What is a landing zone?
Standardized cloud foundation for workloads[cite: 1].
Q2. Why do we need one?
Consistency, security, governance, isolation and scalability[cite: 1].
Q3. Hub-and-spoke vs flat network?
Hub-and-spoke provides stronger separation of shared services and workloads and more controlled connectivity[cite: 1].
IaC
Q6. Why Terraform?
Repeatability, version control, reusable modules, review and automation[cite: 1].
Q7. What makes a good Terraform module?
Module design checklist
Clear interface
Reusable
Minimal hidden dependencies
Good defaults
Configurable
Versioned
Testable
Documented
Q8. How do you avoid copy/paste Terraform?
Reusable modules + variables + composition + environment/region-specific configuration[cite: 1].
Security
Q9. How do you secure a landing zone?
Security layers
Identity
+
Network
+
Governance
+
Encryption
+
Logging
+
Detection
+
Least privilege
PART VI — FINAL MEMORY MAP
When you hear LANDING ZONE, think:
Landing Zone Memory Map
LANDING ZONE
│
┌──────────────┼──────────────┐
│ │ │
BOUNDARY NETWORK IDENTITY
│ │ │
Account/Sub Hub/VPC RBAC/IAM
Subscription Spoke/VNet
│ │
└──────────────┼──────────────┘
│
GOVERNANCE
│
Policy / SCP / Config
│
SECURITY
│
Firewall / KMS / WAF
│
OPERATIONS
│
Logs / Monitoring / DR
│
IaC
│
Terraform / CDKTF
│
SCALE
│
Environment / Region / App
The one sentence to remember
A landing zone is a standardized, governed and secure cloud foundation; IaC is how we make that foundation repeatable.[cite: 1]