AWS CloudFormation and the AWS Cloud Development Kit (CDK) are often presented as competing infrastructure-as-code choices, but operationally they sit at different layers. CloudFormation is the AWS deployment and stack-management engine. CDK is an authoring framework that lets teams define infrastructure in supported programming languages and synthesize that code into CloudFormation templates.

For the current AWS Certified CloudOps Engineer – Associate exam, the important distinction is not whether YAML or TypeScript is more elegant. CloudOps engineers need to understand what ultimately changes AWS resources, how to preview replacements, how rollback behaves, how drift appears, and how a deployment pipeline can keep infrastructure controlled. A CloudFormation deployment workflow remains relevant even when the original source was authored through CDK because the resulting stack is still a CloudFormation stack.

CloudFormation is the deployment and state-management layer

A CloudFormation template declares AWS resources, properties, parameters, outputs, conditions, and relationships. When a stack is created or updated, CloudFormation compares the desired template with the current stack state and calls the underlying service APIs in the required order. It also tracks logical resources so later updates can modify, replace, or delete the corresponding physical resources.

This stack model gives operations teams a consistent place to observe deployment events. If a security group is created successfully but an EC2 instance fails later in the update, the stack event history shows where the deployment stopped and which resource reported the error. Dependencies expressed through references and explicit DependsOn relationships affect the order in which resources are processed.

CloudFormation is therefore more than a template parser. Logical IDs deserve operational attention because changing how a resource is identified in the template can make CloudFormation interpret an apparently familiar component as a different resource. Refactoring infrastructure code should therefore be reviewed for resource identity and replacement risk, not only for syntax. It is the control plane that owns the stack lifecycle. Whether the template was handwritten, generated by a tool, or synthesized by CDK, the operational questions ultimately reach CloudFormation.

CDK is an authoring abstraction over CloudFormation

AWS CDK lets developers define infrastructure with constructs in languages such as TypeScript, Python, Java, C#, and Go. Constructs can package common resource patterns into reusable components, allowing a team to express a large architecture with less repetitive low-level configuration.

The abstraction is productive because application engineers can use normal programming concepts such as functions, classes, loops, composition, and package dependencies while authoring infrastructure. A construct can create an S3 bucket, IAM role, Lambda function, event source, and supporting policies as one reusable building block.

The tradeoff is that the source code may hide the number and exact configuration of resources generated underneath. CloudOps engineers should not treat the construct as magic. The synthesized CloudFormation template is the deployable artifact and should be reviewable when security, replacement behavior, or cost matters.

Use cdk synth, cdk diff, and the template to make changes visible

cdk synth produces the CloudFormation template for a CDK stack. Reviewing that output answers questions that the high-level construct code may not make obvious: Which IAM statements were generated? Which security groups exist? Which resources have retention policies? Which logical IDs and dependencies will CloudFormation manage?

cdk diff compares the locally synthesized template with the deployed stack template so teams can see planned infrastructure changes before deployment. It is useful in pull requests and CI pipelines because reviewers can evaluate infrastructure impact alongside the source-code change.

This does not make cdk diff identical to CloudFormation drift detection. A diff is about local desired code versus the deployed template. Drift detection is about actual AWS resource configuration versus the template that CloudFormation believes should define it. The two answer different operational questions.

Preview CloudFormation updates with change sets

A CloudFormation change set shows how a proposed template update will affect the stack before the update is executed. This is especially important when a property change causes resource replacement. A seemingly small template edit can create a new database, network interface, or other physical resource depending on the service’s update behavior.

Traditional change sets compare the new desired template with the previously deployed template. AWS also supports drift-aware change sets, which compare actual resource state, the previous deployment state, and the new desired state. This helps teams see when a deployment would overwrite an emergency out-of-band change or reconcile drift back to the template.

For production CloudOps, change review should focus on consequences rather than line count. One changed line that replaces a stateful resource deserves more scrutiny than dozens of metadata changes.

Understand rollback, replacement, and protection controls

