Infrastructure as code promises repeatability, but a template alone does not guarantee it. A production incident may lead an engineer to change a security group by hand. Another team may update an instance setting directly in the console. A later automated deployment can reverse those fixes, or the original template may sit unchanged while the actual environment drifts further away. Professional AWS DevOps work requires a clear desired state, a controlled way to change it and evidence that the environment still matches what the organization intends.<\/p>\n
The DOP-C02 DevOps Engineer \u2013 Professional<\/a> exam includes configuration management and infrastructure as code as a distinct domain, but the implications reach into security, delivery, monitoring and incident response. Good IaC is not measured by lines of YAML or the elegance of a programming language. It is measured by whether teams can deploy the right environment, understand a proposed change and recover when the result differs from expectations.<\/p>\n The first decision is organizational. Where is the accepted specification for a service’s infrastructure? Who may change it? How are exceptions recorded? If engineers treat a source repository as documentation while real production changes happen elsewhere, the organization does not have effective configuration control even if every resource was initially created from a template.<\/p>\n Version-controlled definitions make changes reviewable. A proposed adjustment to a network rule, a database capacity setting or a cross-account role can be examined with the application change that requires it. Reviewers need context: the purpose, affected accounts and Regions, security implications, expected replacement behavior and rollback or recovery plan. A diff alone may not reveal a dangerous consequence, particularly when a small property change forces resource replacement.<\/p>\n Separate stable design intent from values that legitimately vary by environment. A production system may use different capacity, domains or retention settings from a test environment. These differences should be explicit and governed rather than scattered through hidden manual patches. Reusable modules or stacks can encode common requirements without making every environment artificially identical.<\/p>\n Infrastructure definitions should also avoid containing secrets. Parameters, references and controlled retrieval can keep credentials out of repositories and deployment artifacts. An infrastructure template can describe access to a secret or a key without carrying the sensitive value itself. The distinction between AWS KMS and Secrets Manager<\/a> matters when designing that separation.<\/p>\n CloudFormation expresses managed AWS resources and their relationships, while the AWS Cloud Development Kit can synthesize infrastructure definitions from higher-level programming constructs. Both help deliver versioned infrastructure, but neither excuses poor change design. A generated template still needs inspection, and a resource with an unexpected replacement property can still disrupt a service.<\/p>\n Treat change sets or equivalent previews as evidence about intended operations, not a perfect prediction of runtime behavior. A change may be valid for the service API but harmful to application traffic. A new security rule may be syntactically acceptable while cutting off a dependent service. A database modification may be allowed but introduce a maintenance interruption that the release schedule did not anticipate.<\/p>\n Stack relationships matter. Dependencies can be declared, but overly coupled stacks make unrelated changes difficult to deploy. Split definitions where teams have meaningful ownership and lifecycle boundaries, not simply to produce more files. Conversely, excessive fragmentation can produce opaque outputs and references that make recovery confusing. A practical boundary is one where change and rollback responsibility remain understandable.<\/p>\n Not every environment needs the same abstraction. A compact workload may be manageable through a small number of straightforward templates; a large platform may benefit from reusable constructs and deployment pipelines. Evaluate how the chosen approach handles testing, security defaults, review and debugging when generated resources do not behave as expected.<\/p>\nChoose a source of truth before choosing syntax<\/h2>\n
Understand what CloudFormation and CDK actually provide<\/h2>\n