AWS Certified SysOps Administrator - Associate Questions and Answers (Dumps and Practice Questions)

Question : JavaSkill Inc System Administrator has configured two single availability zones. The Auto Scaling groups are configured in
separate zones. Now they wants to merge the groups such that one group spans across multiple zones. How can the user configure this?

1. Run the command as-join-auto-scaling-group to join the two groups
2. Run the command as-update-auto-scaling-group to configure one group to span across zones and delete the other group
3. Run the command as-copy-auto-scaling-group to join the two groups
4. Run the command as-merge-auto-scaling-group to merge the groups

Correct Answer : 2
Explanation: By default, an Auto Scaling group periodically reviews the results of EC2 instance status to determine the health state of each instance. However, if you
have associated your Auto Scaling group with an Elastic Load Balancing load balancer, you can choose to use the Elastic Load Balancing health check. In this case, Auto Scaling
determines the health status of your instances by checking the results of both the EC2 instance status check and the Elastic Load Balancing instance health check.

For information about EC2 instance status checks, see Monitor Instances With Status Checks in the Amazon EC2 User Guide for Linux Instances. For information about Elastic Load
Balancing health checks, see Health Check in the Elastic Load Balancing Developer Guide.Auto Scaling marks an instance unhealthy if the calls to the Amazon EC2 action

DescribeInstanceStatus return any 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.If there are multiple load balancers associated with your Auto Scaling group, Auto Scaling checks the health state of your EC2 instances by
making health check calls to each load balancer. For each call, if the Elastic Load Balancing action returns any state other than InService, the instance is marked as unhealthy.
After Auto Scaling marks an instance as unhealthy, it remains in that state, even if subsequent calls from other load balancers return an InService state for the same instance.

Frequently, new instances need to warm up briefly before they can pass a health check. To provide ample warm-up time, set the health check grace period of the group to cover the
expected startup period of your application. Auto Scaling waits until the grace period ends before checking the health status of the instance. The grace period starts after the
instance passes the EC2 system status check and instance status check.The following examples shows you how to add an Elastic Load Balancing health check to your Auto Scaling group,
assuming that you have created a load balancer and have registered the load balancer with your Auto Scaling group. If you have not registered the load balancer with your Auto Scaling
group,If the user has configured two separate single availability zone Auto Scaling groups and wants to merge them then he should update one of the groups and delete the other one.
While updating the first group it is recommended that the user should increase the size of the minimum, maximum and desired capacity as a summation of both the groups.

Adding a Health Check Using the Auto Scaling CLI

Use the following update-auto-scaling-group command to create a health check with a grace period of 300 seconds:
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-test-asg-lbs --health-check-type ELB --health-check-grace-period 300
When Auto Scaling checks the health status, it ignores instances that have been in the InService state for less than the number of seconds you specified using --grace-period.

Adding a Health Check Using the Auto Scaling CLI
Use the following as-update-auto-scaling-group command to create a health check with a grace period of 300 seconds:
as-update-auto-scaling-group my-test-asg-lbs --health-check-type ELB --grace-period 300
You should get a confirmation similar to the following:

OK-Updated AutoScalingGroup
When Auto Scaling checks the health status, it ignores instances that have been in the InService state for less than the number of seconds you specified using --grace-period.

Question : An AWS account wants to be part of the consolidated billing of his organization's payee account. How can the owner of that account achieve this?

1. The payee account has to request AWS support to link the other accounts with his account
2. The owner of the linked account should add the payee account to his master account list from the billing console
3. The payee account will send a request to the linked account to be a part of consolidated billing
4. The owner of the linked account requests the payee account to add his account to consolidated billing

