Deployment practice questions

Answer: A) Create a StackSet with service-managed permissions that targets the OU, and turn on automatic deployment

Only StackSets with service-managed permissions support automatic deployment. When it is turned on, CloudFormation deploys stack instances to accounts as they join a target OU. Self-managed StackSets, nested stacks, and modules do not cover new accounts automatically.

• ACorrect. With service-managed permissions, StackSets deploy to accounts managed by AWS Organizations and create the required IAM roles for you. When automatic deployment is turned on, CloudFormation deploys a stack to any account that is added to a target OU.
• BIncorrect. With self-managed permissions, you must create the IAM roles in each target account yourself, and the StackSet deploys only to the accounts you list. Automatic deployment to new Organizations accounts is a feature of the service-managed model.
• CIncorrect. Nested stacks split one template into reusable pieces that are created as part of a parent stack. They are not a way to deploy across multiple accounts, and they do not respond to accounts being added to an OU.
• DIncorrect. Modules are reusable, versioned resource configurations that you include in your own templates. Each account would still have to deploy a stack that uses the module, so registering a module deploys nothing to new accounts.

Answer: A) The CDK runs the command in a Docker container from the runtime's build image, with the source mounted at /asset-input, and zips the /asset-output contents as the function code.

CDK asset bundling runs the build command in a Docker container during synthesis, by default using the runtime's SAM build image. The /asset-output contents become the Lambda code package, which the CDK then publishes to the bootstrap S3 bucket. (NodejsFunction uses local esbuild when it's available and falls back to Docker otherwise.)

• ACorrect. The CDK runs bundling during synthesis. It mounts the asset path at /asset-input inside the container, and whatever the command writes to /asset-output is zipped and used as the Lambda code. Runtime.bundlingImage points to the AWS SAM build image for that runtime.
• BIncorrect. Bundling happens on the machine running the CDK, during synthesis, not at runtime. Lambda never runs CDK bundling commands. The finished, bundled artifact is what gets published.
• CIncorrect. CloudFormation doesn't run CDK bundling commands. The CDK produces the bundled asset locally in the cloud assembly (cdk.out) before any stack deployment begins.
• DIncorrect. The CDK CLI first publishes file assets to the Amazon S3 bucket created during bootstrapping, and only then deploys the stack's resources. Bundling prepares the artifact but doesn't remove this staging step.

Answer: A) It composes the scoped IAM access policies that let the function write to the table, so the developer doesn't hand-write policy statements

AWS SAM connectors let you state the intended access between resources, such as Read or Write from a function to a table. SAM then composes the scoped IAM policies, so you don't write them by hand.

• ACorrect. Connectors (AWS::Serverless::Connector) let you state the source, the destination, and Read or Write permission. AWS SAM then composes the matching, narrowly scoped access policies for you.
• BIncorrect. Connectors only provision permissions between resources. They don't create networking components such as VPC endpoints.
• CIncorrect. A connector grants the access the source needs to the destination. It does not set up event triggers. A stream trigger is defined separately, for example as an event on the function.
• DIncorrect. Connectors do not package dependencies or create layers. Their only job is to compose the access policies between the source and destination resources.

Answer: A) The service role's permissions, for this and all later operations on the stack; the developer needs iam:PassRole to specify the role

By default, CloudFormation uses a temporary session generated from the caller's credentials. Once a service role is specified, CloudFormation uses that role's credentials for all operations on the stack. The caller needs iam:PassRole to specify the role.

• ACorrect. When a service role is specified, CloudFormation uses that role's credentials and keeps using that role for every later operation on the stack. To specify the role, the caller must have iam:PassRole permission for it. Resources outside the role's EC2 permissions would fail to create, even though the developer has broader access.
• BIncorrect. The service role is not limited to rollbacks. Once specified, it is used for all create, update and delete operations on the stack. The caller's own credentials are used only when no service role is specified.
• CIncorrect. CloudFormation does not evaluate both identities together. It acts with the service role's credentials, so the developer's own resource permissions do not limit or widen what the stack can create.
• DIncorrect. A service role specified at creation is used immediately, including for the initial create. The documentation says CloudFormation always uses that role for all operations performed on the stack.

Answer: A) `eb deploy`, which bundles the project source and deploys it to the environment

`eb deploy` packages the project's source bundle and deploys it to an existing environment directly from the command line. `eb init`, `eb create`, and `eb setenv` handle project setup, environment creation, and environment properties instead.

• A`eb deploy` creates a source bundle from the project directory (using git archive of the latest commit when Git is used, or the directory contents when .ebignore is present). It then deploys that bundle as a new application version to the running environment.
• B`eb init` configures default values and creates the Elastic Beanstalk application. It doesn't deploy code to an environment.
• C`eb create` creates a new environment. The developer wants to update the existing running environment, which is what `eb deploy` does.
• D`eb setenv` only sets environment properties (environment variables). It doesn't package or deploy application code.

