DOP-C02 Readiness and Safe Sandbox Design

Objectives

• Map a sample architecture to the six weighted DOP-C02 domains.
• Identify prerequisite gaps in IAM, networking, Git, and scripting.
• Define sandbox access, cost checks, and a resource cleanup checklist.

1. Readiness means explaining operational decisions

This 30-minute lesson establishes the working contract for the course: understand the exam's scope, identify prerequisite gaps, and design a sandbox before provisioning anything. Suggested pacing: 4 minutes on exam scope, 7 on architecture mapping, 6 on prerequisites, 5 on access, 4 on cost, and 4 on evidence and cleanup.

DOP-C02 evaluates the provisioning, operation, and management of distributed AWS systems, not just recognition of service names. AWS describes a target candidate with at least two years of AWS operational experience plus software lifecycle and scripting or programming experience. Treat that description as a readiness signal, not as a substitute for demonstrating skills. [S40]

The six domains and their weights are:

The names and weights come from the exam guide; the questions are our study prompts. [S1]

Use weights to allocate practice, not to ignore a domain. For example, a deployment question may require both pipeline design and cross-account permissions. The passing scaled score is 750 out of 1,000; it is not a statement that 75% of questions must be answered correctly. The exam includes 65 scored questions and 10 unidentified unscored questions. [S1]

Check yourself: Which domain has the largest weight? Which two have 17%? Answer: SDLC Automation at 22%; Configuration Management and IaC, and Security and Compliance at 17% each.

2. Map one architecture to all six domains

Use this proposed reference architecture throughout the course: a Git repository feeds a delivery pipeline; tests produce a versioned artifact; CloudFormation describes an application environment; a workload spans two Availability Zones; telemetry feeds alarms; and a controlled response workflow handles selected failures. IAM roles and configuration checks apply across the system. This is a teaching design, not an instruction to deploy every component now.

Map responsibilities rather than assigning each service to only one domain:

These responsibilities connect the six exam domains to one operational system. Pipeline testing and artifact management belong to the SDLC scope; reusable infrastructure belongs to IaC; recovery objectives and telemetry belong to resilience and monitoring respectively. [S1] The complete six-domain structure is defined in the exam guide. [S40]

For resilience, choose the architecture from requirements. A single-Region, Multi-AZ design and a multi-Region design are not interchangeable: multiple Regions introduce additional infrastructure, data-management cost, and operational complexity. Define recovery time objective (RTO: acceptable recovery time) and recovery point objective (RPO: acceptable data loss measured in time) before choosing a recovery strategy. [S16]

For security evidence, AWS Config can record configuration history and relationships, while Config rules evaluate settings against specified conditions. A configuration evaluation is evidence about those conditions, not proof that the whole workload is secure. [S38]

Worked decision: A deployment completes, but errors rise. Start with the deployment record and telemetry, then decide whether to stop promotion, recover, or escalate. This crosses SDLC, monitoring, and incident response. Do not assume every deployment mechanism rolls back atomically: a failed Elastic Beanstalk rolling deployment can leave mixed application versions. [S21]

Check yourself: For a cross-account pipeline that cannot decrypt its artifact, which domains are involved? Answer: SDLC Automation and Security and Compliance at minimum. The investigation must consider the artifact bucket, customer-managed KMS key, pipeline role, and target-account role together. [S12]

3. Diagnose prerequisite gaps before adding complexity

Use the following self-assessment without provisioning resources. Score each row 0 if you cannot complete it, 1 if you need a walkthrough, or 2 if you can complete it and explain the failure case. These scores are a course planning aid, not an exam score predictor.

The IAM distinction matters: trust policies control who can assume a role; permission policies control its allowed actions. Explicit denies take precedence over allows. Boundaries and service control policies constrain permissions rather than granting them. [S15]

For networking, test dependencies rather than relying on labels such as 'private' or 'managed.' For example, private Systems Manager endpoints do not themselves provide connectivity to operating-system patch repositories. Patch-source connectivity and required AWS-managed S3 access must be checked separately. [S5]

The scripting example below intentionally validates a local planning record without contacting AWS. Save it as check_sandbox.py and run python3 check_sandbox.py. Its intended success message is Planning checks passed; no AWS resources were inspected. Then remove owner and confirm that the script exits with a missing-fields message. These are expected behaviors for your exercise, not reported execution results.

Readiness decision: For every score below 2, record a concrete repair action. An IAM gap blocks permission-changing exercises; an unresolved networking gap blocks network-dependent exercises; Git and scripting gaps should be repaired before automating shared changes. Do not average away a safety-critical gap.

