A developer is preparing to begin development of a new version of an application. The previous version of the application is deployed in a production environment. The developer needs to deploy fixes a

Question

Options

• AFrom the main branch, create a feature branch for production bug fixes. Create a second feature
• BCreate a Git tag of the code that is currently deployed in production. Create a Git tag for the
• CFrom the main branch, create a branch of the code that is currently deployed in production. Apply
• DCreate a new CodeCommit repository for development of the new version of the application.

• A
  71% (30)
• B
  2% (1)
• C
  17% (7)
• D
  10% (4)

Explanation

Option A is correct because it follows standard Git branching strategy: creating a dedicated branch from main for production hotfixes keeps that work isolated and deployable independently, while a separate branch for the new version allows development to proceed in parallel without interference. This is the standard "feature branch" or "release branch" pattern that CodeCommit, like any Git-based service, is designed to support.

Why the distractors fail:

• B is wrong because Git tags are read-only markers (snapshots), not branches - you cannot commit bug fixes to a tag, making it unsuitable for ongoing maintenance work.
• C likely describes an incomplete or reversed branching approach (e.g., branching from production state back into main in a way that causes merge conflicts or loses new-version changes).
• D is wrong because creating an entirely separate repository is unnecessary overhead and breaks the single-repository workflow; Git branches exist precisely to avoid this.

Memory tip: Think of branches as parallel workstreams and tags as museum labels - you work on branches, you just look at tags. When you need to fix production while building something new, always reach for two branches off main, not two repos or tags.

No community discussion yet for this question.