After you have your stacks and resources set up, you can reuse your templates to replicate your infrastructure in multiple environments. For example, you can create environments for development, testing, and production so that you can test changes before implementing them into production. To make templates reusable, use the parameters, mappings, and conditions sections so that you can customize your stacks when you create them. For example, for your development environments, you can specify a lower-cost instance type compared to your production environment, but all other configurations and settings remain the same For more information on Cloudformation best practises please refer to the below link: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html The correct answer is: Develop models of your entire cloud system in CloudFormation. Use this model in Staging and Production to achieve greater parity.

For more information please refer to the below document link from AWS https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources. For example, you might want to grant users in your AWS account access to resources they don't usually have, or grant users in one AWS account access to resources in another account. Or you might want to allow a mobile app to use AWS resources, but not want to embed AWS keys within the app (where they can be difficult to rotate and where users can potentially extract them). Sometimes you want to give AWS access to users who already have identities defined outside of AWS, such as in your corporate directory. Or, you might want to grant access to your account to third parties so that they can perform an audit on your resources. For more information on IAM Roles , please refer to the below document link: from AWS http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html The correct answer is: Assign an IAM role to your Amazon EC2 instance, and use this IAM role to access the Amazon RDS DB from your Amazon EC2 instances.

This an example of Blue green deployment With Amazon Route 53, you can define a percentage of traffic to go to the green environment and gradually update the weights until the green environment carries the full production traffic. A weighted distribution provides the ability to perform canary analysis where a small percentage of production traffic is introduced to a new environment. You can test the new code and monitor for errors, limiting the blast radius if any issues are encountered. It also allows the green environment to scale out to support the full production load if you’re using Elastic Load Balancing For more information on Blue green deployment, please refer to the link: https://d0.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf The correct answer is: Using AWS CloudFormation templates, create one Elastic Beanstalk application and all AWS resources (in the same template) for each web application. New versions would be deployed using AWS CloudFormation templates to create new Elastic Beanstalk environments, and traffic would be balanced between them using weighted Round Robin (WRR) records in Amazon Route 53.

You can use the container_commands key to execute commands that affect your application source code. Container commands run after the application and web server have been set up and the application version archive has been extracted, but before the application version is deployed. Non-container commands and other customization operations are performed prior to the application source code being extracted. You can use leader_only to only run the command on a single instance, or configure a test to only run the command when a test command evaluates to true. Leader-only container commands are only executed during environment creation and deployments, while other commands and server customization operations are performed every time an instance is provisioned or updated. Leader-only container commands are not executed due to launch configuration changes, such as a change in the AMI Id or instance type. For more information on customizing containers, please visit the below URL: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html The correct answer is: Use a "Container command" within an Elastic Beanstalk configuration file to execute the script, ensuring that the "leader only" flag is set to true.

Please check the following AWS DOCs which provides details on the scenario. Check the example of "configure". https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-events.html You can use the Configure Lifecycle event This event occurs on all of the stack's instances when one of the following occurs: An instance enters or leaves the online state. You associate an Elastic IP address with an instance or disassociate one from an instance. You attach an Elastic Load Balancing load balancer to a layer, or detach one from a layer. Ensure the Opswork layer uses a custom Cookbook For more information on Opswork stacks , please refer to the below document link: from AWS http://docs.aws.amazon.com/opsworks/latest/userguide/welcome_classic.html The correct answer is: Create a Chef Recipe to update this configuration file, configure your AWS OpsWorks stack to use custom cookbooks, and assign this recipe to the Configure LifeCycle Event of the specific layer.

Option A is invalid because there is no "aws git.push" command Option B is invalid because there is no AWS::EC2::Container resource type. Elastic Beanstalk supports the deployment of web applications from Docker containers. With Docker containers, you can define your own runtime environment. You can choose your own platform, programming language, and any application dependencies (such as package managers or tools), that aren't supported by other platforms. Docker containers are self-contained and include all the configuration information and software your web application requires to run. For more information on Docker and Elastic beanstalk please refer to the below link: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html When you launch an instance in Amazon EC2, you have the option of passing user data to the instance that can be used to perform common automated configuration tasks and even run scripts after the instance starts. You can pass two types of user data to Amazon EC2: shell scripts and cloud-init directives. You can also pass this data into the launch wizard as plain text, as a file (this is useful for launching instances using the command line tools), or as base64-encoded text (for API calls). For more information on Ec2 User data please refer to the below link: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html The correct answers are: Create a Docker file to install Node.js. and gets the code from Git. Use the Dockerfile to perform the deployment on a new AWS Elastic Beanstalk application., Create an AWS CloudFormation template which creates an instance with the AWS::EC2::Instance resource type and an AMI with Docker pre-installed. With UserData, install Git to download the Node.js application and then set it up.

An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts. A private S3 bucket can be created for each developer, the keys can be stored in the bucket and then assigned to the instance profile. Option A and D are invalid , because the credentials should not be provided by a AWS EC2 Instance. Option B is invalid because you would not create a service account, instead you should create an instance profile. For more information on Instance profiles , please refer to the below document link: from AWS http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html The correct answer is: Place each developer’s own public key into a private S3 bucket, use instance profiles and configuration management to create a user account for each developer on all instances, and place the user’s public keys into the appropriate account.

