Yeah, this is just showing us the permitted operations, the key identifier, etc.
It's really not trivial to use an Azure‑based BitLocker key on‑prem.
You can do it.
Check the exercise files and read in the Microsoft
Azure Docs and there's instructions.
It's beyond our scope for the purpose of the exam though.
But what I want you to know is that deleting a resource,
we got an error here on updating the disk encryption settings.
Oh, I might want to take a look at that after I finish recording.
But anyway,
to complete my thought here is if I go back to the keyvault
Settings and go back to one of the top levels,
like in this case the Keys,
notice that there's essentially a recycle bin for each service,
and there's a retention period there such that even
deleted artifacts will be protected, and you can,
when you create your key vault,
set a flag called purge protection that would prevent anybody from
purging deleted items out of your Recycle Bin.
Now lastly,
I want you to have the comfort that even if one of your
colleagues were to delete an entire EVault,
you can manage deleted vaults, and you can recover the entire vault,
as well as its artifact.
So these are all things that hopefully give you some comfort as a
customer knowing that there's those layers of protection so that when
you're called in to troubleshoot an encryption issue,
you have the surrounding context because definitely Azure encryption and
Azure VM encryption is dependent upon Azure Key Vault,
pretty fundamentally.
Okay, last thing we'll do here is we'll head on over to Network Watcher,
if I can type correctly.
And in terms of troubleshooting network access on your VMs,
I'd mentioned that there's this tool called NSG diagnostic.
So we can dial up our virtual machine, so let's find that monitorvm,
and we can model inbound or outbound traffic.
Let's say we're modeling inbound traffic on TCP 443.
The Source would be, let's say, my current machine.
Let me go to ipaddress.com to try to grab the public
IP of the machine I'm teaching on.
Now the Destination here, this is showing a public IP,
so that gives me some troubleshooting knowledge right there that my
Azure VM actually has a public internet IP on it,
which you may not want for security reasons.
Interesting!
Though once we've modeled that inbound or outbound traffic flow,
by the way,
the source and destination IP addresses don't have to be
public internet accessible addresses,
you could be testing NSG rules between virtual machines in
the same VNet or on peered VNets as well,
though we would expect that that's denied.
Why?
Because of this particular NSG, all right?
Another NSG‑related Network Watcher tool would be,
let's see here, Effective security rules.
Let's take a look at that one next.
Once again,
we can load up our virtual machine and that pops in the network interface.
It's basically just going to report on any associated network security groups.
This can give you some valuable troubleshooting insight.
Maybe there's more than one NSG.
In this case I learned something new in terms of instead
of an NSG applying from the subnet, which is normally how I design this,
this particular VM has an NSG attached to the network interface.
I may very well not want that and want to shift that around a bit, you see?
So,
these are all ways to gain more visibility into your
Azure VMs for performance tuning, for troubleshooting,
for security optimization,
and to compensate for the fact that you can't touch your machines like you can when you're running on‑premises infrastructure.