AWS CodeDeploy Interview Questions And Answers

Introduction

AWS CodeDeploy makes it easier for developers to quickly release application updates by automating code deployments to any instance, like a magic wand that helps your code smoothly transition from your computer to the servers where your application runs. For beginners, understanding CodeDeploy with our AWS CodeDeploy interview questions and answers can be a game-changer in interviews, as employers prefer candidates who are familiar with AWS services because it's widely used in the industry.

Q1: What Is A Repository (Repo)?

A: A repository (repo) is the foundation of AWS CodeCommit. This is where you store source code files, track revisions, and merge contributions (commits). By default, when you create a repository, it will contain an empty main branch. To configure additional branches and commit code changes, you connect the repository to a local workstation where changes can be made before you upload or push them.

Q2: What Is "Revision" In AWS CodePipeline?

A: A revision is the work item that passes through a pipeline. It can be a change to your source code or data stored in AWS CodeCommit or GitHub or a change to the version of an archive in Amazon S3. 

A pipeline can have multiple revisions flowing through it simultaneously, but a single stage can process one revision at a time. A source action immediately picks up a revision when a change is detected in the source itself (such as a commit to an AWS CodeCommit repository).

Q3: What Is "Approval" In AWS CodePipeline?

A: An approval action is a manual gate that controls whether a revision can proceed to the next stage in a pipeline. Further progress by a revision is halted until a manual approval by an IAM user or IAM role occurs.

AWS CodePipeline approves the revision to proceed to the next stage in the pipeline; however, if the revision is not approved (rejected or the approval expires), the change halts and will stop progress through the pipeline; this action aims to allow manual review of the code or other quality assurance tasks before moving further down the pipeline.

Q4: What Is Phase mapping?

A: The phases map specified commands to run at each stage of the build job. When you specify build settings in the AWS CodeBuild console, AWS CLI, or AWS SDK, you cannot separate commands into phases. However, you can separate commands into phases with a build specifications file.

• Install Commands to execute during the installation of the build environment.

• pre_build Commands to be run before the build begins.

• Build Commands to be run during the build.

• post_build Commands are to be run after the build is complete.

Q5: What Is The Use Of Deployment configuration?

A: You use deployment configurations to drive how quickly Amazon EC2 on-premises instances update by AWS CodeDeploy. You can configure deployments to deploy to all instances in a deployment group at once or subgroups of instances at a time, or you can create an entirely new group of instances (blue/green deployment). 

A deployment configuration also specifies the fault tolerance of deployments, so you can roll back changes if a specified number or percentage of instances or functions in your deployment group fail to complete their deployments and signal success back to AWS CodeDeploy.

Q6: What Is AWS CodePipeline

A: The AWS "Code" services lay the foundation for deploying different parts of an enterprise, starting from a source repository. You start with AWS CodePipeline to create a continuous integration/continuous deployment pipeline (CI/CD) that integrates various sources, tests, deployments, or other components. 

AWS CodePipeline implements AWS CodeCommit as a source in that it acts as the initialization point of your deployment process. AWS CodeBuild lets you pull code and packages from various sources to create publishable build artifacts. 

Lastly, AWS CodeDeploy allows you to deploy compiled artifacts to the infrastructure in your environment. AWS CodePipeline is not limited to deploying application code; it can also be used to provision, configure, and manage infrastructure.

Q7: What Is "Revision" In AWS CodePipeline? And How Do You Use GitHub As A Source Provider?

A: The source action defines the location where you store and update source files. Modifications

to files in a source repository or archive trigger deployments to a pipeline. AWS CodePipeline

supports these sources for your pipeline:

• Amazon S3

• AWS CodeCommit

• GitHub

To use GitHub as a source provider for AWS CodePipeline, you must authenticate to GitHub when you create a pipeline. You provide GitHub credentials to authorize AWS CodePipeline to connect to GitHub to list and view repositories accessible by the authenticating account. For this link, AWS recommends creating a service account user so that the lifecycle of personal accounts is not tied to the link between AWS CodePipeline and GitHub.

