Professional Mastery

Professional Mastery

A company creates separate development and production accounts, then grants its development deployment role unrestricted access to production. It enables a budget alert and calls it a spending limit. It creates a central logging bucket but never verifies that member accounts can deliver logs. The organization chart looks mature; the actual boundaries tell another story.

Professional mastery means turning architecture claims into reviewable evidence. This capstone applies the AWS Well-Architected approach to four applications: an account and policy structure, governed account onboarding, central audit evidence, and cross-account deployment. You will define what each control covers, what it does not cover, and how to prove readiness. Account placement helps organize compliance work; it does not itself certify a workload against a legal or industry framework.

1. Design around boundaries and ownership

An AWS account provides a useful isolation and ownership boundary. Its effectiveness depends on IAM trust, resource policies, network paths, shared services and operating practices. A compromised development account is not automatically unable to reach production if production deliberately trusts its principals. Separate accounts also do not eliminate organization-wide or regional dependencies.

Use OUs to group accounts that need similar controls. They need not reproduce every department in the company. Production/nonproduction, security, infrastructure, sandbox and policy-staging OUs can make different requirements visible. Define the account owner, environment, recovery contact, allowed data, budget owner and decommissioning procedure. Keep application workloads out of the management account and minimize its access because SCPs do not restrict its principals. Organizing accounts, Management account practices

Organization root (a policy container, not an AWS account)
  |
  +-- Management account: organization administration and billing
  |
  +-- Security OU
  |     +-- Log Archive account: controlled evidence storage
  |     +-- Audit/Security Tooling account: delegated inspection
  |
  +-- Infrastructure OU: networking and shared services accounts
  |
  +-- Workloads OU
  |     +-- Production OU: one or more owned workload accounts
  |     +-- Nonproduction OU: development and test accounts
  |
  +-- Sandbox OU: isolated experiments with accountable owners
  +-- Policy Staging OU: controlled tests before wider attachment

The organization root and an account's root user are different concepts. An account belongs to one organization and one parent container at a time. Its policies can inherit through the parent hierarchy. A “Suspended” OU is merely a name unless policies and account lifecycle procedures give it meaning; moving an account there does not close it or eliminate ongoing charges. Organization terminology

Assess the six Well-Architected pillars together: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. For a checkout workload, record the recovery objective and acceptable lost data, then test restore/failover against them. Multi-account deployment alone is not a multi-Region disaster-recovery strategy. Keep an architecture decision record containing requirements, alternatives, chosen tradeoffs, owner, evidence and conditions that would trigger reconsideration. Well-Architected Framework

2. Application one: prove what the policy structure permits

Service control policies (SCPs) restrict the maximum permissions available to affected member-account principals. They do not grant permission. A delegated administrator account is still a member account subject to applicable SCPs. The management account and service-linked roles have documented exemptions. An SCP on a resource owner's account does not directly constrain an outside principal merely because that principal accesses its resource; evaluate resource policies and other applicable controls as well. SCP scope

In a deny-list strategy, retain the necessary Allow coverage, commonly FullAWSAccess, and add explicit prohibitions. New services are not automatically denied just because they are new. In an allow-list strategy, the required allow must exist at every applicable level; omitted actions can be blocked. Both approaches need testing and maintenance. FullAWSAccess is not an IAM grant to users, and it can be a deliberate part of a deny-list design. SCP evaluation

This complete SCP document restricts EC2 RunInstances requests for affected member-account principals to two requested Regions. It is intentionally narrow and does not claim that all data or every AWS service is confined to those Regions. Attach it only within a reviewed design that retains the necessary Allow coverage. The condition uses the global requested-Region key.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "RestrictEC2LaunchRegion",
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["us-east-1", "us-west-2"]
      }
    }
  }]
}

aws:RequestedRegion describes the endpoint Region for a request, not every geographical effect of an operation. A broader Region policy needs maintained exceptions and evaluation of global services, replication, exports and cross-Region actions. Existing resources are not deleted by attaching a deny. Account/OU placement and Region restrictions are not a blanket data-residency guarantee. Requested Region

With the SCP policy type enabled and a reviewed policy already created, attachment uses attach_policy(PolicyId=..., TargetId=...). There is no PolicyType argument on AttachPolicy; policy type is established when the policy is created. Attachments and edits are changes to effective access, so stage and validate them before a broad rollout. AttachPolicy

