The correct answer is C.

Explanation of the Recommended Strategy (Option C)

The company needs both:

• Retroactive visibility for existing RDS instances and DynamoDB tables (to address the current cost surge).
• Preventive enforcement for all future resources (current + future DynamoDB tables and RDS instances) to ensure cost center and project ID tags are always present.

Key steps in Option C:

1. Use Tag Editor to bulk-apply the required tags (cost center and project ID) to all existing eligible resources across multiple accounts.
   Tag Editor is a centralized console tool (and has API support) that lets you search and tag resources like RDS DB instances and DynamoDB tables in one or more accounts/regions without needing custom scripts.

2. Activate the tags as cost allocation tags in the AWS Billing console (under Cost allocation tags).
   This makes the tags visible in Cost Explorer, Cost and Usage Reports, and consolidated billing across the AWS Organization. Activation typically takes up to 24 hours (sometimes longer for full propagation in billing data).

3. Enforce tagging for new resources using Service Control Policies (SCPs) in AWS Organizations.
   SCPs can be attached at the Organization root, OUs (e.g., separate policies or one policy for dev + prod), or specific accounts. They deny Create/Modify actions (e.g., rds:CreateDBInstance, dynamodb:CreateTable, dynamodb:TagResource, etc.) if the required tags are missing or have invalid values.
   Example SCP structure (high-level):

   • Effect: Deny
   • Actions: Relevant RDS/DynamoDB create/update actions
   • Condition: StringNotEquals or Null checks on aws:RequestTag/cost-center and aws:RequestTag/project-id (or use tag policies for more advanced enforcement).

   Because the company already mandates CloudFormation for all infrastructure, SCPs work seamlessly—CloudFormation passes tags at creation time, and non-compliant stacks will simply fail. This provides preventive governance without relying on reactive fixes.

This approach gives immediate tagging for historical/existing resources + ongoing enforcement across the multi-account Organization, directly supporting billing transparency and cost management.

Why the Other Options Are Incorrect or Suboptimal

• Option A:
  Uses Tag Editor + cost allocation tags (good for existing resources and billing visibility).
  Missing: Any enforcement mechanism for future resources. New tables/instances could still be created without the tags, violating the management requirement for "all current and future" resources. Not a complete strategy.

• Option B:
  Relies on AWS Config (to detect untagged resources) + a centralized Lambda that runs every hour with cross-account roles to retroactively tag.
  This is reactive and operational overhead-heavy (hourly runs, custom Lambda code for RDS + DynamoDB, handling permissions, potential race conditions). It does not prevent creation of untagged resources upfront. AWS recommends preventive controls (like SCPs) over detective + corrective ones when possible, especially with CloudFormation already in use.

• Option D:
  Activates cost allocation tags (good) and tries to enforce via modifying federated roles (IAM policies with tag conditions, e.g., aws:RequestTag).
  Problems:

  • Only affects users/roles that go through those specific federated roles. It may not cover all access paths (e.g., service roles, cross-account access, or direct API calls).
  • Harder to manage consistently across many accounts and all IAM principals compared to a single SCP at the Organization level.
  • Less scalable and more error-prone than SCPs for organization-wide policy.

Additional Best Practices (for Exam Context)

• Combine Tag Policies (in Organizations) with SCPs for even stronger standardization (Tag Policies validate tag keys/values; SCPs enforce denial on create).
• For CloudFormation specifically, you can also use cfn-guard or StackSets with enforced parameters, but SCPs provide the strongest guardrail.
• Monitor compliance with AWS Config required-tags rule (supports RDS and DynamoDB) as a detective control on top of prevention.
• Cost allocation tags are not retroactive by default for past billing periods (though recent enhancements allow limited backfill in some cases); tagging existing resources + activation gives visibility going forward.

This strategy aligns with AWS Well-Architected Framework recommendations for Cost Optimization and Governance in multi-account environments using Organizations.