Question : A user has created an Auto Scaling group with default configurations from CLI. The user wants to setup the CloudWatch alarm on the EC instances, which are launched by the Auto Scaling group. The user has setup an alarm to monitor the CPU utilization every minute. Which of the below mentioned statements is true? 1. It will fetch the data at every minute but the four data points [corresponding to 4 minutes] will not have value since the EC2 basic monitoring metrics are collected every five minutes 2. It will fetch the data at every minute as detailed monitoring on EC2 will be enabled by the default launch configuration of Auto Scaling 3. The alarm creation will fail since the user has not enabled detailed monitoring on the EC2 instances 4. The user has to first enable detailed monitoring on the EC2 instances to support alarm monitoring at every minute
Correct Answer : 2
Explanation: You can create an CloudWatch alarm that sends an Amazon Simple Notification Service message when the alarm changes state. An alarm watches a single metric over a time period you specify, and performs one or more actions based on the value of the metric relative to a given threshold over a number of time periods. The action is a notification sent to an Amazon Simple Notification Service topic or Auto Scaling policy. Alarms invoke actions for sustained state changes only. CloudWatch alarms will not invoke actions simply because they are in a particular state, the state must have changed and been maintained for a specified number of periods. After an alarm invokes an action due to a change in state, its subsequent behavior depends on the type of action that you have associated with the alarm. For Auto Scaling policy notifications, the alarm continues to invoke the action for every period that the alarm remains in the new state. For Amazon Simple Notification Service notifications, no additional actions are invoked. An alarm has three possible states: " OK-The metric is within the defined threshold " ALARM-The metric is outside of the defined threshold " INSUFFICIENT_DATA-The alarm has just started, the metric is not available, or not enough data is available for the metric to determine the alarm state In the following figure, the alarm threshold is set to 3 and the minimum breach is 3 periods. That is, the alarm invokes its action only when the threshold is breached for 3 consecutive periods. In the figure, this happens with the third through fifth time periods, and the alarm's state is set to ALARM. At period six, the value dips below the threshold, and the state reverts to OK. Later, during the ninth time period, the threshold is breached again, but not for the necessary three consecutive periods. Consequently, the alarm's state remains OK. CloudWatch is used to monitor AWS as well as the custom services. To enable detailed instance monitoring for a new Auto Scaling group, the user does not need to take any extra steps. When the user creates an Auto Scaling launch config using CLI, each launch configuration contains a flag named InstanceMonitoring.Enabled. The default value of this flag is true. Thus, by default detailed monitoring will be enabled for Auto Scaling as well as for all the instances launched by that Auto Scaling group.
Question : QuickAdmin.com has created a VPC with public and private subnets using the VPC wizard. Which of the below mentioned statements is not true in this scenario? 1. The VPC will create a routing instance and attach it with a public subnet 2. The VPC will create two subnets 3. The VPC will create one internet gateway and attach it to VPC 4. The VPC will launch one NAT instance with an elastic IP
Correct Answer : 1 Route Table Basics : The following are the basic things that you need to know about route tables:
Your VPC has an implicit router. Your VPC automatically comes with a main route table that you can modify. You can create additional custom route tables for your VPC.
Each subnet must be associated with a route table, which controls the routing for the subnet. If you don't explicitly associate a subnet with a particular route table, the subnet uses the main route table. You can replace the main route table with a custom table that you've created (so that this table is the default table each new subnet is associated with). Each route in a table specifies a destination CIDR and a target (for example, traffic destined for 172.16.0.0/12 is targeted for the virtual private gateway); we use the most specific route that matches the traffic to determine how to route the traffic.
Main Route Tables : When you create a VPC, it automatically has a main route table. On the Route Tables page in the VPC console, you can view the main route table for a VPC by looking for Yes in the Main column. Initially, the main route table (and every route table in a VPC) contains only a single route: a local route that enables communication within the VPC. You can't modify the local route in a route table. Whenever you launch an instance in the VPC, the local route automatically covers that instance; you don't need to add the new instance to a route table.
If you don't explicitly associate a subnet with a route table, the subnet is implicitly associated with the main route table. However, you can still explicitly associate a subnet with the main route table. You might do that if you change which table is the main route table
The console shows the number of subnets associated with each table. Only explicit associations are included in that number When you add a gateway to a VPC (either an Internet gateway or a virtual private gateway), you must update the route table for any subnet that uses that gateway. If you've attached a virtual private gateway to your VPC and enabled route propagation on your route table, routes representing your VPN connection automatically appear as propagated routes in your route table's list of routes.
Custom Route Tables : Your VPC can have route tables other than the default table. One way to protect your VPC is to leave the main route table in its original default state (with only the local route), and explicitly associate each new subnet you create with one of the custom route tables you've created. This ensures that you must explicitly control how each subnet's outbound traffic is routed.
The following example shows the routing for a VPC with both an Internet gateway and a virtual private gateway, plus a public subnet and a VPN-only subnet. The main route table came with the VPC, and it also has a route for the VPN-only subnet. There's a custom route table that's associated with the public subnet. The custom route table has a route for the public subnet over the Internet gateway (the destination is 0.0.0.0/0, and the target is the Internet gateway). A user can create a subnet with VPC and launch instances inside that subnet. If the user has created a public private subnet, the instances in the public subnet can receive inbound traffic directly from the internet, whereas the instances in the private subnet cannot. If these subnets are created with Wizard, AWS will create a NAT instance with an elastic IP. Wizard will also create two subnets with route tables. It will also create an internet gateway and attach it to the VPC.
Question : A user has configured ELB with a TCP listener at ELB as well as on the back-end instances. The user wants to enable a proxy protocol to capture the source and destination IP information in the header. Which of the below mentioned statements helps the user understand a proxy protocol with TCP configuration? 1. If the end user is requesting behind a proxy server then the user should not enable a proxy protocol on ELB 2. ELB does not support a proxy protocol when it is listening on both the load balancer and the back-end instances 3. Whether the end user is requesting from a proxy server or directly, it does not make a difference for the proxy protocol 4. If the end user is requesting behind the proxy then the user should add the "isproxy" flag to the ELB Configuration
Correct Answer : 1
When the user has configured Transmission Control Protocol (TCP. or Secure Sockets Layer (SSL. for both front-end and back-end connections of the Elastic Load Balancer, the load balancer forwards the request to the back-end instances without modifying the request headers unless the proxy header is enabled. If the end user is requesting from a Proxy Protocol enabled proxy server, then the ELB admin should not enable the Proxy Protocol on the load balancer. If the Proxy Protocol is enabled on both the proxy server and the load balancer, the load balancer will add another header to the request which already has a header from the proxy server. This duplication may result in errors.
1. The size of a request is limited to 8KB for HTTP GET requests and 40KB for HTTP POST requests 2. The size of a request is limited to 128KB for HTTP GET requests and 64KB for HTTP POST requests 3. Access Mostly Uused Products by 50000+ Subscribers 4. The size of a request is limited to 16KB for HTTP GET requests and 80KB for HTTP POST requests