Practice cloud-native design pattern vocabulary: sidecar, ambassador, adapter, and strangler fig patterns for container-based architectures.
0 / 18 completed
1 / 18
An architect says 'We use the sidecar pattern to add logging without modifying the main container.' What does the sidecar pattern do?
The sidecar pattern deploys a helper container alongside the main application container in the same pod. The sidecar handles cross-cutting concerns (logging, service mesh proxy, secrets injection) without requiring changes to the main application.
2 / 18
Your design doc says 'We use the ambassador pattern to proxy network calls to the payment service.' What does the ambassador pattern provide?
The ambassador pattern places a proxy container (the ambassador) that intercepts outgoing network calls and handles concerns like retries, circuit breaking, authentication, and routing. The main container communicates with localhost; the ambassador handles the real network complexity.
3 / 18
An architecture review mentions 'the adapter pattern standardizes interfaces.' In cloud-native contexts, what does this mean?
The adapter pattern in cloud-native architecture wraps an application to make it conform to a standardized interface. For example, converting application logs from a custom format to a standard format consumed by the logging infrastructure — without changing the application itself.
4 / 18
A migration plan says 'We use the strangler fig to migrate the monolith.' What is the strangler fig pattern?
The strangler fig pattern (named after the plant that grows around a tree until it replaces it) migrates a monolith incrementally. New features are built as microservices; existing functionality is migrated piece by piece with a routing facade — avoiding a risky big-bang rewrite.
5 / 18
A colleague contrasts 'sidecar vs. init container.' What is an init container in Kubernetes?
Init containers in Kubernetes run sequentially before the main container starts. They are used for initialization tasks — downloading config, running database migrations, waiting for dependencies to be ready — and terminate once their work is done.
6 / 18
PR Description:
"Implemented the Circuit Breaker pattern for our external API calls to reduce cascading failures. Initial testing shows a significant improvement in resilience."
This question tests understanding of the core functionality of the Circuit Breaker pattern. The pattern's primary purpose isn't authentication or data replication, but rather to *isolate* a failing service and prevent it from overwhelming dependent systems. It achieves this by temporarily halting requests when an upstream dependency becomes unavailable, thereby mitigating cascading failures – a key benefit often discussed in cloud-native resilience strategies.
7 / 18
During a code review, your senior engineer asks you, 'Can you elaborate on why we implemented the *fault tolerance* aspect using this specific pattern?' What are you primarily communicating when you respond with: 'We used a Circuit Breaker to prevent cascading failures and improve our system's resilience.'?
The question focuses on the *reason* behind using a particular pattern to achieve fault tolerance. Option A incorrectly implies a singular tool; in reality, patterns are selected based on their ability to address specific problems like cascading failures. Option B is too granular – the code itself isn't the primary communication here. Option C accurately reflects the core purpose of the Circuit Breaker: it's designed to improve resilience by stopping chains of errors. Option D is irrelevant; the question probes the strategic justification for pattern choice, not simply adherence to standards.
8 / 18
PR Description:
"Implemented the Circuit Breaker pattern for our external API calls to reduce cascading failures. Initial testing shows a significant improvement in resilience."
This question tests understanding of the core functionality of the Circuit Breaker pattern. The pattern's primary purpose isn't authentication or data replication, but rather to *isolate* a failing service and prevent it from overwhelming dependent systems. It achieves this by temporarily halting requests when an upstream dependency becomes unavailable, thereby mitigating cascading failures – a key benefit often discussed in cloud-native resilience strategies.
9 / 18
During a code review, your senior engineer asks you, 'Can you elaborate on why we implemented the *fault tolerance* aspect using this specific pattern?' What are you primarily communicating when you respond with: 'We used a Circuit Breaker to prevent cascading failures and improve our system's resilience.'?
The question focuses on the *reason* behind using a particular pattern to achieve fault tolerance. Option A incorrectly implies a singular tool; in reality, patterns are selected based on their ability to address specific problems like cascading failures. Option B is too granular – the code itself isn't the primary communication here. Option C accurately reflects the core purpose of the Circuit Breaker: it's designed to improve resilience by stopping chains of errors. Option D is irrelevant; the question probes the strategic justification for pattern choice, not simply adherence to standards.
10 / 18
PR Description:
"Implemented the Circuit Breaker pattern for our external API calls to reduce cascading failures. Initial testing shows a significant improvement in resilience."
This question tests understanding of the core functionality of the Circuit Breaker pattern. The pattern's primary purpose isn't authentication or data replication, but rather to *isolate* a failing service and prevent it from overwhelming dependent systems. It achieves this by temporarily halting requests when an upstream dependency becomes unavailable, thereby mitigating cascading failures – a key benefit often discussed in cloud-native resilience strategies.
11 / 18
During a code review, your senior engineer asks you, 'Can you elaborate on why we implemented the *fault tolerance* aspect using this specific pattern?' What are you primarily communicating when you respond with: 'We used a Circuit Breaker to prevent cascading failures and improve our system's resilience.'?
The question focuses on the *reason* behind using a particular pattern to achieve fault tolerance. Option A incorrectly implies a singular tool; in reality, patterns are selected based on their ability to address specific problems like cascading failures. Option B is too granular – the code itself isn't the primary communication here. Option C accurately reflects the core purpose of the Circuit Breaker: it's designed to improve resilience by stopping chains of errors. Option D is irrelevant; the question probes the strategic justification for pattern choice, not simply adherence to standards.
12 / 18
PR Description:
"Implemented the Circuit Breaker pattern for our external API calls to reduce cascading failures. Initial testing shows a significant improvement in resilience."
This question tests understanding of the core functionality of the Circuit Breaker pattern. The pattern's primary purpose isn't authentication or data replication, but rather to *isolate* a failing service and prevent it from overwhelming dependent systems. It achieves this by temporarily halting requests when an upstream dependency becomes unavailable, thereby mitigating cascading failures – a key benefit often discussed in cloud-native resilience strategies.
13 / 18
During a code review, your senior engineer asks you, 'Can you elaborate on why we implemented the *fault tolerance* aspect using this specific pattern?' What are you primarily communicating when you respond with: 'We used a Circuit Breaker to prevent cascading failures and improve our system's resilience.'?
The question focuses on the *reason* behind using a particular pattern to achieve fault tolerance. Option A incorrectly implies a singular tool; in reality, patterns are selected based on their ability to address specific problems like cascading failures. Option B is too granular – the code itself isn't the primary communication here. Option C accurately reflects the core purpose of the Circuit Breaker: it's designed to improve resilience by stopping chains of errors. Option D is irrelevant; the question probes the strategic justification for pattern choice, not simply adherence to standards.
14 / 18
Sarah (Lead DevOps) sends this Slack message to the team: 'Just finished setting up a dedicated container for Prometheus metrics collection. It's separate from our main application containers – that's the key!'. What design pattern is Sarah primarily illustrating?
Sarah's message describes a separate container solely dedicated to collecting metrics. This aligns perfectly with the sidecar pattern, where supporting components are deployed alongside the main application containers to handle specific tasks like monitoring or logging—avoiding interference and simplifying management. The other options represent distinct patterns focused on different architectural concerns.
15 / 18
During a code review, your team lead asks: 'Can you explain how this implementation utilizes the *bulkhead* pattern?' You respond with: 'We've isolated specific service calls into separate processes to prevent a failure in one from impacting others.' What are you emphasizing when describing the bulkhead pattern?
The bulkhead pattern's core purpose is to isolate failures. By running services in separate processes (or containers), a problem within one service won't cascade and bring down the entire system – this is fault isolation. The other options represent potential side effects or related improvements, but not the fundamental goal of the pattern.
16 / 18
PR Description:
"Implemented a new API gateway using an Ambassador pattern. This allows our microservices to communicate with external systems—particularly payment services—without exposing internal details. The gateway handles authentication and rate limiting."
The Ambassador pattern's key function is to abstract and proxy requests to downstream services. In this case, it's shielding internal service details while still providing a consistent interface for external communication—primarily enhancing security by controlling access and applying rate limiting. Latency improvements or scaling are secondary benefits.
17 / 18
During the daily stand-up, you say: 'We're using a Strangler Fig pattern to migrate our legacy monolith. We're gradually building new features in separate services and routing traffic to them.' What is your primary communication when describing this approach?
The Strangler Fig pattern involves gradually replacing components of a monolithic system with new microservices. Crucially, it maintains backward compatibility – allowing users to continue using existing functionality while new features are built and transitioned over time. This phased approach minimizes risk and disruption compared to a complete rewrite.
18 / 18
A developer asks: 'What's the difference between an init container and a sidecar container in Kubernetes?' You respond with: 'An init container runs before the main application container starts, setting up dependencies. A sidecar container runs alongside the main container to provide supporting functionality.' Which statement best describes your explanation?
The key difference lies in their roles within the container lifecycle. Init containers execute before the main application starts, preparing the environment (e.g., setting up databases), while sidecar containers run alongside for supporting tasks like logging or metrics collection – demonstrating a fundamental distinction in timing and function.
What will I practice in "Cloud-Native Design Patterns Vocabulary"?
This is a Cloud-Native exercise set. It walks through 18 scenario-based multiple-choice questions built around real usage of Cloud-Native 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 18 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-Native 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-Native exercises?
See the Cloud-Native 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-Native vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.