Test using the intended principal in a policy-staging account. Use known-valid inputs and an allowed-Region positive control. An UnauthorizedOperation response alone does not prove the SCP caused denial: IAM, permission boundaries, session policies and other conditions can deny the same request. For EC2 operations supporting dry run, distinguish DryRunOperation from actual creation, inspect authorization evidence and test the relevant effective policy. Do not launch an arbitrary instance just to see whether an unrelated invalid AMI fails. EC2 RunInstances

Document service-linked-role exceptions and an emergency access procedure. A generic SCP cannot implement a universal “every workload must be Multi-AZ” architecture requirement or a human change-approval workflow. Combine enforceable API conditions with deployment validation, detective checks and operating controls. RCPs constrain supported resource access, while declarative policies govern supported service configurations; they are distinct policy tools with their own coverage. Organizations policies

Cost and capacity are also scoped controls

Consolidated billing aggregates charges and eligible usage; RI and Savings Plans benefits depend on coverage and sharing settings. Do not assume every purchase discounts every account unconditionally. If account charges in a simplified teaching example are $1,200, $3,400 and $800 after the modeled discounts, their subtotal is $5,400. Taxes, credits and other charges can change an actual bill. Consolidated billing, Discount sharing

An 80% alert on a $5,000 budget triggers according to configured evaluation when cost crosses $4,000; it is not a synchronous cap at $5,000. Billing delay and continuing resources matter even when budget actions are configured. Inspect actual account/Region service quotas before allocating capacity. Lambda's common default regional concurrency quota is 1,000, with lower initial limits possible for new accounts and increases subject to approval; do not promise 10,000 everywhere. Budget practices, Lambda quotas

3. Application two: onboard an account with a verifiable readiness gate

AWS Control Tower builds and governs a landing zone using Organizations and other services. Its exact enabled resources and controls depend on landing-zone version and configuration. A Log Archive account is for controlled logging storage; an Audit/Security Tooling account supports delegated inspection. Do not assume every service's logs or findings are automatically centralized just because those account names exist. Control Tower

Controls have two different classifications. Behavior is preventive, detective or proactive. Preventive controls use supported Organizations mechanisms including SCPs, RCPs and declarative policies. Detective controls use Config rules. Proactive controls use CloudFormation hooks to evaluate covered provisioning; they do not universally intercept every possible API path. Guidance is mandatory, strongly recommended or elective. These labels are independent of behavior, and “strongly recommended” is not a promise of automatic enablement. Current documentation states that, starting with landing zone 4.0, mandatory controls are no longer applied by default. Inspect what this landing zone actually enables. Control behavior and guidance

Account Factory automates account provisioning and enrollment. The classic Service Catalog interface requires a valid product, provisioning artifact, product name, idempotency token and that product's required parameters. Other customization approaches, including Account Factory for Terraform, have their own interfaces and lifecycle. Choose one supported automation path and make retries, updates and partially completed work explicit. Account Factory, Account Factory for Terraform

This helper submits a reviewed existing Service Catalog product and returns its record ID. The caller supplies the complete parameter dictionary discovered for the chosen product/artifact, a stable token valid for the operation, an authorized client, a reviewed launch-path ID and the reviewed names/IDs. Discover available paths with ListLaunchPaths; products with multiple paths require a top-level selection, not a template parameter. Launch paths This is a submission, not a readiness claim. A real invocation provisions resources; the lesson's local exercises use a fake client.

def submit_account(catalog, product_id, artifact_id, product_name, token, parameters, path_id):
    if not isinstance(parameters, dict) or not parameters:
        raise ValueError("reviewed product parameters required")
    if any(not isinstance(k, str) or not k or not isinstance(v, str)
           for k, v in parameters.items()):
        raise ValueError("parameter keys/values must be strings")
    if not isinstance(path_id, str) or not path_id:
        raise ValueError("reviewed launch-path ID required")
    result = catalog.provision_product(
        ProductId=product_id, ProvisioningArtifactId=artifact_id, PathId=path_id,
        ProvisionedProductName=product_name, ProvisionToken=token,
        ProvisioningParameters=[{"Key": k, "Value": v}
                                for k, v in sorted(parameters.items())])
    return result["RecordDetail"]["RecordId"]

def provisioning_state(catalog, record_id):
    record = catalog.describe_record(Id=record_id)["RecordDetail"]
    return {"status": record["Status"],
            "errors": record.get("RecordErrors", [])}

