- 0-2 years experience. - Roles: Junior DevSecOps Engineer, Associate Security Engineer, DevOps Engineer (Security Focus). - 28 checklist questions, 18 real interview Q&A, 5 scenarios, 8 behavioral questions. - Companies: Swiggy, Razorpay, Zerodha, Hotstar, Flipkart.
You have set up a pipeline in a college project or a bootcamp assignment. You know what a container is. You have probably run `kubectl get pods` at some point and felt good about it. That is enough to walk in the door. It is not enough to get the offer. Junior DevSecOps interviews are not testing whether you can design a zero-trust network or pick between active-active and active-passive regions. They are testing something narrower and more honest: do you understand what security actually means at each stage of building and shipping software, can you read and reason about a pipeline, and will you ask for help instead of guessing when you genuinely do not know something. Three things separate junior candidates who get the offer from equally-skilled peers who do not. They use real terms correctly instead of vaguely waving at "security stuff" - saying "SAST scans the source code before anything runs, DAST attacks the running application" instead of "static and dynamic testing, you know, for security." They show curiosity about the *why*, not just the *what* - explaining why catching a bug early is cheaper instead of just repeating the phrase "shift-left." And they are honest about the edges of their knowledge - "I have not used Vault in a real production system, but I understand the pattern and I have used Kubernetes Secrets" lands far better than bluffing through a follow-up question. This module has four parts, numbered so you always know exactly where you are. **Tier 1 - Junior Fundamentals Checklist (no answers)** 28 questions across 5 categories: DevSecOps core concepts, CI/CD pipeline security, container and Kubernetes basics, cloud security fundamentals, and tools and scripting. These are table stakes for any junior screen. If several of these stump you, spend time with the underlying concept before moving to Tier 2. **Tier 2 - Real Interview Questions (Q1 to Q18)** 18 questions asked at junior DevSecOps and security-aware DevOps screens at companies like Swiggy, Razorpay, and Hotstar. Every answer includes the plain-English explanation, a real example, and code where it helps. **Tier 3 - Scenario Round (Q19 to Q23)** 5 short, practical scenarios. There is no single correct answer here - the interviewer wants to see how you reason when the situation is not a textbook question. **Behavioral Round (Q24 to Q31)** 8 behavioral questions that test attitude, learning speed, and ownership - the things that matter most when a team is deciding whether to take a chance on a junior hire.
These are table stakes. If you need to look several of these up, that is fine - just do it before Tier 2. ### DevSecOps Core Concepts * What is DevSecOps and how is it different from DevOps? * What does "shift-left" mean, and why does it reduce cost? * What are the three pillars of DevSecOps - people, process, technology? * What is the CIA triad (confidentiality, integrity, availability)? * What is the difference between a vulnerability and an exploit? * What is the principle of least privilege? ### CI/CD Pipeline Security Basics * What is SAST, and at what stage of the pipeline does it run? * What is DAST, and how is it different from SAST? * What is SCA, and why does it matter for open source dependencies? * What is a security gate in a pipeline? * Name two tools used for static code analysis. * What can go wrong if you skip security scanning before a deployment? ### Container and Kubernetes Basics * What is a container image, and how is it different from a running container? * Why should containers avoid running as the root user? * What does `kubectl get pods` actually show you? * What is a Kubernetes namespace used for? * What is the difference between a Deployment and a Pod? * What is image scanning, and at what point should it run? ### Cloud Security Fundamentals * What is IAM, and what does least privilege mean in an IAM context? * What is the difference between encryption at rest and encryption in transit? * What is a security group in AWS, in plain terms? * What causes an S3 bucket to become publicly exposed, and how do you prevent it? * What does the "shared responsibility model" mean in cloud security? ### Tools and Scripting * Name three CI/CD platforms you have heard of or used. * What is Git branch protection, and why does it matter for security? * Can you write a basic bash script that loops through a list of files? * What is a secrets manager, and why is hardcoding credentials a bad idea?
### Core DevSecOps Concepts **Q1. What is DevSecOps, and how is it different from DevOps?** Think of building software like building a house. DevOps is making sure the construction crew and the people who maintain the house later work from the same blueprint and the same timeline, so the house gets built faster without arguments between teams. **DevSecOps** adds the safety inspector to that same crew from day one, instead of inspecting the house only after it is built and ready to hand over the keys. DevOps focuses on shipping software fast and reliably by breaking down the wall between development and operations. DevSecOps keeps that same speed but adds a continuous, mostly automated layer of security checks at every stage - when code is written, when it is built, when it is tested, and when it runs in production. The shift is cultural as much as technical. Security stops being "someone else's job" that happens right before launch and becomes a shared responsibility across developers, operations, and security engineers. > 💡 Green Flag: the candidate explains the cultural shift, not just a list of tool names. > 🔴 Red Flag: the candidate says "DevSecOps is just DevOps with a security team added on." **Q2. What does shift-left security mean, and why does it matter?** "Shift-left" means moving security checks earlier in the development timeline - ideally into the code editor and the commit stage, rather than waiting for a security review right before release. Picture a timeline with development on the left and production on the right. Traditional security review sits all the way on the right, just before launch. Shift-left drags those checks toward the left side of that timeline. The reason this matters is mostly economic. A bug caught while a developer is still writing the code costs a few minutes to fix. The same bug caught during a pre-release security review might require re-testing, a delayed release, and a frustrated team. The same bug found by an attacker in production can mean an incident, a postmortem, and real damage to user trust. The earlier you catch it, the cheaper and calmer the fix. > **Note:** "Shift-left" does not mean removing checks later in the pipeline. It means adding earlier checks in addition to the later ones, so problems are caught at the cheapest possible point. **Q3. What is SAST, and how is it different from DAST?** **SAST** (Static Application Security Testing) is like proofreading a recipe before you cook anything - it reads your source code line by line and flags risky patterns, like a database query built by joining strings together instead of using safe parameters. It runs without ever executing the application. **DAST** (Dynamic Application Security Testing) is like tasting the food while it is cooking - it tests the actual running application from the outside, the way an attacker would, by sending it real requests and watching how it responds. DAST cannot see your source code at all; it only sees what the application exposes over the network. ```yaml ## Example: adding a SAST stage to a GitHub Actions pipeline - name: Run SAST scan uses: sonarsource/sonarqube-scan-action@v2 with: args: > -Dsonar.projectKey=checkout-service -Dsonar.qualitygate.wait=true ``` > **Note:** `sonar.qualitygate.wait=true` means the pipeline pauses and waits for SonarQube's quality gate result before continuing. If the gate fails, the build fails too. Common SAST tools: SonarQube, Checkmarx. Common DAST tools: OWASP ZAP, Burp Suite. A mature pipeline runs both, because they catch different categories of problems. **Q4. What is SCA (Software Composition Analysis), and why does it matter for open source dependencies?** Most applications are built on top of dozens or hundreds of open source libraries. **SCA** scans those dependencies - not the code you wrote, but the code you imported - and checks them against databases of known vulnerabilities (CVEs). A famous real-world example is the Log4j vulnerability discovered in 2021, which affected huge numbers of applications that did not even call the vulnerable library directly - it was buried several layers deep as a dependency of a dependency. ```bash ## Example: scanning a Node.js project with Snyk snyk test --severity-threshold=high ## Fails the command (and the pipeline step) if any ## high or critical severity vulnerability is found ``` SCA matters because you are responsible for the security of code you did not write, the moment you `npm install` or `pip install` it into your project. ### CI/CD Pipeline Security **Q5. How would you add basic security scanning to an existing CI/CD pipeline that has none?** Start small and add checks in order of cost versus value, not all at once. A reasonable first pass for a pipeline with zero security tooling looks like this: Commit -> Secrets scan -> Build -> SAST -> SCA -> Container scan -> Deploy ```yaml ## Simplified GitHub Actions pipeline with security stages added jobs: security-checks: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Scan for committed secrets uses: gitleaks/gitleaks-action@v2 - name: Static code analysis run: sonar-scanner - name: Dependency vulnerability scan run: snyk test --severity-threshold=high - name: Container image scan run: trivy image checkout-service:latest ``` > **Note:** Each step here runs in order, and a failure in any step can be configured to stop the pipeline before the bad code reaches production. Start by only blocking on critical and high severity findings - blocking on everything from day one usually buries the team in noise. **Q6. What is a secrets scanner, and why would you add one as a pre-commit hook?** A secrets scanner looks for things that look like API keys, passwords, or tokens inside your code before it gets committed - patterns like long random strings next to words like `key`, `secret`, or `password`. Adding it as a **pre-commit hook** means it runs on the developer's own machine before the commit is even created, so the secret never reaches the shared repository in the first place. ```bash ## Example: installing a gitleaks pre-commit hook pip install pre-commit echo "repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.18.0 hooks: - id: gitleaks" > .pre-commit-config.yaml pre-commit install ``` > 📌 Remember: catching a secret before it is committed is far cheaper than catching it after, because once something is pushed to a shared Git history, you have to assume it is compromised and rotate it - deleting the commit later does not undo the exposure. **Q7. What is the difference between a security gate that blocks a build and one that just warns?** A **blocking gate** stops the pipeline entirely - the code cannot move forward until the issue is fixed. A **warning gate** lets the pipeline continue but flags the issue for later review, usually by creating a ticket. Most teams use severity to decide which is which: critical and high severity findings block the build, medium and low severity findings create a ticket for the backlog. This balance matters because blocking on every single finding, including low-risk ones, trains developers to find ways around the pipeline rather than fix the actual problem. ### Container and Kubernetes Basics **Q8. How do you secure a Docker container? Walk me through the basics.** Four habits cover most of what a junior engineer is expected to know here: use a minimal base image, never run as root, scan the final image, and keep secrets out of the image entirely. ```dockerfile ## Before: common beginner mistakes FROM ubuntu:latest COPY . /app CMD ["python3", "app.py"] ## Runs as root, uses a large base image, no scanning ## After: hardened version FROM python:3.12-slim RUN useradd --create-home appuser WORKDIR /app COPY --chown=appuser:appuser . . USER appuser CMD ["python3", "app.py"] ``` > **Note:** `python:3.12-slim` is much smaller than a full `ubuntu` image, which means fewer installed packages and a smaller attack surface. `USER appuser` ensures the process inside the container does not run as root, so a container breakout has far less power on the host. **Q9. What is image scanning, and what tool would you use?** Image scanning checks a built container image for known vulnerabilities in its operating system packages and installed libraries, similar to SCA but for the whole image rather than just your application's dependencies. Trivy is a common, free tool for this. ```bash ## Scan a built image before pushing it to a registry trivy image checkout-service:1.4.0 ## Fail the pipeline only on critical findings trivy image --exit-code 1 --severity CRITICAL checkout-service:1.4.0 ``` Run image scanning right after the image is built, before it is pushed to a registry that other services might pull from. **Q10. What is RBAC in Kubernetes, in simple terms?** **RBAC** (Role-Based Access Control) is like a keycard system in an office building. Not everyone gets a master key - a junior engineer's keycard might open the developer floor but not the server room. In Kubernetes, a Role defines a set of permissions (what actions are allowed on what resources), and a RoleBinding hands that Role to a specific user or service account. ```yaml ## A Role that can only read pod information, ## scoped to a single namespace apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: staging rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] ``` > 🔴 Common Mistake: granting `cluster-admin` to a new engineer or a CI pipeline "just to get things working" and never narrowing it down afterward. Start narrow and expand only when a real, specific need shows up. ### Cloud and Secrets Basics **Q11. How do you avoid hardcoding secrets in your code or pipeline?** Never put a real password, API key, or token directly in source code or in plain environment variable values inside a YAML file. Instead, store secrets in a dedicated secrets manager or in Kubernetes Secrets, and have the application or pipeline fetch them at runtime. ```yaml ## Bad: hardcoded secret visible to anyone with repo access env: DB_PASSWORD: "Sup3rSecret123" ## Better: reference a Kubernetes Secret instead env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-credentials key: password ``` For production systems, many teams go a step further and use a dedicated secrets manager like AWS Secrets Manager or HashiCorp Vault, which adds automatic rotation and detailed access logging on top of what plain Kubernetes Secrets offer. **Q12. What is the principle of least privilege, and how would you apply it to an IAM role for a CI/CD pipeline?** Least privilege means giving an identity - a person, a service, or a pipeline - only the exact permissions it needs to do its job, and nothing more. A CI/CD pipeline that only needs to push a new container image and update one specific deployment should not have full administrator access to your AWS account. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:GetAuthorizationToken", "ecr:PutImage" ], "Resource": "arn:aws:ecr:ap-south-1:111122223333:repository/checkout-service" } ] } ``` This policy lets the pipeline push images to exactly one ECR repository - nothing else. If the pipeline's credentials are ever leaked, the damage is contained. **Q13. What is encryption at rest versus encryption in transit? Give an example of each.** **Encryption at rest** protects data while it is stored - on a disk, in a database, in a backup file. If someone steals the physical hard drive or an unauthorized snapshot of a database, the data is still unreadable without the key. An example is an encrypted AWS EBS volume attached to an EC2 instance. **Encryption in transit** protects data while it is moving between two points - between a user's browser and your server, or between two internal services. An example is HTTPS (TLS), which protects an API call from being read or modified as it travels across the network. > 📌 Remember: both matter together. Encrypting data at rest does nothing to protect it while it is being sent over the network, and vice versa. ### Practical Mini-Scenarios **Q14. A vulnerability scanner flags a critical CVE in one of your dependencies. What do you do first?** Confirm before you panic, then act quickly. Check whether your application actually calls the vulnerable code path - sometimes a library is flagged for a function your code never uses, which lowers the real risk. Check if a patched version is already available; if so, upgrading is usually the fastest fix. If no patch exists yet, look for a temporary mitigation (disabling a specific feature, adding a web application firewall rule) and escalate to a senior engineer or your security team so the risk is tracked and not forgotten. **Q15. You notice an API key committed to a public GitHub repository. What is your immediate action?** Rotate the key first, investigate second. The moment a secret is visible in a public repository, you have to assume it is compromised - it may already have been scraped by an automated bot, regardless of how long it has been there. Generate a new key, update every system that uses it, and only after the immediate exposure is closed do you investigate how it got there and remove it from the Git history. Notify your team or security lead so they are aware, even if you already fixed it. > ⚠️ Security: do not wait to "confirm if it was actually used maliciously" before rotating. The cost of rotating an unused key is minutes. The cost of an attacker using a live key before you rotate it can be enormous. **Q16. What is a threat model, in simple terms, and why would a junior engineer be asked to think about it?** A threat model is a structured way of asking "what could go wrong here, and who would want to make it go wrong." For a simple login page, a basic threat model might ask: can someone guess passwords by trying many at once (brute force)? Can someone intercept the password while it travels over the network (man-in-the-middle)? Can someone see another user's data by changing a number in the URL (broken access control)? Junior engineers get asked about this because thinking in terms of "what could an attacker do here" is a habit, not a senior-only skill. Interviewers want to see that habit starting early, even if the answers are simple. **Q17. What is the difference between a vulnerability scan and a penetration test?** A **vulnerability scan** is automated - a tool checks your systems against a database of known issues and produces a report, usually in minutes to hours. A **penetration test** is performed by a human, often an external ethical hacker, who actively tries to break into your systems the way a real attacker would, chaining together small issues that an automated scanner would miss on its own. Vulnerability scans are cheap and can run continuously. Penetration tests are expensive, usually done a few times a year, and go much deeper. **Q18. How do you stay updated on new vulnerabilities and security practices as a junior engineer?** A simple, honest routine: follow a CVE feed or a security newsletter (The Hacker News and similar sources cover major incidents in accessible language), read the release notes of the tools your team uses, and spend a little time in hands-on labs - platforms like TryHackMe or OWASP's own vulnerable applications - to build muscle memory rather than just reading theory. Most interviewers are not looking for an exhaustive list of resources; they are looking for evidence that you actually do something consistently, even if it is small.
### Q19. Scenario - The Pipeline With No Security At All You join a 3-month-old startup. Their CI/CD pipeline builds and deploys straight to production with zero security scanning. You have one sprint, two weeks, to make the single biggest improvement. What do you add first, and why? Secrets scanning, first, before anything else. It is the cheapest control to add - usually a single pre-commit hook or pipeline step - and it protects against the single most catastrophic and embarrassing failure mode: a real credential ending up in a public or widely-shared repository. After that, dependency scanning (SCA) is the next highest-value addition, since most applications carry known vulnerabilities in their dependencies without anyone realizing it. Resist the urge to add five tools at once in week one - a team that gets overwhelmed by new tooling will quietly start ignoring all of it. ### Q20. Scenario - The False Positive Flood Your team just turned on a SAST tool, and it immediately flags 200 issues in the existing codebase, blocking every single pull request. The team is frustrated and wants to disable the tool entirely. What do you do? Do not block on the existing 200 issues immediately - that punishes the team for code that has been running safely for months and creates an incentive to just turn the tool off. Instead, baseline the current findings (mark them as accepted-for-now), configure the gate to only block on *new* issues introduced in new code, and work through the existing backlog gradually, prioritized by severity. This keeps the tool's value (catching new problems) without making it the villain that stops all progress on day one. ### Q21. Scenario - The Hardcoded Password While onboarding, you find a hardcoded database password sitting in a config file that has been in the repository for 8 months. What do you do? Treat it exactly like a freshly leaked secret, regardless of its age - rotate the password immediately, update every system that depends on it, and only then investigate how long it has been there and who has had access. Report it to your lead or security contact as soon as you find it; do not sit on it while you quietly try to "clean it up" yourself first, and do not turn it into a blame conversation about whoever originally committed it. Old does not mean safe - if anything, an 8-month-old exposed secret has had 8 months for someone to find it. ### Q22. Scenario - Explaining Security to a Non-Technical Stakeholder A product manager asks, "why does adding this scanning step slow our releases down by 10 minutes? Can we just skip it for this one release?" How do you respond? Translate the risk into terms they care about instead of just repeating the technical justification. Something like: "this check is what would have caught the kind of bug that led to [a well-known public breach the PM has likely heard of] - 10 minutes now versus a multi-day incident and a public apology later is the trade we're making." Then offer a real compromise instead of a flat no: scans can often run in parallel with other pipeline steps rather than adding to the total time sequentially, and for a single release under real time pressure, you could agree to run the scan but only hard-block on critical findings rather than every finding. ### Q23. Scenario - Competing Priorities You are asked to fix a low-severity bug today and also start a security review for a new feature launching next week. You only have time for one today. How do you decide? Weigh urgency against impact rather than just doing whichever was asked most recently or most loudly. A low-severity bug, by definition, can usually wait a day or two without real consequence. A security review for a feature launching in a week has a hard deadline that gets harder to meet the longer it is delayed - starting it late often means rushing it, which is exactly how security reviews miss things. If the priority genuinely is not clear from the two requests alone, the honest move is to ask your lead directly rather than silently guessing and hoping you picked right.
**Q24. Tell me about a time you learned a new tool or technology quickly.** *Strong Answer Framework:* Pick a specific tool, not "I'm a fast learner" in the abstract. Describe the actual situation that forced the learning, what you did in the first few hours versus the first few days, and where you ended up. A genuine example: "For a college project I had never touched Docker before. I spent the first evening just running the official tutorial end to end, then spent the next two days actually breaking my own container on purpose - removing the WORKDIR, forgetting EXPOSE - so I understood what each line actually did instead of just copying examples. By the end of the week I could write a working Dockerfile from a blank file." **Q25. Tell me about a time you found and reported a bug or issue.** *Strong Answer Framework:* Describe what you noticed, how you confirmed it was real before raising it, and how you communicated it. Interviewers are listening for whether you reported it constructively rather than just complaining, and whether you checked your own understanding first rather than crying wolf on something that turned out to be expected behavior. **Q26. How do you handle being told your code or configuration has a security issue?** *Strong Answer Framework:* This question is testing ego, not skill. The strongest answers treat the feedback as the system working correctly - someone caught something before it reached production, which is the entire point of a review process. Avoid any framing that sounds defensive ("well, it technically wasn't wrong") and instead show that you understood the *why* behind the fix, not just applied the suggested change blindly. **Q27. Why do you want to work in DevSecOps specifically?** *Strong Answer Framework:* Generic answers ("I like technology and security sounds interesting") are forgettable. A better answer connects a specific moment of curiosity to the role - reading about a real breach and wanting to understand how it could have been prevented, or enjoying the part of a project where you got a pipeline to actually fail safely on a bad change. Show that you understand DevSecOps is the intersection of build-and-ship speed and security, not security in isolation. **Q28. Describe how you would prioritize tasks when given multiple things at once with no clear order.** *Strong Answer Framework:* Give an actual framework, even a simple one - urgency versus impact, or "what breaks if this waits a day." Then say what you do when the framework genuinely does not resolve the tie: ask. Interviewers are wary of junior candidates who either freeze under ambiguity or silently guess and hope. **Q29. Tell me about a project where you had to work with limited guidance or documentation.** *Strong Answer Framework:* Walk through how you filled the gap - reading source code instead of docs, asking a specific narrow question instead of a vague "I'm stuck," or building a small test to confirm your assumption before committing to it. The signal here is resourcefulness, not whether you eventually got it perfectly right. **Q30. How do you handle making a mistake in front of your team?** *Strong Answer Framework:* Own it plainly, explain what you did to fix or contain it, and mention one concrete thing you changed afterward so it does not repeat. Avoid minimizing language ("it wasn't really a big deal") - interviewers read that as an inability to take ownership, which is a worse signal than the mistake itself. **Q31. What do you do when you do not know the answer to a question, in an interview or at work?** *Strong Answer Framework:* Say so directly, then show how you would find out. "I haven't worked with Vault directly, but based on what I know about secrets managers in general, I'd expect it to handle dynamic credential generation - I'd want to confirm that by checking the docs." This is almost always a better answer than guessing and hoping it lands, because interviewers can tell the difference and respect the honesty.
| Tool | What It Checks | |:-----|:----------------| | `gitleaks` / `trufflehog` | Secrets accidentally committed to Git | | SonarQube / Checkmarx (SAST) | Risky patterns in your own source code | | OWASP ZAP (DAST) | Vulnerabilities in the running application | | Snyk / OWASP Dependency-Check | Known CVEs in third-party libraries | | Trivy | Vulnerabilities inside a built container image | ### Common Mistakes New DevSecOps candidates often treat security tools as a checklist to memorize rather than a set of habits to understand, which falls apart the moment an interviewer asks a one-level-deeper follow-up question; the fix is to always be able to explain *why* a tool exists, not just its name. Another common mistake is confusing SAST and DAST under interview pressure, mixing up which one reads code and which one attacks a running app - the recipe-versus-tasting analogy is worth keeping in your back pocket exactly because it is hard to forget. Many junior candidates also assume a hardcoded secret is "probably fine" if the repository is private, when the real fix is to treat private and public repositories the same way once a secret is committed, since access can change and history can leak. A related mistake is over-explaining a security concept to a non-technical interviewer using only jargon, which signals you cannot communicate outside your own team - practising a plain-English version of your favorite three concepts goes a long way. Some candidates also try to claim deep production experience they do not have, which usually unravels under a single specific follow-up question; being precise about what you have actually done, even if it is project-scale rather than production-scale, builds far more trust. Underestimating behavioral questions is another frequent gap - junior candidates often prepare only the technical half and then freeze on "tell me about a time," when a little structure (situation, action, result) makes these easy to answer well. Finally, many candidates do not ask any questions back at the end of the interview, which reads as low curiosity for a field that genuinely rewards curiosity - even one good question about how the team handles vulnerability triage shows you have been listening.
You have set up a pipeline in a college project or a bootcamp assignment. You know what a container is. You have probabl...
These are table stakes. If you need to look several of these up, that is fine - just do it before Tier 2. DevSecOps Core...
Core DevSecOps Concepts Q1. What is DevSecOps, and how is it different from DevOps? Think of building software like buil...
Q19. Scenario - The Pipeline With No Security At All You join a 3-month-old startup. Their CI/CD pipeline builds and dep...
Q24. Tell me about a time you learned a new tool or technology quickly. Strong Answer Framework: Pick a specific tool, n...
Tool What It Checks gitleaks / trufflehog Secrets accidentally committed to Git SonarQube / Checkmarx (SAST) Risky patte...
Junior DevSecOps Engineer (0-2 years) Company Type Range Service company Rs 4L - Rs 7L Mid-size product startup Rs 6L - ...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.