Career relevance: Week 6

Indicative as of June 2026: see Sources for current numbers.

This page answers two questions students ask every week: why am I learning this, and how does it help me find a job?

It is scoped to Week 6 content: cloud fundamentals on Azure, the az CLI, Azure Blob Storage, Azure Database for PostgreSQL, and serverless container jobs on Azure Container Apps. Other weeks' career pages each cover their week's tools. Generic NL junior-data career content lives in one shared page across the curriculum and is not repeated here.

The numbers below are a rough reading of public NL postings as of June 2026. They are indicative, not measured. Placeholders are marked ~XX% for future replacement with measured percentages.

How cloud and Azure show up in NL postings

Cloud is the default in NL data teams. Almost every posting names a provider, and Azure leads in enterprise and government because so many Dutch organizations already run Microsoft 365 and Active Directory. The specific service names (Blob Storage, managed Postgres, Container Apps) appear most often in engineer-track roles; analyst roles touch the cloud through a query editor and rarely provision anything themselves.

Role	How often you touch this	What they expect
Data Engineer (DE)	~80%	Hands-on, daily. "Azure (or AWS/GCP)", "deploy containerized pipelines", "object storage", "managed Postgres", "comfortable in the cloud CLI". Week 6 maps directly to these requirements.
Analytics Engineer (AE)	~45%	Reads from cloud storage and a cloud warehouse, deploys dbt to a managed runner. Provisions less infrastructure than a DE but must connect to and reason about managed services.
Data Scientist (DS)	~40%	ML-platform-adjacent roles deploy training and scoring jobs to managed compute and read features from object storage. Pure research roles touch the cloud mostly through notebooks.
Data Analyst (DA)	~15%	Rarely provisions resources. Connects to a managed database through a SQL editor or BI tool; the cloud is invisible plumbing behind the connection string.

The directional shape: DE roles treat cloud deployment as table-stakes; AE and ML roles connect to managed services without owning them; DA roles consume the cloud through a connection string they were handed. If you are aiming at DE, this week is the floor that separates "runs a pipeline on my laptop" from "ships a pipeline to the cloud."

The Week 6 stack vs NL alternatives

Concept	Tool taught	Common NL alternatives	Practical implication
Cloud provider	Microsoft Azure	AWS (large at tech scale-ups and secondary cloud in enterprises), Google Cloud Platform (analytics-heavy and ML shops)	The three providers offer the same building blocks. Naming and CLIs differ; the concepts (identity, resource grouping, regions, managed services) transfer directly.
Object storage	Azure Blob Storage	Amazon S3, Google Cloud Storage, MinIO (self-hosted, S3-compatible)	All four use the same "put objects in, get objects out" model. The SDK class names and auth differ, but the extract-to-blob pattern is identical.
Managed Postgres	Azure Database for PostgreSQL	AWS RDS / Aurora, Google Cloud SQL, Supabase (managed Postgres for smaller teams)	Same Postgres engine and the same SQL underneath. The connection string and the provisioning console differ; your `psycopg2` code does not.
Serverless container jobs	Azure Container Apps Jobs	AWS Fargate (and ECS scheduled tasks), Google Cloud Run jobs	All run a container on a trigger and bill per second of execution. You define an image, a trigger, and env vars; the platform handles provisioning and teardown.
Cloud CLI	`az`	`aws` CLI, `gcloud`	Every provider follows `<cli> <service> <action> --flags`. Learn one and the muscle memory carries: you look up the new noun, not a new way of thinking.

What this means for your CV: name the tools you used, but frame the skills as transferable. "Deployed a containerized pipeline to Azure Container Apps Jobs, writing to Blob Storage and a managed PostgreSQL database" communicates the skills regardless of which cloud the interviewer runs.

Junior vs medior expectations

Postings phrase the expectation at three levels:

Junior: "Comfortable in a cloud environment", "has deployed a container to the cloud", "can connect to a managed database", "reads logs to debug a failed run". Your Week 6 work clears this bar: a container job pulling an image from ACR, writing to Blob Storage and managed Postgres, with logs you can read in the portal or CLI.
Medior: "Owns networking and identity for the team's resources", "manages cost governance", "writes infrastructure as code". Goes beyond Week 6: configuring private networking and Managed Identity instead of connection strings, setting budgets and alerts across many resources, and provisioning the infrastructure (the resource groups, storage accounts, and databases your teacher pre-created for you) through Bicep or Terraform rather than the portal.
Senior / Lead: "Designs the cloud landing zone", "sets the multi-environment and security strategy", "owns the FinOps practice". Architecture-level decisions about subscriptions, identity boundaries, and cost allocation across the whole organization.

