Question : A user has created a VPC with CIDR .../ using VPC Wizard. The user has created a public CIDR (.../. and a VPN only subnet CIDR (20.0.1.0/24. along with the hardware VPN access to connect to the user's data centre. Which of the below mentioned components is not present when the VPC is setup with the wizard? 1. Main route table attached with a VPN only subnet 2. A NAT instance configured to allow the VPN subnet instances to connect with the internet 3. Custom route table attached with a public subnet 4. An internet gateway for a public subnet
Correct Answer : 2
Explanation: Connections with Your Local Network and Other VPCs You can optionally set up a connection between your VPC and your corporate or home network. If you have an IP address prefix in your VPC that overlaps with one of your networks' prefixes, any traffic to the network's prefix is dropped. For example, let's say that you have the following: >A VPC with CIDR block 10.0.0.0/16 >A subnet in that VPC with CIDR block 10.0.1.0/24 >Instances running in that subnet with IP addresses 10.0.1.4 and 10.0.1.5 >On-premises host networks using CIDR blocks 10.0.37.0/24 and 10.1.38.0/24
When those instances in the VPC try to talk to hosts in the 10.0.37.0/24 address space, the traffic is dropped because 10.0.37.0/24 is part of the larger prefix assigned to the VPC (10.0.0.0/16). The instances can talk to hosts in the 10.1.38.0/24 space because that block isn't part of 10.0.0.0/16.
You can also create a VPC peering connection between your VPCs, or with a VPC in another AWS account. A VPC peering connection enables you to route traffic between the VPCs using private IP addresses; however, you cannot create a VPC peering connection between VPCs that have overlapping CIDR blocks. For more information, see VPC Peering.
We therefore recommend that you create a VPC with a CIDR range large enough for expected future growth, but not one that overlaps with current or expected future subnets anywhere in your corporate or home network, or that overlaps with current or future VPCs. 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 two route tables and attach to the subnets. The main route table will have the entry "Destination: 20.0.0.0/24 and Target: Local", which allows all instances in the VPC to communicate with each other. The user can create subnets as per the requirement within a VPC. If the user wants to connect VPC from his own data centre, he can setup a public and VPN only subnet which uses hardware VPN access to connect with his data centre. When the user has configured this setup with Wizard, it will update the main route table used with the VPN-only subnet, create a custom route table and associate it with the public subnet. It also creates an internet gateway for the public subnet. The wizard does not create a NAT instance by default. The user can create it manually and attach it with a VPN only subnet.
Question : A user has created a VPC with the public subnet. The user has created a security group for that VPC. Which of the below mentioned statements is true when a security group is created?
1. It can connect to the AWS services, such as S3 and RDS by default 2. It will have all the inbound traffic by default 3. It will have all the outbound traffic by default 4. It will by default allow traffic to the internet gateway
Correct Answer : 3
Explanation: A security group acts as a virtual firewall to control the traffic allowed into its associated instances. To use security groups, you create a group, add the inbound and outbound rules that you want to use, and then associate your instances with the security group when you launch them. If you add and remove rules from the security group, we apply those changes to the instances associated with the security group automatically.
Your VPC comes with a default security group. Any instance not associated with another security group is associated with the default security group. Although we could use the default security group for this exercise, we've chosen to create a security group, WebServerSG, instead. You'll specify this security group when you launch an instance into your VPC.A Virtual Private Cloud (VPC. is a virtual network dedicated to the user's AWS account. AWS provides two features the user can use to increase security in VPC: security groups and network ACLs. Security groups work at the instance level while ACLs work at the subnet level. When a user creates a security group with AWS VPC, by default it will allow all the outbound traffic but block all inbound traffic.
Inbound rules regulate the traffic that is allowed to reach the instances associated with the security group (the source of the traffic and the listening port on the instance). All return traffic is automatically allowed to reach the instances. For example, if a client on the Internet sends a request to a web server in your VPC associated with WebServerSG, the instance can respond, regardless of any outbound rules on the group. In this way, security groups are stateful.
Outbound rules control which destinations the instances associated with the security group can send traffic to (the destination of the traffic and the destination port). All return traffic (such as a response from the host that received the traffic) is automatically allowed to reach the instances, regardless of the inbound rules set on the security group.
Question : A user has setup an Auto Scaling group. The group has failed to launch a single instance for more than hours. What will happen to Auto Scaling in this condition? 1. Auto Scaling will keep trying to launch the instance for 72 hours 2. Auto Scaling will suspend the scaling process 3. Auto Scaling will start an instance in a separate region 4. The Auto Scaling group will be terminated automatically
Correct Answer : 2 Explanation: Auto Scaling allows you to suspend and then resume one or more of the Auto Scaling processes in your Auto Scaling group. This can be very useful when you want to investigate a configuration problem or other issue with your web application and then make changes to your application, without triggering the Auto Scaling process. There are two primary Auto Scaling process types - Launch and Terminate. The Launch process creates a new EC2 instance for an Auto Scaling group, and the Terminate process removes an existing Amazon EC2 instance. The remaining Auto Scaling process types relate to specific Auto Scaling features: AddToLoadBalancer, AlarmNotification, AZRebalance, HealthCheck, ReplaceUnhealthy, ScheduledActions
If you suspend Launch or Terminate, all other process types are affected to varying degrees. The following descriptions discuss how each process type is affected by a suspension of a Launch or a Terminate process. The AddToLoadBalancer process type adds instances to the load balancer when the instances are launched. If you suspend this process, Auto Scaling launches the instances but does not add them to the load balancer. If you resume the AddToLoadBalancer process, Auto Scaling also resumes adding new instances to the load balancer when they are launched. However, Auto Scaling does not add running instances that were launched while the process was suspended; those instances must be added manually using the RegisterInstancesWithLoadBalancer Elastic Load Balancing API action or the elb-register-instances-with-lb Elastic Load Balancing command. The AlarmNotification process type accepts notifications from CloudWatch alarms that are associated with the Auto Scaling group. If you suspend the AlarmNotification process type, Auto Scaling does not automatically execute scaling policies that would be triggered by alarms. Although the AlarmNotification process type is not directly affected by a suspension of Launch or Terminate, alarm notifications are often used to signal that a change in the size of the Auto Scaling group is warranted. If you suspend Launch or Terminate process, Auto Scaling might not be able to implement the alarm's associated policy.
The AZRebalance process type seeks to maintain a balanced number of instances across Availability Zones within a region. If you remove an Availability Zone from your Auto Scaling group or an Availability Zone otherwise becomes unhealthy or unavailable, Auto Scaling launches new instances in an unaffected Availability Zone before terminating the unhealthy or unavailable instances. When the unhealthy Availability Zone returns to a healthy state, Auto Scaling automatically redistributes the application instances evenly across all of the designated Availability Zones. If you suspend the Launch process, the AZRebalance process neither launches new instances nor terminates existing instances. This is because the AZRebalance process terminates existing instances only after launching the replacement instances. If you suspend the Terminate process, the AZRebalance process can cause your Auto Scaling group to grow up to ten percent larger than the maximum size. This is because Auto Scaling allows groups to grow temporarily larger than the maximum size during rebalancing activities. If Auto Scaling cannot terminate instances, your Auto Scaling group could remain up to ten percent larger than the maximum size until you resume the terminate process type. The HealthCheck process type checks the health of the instances. Auto Scaling marks an instance as unhealthy if Amazon EC2 or Elastic Load Balancing informs Auto Scaling that the instance is unhealthy. The HealthCheck process can override the health status of an instance that you set with SetInstanceHealth API action or the as-set-instance-health command. The ReplaceUnhealthy process terminates instances that are marked as unhealthy and subsequently creates new instances to replace them. This process calls both of the primary process type - first Terminate and then Launch.
The HealthCheck process works in conjunction with the ReplaceUnhealthy process to provide health check functionality. If you suspend either the Launch or the Terminate process, the ReplaceUnhealthy process will not function properly. The ScheduledActions process type performs scheduled actions that you create with either the PutScheduledUpdateGroupAction API action or the as-put-scheduled-update-group-action command. Scheduled actions often involve launching new instances or terminating existing instances. If you suspend either the Launch or the Terminate process, your scheduled actions might not function as expected. Auto Scaling might, at times, suspend processes for Auto Scaling groups that repeatedly fail to launch instances. This is known as an administrative suspension, and most commonly applies to Auto Scaling groups that have no running instances, have been trying to launch instances for more than 24 hours, and have not succeeded in that time in launching any instances. Auto Scaling allows you to resume both, processes suspended for administrative reasons and processes suspended following a suspension of Launch or Terminate. The following procedures walk you through the process of suspending all scaling activities on your Auto Scaling group to investigate a configuration problem with your Amazon EC2 application. After you conclude the investigation, you can resume scaling activities on the Auto Scaling group.If Auto Scaling is trying to launch an instance and if the launching of the instance fails continuously, it will suspend the processes for the Auto Scaling groups since it repeatedly failed to launch an instance. This is known as an administrative suspension. It commonly applies to the Auto Scaling group that has no running instances which is trying to launch instances for more than 24 hours, and has not succeeded in that to do so.
1. The user has to request AWS to increase the number of elastic IPs associated with the account 2. AWS allows 10 EC2 Classic IPs per region; so it will allow to allocate new Elastic IPs to the same region 3. The AWS will not allow to create a new elastic IP in VPC; it will throw an error 4. The user can allocate a new IP address in VPC as it has a different limit than EC2