4. Define sandbox access and a permission boundary of responsibility

For this course, propose a dedicated nonproduction AWS account, one approved Region initially, synthetic data only, and an explicitly identified person responsible for teardown. If only a shared account is available, obtain an approved resource scope and exclusions before any write. Do not treat a naming prefix as an authorization boundary.

Write an access contract with these fields:

• Account identifier and approved Region, verified before each write session.
• Human access role and authentication method; prefer temporary role-based access rather than placing long-lived credentials in examples.
• Separate deployment and runtime roles, each with its intended actions and resource scope.
• Who can change IAM, encryption, network exposure, and organization-level controls.
• Explicit exclusions: production resources, real customer data, and shared security controls.
• Stop conditions: unexpected identity, unexpected Region, unreviewed permissions, or unexplained cost.

This is the course's proposed operating policy, not a claim that AWS enforces these fields automatically.

Apply least privilege incrementally: identify the next exercise's required actions, grant only the needed scope, test, and investigate denials rather than attaching administrator access as a shortcut. Role trust and role permissions solve different problems. Cross-account access generally needs authorization on both sides; constraints such as SCPs and permission boundaries do not independently grant access. [S15]

Avoid treating a permissions boundary as a universal ceiling on every possible resource-policy grant. Grants to role sessions and grants to role ARNs can have different interactions with implicit denies. If a resource policy is part of an access path, review that path explicitly. [S15]

The read-only shell example below prints the caller identity and configured Region. Compare the results with your approved contract; the commands do not enforce it. Do not paste identity output, credentials, or account-specific details into a public repository.

Check yourself: The caller may assume a deployment role, but that role cannot update a stack. Which policy question comes first? Answer: inspect the role's allowed actions and relevant constraints; successful assumption establishes neither the required service permission nor the absence of an applicable deny. [S15]

5. Set cost checks before deployment

Choose a spending envelope before building. For this lesson's planning exercise, use an illustrative ceiling of USD 10 for a single practice session, with review thresholds of USD 5 and USD 8. These are learner-selected planning values, not AWS prices, free-tier promises, or automatically enforced caps. Replace them with an approved amount appropriate to your account and exercise.

Create a cost worksheet:

Treat a budget notification as a signal to investigate, not as evidence that resources have been shut down. This course requires an explicit stop-and-cleanup procedure rather than relying on an alert to enforce the spending envelope. If you cannot verify pricing or usage visibility, do not launch the exercise.

Cost decisions interact with architecture. Multi-Region recovery requires duplicated infrastructure and data services; tighter recovery objectives commonly increase both complexity and cost. Choose a small sandbox design for the concept being tested, and document where it differs from a production design. [S16]

For this first lesson, the safest useful outcome is a completed plan and local validation: no billable deployment is needed. Later exercises should add only the resources needed to test their stated objective.

Check yourself: A learner reaches the second review threshold but has not completed the exercise. What happens? Under this proposed policy, pause further provisioning, inspect usage and remaining work, then either obtain explicit approval or clean up. Completion pressure is not permission to exceed the plan.

6. Make evidence and cleanup part of the acceptance criteria

Before any later deployment, create an evidence record that connects intention, action, observation, and cleanup. Store a sanitized record with the exercise: timestamp, approved scope, Git revision, template revision, resource identifiers, expected result, actual result, and cleanup status. Never store access tokens or secrets as evidence.

Use this cleanup checklist as the initial course template, then adapt it to each exercise:

1. Inventory the resources created, including their account and Region. Distinguish exercise-owned resources from shared dependencies.
2. Stop exercise triggers and new deployments before deleting their targets. Save the minimum sanitized evidence needed for learning.
3. Remove exercise infrastructure through its owning automation where possible. Inspect failures rather than assuming a delete request completed.
4. Review retained resources separately: artifact objects, object versions, logs, snapshots, backups, queues, network resources, and lab-only roles. Delete only items within the approved scope; retain required records under an explicit expiry policy.
5. Recheck each recorded resource identifier. Document anything that remains, why it remains, its owner, and its deletion deadline.
6. Revisit usage and cost visibility after teardown. Mark the exercise closed only when unexpected resources and unresolved charges have an owner and a resolution plan.

A useful exception illustrates why resource-specific cleanup matters: AWS Backup restore testing can clean up restored test resources, but removing its restore-test tag can prevent automatic cleanup for resources that depend on that tag. Do not rename or strip service-managed tags casually. [S23]

Final exercise: Produce a one-page sandbox contract containing (a) the six weighted domains mapped to the sample architecture, (b) four prerequisite scores with repair actions, (c) approved access and Region, (d) a cost envelope and review thresholds, and (e) an evidence and cleanup checklist. Keep real account details in your private working copy.

