Learn the IT-English vocabulary of cloud cost tagging: cost allocation tags, tag governance, showback and untagged resources.
0 / 22 completed
1 / 22
A FinOps lead says: 'Every resource needs a cost-allocation tag.' What does such a tag enable?
Cost-allocation tags let you break down the bill by owner, project or environment.
2 / 22
What are 'untagged resources' a problem for?
Untagged resources can't be attributed, leaving spend unaccounted for in cost reports.
3 / 22
The team enforces 'tag governance'. What does that mean?
Tag governance enforces a consistent, mandatory tagging scheme via policy and tooling.
4 / 22
Which sentence correctly uses 'showback'?
Showback presents each team its costs for awareness; chargeback actually bills them.
5 / 22
A 'tagging policy' specifies a required key 'environment'. What might its values be?
An environment tag commonly takes controlled values like prod/staging/dev for clean reporting.
6 / 22
Reviewer: 'I'm seeing a lot of inconsistent tagging on these EC2 instances. Some have 'dev', others have 'staging'. This is making it impossible to accurately track our cloud spend by team.
PR Description: 'Applying the environment tag to all new EC2 instances in the production environment.'
This scenario focuses on practical tagging application. The reviewer's comment highlights a common issue: inconsistent tagging hinders cost analysis. While 'showback' is relevant to tag usage, the PR description's primary purpose is to define the key and its values – this is what the reviewer is reacting to. The incorrect options reflect misunderstandings about showback or focus on implementation details rather than the strategic goal of consistent tagging.
7 / 22
Senior Developer (Slack Message)
Hey team, just noticed a bunch of new Lambda functions being deployed without the `owner:backend` tag. We're trying to get a really clear picture of which teams are responsible for each service – it's making our cost analysis *way* harder. Anyone know if there's a quick way to batch-apply this tag to existing functions? 🤔
This question assesses understanding of *why* tagging is important beyond just 'labeling resources'. The `owner:backend` tag specifically addresses the need for traceability and accurate cost allocation by associating Lambda functions with their responsible team. The incorrect options highlight common misconceptions – that tags are merely redundant or that retroactively applying them is inherently problematic. The key here is recognizing the practical business value of detailed tagging beyond just technical identification.
8 / 22
Reviewer: 'We need to implement a 'showback' strategy for our tagging. Currently, the engineering team is absorbing all costs related to database usage, but management wants to see which departments are directly contributing.' What does a 'showback' strategy primarily aim to achieve in this context?
Showback refers to the practice of attributing cloud costs directly back to the teams or departments that consume those resources. This contrasts with absorption, where costs are consolidated. In this scenario, implementing a showback strategy would allow management to accurately see which departments are responsible for the database usage costs, fulfilling their request for greater visibility and accountability. The incorrect options misinterpret 'showback' as resource allocation adjustment or centralized billing; it's fundamentally about traceability of cost.
9 / 22
Reviewer: 'I'm seeing a lot of inconsistent tagging on these EC2 instances. Some have 'dev', others have 'staging'. This is making it impossible to accurately track our cloud spend by team.
PR Description: 'Applying the environment tag to all new EC2 instances in the production environment.'
This scenario focuses on practical tagging application. The reviewer's comment highlights a common issue: inconsistent tagging hinders cost analysis. While 'showback' is relevant to tag usage, the PR description's primary purpose is to define the key and its values – this is what the reviewer is reacting to. The incorrect options reflect misunderstandings about showback or focus on implementation details rather than the strategic goal of consistent tagging.
10 / 22
Senior Developer (Slack Message)
Hey team, just noticed a bunch of new Lambda functions being deployed without the `owner:backend` tag. We're trying to get a really clear picture of which teams are responsible for each service – it's making our cost analysis *way* harder. Anyone know if there's a quick way to batch-apply this tag to existing functions? 🤔
This question assesses understanding of *why* tagging is important beyond just 'labeling resources'. The `owner:backend` tag specifically addresses the need for traceability and accurate cost allocation by associating Lambda functions with their responsible team. The incorrect options highlight common misconceptions – that tags are merely redundant or that retroactively applying them is inherently problematic. The key here is recognizing the practical business value of detailed tagging beyond just technical identification.
11 / 22
Reviewer: 'We need to implement a 'showback' strategy for our tagging. Currently, the engineering team is absorbing all costs related to database usage, but management wants to see which departments are directly contributing.' What does a 'showback' strategy primarily aim to achieve in this context?
Showback refers to the practice of attributing cloud costs directly back to the teams or departments that consume those resources. This contrasts with absorption, where costs are consolidated. In this scenario, implementing a showback strategy would allow management to accurately see which departments are responsible for the database usage costs, fulfilling their request for greater visibility and accountability. The incorrect options misinterpret 'showback' as resource allocation adjustment or centralized billing; it's fundamentally about traceability of cost.
12 / 22
Reviewer: 'I'm seeing a lot of inconsistent tagging on these EC2 instances. Some have 'dev', others have 'staging'. This is making it impossible to accurately track our cloud spend by team.
PR Description: 'Applying the environment tag to all new EC2 instances in the production environment.'
This scenario focuses on practical tagging application. The reviewer's comment highlights a common issue: inconsistent tagging hinders cost analysis. While 'showback' is relevant to tag usage, the PR description's primary purpose is to define the key and its values – this is what the reviewer is reacting to. The incorrect options reflect misunderstandings about showback or focus on implementation details rather than the strategic goal of consistent tagging.
13 / 22
Senior Developer (Slack Message)
Hey team, just noticed a bunch of new Lambda functions being deployed without the `owner:backend` tag. We're trying to get a really clear picture of which teams are responsible for each service – it's making our cost analysis *way* harder. Anyone know if there's a quick way to batch-apply this tag to existing functions? 🤔
This question assesses understanding of *why* tagging is important beyond just 'labeling resources'. The `owner:backend` tag specifically addresses the need for traceability and accurate cost allocation by associating Lambda functions with their responsible team. The incorrect options highlight common misconceptions – that tags are merely redundant or that retroactively applying them is inherently problematic. The key here is recognizing the practical business value of detailed tagging beyond just technical identification.
14 / 22
Reviewer: 'We need to implement a 'showback' strategy for our tagging. Currently, the engineering team is absorbing all costs related to database usage, but management wants to see which departments are directly contributing.' What does a 'showback' strategy primarily aim to achieve in this context?
Showback refers to the practice of attributing cloud costs directly back to the teams or departments that consume those resources. This contrasts with absorption, where costs are consolidated. In this scenario, implementing a showback strategy would allow management to accurately see which departments are responsible for the database usage costs, fulfilling their request for greater visibility and accountability. The incorrect options misinterpret 'showback' as resource allocation adjustment or centralized billing; it's fundamentally about traceability of cost.
15 / 22
Reviewer: 'I'm seeing a lot of inconsistent tagging on these EC2 instances. Some have 'dev', others have 'staging'. This is making it impossible to accurately track our cloud spend by team.
PR Description: 'Applying the environment tag to all new EC2 instances in the production environment.'
This scenario focuses on practical tagging application. The reviewer's comment highlights a common issue: inconsistent tagging hinders cost analysis. While 'showback' is relevant to tag usage, the PR description's primary purpose is to define the key and its values – this is what the reviewer is reacting to. The incorrect options reflect misunderstandings about showback or focus on implementation details rather than the strategic goal of consistent tagging.
16 / 22
Senior Developer (Slack Message)
Hey team, just noticed a bunch of new Lambda functions being deployed without the `owner:backend` tag. We're trying to get a really clear picture of which teams are responsible for each service – it's making our cost analysis *way* harder. Anyone know if there's a quick way to batch-apply this tag to existing functions? 🤔
This question assesses understanding of *why* tagging is important beyond just 'labeling resources'. The `owner:backend` tag specifically addresses the need for traceability and accurate cost allocation by associating Lambda functions with their responsible team. The incorrect options highlight common misconceptions – that tags are merely redundant or that retroactively applying them is inherently problematic. The key here is recognizing the practical business value of detailed tagging beyond just technical identification.
17 / 22
Reviewer: 'We need to implement a 'showback' strategy for our tagging. Currently, the engineering team is absorbing all costs related to database usage, but management wants to see which departments are directly contributing.' What does a 'showback' strategy primarily aim to achieve in this context?
Showback refers to the practice of attributing cloud costs directly back to the teams or departments that consume those resources. This contrasts with absorption, where costs are consolidated. In this scenario, implementing a showback strategy would allow management to accurately see which departments are responsible for the database usage costs, fulfilling their request for greater visibility and accountability. The incorrect options misinterpret 'showback' as resource allocation adjustment or centralized billing; it's fundamentally about traceability of cost.
18 / 22
Reviewer: 'The PR description states 'Applying tags to improve cost allocation'. However, the tagging strategy seems ambiguous. We're using tags like 'dev', 'staging', and 'production' without a clear hierarchy. This makes it difficult to understand which services are associated with each environment.
What is the primary issue highlighted in this comment?
The core issue isn't about length or specific actions; it's that the current tagging system (using 'dev', 'staging', 'production') lacks a defined hierarchy. This ambiguity obscures the relationship between services and environments, hindering cost allocation understanding – this is what the reviewer directly points out.
19 / 22
Senior Developer (Slack Message):
'I'm seeing a lot of EC2 instances tagged with 'backend' but not linked to any specific team. This makes it impossible to accurately bill out the engineering department for cloud infrastructure costs. We need a consistent approach.
Which of the following actions would BEST address this situation?
The problem isn't simply about a lack of tags; it's the *absence of linkage* between the tags and teams. Requesting a meeting (option 3) is good, but a direct request to change the tags to 'engineering' (option 2) provides immediate corrective action – aligning the tags with the relevant team is key.
20 / 22
PR Description: 'Applying the tag:environment tag to all new deployments allows us to categorize resources by their intended environment (e.g., dev, staging, production). This will facilitate accurate cost tracking and reporting.'
What is a potential consequence of *not* consistently applying this tag?
While accurate cost tracking is a goal, the primary consequence of inconsistent tagging isn't directly about server costs. It's about *inaccurate reports*. The tag's purpose is to categorize resources; without that categorization, reporting will be flawed, leading to misinformed decisions – this is the core problem.
21 / 22
During the daily stand-up, John says: 'I'm working on adding a tag:owner tag to all new Lambda functions. This will help us track responsibility for each function.'
What is the *primary* benefit of this action, as described by John?
John's statement focuses on accountability – the tag is being used to track *responsibility*. While cost reduction might be a secondary benefit, the primary goal is establishing clear ownership for each Lambda function and this allows for easier maintenance and troubleshooting.
22 / 22
GET /cloud-spend?tag=owner&environment=productionResponse: {
"status": 200,
"data": [
{
"service": "database",
"cost": 1234.56,
"owner": "engineering"
},
{
"service": "compute",
"cost": 5678.90,
"owner": "devops"
}
]
}
What does the presence of the owner tag contribute to this API response?
The API response is structured to show costs grouped by service and owner. The presence of the `owner` tag allows for accurate cost allocation *by team* – a key benefit of a well-defined tagging strategy.
This is a Cloud FinOps exercise set. It walks through 22 scenario-based multiple-choice questions built around real usage of Cloud FinOps terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 22 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Cloud FinOps vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Cloud FinOps exercises?
See the Cloud FinOps exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Cloud FinOps vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.