Deployment And Delivery Design — AWS Security Specialty (SCS-C03)
Rollback Speed and Blast Radius Are Different Constraints
Deployment strategy questions on the SCS-C03 surface in the context of patching, certificate rotation, or security control rollout — not general CI/CD. The deciding variables are rollback speed, blast radius, and traffic shift granularity. CodeDeploy linear and canary deployments control traffic shift. CloudFormation change sets provide pre-deployment review. Blue/green deployments eliminate in-place risk. Read whether the scenario requires 'immediate rollback,' 'zero-downtime,' or 'validation before full deployment' — each phrase maps to a different deployment primitive.
What This Pattern Tests
The exam tests deployment pipeline design with service-appropriate strategies. CodePipeline orchestrates source-build-test-deploy stages with manual approval gates. CodeDeploy supports blue/green on ECS (shift traffic between task sets), canary on Lambda (shift 10% then all), and rolling on EC2. For DOP-C02, CloudFormation StackSets deploy infrastructure across multiple accounts and regions simultaneously, while change sets preview modifications before execution. For AIF-C01 and MLS-C01, SageMaker Pipelines orchestrate ML workflows — data processing, training, evaluation, and model registration — with Model Registry tracking model versions and approval status before deployment to endpoints. The trap is using CodeDeploy for ML model deployment (SageMaker Pipelines handles the ML lifecycle) or CloudFormation direct updates without change sets in production.
Decision Axis
Deployment risk tolerance and workload type determine the pipeline: application code uses CodePipeline, infrastructure uses CloudFormation StackSets, ML models use SageMaker Pipelines.
Associated Traps
Decision Rules
Choose AWS Organizations Resource Control Policies (RCPs) rather than Service Control Policies (SCPs) to prevent external principals from accessing organization-managed S3 resources, because SCPs constrain what IAM principals inside the organization are permitted to do while RCPs constrain what any principal — including external accounts — is permitted to do on organization-owned resources, regardless of what resource-based policies grant.
Whether deploy-time gating via Service Catalog launch constraints satisfies a zero-tolerance PCI-DSS deployment consistency mandate, versus post-deployment detection-and-remediation via AWS Config rules which leaves an inherent non-compliant window.
Whether to enforce the cross-account S3 access boundary using an SCP (which restricts member-account principal permissions) or an RCP (which restricts resource-level access and controls what external principals can be granted through bucket policies) — only an RCP propagated from the org root satisfies both the resource-boundary requirement and the least-operational-effort constraint.
Whether to enforce configuration immutability at deploy time through Service Catalog portfolio launch constraints (parameter values locked at provision; direct CloudFormation bypass prevented via SCPs) versus a custom cross-account validation pipeline that interposes Lambda approval hooks before CloudFormation execution but cannot prevent direct API invocations without additional controls.
Choose between an SCP (principal-level control applied to member-account IAM principals) and an RCP (resource-level control applied to the resource itself) to enforce cross-account S3 external-principal restrictions from a single OU-scoped policy.
Domain Coverage
Difficulty Breakdown