5 exercises — master the precise English vocabulary of the 12-Factor App methodology: environment-based config, backing services, disposability and graceful shutdown, dev/prod parity gaps, and treating logs as event streams.
0 / 26 completed
1 / 26
Factor III: Config — The 12-Factor methodology states: "Config that varies between deploy environments must be stored in environment variables, not in the codebase."
Why does 12-Factor specifically mandate environment variables rather than config files committed to the repository?
The core principle: config that varies per environment must never be committed to version control — not even in .env files that are "not pushed".
The dev/prod config problem that Factor III solves:
❌ Anti-pattern (config in code):
app.config.js:
database: {
host: 'localhost', ← dev DB; what happens in production?
password: 'dev123' ← committed to Git; leaked in public repos constantly
}
✓ 12-Factor (config in environment):
app.config.js:
database: {
host: process.env.DB_HOST, ← set per environment
password: process.env.DB_PASS, ← set via secrets manager, never in code
}
Why environment variables specifically (not just config files outside the repo):
Approach
Risk
Config in code
Config is code; wrong environment, leaked secrets, manual changes needed per deployment
Separate config files (not committed)
Language-specific formats; easy to accidentally commit; harder to manage across many services
Environment variables
OS-level; language-agnostic; cannot be committed to Git; standard contract between app and platform (Kubernetes Secrets, AWS Parameter Store, Vault)
Modern implementation in cloud-native deployments:
• Kubernetes: envFrom: secretRef — inject from Kubernetes Secrets
• AWS: Systems Manager Parameter Store / Secrets Manager → Lambda env vars or ECS task definitions
• Vault Agent sidecar: automatically populates environment variables from Vault secrets at pod start
• Never store secrets in ConfigMaps — ConfigMaps are not encrypted at rest; use Secrets
One practical test (12-Factor litmus): "Could you open-source your codebase right now, without compromising any credentials?" If the answer is no due to config in code, you are violating Factor III.
Key vocabulary:
• Factor III: Config — the 12-Factor principle requiring all environment-specific configuration to be stored in environment variables, not in the codebase
• Environment variable — a key-value pair provided to a process by the operating environment; language-agnostic and cannot be committed to version control
• Secrets management — securely storing, rotating, and injecting credentials using dedicated systems (Vault, AWS Secrets Manager, Kubernetes Secrets)
2 / 26
Factor IV: Backing Services — A 12-Factor application treats its PostgreSQL database, Redis cache, and email sending service as "attached resources, accessed via a URL or locator/credentials stored in config."
What does treating a dependency as a backing service operationally enable?
The backing service principle enforces loose coupling between the application and its dependencies — the application should not care whether it is talking to a local database or a managed cloud service, as long as the connection URL works.
Local vs. third-party backing services — same treatment:
Backing service type
Dev environment
Production environment
Database
postgres://localhost:5432/myapp
postgres://rds.amazonaws.com:5432/myapp
Cache
redis://localhost:6379
redis://elasticache.amazonaws.com:6379
Email
smtp://mailhog:1025 (local catcher)
smtp://email-smtp.us-east-1.amazonaws.com:587
Message queue
amqp://localhost:5672 (local RabbitMQ)
amqps://b-xxx.mq.amazonaws.com:5671 (Amazon MQ)
What changes between environments: only the URL in the environment variable.
What does not change: application code, build artifact, Dockerfile — the binary deployed to dev and prod is identical.
Backing services and disaster recovery:
During an incident where the primary database fails, switching to a replica is a config change — update DATABASE_URL to point to the read replica and restart the app. No code change, no new deployment pipeline.
What backing services are NOT (common misconception):
File system paths are not backing services — the 12-Factor App treats the local file system as a non-backing-service, ephemeral resource. Persistent data must be stored in a proper backing service (S3, a database).
Key vocabulary:
• Backing service — any service the app consumes over the network as part of its normal operation (database, queue, SMTP, API); treated as an attached resource addressable by URL
• Attached resource — a backing service that can be attached to or detached from the application by changing config without code modification
• Loose coupling — an architecture principle where components depend on abstractions (a database URL) rather than specific implementations (hardcoded localhost)
3 / 26
Factor IX: Disposability — A DevOps engineer adds a SIGTERM handler to the API service before deploying to Kubernetes:
"When the pod receives SIGTERM, the service must stop accepting new connections, finish processing in-flight requests, and exit within 10 seconds."
Which 12-Factor concern is the engineer directly addressing?
Disposability has two equally important halves: fast startup and graceful shutdown.
Disposability in the Kubernetes context:
Kubernetes rolling update:
1. New pod starts (fast startup → typically <5s for Go/Node, <30s for JVM)
2. New pod passes readiness probe → added to load balancer
3. Old pod receives SIGTERM → graceful shutdown
├─ Stop accepting new connections (remove from load balancer)
├─ Finish in-flight requests (drain period, e.g. 10s)
├─ Close database connections cleanly
└─ Acknowledge queued messages that have been processed
4. After terminationGracePeriodSeconds → SIGKILL (if still running)
What "fast startup" means in practice:
• Target: <10 seconds from process start to readiness
• Enables: rapid auto-scaling (scale out 20 pods when traffic spikes)
• Enables: fast rollback (new broken version → restart all pods quickly on last-known-good)
• Anti-patterns: 5-minute database migration runs at startup (move to init containers or separate migration job)
Disposability and message consumers:
A worker processing a job queue must:
• On SIGTERM: finish the current job, then ack it and exit (do not abandon mid-processing)
• If using SQS or RabbitMQ: use visibility timeout / ack-only-on-completion to ensure at-most-once or at-least-once delivery semantics
Why the other options are wrong:
• Factor VII (Port Binding) is about the app being self-contained and exporting services via a bound port — not about shutdown behaviour
• Factor VIII (Concurrency) is about scaling via process types (web, worker) — not about graceful shutdown
• Factor VI (Processes) is about stateless, share-nothing process execution — not about SIGTERM handling specifically
Key vocabulary:
• Factor IX: Disposability — 12-Factor principle that processes should be disposable: fast startup and graceful shutdown
• SIGTERM — Unix signal sent by Kubernetes to a container before termination; the application should shut down gracefully when received
• Graceful shutdown — a shutdown sequence where in-flight requests complete and connections are drained cleanly before the process exits
• terminationGracePeriodSeconds — the Kubernetes pod spec field defining how long to wait after SIGTERM before sending SIGKILL (default: 30s)
4 / 26
Factor X: Dev/Prod Parity — A team enforces a strict rule: "All developers must run PostgreSQL locally — SQLite is not permitted even for quick prototyping. The docker-compose.yml includes a postgres container for this reason."
Which specific type of dev/prod parity gap does this rule prevent?
Factor X identifies three types of parity gaps — the backing service gap with databases is the most operationally dangerous.
The three dev/prod parity gaps (Factor X):
Gap type
Example
Impact
Time gap
Developer works on a feature branch for 2 weeks; deploys code that assumes a schema not yet in production
Integration failures at deploy time; long-lived feature branches diverge from main
Personnel gap
"Dev writes it, ops deploys it" — engineers never see their code in production context
Developers unaware of production constraints; "works on my machine" culture
Backing service gap
SQLite in dev, PostgreSQL in production
Production-only bugs that cannot be reproduced locally
Concrete ways SQLite vs PostgreSQL diverges:
• Constraint enforcement — SQLite ignores type affinity mismatches; PostgreSQL enforces strict typing
• AUTOINCREMENT behaviour — SQLite AUTOINCREMENT and PostgreSQL SERIAL/GENERATED behave differently in edge cases
• NULL semantics — NULL != NULL in both, but aggregate functions and ordering differ subtly
• Full-text search — SQLite FTS and PostgreSQL tsvector/tsquery are completely different engines
• JSON operations — SQLite JSON support is limited vs. PostgreSQL's JSONB with GIN indexes
• Concurrent writes — SQLite uses file-level locking; PostgreSQL uses MVCC — write contention behaves completely differently
Tools for local parity without heavy setup:
• Docker Compose with official Postgres image: docker compose up -d postgres → full PostgreSQL running locally in seconds
• LocalStack for AWS services (DynamoDB, SQS, S3) — match production backing services locally
Key vocabulary:
• Factor X: Dev/Prod Parity — keeping development, staging, and production environments as similar as possible across time, personnel, and backing services
• Backing service gap — the specific parity failure of using a different service implementation (e.g., different database engine or message broker) in development vs. production
• MVCC (Multi-Version Concurrency Control) — PostgreSQL's concurrency model; enables non-blocking reads without the file-level locks SQLite uses
5 / 26
Factor XI: Logs — The logging guidelines state: "The app writes all log output to stdout and stderr, unbuffered. It never opens log files or manages log rotation. The execution environment is responsible for capturing and routing the log stream."
Which 12-Factor principle is this, and what operational benefit does treating logs as event streams provide?
Factor XI separates the concern of log production (the app writes to stdout) from log routing and storage (the platform decides where logs go).
Why applications should not manage their own log files:
Problem with file-based logging
How stdout-based logging solves it
Disk fills up
No disk usage — log stream is consumed by the runtime and forwarded
Log rotation complexity
Not the app's problem; rotation is handled by the log aggregation infrastructure
Log location differs per environment
Same code everywhere; platform routes stdout to whatever backend is configured
Switching log aggregator
Change the Fluentd/Fluent Bit config, not the application code or its dependencies
Container ephemeral filesystem
Logs written to container filesystem are lost when the pod restarts — stdout is captured before that
How the log pipeline works in Kubernetes:
App → writes to stdout
→ container runtime (containerd) captures stdout
→ writes to /var/log/containers/<pod>.log on the node
→ Fluent Bit DaemonSet reads the file
→ parses, enriches (adds pod name, namespace, labels)
→ forwards to Elasticsearch / CloudWatch / Datadog / Splunk
Log levels and structured logging (related best practice):
Logs should be structured (JSON) rather than unstructured text lines — structured stdout enables the aggregation layer to index fields for efficient querying:
Key vocabulary:
• Factor XI: Logs — 12-Factor principle treating logs as an ordered stream of time-stamped events written to stdout; the app never manages log files
• Log stream — a continuous sequence of log events produced by a running process; consumed by the platform infrastructure
• Log aggregator — infrastructure (Fluentd, Fluent Bit, Logstash) that collects stdout streams from all pods and routes them to a centralised storage backend
• Structured logging — writing logs as JSON or key-value pairs rather than free-form text, enabling efficient querying and alerting in log aggregation systems
6 / 26
Sarah: 'Hey team, I'm deploying a new version of the payment service. I've put all my database connection details – host, port, username, password – directly in the `config.js` file alongside the code. It seems simple enough.'
Mark (Code Reviewer): 'Sarah, I have some concerns about this approach. Can you explain why you're storing sensitive configuration data like database credentials within your application's codebase?'
This question tests understanding of Factor III (Config). The core principle is that hardcoding configuration values like database credentials directly into your codebase introduces significant security risks and makes deployments less flexible. Storing sensitive information in environment variables isolates it from the code and allows for easy changes across different environments – a key requirement for cloud-native applications. Options A, C, and D all represent misunderstandings of this fundamental 12-Factor guideline.
7 / 26
Liam (a backend developer) sends the following PR description to his team:
"Just finished implementing the new user authentication flow. I've hardcoded the API key for our third-party identity provider directly into the application's `auth.js` file. It makes testing much easier – no need to set environment variables."
This question tests understanding of Factor V – Secrets Management. While hardcoding API keys might seem convenient during development, it fundamentally violates the 12-Factor methodology. The core principle is to avoid storing secrets within codebases; this creates significant security risks and operational challenges when deploying to different environments. Options B and C misinterpret the purpose of reducing complexity - the goal isn't simply speed but also security and maintainability.
8 / 26
Alex is writing a Slack message to announce the deployment of a new microservice. He writes: 'Deploying v2.0! All API keys are now directly in the code – makes it super easy to test.'
Mark, another developer on the team, replies: 'That's not ideal, Alex. We need to ensure our services adhere to 12-Factor principles. Why is hardcoding sensitive information like API keys a problem?'
This scenario directly addresses Factor III – Config. The 12-Factor methodology emphasizes separating configuration from code for security and maintainability. Hardcoding API keys introduces several problems: it creates duplicate copies of sensitive data, making it vulnerable to exposure if committed to a repository, and makes rolling back changes or updating keys more complex. Environment variables provide a centralized, secure, and easily configurable way to manage secrets across different environments – this is the core principle behind Factor III.
9 / 26
Mark is reviewing a PR submitted by David for a new feature in their e-commerce platform. David has hardcoded the URL of their third-party payment gateway into the `PaymentService.java` file. Here's the review comment:
'David, this looks great! However, I'm concerned about storing sensitive information like API keys directly within your code. This violates several key 12-Factor principles and introduces significant security risks – particularly around potential exposure in source control repositories or compromised environments. Could you explore using environment variables to manage these configurations instead?'
Which of the following best represents the primary concern Mark is raising, as related to the 12-Factor methodology?
Mark's concern directly addresses Factor V: Disposability. Hardcoding API keys into the codebase makes the service less portable and more vulnerable to security breaches. 12-Factor emphasizes configuration separation to minimize risk and improve deployability; storing sensitive information within code actively undermines these principles by increasing the potential for exposure during development, deployment, and operations. The correct option highlights this critical deviation.
10 / 26
Sarah: 'Hey team, I'm deploying a new version of the payment service. I've put all my database connection details – host, port, username, password – directly in the `config.js` file alongside the code. It seems simple enough.'
Mark (Code Reviewer): 'Sarah, I have some concerns about this approach. Can you explain why you're storing sensitive configuration data like database credentials within your application's codebase?'
This question tests understanding of Factor III (Config). The core principle is that hardcoding configuration values like database credentials directly into your codebase introduces significant security risks and makes deployments less flexible. Storing sensitive information in environment variables isolates it from the code and allows for easy changes across different environments – a key requirement for cloud-native applications. Options A, C, and D all represent misunderstandings of this fundamental 12-Factor guideline.
11 / 26
Liam (a backend developer) sends the following PR description to his team:
"Just finished implementing the new user authentication flow. I've hardcoded the API key for our third-party identity provider directly into the application's `auth.js` file. It makes testing much easier – no need to set environment variables."
This question tests understanding of Factor V – Secrets Management. While hardcoding API keys might seem convenient during development, it fundamentally violates the 12-Factor methodology. The core principle is to avoid storing secrets within codebases; this creates significant security risks and operational challenges when deploying to different environments. Options B and C misinterpret the purpose of reducing complexity - the goal isn't simply speed but also security and maintainability.
12 / 26
Alex is writing a Slack message to announce the deployment of a new microservice. He writes: 'Deploying v2.0! All API keys are now directly in the code – makes it super easy to test.'
Mark, another developer on the team, replies: 'That's not ideal, Alex. We need to ensure our services adhere to 12-Factor principles. Why is hardcoding sensitive information like API keys a problem?'
This scenario directly addresses Factor III – Config. The 12-Factor methodology emphasizes separating configuration from code for security and maintainability. Hardcoding API keys introduces several problems: it creates duplicate copies of sensitive data, making it vulnerable to exposure if committed to a repository, and makes rolling back changes or updating keys more complex. Environment variables provide a centralized, secure, and easily configurable way to manage secrets across different environments – this is the core principle behind Factor III.
13 / 26
Mark is reviewing a PR submitted by David for a new feature in their e-commerce platform. David has hardcoded the URL of their third-party payment gateway into the `PaymentService.java` file. Here's the review comment:
'David, this looks great! However, I'm concerned about storing sensitive information like API keys directly within your code. This violates several key 12-Factor principles and introduces significant security risks – particularly around potential exposure in source control repositories or compromised environments. Could you explore using environment variables to manage these configurations instead?'
Which of the following best represents the primary concern Mark is raising, as related to the 12-Factor methodology?
Mark's concern directly addresses Factor V: Disposability. Hardcoding API keys into the codebase makes the service less portable and more vulnerable to security breaches. 12-Factor emphasizes configuration separation to minimize risk and improve deployability; storing sensitive information within code actively undermines these principles by increasing the potential for exposure during development, deployment, and operations. The correct option highlights this critical deviation.
14 / 26
Sarah: 'Hey team, I'm deploying a new version of the payment service. I've put all my database connection details – host, port, username, password – directly in the `config.js` file alongside the code. It seems simple enough.'
Mark (Code Reviewer): 'Sarah, I have some concerns about this approach. Can you explain why you're storing sensitive configuration data like database credentials within your application's codebase?'
This question tests understanding of Factor III (Config). The core principle is that hardcoding configuration values like database credentials directly into your codebase introduces significant security risks and makes deployments less flexible. Storing sensitive information in environment variables isolates it from the code and allows for easy changes across different environments – a key requirement for cloud-native applications. Options A, C, and D all represent misunderstandings of this fundamental 12-Factor guideline.
15 / 26
Liam (a backend developer) sends the following PR description to his team:
"Just finished implementing the new user authentication flow. I've hardcoded the API key for our third-party identity provider directly into the application's `auth.js` file. It makes testing much easier – no need to set environment variables."
This question tests understanding of Factor V – Secrets Management. While hardcoding API keys might seem convenient during development, it fundamentally violates the 12-Factor methodology. The core principle is to avoid storing secrets within codebases; this creates significant security risks and operational challenges when deploying to different environments. Options B and C misinterpret the purpose of reducing complexity - the goal isn't simply speed but also security and maintainability.
16 / 26
Alex is writing a Slack message to announce the deployment of a new microservice. He writes: 'Deploying v2.0! All API keys are now directly in the code – makes it super easy to test.'
Mark, another developer on the team, replies: 'That's not ideal, Alex. We need to ensure our services adhere to 12-Factor principles. Why is hardcoding sensitive information like API keys a problem?'
This scenario directly addresses Factor III – Config. The 12-Factor methodology emphasizes separating configuration from code for security and maintainability. Hardcoding API keys introduces several problems: it creates duplicate copies of sensitive data, making it vulnerable to exposure if committed to a repository, and makes rolling back changes or updating keys more complex. Environment variables provide a centralized, secure, and easily configurable way to manage secrets across different environments – this is the core principle behind Factor III.
17 / 26
Mark is reviewing a PR submitted by David for a new feature in their e-commerce platform. David has hardcoded the URL of their third-party payment gateway into the `PaymentService.java` file. Here's the review comment:
'David, this looks great! However, I'm concerned about storing sensitive information like API keys directly within your code. This violates several key 12-Factor principles and introduces significant security risks – particularly around potential exposure in source control repositories or compromised environments. Could you explore using environment variables to manage these configurations instead?'
Which of the following best represents the primary concern Mark is raising, as related to the 12-Factor methodology?
Mark's concern directly addresses Factor V: Disposability. Hardcoding API keys into the codebase makes the service less portable and more vulnerable to security breaches. 12-Factor emphasizes configuration separation to minimize risk and improve deployability; storing sensitive information within code actively undermines these principles by increasing the potential for exposure during development, deployment, and operations. The correct option highlights this critical deviation.
18 / 26
Sarah: 'Hey team, I'm deploying a new version of the payment service. I've put all my database connection details – host, port, username, password – directly in the `config.js` file alongside the code. It seems simple enough.'
Mark (Code Reviewer): 'Sarah, I have some concerns about this approach. Can you explain why you're storing sensitive configuration data like database credentials within your application's codebase?'
This question tests understanding of Factor III (Config). The core principle is that hardcoding configuration values like database credentials directly into your codebase introduces significant security risks and makes deployments less flexible. Storing sensitive information in environment variables isolates it from the code and allows for easy changes across different environments – a key requirement for cloud-native applications. Options A, C, and D all represent misunderstandings of this fundamental 12-Factor guideline.
19 / 26
Liam (a backend developer) sends the following PR description to his team:
"Just finished implementing the new user authentication flow. I've hardcoded the API key for our third-party identity provider directly into the application's `auth.js` file. It makes testing much easier – no need to set environment variables."
This question tests understanding of Factor V – Secrets Management. While hardcoding API keys might seem convenient during development, it fundamentally violates the 12-Factor methodology. The core principle is to avoid storing secrets within codebases; this creates significant security risks and operational challenges when deploying to different environments. Options B and C misinterpret the purpose of reducing complexity - the goal isn't simply speed but also security and maintainability.
20 / 26
Alex is writing a Slack message to announce the deployment of a new microservice. He writes: 'Deploying v2.0! All API keys are now directly in the code – makes it super easy to test.'
Mark, another developer on the team, replies: 'That's not ideal, Alex. We need to ensure our services adhere to 12-Factor principles. Why is hardcoding sensitive information like API keys a problem?'
This scenario directly addresses Factor III – Config. The 12-Factor methodology emphasizes separating configuration from code for security and maintainability. Hardcoding API keys introduces several problems: it creates duplicate copies of sensitive data, making it vulnerable to exposure if committed to a repository, and makes rolling back changes or updating keys more complex. Environment variables provide a centralized, secure, and easily configurable way to manage secrets across different environments – this is the core principle behind Factor III.
21 / 26
Mark is reviewing a PR submitted by David for a new feature in their e-commerce platform. David has hardcoded the URL of their third-party payment gateway into the `PaymentService.java` file. Here's the review comment:
'David, this looks great! However, I'm concerned about storing sensitive information like API keys directly within your code. This violates several key 12-Factor principles and introduces significant security risks – particularly around potential exposure in source control repositories or compromised environments. Could you explore using environment variables to manage these configurations instead?'
Which of the following best represents the primary concern Mark is raising, as related to the 12-Factor methodology?
Mark's concern directly addresses Factor V: Disposability. Hardcoding API keys into the codebase makes the service less portable and more vulnerable to security breaches. 12-Factor emphasizes configuration separation to minimize risk and improve deployability; storing sensitive information within code actively undermines these principles by increasing the potential for exposure during development, deployment, and operations. The correct option highlights this critical deviation.
22 / 26
During a code review, Emily notices that David's PR includes the base URL of their payment processor directly within the `OrderService.py` file. Mark comments: 'This approach violates the 12-Factor App principle of configuration management. Specifically, hardcoding sensitive data like API keys creates significant security risks and makes deployments more complex.' What does Mark *primarily* mean in this context?
Mark is highlighting the core issue of 12-Factor: sensitive data should *never* be directly embedded in code. This creates a major security vulnerability if the code is exposed or compromised. Furthermore, it makes deployments harder because changes to API keys require modifying and redeploying the application – a clear violation of the principle of immutable infrastructure. Option A is irrelevant; B is incorrect; and C is a reasonable consequence of failing this important principle.
23 / 26
Alex sends out a Slack message to announce the deployment of a new version of their service: 'New v3.2 deployed! All database credentials are now in the code – super convenient for testing.' Which 12-Factor principle does this statement *most* directly contradict?
Alex's message exemplifies the problem of embedding configuration data – particularly database credentials – directly into code. The 'Configuralization' principle dictates that configuration should be externalized and managed separately. Hardcoding credentials creates significant security risks and operational challenges, making it a direct violation of this critical 12-Factor guideline. Options A, B, and C are unrelated to the core issue of sensitive data management.
24 / 26
In a standup meeting, Liam says: 'I've put all my API keys for our external service into the `environment.yaml` file alongside the code. It's really easy to manage.' Considering the 12-Factor App approach, what is Liam *likely* overlooking?
While putting API keys in an `environment.yaml` file is *better* than hardcoding them, it's not sufficient for a truly 12-Factor compliant application. The principle mandates using a dedicated secrets management solution (like HashiCorp Vault or AWS Secrets Manager) to securely store and rotate sensitive credentials – something Liam's approach doesn't address. Options A, B, and C are related but secondary to the fundamental requirement of externalized secrets.
25 / 26
David is submitting a PR for a new feature in their application. He includes the URL of their third-party payment gateway directly within the `PaymentService.java` file. What's the *primary* concern raised by a 12-Factor App perspective?
While David's action *does* raise a significant security concern – hardcoding sensitive information like API keys directly into code creates vulnerabilities – the core issue highlighted by the 12-Factor principle is that it introduces operational complexity. This makes deployments more difficult and increases the risk of errors when configuration changes are required. Option A is irrelevant; B accurately represents the fundamental problem, and C focuses on a specific vulnerability rather than the broader principle.
26 / 26
Sarah deployed a new version of her payment service by placing all database connection details – host, port, username, password – directly in the `config.js` file alongside the code. A senior developer observes this and says: 'This is problematic from a 12-Factor perspective.' What's the most important reason for their concern?
The core issue here is that Sarah has violated the 'Configuralization' principle by embedding sensitive configuration data directly into her code. This exposes the database credentials to potential exposure and makes it extremely difficult to manage these values securely or rotate them without redeploying the application – a key requirement of 12-Factor deployments.
What will I practice in "12-Factor App Vocabulary — Cloud-Native Language Exercises"?
This is a Cloud-Native exercise set. It walks through 26 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 26 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.