WEBVTT

1
00:00.000 --> 00:08.000
In this challenge, we're asked to answer a series of questions to help ensure

2
00:08.000 --> 00:08.200
that we

3
00:08.200 --> 00:13.820
understand all the concepts covered with the performance and redundancy for our

4
00:13.820 --> 00:14.220
cloud

5
00:14.220 --> 00:15.220
connections.

6
00:15.220 --> 00:20.080
So let's just go ahead and jump in here with our first question.

7
00:20.080 --> 00:25.530
What is a primary method used in cloud environments to achieve connection

8
00:25.530 --> 00:27.440
redundancy between data

9
00:27.440 --> 00:30.720
centers and cloud resources?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:27.440 --> 00:30.720
centers and cloud resources?

10
00:30.720 --> 00:33.680
So let's just work our way down the answers here.

11
00:33.680 --> 00:39.800
First, we have relying on a single ISP with a guaranteed uptime agreement.

12
00:39.800 --> 00:44.110
Well, this is definitely not going to be very good because even if they have a

13
00:44.110 --> 00:44.940
guaranteed

14
00:44.940 --> 00:49.060
uptime agreement, that doesn't necessarily mean they're really going to be

15
00:49.060 --> 00:49.520
permanently

16
00:49.520 --> 00:50.520
up.

17
00:50.520 --> 00:52.520
They can still go down.

18
00:52.520 --> 00:57.960
Something only dedicated leased lines for all incoming and outgoing traffic.

19
00:57.960 --> 01:02.300
Well, leased lines versus a internet connection line.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:57.960 --> 01:02.300
Well, leased lines versus a internet connection line.

20
01:02.300 --> 01:07.040
This doesn't really change anything as far as the reliability.

21
01:07.040 --> 01:11.790
Dedicated leased lines can go down just as easily as internet connections can

22
01:11.790 --> 01:12.880
go down.

23
01:12.880 --> 01:17.240
Implementing multiple internet connections using different ISPs.

24
01:17.240 --> 01:19.240
Now that sounds like a really good answer.

25
01:19.240 --> 01:20.240
In fact, it's so good.

26
01:20.240 --> 01:22.460
I'm just going to go ahead and mark it.

27
01:22.460 --> 01:25.460
If the fourth answer is better, we'll come back.

28
01:25.460 --> 01:28.200
But that's definitely a good answer.

29
01:28.200 --> 01:33.840
So finally, we have deploying a single connection with automatic bandwidth
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:28.200 --> 01:33.840
So finally, we have deploying a single connection with automatic bandwidth

30
01:33.840 --> 01:34.160
scaling.

31
01:34.160 --> 01:37.570
This is not going to be a good answer in any way because again, we're still

32
01:37.570 --> 01:38.480
talking about

33
01:38.480 --> 01:40.080
a single connection.

34
01:40.080 --> 01:42.740
So that's not going to be a good solution.

35
01:42.740 --> 01:46.480
So clearly the best answer here is going to be implementing multiple internet

36
01:46.480 --> 01:47.200
connections

37
01:47.200 --> 01:49.880
using different ISPs.

38
01:49.880 --> 01:57.360
Next question, which AWS feature allows traffic distribution across multiple

39
01:57.360 --> 01:58.540
instances in

40
01:58.540 --> 02:03.380
different availability zones to ensure high availability.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:58.540 --> 02:03.380
different availability zones to ensure high availability.

41
02:03.380 --> 02:06.700
Our first answer here is AWS Lambda.

42
02:06.700 --> 02:11.940
This actually is used to provide Lambda functions for coding and development.

43
02:11.940 --> 02:14.140
That's not going to be correct.

44
02:14.140 --> 02:19.960
Amazon EC2 auto scaling will EC2 is their server platform.

45
02:19.960 --> 02:23.200
So this is not going to be correct either.

46
02:23.200 --> 02:27.500
Amazon S3 is their storage service that they offer.

47
02:27.500 --> 02:32.560
So that's not going to be correct either, which leaves us with elastic load
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
02:27.500 --> 02:32.560
So that's not going to be correct either, which leaves us with elastic load

48
02:32.560 --> 02:33.620
balancing.

49
02:33.620 --> 02:35.780
This is going to be the correct answer.

50
02:35.780 --> 02:38.760
That's exactly what ELB does.

51
02:38.760 --> 02:46.320
Next question in Microsoft Azure, which service is specifically designed to

52
02:46.320 --> 02:47.960
handle global DNS

53
02:47.960 --> 02:49.620
load balancing.

54
02:49.620 --> 02:54.160
So our first answer is the Azure application gateway.

55
02:54.160 --> 02:57.920
This is actually an HTTP load balancer.

56
02:57.920 --> 03:00.640
Therefore, this is not going to be the correct answer.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
02:57.920 --> 03:00.640
Therefore, this is not going to be the correct answer.

57
03:00.640 --> 03:03.160
It's not DNS based.

58
03:03.160 --> 03:10.050
It's the Azure traffic manager and the traffic manager is in fact DNS based

59
03:10.050 --> 03:11.960
load balancing.

60
03:11.960 --> 03:13.900
So this is going to be a good answer.

61
03:13.900 --> 03:16.960
Let's again just verify the rest.

62
03:16.960 --> 03:18.920
Next is Azure Front Door.