RecordId is nested inside RecordDetail, not at the response root. Track IN_PROGRESS, SUCCEEDED, FAILED and any other documented intermediate status deliberately; report unknown statuses for investigation. Successful product provisioning is followed by checks of account enrollment, intended OU, control state, federation, logging delivery and service-specific baseline readiness. An account-created event can precede these conditions. ProvisionProduct, DescribeRecord

Treat baseline configuration as a repeatable reconciliation process. Discover existing GuardDuty/Security Hub configuration and delegated administration before attempting to create or enable it. Apply it in each intended Region and verify centrally. A retry should repair partial work rather than fail forever because an IAM role or detector already exists. Keep state and errors for each account/Region/control, and grant the automation only the supported permissions it needs. A successful Lambda return does not establish that every baseline step succeeded.

Use a trusted configuration catalog rather than assuming every member account can call management-only Organizations metadata APIs. Account IDs are identifiers, not secrets; hardcoding becomes a maintainability problem when it disconnects configuration from authoritative ownership. If tags drive configuration, control who can change them and handle missing values/pagination. Tag policies help standardize supported tagging behavior; they are not a universal mechanism forcing tags onto every resource. Tag policies

Organizations account creation and enabling all features are workflows with quotas and status, not instant toggles. Read the actual current account quota and request increases through the documented route. For an existing consolidated-billing-only organization, enabling all features has a documented approval/migration process; it does not enable every AWS service or automatically attach every desired policy. Verify completion rather than interpreting an initial handshake as success. Organizations quotas, Enabling all features

4. Application three: collect audit evidence that can actually be read

For an organization trail, use the management account or a supported delegated administrator with the required permissions and trusted-service configuration. Set IsOrganizationTrail=True; a collection of ordinary member-account trails is not the same configuration. Choose the intended Regions and event selectors, start logging, and verify delivery. Creating a trail alone does not start it. Organization trail setup

This request builder assumes an existing reviewed S3 bucket and usable KMS key. The bucket policy must allow the documented CloudTrail ACL check and writes to the correct paths, and the key policy must permit the required encryption operations. For an organization trail, use the documented management-account trail ARN in aws:SourceArn conditions, including when a delegated administrator creates the trail. A name such as “OrganizationTrail” has no special enforcement meaning.

def organization_trail_request(name, bucket, kms_key_arn):
    return {"Name": name, "S3BucketName": bucket,
            "IsOrganizationTrail": True, "IsMultiRegionTrail": True,
            "IncludeGlobalServiceEvents": True,
            "EnableLogFileValidation": True, "KmsKeyId": kms_key_arn}

def trail_delivery_evidence(cloudtrail, trail_arn):
    status = cloudtrail.get_trail_status(Name=trail_arn)
    return {"logging_enabled": status.get("IsLogging", False),
            "latest_delivery": status.get("LatestDeliveryTime"),
            "delivery_error": status.get("LatestDeliveryError"),
            "latest_digest_delivery": status.get("LatestDigestDeliveryTime")}

Pass the request to create_trail, then use start_logging after configuring the complete prerequisites. logging_enabled=True with no recent delivery evidence is not proof of working end-to-end collection. Generate an approved benign test event in each relevant account/Region, locate it in the central store and query it with the intended audit principal. Check freshness, selectors, decrypt/read access and the source identity. Data events, such as selected S3 object operations, need their own event selection; management event coverage is not “all activity.” Trail status, Event selectors

CloudTrail organization paths and Config delivery paths are different. Config uses account-specific delivery paths, and a Config aggregator is a cross-account/Region view rather than an automatic recorder/delivery setup in every source. Configure and validate each service independently. GuardDuty findings and VPC Flow Logs also require their own supported centralization choices. CloudTrail bucket policies, Config S3 delivery, Config aggregation

Encryption, versioning, log-file integrity validation and immutable retention solve different problems. KMS encryption does not stop an authorized deletion. CloudTrail log-file validation supplies digest evidence for checking integrity; enabling it does not perform every validation automatically. S3 Object Lock has explicit mode and retention semantics that require deliberate configuration, while lifecycle transitions change storage class. Do not claim MFA Delete is enabled when a script only enables versioning, or combine features without checking their compatibility. Test retrieval/decryption of old evidence and protect the keys for the required retention period. CloudTrail integrity validation, Object Lock

