One Proof Project for Every Cloud Role

This page is role-specific on purpose. If you have no role in mind yet, start somewhere else.

🧭 How to pick

Find the row that matches the job you have today, not the one that sounds best. The skills overlap more than the job titles suggest, so you can switch later.

✅ What makes a project count

Three tests. A project has to pass all three before it goes on your resume.

And the things people often submit that do not count on their own:

Every project below is one system for one role. Each has a step that only exists to produce evidence: a blocked deployment, a triggered rule, a rollback, a rerun. That step is the one interviewers ask about. Do not skip it.

🔐 Identity: Conditional Access, rolled out safely

Proves: you can change how a whole organisation signs in without locking anyone out.

Step 3 is the part that proves judgement. With sign-in logs going to a Log Analytics workspace:

SigninLogs
| where TimeGenerated > ago(7d)
| mv-expand Policy = ConditionalAccessPolicies
| where tostring(Policy.result) startswith "reportOnly"
| summarize SignIns = count() by PolicyName = tostring(Policy.displayName), Result = tostring(Policy.result)
| order by PolicyName asc, SignIns desc

reportOnlyFailure rows are the people to fix before you switch it on.

Done looks like

• Two break-glass accounts, excluded from Conditional Access
• The MFA policy ran in report-only for at least a week
• A query or workbook showing what report-only caught
• The policy is On, with the gaps fixed first
• No standing admin roles: everything privileged is eligible in PIM
• A write-up exists

Evidence to save

Labs that cover the pieces

Three interview questions this lets you answer

1. "How would you roll out MFA for everyone without locking anyone out on day one?"
2. "What is a break-glass account, and how do you stop it becoming a risk of its own?"
3. "Why make admin roles eligible in PIM instead of just assigning them?"

🛡️ Cloud platform security: no public endpoints

Proves: you can lock data services off the internet and stop the next person from undoing it.

Steps 4 and 5 are the screenshot that does the talking:

az policy assignment create \
  --name deny-public-storage \
  --policy b2982f36-99f2-4db5-8eff-283140c09693 \
  --scope "/subscriptions/<subscription-id>/resourceGroups/rg-sec-proof" \
  --params '{ "effect": { "value": "Deny" } }'
 
# Should fail with RequestDisallowedByPolicy
az storage account create \
  --name stpublictest$RANDOM \
  --resource-group rg-sec-proof \
  --public-network-access Enabled

Policy assignments can take a few minutes to apply. If the test deployment succeeds straight away, wait and retry before you debug the policy.

Done looks like

• Storage, SQL and Key Vault each have a private endpoint and DNS that resolves to it
• Public network access is disabled on all three
• A policy assignment with the Deny effect
• A real deployment blocked by that policy
• Defender for Cloud recommendations recorded before and after
• A write-up exists

Evidence to save

Labs that cover the pieces

Hands-on LabCloudlearn.io

Azure Private Endpoints: Lock Down Your Storage and SQL

The middle of this project in a real Azure environment: private endpoints, private DNS and public access turned off.

labs.cloudlearn.ioStart the lab

Three interview questions this lets you answer

1. "How do you make sure a storage account cannot be reached from the internet, and how would you prove it?"
2. "What is the difference between an Audit policy and a Deny policy, and when do you use each?"
3. "After you add a private endpoint, how does the app still find the service by name?"

🚨 Security operations: one detection, one hunt

Proves: you can write detections and hunt by hand, not only work the queue someone else built.

Learn Sentinel in the Defender portal from day one. After March 31, 2027 it is no longer supported in the Azure portal.

A good first hunt is password spraying, one IP failing sign-ins against many accounts. Write your own before you look at this one:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType != "0"
| summarize FailedAccounts = dcount(UserPrincipalName), Attempts = count() by IPAddress
| where FailedAccounts >= 10
| order by FailedAccounts desc

Done looks like

• Workspace onboarded to the Defender portal
• At least one data connector sending data
• One custom analytics rule, with an incident you caused yourself
• One hunt written by hand and documented
• One automation rule firing on that incident
• A write-up exists

Evidence to save

Labs that cover the pieces

Three interview questions this lets you answer

1. "Walk me through a detection you wrote. How did you know it actually worked?"
2. "How would you look for password spraying in our sign-in logs?"
3. "One of your rules is flooding the queue with false positives. What do you do?"

🛣️ Platform engineer: the paved road

Proves: you can build a path to production that other engineers use without asking you, and show that it helped.

DevOps engineers usually start at step 2. QA engineers start at step 1. Network engineers learn Git and pull requests first, then step 1.

Step 1 is not done until you have rolled back. In Container Apps with multiple-revision mode:

az containerapp ingress traffic set \
  --name app-paved-road \
  --resource-group rg-platform-proof \
  --revision-weight app-paved-road--v1=100 app-paved-road--v2=0

Step 4 starts on Warn, then moves to Enforce once you have fixed what the warnings showed:

az aks safeguards update \
  --resource-group rg-platform-proof \
  --name aks-platform-proof \
  --level Enforce

Two services older roadmaps still recommend: Azure Deployment Environments retires on February 22, 2027, and AWS Proton support ended on October 7, 2026. This project uses neither. Details are in Microsoft's Deployment Environments retirement guide.

Done looks like

