Interview Preparation
Comprehensive interview questions: beginner fundamentals, intermediate concepts, and real-world scenario-based questions with detailed answers.
🎯 Beginner Questions (Conceptual Foundation)
Q1: What is the shared responsibility model in Azure?
A: Microsoft secures the cloud infrastructure (data centers, networks, hypervisor). You secure resources running on Azure (identity, applications, data, network security). It's not "Azure secures everything" or "You secure everything"—it's both, at different layers.
A: Microsoft secures the cloud infrastructure (data centers, networks, hypervisor). You secure resources running on Azure (identity, applications, data, network security). It's not "Azure secures everything" or "You secure everything"—it's both, at different layers.
Q2: What's the difference between authentication and authorization?
A: Authentication answers "Who are you?" (prove identity via password/MFA). Authorization answers "What can you do?" (RBAC rules determine permissions).
A: Authentication answers "Who are you?" (prove identity via password/MFA). Authorization answers "What can you do?" (RBAC rules determine permissions).
Q3: What is MFA and why is it important?
A: Multi-Factor Authentication requires two proof methods (something you know like password, something you have like phone). Critical because passwords alone are vulnerable to phishing, leaks. MFA adds a second barrier.
A: Multi-Factor Authentication requires two proof methods (something you know like password, something you have like phone). Critical because passwords alone are vulnerable to phishing, leaks. MFA adds a second barrier.
Q4: Why should you use Azure Key Vault instead of hardcoding secrets?
A: Hardcoded secrets are exposed in git history, config files, and logs. Key Vault encrypts, audits access, rotates automatically. Apps request secrets at runtime—no human sees them.
A: Hardcoded secrets are exposed in git history, config files, and logs. Key Vault encrypts, audits access, rotates automatically. Apps request secrets at runtime—no human sees them.
Q5: Explain Zero Trust architecture in one sentence.
A: Never trust any access request by default; verify every user, device, and request before granting permissions, even inside internal networks.
A: Never trust any access request by default; verify every user, device, and request before granting permissions, even inside internal networks.
🎓 Intermediate Questions (Deeper Understanding)
Q6: What's the difference between an NSG and Azure Firewall?
A: NSG is a stateless Layer 4 firewall at VM/subnet level (controls ports/protocols). Firewall is a stateful, managed service at VNet/hub level (app-layer filtering, threat intelligence, centralized policy). NSG for simple rules, Firewall for complex scenarios.
A: NSG is a stateless Layer 4 firewall at VM/subnet level (controls ports/protocols). Firewall is a stateful, managed service at VNet/hub level (app-layer filtering, threat intelligence, centralized policy). NSG for simple rules, Firewall for complex scenarios.
Q7: Explain RBAC scope hierarchy and why it matters.
A: Hierarchy is Management Group > Subscription > Resource Group > Resource. Lower scope = more restrictive. Always assign at the most restrictive scope (resource or RG, not subscription) to follow least privilege and limit blast radius if credentials are compromised.
A: Hierarchy is Management Group > Subscription > Resource Group > Resource. Lower scope = more restrictive. Always assign at the most restrictive scope (resource or RG, not subscription) to follow least privilege and limit blast radius if credentials are compromised.
Q8: What's a managed identity and why use it over service principals with passwords?
A: Managed identity is an Azure-managed credential (no password to manage/rotate). Azure automatically handles authentication/rotation. Safer than service principals with passwords (which can be exposed, leaked in code). Ideal for VMs, App Services, containers.
A: Managed identity is an Azure-managed credential (no password to manage/rotate). Azure automatically handles authentication/rotation. Safer than service principals with passwords (which can be exposed, leaked in code). Ideal for VMs, App Services, containers.
Q9: Describe how Conditional Access works with an example.
A: Conditional Access dynamically enforces policies based on real-time conditions. Example: "Allow access IF user is in office AND device is compliant AND MFA is satisfied. ELSE block access." If user tries to sign in from untrusted device, policy blocks them until satisfying conditions.
A: Conditional Access dynamically enforces policies based on real-time conditions. Example: "Allow access IF user is in office AND device is compliant AND MFA is satisfied. ELSE block access." If user tries to sign in from untrusted device, policy blocks them until satisfying conditions.
Q10: What's the difference between "Audit" and "Deny" modes in Azure Policy?
A: Audit logs violations but allows resource creation (policy not enforced). Deny blocks resource creation if non-compliant (policy enforced). Audit = visibility, Deny = enforcement.
A: Audit logs violations but allows resource creation (policy not enforced). Deny blocks resource creation if non-compliant (policy enforced). Audit = visibility, Deny = enforcement.
⚡ Scenario-Based Questions (VERY IMPORTANT - Senior-Level)
⚠️ Scenario questions are critical for senior roles. Interviewers want to hear your design thinking, not just definitions.
Q11 (Scenario): Your company moves a payment processing app to Azure. It must comply with PCI-DSS. Walk me through your security design.
A:
• Identity layer: Azure AD + MFA for all admins. Manage access via groups (engineers, DBAs, operators) with least-privilege RBAC.
• Network layer: Payment app in private subnet behind LB. DB in separate subnet with NSG allowing traffic only from app subnet. Firewall rejects all non-HTTPS traffic.
• Data layer: SQL DB encrypted at rest (transparent encryption), encrypted in transit (TLS). Secrets (DB password, API keys) in Key Vault (no hardcoding).
• Monitoring: Defender for Cloud scans for PCI-DSS violations. Audit logs capture all access. Alerts sent for suspicious activity.
• Compliance: Quarterly audit reports from Defender's compliance dashboard for auditors.
A:
• Identity layer: Azure AD + MFA for all admins. Manage access via groups (engineers, DBAs, operators) with least-privilege RBAC.
• Network layer: Payment app in private subnet behind LB. DB in separate subnet with NSG allowing traffic only from app subnet. Firewall rejects all non-HTTPS traffic.
• Data layer: SQL DB encrypted at rest (transparent encryption), encrypted in transit (TLS). Secrets (DB password, API keys) in Key Vault (no hardcoding).
• Monitoring: Defender for Cloud scans for PCI-DSS violations. Audit logs capture all access. Alerts sent for suspicious activity.
• Compliance: Quarterly audit reports from Defender's compliance dashboard for auditors.
Q12 (Scenario): Your startup has 10 developers, 2 DBAs, 1 DevOps person working on production & dev environments. Design an RBAC strategy with separation of duties.
A:
• Subscriptions: Separate "prod" and "dev" subscriptions.
• Resource Groups: prod-app, prod-db, dev.
• Roles:
- Developers: "App Service Contributor" in prod-app RG, "Contributor" in dev RG (encourage testing).
- DBAs: "SQL Server Contributor" in prod-db RG only.
- DevOps: "Virtual Machine Contributor" in prod-app RG (manage infra), "Storage Contributor" in prod-app RG (logs/backups).
- Everyone: "Reader" at subscription (see costs, no modifications).
• Benefit: If developer's account is compromised, attacker can't delete DB or drop production tables.
A:
• Subscriptions: Separate "prod" and "dev" subscriptions.
• Resource Groups: prod-app, prod-db, dev.
• Roles:
- Developers: "App Service Contributor" in prod-app RG, "Contributor" in dev RG (encourage testing).
- DBAs: "SQL Server Contributor" in prod-db RG only.
- DevOps: "Virtual Machine Contributor" in prod-app RG (manage infra), "Storage Contributor" in prod-app RG (logs/backups).
- Everyone: "Reader" at subscription (see costs, no modifications).
• Benefit: If developer's account is compromised, attacker can't delete DB or drop production tables.
Q13 (Scenario): A contractor needs 1-month access to production databases to migrate data. Design this securely and outline the offboarding process.
A:
• Onboarding:
1) Create temporary user account in Azure AD (contractor@company.com).
2) Add to "Contractors" group (custom).
3) Assign "SQL Database Reader" custom role (read-only) to prod-db RG.
4) Enable Conditional Access: require MFA + managed device.
5) Set account expiration date (30 days).
• Monitoring: Audit all SQL queries accessing data. Set alerts for bulk exports.
• Offboarding: Disable account at day 30 (don't delete, keep audit trail). Revoke all role assignments.
• Why secure? Least privilege (read-only), MFA, managed device, audited, time-limited.
A:
• Onboarding:
1) Create temporary user account in Azure AD (contractor@company.com).
2) Add to "Contractors" group (custom).
3) Assign "SQL Database Reader" custom role (read-only) to prod-db RG.
4) Enable Conditional Access: require MFA + managed device.
5) Set account expiration date (30 days).
• Monitoring: Audit all SQL queries accessing data. Set alerts for bulk exports.
• Offboarding: Disable account at day 30 (don't delete, keep audit trail). Revoke all role assignments.
• Why secure? Least privilege (read-only), MFA, managed device, audited, time-limited.
Q14 (Scenario): Your app retrieves a database password from config file (currently hardcoded). Security audit found this. Migrate to Key Vault securely with zero downtime.
A:
• Phase 1 (Preparation): Create Key Vault. Store DB password as secret.
• Phase 2 (Testing in dev): Enable managed identity on dev App Service. Grant access to Vault. Update app code to retrieve from Key Vault instead of config. Test thoroughly.
• Phase 3 (Staged production rollout):
1) Enable managed identity on prod App Service.
2) Grant managed identity access to Vault.
3) Deploy updated app code (pointing to Vault) as canary (5% of instances).
4) Monitor for errors (they'll go to Vault instead of config file).
5) If successful, roll out to 100%.
6) After success, remove hardcoded password from config.
• Why this order? Code first (support both paths), identity second (managed setup), then cut over. Zero downtime because new code works, old code path still available during transition.
A:
• Phase 1 (Preparation): Create Key Vault. Store DB password as secret.
• Phase 2 (Testing in dev): Enable managed identity on dev App Service. Grant access to Vault. Update app code to retrieve from Key Vault instead of config. Test thoroughly.
• Phase 3 (Staged production rollout):
1) Enable managed identity on prod App Service.
2) Grant managed identity access to Vault.
3) Deploy updated app code (pointing to Vault) as canary (5% of instances).
4) Monitor for errors (they'll go to Vault instead of config file).
5) If successful, roll out to 100%.
6) After success, remove hardcoded password from config.
• Why this order? Code first (support both paths), identity second (managed setup), then cut over. Zero downtime because new code works, old code path still available during transition.
Q15 (Scenario): Security alerts from Defender: "SQL injection attempt detected", "Malware found on VM", "Suspicious account creation." Prioritize & respond.
A:
• Priority 1 (Malware): Immediately isolate VM (disconnect from network via NSG rule). Verify if actual infection or false positive (Defender logs). If confirmed: snapshot VM (for forensics), terminate instance, patch with latest updates, redeploy.
• Priority 2 (SQL injection): Check logs for unauthorized database access. If successful: rotate credentials, review queries for vulnerability (parameterized queries?), update app code, scan for backdoors, notify customers of potential data exposure (if applicable).
• Priority 3 (Suspicious account): Check Azure AD logs for account activity. If unauthorized: disable account, audit credentials (where used?), check what commands ran, wipe credentials from systems.
• Post-incident: Document timeline, root cause, recovery steps. Conduct postmortem with team. Update policies (e.g., "enforce parameter queries", "auto-disable unusual accounts").
A:
• Priority 1 (Malware): Immediately isolate VM (disconnect from network via NSG rule). Verify if actual infection or false positive (Defender logs). If confirmed: snapshot VM (for forensics), terminate instance, patch with latest updates, redeploy.
• Priority 2 (SQL injection): Check logs for unauthorized database access. If successful: rotate credentials, review queries for vulnerability (parameterized queries?), update app code, scan for backdoors, notify customers of potential data exposure (if applicable).
• Priority 3 (Suspicious account): Check Azure AD logs for account activity. If unauthorized: disable account, audit credentials (where used?), check what commands ran, wipe credentials from systems.
• Post-incident: Document timeline, root cause, recovery steps. Conduct postmortem with team. Update policies (e.g., "enforce parameter queries", "auto-disable unusual accounts").
🎯 Quick Revision Checklist
- ☐ Shared Responsibility Model: Microsoft owns infrastructure, you own identity + apps + data
- ☐ Defense in Depth: Multiple security layers (perimeter, network, app, data)
- ☐ Zero Trust: Never trust, always verify
- ☐ Identity & Access: Azure AD, MFA, RBAC, Conditional Access = foundation of all security
- ☐ Network Security: NSGs, Firewalls, private endpoints, segmentation
- ☐ Secrets: Never hardcode—use Key Vault + managed identity
- ☐ Monitoring: Defender for Cloud detects threats, policies enforce compliance
- ☐ Troubleshooting: Check RBAC → network → auth → logs (systematic approach)
- ☐ Scenarios: Think design (least privilege, isolation, audit, recovery)
Interview Tips
- Listen carefully: Some questions test depth (explain RBAC role inheritance), others test breadth (name 5 security services).
- Use frameworks: "First I'd check RBAC, then network, then logs" (systematic approach impresses).
- Real-world examples: "I once debugged access denied by checking role assignments, discovery user was in wrong RG scope" (experience = credibility).
- Security mindset: Always think about least privilege, isolation, audit trails, recovery.
- Ask clarifying questions: "Is this for a startup or enterprise? Compliant with PCI-DSS or HIPAA?" (context matters).