Acceptance check: Can another operator identify who may deploy, what may be created, when work must stop, how success is demonstrated, and how remaining resources will be found? If any answer is missing, revise the contract before continuing to reusable CloudFormation stacks. A valid plan permits learning safely; it is not evidence that a deployment or cleanup has already succeeded.

import sys

# Local planning example only. These values do not configure AWS controls.
plan = {
    "environment": "sandbox",
    "owner": "learner",
    "region": "us-east-1",
    "session_limit_usd": 10,
    "review_thresholds_usd": [5, 8],
    "cleanup_required": True,
}

required = ("environment", "owner", "region", "session_limit_usd",
            "review_thresholds_usd", "cleanup_required")
missing = [key for key in required if key not in plan or plan[key] == ""]
if missing:
    sys.exit("Missing planning fields: " + ", ".join(missing))
if plan["environment"] != "sandbox":
    sys.exit("Only sandbox planning is allowed in this example.")
limit = plan["session_limit_usd"]
thresholds = plan["review_thresholds_usd"]
if type(limit) not in (int, float) or limit <= 0:
    sys.exit("Session limit must be a positive number.")
if not isinstance(thresholds, list) or not thresholds:
    sys.exit("Provide a nonempty list of review thresholds.")
if any(type(value) not in (int, float) or not 0 < value < limit
       for value in thresholds):
    sys.exit("Each review threshold must be positive and below the limit.")
if thresholds != sorted(set(thresholds)):
    sys.exit("Review thresholds must be unique and ascending.")
if plan["cleanup_required"] is not True:
    sys.exit("A cleanup commitment is required.")
print("Planning checks passed; no AWS resources were inspected.")

Local planning validation only: no AWS calls, budget creation, or permissions enforcement. Use the Region approved for your sandbox.

# Read-only identity checks; requires an installed, authenticated AWS CLI.
# Select your approved profile through your normal local configuration first.
aws sts get-caller-identity --output json
aws configure get region
# Compare both outputs with your private sandbox contract before any write.

Display identity and configured Region for manual comparison. These checks neither create resources nor prove the safety of a later command.

Key takeaways

• DOP-C02 weights are 22%, 17%, 15%, 15%, 14%, and 17%; map operational responsibilities, not just service names, to the domains. [S1]
• Use observable IAM, networking, Git, and scripting demonstrations to find prerequisite gaps before provisioning.
• Separate role trust from role permissions, and inspect resource policies and applicable constraints for the actual access path. [S15]
• Write an approved sandbox contract covering identity, Region, allowed resources, spending reviews, stop conditions, and cleanup ownership.
• Cost thresholds in a planning file are not enforced spending controls; investigate usage and explicitly stop and clean up when required.
• Preserve sanitized evidence and verify the final resource inventory before treating an exercise as complete.

Common mistakes

• Treating the 750 passing scaled score as a raw 75% requirement.: Distinguish scaled scoring from raw answer percentages and use practice results to locate skill gaps. [S1]
• Assigning every AWS service to exactly one exam domain.: Map responsibilities: a cross-account pipeline can involve delivery, IAM, artifact encryption, monitoring, and incident response. [S12]
• Using broad administrator permissions to resolve every access failure.: Separate trust from permissions, inspect explicit denies and applicable constraints, and grant only the actions required for the approved exercise. [S15]
• Assuming a cost threshold or notification automatically stops the sandbox.: Document what is actually enforced; use a named owner, explicit stop decisions, resource cleanup, and later cost review.
• Calling teardown complete after issuing a delete request.: Read back the resource inventory, investigate failures and retained items, and record owners and deadlines for exceptions.
• Assuming private service endpoints provide every dependency's connectivity.: Trace each dependency independently; Systems Manager patching still needs access to patch sources and required AWS-managed S3 resources. [S5]

References

1. AWS Certified DevOps Engineer - Professional: Exam Guide (DOP-C02), Amazon Web Services
2. AWS Certified DevOps Engineer - Professional (DOP-C02) Exam Guide, Amazon Web Services
3. Policies and permissions in AWS Identity and Access Management, AWS
4. Reliability Pillar - AWS Well-Architected Framework, AWS
5. What Is AWS Config?, Amazon Web Services
6. Deployment policies and settings, Amazon Web Services
7. Create a pipeline in CodePipeline that uses resources from another AWS account, AWS
8. Patch Manager prerequisites, Amazon Web Services
9. Restore testing, Amazon Web Services

See the full course: AWS DevOps Engineer Professional: DOP-C02 Preparation