During the AMI-creation process, Amazon EC2 creates snapshots of your instance's root volume and any other EBS volumes attached to your instance New EBS volumes receive their maximum performance the moment that they are available and do not require initialization (formerly known as pre-warming). However, storage blocks on volumes that were restored from snapshots must be initialized (pulled down from Amazon S3 and written to the volume) before you can access the block. This preliminary action takes time and can cause a significant increase in the latency of an I/O operation the first time each block is accessed. For most applications, amortizing this cost over the lifetime of the volume is acceptable. Option A is invalid because block sizes are predetermined and should not be randomly selected. Option C is invalid because this is part of continuous integration and hence volumes can be destroyed after the test and hence there should not be snapshots created unnecessarily Option D is invalid because the encryption is a security feature and not part of load tests normally. For more information on EBS initialization please refer to the below link: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html The correct answer is: Ensure that the Amazon EBS volumes have been pre-warmed by reading all the blocks before the test.

A Dockerrun.aws.json file is an Elastic Beanstalk–specific JSON file that describes how to deploy a set of Docker containers as an Elastic Beanstalk application. You can use aDockerrun.aws.json file for a multicontainer Docker environment. Dockerrun.aws.json describes the containers to deploy to each container instance in the environment as well as the data volumes to create on the host instance for the containers to mount. http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker_v2config.html The correct answer is: Dockerrun.aws.json

Elastic Beanstalk simplifies this process by managing the Amazon SQS queue and running a daemon process on each instance that reads from the queue for you. When the daemon pulls an item from the queue, it sends an HTTP POST request locally to http://localhost/ with the contents of the queue message in the body. All that your application needs to do is perform the long-running task in response to the POST. For more information Elastic Beanstalk managing worker environments, please visit the below URL: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html The correct answer is: Manages a Amazon SQS queue and running a daemon process on each instance

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. Option A and D are invalid because you can do build tests on a CI system and not only Syntax tests. And Syntax tests are normally done during coding time and not during the build time. Option C is invalid because Opswork is ideally not used for build and integration tests. For an example of a Continous integration system, please refer to the Jenkins system via the url below https://jenkins.io/ The correct answer is: Perform syntax and build tests on the continuous integration system before launching the new Amazon EC2 instance unit and integration tests.

The AWS::AutoScaling::AutoScalingGroup resource supports an UpdatePolicy attribute. This is used to define how an Auto Scaling group resource is updated when an update to the CloudFormation stack occurs. A common approach to updating an Auto Scaling group is to perform a rolling update, which is done by specifying the AutoScalingRollingUpdate policy. This retains the same Auto Scaling group and replaces old instances with new ones, according to the parameters specified. Option A is invalid because it not efficient to use Cloudformation to use Elastic Beanstalk. Option D is invalid because this is an inefficient process to tear down stacks when there are stack policies available For more information on Autoscaling Rolling Updates please refer to the below link: https://aws.amazon.com/premiumsupport/knowledge-center/auto-scaling-group-rolling-updates/ The correct answers are: Re-deploy with a CloudFormation template, define update policies on Auto Scaling groups in your CloudFormation template, Use update stack policies with CloudFormation to deploy new code

The following diagram shows the lifecycle of the instances in Autoscaling You can put the instances in a standby state , via the application , do the processing and then put the instance back in a state where it can be governed by the Autoscaling Group. For more information on the Autoscaling Group Lifecycle please refer to the below link: http://docs.aws.amazon.com/autoscaling/latest/userguide/AutoScalingGroupLifecycle.html The correct answer is: Modify the application running on the instances to put itself into an Auto Scaling Standby state while it processes a task and return itself to InService when the processing is complete.

You can add another layer of protection by enabling MFA Delete on a versioned bucket. Once you do so, you must provide your AWS account’s access keys and a valid code from the account’s MFA device in order to permanently delete an object version or suspend or reactivate versioning on the bucket. For more information on MFA please refer to the below link: https://aws.amazon.com/blogs/security/securing-access-to-aws-using-mfa-part-3/ IAM roles are designed so that your applications can securely make API requests from your instances, without requiring you to manage the security credentials that the applications use. Instead of creating and distributing your AWS credentials, you can delegate permission to make API requests using IAM roles For more information on Roles for EC2 please refer to the below link: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html Option A is invalid because this will not address either the integrity or security concern completely. Option C is invalid because user credentials should never be used in EC2 instances to access AWS resources. Option E and F are invalid because AWS Pipeline is an unnecessary overhead when you already have inbuilt controls to manager security for S3. The correct answers are: Add an Amazon S3 bucket policy with a condition statement that requires multi-factor authentication in order to delete objects and enable bucket versioning., Create an Amazon Identity and Access Management role with authorization to access the Amazon S3 bucket, and launch all of your application’s Amazon EC2 instances with this role.

The Weighted Routing policy of Route53 can be used to direct a proportion of traffic to your application. The best option is to create a second ELB, attach the new Autoscaling Group and then use Route53 to divert the traffic. Option B is wrong because just having EC2 instances running with the new code will not help. Option C is wrong because Elastic beanstalk is good for development environments , and also there is no mention of having 2 environments where environment url’s can be swapped. Option D is wrong because you still need Route53 to split the traffic. For more information on Route53 routing policies , please refer to the below link: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html The correct answer is: Create a second ELB, Auto Scaling. Create the AMI with the new app. Use a new launch configuration. Use Route 53 Weighted Round Robin records to adjust the proportion of traffic hitting the two ELBs.