63
03:18.920 --> 03:22.440
I'm not aware that that's actually an Azure product.

64
03:22.440 --> 03:26.930
Maybe it is that I've not seen, but that's not going to be the correct answer

65
03:26.930 --> 03:27.280
here.

66
03:27.280 --> 03:33.320
And finally is the Azure load balancer. This is also incorrect because remember
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
03:27.280 --> 03:33.320
And finally is the Azure load balancer. This is also incorrect because remember

67
03:33.320 --> 03:33.720
this one

68
03:33.720 --> 03:37.920
operates using the TCP and UDP port numbers.

69
03:37.920 --> 03:41.040
So again, not DNS based.

70
03:41.040 --> 03:45.640
So the correct answer is the Azure traffic manager.

71
03:45.640 --> 03:47.200
Next question.

72
03:47.200 --> 03:53.370
What is the purpose of Google Cloud's global load balancer in terms of

73
03:53.370 --> 03:54.840
redundancy?

74
03:54.840 --> 04:00.710
So our first answer here is to distribute and user requests across regional
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:54.840 --> 04:00.710
So our first answer here is to distribute and user requests across regional

75
04:00.710 --> 04:02.800
backend services

76
04:02.800 --> 04:05.600
depending on origin.

77
04:05.600 --> 04:08.200
That actually sounds like a really good answer.

78
04:08.200 --> 04:13.610
But before we mark it, let's verify the others to increase computational power

79
04:13.610 --> 04:14.440
globally.

80
04:14.440 --> 04:18.080
Well, that wouldn't have anything to do with this service.

81
04:18.080 --> 04:19.800
That's not what that is.

82
04:19.800 --> 04:22.760
So that's definitely just going to be incorrect.

83
04:22.760 --> 04:27.880
To provide a single global IP address for deploying applications.

84
04:27.880 --> 04:32.280
This actually doesn't have anything to do with the deployment of applications.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
04:27.880 --> 04:32.280
This actually doesn't have anything to do with the deployment of applications.

85
04:32.280 --> 04:34.920
It has to do with accessing applications.

86
04:34.920 --> 04:37.760
So that's not going to be correct either.

87
04:37.760 --> 04:41.920
To restrict access to applications based on user geography.

88
04:41.920 --> 04:47.650
Well, this is sort of based on user geography in that it's going to route

89
04:47.650 --> 04:48.920
traffic based

90
04:48.920 --> 04:50.760
on the origin.

91
04:50.760 --> 04:55.830
However, that really just means that our first answer here, which is to

92
04:55.830 --> 04:57.080
distribute end user

93
04:57.080 --> 05:03.620
requests across regional backend services, depending on the origin is going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:57.080 --> 05:03.620
requests across regional backend services, depending on the origin is going to

94
05:03.620 --> 05:04.160
be our

95
05:04.160 --> 05:05.920
best answer.

96
05:05.920 --> 05:11.890
And our final question, which AWS networking service is primarily used to

97
05:11.890 --> 05:13.400
connect multiple

98
05:13.400 --> 05:17.680
VPCs and simplifying network management.

99
05:17.680 --> 05:21.760
So our first answer here is Amazon VPC peering.

100
05:21.760 --> 05:27.800
VPC peering actually occurs within a VPC, not between VPCs.

101
05:27.800 --> 05:30.840
So this is going to be incorrect.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:27.800 --> 05:30.840
So this is going to be incorrect.

102
05:30.840 --> 05:35.000
Amazon route 53 is actually their DNS service.

103
05:35.000 --> 05:39.720
So that again is not going to have anything to do with this solution.

104
05:39.720 --> 05:45.240
AWS transit gateway actually sounds like a really good solution.

105
05:45.240 --> 05:49.490
We saw this on the diagram connecting the different VPCs from different

106
05:49.490 --> 05:50.440
availability

107
05:50.440 --> 05:52.040
zones together.

108
05:52.040 --> 05:53.040
So that's a good answer.

109
05:53.040 --> 05:55.320
Let's just check the last one quick.

110
05:55.320 --> 05:57.600
AWS direct connect.

111
05:57.600 --> 06:01.440
Well, this will give us a direct connection to our cloud resources.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
05:57.600 --> 06:01.440
Well, this will give us a direct connection to our cloud resources.

112
06:01.440 --> 06:05.720
But again, that doesn't have anything to do with connecting multiple VPCs to

113
06:05.720 --> 06:06.280
simplify

114
06:06.280 --> 06:08.040
network management.

115
06:08.040 --> 06:14.720
So again, our best answer here is going to be the AWS transit gateway.

116
06:14.720 --> 06:19.880
So that answers all of these questions and therefore concludes this challenge.

117
06:19.880 --> 06:24.010
If you find you were not able to answer any of these questions successfully, I

118
06:24.010 --> 06:24.600
would encourage

119
06:24.600 --> 06:29.880
you to go back and review the necessary videos in the scale above.

120
06:29.880 --> 06:35.200
Otherwise, congratulations on completing performance and redundancy for cloud
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
06:29.880 --> 06:35.200
Otherwise, congratulations on completing performance and redundancy for cloud

121
06:35.200 --> 06:36.320
connections.

122
06:36.320 --> 06:40.440
I hope this has been informative for you and I'd like to thank you for viewing.

123
06:40.440 --> 06:50.440
[BLANK_AUDIO]