Question : An organization has created one IAM user and applied the below mentioned policy to the user. What entitlements do the IAM users avail with this policy? { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" },{ "Effect": "Allow" "Action": [ "cloudwatch:ListMetrics", "cloudwatch:GetMetricStatistics", "cloudwatch:Describe*" ], "Resource": "*" },{ "Effect": "Allow", "Action": "autoscaling:Describe*", "Resource": "*" }]} 1. The policy will allow the user to perform all read only activities on the EC2 services 2. The policy will allow the user to list all the EC2 resources except EBS 3. The policy will allow the user to perform all read and write activities on the EC2 services 4. The policy will allow the user to perform all read only activities on the EC2 services except load Balancing
Correct Answer : 4 Explanation: AWS Identity and Access Management is a web service which allows organizations to manage users and user permissions for various AWS services. If an organization wants to setup read only access to EC2 for a particular user, they should mention the action in the IAM policy which entitles the user for Describe rights for EC2, CloudWatch, Auto Scaling and ELB. In the policy shown below, the user will have read only access for EC2 and EBS, CloudWatch and Auto Scaling. Since ELB is not mentioned as a part of the list, the user will not have access to ELB. { "Version": "2012-10-17", "Statement": [ {"Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" },{ "Effect": "Allow", "Action": [ "cloudwatch:ListMetrics", "cloudwatch:GetMetricStatistics", "cloudwatch:Describe*" ],"Resource": "*" },{ "Effect": "Allow", "Action": "autoscaling:Describe*", "Resource": "*" }]}
Question : A user has enabled session stickiness with ELB. The user does not want ELB to manage the cookie; instead he wants the application to manage the cookie. What will happen when the server instance, which is bound to a cookie, crashes? 1. The response will have a cookie but stickiness will be deleted 2. The session will not be sticky until a new cookie is inserted 3. ELB will throw an error due to cookie unavailability 4. The session will be sticky and ELB will route requests to another server as ELB keeps replicating the Cookie
Correct Answer : 2 Explanation: Sticky Sessions
By default, a load balancer routes each request independently to the application instance with the smallest load. However, you can use the sticky session feature (also known as session affinity) which enables the load balancer to bind a user's session to a specific application instance. This ensures that all requests coming from the user during the session will be sent to the same application instance.
You can use sticky sessions for only HTTP/HTTPS load balancer listeners.
The key to managing the sticky session is determining how long should your load balancer consistently route the user's request to the same application instance. If your application has its own session cookie, then you can set Elastic Load Balancing to create the session cookie to follow the duration specified by the application's session cookie. If your application does not have its own session cookie, then you can set Elastic Load Balancing to create a session cookie by specifying your own stickiness duration.
The load balancer uses a special load-balancer-generated cookie to track the application instance for each request. When the load balancer receives a request, it first checks to see if this cookie is present in the request. If so, the request is sent to the application instance specified in the cookie. If there is no cookie, the load balancer chooses an application instance based on the existing load balancing algorithm. A cookie is inserted into the response for binding subsequent requests from the same user to that application instance. The stickiness policy configuration defines a cookie expiration, which establishes the duration of validity for each cookie. The cookie is automatically updated after its duration expires. If an application instance fails or becomes unhealthy, the load balancer stops routing request to that instance, instead chooses a new instance based on the existing load balancing algorithm. The request is routed to the new instance as if there is no cookie and the session is no longer sticky.
In this example, you create a stickiness policy and then use it to enable sticky sessions for a load balancer that has load balancer-generated HTTP cookies. Before you get started, make sure you have a HTTP/HTTPS load balancer.
With Elastic Load Balancer, if the admin has enabled a sticky session with application controlled stickiness, the load balancer uses a special cookie generated by the application to associate the session with the original server which handles the request. ELB follows the lifetime of the application-generated cookie corresponding to the cookie name specified in the ELB policy configuration. The load balancer only inserts a new stickiness cookie if the application response includes a new application cookie. The load balancer stickiness cookie does not update with each request. If the application cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.
Question : A user is observing the EC CPU utilization metric on CloudWatch. The user has observed some interesting patterns while filtering over the week period for a particular hour. The user wants to zoom that data point to a more granular period. How can the user do that easily with CloudWatch? 1. The user can zoom a particular period by selecting that period with the mouse and then releasing the mouse 2. The user can zoom a particular period by double clicking on that period with the mouse 3. The user can zoom a particular period by specifying the aggregation data for that period 4. The user can zoom a particular period by specifying the period in the Time Range
Correct Answer : 1
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
1. Send the data using the put-metric-data command with the aggregate-values parameter 2. Send the data using the put-metric-data command with the average-values parameter 3. Access Mostly Uused Products by 50000+ Subscribers 4. Send the data using the put-metric-data command with the aggregate -data parameter