A company is examining its disaster recovery capability and wants the ability to switch over its daily operations to a secondary AWS Region. The company uses AWS CodeCommit as a source control tool in the primary Region.
A DevOps engineer must provide the capability for the company to develop code in the secondary Region. If the company needs to use the secondary Region, developers can add an additional remote URL to their local Git configuration.
Which solution will meet these requirements?
To meet the requirement of enabling the company to develop code in the secondary AWS Region, the best solution is to create a CodeCommit repository in both the primary and secondary regions and ensure they are synchronized. This allows developers to add a remote URL to their local Git configuration, making it easy to switch to the secondary region if needed. Creating a CodeCommit repository directly in the secondary region, along with using an automated process like CodeBuild to perform a Git mirror operation triggered by merge events via EventBridge, ensures updates are reflected in both repositories. This setup provides a reliable solution to keep repositories synchronized across regions, meeting operational and disaster recovery needs effectively.
https://dev.to/apatil88/replicate-aws-codecommit-repositories-between-regions-using-codebuild-and-codepipeline-5fh1
This solution meets all of the company's requirements: It allows developers to add an additional remote URL to their local Git configuration to develop code in the secondary Region. It is automated: the EventBridge rule will automatically invoke the Lambda function whenever a merge event occurs in the primary Region's CodeCommit repository. It is reliable: the CodeBuild project will use Git to ensure that a perfect copy of the primary Region's CodeCommit repository is created in the secondary Region.
A is correct: <A DevOps engineer must provide the capability for the company to develop code in the secondary Region> means code commit
A is correct: < develop code in the secondary Region>: code commit cannot automatically clone cross-region.Must use a tool to do this duplication task B: Using S3 as a secondary repo is incorrect C and D: no mention of using codecommit as the secondary repo
B is right. https://aws.amazon.com/cn/blogs/devops/replicate-aws-codecommit-repository-between-regions-using-aws-fargate/
B is wrong because it uses S3. Developers need a valid git remote URL. Correct answer is A
A is at least operation and cost
B- It does the replication out of the box and meets the requirements https://aws.amazon.com/blogs/devops/replicate-aws-codecommit-repository-between-regions-using-aws-fargate/
This part of B is incorrect. - It should use Code commit instead of S3. "Create an AWS Fargate task to perform a Git mirror operation of the primary Region's CodeCommit repository and copy the result to the S3 bucket. "
Agree answer is A
A: (NO) "Create an AWS CodeBuild project to perform a Git mirror operation of the primary Region's CodeCommit repository to the secondary Region's CodeCommit repository." CodeBuild doesn't have the ability to do a "git mirror" operation itself. All online examples have CodeCommit actions calling Lambda (directly or through EventWatch) which calls fargate (or EC2) which does the actual git mirror A: (NO) "Create an AWS Lambda function that invokes the CodeBuild project. The is exactly the reverse from online examples B: (NO) "Create an AWS Fargate task to perform a Git mirror operation of the primary Region's CodeCommit repository and copy the result to the S3 bucket." Does it really make sense to use a "git" mirror operations copy from a CodeCommit repo to an S3 bucket? All online examples using "git" "mirror" have CodeCommit repo as remote target.
The specific requirement here isn't "disaster recovery capability" and "ability to switch over its daily operations to a secondary AWS Region." That is just being investigated. The specific requirement is to "provide the capability for the company to develop code in the secondary Region." "If the company needs to use the secondary Region, developers can add an additional remote URL to their local Git configuration." To me this sounds to like the specific requirement here is only to provide developers with a complete remote development environment (not to provide a DR solution) If that is true, then using Cloud9 web development environment (includes git, etc.) with same local CodeCommit repo is acceptiable I'm not a developer, but the specific criteria wording and logic make me lean towards "C"
Actually, I meant to say I lean towards "D" (using Cloud9 as remote development environment)
Also want to add that "D" would would work fine if you presume that the "git" "mirror" is also being done (though additional undefined step in the solution). Nothing says "D" is the complete solution. The ONLY requirement here is to provide developers a remote environment to develop in.
Flow: AWS Example: CodeCommit(action) ----------------> Lambda -> Fargate task ("git clone --mirror" local repo, "git remote set-url --push origin" destination repo) -> CodeCommit(remote repo) Solution "B": CodeCommit(action) -> EventBridge -> Lambda -> Fargate task ("git clone --mirror" local repo, "git remote set-url --push origin" destination repo) -> S3(remote bucket) References: https://aws.amazon.com/blogs/devops/replicate-aws-codecommit-repository-between-regions-using-aws-fargate/ https://aws.amazon.com/cloud9/
Why is not D a solution? If the developers in the secondary region can configure primary region's codecommit repository as a remote repository in the AWS Cloud9 environment they can do development and do all git functions remote.