• One app deploys to Container Apps from a GitHub Actions pipeline
• A broken release rolled back on purpose
• The infrastructure is a versioned Bicep module in a private registry
• Someone else deployed it using only your README
• Changes reach the AKS cluster only through Git
• Deployment safeguards on Enforce, with a blocked deployment captured
• An Azure Policy denies at least one insecure Azure resource
• A Backstage template creates a new service from one form
• DORA metrics recorded before and after
• Feedback from one developer, and one change you made because of it

Evidence to save

Labs that cover the pieces

Steps 4 to 6 have no CloudLearn lab yet. Use the AKS deployment safeguards docs for step 4, and the Backstage and DORA documentation for steps 5 and 6.

Three interview questions this lets you answer

1. "A release just went out broken. Talk me through how you get users back on the last good version."
2. "How do you get teams to use the platform instead of building their own way around it?"
3. "How would you know whether your platform actually made delivery better?"

🥇 Data engineer: one medallion project

Proves: you can take messy data from raw to useful, on a schedule, and explain every layer.

Pick one platform first. Count which of Microsoft Fabric or Azure Databricks the data engineering job ads near you name more often. The five skills underneath carry across either way.

Once the first load works, make silver incremental with MERGE so a rerun updates changed rows instead of rewriting everything. The core of it, as Spark SQL in the same notebook:

MERGE INTO silver_trips AS target
USING (
  SELECT trip_id, trip_date, fare FROM (
    SELECT trip_id,
           to_date(pickup_datetime) AS trip_date,
           CAST(fare AS DECIMAL(10,2)) AS fare,
           ROW_NUMBER() OVER (PARTITION BY trip_id ORDER BY _ingested_at DESC) AS rn
    FROM bronze_trips
    WHERE _ingested_at > current_timestamp() - INTERVAL 1 DAY AND fare >= 0
  ) WHERE rn = 1
) AS source
ON target.trip_id = source.trip_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

Done looks like

• Bronze, silver and gold tables exist and are rebuilt from bronze alone
• Silver loads incrementally with MERGE, and a rerun does not duplicate rows
• The flow runs on a schedule without you
• One column is hidden from a reader role (OneLake security in Fabric, a column mask in Unity Catalog)
• Notebooks and pipeline definitions are in Git
• A write-up exists

Evidence to save

Labs that cover the pieces

CloudLearn has no Fabric or Databricks lab yet. Use the Fabric trial or Databricks Free Edition for the platform. The labs cover the Azure pieces underneath every data platform:

Three interview questions this lets you answer

1. "Why keep a bronze layer at all if you are going to clean the data anyway?"
2. "Your pipeline failed halfway and you rerun it. How do you make sure you do not end up with duplicate rows?"
3. "How would you stop analysts from seeing one sensitive column without building a second copy of the table?"

🤖 AI cloud developer: vector search with no keys

Proves: you can build the back end around a model: the container, the vector store, the queue, the identity and the monitoring. AI-200 does not test training a model, so neither does this project.

Every service here is in the AI-200 skills outline. The app is a small "search my documents" API in Python. Which embedding model you call is your choice. The project is everything around it.

Steps 3 and 6, the parts that define "done":

# Turn on vector search for the account (can take about 15 minutes)
az cosmosdb update \
  --resource-group rg-ai-proof \
  --name cosmos-ai-proof \
  --capabilities EnableNoSQLVectorSearch
 
# Give the Container App's managed identity read and write on the data
az cosmosdb sql role assignment create \
  --account-name cosmos-ai-proof \
  --resource-group rg-ai-proof \
  --role-definition-id 00000000-0000-0000-0000-000000000002 \
  --scope "/" \
  --principal-id <app-principal-id>

The search query. Always use TOP N, or the query costs more Request Units than it needs to:

SELECT TOP 5 c.title, VectorDistance(c.embedding, @queryVector) AS score
FROM c
ORDER BY VectorDistance(c.embedding, @queryVector)

Once it works, the stretch goal is the comparison AI-200 actually asks about: try the same search in PostgreSQL with pgvector or in Azure Managed Redis, and write down when you would pick each.

Done looks like

• Image built with ACR Tasks and running in Container Apps
• A document dropped on the queue ends up searchable, with the worker scaling up from zero and back
• The search endpoint returns ranked results from a VectorDistance query
• No connection string or account key in app settings or the repo
• One request traced end to end in Application Insights
• A KQL query you wrote yourself that answers "what is slow"
• A write-up exists

Evidence to save

Labs that cover the pieces

The vector search step itself has no CloudLearn lab yet. Microsoft's vector search in Cosmos DB for NoSQL page and the Python index and query guide cover it.

Hands-on LabCloudlearn.io

Container Apps KEDA Scaling with Service Bus Queue Workers

The ingestion worker from step 4: a queue fills up, the app scales out from zero, then back down.

labs.cloudlearn.ioStart the lab

Three interview questions this lets you answer

1. "Why did you store the vectors in Cosmos DB and not PostgreSQL or Redis?"
2. "How does your app get into the database without a key or a connection string?"
3. "A user says search is slow. How do you find out which part is slow?"

⚠️ Where this goes wrong

Pick your row, build the one project, tick every box, then book the exam. Come back to this page with the checklist open, not to read it again.