(function() {
  var extra = [
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "Your organization wants one shared project for reporting, but each product team needs its own backlog and board configuration.",
        "de": "Ihre Organisation möchte ein gemeinsames Projekt für Reporting, aber jedes Produktteam benötigt ein eigenes Backlog und eine eigene Board-Konfiguration."
      },
      "question": {
        "en": "Which Azure Boards configuration should you use so several teams can keep separate backlogs and boards while staying in one Azure DevOps project?",
        "de": "Welche Azure-Boards-Konfiguration sollten Sie verwenden, damit mehrere Teams getrennte Backlogs und Boards behalten können und dennoch in einem Azure-DevOps-Projekt bleiben?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Agent pools",
            "de": "Agent-Pools"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Variable groups",
            "de": "Variablengruppen"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Deployment groups",
            "de": "Bereitstellungsgruppen"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Area paths is correct because they let one project contain team-specific backlogs, boards, and ownership boundaries. It best meets the requirement to keep one project but separate team work views.",
        "de": "Area Paths ist richtig, weil sie ermöglichen teambezogene Backlogs, Boards und Zuständigkeitsgrenzen innerhalb eines Projekts. Damit wird die Anforderung am besten erfüllt, in einem Projekt zu bleiben, aber getrennte Teamsichten zu erhalten."
      },
      "hint": {
        "en": "Focus on the need to keep one project but separate team work views.",
        "de": "Achten Sie auf die Anforderung, in einem Projekt zu bleiben, aber getrennte Teamsichten zu erhalten."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-area-paths?view=azure-devops",
      "id": "az400-107"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "A program manager needs one planning board for issues coming from several repositories and wants fields such as target quarter and customer segment.",
        "de": "Ein Programmmanager benötigt ein gemeinsames Planungsboard für Issues aus mehreren Repositorys und möchte Felder wie Zielquartal und Kundensegment verwenden."
      },
      "question": {
        "en": "Which GitHub feature is best for tracking work across multiple repositories with custom fields and board-style views?",
        "de": "Welche GitHub-Funktion eignet sich am besten, um Arbeit über mehrere Repositorys mit benutzerdefinierten Feldern und Board-Ansichten zu verfolgen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "GitHub Projects",
            "de": "GitHub Projects"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Git tags",
            "de": "Git-Tags"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "GitHub Packages",
            "de": "GitHub Packages"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "GitHub Releases",
            "de": "GitHub Releases"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "GitHub Projects is correct because it supports cross-repository planning, custom fields, workflows, and multiple views. It best meets the requirement to manage cross-repository planning work in one place.",
        "de": "GitHub Projects ist richtig, weil es unterstützt repositoryübergreifende Planung, benutzerdefinierte Felder, Workflows und mehrere Ansichten. Damit wird die Anforderung am besten erfüllt, repositoryübergreifende Planungsarbeit an einem Ort zu verwalten."
      },
      "hint": {
        "en": "Focus on the need to manage cross-repository planning work in one place.",
        "de": "Achten Sie auf die Anforderung, repositoryübergreifende Planungsarbeit an einem Ort zu verwalten."
      },
      "reference": "https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects",
      "id": "az400-108"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure Boards chart helps a team see work-in-progress growth and bottlenecks by workflow state over time?",
        "de": "Welches Azure-Boards-Diagramm hilft einem Team, das Wachstum von Work in Progress und Engpässe nach Workflow-Status im Zeitverlauf zu erkennen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Cumulative flow diagram",
            "de": "Kumulatives Flussdiagramm"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Burndown chart",
            "de": "Burndown-Diagramm"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Velocity chart",
            "de": "Velocity-Diagramm"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Test summary chart",
            "de": "Testzusammenfassungsdiagramm"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The cumulative flow diagram is correct because it visualizes how items accumulate in each state and exposes queue growth. It best meets the requirement to identify bottlenecks in the delivery flow.",
        "de": "Das kumulative Flussdiagramm ist richtig, weil es visualisiert, wie sich Elemente in jedem Status ansammeln und macht wachsende Warteschlangen sichtbar. Damit wird die Anforderung am besten erfüllt, Engpässe im Lieferfluss zu erkennen."
      },
      "hint": {
        "en": "Focus on the need to identify bottlenecks in the delivery flow.",
        "de": "Achten Sie auf die Anforderung, Engpässe im Lieferfluss zu erkennen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/report/dashboards/cumulative-flow?view=azure-devops",
      "id": "az400-109"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "You want engineering documentation versioned with code and editable through pull requests. What should you use in Azure DevOps?",
        "de": "Sie möchten technische Dokumentation zusammen mit dem Code versionieren und über Pull Requests bearbeiten. Was sollten Sie in Azure DevOps verwenden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A code wiki published from a Git repository",
            "de": "Ein aus einem Git-Repository veröffentlichtes Code-Wiki"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A deployment group",
            "de": "Eine Bereitstellungsgruppe"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A classic release pipeline only",
            "de": "Nur eine klassische Release-Pipeline"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A service connection",
            "de": "Eine Serviceverbindung"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A code wiki published from a Git repository is correct because it keeps markdown content under source control and enables normal PR review workflows. It best meets the requirement to store docs next to code with reviewable changes.",
        "de": "Ein aus einem Git-Repository veröffentlichtes Code-Wiki ist richtig, weil es hält Markdown-Inhalte unter Versionskontrolle und ermöglicht normale PR-Review-Workflows. Damit wird die Anforderung am besten erfüllt, Dokumentation neben dem Code mit prüfbaren Änderungen abzulegen."
      },
      "hint": {
        "en": "Focus on the need to store docs next to code with reviewable changes.",
        "de": "Achten Sie auf die Anforderung, Dokumentation neben dem Code mit prüfbaren Änderungen abzulegen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/project/wiki/publish-repo-to-wiki?view=azure-devops",
      "id": "az400-110"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "easy",
      "scenario": {
        "en": "A team sees too much partially finished work piling up in In Progress and Code Review.",
        "de": "Ein Team sieht, dass sich zu viele teilweise fertiggestellte Arbeiten in In Progress und Code Review ansammeln."
      },
      "question": {
        "en": "Which Azure Boards capability should a Kanban team use to stop columns from holding too many active items at once?",
        "de": "Welche Azure-Boards-Funktion sollte ein Kanban-Team verwenden, damit Spalten nicht zu viele aktive Elemente gleichzeitig enthalten?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "WIP limits",
            "de": "WIP-Limits"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Branch policies",
            "de": "Branchrichtlinien"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Release gates",
            "de": "Release-Gates"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Agent capabilities",
            "de": "Agent-Fähigkeiten"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "WIP limits is correct because they highlight when a workflow column exceeds the allowed number of active items. It best meets the requirement to control work-in-progress on the board.",
        "de": "WIP-Limits ist richtig, weil sie zeigen an, wenn eine Workflow-Spalte die zulässige Anzahl aktiver Elemente überschreitet. Damit wird die Anforderung am besten erfüllt, Work in Progress auf dem Board zu steuern."
      },
      "hint": {
        "en": "Focus on the need to control work-in-progress on the board.",
        "de": "Achten Sie auf die Anforderung, Work in Progress auf dem Board zu steuern."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/boards/boards/set-kanban-limits?view=azure-devops",
      "id": "az400-111"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "Auditors ask the team to show which user stories are implemented by each pull request without relying on manual note taking.",
        "de": "Auditoren verlangen vom Team, für jeden Pull Request nachvollziehen zu können, welche User Stories umgesetzt werden, ohne sich auf manuelle Notizen zu verlassen."
      },
      "question": {
        "en": "Which two practices improve traceability between Azure Repos pull requests and Azure Boards work items?",
        "de": "Welche zwei Vorgehensweisen verbessern die Nachverfolgbarkeit zwischen Azure-Repos-Pull-Requests und Azure-Boards-Arbeitselementen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Enable a branch policy that checks for linked work items",
            "de": "Eine Branchrichtlinie aktivieren, die verknüpfte Arbeitselemente prüft"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Use AB# references in branch names, commits, or pull requests",
            "de": "AB#-Verweise in Branchnamen, Commits oder Pull Requests verwenden"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Disable work item linking in pull requests",
            "de": "Die Verknüpfung von Arbeitselementen in Pull Requests deaktivieren"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Track changes only in a spreadsheet",
            "de": "Änderungen nur in einer Tabellenkalkulation nachverfolgen"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Linked work item checks together with AB# references is correct because they enforce and create links from code activity back to planned work. It best meets the requirement to create auditable links between code changes and work items.",
        "de": "Prüfungen auf verknüpfte Arbeitselemente zusammen mit AB#-Verweisen ist richtig, weil sie erzwingen und erzeugen Verknüpfungen von Codeaktivitäten zurück zur geplanten Arbeit. Damit wird die Anforderung am besten erfüllt, prüfbare Verknüpfungen zwischen Codeänderungen und Arbeitselementen zu schaffen."
      },
      "hint": {
        "en": "Focus on the need to create auditable links between code changes and work items.",
        "de": "Achten Sie auf die Anforderung, prüfbare Verknüpfungen zwischen Codeänderungen und Arbeitselementen zu schaffen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#check-for-linked-work-items",
      "id": "az400-112"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which GitHub feature is best for long-form community Q&A that is not yet a bug or task?",
        "de": "Welche GitHub-Funktion eignet sich am besten für ausführliche Community-Fragen und Antworten, die noch kein Bug oder Task sind?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "GitHub Discussions",
            "de": "GitHub Discussions"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "GitHub Actions",
            "de": "GitHub Actions"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "GitHub Packages",
            "de": "GitHub Packages"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "GitHub Codespaces",
            "de": "GitHub Codespaces"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "GitHub Discussions is correct because it separates exploratory conversations and community feedback from actionable issues. It best meets the requirement to collect design questions and community conversations.",
        "de": "GitHub Discussions ist richtig, weil es trennt explorative Gespräche und Community-Feedback von umsetzbaren Issues. Damit wird die Anforderung am besten erfüllt, Designfragen und Community-Gespräche zu sammeln."
      },
      "hint": {
        "en": "Focus on the need to collect design questions and community conversations.",
        "de": "Achten Sie auf die Anforderung, Designfragen und Community-Gespräche zu sammeln."
      },
      "reference": "https://docs.github.com/en/discussions/collaborating-with-your-community-using-discussions/about-discussions",
      "id": "az400-113"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "What should you configure in GitHub to require reporters to submit structured bug details such as environment, version, and repro steps?",
        "de": "Was sollten Sie in GitHub konfigurieren, damit Meldende strukturierte Bug-Details wie Umgebung, Version und Reproduktionsschritte angeben müssen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Issue forms",
            "de": "Issue Forms"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Release tags",
            "de": "Release-Tags"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Repository forks",
            "de": "Repository-Forks"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Branch renaming",
            "de": "Branch-Umbenennung"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Issue forms is correct because they collect standardized fields before an issue is submitted. It best meets the requirement to standardize incoming bug feedback.",
        "de": "Issue Forms ist richtig, weil sie erfassen standardisierte Felder, bevor ein Issue eingereicht wird. Damit wird die Anforderung am besten erfüllt, eingehendes Bug-Feedback zu standardisieren."
      },
      "hint": {
        "en": "Focus on the need to standardize incoming bug feedback.",
        "de": "Achten Sie auf die Anforderung, eingehendes Bug-Feedback zu standardisieren."
      },
      "reference": "https://docs.github.com/en/issues/building-community/using-issue-forms-to-encourage-useful-issues",
      "id": "az400-114"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "Two developers are on holiday next sprint and the team wants its commitment to reflect that automatically.",
        "de": "Zwei Entwickler haben im nächsten Sprint Urlaub, und das Team möchte, dass sich dies automatisch in seiner Zusage widerspiegelt."
      },
      "question": {
        "en": "Which Azure Boards feature should a Scrum Master use to account for vacations and individual availability during sprint planning?",
        "de": "Welche Azure-Boards-Funktion sollte ein Scrum Master verwenden, um Urlaube und individuelle Verfügbarkeit in der Sprintplanung zu berücksichtigen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Sprint capacity planning",
            "de": "Sprint-Kapazitätsplanung"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Release approvals",
            "de": "Release-Genehmigungen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Service hooks",
            "de": "Service Hooks"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Variable templates",
            "de": "Variablen-Templates"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Sprint capacity planning is correct because it models each team member's available effort for the sprint. It best meets the requirement to plan sprint work using real team availability.",
        "de": "Sprint-Kapazitätsplanung ist richtig, weil sie bildet den verfügbaren Aufwand jedes Teammitglieds für den Sprint ab. Damit wird die Anforderung am besten erfüllt, Sprint-Arbeit anhand der tatsächlichen Teamverfügbarkeit zu planen."
      },
      "hint": {
        "en": "Focus on the need to plan sprint work using real team availability.",
        "de": "Achten Sie auf die Anforderung, Sprint-Arbeit anhand der tatsächlichen Teamverfügbarkeit zu planen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/boards/sprints/set-capacity?view=azure-devops",
      "id": "az400-115"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "What should you add to a repository so every new pull request starts with the same review checklist and context prompts?",
        "de": "Was sollten Sie einem Repository hinzufügen, damit jeder neue Pull Request mit derselben Review-Checkliste und denselben Kontextfragen startet?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A pull request template",
            "de": "Ein Pull-Request-Template"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A deployment slot",
            "de": "Einen Bereitstellungsslot"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A build badge",
            "de": "Ein Build-Badge"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A branch tag",
            "de": "Ein Branch-Tag"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A pull request template is correct because it pre-populates the PR description with consistent review guidance. It best meets the requirement to standardize pull request communication.",
        "de": "Ein Pull-Request-Template ist richtig, weil es füllt die PR-Beschreibung mit konsistenten Review-Hinweisen vor. Damit wird die Anforderung am besten erfüllt, die Kommunikation in Pull Requests zu standardisieren."
      },
      "hint": {
        "en": "Focus on the need to standardize pull request communication.",
        "de": "Achten Sie auf die Anforderung, die Kommunikation in Pull Requests zu standardisieren."
      },
      "reference": "https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository",
      "id": "az400-116"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Business stakeholders need to create and update work items but should not have access to source code repositories. Which access level fits best?",
        "de": "Geschäftliche Stakeholder sollen Arbeitselemente erstellen und aktualisieren können, aber keinen Zugriff auf Quellcode-Repositorys erhalten. Welche Zugriffsebene passt am besten?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Stakeholder access",
            "de": "Stakeholder-Zugriff"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Project Collection Administrator",
            "de": "Project Collection Administrator"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Basic plus Test Plans for everyone",
            "de": "Basic plus Test Plans für alle"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Repository contributor access",
            "de": "Mitwirkendenzugriff auf Repositorys"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Stakeholder access is correct because it is designed for work tracking participation without unnecessary code permissions. It best meets the requirement to let non-developers collaborate on work tracking only.",
        "de": "Stakeholder-Zugriff ist richtig, weil er ist für die Mitarbeit an der Arbeitsverfolgung ohne unnötige Codeberechtigungen ausgelegt. Damit wird die Anforderung am besten erfüllt, Nicht-Entwicklern die Zusammenarbeit an der Arbeitsverfolgung zu ermöglichen."
      },
      "hint": {
        "en": "Focus on the need to let non-developers collaborate on work tracking only.",
        "de": "Achten Sie auf die Anforderung, Nicht-Entwicklern die Zusammenarbeit an der Arbeitsverfolgung zu ermöglichen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/organizations/security/stakeholder-access?view=azure-devops",
      "id": "az400-117"
    },
    {
      "type": "single",
      "domain": {
        "en": "Configure Processes and Communications",
        "de": "Prozesse und Kommunikation konfigurieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "An architecture group wants one central wiki for runbooks and standards that should not live inside any product repository.",
        "de": "Eine Architekturgruppe möchte ein zentrales Wiki für Runbooks und Standards, das nicht in einem Produkt-Repository liegen soll."
      },
      "question": {
        "en": "Which Azure DevOps wiki type is best when several teams want one browser-editable knowledge base that is separate from application repositories?",
        "de": "Welcher Azure-DevOps-Wiki-Typ ist am besten geeignet, wenn mehrere Teams eine browserbearbeitbare Wissensdatenbank wünschen, die von den Anwendungsrepositorys getrennt ist?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A project wiki",
            "de": "Ein Projekt-Wiki"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A code wiki",
            "de": "Ein Code-Wiki"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A release pipeline",
            "de": "Eine Release-Pipeline"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A variable group",
            "de": "Eine Variablengruppe"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A project wiki is correct because it provides a standalone shared wiki experience that is not tied to a single code repository. It best meets the requirement to maintain a shared knowledge base outside application repos.",
        "de": "Ein Projekt-Wiki ist richtig, weil es bietet eine eigenständige gemeinsame Wiki-Erfahrung, die nicht an ein einzelnes Code-Repository gebunden ist. Damit wird die Anforderung am besten erfüllt, eine gemeinsame Wissensdatenbank außerhalb der Anwendungsrepositorys zu pflegen."
      },
      "hint": {
        "en": "Focus on the need to maintain a shared knowledge base outside application repos.",
        "de": "Achten Sie auf die Anforderung, eine gemeinsame Wissensdatenbank außerhalb der Anwendungsrepositorys zu pflegen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/project/wiki/wiki-create-repo?view=azure-devops",
      "id": "az400-118"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "You need to copy one specific hotfix commit from main to a release branch without merging unrelated changes. Which Git operation should you use?",
        "de": "Sie müssen einen bestimmten Hotfix-Commit von main in einen Release-Branch übernehmen, ohne nicht zusammengehörige Änderungen zu mergen. Welche Git-Operation sollten Sie verwenden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Cherry-pick",
            "de": "Cherry-Pick"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Rebase",
            "de": "Rebase"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Clone",
            "de": "Clone"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Squash",
            "de": "Squash"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Cherry-pick is correct because it applies selected commits to another branch without bringing the whole branch history. It best meets the requirement to backport one isolated fix only.",
        "de": "Cherry-Pick ist richtig, weil es übernimmt ausgewählte Commits in einen anderen Branch, ohne die gesamte Branch-Historie mitzubringen. Damit wird die Anforderung am besten erfüllt, nur einen einzelnen Fix zurückzuportieren."
      },
      "hint": {
        "en": "Focus on the need to backport one isolated fix only.",
        "de": "Achten Sie auf die Anforderung, nur einen einzelnen Fix zurückzuportieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/repos/git/cherry-pick?view=azure-devops",
      "id": "az400-119"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which GitHub merge method gives a linear history and keeps the individual commits from the pull request?",
        "de": "Welche GitHub-Merge-Methode liefert eine lineare Historie und behält die einzelnen Commits aus dem Pull Request bei?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Rebase and merge",
            "de": "Rebase and merge"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Merge commit",
            "de": "Merge Commit"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Squash and merge",
            "de": "Squash and merge"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Force push",
            "de": "Force Push"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Rebase and merge is correct because it replays the PR commits onto the base branch without adding a merge commit. It best meets the requirement to keep a linear history while preserving individual commits.",
        "de": "Rebase and merge ist richtig, weil es spielt die PR-Commits auf dem Basis-Branch erneut ein, ohne einen Merge-Commit hinzuzufügen. Damit wird die Anforderung am besten erfüllt, eine lineare Historie bei Erhalt der einzelnen Commits zu behalten."
      },
      "hint": {
        "en": "Focus on the need to keep a linear history while preserving individual commits.",
        "de": "Achten Sie auf die Anforderung, eine lineare Historie bei Erhalt der einzelnen Commits zu behalten."
      },
      "reference": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github",
      "id": "az400-120"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "Different teams own ten services and want to avoid unrelated PR noise and shared branch rules.",
        "de": "Verschiedene Teams verantworten zehn Services und möchten irrelevantes PR-Rauschen sowie gemeinsame Branch-Regeln vermeiden."
      },
      "question": {
        "en": "A company wants each microservice to have its own permissions and release cadence. Which repository strategy is usually the better fit?",
        "de": "Ein Unternehmen möchte für jeden Microservice eigene Berechtigungen und einen eigenen Release-Takt. Welche Repository-Strategie ist in der Regel besser geeignet?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Multi-repo",
            "de": "Multi-Repo"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Mono-repo",
            "de": "Mono-Repo"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A single release branch",
            "de": "Ein einzelner Release-Branch"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A bare repository only",
            "de": "Nur ein Bare-Repository"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A multi-repo strategy is correct because it separates codebases so teams can version, secure, and ship them independently. It best meets the requirement to support independent service ownership and releases.",
        "de": "Eine Multi-Repo-Strategie ist richtig, weil sie trennt Codebasen, damit Teams sie unabhängig versionieren, absichern und ausliefern können. Damit wird die Anforderung am besten erfüllt, unabhängige Service-Verantwortung und Releases zu unterstützen."
      },
      "hint": {
        "en": "Focus on the need to support independent service ownership and releases.",
        "de": "Achten Sie auf die Anforderung, unabhängige Service-Verantwortung und Releases zu unterstützen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/devops",
      "id": "az400-121"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The same team owns closely coupled services and wants one source of truth for refactoring shared contracts.",
        "de": "Dasselbe Team verantwortet eng gekoppelte Services und möchte eine zentrale Quelle der Wahrheit für Refactorings gemeinsamer Verträge."
      },
      "question": {
        "en": "A product frequently needs one pull request that changes the API, UI, and shared contract together. Which repository strategy is often the best fit?",
        "de": "Ein Produkt benötigt häufig einen Pull Request, der API, UI und gemeinsames Vertragsmodell gleichzeitig ändert. Welche Repository-Strategie ist oft am besten geeignet?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Mono-repo",
            "de": "Mono-Repo"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Multi-repo",
            "de": "Multi-Repo"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A fork-only workflow",
            "de": "Ein reiner Fork-Workflow"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A package feed only",
            "de": "Nur ein Paketfeed"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A mono-repo strategy is correct because it allows atomic cross-component changes and one review for a single business change. It best meets the requirement to make coordinated cross-component changes in one unit.",
        "de": "Eine Mono-Repo-Strategie ist richtig, weil sie ermöglicht atomare Änderungen über Komponenten hinweg und ein gemeinsames Review für eine einzelne fachliche Änderung. Damit wird die Anforderung am besten erfüllt, abgestimmte komponentenübergreifende Änderungen in einer Einheit vorzunehmen."
      },
      "hint": {
        "en": "Focus on the need to make coordinated cross-component changes in one unit.",
        "de": "Achten Sie auf die Anforderung, abgestimmte komponentenübergreifende Änderungen in einer Einheit vorzunehmen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/devops",
      "id": "az400-122"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "Only the platform security group may approve changes under /infra/security and /policies.",
        "de": "Nur die Plattform-Sicherheitsgruppe darf Änderungen unter /infra/security und /policies genehmigen."
      },
      "question": {
        "en": "Which two GitHub controls help ensure changes to security-sensitive files are reviewed by the right specialists?",
        "de": "Welche zwei GitHub-Steuerungen helfen sicherzustellen, dass Änderungen an sicherheitskritischen Dateien von den richtigen Spezialisten geprüft werden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Define CODEOWNERS entries for those paths",
            "de": "CODEOWNERS-Einträge für diese Pfade definieren"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Require review from code owners in branch protection",
            "de": "In der Branch-Protection ein Review von Code Ownern verlangen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Allow force pushes to the branch",
            "de": "Force Pushes auf den Branch erlauben"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Disable pull requests for the repository",
            "de": "Pull Requests für das Repository deaktivieren"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "CODEOWNERS together with required code owner review is correct because they map paths to responsible reviewers and enforce their approval before merge. It best meets the requirement to route sensitive changes to the correct approvers.",
        "de": "CODEOWNERS zusammen mit verpflichtenden Code-Owner-Reviews ist richtig, weil sie ordnen Pfade verantwortlichen Reviewern zu und erzwingen deren Zustimmung vor dem Merge. Damit wird die Anforderung am besten erfüllt, sensible Änderungen an die richtigen Genehmiger zu leiten."
      },
      "hint": {
        "en": "Focus on the need to route sensitive changes to the correct approvers.",
        "de": "Achten Sie auf die Anforderung, sensible Änderungen an die richtigen Genehmiger zu leiten."
      },
      "reference": "https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners",
      "id": "az400-123"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "An external contributor needs to propose a change but must not receive write access to the main repository. Which workflow should you use?",
        "de": "Ein externer Mitwirkender soll eine Änderung vorschlagen können, darf aber keinen Schreibzugriff auf das Hauptrepository erhalten. Welchen Workflow sollten Sie verwenden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Fork the repository and open a pull request",
            "de": "Das Repository forken und einen Pull Request öffnen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Grant direct push access to main",
            "de": "Direkten Push-Zugriff auf main gewähren"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Send patch files by email only",
            "de": "Patch-Dateien nur per E-Mail senden"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Use a shared administrator account",
            "de": "Ein gemeinsames Administratorkonto verwenden"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A fork-based workflow is correct because it lets contributors work in their own copy and submit changes through review. It best meets the requirement to accept contributions without granting repository write access.",
        "de": "Einen Fork-basierten Workflow ist richtig, weil er ermöglicht Mitwirkenden, in ihrer eigenen Kopie zu arbeiten und Änderungen per Review einzureichen. Damit wird die Anforderung am besten erfüllt, Beiträge anzunehmen, ohne Schreibzugriff auf das Repository zu geben."
      },
      "hint": {
        "en": "Focus on the need to accept contributions without granting repository write access.",
        "de": "Achten Sie auf die Anforderung, Beiträge anzunehmen, ohne Schreibzugriff auf das Repository zu geben."
      },
      "reference": "https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks",
      "id": "az400-124"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The default branch deploys automatically, so any bypass of review or CI is unacceptable.",
        "de": "Der Standard-Branch wird automatisch bereitgestellt, daher ist jede Umgehung von Review oder CI inakzeptabel."
      },
      "question": {
        "en": "Which GitHub branch protection setting should you use to block direct pushes and require CI to pass before main can be updated?",
        "de": "Welche GitHub-Branch-Protection-Einstellung sollten Sie verwenden, um direkte Pushes zu blockieren und zu verlangen, dass CI erfolgreich ist, bevor main aktualisiert werden kann?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Require a pull request and required status checks",
            "de": "Einen Pull Request und erforderliche Statusprüfungen verlangen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Allow deletion of the branch",
            "de": "Das Löschen des Branches erlauben"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Disable branch protection",
            "de": "Branch-Protection deaktivieren"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Require repository forks",
            "de": "Repository-Forks verlangen"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Protected branch rules with required pull requests and status checks is correct because they centralize protection on the branch instead of relying on local habits. It best meets the requirement to protect main from unvalidated direct changes.",
        "de": "Protected-Branch-Regeln mit verpflichtenden Pull Requests und Statusprüfungen ist richtig, weil sie zentralisieren den Schutz auf dem Branch, statt sich auf lokale Gewohnheiten zu verlassen. Damit wird die Anforderung am besten erfüllt, main vor nicht validierten direkten Änderungen zu schützen."
      },
      "hint": {
        "en": "Focus on the need to protect main from unvalidated direct changes.",
        "de": "Achten Sie auf die Anforderung, main vor nicht validierten direkten Änderungen zu schützen."
      },
      "reference": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches",
      "id": "az400-125"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Git technology should you use for large binary assets such as videos or design files so the repository stays manageable?",
        "de": "Welche Git-Technologie sollten Sie für große Binärdateien wie Videos oder Designdateien verwenden, damit das Repository handhabbar bleibt?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Git LFS",
            "de": "Git LFS"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Git stash",
            "de": "Git Stash"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git blame",
            "de": "Git Blame"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Git notes",
            "de": "Git Notes"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Git LFS is correct because it stores large file content outside normal Git object history while keeping lightweight pointers in the repo. It best meets the requirement to manage large binary assets efficiently.",
        "de": "Git LFS ist richtig, weil es speichert große Dateiinhalte außerhalb der normalen Git-Objekthistorie und behält nur schlanke Verweise im Repository. Damit wird die Anforderung am besten erfüllt, große Binärdateien effizient zu verwalten."
      },
      "hint": {
        "en": "Focus on the need to manage large binary assets efficiently.",
        "de": "Achten Sie auf die Anforderung, große Binärdateien effizient zu verwalten."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/repos/git/manage-large-files?view=azure-devops",
      "id": "az400-126"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "What should a developer do to bring a feature branch up to date with main while keeping a clean linear history before opening a pull request?",
        "de": "Was sollte ein Entwickler tun, um einen Feature-Branch vor dem Öffnen eines Pull Requests mit main zu synchronisieren und dabei eine saubere lineare Historie zu behalten?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Rebase the feature branch onto main",
            "de": "Den Feature-Branch auf main rebasen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Delete and recreate the repository",
            "de": "Das Repository löschen und neu erstellen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Squash the main branch into the feature branch",
            "de": "Den main-Branch in den Feature-Branch squashen"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Convert commits to tags",
            "de": "Commits in Tags umwandeln"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Rebasing the feature branch onto main is correct because it replays the branch work on top of the latest base branch history. It best meets the requirement to synchronize with main without adding merge commits.",
        "de": "Das Rebasen des Feature-Branches auf main ist richtig, weil es spielt die Branch-Arbeit auf der neuesten Historie des Basis-Branches erneut ein. Damit wird die Anforderung am besten erfüllt, mit main zu synchronisieren, ohne Merge-Commits hinzuzufügen."
      },
      "hint": {
        "en": "Focus on the need to synchronize with main without adding merge commits.",
        "de": "Achten Sie auf die Anforderung, mit main zu synchronisieren, ohne Merge-Commits hinzuzufügen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/repos/git/rebase?view=azure-devops",
      "id": "az400-127"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which pull request state should you use when you want early feedback but the change is not ready to merge yet?",
        "de": "Welchen Pull-Request-Status sollten Sie verwenden, wenn Sie frühes Feedback möchten, die Änderung aber noch nicht zum Mergen bereit ist?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Draft pull request",
            "de": "Entwurfs-Pull-Request"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Closed pull request",
            "de": "Geschlossener Pull Request"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Merged pull request",
            "de": "Gemergter Pull Request"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Protected pull request",
            "de": "Geschützter Pull Request"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A draft pull request is correct because it signals that review input is welcome while merge readiness has not been reached. It best meets the requirement to collect feedback without signaling merge readiness.",
        "de": "Ein Entwurfs-Pull-Request ist richtig, weil er signalisiert, dass Review-Feedback willkommen ist, während die Änderungsmenge noch nicht merge-bereit ist. Damit wird die Anforderung am besten erfüllt, Feedback zu sammeln, ohne Merge-Bereitschaft zu signalisieren."
      },
      "hint": {
        "en": "Focus on the need to collect feedback without signaling merge readiness.",
        "de": "Achten Sie auf die Anforderung, Feedback zu sammeln, ohne Merge-Bereitschaft zu signalisieren."
      },
      "reference": "https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests",
      "id": "az400-128"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which merge method is most appropriate when you want the target branch history to show an explicit integration point for a long-lived branch?",
        "de": "Welche Merge-Methode ist am geeignetsten, wenn die Historie des Ziel-Branches einen expliziten Integrationspunkt für einen langlebigen Branch zeigen soll?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Create a merge commit",
            "de": "Einen Merge-Commit erstellen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Rebase and merge",
            "de": "Rebase and merge"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Cherry-pick every commit",
            "de": "Jeden Commit cherry-picken"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Force push the feature branch",
            "de": "Den Feature-Branch per Force Push übertragen"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A merge commit is correct because it preserves the branch topology and shows where the histories were joined. It best meets the requirement to keep an explicit branch integration record.",
        "de": "Ein Merge-Commit ist richtig, weil er erhält die Branch-Topologie und zeigt, an welcher Stelle die Historien zusammengeführt wurden. Damit wird die Anforderung am besten erfüllt, einen expliziten Integrationspunkt in der Branch-Historie zu behalten."
      },
      "hint": {
        "en": "Focus on the need to keep an explicit branch integration record.",
        "de": "Achten Sie auf die Anforderung, einen expliziten Integrationspunkt in der Branch-Historie zu behalten."
      },
      "reference": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github",
      "id": "az400-129"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which merge method is best when you want a noisy feature branch to become a single clean commit on main?",
        "de": "Welche Merge-Methode ist am besten, wenn ein unübersichtlicher Feature-Branch als einzelner sauberer Commit auf main erscheinen soll?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Squash and merge",
            "de": "Squash and merge"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Rebase and merge",
            "de": "Rebase and merge"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Merge commit",
            "de": "Merge Commit"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Cherry-pick the merge commit",
            "de": "Den Merge-Commit cherry-picken"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Squash and merge is correct because it combines the branch commits into one curated commit on the target branch. It best meets the requirement to collapse many small commits into one clean change.",
        "de": "Squash and merge ist richtig, weil es fasst die Branch-Commits zu einem kuratierten Commit auf dem Ziel-Branch zusammen. Damit wird die Anforderung am besten erfüllt, viele kleine Commits zu einer sauberen Änderung zusammenzufassen."
      },
      "hint": {
        "en": "Focus on the need to collapse many small commits into one clean change.",
        "de": "Achten Sie auf die Anforderung, viele kleine Commits zu einer sauberen Änderung zusammenzufassen."
      },
      "reference": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github",
      "id": "az400-130"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": null,
      "question": {
        "en": "Which two actions help teams consume a shared repository at an approved revision without copying its contents into every repo?",
        "de": "Welche zwei Maßnahmen helfen Teams, ein gemeinsames Repository in einer freigegebenen Revision zu verwenden, ohne dessen Inhalte in jedes Repository zu kopieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Add it as a Git submodule",
            "de": "Es als Git-Submodul hinzufügen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Update the recorded submodule commit only when a version is approved",
            "de": "Den gespeicherten Submodul-Commit nur aktualisieren, wenn eine Version freigegeben ist"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Tell every developer to copy the files manually",
            "de": "Allen Entwicklern sagen, die Dateien manuell zu kopieren"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Store the dependency only on a network share",
            "de": "Die Abhängigkeit nur auf einer Netzwerkfreigabe abzulegen"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Git submodules together with pinned submodule commits is correct because they link another repository while letting each consumer stay on a known revision. It best meets the requirement to reuse another repository while pinning approved versions.",
        "de": "Git-Submodule zusammen mit festgepinnten Submodul-Commits ist richtig, weil sie binden ein anderes Repository ein und erlauben gleichzeitig, pro Consumer auf einer bekannten Revision zu bleiben. Damit wird die Anforderung am besten erfüllt, ein anderes Repository wiederzuverwenden und dabei freigegebene Versionen festzupinnen."
      },
      "hint": {
        "en": "Focus on the need to reuse another repository while pinning approved versions.",
        "de": "Achten Sie auf die Anforderung, ein anderes Repository wiederzuverwenden und dabei freigegebene Versionen festzupinnen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/repos/git/git-submodules?view=azure-devops",
      "id": "az400-131"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which repository rule should you enable if your organization wants GitHub to verify commit signatures before protected branches accept new commits?",
        "de": "Welche Repository-Regel sollten Sie aktivieren, wenn Ihre Organisation möchte, dass GitHub Commit-Signaturen prüft, bevor geschützte Branches neue Commits akzeptieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Require signed commits",
            "de": "Signierte Commits verlangen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Allow merge queue bypass",
            "de": "Merge-Queue-Bypass erlauben"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Disable status checks",
            "de": "Statusprüfungen deaktivieren"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Require issue labels on all commits",
            "de": "Issue-Labels für alle Commits verlangen"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Require signed commits is correct because it adds identity and integrity checks to accepted commits. It best meets the requirement to verify authorship on protected branches.",
        "de": "Signierte Commits verlangen ist richtig, weil es fügt angenommenen Commits Identitäts- und Integritätsprüfungen hinzu. Damit wird die Anforderung am besten erfüllt, die Urheberschaft auf geschützten Branches zu überprüfen."
      },
      "hint": {
        "en": "Focus on the need to verify authorship on protected branches.",
        "de": "Achten Sie auf die Anforderung, die Urheberschaft auf geschützten Branches zu überprüfen."
      },
      "reference": "https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification",
      "id": "az400-132"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Git hook runs on a developer workstation before a commit is created and is commonly used for local linting or formatting?",
        "de": "Welcher Git-Hook läuft auf dem Entwicklerarbeitsplatz, bevor ein Commit erstellt wird, und wird häufig für lokales Linting oder Formatierung verwendet?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "pre-commit",
            "de": "pre-commit"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "post-receive",
            "de": "post-receive"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "prepare-commit-msg on the server",
            "de": "prepare-commit-msg auf dem Server"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "pre-push on the remote repository",
            "de": "pre-push auf dem Remote-Repository"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The pre-commit hook is correct because it runs before the commit is recorded and is suited to local checks. It best meets the requirement to run local validation before a commit is written.",
        "de": "Der pre-commit-Hook ist richtig, weil er läuft, bevor der Commit gespeichert wird, und eignet sich für lokale Prüfungen. Damit wird die Anforderung am besten erfüllt, lokale Validierung auszuführen, bevor ein Commit geschrieben wird."
      },
      "hint": {
        "en": "Focus on the need to run local validation before a commit is written.",
        "de": "Achten Sie auf die Anforderung, lokale Validierung auszuführen, bevor ein Commit geschrieben wird."
      },
      "reference": "https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks",
      "id": "az400-133"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The contributor's fork is weeks behind and now has conflicts with the project's default branch.",
        "de": "Der Fork des Mitwirkenden ist Wochen hinterher und hat nun Konflikte mit dem Standard-Branch des Projekts."
      },
      "question": {
        "en": "A developer works in a personal fork and wants the latest changes from the original repository. What should the developer do?",
        "de": "Ein Entwickler arbeitet in einem persönlichen Fork und möchte die neuesten Änderungen aus dem ursprünglichen Repository übernehmen. Was sollte der Entwickler tun?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Add the original repository as an upstream remote and sync from it",
            "de": "Das ursprüngliche Repository als Upstream-Remote hinzufügen und davon synchronisieren"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Delete the fork and start over",
            "de": "Den Fork löschen und neu beginnen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Force push main from the fork into the original repository",
            "de": "main aus dem Fork per Force Push in das Ursprungsrepository übertragen"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Create a release from the fork",
            "de": "Einen Release aus dem Fork erstellen"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "An upstream remote sync is correct because it is the standard way to pull updates from the original repository into a fork. It best meets the requirement to keep a fork current with upstream changes.",
        "de": "Eine Synchronisierung über ein Upstream-Remote ist richtig, weil es ist der Standardweg, Updates aus dem Ursprungsrepository in einen Fork zu übernehmen. Damit wird die Anforderung am besten erfüllt, einen Fork mit Upstream-Änderungen aktuell zu halten."
      },
      "hint": {
        "en": "Focus on the need to keep a fork current with upstream changes.",
        "de": "Achten Sie auf die Anforderung, einen Fork mit Upstream-Änderungen aktuell zu halten."
      },
      "reference": "https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks",
      "id": "az400-134"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure Repos pull request feature should you use when you want the PR to complete automatically after all required policies succeed?",
        "de": "Welche Azure-Repos-Pull-Request-Funktion sollten Sie verwenden, wenn der PR automatisch abgeschlossen werden soll, sobald alle erforderlichen Richtlinien erfolgreich sind?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Auto-complete",
            "de": "Auto-Complete"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Abandon",
            "de": "Abandon"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Revert",
            "de": "Revert"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Force push",
            "de": "Force Push"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Auto-complete is correct because it queues the PR for completion once policy requirements are satisfied. It best meets the requirement to finish the PR automatically after policy success.",
        "de": "Auto-Complete ist richtig, weil es stellt den PR zum Abschluss an, sobald die Richtlinienanforderungen erfüllt sind. Damit wird die Anforderung am besten erfüllt, den PR nach erfolgreicher Richtlinienprüfung automatisch abzuschließen."
      },
      "hint": {
        "en": "Focus on the need to finish the PR automatically after policy success.",
        "de": "Achten Sie auf die Anforderung, den PR nach erfolgreicher Richtlinienprüfung automatisch abzuschließen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/repos/git/complete-pull-requests?view=azure-devops",
      "id": "az400-135"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Design and Implement Source Control",
        "de": "Quellcodeverwaltung entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The main branch is production-facing and must resist accidental overwrites as well as unreviewed pushes.",
        "de": "Der main-Branch ist produktionsrelevant und muss sowohl gegen versehentliche Überschreibungen als auch gegen nicht geprüfte Pushes geschützt sein."
      },
      "question": {
        "en": "Which two protected branch settings on GitHub reduce the risk of unsafe changes landing directly on main?",
        "de": "Welche zwei Einstellungen für geschützte Branches in GitHub verringern das Risiko, dass unsichere Änderungen direkt auf main landen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Require a pull request before merging",
            "de": "Einen Pull Request vor dem Merge verlangen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Block force pushes",
            "de": "Force Pushes blockieren"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Allow branch deletion",
            "de": "Das Löschen des Branches erlauben"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Allow bypass for everyone",
            "de": "Bypass für alle erlauben"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Required pull requests and blocked force pushes is correct because they stop direct history rewrites and require reviewed integration through the normal workflow. It best meets the requirement to harden the default branch against unsafe direct updates.",
        "de": "Verpflichtende Pull Requests und blockierte Force Pushes ist richtig, weil sie verhindern direkte Umschreibungen der Historie und verlangen eine geprüfte Integration über den normalen Workflow. Damit wird die Anforderung am besten erfüllt, den Standard-Branch gegen unsichere direkte Aktualisierungen abzusichern."
      },
      "hint": {
        "en": "Focus on the need to harden the default branch against unsafe direct updates.",
        "de": "Achten Sie auf die Anforderung, den Standard-Branch gegen unsichere direkte Aktualisierungen abzusichern."
      },
      "reference": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches",
      "id": "az400-136"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "A monorepo contains many services, and the API build should not run when only documentation changes.",
        "de": "Ein Monorepo enthält viele Services, und der API-Build soll nicht laufen, wenn nur Dokumentation geändert wurde."
      },
      "question": {
        "en": "Which Azure DevOps trigger filter should you use when a pipeline must run only if files under src/api change?",
        "de": "Welchen Azure-DevOps-Trigger-Filter sollten Sie verwenden, wenn eine Pipeline nur bei Änderungen unter src/api laufen soll?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A path filter",
            "de": "Einen Pfadfilter"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "An agent demand",
            "de": "Eine Agent-Anforderung"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A variable group",
            "de": "Eine Variablengruppe"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A manual approval",
            "de": "Eine manuelle Genehmigung"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A path filter is correct because it limits pipeline execution to changes affecting specified paths. It best meets the requirement to run the pipeline only for relevant file changes.",
        "de": "Einen Pfadfilter ist richtig, weil er begrenzt die Pipelineausführung auf Änderungen, die bestimmte Pfade betreffen. Damit wird die Anforderung am besten erfüllt, die Pipeline nur für relevante Dateiänderungen auszuführen."
      },
      "hint": {
        "en": "Focus on the need to run the pipeline only for relevant file changes.",
        "de": "Achten Sie auf die Anforderung, die Pipeline nur für relevante Dateiänderungen auszuführen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops",
      "id": "az400-137"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "What should you use in GitHub Actions to share an entire deployment workflow across many repositories?",
        "de": "Was sollten Sie in GitHub Actions verwenden, um einen vollständigen Bereitstellungs-Workflow über viele Repositorys hinweg gemeinsam zu nutzen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A reusable workflow called with workflow_call",
            "de": "Einen wiederverwendbaren Workflow mit workflow_call"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A release tag only",
            "de": "Nur einen Release-Tag"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A CODEOWNERS file",
            "de": "Eine CODEOWNERS-Datei"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A local Git hook",
            "de": "Einen lokalen Git-Hook"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A reusable workflow is correct because it packages whole jobs and permissions behind a shared workflow interface. It best meets the requirement to reuse a complete workflow across repositories.",
        "de": "Einen wiederverwendbaren Workflow ist richtig, weil er kapselt ganze Jobs und Berechtigungen hinter einer gemeinsamen Workflow-Schnittstelle. Damit wird die Anforderung am besten erfüllt, einen vollständigen Workflow über Repositorys hinweg wiederzuverwenden."
      },
      "hint": {
        "en": "Focus on the need to reuse a complete workflow across repositories.",
        "de": "Achten Sie auf die Anforderung, einen vollständigen Workflow über Repositorys hinweg wiederzuverwenden."
      },
      "reference": "https://docs.github.com/en/actions/using-workflows/reusing-workflows",
      "id": "az400-138"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The team wants one concise workflow file but needs every pull request validated on both hosted Linux and Windows runners.",
        "de": "Das Team möchte eine kompakte Workflow-Datei, muss aber jeden Pull Request sowohl auf gehosteten Linux- als auch Windows-Runnern validieren."
      },
      "question": {
        "en": "Which two GitHub Actions features should you use to test the same application on Ubuntu and Windows without duplicating jobs?",
        "de": "Welche zwei GitHub-Actions-Funktionen sollten Sie verwenden, um dieselbe Anwendung unter Ubuntu und Windows zu testen, ohne Jobs zu duplizieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A strategy.matrix definition",
            "de": "Eine strategy.matrix-Definition"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Use matrix values in runs-on",
            "de": "Matrixwerte in runs-on verwenden"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Create one repository per operating system",
            "de": "Ein Repository pro Betriebssystem erstellen"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Use workflow_dispatch only",
            "de": "Nur workflow_dispatch verwenden"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "A build matrix together with matrix-driven runner selection is correct because they let one job definition expand into multiple operating-system combinations. It best meets the requirement to run the same test logic across multiple operating systems.",
        "de": "Eine Build-Matrix zusammen mit Matrix-gesteuerter Runner-Auswahl ist richtig, weil sie ermöglichen, dass sich eine Job-Definition in mehrere Betriebssystem-Kombinationen erweitert. Damit wird die Anforderung am besten erfüllt, dieselbe Testlogik auf mehreren Betriebssystemen auszuführen."
      },
      "hint": {
        "en": "Focus on the need to run the same test logic across multiple operating systems.",
        "de": "Achten Sie auf die Anforderung, dieselbe Testlogik auf mehreren Betriebssystemen auszuführen."
      },
      "reference": "https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs",
      "id": "az400-139"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps library feature is designed to share non-secret variables across multiple pipelines?",
        "de": "Welche Azure-DevOps-Library-Funktion ist dafür vorgesehen, nicht geheime Variablen über mehrere Pipelines hinweg gemeinsam zu nutzen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Variable groups",
            "de": "Variablengruppen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Agent pools",
            "de": "Agent-Pools"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Deployment groups",
            "de": "Bereitstellungsgruppen"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Variable groups is correct because they centralize reusable pipeline values for many definitions. It best meets the requirement to share common pipeline configuration values.",
        "de": "Variablengruppen ist richtig, weil sie zentralisieren wiederverwendbare Pipeline-Werte für viele Definitionen. Damit wird die Anforderung am besten erfüllt, gemeinsame Pipeline-Konfigurationswerte zu teilen."
      },
      "hint": {
        "en": "Focus on the need to share common pipeline configuration values.",
        "de": "Achten Sie auf die Anforderung, gemeinsame Pipeline-Konfigurationswerte zu teilen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops",
      "id": "az400-140"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "The security team has banned service principal secrets in repository settings.",
        "de": "Das Sicherheitsteam hat Service-Principal-Secrets in Repository-Einstellungen verboten."
      },
      "question": {
        "en": "Which two components are required to let GitHub Actions deploy to Azure without storing a client secret in GitHub?",
        "de": "Welche zwei Komponenten sind erforderlich, damit GitHub Actions nach Azure bereitstellen kann, ohne ein Client Secret in GitHub zu speichern?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A federated credential between GitHub and Microsoft Entra ID",
            "de": "Eine föderierte Anmeldeinformation zwischen GitHub und Microsoft Entra ID"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "The Azure Login action configured for OIDC",
            "de": "Die Azure-Login-Action, konfiguriert für OIDC"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A password stored in plaintext in the workflow",
            "de": "Ein im Workflow im Klartext gespeichertes Passwort"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A personal access token for Azure Resource Manager",
            "de": "Ein Personal Access Token für Azure Resource Manager"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "OIDC federation together with the Azure Login action is correct because they exchange short-lived tokens at runtime instead of storing long-lived secrets. It best meets the requirement to authenticate to Azure from GitHub without a stored secret.",
        "de": "OIDC-Föderation zusammen mit der Azure-Login-Action ist richtig, weil sie tauschen zur Laufzeit kurzlebige Tokens aus, statt langlebige Geheimnisse zu speichern. Damit wird die Anforderung am besten erfüllt, sich aus GitHub ohne gespeichertes Geheimnis bei Azure zu authentifizieren."
      },
      "hint": {
        "en": "Focus on the need to authenticate to Azure from GitHub without a stored secret.",
        "de": "Achten Sie auf die Anforderung, sich aus GitHub ohne gespeichertes Geheimnis bei Azure zu authentifizieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure-openid-connect",
      "id": "az400-141"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps expression syntax is evaluated at compile time and is commonly used in templates?",
        "de": "Welche Azure-DevOps-Ausdruckssyntax wird zur Compile-Zeit ausgewertet und häufig in Templates verwendet?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "${{ }}",
            "de": "${{ }}"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "$[ ]",
            "de": "$[ ]"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "$( )",
            "de": "$( )"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "@@",
            "de": "@@"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The ${{ }} syntax is correct because it is processed during template expansion before runtime starts. It best meets the requirement to evaluate template logic before jobs run.",
        "de": "Die ${{ }}-Syntax ist richtig, weil sie wird während der Template-Erweiterung verarbeitet, bevor die Laufzeit beginnt. Damit wird die Anforderung am besten erfüllt, Template-Logik auszuwerten, bevor Jobs laufen."
      },
      "hint": {
        "en": "Focus on the need to evaluate template logic before jobs run.",
        "de": "Achten Sie auf die Anforderung, Template-Logik auszuwerten, bevor Jobs laufen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops",
      "id": "az400-142"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps expression syntax should you use to compute a variable at runtime from other runtime values?",
        "de": "Welche Azure-DevOps-Ausdruckssyntax sollten Sie verwenden, um eine Variable zur Laufzeit aus anderen Laufzeitwerten zu berechnen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "$[ ]",
            "de": "$[ ]"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "${{ }}",
            "de": "${{ }}"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "#[]",
            "de": "#[]"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "%%",
            "de": "%%"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The $[ ] syntax is correct because it evaluates during pipeline runtime when dynamic values are available. It best meets the requirement to calculate values from runtime context.",
        "de": "Die $[ ]-Syntax ist richtig, weil sie wird während der Pipeline-Laufzeit ausgewertet, wenn dynamische Werte verfügbar sind. Damit wird die Anforderung am besten erfüllt, Werte aus dem Laufzeitkontext zu berechnen."
      },
      "hint": {
        "en": "Focus on the need to calculate values from runtime context.",
        "de": "Achten Sie auf die Anforderung, Werte aus dem Laufzeitkontext zu berechnen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops",
      "id": "az400-143"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "Operations allows releases only between 22:00 and 02:00 and still requires an approver on duty.",
        "de": "Der Betrieb erlaubt Releases nur zwischen 22:00 und 02:00 Uhr und verlangt dennoch einen diensthabenden Genehmiger."
      },
      "question": {
        "en": "Which two Azure DevOps environment checks fit a requirement for a production deployment that must be approved and must start only during an allowed change window?",
        "de": "Welche zwei Azure-DevOps-Umgebungsprüfungen passen zu einer Produktionsbereitstellung, die genehmigt werden muss und nur in einem erlaubten Änderungsfenster starten darf?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Manual approvals",
            "de": "Manuelle Genehmigungen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Business Hours",
            "de": "Business Hours"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A Git stash",
            "de": "Ein Git Stash"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A sprint capacity setting",
            "de": "Eine Sprint-Kapazitätseinstellung"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Manual approvals together with the Business Hours check is correct because they combine human governance with a deployment time window. It best meets the requirement to enforce both approval and timing constraints on production deploys.",
        "de": "Manuelle Genehmigungen zusammen mit der Business-Hours-Prüfung ist richtig, weil sie kombinieren menschliche Governance mit einem Zeitfenster für Bereitstellungen. Damit wird die Anforderung am besten erfüllt, sowohl Genehmigungs- als auch Zeitvorgaben für Produktionsdeployments durchzusetzen."
      },
      "hint": {
        "en": "Focus on the need to enforce both approval and timing constraints on production deploys.",
        "de": "Achten Sie auf die Anforderung, sowohl Genehmigungs- als auch Zeitvorgaben für Produktionsdeployments durchzusetzen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops",
      "id": "az400-144"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which deployment strategy in an Azure DevOps deployment job is designed to update VM targets in batches instead of all at once?",
        "de": "Welche Bereitstellungsstrategie in einem Azure-DevOps-Deployment-Job ist dafür gedacht, VM-Ziele in Batches statt alle auf einmal zu aktualisieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Rolling",
            "de": "Rolling"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "runOnce",
            "de": "runOnce"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Manual",
            "de": "Manual"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Template",
            "de": "Template"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The rolling strategy is correct because it deploys to subsets of targets sequentially to reduce blast radius. It best meets the requirement to roll out changes to VMs gradually.",
        "de": "Die Rolling-Strategie ist richtig, weil sie stellt sequenziell auf Teilmengen von Zielen bereit, um den Blast Radius zu reduzieren. Damit wird die Anforderung am besten erfüllt, Änderungen schrittweise auf VMs auszurollen."
      },
      "hint": {
        "en": "Focus on the need to roll out changes to VMs gradually.",
        "de": "Achten Sie auf die Anforderung, Änderungen schrittweise auf VMs auszurollen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops",
      "id": "az400-145"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": {
        "en": "The security team wants fewer packages in production images and faster image pulls.",
        "de": "Das Sicherheitsteam möchte weniger Pakete in Produktionsimages und schnellere Image-Pulls."
      },
      "question": {
        "en": "Which Docker technique should you use to keep the runtime image small and exclude build tooling from the final container?",
        "de": "Welche Docker-Technik sollten Sie verwenden, um das Runtime-Image klein zu halten und Build-Werkzeuge aus dem finalen Container auszuschließen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Multi-stage builds",
            "de": "Multi-Stage-Builds"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Docker attach",
            "de": "Docker attach"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Container restart policies",
            "de": "Container-Neustartrichtlinien"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A single giant base image",
            "de": "Ein einziges sehr großes Basis-Image"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Multi-stage builds is correct because they separate build layers from the final runtime layer. It best meets the requirement to produce a smaller runtime container image.",
        "de": "Multi-Stage-Builds ist richtig, weil sie trennen Build-Layer von der finalen Runtime-Schicht. Damit wird die Anforderung am besten erfüllt, ein kleineres Runtime-Container-Image zu erzeugen."
      },
      "hint": {
        "en": "Focus on the need to produce a smaller runtime container image.",
        "de": "Achten Sie auf die Anforderung, ein kleineres Runtime-Container-Image zu erzeugen."
      },
      "reference": "https://docs.docker.com/build/building/multi-stage/",
      "id": "az400-146"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure Artifacts capability lets an internal feed cache and expose packages from public registries together with private packages?",
        "de": "Welche Azure-Artifacts-Funktion ermöglicht es einem internen Feed, Pakete aus öffentlichen Registries zwischenzuspeichern und zusammen mit privaten Paketen bereitzustellen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Upstream sources",
            "de": "Upstream Sources"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Deployment rings",
            "de": "Deployment-Ringe"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Webhook subscriptions",
            "de": "Webhook-Abonnements"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Upstream sources is correct because they proxy and cache upstream packages through a managed internal feed. It best meets the requirement to combine private packages with controlled access to public packages.",
        "de": "Upstream Sources ist richtig, weil sie leiten Upstream-Pakete über einen verwalteten internen Feed weiter und cachen sie. Damit wird die Anforderung am besten erfüllt, private Pakete mit kontrolliertem Zugriff auf öffentliche Pakete zu kombinieren."
      },
      "hint": {
        "en": "Focus on the need to combine private packages with controlled access to public packages.",
        "de": "Achten Sie auf die Anforderung, private Pakete mit kontrolliertem Zugriff auf öffentliche Pakete zu kombinieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops",
      "id": "az400-147"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps artifact type should you use to pass build output from one stage to another in YAML pipelines?",
        "de": "Welchen Azure-DevOps-Artefakttyp sollten Sie verwenden, um Build-Ausgaben in YAML-Pipelines von einer Stage an die nächste zu übergeben?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Pipeline Artifacts",
            "de": "Pipeline Artifacts"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Wiki attachments",
            "de": "Wiki-Anhänge"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Work item comments",
            "de": "Arbeitselementkommentare"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Pipeline Artifacts is correct because they are optimized for sharing files between pipeline jobs and stages. It best meets the requirement to transfer build output between stages.",
        "de": "Pipeline Artifacts ist richtig, weil sie sind dafür optimiert, Dateien zwischen Pipeline-Jobs und Stages auszutauschen. Damit wird die Anforderung am besten erfüllt, Build-Ausgaben zwischen Stages zu übertragen."
      },
      "hint": {
        "en": "Focus on the need to transfer build output between stages.",
        "de": "Achten Sie auf die Anforderung, Build-Ausgaben zwischen Stages zu übertragen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/pipeline-artifacts?view=azure-devops",
      "id": "az400-148"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Bicep or ARM capability should you use to preview the resource changes that a deployment would make before actually applying them?",
        "de": "Welche Bicep- oder ARM-Funktion sollten Sie verwenden, um die Ressourcenänderungen einer Bereitstellung vor der tatsächlichen Ausführung anzuzeigen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "What-if",
            "de": "What-if"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Force push",
            "de": "Force Push"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git blame",
            "de": "Git Blame"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Tag protection",
            "de": "Tag-Schutz"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "What-if is correct because it evaluates the planned template changes and shows the expected resource impact. It best meets the requirement to preview infrastructure changes before deployment.",
        "de": "What-if ist richtig, weil es wertet die geplanten Template-Änderungen aus und zeigt die erwarteten Auswirkungen auf Ressourcen. Damit wird die Anforderung am besten erfüllt, Infrastrukturänderungen vor der Bereitstellung anzuzeigen."
      },
      "hint": {
        "en": "Focus on the need to preview infrastructure changes before deployment.",
        "de": "Achten Sie auf die Anforderung, Infrastrukturänderungen vor der Bereitstellung anzuzeigen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deploy-what-if",
      "id": "az400-149"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "Multiple pipeline runs manage the same environment, and state drift caused by local state files is no longer acceptable.",
        "de": "Mehrere Pipeline-Läufe verwalten dieselbe Umgebung, und Drift durch lokale State-Dateien ist nicht mehr akzeptabel."
      },
      "question": {
        "en": "What should a team use for Terraform state when several engineers run pipelines and must avoid concurrent state corruption?",
        "de": "Was sollte ein Team für den Terraform-State verwenden, wenn mehrere Ingenieure Pipelines ausführen und gleichzeitige State-Beschädigungen vermieden werden müssen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A remote backend such as Azure Storage",
            "de": "Ein Remote-Backend wie Azure Storage"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A local file on each developer machine",
            "de": "Eine lokale Datei auf jedem Entwicklerrechner"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A wiki page",
            "de": "Eine Wiki-Seite"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A Git tag",
            "de": "Ein Git-Tag"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A remote backend such as Azure Storage is correct because it centralizes state and supports coordination and locking for team use. It best meets the requirement to manage Terraform state safely for a team.",
        "de": "Ein Remote-Backend wie Azure Storage ist richtig, weil es zentralisiert den State und unterstützt Koordination sowie Sperren für die Teamnutzung. Damit wird die Anforderung am besten erfüllt, Terraform-State sicher für ein Team zu verwalten."
      },
      "hint": {
        "en": "Focus on the need to manage Terraform state safely for a team.",
        "de": "Achten Sie auf die Anforderung, Terraform-State sicher für ein Team zu verwalten."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/developer/terraform/get-started/store-state-in-azure-storage",
      "id": "az400-150"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure service is designed for cloud-based container image builds that can also react to base image updates?",
        "de": "Welcher Azure-Dienst ist für cloudbasierte Container-Image-Builds vorgesehen und kann auch auf Aktualisierungen von Basis-Images reagieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Azure Container Registry Tasks",
            "de": "Azure Container Registry Tasks"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Azure Boards",
            "de": "Azure Boards"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Azure Policy",
            "de": "Azure Policy"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Azure Key Vault",
            "de": "Azure Key Vault"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Azure Container Registry Tasks is correct because it builds container images in the registry service and supports trigger-based rebuilds. It best meets the requirement to offload image builds and react to base image changes.",
        "de": "Azure Container Registry Tasks ist richtig, weil es baut Container-Images im Registry-Dienst und unterstützt triggerbasierte Rebuilds. Damit wird die Anforderung am besten erfüllt, Image-Builds auszulagern und auf Basis-Image-Änderungen zu reagieren."
      },
      "hint": {
        "en": "Focus on the need to offload image builds and react to base image changes.",
        "de": "Achten Sie auf die Anforderung, Image-Builds auszulagern und auf Basis-Image-Änderungen zu reagieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-overview",
      "id": "az400-151"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The platform team wants a standard way to package, parameterize, and roll back AKS application releases.",
        "de": "Das Plattformteam möchte eine standardisierte Möglichkeit, AKS-Anwendungsreleases zu paketieren, zu parametrisieren und zurückzusetzen."
      },
      "question": {
        "en": "Which packaging technology is best when you want a versioned Kubernetes application package with templating and rollback support?",
        "de": "Welche Paketierungstechnologie ist am besten geeignet, wenn Sie ein versioniertes Kubernetes-Anwendungspaket mit Templating und Rollback-Unterstützung benötigen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Helm charts",
            "de": "Helm-Charts"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Azure Boards queries",
            "de": "Azure-Boards-Abfragen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git stash entries",
            "de": "Git-Stash-Einträge"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Repository wikis",
            "de": "Repository-Wikis"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Helm charts is correct because they package Kubernetes resources, values, and release versions together. It best meets the requirement to manage versioned Kubernetes application releases.",
        "de": "Helm-Charts ist richtig, weil sie paketieren Kubernetes-Ressourcen, Werte und Release-Versionen gemeinsam. Damit wird die Anforderung am besten erfüllt, versionierte Kubernetes-Anwendungsreleases zu verwalten."
      },
      "hint": {
        "en": "Focus on the need to manage versioned Kubernetes application releases.",
        "de": "Achten Sie auf die Anforderung, versionierte Kubernetes-Anwendungsreleases zu verwalten."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/aks/kubernetes-helm",
      "id": "az400-152"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "When should you prefer a self-hosted Azure DevOps agent over a Microsoft-hosted agent?",
        "de": "Wann sollten Sie einen selbstgehosteten Azure-DevOps-Agenten einem Microsoft-gehosteten Agenten vorziehen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "When the build must access private network resources",
            "de": "Wenn der Build auf Ressourcen in einem privaten Netzwerk zugreifen muss"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "When you want fewer permissions in Azure Boards",
            "de": "Wenn Sie weniger Berechtigungen in Azure Boards möchten"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "When you need a wiki page",
            "de": "Wenn Sie eine Wiki-Seite benötigen"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "When you want to rename a branch",
            "de": "Wenn Sie einen Branch umbenennen möchten"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A self-hosted agent for private network access is correct because it can reach internal resources and carry custom tools that hosted agents cannot access. It best meets the requirement to run builds that depend on private infrastructure.",
        "de": "Einen selbstgehosteten Agenten für privaten Netzwerkzugriff ist richtig, weil er kann interne Ressourcen erreichen und benutzerdefinierte Werkzeuge bereitstellen, auf die gehostete Agenten nicht zugreifen können. Damit wird die Anforderung am besten erfüllt, Builds auszuführen, die von privater Infrastruktur abhängen."
      },
      "hint": {
        "en": "Focus on the need to run builds that depend on private infrastructure.",
        "de": "Achten Sie auf die Anforderung, Builds auszuführen, die von privater Infrastruktur abhängen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops",
      "id": "az400-153"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps connection type should you create so a pipeline can deploy Azure resources with centrally managed authentication?",
        "de": "Welchen Azure-DevOps-Verbindungstyp sollten Sie erstellen, damit eine Pipeline Azure-Ressourcen mit zentral verwalteter Authentifizierung bereitstellen kann?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "An Azure Resource Manager service connection",
            "de": "Eine Azure-Resource-Manager-Serviceverbindung"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A Git submodule",
            "de": "Ein Git-Submodul"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A branch policy",
            "de": "Eine Branchrichtlinie"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A stakeholder account",
            "de": "Ein Stakeholder-Konto"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "An Azure Resource Manager service connection is correct because it stores and governs the pipeline's connection to Azure centrally. It best meets the requirement to let pipelines deploy into Azure securely.",
        "de": "Eine Azure-Resource-Manager-Serviceverbindung ist richtig, weil sie verwaltet und steuert die Verbindung der Pipeline zu Azure zentral. Damit wird die Anforderung am besten erfüllt, Pipelines eine sichere Bereitstellung in Azure zu ermöglichen."
      },
      "hint": {
        "en": "Focus on the need to let pipelines deploy into Azure securely.",
        "de": "Achten Sie auf die Anforderung, Pipelines eine sichere Bereitstellung in Azure zu ermöglichen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops",
      "id": "az400-154"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps resource type should you use when one pipeline must start automatically after another pipeline completes and then consume its artifacts?",
        "de": "Welchen Azure-DevOps-Ressourcentyp sollten Sie verwenden, wenn eine Pipeline automatisch nach Abschluss einer anderen Pipeline starten und deren Artefakte verwenden soll?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A pipeline resource trigger",
            "de": "Einen Pipeline-Resource-Trigger"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "An area path",
            "de": "Einen Area Path"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A wiki link",
            "de": "Einen Wiki-Link"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A Git hook",
            "de": "Einen Git-Hook"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A pipeline resource trigger is correct because it connects pipeline completion events and artifact consumption between pipelines. It best meets the requirement to chain pipelines together by completion and artifacts.",
        "de": "Einen Pipeline-Resource-Trigger ist richtig, weil er verbindet Pipeline-Abschlussereignisse und Artefaktkonsum zwischen Pipelines. Damit wird die Anforderung am besten erfüllt, Pipelines über Abschluss und Artefakte miteinander zu verketten."
      },
      "hint": {
        "en": "Focus on the need to chain pipelines together by completion and artifacts.",
        "de": "Achten Sie auf die Anforderung, Pipelines über Abschluss und Artefakte miteinander zu verketten."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/pipeline-triggers?view=azure-devops",
      "id": "az400-155"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": null,
      "question": {
        "en": "How should you reference a central YAML template repository from another Azure DevOps pipeline?",
        "de": "Wie sollten Sie ein zentrales YAML-Template-Repository aus einer anderen Azure-DevOps-Pipeline referenzieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Declare it under resources.repositories",
            "de": "Es unter resources.repositories deklarieren"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Put it in .gitignore",
            "de": "Es in .gitignore eintragen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Store it in a dashboard widget",
            "de": "Es in einem Dashboard-Widget speichern"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Convert it to a wiki attachment",
            "de": "Es in einen Wiki-Anhang umwandeln"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A repository resource declaration is correct because it lets the pipeline pull templates from another repository in a supported way. It best meets the requirement to consume shared YAML templates from another repository.",
        "de": "Eine Repository-Ressourcendeklaration ist richtig, weil sie ermöglicht es der Pipeline, Templates auf unterstützte Weise aus einem anderen Repository zu beziehen. Damit wird die Anforderung am besten erfüllt, gemeinsame YAML-Templates aus einem anderen Repository zu verwenden."
      },
      "hint": {
        "en": "Focus on the need to consume shared YAML templates from another repository.",
        "de": "Achten Sie auf die Anforderung, gemeinsame YAML-Templates aus einem anderen Repository zu verwenden."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops",
      "id": "az400-156"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps YAML property should you use to prevent a production stage from running unless the branch is main and earlier stages succeeded?",
        "de": "Welche Azure-DevOps-YAML-Eigenschaft sollten Sie verwenden, um zu verhindern, dass eine Produktions-Stage läuft, sofern der Branch nicht main ist und frühere Stages nicht erfolgreich waren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "condition",
            "de": "condition"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "displayName",
            "de": "displayName"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "pool",
            "de": "pool"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "workspace",
            "de": "workspace"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The condition property is correct because it allows stage execution rules based on branch and pipeline status. It best meets the requirement to gate stage execution based on branch and success state.",
        "de": "Die Eigenschaft condition ist richtig, weil sie erlaubt Ausführungsregeln für Stages basierend auf Branch und Pipeline-Status. Damit wird die Anforderung am besten erfüllt, die Stage-Ausführung anhand von Branch und Erfolgsstatus zu steuern."
      },
      "hint": {
        "en": "Focus on the need to gate stage execution based on branch and success state.",
        "de": "Achten Sie auf die Anforderung, die Stage-Ausführung anhand von Branch und Erfolgsstatus zu steuern."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops",
      "id": "az400-157"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "Your AKS rollout occasionally sends users to pods that have started but have not finished warming up.",
        "de": "Ihr AKS-Rollout leitet gelegentlich Benutzer an Pods weiter, die zwar gestartet sind, aber noch nicht vollständig hochgefahren sind."
      },
      "question": {
        "en": "Which Kubernetes configuration helps ensure new pods do not receive production traffic until the application is actually ready?",
        "de": "Welche Kubernetes-Konfiguration hilft sicherzustellen, dass neue Pods keinen Produktionsverkehr erhalten, bevor die Anwendung tatsächlich bereit ist?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Readiness probes",
            "de": "Readiness-Probes"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git tags",
            "de": "Git-Tags"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Merge queues",
            "de": "Merge Queues"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Readiness probes is correct because they signal when a pod is ready to accept traffic during rollout. It best meets the requirement to avoid sending traffic to unready pods.",
        "de": "Readiness-Probes ist richtig, weil sie signalisieren während des Rollouts, wann ein Pod bereit ist, Traffic anzunehmen. Damit wird die Anforderung am besten erfüllt, zu vermeiden, Traffic an nicht bereite Pods zu senden."
      },
      "hint": {
        "en": "Focus on the need to avoid sending traffic to unready pods.",
        "de": "Achten Sie auf die Anforderung, zu vermeiden, Traffic an nicht bereite Pods zu senden."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/aks/concepts-liveness-probe",
      "id": "az400-158"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps task should you use to pause a YAML pipeline and wait for a person to continue it?",
        "de": "Welche Azure-DevOps-Task sollten Sie verwenden, um eine YAML-Pipeline anzuhalten und auf die Fortsetzung durch eine Person zu warten?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "ManualValidation",
            "de": "ManualValidation"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "PublishBuildArtifacts",
            "de": "PublishBuildArtifacts"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "UseNode",
            "de": "UseNode"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "HelmInstaller",
            "de": "HelmInstaller"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The ManualValidation task is correct because it intentionally pauses the run for a human decision. It best meets the requirement to insert a manual checkpoint inside a YAML pipeline.",
        "de": "Die ManualValidation-Task ist richtig, weil sie pausiert den Lauf bewusst für eine menschliche Entscheidung. Damit wird die Anforderung am besten erfüllt, einen manuellen Kontrollpunkt in eine YAML-Pipeline einzufügen."
      },
      "hint": {
        "en": "Focus on the need to insert a manual checkpoint inside a YAML pipeline.",
        "de": "Achten Sie auf die Anforderung, einen manuellen Kontrollpunkt in eine YAML-Pipeline einzufügen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/manual-validation-v0?view=azure-pipelines",
      "id": "az400-159"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The same workflow deploys to test and production, but only production needs protected secrets and reviewer approval.",
        "de": "Derselbe Workflow stellt in Test und Produktion bereit, aber nur die Produktion benötigt geschützte Geheimnisse und Reviewer-Genehmigungen."
      },
      "question": {
        "en": "What should you use in GitHub Actions when production secrets and approvals must apply only to deployment jobs for the production target?",
        "de": "Was sollten Sie in GitHub Actions verwenden, wenn Produktionsgeheimnisse und Genehmigungen nur für Bereitstellungsjobs zum Produktionsziel gelten sollen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "An environment",
            "de": "Eine Umgebung"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A branch rename",
            "de": "Eine Branch-Umbenennung"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A release draft",
            "de": "Einen Release-Entwurf"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A discussion category",
            "de": "Eine Diskussionskategorie"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A GitHub Actions environment is correct because it scopes secrets and protection rules to a deployment target. It best meets the requirement to apply secrets and approvals only to production deployments.",
        "de": "Eine GitHub-Actions-Umgebung ist richtig, weil sie begrenzt Geheimnisse und Schutzregeln auf ein Bereitstellungsziel. Damit wird die Anforderung am besten erfüllt, Geheimnisse und Genehmigungen nur auf Produktionsdeployments anzuwenden."
      },
      "hint": {
        "en": "Focus on the need to apply secrets and approvals only to production deployments.",
        "de": "Achten Sie auf die Anforderung, Geheimnisse und Genehmigungen nur auf Produktionsdeployments anzuwenden."
      },
      "reference": "https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment",
      "id": "az400-160"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": null,
      "question": {
        "en": "Which two Azure DevOps components should you combine to load secrets from Azure Key Vault into many pipelines centrally?",
        "de": "Welche zwei Azure-DevOps-Komponenten sollten Sie kombinieren, um Geheimnisse zentral aus Azure Key Vault in viele Pipelines zu laden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A variable group linked to Key Vault",
            "de": "Eine mit Key Vault verknüpfte Variablengruppe"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A service connection authorized to the vault",
            "de": "Eine für den Vault autorisierte Serviceverbindung"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A Git tag",
            "de": "Einen Git-Tag"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "An area path",
            "de": "Einen Area Path"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "A Key Vault-linked variable group together with an authorized service connection is correct because they let pipelines retrieve centrally managed secrets at runtime. It best meets the requirement to share rotated secrets across pipelines without hardcoding them.",
        "de": "Eine mit Key Vault verknüpfte Variablengruppe zusammen mit einer autorisierten Serviceverbindung ist richtig, weil sie ermöglichen Pipelines, zentral verwaltete Geheimnisse zur Laufzeit abzurufen. Damit wird die Anforderung am besten erfüllt, rotierte Geheimnisse über Pipelines hinweg zu teilen, ohne sie fest einzutragen."
      },
      "hint": {
        "en": "Focus on the need to share rotated secrets across pipelines without hardcoding them.",
        "de": "Achten Sie auf die Anforderung, rotierte Geheimnisse über Pipelines hinweg zu teilen, ohne sie fest einzutragen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/library/link-variable-groups-to-key-vaults?view=azure-devops",
      "id": "az400-161"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "What is the best way to promote the exact same container image through test, staging, and production without rebuilding it?",
        "de": "Wie fördern Sie am besten exakt dasselbe Container-Image durch Test, Staging und Produktion, ohne es neu zu bauen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Promote the immutable image digest",
            "de": "Den unveränderlichen Image-Digest promoten"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Rebuild the image in every stage",
            "de": "Das Image in jeder Stage neu bauen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Retag source code commits only",
            "de": "Nur Quellcode-Commits neu taggen"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Copy Dockerfiles into each environment",
            "de": "Dockerfiles in jede Umgebung kopieren"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The immutable image digest is correct because it identifies the exact image content independent of mutable tags. It best meets the requirement to promote the identical tested artifact across environments.",
        "de": "Den unveränderlichen Image-Digest ist richtig, weil er identifiziert den exakten Image-Inhalt unabhängig von veränderbaren Tags. Damit wird die Anforderung am besten erfüllt, das identische getestete Artefakt durch die Umgebungen zu promoten."
      },
      "hint": {
        "en": "Focus on the need to promote the identical tested artifact across environments.",
        "de": "Achten Sie auf die Anforderung, das identische getestete Artefakt durch die Umgebungen zu promoten."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/container-registry/container-registry-concepts#manifest",
      "id": "az400-162"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps trigger setting helps reduce redundant pipeline runs on a busy branch by queuing recent changes together?",
        "de": "Welche Azure-DevOps-Trigger-Einstellung hilft, redundante Pipeline-Läufe auf einem stark genutzten Branch zu reduzieren, indem aktuelle Änderungen zusammengefasst werden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "batch: true",
            "de": "batch: true"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "pr: none",
            "de": "pr: none"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "workspace.clean: all",
            "de": "workspace.clean: all"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "checkout: none",
            "de": "checkout: none"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The batch setting is correct because it combines incoming changes while a run is already in progress. It best meets the requirement to avoid excessive duplicate runs on an active branch.",
        "de": "Die Batch-Einstellung ist richtig, weil sie fasst eingehende Änderungen zusammen, während bereits ein Lauf aktiv ist. Damit wird die Anforderung am besten erfüllt, übermäßige doppelte Läufe auf einem aktiven Branch zu vermeiden."
      },
      "hint": {
        "en": "Focus on the need to avoid excessive duplicate runs on an active branch.",
        "de": "Achten Sie auf die Anforderung, übermäßige doppelte Läufe auf einem aktiven Branch zu vermeiden."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/trigger?view=azure-pipelines",
      "id": "az400-163"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "Operations wants a clear record of every staging and production deployment without relying on manual spreadsheets.",
        "de": "Der Betrieb möchte eine klare Historie jeder Staging- und Produktionsbereitstellung, ohne sich auf manuelle Tabellen zu verlassen."
      },
      "question": {
        "en": "Which two Azure DevOps YAML concepts should you use when you want deployment history recorded per target environment and environment-level checks applied automatically?",
        "de": "Welche zwei Azure-DevOps-YAML-Konzepte sollten Sie verwenden, wenn Bereitstellungshistorie pro Zielumgebung aufgezeichnet und umgebungsspezifische Prüfungen automatisch angewendet werden sollen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A deployment job",
            "de": "Einen Deployment-Job"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "An environment resource",
            "de": "Eine Umgebungsressource"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A wiki page",
            "de": "Eine Wiki-Seite"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A backlog level",
            "de": "Eine Backlog-Ebene"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "A deployment job together with an environment is correct because they attach releases, history, and checks to a named deployment target. It best meets the requirement to record deploy history and apply checks per environment.",
        "de": "Einen Deployment-Job zusammen mit einer Umgebung ist richtig, weil sie verknüpfen Releases, Historie und Prüfungen mit einem benannten Bereitstellungsziel. Damit wird die Anforderung am besten erfüllt, Bereitstellungshistorie aufzuzeichnen und Prüfungen pro Umgebung anzuwenden."
      },
      "hint": {
        "en": "Focus on the need to record deploy history and apply checks per environment.",
        "de": "Achten Sie auf die Anforderung, Bereitstellungshistorie aufzuzeichnen und Prüfungen pro Umgebung anzuwenden."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops",
      "id": "az400-164"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps mechanism lets one job expose a value that later jobs can consume in the same pipeline?",
        "de": "Welcher Azure-DevOps-Mechanismus erlaubt es einem Job, einen Wert bereitzustellen, den spätere Jobs in derselben Pipeline verwenden können?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Output variables",
            "de": "Output-Variablen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Branch renaming",
            "de": "Branch-Umbenennung"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Merge queues",
            "de": "Merge Queues"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Output variables is correct because they carry computed values from one job boundary to another. It best meets the requirement to pass dynamic values between jobs.",
        "de": "Output-Variablen ist richtig, weil sie transportieren berechnete Werte von einer Job-Grenze zur nächsten. Damit wird die Anforderung am besten erfüllt, dynamische Werte zwischen Jobs zu übergeben."
      },
      "hint": {
        "en": "Focus on the need to pass dynamic values between jobs.",
        "de": "Achten Sie auf die Anforderung, dynamische Werte zwischen Jobs zu übergeben."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/set-variables-scripts?view=azure-devops",
      "id": "az400-165"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which GitHub Actions reuse mechanism is best when you want to package a sequence of steps that can be called as one step inside a job?",
        "de": "Welcher GitHub-Actions-Wiederverwendungsmechanismus ist am besten, wenn Sie eine Folge von Schritten paketieren möchten, die als einzelner Schritt in einem Job aufgerufen werden kann?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A composite action",
            "de": "Eine Composite Action"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A protected branch",
            "de": "Ein geschützter Branch"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A release draft",
            "de": "Ein Release-Entwurf"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A discussion template",
            "de": "Ein Diskussionstemplate"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A composite action is correct because it bundles several steps behind one reusable action interface. It best meets the requirement to reuse a step sequence within jobs.",
        "de": "Eine Composite Action ist richtig, weil sie bündelt mehrere Schritte hinter einer wiederverwendbaren Action-Schnittstelle. Damit wird die Anforderung am besten erfüllt, eine Schrittfolge innerhalb von Jobs wiederzuverwenden."
      },
      "hint": {
        "en": "Focus on the need to reuse a step sequence within jobs.",
        "de": "Achten Sie auf die Anforderung, eine Schrittfolge innerhalb von Jobs wiederzuverwenden."
      },
      "reference": "https://docs.github.com/en/actions/creating-actions/creating-a-composite-action",
      "id": "az400-166"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps YAML keyword should you use to define validation runs for pull requests?",
        "de": "Welches Azure-DevOps-YAML-Schlüsselwort sollten Sie verwenden, um Validierungsläufe für Pull Requests zu definieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "pr",
            "de": "pr"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "workspace",
            "de": "workspace"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "pool",
            "de": "pool"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "extends",
            "de": "extends"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The pr trigger is correct because it configures pipeline execution in response to pull request activity. It best meets the requirement to run validation on pull requests.",
        "de": "Den pr-Trigger ist richtig, weil er konfiguriert die Pipelineausführung als Reaktion auf Pull-Request-Aktivität. Damit wird die Anforderung am besten erfüllt, Validierung bei Pull Requests auszuführen."
      },
      "hint": {
        "en": "Focus on the need to run validation on pull requests.",
        "de": "Achten Sie auf die Anforderung, Validierung bei Pull Requests auszuführen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops",
      "id": "az400-167"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which GitHub Actions capability should you use to restore dependencies quickly based on a cache key such as a lock file hash?",
        "de": "Welche GitHub-Actions-Funktion sollten Sie verwenden, um Abhängigkeiten schnell auf Basis eines Cache-Schlüssels wie eines Lockfile-Hashs wiederherzustellen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "actions/cache",
            "de": "actions/cache"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "workflow_dispatch",
            "de": "workflow_dispatch"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "CODEOWNERS",
            "de": "CODEOWNERS"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "GitHub Discussions",
            "de": "GitHub Discussions"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "actions/cache is correct because it saves and restores files between workflow runs using explicit keys. It best meets the requirement to speed up repeated dependency installation.",
        "de": "actions/cache ist richtig, weil es speichert und stellt Dateien zwischen Workflow-Läufen anhand expliziter Schlüssel wieder her. Damit wird die Anforderung am besten erfüllt, wiederholte Abhängigkeitsinstallationen zu beschleunigen."
      },
      "hint": {
        "en": "Focus on the need to speed up repeated dependency installation.",
        "de": "Achten Sie auf die Anforderung, wiederholte Abhängigkeitsinstallationen zu beschleunigen."
      },
      "reference": "https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows",
      "id": "az400-168"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "Only hardened build servers may deploy to the payment environment.",
        "de": "Nur gehärtete Build-Server dürfen in die Zahlungsumgebung bereitstellen."
      },
      "question": {
        "en": "What should you configure when regulated deployment jobs must run only on a dedicated set of self-hosted machines?",
        "de": "Was sollten Sie konfigurieren, wenn regulierte Bereitstellungsjobs nur auf einer dedizierten Menge selbstgehosteter Maschinen laufen dürfen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A dedicated agent pool",
            "de": "Einen dedizierten Agent-Pool"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "An area path",
            "de": "Einen Area Path"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A wiki page",
            "de": "Eine Wiki-Seite"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A Git tag",
            "de": "Einen Git-Tag"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A dedicated agent pool is correct because it isolates eligible agents for specific workloads and controls which pipelines can use them. It best meets the requirement to isolate sensitive jobs to approved agents.",
        "de": "Einen dedizierten Agent-Pool ist richtig, weil er isoliert geeignete Agenten für bestimmte Workloads und steuert, welche Pipelines sie verwenden dürfen. Damit wird die Anforderung am besten erfüllt, sensible Jobs auf freigegebene Agenten zu isolieren."
      },
      "hint": {
        "en": "Focus on the need to isolate sensitive jobs to approved agents.",
        "de": "Achten Sie auf die Anforderung, sensible Jobs auf freigegebene Agenten zu isolieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops",
      "id": "az400-169"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The integration tests need a local Docker daemon and access to internal test services.",
        "de": "Die Integrationstests benötigen einen lokalen Docker-Daemon und Zugriff auf interne Testservices."
      },
      "question": {
        "en": "Why would a team choose a self-hosted Linux agent for container integration tests instead of a Microsoft-hosted runner?",
        "de": "Warum würde sich ein Team für einen selbstgehosteten Linux-Agenten für Container-Integrationstests statt für einen Microsoft-gehosteten Runner entscheiden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "It can provide required Docker or network capabilities inside the team's environment",
            "de": "Er kann die erforderlichen Docker- oder Netzwerkfähigkeiten innerhalb der Teamumgebung bereitstellen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "It automatically creates Azure Boards items",
            "de": "Er erstellt automatisch Azure-Boards-Arbeitselemente"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "It removes the need for YAML",
            "de": "Er beseitigt die Notwendigkeit von YAML"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "It encrypts Git history",
            "de": "Er verschlüsselt die Git-Historie"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A self-hosted agent with the required environment is correct because it can expose privileged runtimes, private endpoints, or custom tools unavailable on hosted runners. It best meets the requirement to run specialized container tests in a controlled environment.",
        "de": "Einen selbstgehosteten Agenten mit der erforderlichen Umgebung ist richtig, weil er kann privilegierte Laufzeiten, private Endpunkte oder benutzerdefinierte Werkzeuge bereitstellen, die auf gehosteten Runnern nicht verfügbar sind. Damit wird die Anforderung am besten erfüllt, spezialisierte Container-Tests in einer kontrollierten Umgebung auszuführen."
      },
      "hint": {
        "en": "Focus on the need to run specialized container tests in a controlled environment.",
        "de": "Achten Sie auf die Anforderung, spezialisierte Container-Tests in einer kontrollierten Umgebung auszuführen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops",
      "id": "az400-170"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "How should you manage environment-specific Helm configuration while keeping one reusable chart?",
        "de": "Wie sollten Sie umgebungsspezifische Helm-Konfigurationen verwalten und dabei nur ein wiederverwendbares Chart behalten?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Use separate values files per environment",
            "de": "Separate Values-Dateien pro Umgebung verwenden"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Copy the chart into a new repository per environment",
            "de": "Das Chart für jede Umgebung in ein neues Repository kopieren"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Store values in Git tags only",
            "de": "Werte nur in Git-Tags speichern"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Replace Helm with wiki pages",
            "de": "Helm durch Wiki-Seiten ersetzen"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Separate values files with one shared chart is correct because they let one chart definition be parameterized per environment. It best meets the requirement to avoid duplicating Helm chart logic across environments.",
        "de": "Separate Values-Dateien mit einem gemeinsamen Chart ist richtig, weil sie erlauben, ein Chart pro Umgebung zu parametrisieren. Damit wird die Anforderung am besten erfüllt, die Duplizierung von Helm-Chart-Logik über Umgebungen hinweg zu vermeiden."
      },
      "hint": {
        "en": "Focus on the need to avoid duplicating Helm chart logic across environments.",
        "de": "Achten Sie auf die Anforderung, die Duplizierung von Helm-Chart-Logik über Umgebungen hinweg zu vermeiden."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/aks/kubernetes-helm",
      "id": "az400-171"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps task should you add before npm install when a self-hosted pipeline must authenticate to a private Azure Artifacts npm feed?",
        "de": "Welche Azure-DevOps-Task sollten Sie vor npm install hinzufügen, wenn sich eine selbstgehostete Pipeline an einem privaten Azure-Artifacts-npm-Feed authentifizieren muss?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "npmAuthenticate",
            "de": "npmAuthenticate"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "ManualValidation",
            "de": "ManualValidation"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "HelmDeploy",
            "de": "HelmDeploy"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "PublishSymbols",
            "de": "PublishSymbols"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The npmAuthenticate task is correct because it injects feed authentication into the npm configuration used by the job. It best meets the requirement to authenticate npm to a private Azure Artifacts feed.",
        "de": "Die npmAuthenticate-Task ist richtig, weil sie fügt der vom Job verwendeten npm-Konfiguration die Feed-Authentifizierung hinzu. Damit wird die Anforderung am besten erfüllt, npm gegenüber einem privaten Azure-Artifacts-Feed zu authentifizieren."
      },
      "hint": {
        "en": "Focus on the need to authenticate npm to a private Azure Artifacts feed.",
        "de": "Achten Sie auf die Anforderung, npm gegenüber einem privaten Azure-Artifacts-Feed zu authentifizieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/npm-authenticate-v0?view=azure-pipelines",
      "id": "az400-172"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "Production deployment must wait if the platform is already degraded.",
        "de": "Die Produktionsbereitstellung muss warten, wenn die Plattform bereits degradiert ist."
      },
      "question": {
        "en": "Which Azure DevOps check should you use if a deployment must be blocked whenever a related Azure Monitor alert is active?",
        "de": "Welche Azure-DevOps-Prüfung sollten Sie verwenden, wenn eine Bereitstellung blockiert werden muss, sobald ein zugehöriger Azure-Monitor-Alert aktiv ist?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "An Azure Monitor query or alert check",
            "de": "Eine Azure-Monitor-Abfrage- oder Alert-Prüfung"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A Git stash",
            "de": "Ein Git Stash"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A PR template",
            "de": "Ein PR-Template"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A cumulative flow chart",
            "de": "Ein kumulatives Flussdiagramm"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "An Azure Monitor environment check is correct because it integrates live health signals into deployment gating. It best meets the requirement to gate deployment on observed platform health.",
        "de": "Eine Azure-Monitor-Umgebungsprüfung ist richtig, weil sie integriert aktuelle Health-Signale in die Deployment-Governance. Damit wird die Anforderung am besten erfüllt, Bereitstellungen anhand beobachteter Plattform-Health zu steuern."
      },
      "hint": {
        "en": "Focus on the need to gate deployment on observed platform health.",
        "de": "Achten Sie auf die Anforderung, Bereitstellungen anhand beobachteter Plattform-Health zu steuern."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops#azure-monitor-alerts",
      "id": "az400-173"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Bicep feature should you use to publish and consume versioned infrastructure modules centrally?",
        "de": "Welche Bicep-Funktion sollten Sie verwenden, um versionierte Infrastrukturmodule zentral zu veröffentlichen und zu konsumieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "A private module registry",
            "de": "Eine private Modul-Registry"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A wiki repository",
            "de": "Ein Wiki-Repository"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A deployment slot",
            "de": "Einen Bereitstellungsslot"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A Git hook",
            "de": "Einen Git-Hook"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A private Bicep module registry is correct because it stores reusable modules with explicit version references. It best meets the requirement to share approved Bicep modules centrally.",
        "de": "Eine private Bicep-Modul-Registry ist richtig, weil sie speichert wiederverwendbare Module mit expliziten Versionsverweisen. Damit wird die Anforderung am besten erfüllt, freigegebene Bicep-Module zentral bereitzustellen."
      },
      "hint": {
        "en": "Focus on the need to share approved Bicep modules centrally.",
        "de": "Achten Sie auf die Anforderung, freigegebene Bicep-Module zentral bereitzustellen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/private-module-registry",
      "id": "az400-174"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "A Bicep deployment creates an App Service URL that the application smoke tests need in the next stage.",
        "de": "Eine Bicep-Bereitstellung erzeugt eine App-Service-URL, die die Smoke-Tests der Anwendung in der nächsten Stage benötigen."
      },
      "question": {
        "en": "Which Azure DevOps feature should you use to capture outputs from an infrastructure deployment and pass them to later application deployment steps?",
        "de": "Welche Azure-DevOps-Funktion sollten Sie verwenden, um Ausgaben einer Infrastruktur-Bereitstellung zu erfassen und an spätere Schritte der Anwendungsbereitstellung zu übergeben?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Set pipeline variables from deployment outputs",
            "de": "Pipeline-Variablen aus Deployment-Ausgaben setzen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Rename the stage",
            "de": "Die Stage umbenennen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Use a wiki page",
            "de": "Eine Wiki-Seite verwenden"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Add a CODEOWNERS file",
            "de": "Eine CODEOWNERS-Datei hinzufügen"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Pipeline variables derived from deployment outputs is correct because they expose infrastructure-created values such as resource names or endpoints to later tasks. It best meets the requirement to reuse infrastructure outputs in later pipeline steps.",
        "de": "Pipeline-Variablen aus Deployment-Ausgaben ist richtig, weil sie machen von der Infrastruktur erzeugte Werte wie Ressourcennamen oder Endpunkte für spätere Tasks verfügbar. Damit wird die Anforderung am besten erfüllt, Infrastruktur-Ausgaben in späteren Pipelineschritten wiederzuverwenden."
      },
      "hint": {
        "en": "Focus on the need to reuse infrastructure outputs in later pipeline steps.",
        "de": "Achten Sie auf die Anforderung, Infrastruktur-Ausgaben in späteren Pipelineschritten wiederzuverwenden."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/process/set-variables-scripts?view=azure-devops",
      "id": "az400-175"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which GitHub Actions trigger should you use for a nightly compliance scan that runs even when no one pushes code?",
        "de": "Welchen GitHub-Actions-Trigger sollten Sie für einen nächtlichen Compliance-Scan verwenden, der auch ohne Code-Push laufen soll?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "schedule",
            "de": "schedule"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "pull_request",
            "de": "pull_request"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "push",
            "de": "push"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "workflow_run",
            "de": "workflow_run"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The schedule trigger is correct because it runs workflows on a cron schedule independent of repository events. It best meets the requirement to run a workflow on a fixed recurring schedule.",
        "de": "Den schedule-Trigger ist richtig, weil er führt Workflows per Cron-Zeitplan unabhängig von Repository-Ereignissen aus. Damit wird die Anforderung am besten erfüllt, einen Workflow nach einem festen wiederkehrenden Zeitplan auszuführen."
      },
      "hint": {
        "en": "Focus on the need to run a workflow on a fixed recurring schedule.",
        "de": "Achten Sie auf die Anforderung, einen Workflow nach einem festen wiederkehrenden Zeitplan auszuführen."
      },
      "reference": "https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule",
      "id": "az400-176"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which GitHub Actions trigger is best when you want operators to start a deployment manually and choose input values such as region or version?",
        "de": "Welcher GitHub-Actions-Trigger ist am besten geeignet, wenn Operatoren eine Bereitstellung manuell starten und Eingabewerte wie Region oder Version wählen sollen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "workflow_dispatch",
            "de": "workflow_dispatch"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "fork",
            "de": "fork"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "watch",
            "de": "watch"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "gollum",
            "de": "gollum"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "workflow_dispatch is correct because it exposes a manual workflow entry point with user-provided inputs. It best meets the requirement to start a workflow manually with parameters.",
        "de": "workflow_dispatch ist richtig, weil es stellt einen manuellen Einstiegspunkt für Workflows mit benutzerdefinierten Eingaben bereit. Damit wird die Anforderung am besten erfüllt, einen Workflow manuell mit Parametern zu starten."
      },
      "hint": {
        "en": "Focus on the need to start a workflow manually with parameters.",
        "de": "Achten Sie auf die Anforderung, einen Workflow manuell mit Parametern zu starten."
      },
      "reference": "https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch",
      "id": "az400-177"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure DevOps agent feature should you use when a job must run only on agents that advertise a specific installed tool or capability?",
        "de": "Welche Azure-DevOps-Agent-Funktion sollten Sie verwenden, wenn ein Job nur auf Agenten laufen darf, die ein bestimmtes installiertes Werkzeug oder eine bestimmte Fähigkeit ausweisen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Demands",
            "de": "Demands"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Release tags",
            "de": "Release-Tags"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Work item states",
            "de": "Arbeitselementstatus"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Demands is correct because they filter eligible agents based on declared capabilities. It best meets the requirement to target jobs to agents with a required capability.",
        "de": "Demands ist richtig, weil sie filtern geeignete Agenten anhand deklarierter Fähigkeiten. Damit wird die Anforderung am besten erfüllt, Jobs auf Agenten mit einer erforderlichen Fähigkeit zu lenken."
      },
      "hint": {
        "en": "Focus on the need to target jobs to agents with a required capability.",
        "de": "Achten Sie auf die Anforderung, Jobs auf Agenten mit einer erforderlichen Fähigkeit zu lenken."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops",
      "id": "az400-178"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which App Service deployment feature should you use for zero-downtime swaps and quick rollback between current and new versions?",
        "de": "Welche App-Service-Bereitstellungsfunktion sollten Sie für Zero-Downtime-Swaps und schnelles Rollback zwischen aktueller und neuer Version verwenden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Deployment slots",
            "de": "Bereitstellungsslots"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git stashes",
            "de": "Git Stashes"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Code owners",
            "de": "Code Owner"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Deployment slots is correct because they let you warm up a new version separately and then swap traffic. It best meets the requirement to swap web app versions with minimal downtime.",
        "de": "Bereitstellungsslots ist richtig, weil sie ermöglichen es, eine neue Version separat aufzuwärmen und anschließend den Traffic umzuschalten. Damit wird die Anforderung am besten erfüllt, Web-App-Versionen mit minimaler Downtime umzuschalten."
      },
      "hint": {
        "en": "Focus on the need to swap web app versions with minimal downtime.",
        "de": "Achten Sie auf die Anforderung, Web-App-Versionen mit minimaler Downtime umzuschalten."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots",
      "id": "az400-179"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure Artifacts package type is designed for distributing arbitrary versioned build outputs such as tools, scripts, or configuration bundles?",
        "de": "Welcher Azure-Artifacts-Pakettyp ist für die Verteilung beliebiger versionierter Build-Ausgaben wie Tools, Skripte oder Konfigurationsbündel vorgesehen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Universal Packages",
            "de": "Universal Packages"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Work item links",
            "de": "Arbeitselementverknüpfungen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Branch policies",
            "de": "Branchrichtlinien"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Delivery Plans",
            "de": "Delivery Plans"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Universal Packages is correct because they package generic files with versioning in Azure Artifacts. It best meets the requirement to distribute versioned non-language-specific build output.",
        "de": "Universal Packages ist richtig, weil sie paketieren allgemeine Dateien mit Versionierung in Azure Artifacts. Damit wird die Anforderung am besten erfüllt, versionierte, nicht sprachspezifische Build-Ausgaben zu verteilen."
      },
      "hint": {
        "en": "Focus on the need to distribute versioned non-language-specific build output.",
        "de": "Achten Sie auf die Anforderung, versionierte, nicht sprachspezifische Build-Ausgaben zu verteilen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/devops/artifacts/quickstarts/universal-packages?view=azure-devops",
      "id": "az400-180"
    },
    {
      "type": "single",
      "domain": {
        "en": "Design and Implement Build and Release Pipelines",
        "de": "Build- und Release-Pipelines entwerfen und implementieren"
      },
      "difficulty": "easy",
      "scenario": {
        "en": "The team wants to guarantee that no image is published until the test job has passed.",
        "de": "Das Team möchte sicherstellen, dass kein Image veröffentlicht wird, bevor der Testjob erfolgreich war."
      },
      "question": {
        "en": "Which GitHub Actions job keyword makes a deployment job wait for a build job to finish successfully first?",
        "de": "Welches GitHub-Actions-Job-Schlüsselwort sorgt dafür, dass ein Bereitstellungsjob zuerst auf den erfolgreichen Abschluss eines Build-Jobs wartet?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "needs",
            "de": "needs"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "uses",
            "de": "uses"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "with",
            "de": "with"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "env",
            "de": "env"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The needs keyword is correct because it declares job dependencies inside the workflow graph. It best meets the requirement to ensure deployment starts only after required jobs succeed.",
        "de": "Das Schlüsselwort needs ist richtig, weil es deklariert Job-Abhängigkeiten innerhalb des Workflow-Graphen. Damit wird die Anforderung am besten erfüllt, sicherzustellen, dass die Bereitstellung erst startet, nachdem erforderliche Jobs erfolgreich waren."
      },
      "hint": {
        "en": "Focus on the need to ensure deployment starts only after required jobs succeed.",
        "de": "Achten Sie auf die Anforderung, sicherzustellen, dass die Bereitstellung erst startet, nachdem erforderliche Jobs erfolgreich waren."
      },
      "reference": "https://docs.github.com/en/actions/using-jobs/using-jobs-in-a-workflow",
      "id": "az400-181"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "Developers occasionally paste cloud keys into configuration files by mistake, and security wants prevention rather than later cleanup.",
        "de": "Entwickler fügen gelegentlich versehentlich Cloud-Schlüssel in Konfigurationsdateien ein, und die Sicherheit möchte Prävention statt späterer Bereinigung."
      },
      "question": {
        "en": "Which GitHub feature can block a developer from pushing a known secret pattern to a repository in the first place?",
        "de": "Welche GitHub-Funktion kann einen Entwickler bereits daran hindern, ein bekanntes Secret-Muster in ein Repository zu pushen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Secret scanning push protection",
            "de": "Push Protection für Secret Scanning"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A wiki page",
            "de": "Eine Wiki-Seite"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git stash",
            "de": "Git Stash"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A merge queue",
            "de": "Eine Merge Queue"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Secret scanning push protection is correct because it detects supported secret patterns and stops the push before the secret lands. It best meets the requirement to prevent leaked credentials from entering the repository.",
        "de": "Push Protection für Secret Scanning ist richtig, weil sie erkennt unterstützte Secret-Muster und stoppt den Push, bevor das Secret landet. Damit wird die Anforderung am besten erfüllt, zu verhindern, dass geleakte Zugangsdaten ins Repository gelangen."
      },
      "hint": {
        "en": "Focus on the need to prevent leaked credentials from entering the repository.",
        "de": "Achten Sie auf die Anforderung, zu verhindern, dass geleakte Zugangsdaten ins Repository gelangen."
      },
      "reference": "https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning",
      "id": "az400-182"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which two Dependabot capabilities help a repository stay current on open-source dependencies?",
        "de": "Welche zwei Dependabot-Funktionen helfen einem Repository, bei Open-Source-Abhängigkeiten aktuell zu bleiben?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Dependency alerts",
            "de": "Abhängigkeitswarnungen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Version update pull requests",
            "de": "Pull Requests für Versionsupdates"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Area path inheritance",
            "de": "Area-Path-Vererbung"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Manual validation tasks",
            "de": "Manual-Validation-Tasks"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Dependabot alerts together with version update pull requests is correct because they surface vulnerable packages and automate the update workflow. It best meets the requirement to identify and remediate outdated dependencies faster.",
        "de": "Dependabot-Warnungen zusammen mit Pull Requests für Versionsupdates ist richtig, weil sie machen anfällige Pakete sichtbar und automatisieren den Update-Workflow. Damit wird die Anforderung am besten erfüllt, veraltete Abhängigkeiten schneller zu identifizieren und zu beheben."
      },
      "hint": {
        "en": "Focus on the need to identify and remediate outdated dependencies faster.",
        "de": "Achten Sie auf die Anforderung, veraltete Abhängigkeiten schneller zu identifizieren und zu beheben."
      },
      "reference": "https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates",
      "id": "az400-183"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which GitHub Advanced Security capability should you enable to analyze code for common vulnerability patterns such as injection issues?",
        "de": "Welche GitHub-Advanced-Security-Funktion sollten Sie aktivieren, um Code auf häufige Schwachstellenmuster wie Injection-Probleme zu analysieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Code scanning with CodeQL",
            "de": "Code-Scanning mit CodeQL"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Project wiki",
            "de": "Projekt-Wiki"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git LFS",
            "de": "Git LFS"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Issue forms",
            "de": "Issue Forms"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Code scanning with CodeQL is correct because it performs static analysis against security queries for supported languages. It best meets the requirement to find code vulnerabilities during development.",
        "de": "Code-Scanning mit CodeQL ist richtig, weil es führt statische Analysen mit Sicherheitsabfragen für unterstützte Sprachen durch. Damit wird die Anforderung am besten erfüllt, Code-Schwachstellen während der Entwicklung zu finden."
      },
      "hint": {
        "en": "Focus on the need to find code vulnerabilities during development.",
        "de": "Achten Sie auf die Anforderung, Code-Schwachstellen während der Entwicklung zu finden."
      },
      "reference": "https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql",
      "id": "az400-184"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "What should you use between GitHub Actions and Azure when security policy forbids storing long-lived service principal secrets?",
        "de": "Was sollten Sie zwischen GitHub Actions und Azure verwenden, wenn die Sicherheitsrichtlinie das Speichern langlebiger Service-Principal-Secrets verbietet?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "OIDC federation with federated credentials",
            "de": "OIDC-Föderation mit föderierten Anmeldeinformationen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A shared admin password",
            "de": "Ein gemeinsames Admin-Passwort"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A PAT stored in code",
            "de": "Ein im Code gespeichertes PAT"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Anonymous access",
            "de": "Anonymer Zugriff"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "OIDC federation is correct because it replaces stored credentials with short-lived token exchange. It best meets the requirement to authenticate CI to Azure without long-lived secrets.",
        "de": "OIDC-Föderation ist richtig, weil sie ersetzt gespeicherte Anmeldedaten durch den Austausch kurzlebiger Tokens. Damit wird die Anforderung am besten erfüllt, CI gegenüber Azure ohne langlebige Geheimnisse zu authentifizieren."
      },
      "hint": {
        "en": "Focus on the need to authenticate CI to Azure without long-lived secrets.",
        "de": "Achten Sie auf die Anforderung, CI gegenüber Azure ohne langlebige Geheimnisse zu authentifizieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure-openid-connect",
      "id": "az400-185"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "The architecture board wants no manual exceptions for new code smells, low coverage, or critical vulnerabilities.",
        "de": "Das Architekturboard möchte keine manuellen Ausnahmen für neue Code Smells, geringe Testabdeckung oder kritische Schwachstellen."
      },
      "question": {
        "en": "Which two controls should you combine if SonarCloud or SonarQube quality gates must stop low-quality code from being merged?",
        "de": "Welche zwei Kontrollen sollten Sie kombinieren, wenn SonarCloud- oder SonarQube-Quality-Gates verhindern sollen, dass minderwertiger Code gemergt wird?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Run Sonar analysis in CI",
            "de": "Sonar-Analyse in CI ausführen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Require the quality gate status check before merge",
            "de": "Den Statuscheck des Quality Gates vor dem Merge verlangen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Disable pull requests",
            "de": "Pull Requests deaktivieren"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Store metrics in a wiki only",
            "de": "Metriken nur in einem Wiki speichern"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "CI-based Sonar analysis together with a required quality gate check is correct because they evaluate code quality and enforce the result through repository policy. It best meets the requirement to block merges when code quality gates fail.",
        "de": "CI-basierte Sonar-Analyse zusammen mit einem verpflichtenden Quality-Gate-Check ist richtig, weil sie bewerten die Codequalität und erzwingen das Ergebnis über Repository-Richtlinien. Damit wird die Anforderung am besten erfüllt, Merges zu blockieren, wenn Qualitätsprüfungen fehlschlagen."
      },
      "hint": {
        "en": "Focus on the need to block merges when code quality gates fail.",
        "de": "Achten Sie auf die Anforderung, Merges zu blockieren, wenn Qualitätsprüfungen fehlschlagen."
      },
      "reference": "https://docs.sonarsource.com/sonarqube-cloud/improving/pull-request-analysis/",
      "id": "az400-186"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Azure service should you use as the central store for secrets, certificates, and keys used by applications and pipelines?",
        "de": "Welchen Azure-Dienst sollten Sie als zentrale Ablage für Geheimnisse, Zertifikate und Schlüssel verwenden, die von Anwendungen und Pipelines genutzt werden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Azure Key Vault",
            "de": "Azure Key Vault"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Azure Boards",
            "de": "Azure Boards"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Azure DevTest Labs",
            "de": "Azure DevTest Labs"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Azure Policy",
            "de": "Azure Policy"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Azure Key Vault is correct because it is designed for controlled storage, rotation, and access to secrets and keys. It best meets the requirement to centralize sensitive values securely.",
        "de": "Azure Key Vault ist richtig, weil er ist für kontrollierte Speicherung, Rotation und Zugriff auf Geheimnisse und Schlüssel ausgelegt. Damit wird die Anforderung am besten erfüllt, sensible Werte sicher zu zentralisieren."
      },
      "hint": {
        "en": "Focus on the need to centralize sensitive values securely.",
        "de": "Achten Sie auf die Anforderung, sensible Werte sicher zu zentralisieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/key-vault/general/basic-concepts",
      "id": "az400-187"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The operations team wants the application to retrieve secrets dynamically but has forbidden connection strings with embedded credentials.",
        "de": "Das Betriebsteam möchte, dass die Anwendung Geheimnisse dynamisch abruft, hat jedoch Verbindungszeichenfolgen mit eingebetteten Zugangsdaten verboten."
      },
      "question": {
        "en": "Which Azure identity feature should an App Service use to read from Key Vault at runtime without storing credentials in configuration?",
        "de": "Welche Azure-Identitätsfunktion sollte ein App Service verwenden, um zur Laufzeit aus Key Vault zu lesen, ohne Zugangsdaten in der Konfiguration zu speichern?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Managed identity",
            "de": "Verwaltete Identität"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "PAT authentication",
            "de": "PAT-Authentifizierung"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A repository secret",
            "de": "Ein Repository-Secret"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "A shared local admin account",
            "de": "Ein gemeinsames lokales Administratorkonto"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Managed identity is correct because it gives the resource an Azure AD identity that can be granted access directly. It best meets the requirement to let an Azure resource call other Azure services without stored secrets.",
        "de": "Verwaltete Identität ist richtig, weil sie gibt der Ressource eine Azure-AD-Identität, der direkt Zugriff gewährt werden kann. Damit wird die Anforderung am besten erfüllt, einer Azure-Ressource den Aufruf anderer Azure-Dienste ohne gespeicherte Geheimnisse zu ermöglichen."
      },
      "hint": {
        "en": "Focus on the need to let an Azure resource call other Azure services without stored secrets.",
        "de": "Achten Sie auf die Anforderung, einer Azure-Ressource den Aufruf anderer Azure-Dienste ohne gespeicherte Geheimnisse zu ermöglichen."
      },
      "reference": "https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview",
      "id": "az400-188"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which two actions support a software supply chain requirement to produce and preserve an inventory of components used in each build?",
        "de": "Welche zwei Maßnahmen unterstützen die Anforderung der Software-Lieferkette, für jeden Build ein Inventar der verwendeten Komponenten zu erzeugen und aufzubewahren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Generate an SBOM during the build",
            "de": "Während des Builds ein SBOM erzeugen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Publish the SBOM with the build or release artifacts",
            "de": "Das SBOM mit den Build- oder Release-Artefakten veröffentlichen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Delete dependency manifests after packaging",
            "de": "Abhängigkeitsmanifeste nach dem Paketieren löschen"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Store the component list only in a chat thread",
            "de": "Die Komponentenliste nur in einem Chat-Thread speichern"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Generating and publishing an SBOM is correct because they create a bill of materials and keep it with the deliverable for audit and investigation. It best meets the requirement to retain component inventory for each released build.",
        "de": "Das Erzeugen und Veröffentlichen eines SBOM ist richtig, weil sie erzeugen ein Komponentenverzeichnis und bewahren es zusammen mit dem Auslieferungsobjekt für Audits und Untersuchungen auf. Damit wird die Anforderung am besten erfüllt, ein Komponenteninventar für jeden freigegebenen Build aufzubewahren."
      },
      "hint": {
        "en": "Focus on the need to retain component inventory for each released build.",
        "de": "Achten Sie auf die Anforderung, ein Komponenteninventar für jeden freigegebenen Build aufzubewahren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/security/fundamentals/supply-chain-security",
      "id": "az400-189"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure governance service should you use to deny noncompliant resource configurations during infrastructure deployments?",
        "de": "Welchen Azure-Governance-Dienst sollten Sie verwenden, um nicht konforme Ressourcenkonfigurationen während Infrastruktur-Bereitstellungen abzulehnen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Azure Policy",
            "de": "Azure Policy"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Azure Boards",
            "de": "Azure Boards"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git LFS",
            "de": "Git LFS"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Helm",
            "de": "Helm"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Azure Policy is correct because it evaluates resources against rules and can deny creations that violate governance standards. It best meets the requirement to enforce compliance rules automatically during deployment.",
        "de": "Azure Policy ist richtig, weil sie bewertet Ressourcen anhand von Regeln und kann Erstellungen ablehnen, die Governance-Standards verletzen. Damit wird die Anforderung am besten erfüllt, Compliance-Regeln während der Bereitstellung automatisch durchzusetzen."
      },
      "hint": {
        "en": "Focus on the need to enforce compliance rules automatically during deployment.",
        "de": "Achten Sie auf die Anforderung, Compliance-Regeln während der Bereitstellung automatisch durchzusetzen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/governance/policy/overview",
      "id": "az400-190"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The release pipeline must not promote images with known critical CVEs.",
        "de": "Die Release-Pipeline darf Images mit bekannten kritischen CVEs nicht promoten."
      },
      "question": {
        "en": "Which Azure security service can assess container images stored in Azure Container Registry for vulnerabilities before promotion?",
        "de": "Welcher Azure-Sicherheitsdienst kann in Azure Container Registry gespeicherte Container-Images vor der Promotion auf Schwachstellen prüfen?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Microsoft Defender for Cloud",
            "de": "Microsoft Defender for Cloud"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Azure Boards Analytics",
            "de": "Azure Boards Analytics"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git stash",
            "de": "Git Stash"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Delivery Plans",
            "de": "Delivery Plans"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Microsoft Defender for Cloud is correct because it includes vulnerability assessment capabilities for container registries and images. It best meets the requirement to scan registry images before promotion.",
        "de": "Microsoft Defender for Cloud ist richtig, weil es umfasst Funktionen zur Schwachstellenbewertung für Container-Registries und Images. Damit wird die Anforderung am besten erfüllt, Registry-Images vor der Promotion zu scannen."
      },
      "hint": {
        "en": "Focus on the need to scan registry images before promotion.",
        "de": "Achten Sie auf die Anforderung, Registry-Images vor der Promotion zu scannen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-container-registries-introduction",
      "id": "az400-191"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which GitHub Action is designed to summarize dependency risk in a pull request when package manifests change?",
        "de": "Welche GitHub-Action ist dafür vorgesehen, das Abhängigkeitsrisiko in einem Pull Request zusammenzufassen, wenn Paketmanifeste geändert werden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Dependency review action",
            "de": "Dependency-Review-Action"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "actions/cache",
            "de": "actions/cache"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "setup-node",
            "de": "setup-node"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "checkout",
            "de": "checkout"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "The dependency review action is correct because it analyzes dependency manifest changes and highlights introduced risk before merge. It best meets the requirement to review dependency impact in pull requests.",
        "de": "Die Dependency-Review-Action ist richtig, weil sie analysiert Änderungen an Abhängigkeitsmanifesten und macht eingeführte Risiken vor dem Merge sichtbar. Damit wird die Anforderung am besten erfüllt, die Auswirkungen von Abhängigkeitsänderungen in Pull Requests zu prüfen."
      },
      "hint": {
        "en": "Focus on the need to review dependency impact in pull requests.",
        "de": "Achten Sie auf die Anforderung, die Auswirkungen von Abhängigkeitsänderungen in Pull Requests zu prüfen."
      },
      "reference": "https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review",
      "id": "az400-192"
    },
    {
      "type": "single",
      "domain": {
        "en": "Develop a Security and Compliance Plan",
        "de": "Sicherheits- und Compliance-Plan entwickeln"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "A security review rejected the team's plan to store service principal secrets as Kubernetes secrets for every namespace.",
        "de": "Eine Sicherheitsprüfung hat den Plan des Teams abgelehnt, Service-Principal-Secrets als Kubernetes-Secrets für jeden Namespace zu speichern."
      },
      "question": {
        "en": "Which AKS identity approach should you prefer when pods need to access Azure resources without storing secrets in Kubernetes?",
        "de": "Welchen Identitätsansatz für AKS sollten Sie bevorzugen, wenn Pods auf Azure-Ressourcen zugreifen müssen, ohne Geheimnisse in Kubernetes zu speichern?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Microsoft Entra Workload ID",
            "de": "Microsoft Entra Workload ID"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "A shared service principal secret in a Kubernetes secret",
            "de": "Ein gemeinsames Service-Principal-Secret in einem Kubernetes-Secret"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "A PAT in ConfigMap",
            "de": "Ein PAT in einer ConfigMap"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Anonymous access from the cluster",
            "de": "Anonymer Zugriff aus dem Cluster"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Microsoft Entra Workload ID is correct because it maps Kubernetes service accounts to Azure identities without embedded secrets. It best meets the requirement to let AKS workloads access Azure securely without stored secrets.",
        "de": "Microsoft Entra Workload ID ist richtig, weil sie ordnet Kubernetes-Servicekonten Azure-Identitäten ohne eingebettete Geheimnisse zu. Damit wird die Anforderung am besten erfüllt, AKS-Workloads einen sicheren Azure-Zugriff ohne gespeicherte Geheimnisse zu ermöglichen."
      },
      "hint": {
        "en": "Focus on the need to let AKS workloads access Azure securely without stored secrets.",
        "de": "Achten Sie auf die Anforderung, AKS-Workloads einen sicheren Azure-Zugriff ohne gespeicherte Geheimnisse zu ermöglichen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview",
      "id": "az400-193"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "After each release, the team wants to compare telemetry before and after the change without relying on memory.",
        "de": "Nach jedem Release möchte das Team die Telemetrie vor und nach der Änderung vergleichen, ohne sich auf Erinnerungen zu verlassen."
      },
      "question": {
        "en": "Which Application Insights feature should you use so operators can correlate a deployment time with later spikes in failures or latency?",
        "de": "Welche Application-Insights-Funktion sollten Sie verwenden, damit Operatoren den Zeitpunkt einer Bereitstellung mit späteren Spitzen bei Fehlern oder Latenz korrelieren können?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Release annotations",
            "de": "Release-Anmerkungen"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git LFS",
            "de": "Git LFS"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Variable groups",
            "de": "Variablengruppen"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Release annotations is correct because they mark deployment events on telemetry timelines for easier correlation. It best meets the requirement to see deployment moments inside telemetry views.",
        "de": "Release-Anmerkungen ist richtig, weil sie markieren Bereitstellungsereignisse auf Telemetrie-Zeitachsen zur einfacheren Korrelation. Damit wird die Anforderung am besten erfüllt, Bereitstellungszeitpunkte in Telemetrieansichten zu sehen."
      },
      "hint": {
        "en": "Focus on the need to see deployment moments inside telemetry views.",
        "de": "Achten Sie auf die Anforderung, Bereitstellungszeitpunkte in Telemetrieansichten zu sehen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-monitor/app/annotations",
      "id": "az400-194"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which two Azure Monitor capabilities should you combine to build an interactive operational view that mixes charts, parameters, and log query results?",
        "de": "Welche zwei Azure-Monitor-Funktionen sollten Sie kombinieren, um eine interaktive Betriebsansicht zu erstellen, die Diagramme, Parameter und Logabfrageergebnisse mischt?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Workbooks",
            "de": "Workbooks"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "KQL queries",
            "de": "KQL-Abfragen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Branch policies",
            "de": "Branchrichtlinien"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Deployment groups",
            "de": "Bereitstellungsgruppen"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Workbooks together with KQL queries is correct because they let you compose parameterized operational reports from logs and metrics. It best meets the requirement to build an interactive observability view from operational data.",
        "de": "Workbooks zusammen mit KQL-Abfragen ist richtig, weil sie ermöglichen die Erstellung parametrisierter Betriebsberichte aus Logs und Metriken. Damit wird die Anforderung am besten erfüllt, eine interaktive Observability-Ansicht aus Betriebsdaten zu erstellen."
      },
      "hint": {
        "en": "Focus on the need to build an interactive observability view from operational data.",
        "de": "Achten Sie auf die Anforderung, eine interaktive Observability-Ansicht aus Betriebsdaten zu erstellen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-overview",
      "id": "az400-195"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which Azure Monitor alert type is best when you need near real-time notification that a metric such as CPU or response time crossed a threshold?",
        "de": "Welcher Azure-Monitor-Alert-Typ ist am besten geeignet, wenn Sie nahezu in Echtzeit benachrichtigt werden möchten, dass eine Metrik wie CPU oder Antwortzeit einen Schwellenwert überschritten hat?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Metric alert",
            "de": "Metrik-Alert"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Work item rule",
            "de": "Arbeitselementregel"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Branch policy",
            "de": "Branchrichtlinie"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Git tag",
            "de": "Git-Tag"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "A metric alert is correct because it evaluates platform metrics quickly against numeric thresholds. It best meets the requirement to alert on threshold breaches in metrics.",
        "de": "Ein Metrik-Alert ist richtig, weil er wertet Plattformmetriken schnell anhand numerischer Schwellenwerte aus. Damit wird die Anforderung am besten erfüllt, bei Schwellenwertüberschreitungen in Metriken zu alarmieren."
      },
      "hint": {
        "en": "Focus on the need to alert on threshold breaches in metrics.",
        "de": "Achten Sie auf die Anforderung, bei Schwellenwertüberschreitungen in Metriken zu alarmieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-metric-overview",
      "id": "az400-196"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "Product management wants to expose a new payment option to only a small audience first and turn it off instantly if needed.",
        "de": "Das Produktmanagement möchte eine neue Zahlungsoption zunächst nur einer kleinen Zielgruppe zeigen und sie bei Bedarf sofort deaktivieren können."
      },
      "question": {
        "en": "Which Azure service should you use for feature flags when you want to enable or disable functionality without redeploying the application?",
        "de": "Welchen Azure-Dienst sollten Sie für Feature Flags verwenden, wenn Sie Funktionen ohne erneute Bereitstellung der Anwendung aktivieren oder deaktivieren möchten?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Azure App Configuration feature flags",
            "de": "Feature Flags in Azure App Configuration"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Azure Boards queries",
            "de": "Azure-Boards-Abfragen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git tags",
            "de": "Git-Tags"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Azure Artifacts feeds",
            "de": "Azure-Artifacts-Feeds"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Azure App Configuration feature flags is correct because they externalize feature exposure decisions from the application deployment artifact. It best meets the requirement to toggle features progressively without redeploying.",
        "de": "Feature Flags in Azure App Configuration ist richtig, weil sie lagern Entscheidungen zur Funktionsfreigabe aus dem Bereitstellungsartefakt der Anwendung aus. Damit wird die Anforderung am besten erfüllt, Features schrittweise zu schalten, ohne neu bereitzustellen."
      },
      "hint": {
        "en": "Focus on the need to toggle features progressively without redeploying.",
        "de": "Achten Sie auf die Anforderung, Features schrittweise zu schalten, ohne neu bereitzustellen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-app-configuration/manage-feature-flags",
      "id": "az400-197"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which two SRE concepts define a measurable reliability signal and the target value it should meet?",
        "de": "Welche zwei SRE-Konzepte definieren ein messbares Zuverlässigkeitssignal und den Zielwert, den es erreichen soll?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "SLI",
            "de": "SLI"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "SLO",
            "de": "SLO"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "PAT",
            "de": "PAT"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "LFS",
            "de": "LFS"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "SLI and SLO is correct because they separate the measured indicator from the reliability objective for that indicator. It best meets the requirement to define reliability measurements and targets.",
        "de": "SLI und SLO ist richtig, weil sie trennen den gemessenen Indikator vom Zuverlässigkeitsziel für diesen Indikator. Damit wird die Anforderung am besten erfüllt, Zuverlässigkeitsmessungen und -ziele zu definieren."
      },
      "hint": {
        "en": "Focus on the need to define reliability measurements and targets.",
        "de": "Achten Sie auf die Anforderung, Zuverlässigkeitsmessungen und -ziele zu definieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/metrics-monitoring",
      "id": "az400-198"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Application Insights capability is most important for following a request across multiple services that participate in the same end-to-end transaction?",
        "de": "Welche Application-Insights-Funktion ist am wichtigsten, um eine Anforderung über mehrere Services zu verfolgen, die an derselben Ende-zu-Ende-Transaktion beteiligt sind?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Distributed tracing",
            "de": "Verteiltes Tracing"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Stakeholder access",
            "de": "Stakeholder-Zugriff"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git submodules",
            "de": "Git-Submodule"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Pipeline caching",
            "de": "Pipeline-Caching"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Distributed tracing is correct because it correlates telemetry across components for a single operation. It best meets the requirement to trace one transaction across multiple services.",
        "de": "Verteiltes Tracing ist richtig, weil es korreliert Telemetrie über Komponenten hinweg für einen einzelnen Vorgang. Damit wird die Anforderung am besten erfüllt, eine Transaktion über mehrere Services hinweg nachzuverfolgen."
      },
      "hint": {
        "en": "Focus on the need to trace one transaction across multiple services.",
        "de": "Achten Sie auf die Anforderung, eine Transaktion über mehrere Services hinweg nachzuverfolgen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview",
      "id": "az400-199"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "The on-call team wants one query that shows failed requests by operation name during the last deployment window.",
        "de": "Das Bereitschaftsteam möchte eine Abfrage, die fehlgeschlagene Anforderungen nach Vorgangsname während des letzten Bereitstellungsfensters zeigt."
      },
      "question": {
        "en": "Which query language should engineers use in Azure Monitor Logs to analyze request failures, latency, and custom telemetry?",
        "de": "Welche Abfragesprache sollten Ingenieure in Azure Monitor Logs verwenden, um Anforderungsfehler, Latenz und benutzerdefinierte Telemetrie zu analysieren?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "KQL",
            "de": "KQL"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "T-SQL only",
            "de": "Nur T-SQL"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "XPath",
            "de": "XPath"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Bicep",
            "de": "Bicep"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "KQL is correct because it is the native language for querying Azure Monitor log data. It best meets the requirement to analyze log data in Azure Monitor.",
        "de": "KQL ist richtig, weil es ist die native Sprache zum Abfragen von Azure-Monitor-Logdaten. Damit wird die Anforderung am besten erfüllt, Logdaten in Azure Monitor zu analysieren."
      },
      "hint": {
        "en": "Focus on the need to analyze log data in Azure Monitor.",
        "de": "Achten Sie auf die Anforderung, Logdaten in Azure Monitor zu analysieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/get-started-queries",
      "id": "az400-200"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which two Azure Monitor features should you use for synthetic uptime checks from several regions plus automatic notifications when availability drops?",
        "de": "Welche zwei Azure-Monitor-Funktionen sollten Sie für synthetische Verfügbarkeitsprüfungen aus mehreren Regionen plus automatische Benachrichtigungen bei sinkender Verfügbarkeit verwenden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Availability tests",
            "de": "Verfügbarkeitstests"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Alert rules",
            "de": "Alert-Regeln"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Branch protection",
            "de": "Branch-Protection"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Area paths",
            "de": "Area Paths"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Availability tests together with alert rules is correct because they probe endpoints proactively and notify responders when results degrade. It best meets the requirement to monitor user-visible availability proactively.",
        "de": "Verfügbarkeitstests zusammen mit Alert-Regeln ist richtig, weil sie prüfen Endpunkte proaktiv und benachrichtigen Reagierende, wenn Ergebnisse schlechter werden. Damit wird die Anforderung am besten erfüllt, sichtbare Verfügbarkeit für Benutzer proaktiv zu überwachen."
      },
      "hint": {
        "en": "Focus on the need to monitor user-visible availability proactively.",
        "de": "Achten Sie auf die Anforderung, sichtbare Verfügbarkeit für Benutzer proaktiv zu überwachen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-monitor/app/availability-overview",
      "id": "az400-201"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "easy",
      "scenario": null,
      "question": {
        "en": "Which term describes a contractual uptime commitment made by a provider to its customers?",
        "de": "Welcher Begriff beschreibt eine vertragliche Verfügbarkeitszusage eines Anbieters gegenüber seinen Kunden?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "SLA",
            "de": "SLA"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "SLO",
            "de": "SLO"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "SLI",
            "de": "SLI"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Error budget",
            "de": "Error Budget"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "An SLA is correct because it is the formal service commitment promised to customers. It best meets the requirement to identify the external contractual reliability commitment.",
        "de": "Ein SLA ist richtig, weil es ist die formale Servicezusage gegenüber Kunden. Damit wird die Anforderung am besten erfüllt, die externe vertragliche Zuverlässigkeitszusage zu identifizieren."
      },
      "hint": {
        "en": "Focus on the need to identify the external contractual reliability commitment.",
        "de": "Achten Sie auf die Anforderung, die externe vertragliche Zuverlässigkeitszusage zu identifizieren."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/service-level-agreements/slas-overview",
      "id": "az400-202"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "hard",
      "scenario": {
        "en": "The team wants a release strategy that automatically pauses or rolls back when latency or error rate worsens for the first cohort of users.",
        "de": "Das Team möchte eine Release-Strategie, die automatisch pausiert oder zurückrollt, wenn sich Latenz oder Fehlerquote für die erste Benutzergruppe verschlechtern."
      },
      "question": {
        "en": "What practice should you use when a new release is exposed gradually and continued only if telemetry stays healthy?",
        "de": "Welche Vorgehensweise sollten Sie verwenden, wenn eine neue Version schrittweise freigegeben und nur bei gesunder Telemetrie weiter ausgerollt wird?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Progressive exposure",
            "de": "Progressive Exposure"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Big bang deployment",
            "de": "Big-Bang-Bereitstellung"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Force pushing to main",
            "de": "Force Push auf main"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Manual copy deployment",
            "de": "Manuelle Kopier-Bereitstellung"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Progressive exposure is correct because it limits blast radius by increasing audience size only after health signals remain acceptable. It best meets the requirement to roll out a release based on observed telemetry health.",
        "de": "Progressive Exposure ist richtig, weil sie begrenzt den Blast Radius, indem die Zielgruppe nur bei akzeptablen Health-Signalen vergrößert wird. Damit wird die Anforderung am besten erfüllt, ein Release anhand beobachteter Telemetrie-Gesundheit auszurollen."
      },
      "hint": {
        "en": "Focus on the need to roll out a release based on observed telemetry health.",
        "de": "Achten Sie auf die Anforderung, ein Release anhand beobachteter Telemetrie-Gesundheit auszurollen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-app-configuration/manage-feature-flags",
      "id": "az400-203"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "Which Azure Monitor feature is best for building a shared operational dashboard that can combine resources from multiple subscriptions?",
        "de": "Welche Azure-Monitor-Funktion eignet sich am besten, um ein gemeinsames Betriebsdashboard zu erstellen, das Ressourcen aus mehreren Abonnements kombinieren kann?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Workbooks",
            "de": "Workbooks"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Branch policies",
            "de": "Branchrichtlinien"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Git hooks",
            "de": "Git-Hooks"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Universal Packages",
            "de": "Universal Packages"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Workbooks is correct because they provide flexible cross-resource visualizations and parameters. It best meets the requirement to build a shared cross-subscription observability view.",
        "de": "Workbooks ist richtig, weil sie bieten flexible Visualisierungen und Parameter über mehrere Ressourcen hinweg. Damit wird die Anforderung am besten erfüllt, eine gemeinsame Observability-Ansicht über mehrere Abonnements hinweg zu erstellen."
      },
      "hint": {
        "en": "Focus on the need to build a shared cross-subscription observability view.",
        "de": "Achten Sie auf die Anforderung, eine gemeinsame Observability-Ansicht über mehrere Abonnements hinweg zu erstellen."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-overview",
      "id": "az400-204"
    },
    {
      "type": "single",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": null,
      "question": {
        "en": "According to SRE practice, what should a team do when it has exhausted its error budget for the current period?",
        "de": "Was sollte ein Team gemäß SRE-Praxis tun, wenn es sein Error Budget für den aktuellen Zeitraum ausgeschöpft hat?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Slow or pause risky releases until reliability improves",
            "de": "Riskante Releases verlangsamen oder pausieren, bis sich die Zuverlässigkeit verbessert"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Ship changes faster to catch up",
            "de": "Änderungen schneller ausliefern, um aufzuholen"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Disable monitoring temporarily",
            "de": "Monitoring vorübergehend deaktivieren"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Lower customer expectations manually",
            "de": "Kundenerwartungen manuell senken"
          }
        }
      ],
      "correct": [
        "A"
      ],
      "explanation": {
        "en": "Slowing or pausing risky releases is correct because it protects reliability when the agreed error budget has been consumed. It best meets the requirement to respond appropriately when reliability tolerance is exhausted.",
        "de": "Das Verlangsamen oder Pausieren riskanter Releases ist richtig, weil es schützt die Zuverlässigkeit, wenn das vereinbarte Error Budget verbraucht ist. Damit wird die Anforderung am besten erfüllt, angemessen zu reagieren, wenn die Zuverlässigkeitstoleranz ausgeschöpft ist."
      },
      "hint": {
        "en": "Focus on the need to respond appropriately when reliability tolerance is exhausted.",
        "de": "Achten Sie auf die Anforderung, angemessen zu reagieren, wenn die Zuverlässigkeitstoleranz ausgeschöpft ist."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/metrics-monitoring",
      "id": "az400-205"
    },
    {
      "type": "multiple",
      "domain": {
        "en": "Implement an Instrumentation Strategy",
        "de": "Instrumentierungsstrategie implementieren"
      },
      "difficulty": "medium",
      "scenario": {
        "en": "A canary deployment has started, and the team needs fast evidence about whether the new version is harming user experience.",
        "de": "Ein Canary-Rollout hat begonnen, und das Team benötigt schnell Hinweise darauf, ob die neue Version die Benutzererfahrung beeinträchtigt."
      },
      "question": {
        "en": "Which two rollout indicators are most useful to watch immediately after a deployment when deciding whether to continue or roll back a web API release?",
        "de": "Welche zwei Rollout-Indikatoren sind direkt nach einer Bereitstellung am nützlichsten, um zu entscheiden, ob ein Web-API-Release fortgesetzt oder zurückgerollt werden soll?"
      },
      "options": [
        {
          "id": "A",
          "text": {
            "en": "Error rate",
            "de": "Fehlerquote"
          }
        },
        {
          "id": "B",
          "text": {
            "en": "Latency",
            "de": "Latenz"
          }
        },
        {
          "id": "C",
          "text": {
            "en": "Number of wiki pages",
            "de": "Anzahl der Wiki-Seiten"
          }
        },
        {
          "id": "D",
          "text": {
            "en": "Count of Git tags",
            "de": "Anzahl der Git-Tags"
          }
        }
      ],
      "correct": [
        "A",
        "B"
      ],
      "explanation": {
        "en": "Error rate and latency is correct because they are user-facing health signals that quickly reveal regressions during rollout. It best meets the requirement to judge release health from high-value user-facing indicators.",
        "de": "Fehlerquote und Latenz ist richtig, weil sie sind benutzernahe Health-Signale, die Regressionen während des Rollouts schnell sichtbar machen. Damit wird die Anforderung am besten erfüllt, die Release-Gesundheit anhand aussagekräftiger benutzerbezogener Indikatoren zu bewerten."
      },
      "hint": {
        "en": "Focus on the need to judge release health from high-value user-facing indicators.",
        "de": "Achten Sie auf die Anforderung, die Release-Gesundheit anhand aussagekräftiger benutzerbezogener Indikatoren zu bewerten."
      },
      "reference": "https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/metrics-monitoring",
      "id": "az400-206"
    }
  ];
  if (window.ExamData && window.ExamData['az-400']) {
    window.ExamData['az-400'].questions = window.ExamData['az-400'].questions.concat(extra);
  }
})();
