Hands-onPractical

Real-world Scenarios

Implement security in realistic scenarios: securing applications with RBAC, restricting access with Conditional Access, managing secrets in Key Vault, and detecting threats with Defender.

Scenario 1: Securing a Web App with RBAC

Setup

Team: 3 developers, 2 DevOps engineers, 1 DBA working on production e-commerce app.

Goal: Implement least-privilege access.

Solution

# Create resource groups
az group create --name prodApp --location eastus
az group create --name prodDB --location eastus

# Assign Developers: App Service Contributor (app RG only)
az role assignment create \
 --assignee "${devGroupId}" \
 --role "App Service Contributor" \
 --resource-group prodApp

# Assign DevOps: VM Contributor (app RG) + Storage Contributor (app RG)
az role assignment create \
 --assignee "${devopsGroupId}" \
 --role "Virtual Machine Contributor" \
 --resource-group prodApp
az role assignment create \
 --assignee "${devopsGroupId}" \
 --role "Storage Account Contributor" \
 --resource-group prodApp

# Assign DBA: SQL Server Contributor (DB RG only)
az role assignment create \
 --assignee "${dbaGroupId}" \
 --role "SQL Server Contributor" \
 --resource-group prodDB

# All teams: Reader at subscription (view costs, compliance)
az role assignment create \
 --assignee "${devGroupId}" \
 --role "Reader" \
 --scope /subscriptions/{subscriptionId}
az role assignment create \
 --assignee "${devopsGroupId}" \
 --role "Reader" \
 --scope /subscriptions/{subscriptionId}
az role assignment create \
 --assignee "${dbaGroupId}" \
 --role "Reader" \
 --scope /subscriptions/{subscriptionId}

Result: If dev account is compromised, attacker can modify app but not database or infrastructure.

Scenario 2: Restricting Access with Conditional Access

Setup

Policy: Executive team accesses sensitive data. Must authenticate with MFA + be on managed device.

Solution (Azure Portal Manual)

Conditional Access policies are typically managed in Azure AD Portal (manual), not CLI. Here's the configuration:

Users/Groups: "Executive" group
Conditions:

Grant access IF device is compliant
Grant access IF MFA is satisfied
Deny access IF not from trusted location

Result: Executive can access portal only from managed device + MFA + office network

Scenario 3: Managing Secrets in Key Vault

Setup

App needs: Database password, 3rd-party API keys, TLS certificate.

Solution

# Create Key Vault
az keyvault create \
 --name prodKeyVault \
 --resource-group prodApp \
 --enable-rbac-authorization

# Store secrets
az keyvault secret set \
 --vault-name prodKeyVault \
 --name dbPassword \
 --value "${DB_PASSWORD}"
az keyvault secret set \
 --vault-name prodKeyVault \
 --name stripeApiKey \
 --value "${STRIPE_API_KEY}"

# Store certificate
az keyvault certificate import \
 --vault-name prodKeyVault \
 --name webAppCert \
 --file /path/to/cert.pfx

# Enable App Service managed identity
az app service identity assign \
 --name myAppService \
 --resource-group prodApp

# Grant App Service read access to Vault
appServicePrincipalId=$(az app service identity show \
 --name myAppService \
 --resource-group prodApp \
 --query principalId --output tsv)

az role assignment create \
 --assignee "${appServicePrincipalId}" \
 --role "Key Vault Secrets Officer" \
 --scope /subscriptions/{subId}/resourceGroups/prodApp/providers/Microsoft.KeyVault/vaults/prodKeyVault

App code (C# example):

var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri("https://prodKeyVault.vault.azure.net"), credential);
KeyVaultSecret secret = client.GetSecret("dbPassword");
string dbPassword = secret.Value;

Result: No secrets in code or config. App requests at runtime, Vault audits access.

Scenario 4: Detecting Threats with Defender

Setup

Goal: Detect and respond to suspicious activity (brute force, malware, DDoS).

Solution

Enable Defender for Cloud (Standard tier)
Enable Defender for Servers (includes VM vulnerability scanning)
Enable Defender for SQL (scans databases)
Set up alerts to email security team
Route to Azure Sentinel (SIEM) for correlation

Example alert: "10 failed SSH login attempts from IP 203.0.113.45 in 5 minutes" → Defender marks High severity → Alert sent → Team reviews logs → Blocks IP via NSG/Firewall

Summary & Lab Steps

Lab 1: Create resource groups, assign RBAC roles to teams, verify least privilege.
Lab 2: Configure Conditional Access policy (MFA + managed device requirement).
Lab 3: Create Key Vault, store secrets, enable managed identity, grant access.
Lab 4: Enable Defender for Cloud, review alerts, create action plan.

Interview Questions

Q (Scenario): You have 5 developers, 2 DBAs, 1 DevOps person. How would you design RBAC?
A: Create groups: Developers, DBAs, DevOps. Assign roles: Developers = App Service Contributor (app RG), DBAs = SQL Contributor (DB RG), DevOps = VM + Storage Contributor. All = Reader at subscription.

Q (Scenario): API keys are currently hardcoded in environment variables. Migrate to Key Vault securely.
A: 1) Create Key V ault 2) Import API keys as secrets 3) Enable managed identity on app 4) Grant managed identity secret access 5) Update app code to call Key Vault API 6) Test in dev, then prod 7) Remove hardcoded keys.

Q (Scenario): Defender alerts: "SQL injection attempt detected on database." What's your response plan?
A: 1) Acknowledge alert 2) Check logs for affected queries 3) Verify if injection succeeded (check for unauthorized data access) 4) If compromised, rotate credentials 5) Review app code for parameterized queries 6) Update WAF rules 7) Document incident.