After you authenticate GitHub, a link is created between AWS CodePipeline for this AWS region and GitHub. This allows IAM users to list repositories and branches accessible by the authenticated GitHub user.

Q8: What Is "Transition" In AWS CodePipeline?

A: Transitions connect stages in a pipeline and define which stages should transition to one another. When all actions in a stage are completed successfully, the revision passes to the next stage(s) in the pipeline. 

You can manually turn off transitions, which stops all revisions in the pipeline once they complete the preceding stage (successfully or unsuccessfully). Once you enable the transition again, the most recent successful revision resumes. Other previous successful revisions will not resume through the pipeline at this time. 

This concept also applies to stages that must be available when the next revision is completed. They will be batched if more than one revision is completed while the next stage is unavailable. This means the most current revision will continue through the pipeline once the next stage becomes available.

Q9: What Is AWS CodeCommit?

A: Before any activities can occur to deploy applications, you must first have a location where you can store and version application code reliably. 

AWS CodeCommit is a cloud-based, highly available, and redundant version control service. AWS CodeCommit leverages the Git framework and is fully compatible with existing tooling. There are several benefits to this service, such as the following:

• Automatic encryption in transit and at rest.

• Scaling to handle rapid release cycles and large repositories.

• Access control to the repository using IAM users, IAM roles, and IAM policies.

• Hypertext Transfer Protocol Secure (HTTPS) and Secure Shell (SSH) connectivity.

Q10: What Are Some Event Types That'll Fire Repository Notifications?

A: AWS CodeCommit supports triggers via Amazon SNS, which you can use to leverage other AWS services for post-commit actions, such as firing a webhook with AWS Lambda after a commit is pushed to a development branch. 

To implement this, AWS CodeCommit uses AWS CloudWatch Events. You create event rules that trigger for each of the event types that you select in AWS CodeCommit. Event types that will fire notifications include the following:

• Pull Request Update Events

• Create a Pull Request

• Close a Pull Request

• Update Code in a Pull Request

• Title or Description Changes

• Pull Request Comment Events

• Commit Comment Events

• Comments on Code Changes

• Comments on Files in a Commit

• Comments on the Commit Itself

Q11: What Are Repository Triggers?

A: Repository triggers are not the same as notifications, as the events that fire each differ significantly. Use repository triggers to send notifications to Amazon SNS or AWS Lambda during these events:

• Push to the Existing Branch

• Create a Branch or Tag

• Delete a Branch or Tag

Triggers are similar in functionality to webhooks used by other Git providers like GitHub. You can use triggers to perform automated tasks such as starting external builds, notifying administrators of code pushes, or performing unit tests. There are some restrictions on how to configure triggers.

• The trigger destination, Amazon SNS or AWS Lambda, must exist in the same AWS region as the repository.

• If the destination is Amazon SNS in another AWS account, the Amazon SNS topic must have a policy that allows notifications from the repository account.

Q12: What Are Pull Requests? And How Do They Work?

A: Pull requests are the primary vehicle for reviewing and merging code changes between branches. Unlike branch merging, pull requests allow multiple users to comment on changes before they merge with the destination branch. The typical workflow of a pull request is as follows:

1. Create a new branch of the default for the feature or bug fix.

2. Make changes to the branch files, commit, and push to the remote repository.

3. Create a pull request for the changes to integrate them with the default branch.

4. Other users can review the changes in the pull request and provide comments.

5. You can add changes from user feedback to the pull request in the same branch.

6. Once all reviewers approve, the pull request merges into the default branch and closes. You can close pull requests when you merge the branches locally or close the request via the AWS CodeCommit console or the AWS CLI.

Q13: What is AWS CodeBuild?

A: AWS CodeBuild enables you to define the build environment to perform build tasks and the actual tasks it will perform. AWS CodeBuild has prepackaged build environments for the most common workloads and build tools (Apache Maven, Grade, and others). It allows you to create custom environments for any custom tools or processes. AWS CodePipeline includes built-in integration with AWS CodeBuild, which can act as a provider for any build or test actions in your pipeline. AWS CodeBuild is a fully managed build service that compiles source code, runs tests, and produces software packages ready to deploy. With AWS CodeBuild, you do not need to provision, manage, and scale your build servers.