Answer: A) Weighted records with the same name for each endpoint, adjusting each record's relative weight over time

Route 53 weighted routing splits traffic among records with the same name in proportion to their weights. Changing the weights over time gives a gradual, DNS-level shift between versions without an ALB or CodeDeploy.

• ACorrect. With weighted routing, Route 53 sends each record a share of traffic equal to its weight divided by the total weight of the group. The team can change the weights gradually and set the old record's weight to 0 to stop sending it traffic.
• BIncorrect. Failover routing is active-passive. All traffic goes to the primary while it is healthy, so traffic cannot be split in set proportions.
• CIncorrect. Latency routing picks the AWS Region with the lowest latency for the client. Both endpoints are in the same Region, and this policy gives no control over traffic proportions.
• DIncorrect. Multivalue answer routing returns up to eight healthy records chosen at random. It does not let the team set or gradually change how much traffic each endpoint receives.

Answer: A) BeforeAllowTraffic

In a CodeDeploy Lambda deployment, only BeforeAllowTraffic and AfterAllowTraffic can be hooks. BeforeAllowTraffic is the one that validates the new version before any traffic shifts. AllowTraffic itself is reserved for CodeDeploy and can't be scripted.

• AIn a Lambda deployment, BeforeAllowTraffic runs tasks before traffic shifts to the new function version. The validation function reports its result with PutLifecycleEventHookExecutionStatus, and a Failed result fails the deployment.
• BAfterAllowTraffic runs after all traffic has shifted to the new version. That's too late for a check that must pass before any traffic moves.
• CAllowTraffic is the event in which CodeDeploy shifts the traffic. Like Start and End, it's reserved and can't be scripted, so no hook function can be attached to it.
• DBeforeInstall is a hook for EC2/On-Premises and Amazon ECS deployments. Lambda deployments support only BeforeAllowTraffic and AfterAllowTraffic hooks.

Answer: A) A Rules entry whose RuleCondition checks that UseSSL equals Yes and whose Assert requires CertificateArn to be non-empty

The Rules section is CloudFormation's built-in way to validate parameters, including checks across more than one parameter, before any resources are created or updated. Per-parameter constraints, Conditions and Mappings can't do this.

• ARules validate parameter values before CloudFormation creates or updates resources. A RuleCondition decides when the assertions apply, and a failed Assert stops the stack operation and shows the AssertDescription. That makes it a fit for checks that depend on another parameter.
• BAllowedPattern checks one parameter by itself, so it can't depend on UseSSL. It would also reject the empty default when UseSSL is No.
• CConditions control whether resources or properties are created. They don't reject a stack operation because a parameter combination is invalid.
• DMappings are static lookup tables read with Fn::FindInMap. They don't check user-supplied parameter values or cause a stack operation to fail.

Answer: A) It stops the older, in-progress execution at its current stage boundary and lets the newer execution proceed, rather than making the new one wait in a queue behind the old one

• ASuperseded mode (a common default) means that when newer source changes trigger a fresh execution while an older one is still running, the older execution is superseded (stopped) at its next stage transition and the pipeline moves forward with the newer, more current execution instead of processing every stale execution one after another.
• BThat describes parallel execution mode, a different, separate configuration option — not what superseded mode does, which specifically supersedes (stops) the older execution rather than running both concurrently.
• CThat describes queued execution mode, a different option — superseded mode specifically allows skipping past a stale, still-running older execution rather than strictly processing every one in order.
• DExecution mode is specifically the setting that determines how CodePipeline handles overlapping executions — it has a very real, defined effect on this behavior.

Answer: A) The same templates can redeploy the infrastructure in us-west-2 quickly and consistently, which helps the team meet its recovery time objective (RTO)

For disaster recovery, infrastructure as code lets you redeploy the same infrastructure quickly and reliably in another Region or account, which supports the RTO. Application data still needs its own backup or replication, and traffic failover is handled by other services.

• ACorrect. AWS guidance for backup and restore is to deploy with infrastructure as code (CloudFormation or CDK) so that infrastructure can be redeployed in the recovery Region quickly and without errors. Without IaC, restoring in the recovery Region is complex, which increases recovery time and may exceed the RTO.
• BIncorrect. A template defines resources, not their contents. Data needs its own backup or replication, for example AWS Backup cross-Region copies, DynamoDB backups or global tables, or S3 Cross-Region Replication.
• CIncorrect. CloudFormation does not run standby stacks or fail traffic over. Traffic failover is done with services such as Amazon Route 53 health checks or Amazon Application Recovery Controller (ARC).
• DIncorrect. RPO depends on how often data is backed up or replicated. CloudFormation does not take snapshots of resource data. IaC mainly helps with how fast infrastructure is redeployed, which affects RTO.