> For the complete documentation index, see [llms.txt](https://docs.finopscenter.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.finopscenter.com/ai-cost-governance/cloud-engineer-enablement-tasks.md).

# Cloud Engineer Enablement Tasks

**Role:** Cloud Engineer **Location:** AI Governance → AI Tasks

The AI Tasks queue is where Cloud Engineers pick up the work generated by FinOps Lead model approvals. Each task represents one (model × account × region) combination that has been approved and needs IAM configuration before Product Owners can use it.

You do not need AWS console access beyond what you already have to complete these tasks — FinOps Center generates all CLI commands and deep links for each step.

### The AI Tasks Queue

The queue shows one row per pending task. Each row displays:

* Model name and ARN
* Target account and region
* Rationale entered by the FinOps Lead at approval time
* Current task status
* Date approved

**Task status values:**

| Status      | Meaning                                                             |
| ----------- | ------------------------------------------------------------------- |
| Pending     | Task created; no action taken yet                                   |
| In Progress | You have opened the task and started work                           |
| Implemented | You have marked the task complete; model is live for Product Owners |
| Cancelled   | The FinOps Lead blocked the model after task creation               |

Filter by status using the tabs at the top of the queue. The default view shows **Pending** tasks.

### Completing a Task

Click any task row to open the task detail panel. The panel contains four steps. Complete them in order.

#### Step 1 — Verify Model Access

Confirm that the model is accessible in the target account. The task panel includes a deep link to **AWS Bedrock Model Access** for the specific account and region. Open it and verify the model's access status is enabled. If it is not enabled, follow the AWS console steps to request access before proceeding.

#### Step 2 — Create the IAM Role

Create a dedicated IAM role for AI workloads using this model. The task panel generates the exact CLI command for this account, region, and model. Copy and run it in the target account.

The generated role name follows the convention:

```
finops-{sanitizedWorkloadName}-{4charId}
```

The trust policy scope is configurable — the task panel offers pre-generated trust policies for Lambda, EC2, and ECS use cases. Select the one that matches how workloads in this account invoke Bedrock.

#### Step 3 — Apply Deny Policy

Apply the deny-by-default policy to the role. This policy denies all Bedrock `InvokeModel` calls by default. The CLI command is pre-generated in the task panel. Run it in the target account.

#### Step 4 — Apply Model Allow Policy

Apply the model-specific allow policy. This policy uses the `bedrock:InvokedModelId` condition key to permit invocations only for the approved model ARN. The CLI command is pre-generated and scoped to the exact model ARN from the approval.

Run the command in the target account.

#### Developer Handoff Block

After completing Step 4, the task panel generates a **Developer Handoff block** containing:

* IAM Role ARN
* Approved Model ID
* Example SDK invocation snippet

This block is what the Product Owner needs to claim the role in Spaces and what the application team needs to configure their SDK calls. Copy it and share it with the Product Owner for this workload.

#### Marking the Task Implemented

Once all four steps are complete, click **Mark Implemented** at the bottom of the task panel.

This action:

* Changes the task status to **Implemented**
* Flips the ModelApprovalScope state to **Implemented** for this (account × region)
* Makes the model available in the Product Owner's Spaces wizard for this account and region

> **Important:** Do not mark a task Implemented until the IAM role is confirmed created and the allow policy is applied. Product Owners will attempt to claim the role immediately after Implemented status appears.

### Cross-Region Inference Profiles (MAP and High-Availability Workloads)

If the Business Request for a workload includes an **Availability Requirement** of **Production / High Availability**, the task panel will include an additional step to create an Application Inference Profile.

The inference profile is tagged:

```
map-migrated=mig{MPEID}
```

where `{MPEID}` is the MAP engagement ID shown in the task. This tagging is required for MAP credit eligibility. Create the profile before marking the task Implemented.

The inference profile ID is included in the Developer Handoff block when present.

### Claude Platform Tasks (Claude for Enterprise)

For Claude Platform workloads (CCU billing), the task steps differ from Bedrock:

1. Create the Claude Platform workspace via the Workspace creation flow.
2. Apply the `aws-external-anthropic:CreateInference` IAM policy to the role.
3. Mark the task Implemented.

The task panel identifies Claude Platform tasks with a **Platform: Claude Platform** badge and shows the workspace-specific steps in place of the standard Bedrock steps.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.finopscenter.com/ai-cost-governance/cloud-engineer-enablement-tasks.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
