WEBVTT

1
00:00.000 --> 00:07.040
So for this challenge, we're asked to answer just a few questions here about

2
00:07.040 --> 00:08.240
the topics

3
00:08.240 --> 00:11.560
to verify that we understand the information.

4
00:11.560 --> 00:16.080
So let's go ahead and jump in here with our first question.

5
00:16.080 --> 00:22.780
Why was the Gcloud command to check the status of the VPN gateway not

6
00:22.780 --> 00:25.640
successful in our demonstration?

7
00:25.640 --> 00:31.440
Well, let's go down our answers. Our first answer here is because we are using
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

7
00:25.640 --> 00:31.440
Well, let's go down our answers. Our first answer here is because we are using

8
00:31.440 --> 00:32.100
standard

9
00:32.100 --> 00:37.400
gateways. And that sounds like a really good answer, which would actually make

10
00:37.400 --> 00:37.820
our second

11
00:37.820 --> 00:43.620
answer here incorrect because we were not using fault tolerant gateways. If we

12
00:43.620 --> 00:44.280
had been,

13
00:44.280 --> 00:49.170
it would have worked. Now, the last two answers, because it's not a Gcloud

14
00:49.170 --> 00:50.700
command implying

15
00:50.700 --> 00:54.870
that there's a different command other than Gcloud we should have been using,

16
00:54.870 --> 00:55.080
that's

17
00:55.080 --> 00:59.820
incorrect because it is in fact a Gcloud command. And because we didn't have

18
00:59.820 --> 01:01.200
any gateways,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:59.820 --> 01:01.200
any gateways,

19
01:01.200 --> 01:08.630
also not true because we of course had two gateways in our example. This leaves

20
01:08.630 --> 01:09.120
the because

21
01:09.120 --> 01:16.170
we are using standard gateways as our correct answer for question one. Next

22
01:16.170 --> 01:17.400
question, what

23
01:17.400 --> 01:24.910
do we need to keep in mind when using AWS CloudTrail? Remember that CloudTrail

24
01:24.910 --> 01:25.520
is the feature

25
01:25.520 --> 01:31.350
we looked at that allows us to do filtering and create logs based on certain
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:25.520 --> 01:31.350
we looked at that allows us to do filtering and create logs based on certain

26
01:31.350 --> 01:32.280
topics. So

27
01:32.280 --> 01:38.760
let's go down our answers here. The first answer is the database used by trail

28
01:38.760 --> 01:39.600
is limited

29
01:39.600 --> 01:45.170
in size. Now, it may or may not actually use like a database structure or

30
01:45.170 --> 01:46.080
something on

31
01:46.080 --> 01:50.350
the back end. But if it does, we don't really see that. And there's no

32
01:50.350 --> 01:51.520
indication that it's

33
01:51.520 --> 01:57.640
limited in size. It actually just stores it in an S3 bucket. Now again, those

34
01:57.640 --> 01:58.160
files that

35
01:58.160 --> 02:02.260
it puts on the S3 bucket may in fact be part of database. That's not really the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:58.160 --> 02:02.260
it puts on the S3 bucket may in fact be part of database. That's not really the

36
02:02.260 --> 02:02.880
question

37
02:02.880 --> 02:07.750
here. I think the big thing we're trying to get to is probably the second

38
02:07.750 --> 02:08.880
answer that

39
02:08.880 --> 02:15.330
the S3 bucket used may incur fees. We are going to have to pay for that S3

40
02:15.330 --> 02:16.840
bucket. So that's

41
02:16.840 --> 02:22.540
a true answer. But let's see if there's something better. Number three, the S3

42
02:22.540 --> 02:23.760
bucket is deleted

43
02:23.760 --> 02:28.070
automatically with the trail. Well, we know this is not correct because as we

44
02:28.070 --> 02:28.840
went through

45
02:28.840 --> 02:34.280
the demonstration, we saw that when we deleted the trail, the S3 bucket was in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:28.840 --> 02:34.280
the demonstration, we saw that when we deleted the trail, the S3 bucket was in

46
02:34.280 --> 02:34.840
fact still

47
02:34.840 --> 02:39.990
there. And we had to delete it manually, which in all honesty, in case I didn't

48
02:39.990 --> 02:41.560
say it then,

