PostgreSQL is running.

The private networking exists.

Public access is disabled exactly as requested.

But your application is down.

Before the change, your application was able to reach PostgreSQL.

Now the database is private.

So the backend needs a private network path to the database and it needs to resolve the database hostname correctly.

The flow should look something like this:

But imagine we missed one small thing.

The Private DNS Zone exists.

But it isn't linked to the VNet being used by the application.

Now:

That's it.

One missing piece.

Your resources can exist.

Your Terraform can apply successfully.

Azure can happily accept the configuration.

And your application can still be completely broken.

This is why I keep saying that learning Terraform syntax is the easy part.

Creating a Private Endpoint is also not that difficult.

You can search the documentation and create one.

The actual skill is understanding what happens to the complete system when you make that change.

You made one change:

Public database → Private database

But now you're dealing with networking, DNS, routing, security and application connectivity.

Everything starts coming together.

Personally, I wouldn't immediately start changing Terraform randomly.

I'd first check:

What is the database hostname resolving to from the application environment?

Then I'd follow the path.

Is the backend integrated with the correct VNet?

Is the Private DNS Zone linked?

Does the hostname resolve to the expected private IP?

Can the backend actually reach that IP?

Is anything blocking the traffic?

Once you understand the complete path, troubleshooting becomes much easier.

And this is the part that is difficult to learn by only watching videos.

DEVOPS-032 — Remove Public Database Access

Security has identified that the PostgreSQL database is accessible through a public network path.

Remove public database connectivity without affecting the application.

Requirements

• PostgreSQL must not be publicly accessible
• Backend must continue connecting to PostgreSQL
• Database traffic must use the private network
• DNS resolution must work correctly
• Existing application functionality must not be affected

Validation

Prove that the backend can still communicate with PostgreSQL and that the database is no longer accessible through the public network.

And that's all I give you.

No video showing you what to create.

No step-by-step instructions.

You have to figure it out.

What architecture would you use?

What would you change?

How would you test it?

How would you prove that the traffic is actually private?

And when you're done, you don't just tell me:

“It works.”

Because I'm going to ask you:

Why did you do it this way?

What happens to DNS?

What happens if I remove the DNS link?

How did you validate that public access is actually disabled?

If the backend stops connecting tomorrow, where would you start troubleshooting?

That's the kind of discussion I want.

I'm starting the next batch now.

The first live review session is on 5 October.

This isn't for someone starting DevOps from zero.

If you already understand the basics of Linux, Git, Docker, networking and cloud, but you feel like:

“I know all these things individually, but I don't know how they actually come together in a real project.”

That's exactly what I want to work on.

I give you the ticket.

You do the work yourself.

Then we meet live three times a week and you explain your decisions.

I'll challenge them.

Sometimes I'll agree with you.

Sometimes I'll ask why you didn't choose another approach.

Sometimes something won't work and we'll troubleshoot it.

That's the whole point.

This is not another 30 days of watching videos.

If that's the kind of hands-on experience you're looking for:

First live review: 5 October

See you,

Arbaz
Learn With DevOps Engineer