Q14: What Is AWS CodeDeploy?

A: AWS CodeDeploy standardizes and automates deployments of any type of content or configuration to Amazon EC2 instances, on-premises servers, or AWS Lambda functions. Because of its flexibility, it is not restricted to deploying only application code. It can also perform various administrative tasks that are part of your deployment process. 

Additionally, you can create custom deployment configurations tailored to your specific infrastructure needs. You can configure AWS CodeDeploy with a predetermined failure tolerance if deployments fail in your environment. Once this tolerance is breached, deployment will automatically roll back to the last working version.

You can automate the deployment of AWS CodeDeploy with AWS Lambda functions through traffic switching. When functions are updated, AWS CodeDeploy creates new versions of each updated function and gradually routes requests from the previous version to the updated function. AWS Lambda functions also support custom deployment configurations, which can specify the rate and percentage of traffic to switch.

Q15: What Is The Deployment Group?

A: A deployment group designates the Amazon EC2 on-premises instances that a revision deploys. When you deploy to AWS Lambda functions, this specifies what functions will deploy new versions. Deployment groups also specify alarms that trigger automatic rollbacks after a specified number or percentage of instances or functions fail their deployment.

For Amazon EC2 on-premises deployments, you can add instances to a deployment group based on tag name/value pairs or Amazon EC2 Auto Scaling group names. An individual application can have one or more deployment groups defined. 

This allows you to separate groups of instances into environments so that changes can be progressively rolled out and tested before going to production. You can identify instances by individual tags or tag groups. 

If an instance matches one or more tags in a tag group, it is associated with the deployment group. If you would like to require that an instance match multiple tags, each tag must be in a separate tag group. A single deployment group supports up to 10 tags in up to three tag groups.

Q16: Explain Amazon EC2 On-Premises Deployment Configurations

A: When you deploy to Amazon EC2 on-premises instances, you can configure in-place or blue/green deployments.

In-Place deployments- These deployments recycle currently running instances and deploy revisions on existing instances.

Blue/Green deployments- These deployments replace currently running instances with sets of newly created instances.

In both scenarios, you can specify wait times between groups of deployed instances (batches). Additionally, if you register the deployment group with an elastic load balancer, newly deployed instances also register with the load balancer and are subject to its health checks.

The deployment configuration specifies success criteria for deployments, such as the minimum number of healthy instances that must pass health checks during deployment. This is done to maintain required availability during application updates. AWS CodeDeploy provides three built-in deployment configurations.

Q17: What Are The Three Methods For Handling Traffic Switching In AWS Lambda?

A: AWS CodeDeploy supports three methods for handling traffic switching in an AWS Lambda environment.

Canary

Traffic shifts in two percentage-based increments. The first increment routes to the new function version and is monitored for the number of minutes you define. After this period, the remainder of traffic routes to the new version if the initial request increment executes.

AWS CodeDeploy provides several built-in canary-based deployment configurations, such as Code Deploy Default. Lambda Canary 10Percent in 15 Minutes. If you use this deployment configuration, 10 percent of traffic shifts in the first increment and is monitored for 15 minutes. After this period, 90 percent of the remaining traffic shifts to the new function version. You can create additional configurations as needed.

Linear

Traffic can be shifted in percentage-based increments, with a set number of minutes between each increment. During the waiting period between each increment, the requests routed to the new function versions must be completed successfully for the deployment to continue.

AWS CodeDeploy provides several built-in linear deployment configurations, such as Code Deploy Default. Lambda Linear 10 Percent in Every1 Minute. With this configuration, 10 percent of traffic is routed to the new function version every minute until all traffic is routed after 10 minutes.

All-at-Once

All traffic is shifted at once to the new function versions.

Conclusion

JanBask Training's AWS courses can benefit beginners looking to ace interviews, especially with topics like AWS CodeDeploy. By enrolling in JanBask Training, beginners can gain a deep understanding of AWS CodeDeploy and other essential services, preparing them to tackle interview questions related to cloud deployment strategies confidently.