Correct Answer : 3
Explanation: Pay Bills for Multiple Accounts with Consolidated Billing
You can use the Consolidated Billing feature to consolidate payment for multiple Amazon Web Services (AWS) accounts within your organization by designating one of them to be the
payer account. With Consolidated Billing, you can see a combined view of AWS charges incurred by all accounts, as well as get a detailed cost report for each individual AWS accounts
associated with your payer account. Consolidated Billing is offered at no additional charge.
Flow Elements : AWS consolidated billing enables the organization to consolidate payments for multiple Amazon Web Services (AWS. accounts within a single organization by making a
single paying account. To add a particular account (linked. to the master (payee. account, the payee account has to request the linked account to join consolidated billing. Once the
linked account accepts the request henceforth all charges incurred by the linked account will be paid by the payee account.
When to Use Consolidated Billing
The Consolidated Billing feature is probably a good option for you in any of the following scenarios:
You have multiple accounts today and want to get a single bill and track each account's charges (e.g., you might have multiple projects, each with its own AWS account).
You have multiple cost centers to track.
You've acquired a project or company that has its own existing AWS account and you want to consolidate it on the same bill with your other AWS accounts.
Consolidated Billing is strictly an accounting and billing feature. It is not a method for controlling accounts, or provisioning resources for accounts. It doesn't change how the
accounts function or how they are accessed. Consolidated Billing, therefore, cannot be used for sharing computing resources between accounts.
Note : You can also use cost allocation tagging to create a custom tag set that maps to your organization's cost centers.
Billing and Account Activity

Each month, AWS charges the payer account owner, and not the owners of the linked accounts. The paying account's AWS Bills page shows the total usage and charges across all the
accounts on the bill. That page is updated multiple times each day. Each day, AWS makes a downloadable cost report available.

Although the owners of the linked accounts aren't charged, they can still see their usage and charges by going to their AWS Bills pages. They can't view or obtain data for the paying
account or any other linked accounts on the bill.

Question : A sysadmin has created the below mentioned policy on an S bucket named hadoopexam. What does this policy define?
"Statement": [{
"Sid": "Stmt1388811069831",
"Effect": "Allow",
"Principal": { "AWS": "*"},
"Action": [ "s3:GetObjectAcl", "s3:ListBucket"],
"Resource": [ "arn:aws:s3:::hadoopexam]
}]

1. It will make the hadoopexam bucket as well as all its objects as public
2. It will allow everyone to view the ACL of the bucket
3. It will give an error as no object is defined as part of the policy while the action defines the rule about the object
4. It will make the hadoopexam bucket as public

Correct Answers: 4
Explanation: A sysadmin can grant permission to the S3 objects or the buckets to any user or make objects public using the bucket policy and user policy. Both use the
JSON-based access policy language. Generally if the user is defining the ACL on the bucket, the objects in the bucket do not inherit it and
vice a versa. The bucket policy can be defined at the bucket level which allows the objects as well as the bucket to be public with a single policy applied to that bucket. In the
sample policy the action says "S3:ListBucket" for effect Allow on Resource arn:aws:s3:::hadoopexam. This will make the hadoopexam bucket public.
"Statement": [{
"Sid": "Stmt1388811069831",
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": [ "s3:GetObjectAcl", "s3:ListBucket"],
"Resource": [ "arn:aws:s3:::hadoopexam]
}]
Amazon S3 allows you to set per-file permissions to grant read and/or write access. This is nice, but sometimes you just want to share your whole bucket with the world. Luckily,
Amazon features bucket policies, which allow you to define permissions for an entire bucket. ~ This example will give read access to Everyone on all files in your bucket.
{ "Version":"2008-10-17",
"Statement":[{
"Sid":"AllowPublicRead",
"Effect":"Allow",
"Principal": {
"AWS": "*"
},
"Action":["s3:GetObject"],
"Resource":["arn:aws:s3:::bucket/*"
] } ] }
Make sure you replace bucket in arn:aws:s3:::bucket/* with your bucket name. After setting this bucket policy (see 'Bucket -> Properties -> Add Bucket Policy'), all your files will
be publicly readable.

AWS Certified SysOps Administrator - Associate Questions and Answers (Dumps and Practice Questions)

Related Questions