Maintain both positive and negative evidence: intended writers deliver; unauthorized users cannot alter or read protected records; authorized auditors can retrieve them; operational alarms detect a deliberately simulated delivery failure. Store the test date, principal, account/Region, expected result and observed evidence. A screenshot of an empty bucket is not a successful logging test.

5. Application four: deploy across accounts through a traceable trust path

Cross-account access has multiple gates. The caller needs permission to assume the target role; the target trust policy must accept that caller and its conditions; the resulting session needs permissions for the operation; resource/KMS policies and applicable organization controls must also allow the access. Trusting arn:aws:iam::ACCOUNT:root delegates to that account, not only to its root user. Prefer a deliberately scoped deployment principal when that fits the lifecycle. Cross-account role evaluation

For a third-party provider acting for many customers, an external ID helps address the confused-deputy problem. The provider assigns a unique value per customer and supplies it when assuming that customer's role. It is not a secret password and does not replace a restrictive principal and permission policy. A source-IP condition on the role assumption constrains that assumption request; it does not automatically restrict every subsequent API call made with the session credentials. Third-party external IDs

This helper shows only role assumption. Supply the reviewed provider-assigned ID when the trust policy requires it, and a known permitted source context. Do not log the returned credentials; use the SDK's supported refresh/provider mechanisms for long-running clients rather than assuming a one-hour session lasts forever.

def assume_reviewed_role(sts, role_arn, session_name, external_id):
    result = sts.assume_role(RoleArn=role_arn,
                             RoleSessionName=session_name,
                             ExternalId=external_id,
                             DurationSeconds=3600)
    return result["Credentials"]

A central CodePipeline deployment typically involves three different roles: the pipeline service role in the tooling account, an action role in the target account, and a CloudFormation execution role in the target account. The action role invokes deployment and passes the permitted execution role; CloudFormation uses that execution role to change resources. Avoid granting broad iam:PassRole over unrelated privileged roles.

For cross-account artifacts, configure the S3 bucket policy and a suitable customer-managed KMS key, including grants/policies for the required accounts and roles. An AWS-managed artifact key is not a drop-in cross-account substitute. A target role ARN in a stage does not supply artifact read/decrypt permissions. Do not require an arbitrary ExternalId in an action-role trust policy unless the actual service integration supplies it; the generic cross-account action definition has no field for an arbitrary external ID. Cross-account CodePipeline

Use one built, versioned artifact for development validation and production promotion. Bind approval to that artifact identity and evidence: tests, configuration, data migration, rollback/recovery, expected service impact and relevant security checks. If the artifact changes, the old approval should not silently authorize it. A manual approval button does not prove the content was reviewed. Separate the ability to change the pipeline from the ability to approve a release when that separation is part of the requirement.

AWS RAM shares supported resource types across eligible principals; it does not make all resources shareable or remove their service-specific permissions. A shared VPC subnet requires the documented organization/VPC-sharing prerequisites, and participants still need permissions to launch supported resources. A transit gateway can be shared; do not describe all of its attachments as freely transferable shares. Confirm the current resource-type list instead of assuming every Aurora cluster or networking object is supported. RAM shareable resources, Shared VPC responsibilities

A central audit hub can assume purpose-built read roles in workload accounts. The roles should expose the evidence needed, with explicit treatment of sensitive data and decryption. Reciprocal trust is not automatically an exploit, but every allowed path needs a reason and a review of possible privilege escalation. Draw the assumed-role direction separately from the trust declaration so reviewers can trace who can do what.

6. Finish with a readiness review

For a company with Engineering, Marketing and Finance, propose six workload accounts for production and development plus the central accounts needed for administration, audit and logging. Explain whether OUs follow environment policies, business ownership or a deliberate combination; there is more than one valid structure. Show the inherited policy path and the narrowly scoped audit/deployment trust paths.

Before declaring the platform ready, present evidence that a permitted workload operation succeeds, a prohibited one fails for the intended reason, a newly provisioned account completes its baseline, and central logs are delivered and readable. Demonstrate that deployment uses the reviewed artifact and that recovery works within the workload's stated objectives. Assign owners for exceptions and unresolved controls.

Use operational reviews to revisit those assumptions: new services, changed trust, new data flows, quota pressure, drift and staff changes can invalidate yesterday's evidence. Professional mastery is the ability to explain a boundary precisely, demonstrate it, and keep it correct as the system evolves.