49
02:41.560 --> 02:46.280
that's actually what we would want, because we may still want the logs that we

50
02:46.280 --> 02:46.960
collected

51
02:46.960 --> 02:50.730
just because we deleted the trail doesn't necessarily mean we want to delete

52
02:50.730 --> 02:51.400
the logs.

53
02:51.400 --> 02:56.130
So it's good that it's a separate process, but it is a separate process. And of

54
02:56.130 --> 02:56.720
course,

55
02:56.720 --> 03:01.260
that would go completely against this last answer that all of the entries are
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:56.720 --> 03:01.260
that would go completely against this last answer that all of the entries are

56
03:01.260 --> 03:01.840
removed

57
03:01.840 --> 03:07.330
after 24 hours. That would actually be really, really bad. So that leaves us

58
03:07.330 --> 03:08.380
with the S3

59
03:08.380 --> 03:17.270
bucket used may incur fees as our correct answer. Final question. What happens

60
03:17.270 --> 03:17.560
if you

61
03:17.560 --> 03:24.740
do a reset at the connection level in Azure? Now, as we jump in here, the

62
03:24.740 --> 03:26.000
really important

63
03:26.000 --> 03:30.950
part of this question is going to be the fact that we're talking about the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
03:26.000 --> 03:30.950
part of this question is going to be the fact that we're talking about the

64
03:30.950 --> 03:31.600
connection

65
03:31.600 --> 03:36.940
level here in Azure, because if it was at the virtual network gateway level, it

66
03:36.940 --> 03:37.160
would

67
03:37.160 --> 03:41.180
have a different behavior. So let's go down our answers and figure out which

68
03:41.180 --> 03:42.460
ones correct.

69
03:42.460 --> 03:48.310
So first we have all settings for the connection will be reset to defaults. Now

70
03:48.310 --> 03:49.320
, that is what

71
03:49.320 --> 03:53.280
reset means in some contexts, but that would actually be really bad here since

72
03:53.280 --> 03:54.040
we're talking

73
03:54.040 --> 04:00.500
about just wanting to reset the VPN, not all of the settings for it. If you did
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

73
03:54.040 --> 04:00.500
about just wanting to reset the VPN, not all of the settings for it. If you did

74
04:00.500 --> 04:00.720
want

75
04:00.720 --> 04:04.550
to do that, you could of course just delete the VPN and recreate it and you

76
04:04.550 --> 04:05.000
would get

77
04:05.000 --> 04:11.690
a VPN with all the defaults. All tunnels to Azure will be reset. Well, the

78
04:11.690 --> 04:12.200
problem with

79
04:12.200 --> 04:17.250
this answer is the word all. It's not going to reset all of the tunnels because

80
04:17.250 --> 04:18.040
it's not

81
04:18.040 --> 04:24.170
going to reboot the virtual network gateway. And that statement sort of takes

82
04:24.170 --> 04:24.800
out this

83
04:24.800 --> 04:31.680
answer and this answer at the same time. And of course, that leaves us with our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

83
04:24.800 --> 04:31.680
answer and this answer at the same time. And of course, that leaves us with our

84
04:31.680 --> 04:32.520
correct

85
04:32.520 --> 04:40.490
answer that the tunnels for that connection will be rebuilt. It'll reset the

86
04:40.490 --> 04:41.760
tunnels,

87
04:41.760 --> 04:47.750
renegotiate the tunnels and bring them back online. So that concludes this

88
04:47.750 --> 04:48.800
challenge and

89
04:48.800 --> 04:53.320
therefore this skill. If you find that you were missing any of the information

90
04:53.320 --> 04:53.720
needed

91
04:53.720 --> 04:57.910
to answer these questions, I would encourage you to go back and review the

92
04:57.910 --> 04:59.120
necessary sections

93
04:59.120 --> 05:05.860
above. Otherwise, congratulations on completing troubleshooting cloud gateways.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:59.120 --> 05:05.860
above. Otherwise, congratulations on completing troubleshooting cloud gateways.

94
05:05.860 --> 05:06.380
I hope this

95
05:06.380 --> 05:09.960
has been informative for you and I'd like to thank you for viewing.

96
05:09.960 --> 05:18.700
[BLANK_AUDIO]