CCNA Sdlc Automation Questions

By enabling default encryption on the S3 bucket used as CodePipeline's artifact store—or specifying an AWS KMS customer-managed key in the pipeline settings—all build outputs and source artifacts are encrypted at rest with either SSE-S3 or SSE-KMS. This protects sensitive data from unauthorized direct access to the bucket, even if the bucket policy or ACL is misconfigured. Using KMS adds an additional layer of control by letting you restrict which roles can decrypt artifacts and enabling CloudTrail auditing of all decrypt operations.

Creating an ECR lifecycle policy is the correct action because it automatically applies expiration rules to images in the chosen repository. Lifecycle policies evaluate images based on criteria like tag status and age, then expire matching images for you. They are managed through the ECR service (console, CLI, or SDK), not through the CI/CD build steps, and are the standard mechanism for controlling image retention and storage costs.

The target group tied to the Auto Scaling group acts as the traffic-routing endpoint for the load balancer. If its health check path, port, or timeout settings are misconfigured—or if it is not attached to the appropriate listener rule—the newly deployed instances will be registered but immediately marked unhealthy and deregistered, so no user traffic reaches them. CodeDeploy itself successfully completes its scripts, but the deployment outcome appears as a routing failure, not an instance-level failure.

The CodePipeline service role must be explicitly listed as a principal in the artifact bucket's bucket policy with permissions like s3:GetObject, s3:PutObject, and s3:ListBucket. If the bucket policy is missing or uses the wrong role ARN, the pipeline gets an AccessDenied error when trying to read or write artifacts. This is the correct root cause because CodePipeline validates bucket access via the bucket policy and the attached IAM role policies.

AWS EventBridge (CloudWatch Events) can be configured with a cron or rate expression to invoke the StartPipelineExecution API action on CodePipeline as a rule target. This provides a fully managed, scheduled trigger for pipelines, commonly used for nightly builds, recurring data syncs, or regular compliance scans. It is a legitimate automated trigger that does not require any external activity, making it ideal for time-based initiation.

Defining a parameter of type AWS::EC2::Subnet::Id lets the caller supply the actual subnet at stack creation or update, and CloudFormation validates that the value is a real subnet ID. Referencing it via Ref keeps the template portable across environments, and the parameter appears in the console or CLI for clear input.

When a user clicks the 'Cancel' button in the CloudFormation console, or an automation script invokes DeleteStack during a creation operation, CloudFormation aborts pending resource creation and emits a 'Resource creation cancelled' event for each in-progress resource. The stack then transitions to ROLLBACK_IN_PROGRESS, destroying any resources that were successfully created before the cancellation. This event reason directly matches the manual or scripted interruption described in the correct answer.

AWS CodeDeploy natively integrates with ECS blue/green deployments, shifting traffic between original and replacement task sets via a load balancer. Its deployment group accepts CloudWatch alarm configurations, so a breached alarm automatically triggers rollback to the original task set — satisfying the stem's requirement for alarm-driven automatic rollback.

buildspec.yml is the correct file because AWS CodeBuild automatically looks for a file named buildspec.yml in the root of the source code directory, unless an alternate buildspec file is specified in the build project. This YAML file defines the build phases—install, pre_build, build, and post_build—along with environment variables, artifact output, and cache settings. For a Java application, the `build` phase would contain commands such as `mvn compile` or `gradle build` to compile the source code. Without a valid buildspec, CodeBuild will fail unless an inline buildspec is provided in the project configuration.

CodePipeline's S3 source action resolves the artifact by object key at the moment the pipeline execution starts. If an external system overwrites or deletes that object during the run, the pipeline may fetch a different revision or fail entirely because the original content no longer exists. Enforcing immutability through a write-once policy or access controls prevents this race condition and guarantees the pipeline operates on a stable artifact.

The built-in deployment configuration CodeDeployDefault.ECSCanary10Percent5Minutes instructs CodeDeploy to initially route 10% of the load balancer's traffic to the new ECS task set (the green environment) while the remaining 90% continues to go to the blue task set. After a 5-minute waiting period, during which health checks and metrics can be evaluated, CodeDeploy automatically shifts the remaining 90% of traffic to green, completing the deployment. This two-step canary pattern exactly satisfies the requirement for a 10% initial shift with a 5-minute soak before the final 90% cutover.

A manual RDS snapshot taken immediately before the migration is the only mechanism that provides a point-in-time, database-level restore point independent of the application deployment. If the migration script corrupts data or fails mid-transaction, you can restore the instance from this snapshot and redeploy the previous code version, ensuring a clean rollback. This is the standard pre-migration practice because other options either target application code only or do not give you a deterministic restore point for the database itself.

Removing the output from the CloudFormation stack is the only direct way to prevent the password from being exposed in the stack's output section. Outputs are stored in plaintext by CloudFormation and are retrievable via the console, APIs such as DescribeStacks, and any logging that captures API responses. By eliminating the output, you ensure that the password does not appear in that specific exposure path; additional best practices like using Secrets Manager for retrieval by applications should still be implemented to protect the secret throughout its lifecycle.

In CodePipeline, every pipeline is bound to a single region. If a Deploy action references a CodeDeploy application in another region, it is treated as a cross-region action and must be explicitly configured with the Region property. Without that, the pipeline attempts to execute the action in us-east-1, where no deployment group exists, producing the 'Deployment group not found' error. The fix is to add the cross-region configuration or move the Deploy action to the same region.

Creating a new Elastic Beanstalk environment and then swapping the environment CNAMEs is the native blue/green deployment method. The new environment is fully provisioned, tested, and warmed up behind its own URL before the CNAME swap atomically redirects production traffic. This enables immediate rollback by swapping back, and it is the standard Elastic Beanstalk pattern for zero-downtime blue/green releases.

Configuring the source stage to trigger on all branches is the recommended approach because CodePipeline natively supports branch filters on source actions, allowing a single pipeline to react to every branch push. Branch-specific logic can then be implemented in the test stage using environment variables or run-time conditions to vary test suites, while a manual approval action can be conditionally added to the deploy stage only when the branch is 'main'. This leverages built-in pipeline features, avoids duplication, and keeps the deployment workflow centralized and auditable, which is the most scalable and maintainable design.