CloudFormation normally attempts to roll back a failed stack update to the last stable state. That behavior protects consistency, but rollback is not a guarantee that every external side effect disappears. A custom resource, database migration, API call, or application deployment may have effects outside the resources CloudFormation can reverse automatically.

Resource replacement is another key risk. Some property changes require CloudFormation to create a new physical resource and remove the old one. DeletionPolicy and UpdateReplacePolicy can be used for supported resources when data retention should survive stack deletion or replacement. Stack policies can also protect designated stack resources from unintended update actions.

CDK inherits these CloudFormation semantics because normal CDK deployments use CloudFormation. Disabling rollback or using development-oriented hotswap behavior can speed iteration, but those choices intentionally change the normal safety model and should not become accidental production defaults.

Treat drift as an operational signal

Drift occurs when a resource managed by CloudFormation is changed outside the stack workflow. An operator might edit a security group in the console during an incident, another automation system might change a property, or a service integration might modify a supported configuration. The deployed resource then differs from the template-defined state.

CloudFormation drift detection can identify supported resources and properties that no longer match the template. The CDK CLI also provides drift-related commands that rely on CloudFormation’s drift capabilities. Not every AWS resource or property supports drift detection, so an IN_SYNC result should be interpreted within that coverage rather than as proof that absolutely nothing changed.

A useful governance rule is to decide how emergency changes return to code. Either update the source template to reflect the accepted change or deploy the intended template state back over the drift. Leaving undocumented drift indefinitely makes later deployments harder to predict.

Keep CDK bootstrap assets and permissions in the operating model

CDK applications often use a bootstrapped environment for deployment roles, asset storage, and other supporting resources. Assets such as Lambda code or container images may be published before the CloudFormation update runs. If the bootstrap resources, deployment role, or asset permissions are broken, the CDK deployment can fail before the target stack reaches the expected update path.

That means CloudOps teams should monitor more than the application stack. They need to understand which pipeline identity performs synthesis and deployment, which role is assumed in the target account, where assets are stored, and which accounts or Regions are bootstrapped. Multi-account deployments should use deliberate trust relationships rather than broadly privileged credentials.

The same principle applies to raw CloudFormation automation. CI/CD roles should have the permissions needed to create and update the stack, while the stack execution role should be scoped to the resources the stack is intended to manage.

Standardize deployment pipelines regardless of authoring language

A safe infrastructure pipeline usually includes source control, automated validation, a preview or change review, deployment through a controlled identity, and monitoring of the resulting stack events. CDK can add unit tests and construct-level policy validation. CloudFormation can use template validation, change sets, stack policies, and drift detection. The authoring method changes, but the operational discipline is similar.

For organization-wide deployments, CloudFormation StackSets can extend stack management across accounts and Regions. CDK can also synthesize stacks that participate in broader multi-account deployment workflows. The crucial issue is ownership: teams should know which system is authoritative for a resource and avoid two independent infrastructure tools fighting over the same configuration.

Manual console changes should be exceptions with a path back to code. If production can only be repaired by editing resources manually and nobody updates the infrastructure source afterward, the environment slowly stops being reproducible.

Choose the authoring model separately from the operating model

Use direct CloudFormation templates when the team wants explicit JSON or YAML resource definitions, already has a mature template estate, or benefits from seeing the service-level configuration without another abstraction. Use AWS CDK when reusable constructs, programming-language abstractions, application/infrastructure co-development, and code-level testing materially improve engineering productivity.

In both cases, operate the resulting stacks with the same rigor: inspect proposed changes, understand replacement behavior, preserve important data, watch stack events, manage execution roles, detect drift, and test rollback. CDK changes how desired infrastructure is authored; it does not remove CloudFormation’s responsibility for the normal deployment lifecycle.

For SOA-C03, the useful mental model is simple: CDK code synthesizes desired infrastructure; CloudFormation manages the stack that applies it. When troubleshooting or reviewing risk, follow the chain from source code to synthesized template to change set to stack events to actual resource state.