1
00:00:00,940 --> 00:00:07,320
Yeah, this is just showing us the permitted operations, the key identifier, etc.

2
00:00:07,320 --> 00:00:13,420
It's really not trivial to use an Azure‑based BitLocker key on‑prem.

3
00:00:13,420 --> 00:00:14,060
You can do it.

4
00:00:14,060 --> 00:00:17,140
Check the exercise files and read in the Microsoft

5
00:00:17,140 --> 00:00:19,810
Azure Docs and there's instructions.

6
00:00:19,810 --> 00:00:23,440
It's beyond our scope for the purpose of the exam though.

7
00:00:23,440 --> 00:00:27,330
But what I want you to know is that deleting a resource,

8
00:00:27,330 --> 00:00:31,060
we got an error here on updating the disk encryption settings.

9
00:00:31,060 --> 00:00:34,740
Oh, I might want to take a look at that after I finish recording.

10
00:00:34,740 --> 00:00:35,170
But anyway,

11
00:00:35,170 --> 00:00:39,260
to complete my thought here is if I go back to the keyvault

12
00:00:39,260 --> 00:00:42,180
Settings and go back to one of the top levels,

13
00:00:42,180 --> 00:00:44,340
like in this case the Keys,

14
00:00:44,340 --> 00:00:48,740
notice that there's essentially a recycle bin for each service,

15
00:00:48,740 --> 00:00:53,020
and there's a retention period there such that even

16
00:00:53,020 --> 00:00:56,580
deleted artifacts will be protected, and you can,

17
00:00:56,580 --> 00:00:58,360
when you create your key vault,

18
00:00:58,360 --> 00:01:02,480
set a flag called purge protection that would prevent anybody from

19
00:01:02,480 --> 00:01:05,460
purging deleted items out of your Recycle Bin.

20
00:01:05,460 --> 00:01:06,570
Now lastly,

21
00:01:06,570 --> 00:01:09,030
I want you to have the comfort that even if one of your

22
00:01:09,030 --> 00:01:12,240
colleagues were to delete an entire EVault,

23
00:01:12,240 --> 00:01:16,660
you can manage deleted vaults, and you can recover the entire vault,

24
00:01:16,660 --> 00:01:18,440
as well as its artifact.

25
00:01:18,440 --> 00:01:22,350
So these are all things that hopefully give you some comfort as a

26
00:01:22,350 --> 00:01:26,330
customer knowing that there's those layers of protection so that when

27
00:01:26,330 --> 00:01:29,540
you're called in to troubleshoot an encryption issue,

28
00:01:29,540 --> 00:01:34,850
you have the surrounding context because definitely Azure encryption and

29
00:01:34,850 --> 00:01:38,690
Azure VM encryption is dependent upon Azure Key Vault,

30
00:01:38,690 --> 00:01:40,540
pretty fundamentally.

31
00:01:40,540 --> 00:01:44,190
Okay, last thing we'll do here is we'll head on over to Network Watcher,

32
00:01:44,190 --> 00:01:46,140
if I can type correctly.

33
00:01:46,140 --> 00:01:50,340
And in terms of troubleshooting network access on your VMs,

34
00:01:50,340 --> 00:01:53,620
I'd mentioned that there's this tool called NSG diagnostic.

35
00:01:53,620 --> 00:01:58,800
So we can dial up our virtual machine, so let's find that monitorvm,

36
00:01:58,800 --> 00:02:02,570
and we can model inbound or outbound traffic.

37
00:02:02,570 --> 00:02:07,640
Let's say we're modeling inbound traffic on TCP 443.

38
00:02:07,640 --> 00:02:11,420
The Source would be, let's say, my current machine.

39
00:02:11,420 --> 00:02:18,260
Let me go to ipaddress.com to try to grab the public

40
00:02:18,260 --> 00:02:20,440
IP of the machine I'm teaching on.

41
00:02:20,440 --> 00:02:23,600
Now the Destination here, this is showing a public IP,

42
00:02:23,600 --> 00:02:27,510
so that gives me some troubleshooting knowledge right there that my

43
00:02:27,510 --> 00:02:31,330
Azure VM actually has a public internet IP on it,

44
00:02:31,330 --> 00:02:34,060
which you may not want for security reasons.

45
00:02:34,060 --> 00:02:35,340
Interesting!

46
00:02:35,340 --> 00:02:39,540
Though once we've modeled that inbound or outbound traffic flow,

47
00:02:39,540 --> 00:02:40,110
by the way,

48
00:02:40,110 --> 00:02:43,200
the source and destination IP addresses don't have to be

49
00:02:43,200 --> 00:02:45,940
public internet accessible addresses,

50
00:02:45,940 --> 00:02:50,510
you could be testing NSG rules between virtual machines in

51
00:02:50,510 --> 00:02:54,220
the same VNet or on peered VNets as well,

52
00:02:54,220 --> 00:02:56,180
though we would expect that that's denied.

53
00:02:56,180 --> 00:02:56,540
Why?

54
00:02:56,540 --> 00:02:59,640
Because of this particular NSG, all right?

55
00:02:59,640 --> 00:03:03,100
Another NSG‑related Network Watcher tool would be,

56
00:03:03,100 --> 00:03:05,380
let's see here, Effective security rules.

57
00:03:05,380 --> 00:03:07,540
Let's take a look at that one next.

58
00:03:07,540 --> 00:03:08,180
Once again,

59
00:03:08,180 --> 00:03:14,290
we can load up our virtual machine and that pops in the network interface.

60
00:03:14,290 --> 00:03:19,280
It's basically just going to report on any associated network security groups.

61
00:03:19,280 --> 00:03:22,540
This can give you some valuable troubleshooting insight.

62
00:03:22,540 --> 00:03:24,780
Maybe there's more than one NSG.

63
00:03:24,780 --> 00:03:27,850
In this case I learned something new in terms of instead

64
00:03:27,850 --> 00:03:32,710
of an NSG applying from the subnet, which is normally how I design this,

65
00:03:32,710 --> 00:03:37,110
this particular VM has an NSG attached to the network interface.

66
00:03:37,110 --> 00:03:42,540
I may very well not want that and want to shift that around a bit, you see?

67
00:03:42,540 --> 00:03:42,900
So,

68
00:03:42,900 --> 00:03:47,070
these are all ways to gain more visibility into your

69
00:03:47,070 --> 00:03:51,040
Azure VMs for performance tuning, for troubleshooting,

70
00:03:51,040 --> 00:03:53,240
for security optimization,

71
00:03:53,240 --> 00:04:01,000
and to compensate for the fact that you can't touch your machines like you can when you're running on‑premises infrastructure.