Learn the IT-English vocabulary of container orchestration: scheduling, desired state, replicas, self-healing and scaling.
0 / 26 completed
1 / 26
An orchestrator maintains the 'desired state'. What does that mean?
Desired-state orchestration constantly works to make reality match the declared spec (e.g. 'run 3 replicas').
2 / 26
What does 'self-healing' refer to in orchestration?
Self-healing means the orchestrator replaces failed containers to keep the desired state.
3 / 26
A service runs three 'replicas'. What is a replica?
Replicas are duplicate instances of a workload for availability and capacity.
4 / 26
The orchestrator 'schedules' a container. What does scheduling decide?
Scheduling places workloads onto nodes that satisfy their resource and constraint requirements.
5 / 26
Which sentence correctly uses 'horizontal scaling'?
Horizontal scaling adds more instances; vertical scaling adds more resources to one instance.
6 / 26
Sarah: 'Hey team, I've merged the new deployment for OrderService into production. It's running, but the logs show intermittent errors related to database connection timeouts. I've increased the number of replicas in Kubernetes to 5. Should we investigate further?
Review Comment: 'Looks like the service is scaling up – good job! However, the error rate seems high for five instances; can you check the resource utilization metrics and ensure there isn't a bottleneck somewhere?'
The correct answer focuses on the 'desired state' concept. Orchestration tools like Kubernetes don't simply react to errors; they strive to maintain what was *configured*. Increasing replicas is a common strategy to distribute load and address potential issues, but it's not a *solution* without understanding *why* the error rate is high. The comment highlights the importance of monitoring resources and confirming the orchestrator is aligned with the intended configuration.
7 / 26
PR Description
Subject: Deploying v2.3 of UserProfileService - Increased Replica Count
This PR deploys version 2.3 of the UserProfileService with an increased replica count to 4, addressing recent performance concerns identified during load testing. The increase was implemented based on recommendations from the monitoring team.
This question assesses understanding of horizontal scaling. The correct answer highlights how increasing replicas allows an orchestrator to dynamically adjust capacity based on demand – this is the core concept behind horizontal scaling. Options A and D are incorrect because they misrepresent the primary goal of replica changes; option B oversimplifies the benefit, while option C accurately describes the orchestrated response to increased load.
8 / 26
John in the DevOps Slack channel: 'Just deployed the new authentication service. We bumped up the number of replicas to 10 because we were seeing a spike in traffic during the morning peak. Seems like it's handling things better now.'
Maria (Code Reviewer) comments on John's PR description:
'That's great, but can you elaborate on what 'bumped up the number of replicas' actually *means* in this context? I want to understand how we're ensuring resilience and handling potential future load increases.'
The term 'replicas' in container orchestration, particularly with Kubernetes, refers to *multiple* identical copies of a running application. Increasing the number of replicas means the orchestrator creates and manages ten separate instances of the authentication service – this allows the system to handle more requests concurrently, improving resilience and scaling horizontally. Option A is incorrect because CPU allocation isn't directly tied to the replica count; options C and D misinterpret the meaning of 'replicas' in this scenario.
9 / 26
John increased the number of replicas for the new authentication service. What is the primary purpose of this action in the context of container orchestration?
Hint: Consider how orchestrators manage application availability and responsiveness.
John's action of increasing the number of replicas is a fundamental concept in container orchestration. Orchestrators like Kubernetes use replicas to ensure high availability and fault tolerance – if one instance fails, others can seamlessly take over. Increasing the replica count allows the orchestrator to distribute incoming traffic across multiple instances, preventing overload on any single server and improving overall responsiveness. The key here is that it's about *distribution* of load, not just raw capacity.
10 / 26
Sarah: 'Hey team, I've merged the new deployment for OrderService into production. It's running, but the logs show intermittent errors related to database connection timeouts. I've increased the number of replicas in Kubernetes to 5. Should we investigate further?
Review Comment: 'Looks like the service is scaling up – good job! However, the error rate seems high for five instances; can you check the resource utilization metrics and ensure there isn't a bottleneck somewhere?'
The correct answer focuses on the 'desired state' concept. Orchestration tools like Kubernetes don't simply react to errors; they strive to maintain what was *configured*. Increasing replicas is a common strategy to distribute load and address potential issues, but it's not a *solution* without understanding *why* the error rate is high. The comment highlights the importance of monitoring resources and confirming the orchestrator is aligned with the intended configuration.
11 / 26
PR Description
Subject: Deploying v2.3 of UserProfileService - Increased Replica Count
This PR deploys version 2.3 of the UserProfileService with an increased replica count to 4, addressing recent performance concerns identified during load testing. The increase was implemented based on recommendations from the monitoring team.
This question assesses understanding of horizontal scaling. The correct answer highlights how increasing replicas allows an orchestrator to dynamically adjust capacity based on demand – this is the core concept behind horizontal scaling. Options A and D are incorrect because they misrepresent the primary goal of replica changes; option B oversimplifies the benefit, while option C accurately describes the orchestrated response to increased load.
12 / 26
John in the DevOps Slack channel: 'Just deployed the new authentication service. We bumped up the number of replicas to 10 because we were seeing a spike in traffic during the morning peak. Seems like it's handling things better now.'
Maria (Code Reviewer) comments on John's PR description:
'That's great, but can you elaborate on what 'bumped up the number of replicas' actually *means* in this context? I want to understand how we're ensuring resilience and handling potential future load increases.'
The term 'replicas' in container orchestration, particularly with Kubernetes, refers to *multiple* identical copies of a running application. Increasing the number of replicas means the orchestrator creates and manages ten separate instances of the authentication service – this allows the system to handle more requests concurrently, improving resilience and scaling horizontally. Option A is incorrect because CPU allocation isn't directly tied to the replica count; options C and D misinterpret the meaning of 'replicas' in this scenario.
13 / 26
John increased the number of replicas for the new authentication service. What is the primary purpose of this action in the context of container orchestration?
Hint: Consider how orchestrators manage application availability and responsiveness.
John's action of increasing the number of replicas is a fundamental concept in container orchestration. Orchestrators like Kubernetes use replicas to ensure high availability and fault tolerance – if one instance fails, others can seamlessly take over. Increasing the replica count allows the orchestrator to distribute incoming traffic across multiple instances, preventing overload on any single server and improving overall responsiveness. The key here is that it's about *distribution* of load, not just raw capacity.
14 / 26
Sarah: 'Hey team, I've merged the new deployment for OrderService into production. It's running, but the logs show intermittent errors related to database connection timeouts. I've increased the number of replicas in Kubernetes to 5. Should we investigate further?
Review Comment: 'Looks like the service is scaling up – good job! However, the error rate seems high for five instances; can you check the resource utilization metrics and ensure there isn't a bottleneck somewhere?'
The correct answer focuses on the 'desired state' concept. Orchestration tools like Kubernetes don't simply react to errors; they strive to maintain what was *configured*. Increasing replicas is a common strategy to distribute load and address potential issues, but it's not a *solution* without understanding *why* the error rate is high. The comment highlights the importance of monitoring resources and confirming the orchestrator is aligned with the intended configuration.
15 / 26
PR Description
Subject: Deploying v2.3 of UserProfileService - Increased Replica Count
This PR deploys version 2.3 of the UserProfileService with an increased replica count to 4, addressing recent performance concerns identified during load testing. The increase was implemented based on recommendations from the monitoring team.
This question assesses understanding of horizontal scaling. The correct answer highlights how increasing replicas allows an orchestrator to dynamically adjust capacity based on demand – this is the core concept behind horizontal scaling. Options A and D are incorrect because they misrepresent the primary goal of replica changes; option B oversimplifies the benefit, while option C accurately describes the orchestrated response to increased load.
16 / 26
John in the DevOps Slack channel: 'Just deployed the new authentication service. We bumped up the number of replicas to 10 because we were seeing a spike in traffic during the morning peak. Seems like it's handling things better now.'
Maria (Code Reviewer) comments on John's PR description:
'That's great, but can you elaborate on what 'bumped up the number of replicas' actually *means* in this context? I want to understand how we're ensuring resilience and handling potential future load increases.'
The term 'replicas' in container orchestration, particularly with Kubernetes, refers to *multiple* identical copies of a running application. Increasing the number of replicas means the orchestrator creates and manages ten separate instances of the authentication service – this allows the system to handle more requests concurrently, improving resilience and scaling horizontally. Option A is incorrect because CPU allocation isn't directly tied to the replica count; options C and D misinterpret the meaning of 'replicas' in this scenario.
17 / 26
John increased the number of replicas for the new authentication service. What is the primary purpose of this action in the context of container orchestration?
Hint: Consider how orchestrators manage application availability and responsiveness.
John's action of increasing the number of replicas is a fundamental concept in container orchestration. Orchestrators like Kubernetes use replicas to ensure high availability and fault tolerance – if one instance fails, others can seamlessly take over. Increasing the replica count allows the orchestrator to distribute incoming traffic across multiple instances, preventing overload on any single server and improving overall responsiveness. The key here is that it's about *distribution* of load, not just raw capacity.
18 / 26
Sarah: 'Hey team, I've merged the new deployment for OrderService into production. It's running, but the logs show intermittent errors related to database connection timeouts. I've increased the number of replicas in Kubernetes to 5. Should we investigate further?
Review Comment: 'Looks like the service is scaling up – good job! However, the error rate seems high for five instances; can you check the resource utilization metrics and ensure there isn't a bottleneck somewhere?'
The correct answer focuses on the 'desired state' concept. Orchestration tools like Kubernetes don't simply react to errors; they strive to maintain what was *configured*. Increasing replicas is a common strategy to distribute load and address potential issues, but it's not a *solution* without understanding *why* the error rate is high. The comment highlights the importance of monitoring resources and confirming the orchestrator is aligned with the intended configuration.
19 / 26
PR Description
Subject: Deploying v2.3 of UserProfileService - Increased Replica Count
This PR deploys version 2.3 of the UserProfileService with an increased replica count to 4, addressing recent performance concerns identified during load testing. The increase was implemented based on recommendations from the monitoring team.
This question assesses understanding of horizontal scaling. The correct answer highlights how increasing replicas allows an orchestrator to dynamically adjust capacity based on demand – this is the core concept behind horizontal scaling. Options A and D are incorrect because they misrepresent the primary goal of replica changes; option B oversimplifies the benefit, while option C accurately describes the orchestrated response to increased load.
20 / 26
John in the DevOps Slack channel: 'Just deployed the new authentication service. We bumped up the number of replicas to 10 because we were seeing a spike in traffic during the morning peak. Seems like it's handling things better now.'
Maria (Code Reviewer) comments on John's PR description:
'That's great, but can you elaborate on what 'bumped up the number of replicas' actually *means* in this context? I want to understand how we're ensuring resilience and handling potential future load increases.'
The term 'replicas' in container orchestration, particularly with Kubernetes, refers to *multiple* identical copies of a running application. Increasing the number of replicas means the orchestrator creates and manages ten separate instances of the authentication service – this allows the system to handle more requests concurrently, improving resilience and scaling horizontally. Option A is incorrect because CPU allocation isn't directly tied to the replica count; options C and D misinterpret the meaning of 'replicas' in this scenario.
21 / 26
John increased the number of replicas for the new authentication service. What is the primary purpose of this action in the context of container orchestration?
Hint: Consider how orchestrators manage application availability and responsiveness.
John's action of increasing the number of replicas is a fundamental concept in container orchestration. Orchestrators like Kubernetes use replicas to ensure high availability and fault tolerance – if one instance fails, others can seamlessly take over. Increasing the replica count allows the orchestrator to distribute incoming traffic across multiple instances, preventing overload on any single server and improving overall responsiveness. The key here is that it's about *distribution* of load, not just raw capacity.
22 / 26
Maria is discussing a recent deployment with the team. She states: 'We increased the number of replicas for our API service from 2 to 8. This was done because we've seen a significant increase in user requests during peak hours.' What is Maria primarily referring to when she mentions increasing the 'number of replicas'?
Maria correctly identifies that increasing replicas is about handling increased load. Container orchestration systems like Kubernetes automatically scale applications by creating more instances (replicas) when demand rises – this ensures availability and responsiveness. The other options misrepresent the core function of replica management.
23 / 26
During a standup meeting, David says: 'We're running Kubernetes deployments for our microservices. We've been monitoring CPU utilization and noticed the service responsible for processing user payments is consistently hitting 90% during peak times. To address this, we increased its replica count from 3 to 15.' What was David's *primary* motivation for changing the deployment configuration?
David's action was driven by performance monitoring – specifically high CPU utilization. Increasing the replica count allows the system to distribute the workload across more instances, preventing bottlenecks and improving response times under heavy load. This is a core principle of scaling applications in container orchestration.
24 / 26
You receive this Slack message from a teammate: 'Just deployed the new notification service. We bumped up the number of replicas to 20 because we were seeing increased error rates in our logging pipeline – specifically, messages weren't being delivered reliably.' What is the *underlying* problem this action attempts to resolve?
The Slack message highlights a critical issue: unreliable message delivery. Increasing the number of replicas is a *reactive* measure to mitigate the impact of a failing logging pipeline on the notification service's availability and reliability – it's addressing the symptom, not the root cause.
25 / 26
Sarah is reviewing a PR that updates the deployment of the 'Product Catalog' service. The description states: 'Increased replica count to 6 to improve read performance under heavy user loads.' What does Sarah *most* likely understand is the relationship between this change and container orchestration?
Sarah correctly grasps that increasing replica count facilitates parallel processing of read requests. This is a fundamental mechanism in container orchestration – by running multiple instances concurrently, the system can handle more user requests simultaneously, reducing latency and improving throughput for read-heavy operations.
26 / 26
During a code review discussion, you notice a comment on a PR that changes the number of replicas for a microservice from 4 to 12. The reviewer states: 'This change should improve availability during peak traffic.' Which aspect of container orchestration is this comment primarily referencing?
The reviewer's statement directly relates to availability and fault tolerance. Container orchestration systems automatically manage failover – if one replica fails, another takes over its workload, ensuring continuous service operation. This is a core function of orchestrators in providing high availability.
What does the "Container Orchestration Basics" exercise practise?
Learn the IT-English vocabulary of container orchestration: scheduling, desired state, replicas, self-healing and scaling.
How many questions are in this exercise?
This exercise has 26 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Containers & Virtualization category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Container Orchestration Basics" part of a larger series?
Yes — it's one exercise in the Containers & Virtualization category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Containers & Virtualization category page for related exercises, or browse the main Exercises hub for other IT English topics.