SAP-C01 : AWS Certified Solutions Architect – Professional : Part 15
-
An organization, which has the AWS account ID as 999988887777, has created 50 IAM users. All the users are added to the same group ABC.
If the organization has enabled that each IAM user can login with the AWS console, which AWS login URL will the IAM users use??
- https://999988887777.aws.amazon.com/ABC/
- https://signin.aws.amazon.com/ABC/
- https://ABC.signin.aws.amazon.com/999988887777/console/
- https://999988887777.signin.aws.amazon.com/console/
Explanation:
AWS Identity and Access Management is a web service which allows organizations to manage users and user permissions for various AWS services. Once the organization has created the IAM users, they will have a separate AWS console URL to login to the AWS console. The console login URL for the IAM user will be https:// AWS_Account_ID.signin.aws.amazon.com/console/. It uses only the AWS account ID and does not depend on the group or user ID. -
Can you configure multiple Load Balancers with a single Auto Scaling group?
- No
- Yes, you can but only if it is configured with Amazon Redshift.
- Yes, you can provide the ELB is configured with Amazon AppStream.
- Yes
Explanation:
Yes, you can configure more than one load balancer with an autoscaling group. Auto Scaling integrates with Elastic Load Balancing to enable you to attach one or more load balancers to an existing Auto Scaling group. After you attach the load balancer, it automatically registers the instances in the group and distributes incoming traffic across the instances. -
An Auto Scaling group is running at the desired capacity of 5 instances and receives a trigger from the Cloudwatch Alarm to increase the capacity by 1. The cool down period is 5 minutes. Cloudwatch sends another trigger after 2 minutes to decrease the desired capacity by 1.
What will be the count of instances at the end of 4 minutes?
- 4
- 5
- 6
- 7
Explanation:
The cool down period is the time difference between the end of one scaling activity (can be start or terminate) and the start of another one (can be start or terminate). During the cool down period, Auto Scaling does not allow the desired capacity of the Auto Scaling group to be changed by any other CloudWatch alarm. Thus, in this case the trigger from the second alarm will have no effect. -
Which of the following is NOT a true statement about Auto Scaling?
- Auto Scaling can launch instances in different Azs.
- Auto Scaling can work with CloudWatch.
- Auto Scaling can launch an instance at a specific time.
- Auto Scaling can launch instances in different regions.
Explanation:
Auto Scaling provides an option to scale up and scale down based on certain conditions or triggers from Cloudwatch. A user can configure such that Auto Scaling launches instances across Azs, but it cannot span across regions. -
A user wants to configure AutoScaling which scales up when the CPU utilization is above 70% and scales down when the CPU utilization is below 30%.
How can the user configure AutoScaling for the above mentioned condition?
- Configure ELB to notify AutoScaling on load increase or decrease
- Use AutoScaling with a schedule
- Use AutoScaling by manually modifying the desired capacity during a condition
- Use dynamic AutoScaling with a policy
Explanation: The user can configure the AutoScaling group to automatically scale up and then scale down based on the specified conditions. To configure this, the user must setup policies which will get triggered by the CloudWatch alarms. -
Can a user configure a custom health check with Auto Scaling?
- Yes, but the configured data will not be saved to Auto Scaling.
- No, only an ELB health check can be configured with Auto Scaling.
- Yes
- No
Explanation:
Auto Scaling can determine the health status of an instance using custom health checks. If you have custom health checks, you can send the information from your health checks to Auto Scaling so that Auto Scaling can use this information. For example, if you determine that an instance is not functioning as expected, you can set the health status of the instance to Unhealthy. The next time that Auto Scaling performs a health check on the instance, it will determine that the instance is unhealthy and then launch a replacement instance. -
You have setup an Auto Scaling group. The cool down period for the Auto Scaling group is 7 minutes. The first scaling activity request for the Auto Scaling group is to launch two instances. It receives the activity question at time “t”, and the first instance is launched at t+3 minutes, while the second instance is launched at t+4 minutes.
How many minutes after time “t” will Auto Scaling accept another scaling activity request?
- 11 minutes
- 10 minutes
- 7 minutes
- 14 minutes
Explanation:
If an Auto Scaling group is launching more than one instance, the cool down period for each instance starts after that instance is launched. The group remains locked until the last instance that was launched has completed its cool down period. In this case the cool down period for the first instance starts after 3 minutes and finishes at the 10th minute (3+7 cool down), while for the second instance it starts at the 4th minute and finishes at the 11th minute (4+7 cool down). Thus, the Auto Scaling group will receive another request only after 11 minutes. -
You have just added a new instance to your Auto Scaling group, which receives ELB health checks. An ELB heath check says the new instance’s state is out of Service.
What does Auto Scaling do in this particular scenario?
- It replaces the instance with a healthy one
- It stops the instance
- It marks an instance as unhealthy
- It terminates the instance
Explanation:
If you have attached a load balancer to your Auto Scaling group, you can have Auto Scaling include the results of Elastic Load Balancing health checks when it determines the health status of an instance. After you add ELB health checks, Auto Scaling will mark an instance as unhealthy if Elastic Load Balancing reports the instance state as Out of Service. Frequently, an Auto Scaling instance that has just come into service needs to warm up before it can pass the Auto Scaling health check. Auto Scaling waits until the health check grace period ends before checking the health status of the instance. While the EC2 status checks and ELB health checks can complete before the health check grace period expires, Auto Scaling does not act on them until the health check grace period expires. To provide ample warm-up time for your instances, ensure that the health check grace period covers the expected startup time for your application. -
A sys admin is maintaining an application on AWS. The application is installed on EC2 and user has configured ELB and Auto Scaling. Considering future load increase, the user is planning to launch new servers proactively so that they get registered with ELB.
How can the user add these instances with Auto Scaling?
- Decrease the minimum limit of the Auto Scaling group
- Increase the maximum limit of the Auto Scaling group
- Launch an instance manually and register it with ELB on the fly
- Increase the desired capacity of the Auto Scaling group
Explanation:
A user can increase the desired capacity of the Auto Scaling group and Auto Scaling will launch a new instance as per the new capacity. The newly launched instances will be registered with ELB if Auto Scaling group is configured with ELB. If the user decreases the minimum size the instances will be removed from Auto Scaling. Increasing the maximum size will not add instances but only set the maximum instance cap. -
You have set up Auto Scaling to automatically scale in. Consequently, you must decide which instances Auto Scaling should end first.
What should you use to configure this?
- An Elastic Load Balancer
- A termination policy
- An IAM role
- Another scaling group
Explanation:
If you instruct Auto Scaling to automatically scale in, you must decide which instances Auto Scaling should terminate first. This can be configured through the use of a termination policy. -
Which of the following commands accepts binary data as parameters?
- –user-data
- –cipher text-key
- –aws-customer-key
- –describe-instances-user
Explanation:
For commands that take binary data as a parameter, specify that the data is binary content by using the fileb:// prefix.
Commands that accept binary data include: aws ec2 run-instances –user-data parameter.
aws s3api put-object –sse-customer-key parameter. aws kms decrypt –ciphertext-blob parameter. -
To scale out the AWS resources using manual AutoScaling, which of the below mentioned parameters should the user change?
- Current capacity
- Desired capacity
- Preferred capacity
- Maximum capacity
Explanation:
The Manual Scaling as part of Auto Scaling allows the user to change the capacity of Auto Scaling group. The user can add / remove EC2 instances on the fly. To execute manual scaling, the user should modify the desired capacity. AutoScaling will adjust instances as per the requirements. -
After moving an E-Commerce website for a client from a dedicated server to AWS you have also set up auto scaling to perform health checks on the instances in your group and replace instances that fail these checks. Your client has come to you with his own health check system that he wants you to use as it has proved to be very useful prior to his site running on AWS.
What do you think would be an appropriate response to this given all that you know about auto scaling and CloudWatch?
- It is not possible to implement your own health check system due to compatibility issues.
- It is not possible to implement your own health check system. You need to use AWSs health check system.
- It is possible to implement your own health check system and then send the instance’s health information directly from your system to CloudWatch but only in the US East (N. Virginia) region.
- It is possible to implement your own health check system and then send the instance’s health information directly from your system to CloudWatch.
Explanation:
Auto Scaling periodically performs health checks on the instances in your group and replaces instances that fail these checks. By default, these health checks use the results of EC2 instance status checks to determine the health of an instance. If you use a load balancer with your Auto Scaling group, you can optionally choose to include the results of Elastic Load Balancing health checks.
Auto Scaling marks an instance unhealthy if the calls to the Amazon EC2 action DescribeInstanceStatus returns any other state other than running, the system status shows impaired, or the calls to Elastic Load Balancing action DescribeInstanceHealth returns OutOfService in the instance state field.
After an instance is marked unhealthy because of an Amazon EC2 or Elastic Load Balancing health check, it is scheduled for replacement.
You can customize the health check conducted by your Auto Scaling group by specifying additional checks or by having your own health check system and then sending the instance’s health information directly from your system to Auto Scaling. -
Identify a benefit of using Auto Scaling for your application.
- Your application gains better fault tolerance.
- Your application optimizes only logistics and operations.
- Your application receives latency requirements in every region.
- You acquire clarity on prototypes in your application.
Explanation:
When you use Auto Scaling, your applications gain better fault tolerance. Auto Scaling can detect when an instance is unhealthy, terminate it, and launch an instance to replace it. You can also configure Auto Scaling to use multiple Availability Zones. If one Availability Zone becomes unavailable, Auto Scaling can launch instances in another one to compensate. -
A user has suspended the scaling process on the Auto Scaling group. A scaling activity to increase the instance count was already in progress.
What effect will the suspension have on that activity?
- No effect. The scaling activity continues
- Pauses the instance launch and launches it only after Auto Scaling is resumed
- Terminates the instance
- Stops the instance temporary
Explanation:
The user may want to stop the automated scaling processes on the Auto Scaling groups either to perform manual operations or during emergency situations. To perform this, the user can suspend one or more scaling processes at any time. When this process is suspended, Auto Scaling creates no new scaling activities for that group. Scaling activities that were already in progress before the group was suspended continue until completed. -
Does Autoscaling automatically assign tags to resources?
- No, not unless they are configured via API.
- Yes, it does.
- Yes, by default.
- No, it does not.
Explanation:
Tags don’t have any semantic meaning to Amazon EC2 and are interpreted strictly as a string of characters.
Tags are assigned automatically to the instances created by an Auto Scaling group. Auto Scaling adds a tag to the instance with a key of aws: autoscaling:groupName and a value of the name of the Auto Scaling group. -
If you have a running instance using an Amazon EBS boot partition, you can call the _______ API to release the compute resources but preserve the data on the boot partition.
- Stop Instances
- Terminate Instances
- AMI Instance
- Ping Instance
Explanation:
If you have a running instance using an Amazon EBS boot partition, you can also call the Stop Instances API to release the compute resources but preserve the data on the boot partition. -
Which EC2 functionality allows the user to place the Cluster Compute instances in clusters?
- Cluster group
- Cluster security group
- GPU units
- Cluster placement group
Explanation:
The Amazon EC2 cluster placement group functionality allows users to group cluster compute instances in clusters. -
A user has launched a dedicated EBS backed instance with EC2. You are curious where the EBS volume for this instance will be created.
Which statement is correct about the EBS volume’s creation?
- The EBS volume will not be created on the same tenant hardware assigned to the dedicated instance
- AWS does not allow a dedicated EBS backed instance launch
- The EBS volume will be created on the same tenant hardware assigned to the dedicated instance
- The user can specify where the EBS will be created
Explanation:
The dedicated instances are Amazon EC2 instances that run in a Virtual Private Cloud (VPC) on hardware that is dedicated to a single customer. When a user launches an Amazon EBS-backed dedicated instance, the EBS volume does not run on single-tenant hardware. -
Which system is used by Amazon Machine Images paravirtual (PV) virtualization during the boot process?
- PV-BOOT
- PV-AMI
- PV-WORM
- PV-GRUB
Explanation:
Amazon Machine Images that use paravirtual (PV) virtualization use a system called PV-GRUB during the boot process. PV-GRUB is a paravirtual boot loader that runs a patched version of GNU GRUB 0.97. When you start an instance, PV-GRUB starts the boot process and then chain loads the kernel specified by your image’s menu.lst file.
Subscribe
0 Comments
Newest