Week 6 is the foundation for the medior expectation. The hands-on container job, the managed-Postgres connection, and reading execution logs give you the vocabulary and the artifact to demonstrate in an interview.

How Week 6 work signals on a CV

Strong line a student can copy-adapt:

Deployed a containerized Python ingestion pipeline to Azure Container Apps Jobs: the job pulls its image from Azure Container Registry, runs on a manual and scheduled trigger with a replica timeout, writes raw output as JSON blobs to Azure Blob Storage, and upserts results into a managed Azure Database for PostgreSQL instance, with configuration passed as environment variables and run status verified through the execution log.

Recruiter keywords this carries: Azure, Azure Container Apps Jobs, Azure Container Registry, Azure Blob Storage, object storage, Azure Database for PostgreSQL, managed database, psycopg2, serverless, az CLI, containerized pipeline.

Weaker alternative for contrast (avoid):

Used Azure to run my pipeline in the cloud.

The weaker version is true but says nothing a student who clicked through the portal once could not also say. The strong version names the specific services, the specific trigger and timeout choices, and the end-to-end data path.

Interview phrasing for the Week 6 assignment

Three sentences that cover the assignment cleanly when an interviewer asks "tell me about a project you have built":

"I deployed a Python ingestion pipeline as an Azure Container Apps Job. The job pulls my image from Azure Container Registry and runs on demand or on a cron schedule, then exits, so I pay only for the seconds it runs instead of keeping a VM on around the clock."
"The pipeline writes its raw output as JSON blobs to Azure Blob Storage and upserts the parsed records into a managed Azure Database for PostgreSQL instance using psycopg2 with ON CONFLICT ... DO UPDATE, so re-running the job on the same data updates rows instead of duplicating them."
"I passed the connection strings as environment variables on the job and set a replica timeout so a hung run gets killed instead of billing forever. When a run failed I read the execution log through the az CLI to find the image-pull or connection error, fixed it, and re-ran."

Two honest follow-ups if asked "what would you do differently?":

"I passed connection strings as plain environment variables. In production I'd store them in Azure Key Vault and use a Managed Identity so the container never handles a raw credential, which is what the track covers in a later week."
"My pipeline user connected with a password over SSL. For a real deployment I'd lock down the database with private networking instead of a public endpoint, and provision the whole resource group through infrastructure as code so the setup is reproducible rather than clicked together in the portal."

What Week 6 does not make you

Week 6 is the deployment-and-connection layer, not the platform layer. After this week you are not yet:

A cloud architect. You deploy into resource groups and connect to managed services your teacher provisioned. Designing subscriptions, identity boundaries, networking topology, and multi-environment promotion is a separate discipline that needs operating experience this track does not give.
A DevOps or platform engineer. You run one pipeline's job and read its logs. Platform engineers own the infrastructure-as-code, the secret-rotation policy, and the cost-governance guardrails across the whole team. That scope goes well beyond this week.
A cloud cost or security specialist. You learned to pick a small SKU, stop idle compute, and keep secrets out of code. Production FinOps (cost allocation, reservations, anomaly detection) and cloud security (private endpoints, Managed Identity, least-privilege role design at scale) are deeper specialties.

These are the senior-shaped skills the chapter does not yet make you qualified for. Naming them honestly in an interview is more impressive than overclaiming.

Sources

Indeed.nl "Azure data engineer" search: for posting frequency and phrasing samples (NL postings as of June 2026).
LinkedIn NL Data Engineer postings: role-specific posting volume and cloud-provider mentions.
Stack Overflow Developer Survey: Cloud Platforms: Azure, AWS, and GCP adoption signals among professional developers.
ACM market study on cloud services: NL market-share context for why this track teaches Azure first.

Mark this page indicative, not statistical. Numbers will be replaced with measured percentages once the postings-crawler project ships.

<aside> 💭 For generic NL junior data-career content (salary bands, day-to-day work, what employers do not expect from any junior), one shared page across all weeks is the right home. That page does not exist yet; for now, treat this page as Week-6-specific only.

</aside>

The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*

CC BY-NC-SA 4.0 Icons

Built with ❤️ by the HackYourFuture community · Thank you, contributors

Found a mistake or have a suggestion? Let us know in the feedback form.