window.ExamData = window.ExamData || {};
window.ExamData['az-400'] = {
  meta: {
    id: 'az-400',
    title: {
      en: 'Designing and Implementing Microsoft DevOps Solutions',
      de: 'Entwerfen und Implementieren von Microsoft DevOps-Lösungen'
    },
    description: {
      en: 'This exam measures your ability to design and implement DevOps practices for version control, compliance, infrastructure as code, configuration management, and continuous delivery using Azure technologies.',
      de: 'Diese Prüfung misst Ihre Fähigkeit, DevOps-Praktiken für Versionskontrolle, Compliance, Infrastructure as Code, Konfigurationsmanagement und Continuous Delivery mit Azure-Technologien zu entwerfen und zu implementieren.'
    },
    icon: '🔄',
    level: 'expert',
    passingScore: 700,
    totalTime: 120,
    questionCount: '40-60',
    msLearnUrl: 'https://learn.microsoft.com/en-us/certifications/exams/az-400/',
    domains: [
      {
        name: {
          en: 'Configure Processes and Communications',
          de: 'Prozesse und Kommunikation konfigurieren'
        },
        weight: '10-15%'
      },
      {
        name: {
          en: 'Design and Implement Source Control',
          de: 'Quellcodeverwaltung entwerfen und implementieren'
        },
        weight: '15-20%'
      },
      {
        name: {
          en: 'Design and Implement Build and Release Pipelines',
          de: 'Build- und Release-Pipelines entwerfen und implementieren'
        },
        weight: '40-45%'
      },
      {
        name: {
          en: 'Develop a Security and Compliance Plan',
          de: 'Sicherheits- und Compliance-Plan entwickeln'
        },
        weight: '10-15%'
      },
      {
        name: {
          en: 'Implement an Instrumentation Strategy',
          de: 'Instrumentierungsstrategie implementieren'
        },
        weight: '10-15%'
      }
    ]
  },
  questions: [
    {
      id: 'az400-001',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: null,
      question: {
        en: 'Your organization uses Azure Boards across several teams. You need a shared view that highlights cross-team dependencies and upcoming milestones during release planning. Which Azure DevOps feature should you use?',
        de: 'Ihre Organisation verwendet Azure Boards in mehreren Teams. Sie benötigen eine gemeinsame Ansicht, die teamübergreifende Abhängigkeiten und bevorstehende Meilensteine während der Release-Planung hervorhebt. Welche Azure-DevOps-Funktion sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Delivery Plans', de: 'Delivery Plans' } },
        { id: 'B', text: { en: 'Test Plans', de: 'Test Plans' } },
        { id: 'C', text: { en: 'Deployment groups', de: 'Bereitstellungsgruppen' } },
        { id: 'D', text: { en: 'Service connections', de: 'Serviceverbindungen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Delivery Plans provide a timeline view across multiple Azure Boards teams and backlogs. They are designed to surface dependencies, planned work, and milestones in one place, which makes them useful for release coordination and communication.',
        de: 'Delivery Plans bieten eine Zeitachsenansicht über mehrere Azure-Boards-Teams und Backlogs hinweg. Sie sind dafür ausgelegt, Abhängigkeiten, geplante Arbeit und Meilensteine an einem Ort sichtbar zu machen, was sie für Release-Koordination und Kommunikation besonders geeignet macht.'
      },
      hint: {
        en: 'Look for the feature that gives portfolio-level visibility across more than one team backlog.',
        de: 'Suchen Sie nach der Funktion, die eine Portfolio-Sicht über mehr als ein Team-Backlog hinweg bereitstellt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/boards/plans/review-team-plans?view=azure-devops'
    },
    {
      id: 'az400-002',
      type: 'multiple',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: {
        en: 'Developers at Fabrikam, Inc. use GitHub for code and Azure Boards for work tracking. Product owners want work items updated from commits and pull requests, and operations wants release notifications in Microsoft Teams.',
        de: 'Entwickler bei Fabrikam, Inc. verwenden GitHub für den Code und Azure Boards für die Arbeitsverfolgung. Product Owner möchten, dass Arbeitselemente durch Commits und Pull Requests aktualisiert werden, und das Betriebsteam möchte Release-Benachrichtigungen in Microsoft Teams erhalten.'
      },
      question: {
        en: 'Which two integrations should you configure?',
        de: 'Welche zwei Integrationen sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Connect the GitHub repository to Azure Boards', de: 'Das GitHub-Repository mit Azure Boards verbinden' } },
        { id: 'B', text: { en: 'Configure a service hook or connector to send release events to Teams', de: 'Einen Service Hook oder Connector konfigurieren, um Release-Ereignisse an Teams zu senden' } },
        { id: 'C', text: { en: 'Export Azure Boards data to Excel every day', de: 'Azure-Boards-Daten täglich nach Excel exportieren' } },
        { id: 'D', text: { en: 'Disable work item linking in pull requests', de: 'Die Verknüpfung von Arbeitselementen in Pull Requests deaktivieren' } }
      ],
      correct: ['A', 'B'],
      explanation: {
        en: 'Connecting GitHub to Azure Boards enables traceability from commits and pull requests to work items. Service hooks or Teams connectors can publish release-related events so stakeholders are informed automatically without manual status updates.',
        de: 'Die Verbindung von GitHub mit Azure Boards ermöglicht die Nachverfolgbarkeit von Commits und Pull Requests zu Arbeitselementen. Service Hooks oder Teams-Connectoren können Release-bezogene Ereignisse veröffentlichen, sodass Stakeholder automatisch informiert werden und keine manuellen Statusmeldungen nötig sind.'
      },
      hint: {
        en: 'One answer is about traceability between code and work items, and the other is about automatic notifications.',
        de: 'Eine Antwort betrifft die Nachverfolgbarkeit zwischen Code und Arbeitselementen, die andere automatische Benachrichtigungen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/boards/github/?view=azure-devops'
    },
    {
      id: 'az400-003',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Fabrikam, Inc., a regulated company uses Azure DevOps multi-stage pipelines. Auditors require evidence that production deployments were approved by specific roles and that the approval history is retained with the deployment target.',
        de: 'Bei Fabrikam, Inc.: ein reguliertes Unternehmen verwendet mehrstufige Azure-DevOps-Pipelines. Auditoren verlangen Nachweise, dass Produktionsbereitstellungen von bestimmten Rollen genehmigt wurden und dass die Genehmigungshistorie zusammen mit dem Bereitstellungsziel erhalten bleibt.'
      },
      question: {
        en: 'What should you configure?',
        de: 'Was sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Classic release notes only', de: 'Nur klassische Release Notes' } },
        { id: 'B', text: { en: 'Approvals and checks on the production environment', de: 'Genehmigungen und Prüfungen für die Produktionsumgebung' } },
        { id: 'C', text: { en: 'Required reviewers on every commit to main', de: 'Erforderliche Reviewer für jeden Commit auf main' } },
        { id: 'D', text: { en: 'A dashboard widget that shows build counts', de: 'Ein Dashboard-Widget, das Build-Anzahlen anzeigt' } }
      ],
      correct: ['B'],
      explanation: {
        en: 'Environment approvals and checks are the right control for release governance in Azure DevOps. They gate deployment to the target environment, can require specific approvers, and create an auditable history tied directly to that environment and deployment run.',
        de: 'Umgebungs-Genehmigungen und Prüfungen sind die richtige Steuerung für Release-Governance in Azure DevOps. Sie blockieren die Bereitstellung in die Zielumgebung, können bestimmte Genehmiger verlangen und erzeugen eine prüfbare Historie, die direkt mit dieser Umgebung und dem Bereitstellungslauf verknüpft ist.'
      },
      hint: {
        en: 'The requirement is about governed deployment approval, not about code review or reporting after the fact.',
        de: 'Die Anforderung betrifft eine gesteuerte Bereitstellungsgenehmigung, nicht Code-Review oder Berichterstattung im Nachhinein.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops'
    },
    {
      id: 'az400-004',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: null,
      question: {
        en: 'A team deploys to production several times per day and wants minimal merge overhead. Which branching strategy fits best?',
        de: 'Ein Team stellt mehrmals pro Tag in Produktion bereit und möchte möglichst wenig Merge-Aufwand. Welche Branching-Strategie passt am besten?'
      },
      options: [
        { id: 'A', text: { en: 'Trunk-based development with short-lived feature branches', de: 'Trunk-Based Development mit kurzlebigen Feature-Branches' } },
        { id: 'B', text: { en: 'Long-lived GitFlow release branches for all work', de: 'Langlebige GitFlow-Release-Branches für alle Arbeiten' } },
        { id: 'C', text: { en: 'One branch per developer kept open for months', de: 'Ein Branch pro Entwickler, der monatelang offen bleibt' } },
        { id: 'D', text: { en: 'Cherry-picking directly from tags only', de: 'Ausschließlich Cherry-Picking direkt von Tags' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Trunk-based development supports frequent integration and rapid deployment. Short-lived branches reduce divergence and merge conflicts, which is a better fit than long-lived release or developer branches for high deployment frequency.',
        de: 'Trunk-Based Development unterstützt häufige Integration und schnelle Bereitstellung. Kurzlebige Branches verringern Abweichungen und Merge-Konflikte und sind daher für eine hohe Bereitstellungsfrequenz besser geeignet als langlebige Release- oder Entwickler-Branches.'
      },
      hint: {
        en: 'Choose the strategy optimized for continuous integration and small batches.',
        de: 'Wählen Sie die Strategie, die für Continuous Integration und kleine Änderungen optimiert ist.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops'
    },
    {
      id: 'az400-005',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., an Azure Repos repository contains an application that is deployed automatically from main. The team wants every change to main to have peer review and a successful validation build before merge.',
        de: 'Proseware, Inc. – Ein Azure-Repos-Repository enthält eine Anwendung, die automatisch aus main bereitgestellt wird. Das Team möchte, dass jede Änderung an main vor dem Merge ein Peer Review und einen erfolgreichen Validierungs-Build durchläuft.'
      },
      question: {
        en: 'What should you configure on the main branch?',
        de: 'Was sollten Sie auf dem Branch main konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Branch policies with required reviewers and build validation', de: 'Branchrichtlinien mit verpflichtenden Reviewern und Buildvalidierung' } },
        { id: 'B', text: { en: 'A local pre-commit hook on each developer computer', de: 'Einen lokalen Pre-Commit-Hook auf jedem Entwicklercomputer' } },
        { id: 'C', text: { en: 'A scheduled pipeline that runs once per week', de: 'Eine geplante Pipeline, die einmal pro Woche läuft' } },
        { id: 'D', text: { en: 'An unrestricted force-push policy', de: 'Eine uneingeschränkte Force-Push-Richtlinie' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Azure Repos branch policies can require minimum reviewers and a successful build before a pull request completes. This enforces quality gates consistently at the branch level instead of depending on local developer tooling or manual discipline.',
        de: 'Azure-Repos-Branchrichtlinien können eine Mindestanzahl an Reviewern und einen erfolgreichen Build verlangen, bevor ein Pull Request abgeschlossen wird. Dadurch werden Qualitätsprüfungen konsistent auf Branch-Ebene erzwungen, anstatt sich auf lokale Entwicklerwerkzeuge oder manuelle Disziplin zu verlassen.'
      },
      hint: {
        en: 'The control must be enforced centrally on the protected branch, not only on developer workstations.',
        de: 'Die Kontrolle muss zentral auf dem geschützten Branch erzwungen werden, nicht nur auf Entwicklerarbeitsplätzen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops'
    },
    {
      id: 'az400-006',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: null,
      question: {
        en: 'A mobile application has planned release hardening periods and occasional hotfixes while new feature work continues. Which branching strategy is the best fit?',
        de: 'Eine mobile Anwendung hat geplante Stabilisierungsphasen vor Releases und gelegentliche Hotfixes, während neue Features weiterentwickelt werden. Welche Branching-Strategie passt am besten?'
      },
      options: [
        { id: 'A', text: { en: 'GitFlow with develop, release, and hotfix branches', de: 'GitFlow mit develop-, release- und hotfix-Branches' } },
        { id: 'B', text: { en: 'Trunk-based development with no release branching at all', de: 'Trunk-Based Development ohne jegliche Release-Branches' } },
        { id: 'C', text: { en: 'A single branch and manual ZIP backups', de: 'Ein einzelner Branch und manuelle ZIP-Sicherungen' } },
        { id: 'D', text: { en: 'Only annotated tags and no parallel branches', de: 'Nur annotierte Tags und keine parallelen Branches' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'GitFlow is useful when you need a separate release hardening path and structured hotfix handling while ongoing feature development continues. It adds process overhead, but that overhead can be appropriate for planned release trains.',
        de: 'GitFlow ist nützlich, wenn Sie einen separaten Stabilisierungszweig für Releases und eine strukturierte Behandlung von Hotfixes benötigen, während die Feature-Entwicklung weiterläuft. Es bringt zwar mehr Prozessaufwand mit sich, dieser kann jedoch für geplante Release-Zyklen angemessen sein.'
      },
      hint: {
        en: 'Choose the model that explicitly supports release branches and hotfix branches.',
        de: 'Wählen Sie das Modell, das Release-Branches und Hotfix-Branches ausdrücklich unterstützt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops'
    },
    {
      id: 'az400-007',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'The platform team at Contoso, Ltd. stores reusable Bicep modules in a separate Azure Repos repository. Application teams must consume approved versions of those modules without copying files into every repository and must stay pinned to known revisions.',
        de: 'Das Plattformteam von Contoso, Ltd. speichert wiederverwendbare Bicep-Module in einem separaten Azure-Repos-Repository. Anwendungsteams müssen genehmigte Versionen dieser Module nutzen, ohne Dateien in jedes Repository zu kopieren, und auf bekannte Revisionen festgelegt bleiben.'
      },
      question: {
        en: 'Which Git technique best meets the requirement?',
        de: 'Welche Git-Technik erfüllt die Anforderung am besten?'
      },
      options: [
        { id: 'A', text: { en: 'Use a Git submodule that points to the approved commit', de: 'Ein Git-Submodul verwenden, das auf den genehmigten Commit verweist' } },
        { id: 'B', text: { en: 'Force all teams to manually copy the module files', de: 'Alle Teams dazu zwingen, die Moduldateien manuell zu kopieren' } },
        { id: 'C', text: { en: 'Use git stash before every deployment', de: 'Vor jeder Bereitstellung git stash verwenden' } },
        { id: 'D', text: { en: 'Reset the repository to HEAD every morning', de: 'Das Repository jeden Morgen auf HEAD zurücksetzen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A submodule references another repository at a specific commit, which preserves traceability and version pinning without duplicating content into every application repository. That makes it suitable when consumers must stay on approved revisions until they intentionally update.',
        de: 'Ein Submodul verweist auf ein anderes Repository an einem bestimmten Commit und bewahrt so Nachverfolgbarkeit und Versionsfixierung, ohne Inhalte in jedes Anwendungsrepository zu duplizieren. Das ist geeignet, wenn Verbraucher auf genehmigten Revisionen bleiben müssen, bis sie diese bewusst aktualisieren.'
      },
      hint: {
        en: 'The key requirement is pinning another repository to an explicit revision.',
        de: 'Die zentrale Anforderung ist, ein anderes Repository auf eine explizite Revision festzulegen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/repos/git/submodules?view=azure-devops'
    },
    {
      id: 'az400-008',
      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: 'In an Azure DevOps YAML pipeline, which keyword makes one stage depend on the successful completion of another stage?',
        de: 'Welches Schlüsselwort sorgt in einer Azure-DevOps-YAML-Pipeline dafür, dass eine Stage vom erfolgreichen Abschluss einer anderen Stage abhängt?'
      },
      options: [
        { id: 'A', text: { en: 'dependsOn', de: 'dependsOn' } },
        { id: 'B', text: { en: 'trigger', de: 'trigger' } },
        { id: 'C', text: { en: 'pool', de: 'pool' } },
        { id: 'D', text: { en: 'checkout', de: 'checkout' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'The dependsOn keyword defines stage or job dependencies in Azure Pipelines YAML. It is used to model execution order so downstream stages run only after prerequisite stages succeed.',
        de: 'Das Schlüsselwort dependsOn definiert Abhängigkeiten zwischen Stages oder Jobs in Azure Pipelines YAML. Es wird verwendet, um die Ausführungsreihenfolge zu modellieren, sodass nachgelagerte Stages erst nach erfolgreich abgeschlossenen Vorstufen laufen.'
      },
      hint: {
        en: 'Think about the YAML property that expresses execution dependency, not repository checkout or triggers.',
        de: 'Denken Sie an die YAML-Eigenschaft, die eine Ausführungsabhängigkeit ausdrückt, nicht an Repository-Checkout oder Trigger.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/stages?view=azure-devops'
    },
    {
      id: 'az400-009',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'You work for Fabrikam, Inc. Use an environment-level control, not a text comment or a timing setting.',
        de: 'Sie arbeiten für Fabrikam, Inc. Verwenden Sie eine Kontrolle auf Umgebungsebene, nicht einen Textkommentar oder eine Zeiteinstellung.'
      },
      question: {
        en: 'How should you implement this?',
        de: 'Wie sollten Sie dies umsetzen?'
      },
      options: [
        { id: 'A', text: { en: 'Add an approval check to the production environment', de: 'Der Produktionsumgebung eine Genehmigungsprüfung hinzufügen' } },
        { id: 'B', text: { en: 'Add a comment in the YAML file', de: 'Einen Kommentar in der YAML-Datei hinzufügen' } },
        { id: 'C', text: { en: 'Use only path filters', de: 'Nur Pfadfilter verwenden' } },
        { id: 'D', text: { en: 'Increase the agent timeout', de: 'Das Agent-Timeout erhöhen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Environment approvals are the standard way to gate production deployments in a multi-stage pipeline. They separate deployment governance from the build logic and provide an auditable approval trail for the protected environment.',
        de: 'Umgebungs-Genehmigungen sind der Standardweg, um Produktionsbereitstellungen in einer mehrstufigen Pipeline zu steuern. Sie trennen Bereitstellungs-Governance von der Build-Logik und liefern eine prüfbare Genehmigungsspur für die geschützte Umgebung.'
      },
      hint: {
        en: 'Use an environment-level control, not a text comment or a timing setting.',
        de: 'Verwenden Sie eine Kontrolle auf Umgebungsebene, nicht einen Textkommentar oder eine Zeiteinstellung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops'
    },
    {
      id: 'az400-010',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'You work for Proseware, Inc. Your team needs the strategy that starts with a small user percentage rather than a full traffic switch.',
        de: 'Sie arbeiten für Proseware, Inc. Ihr Team benötigt die Strategie, die mit einem kleinen Benutzeranteil beginnt, statt den gesamten Traffic sofort umzuschalten.'
      },
      question: {
        en: 'Which deployment strategy should you choose?',
        de: 'Welche Bereitstellungsstrategie sollten Sie wählen?'
      },
      options: [
        { id: 'A', text: { en: 'Canary deployment', de: 'Canary-Bereitstellung' } },
        { id: 'B', text: { en: 'Big bang deployment', de: 'Big-Bang-Bereitstellung' } },
        { id: 'C', text: { en: 'Direct in-place replacement for all users at once', de: 'Direkter In-Place-Ersatz für alle Benutzer gleichzeitig' } },
        { id: 'D', text: { en: 'Disable health checks during rollout', de: 'Integritätsprüfungen während des Rollouts deaktivieren' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Canary deployment is designed for progressive exposure. It releases the new version to a limited audience first, allowing the team to validate quality and telemetry before moving all traffic to the new version.',
        de: 'Die Canary-Bereitstellung ist für schrittweise Freigabe ausgelegt. Sie stellt die neue Version zunächst nur einer begrenzten Zielgruppe bereit, sodass das Team Qualität und Telemetrie validieren kann, bevor der gesamte Datenverkehr auf die neue Version umgeschaltet wird.'
      },
      hint: {
        en: 'Choose the strategy that starts with a small user percentage rather than a full traffic switch.',
        de: 'Wählen Sie die Strategie, die mit einem kleinen Benutzeranteil beginnt, statt den gesamten Traffic sofort umzuschalten.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/ecosystems/kubernetes/deploy?view=azure-devops'
    },
    {
      id: 'az400-011',
      type: 'multiple',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Proseware, Inc., several product teams use Azure DevOps and each pipeline repeats the same build, security scan, and container publish steps. The platform team wants centrally maintained YAML logic with controlled inputs.',
        de: 'Bei Proseware, Inc.: mehrere Produktteams verwenden Azure DevOps, und jede Pipeline wiederholt dieselben Schritte für Build, Sicherheitsscan und Containerveröffentlichung. Das Plattformteam möchte zentral gepflegte YAML-Logik mit kontrollierten Eingaben.'
      },
      question: {
        en: 'Which two YAML capabilities should you use?',
        de: 'Welche zwei YAML-Funktionen sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Templates', de: 'Templates' } },
        { id: 'B', text: { en: 'Parameters', de: 'Parameter' } },
        { id: 'C', text: { en: 'Manual copy and paste into every repository', de: 'Manuelles Kopieren und Einfügen in jedes Repository' } },
        { id: 'D', text: { en: 'Separate agent pools only', de: 'Nur separate Agent-Pools' } }
      ],
      correct: ['A', 'B'],
      explanation: {
        en: 'Templates let you reuse pipeline logic across teams, while parameters provide controlled customization points for values such as image names, environments, or scan settings. Together they support standardization without duplicating YAML in every repository.',
        de: 'Templates ermöglichen die Wiederverwendung von Pipeline-Logik über Teams hinweg, während Parameter kontrollierte Anpassungspunkte für Werte wie Imagenamen, Umgebungen oder Scan-Einstellungen bieten. Zusammen unterstützen sie Standardisierung, ohne YAML in jedes Repository zu duplizieren.'
      },
      hint: {
        en: 'One feature promotes reuse, and the other lets you safely vary inputs.',
        de: 'Eine Funktion fördert Wiederverwendung, die andere erlaubt eine sichere Variation der Eingaben.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops'
    },
    {
      id: 'az400-012',
      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 service is designed to host internal NuGet and npm packages for reuse across teams?',
        de: 'Welcher Azure-Dienst ist dafür vorgesehen, interne NuGet- und npm-Pakete für die Wiederverwendung zwischen Teams zu hosten?'
      },
      options: [
        { id: 'A', text: { en: 'Azure Artifacts', de: 'Azure Artifacts' } },
        { id: 'B', text: { en: 'Azure Monitor', de: 'Azure Monitor' } },
        { id: 'C', text: { en: 'Azure Policy', de: 'Azure Policy' } },
        { id: 'D', text: { en: 'Azure Load Testing', de: 'Azure Load Testing' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Azure Artifacts provides managed feeds for package types such as NuGet and npm. It is built for package versioning, sharing, upstream sources, and controlled consumption in build pipelines and developer workstations.',
        de: 'Azure Artifacts stellt verwaltete Feeds für Pakettypen wie NuGet und npm bereit. Der Dienst ist für Paketversionierung, Freigabe, Upstream-Quellen und kontrollierte Nutzung in Build-Pipelines und auf Entwicklerarbeitsplätzen konzipiert.'
      },
      hint: {
        en: 'Choose the service that is a package repository, not a monitoring or governance service.',
        de: 'Wählen Sie den Dienst, der ein Paketrepository ist und kein Monitoring- oder Governance-Dienst.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/artifacts/start-using-azure-artifacts?view=azure-devops'
    },
    {
      id: 'az400-013',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., a GitHub Actions workflow builds a container image and pushes it to Azure Container Registry. Security policy says you must avoid storing long-lived client secrets in GitHub.',
        de: 'Bei Contoso, Ltd.: ein GitHub-Actions-Workflow erstellt ein Container-Image und pusht es in Azure Container Registry. Laut Sicherheitsrichtlinie dürfen keine langlebigen Client-Geheimnisse in GitHub gespeichert werden.'
      },
      question: {
        en: 'What should you use for authentication?',
        de: 'Was sollten Sie zur Authentifizierung verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Azure federated identity with azure/login and OpenID Connect', de: 'Eine föderierte Azure-Identität mit azure/login und OpenID Connect' } },
        { id: 'B', text: { en: 'A personal access token committed to the workflow file', de: 'Ein Personal Access Token, das in die Workflow-Datei eingecheckt wird' } },
        { id: 'C', text: { en: 'A username and password hardcoded in YAML', de: 'Benutzername und Kennwort fest in YAML codiert' } },
        { id: 'D', text: { en: 'A certificate file stored in the repository', de: 'Eine Zertifikatsdatei im Repository' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'GitHub Actions can authenticate to Azure by using OpenID Connect with a federated credential. This avoids long-lived secrets, improves rotation and governance, and aligns with recommended modern authentication patterns for Azure deployments.',
        de: 'GitHub Actions kann sich über OpenID Connect mit einer föderierten Anmeldeinformation bei Azure authentifizieren. Dadurch entfallen langlebige Geheimnisse, die Rotation und Governance werden verbessert, und es entspricht modernen empfohlenen Authentifizierungsmustern für Azure-Bereitstellungen.'
      },
      hint: {
        en: 'Select the option that uses workload identity federation instead of stored secrets.',
        de: 'Wählen Sie die Option, die Workload Identity Federation statt gespeicherter Geheimnisse verwendet.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure-openid-connect'
    },
    {
      id: 'az400-014',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Fabrikam, Inc., a web app runs in Azure App Service. You need a blue-green deployment pattern with fast rollback if smoke tests fail after release.',
        de: 'Bei Fabrikam, Inc.: eine Web-App läuft in Azure App Service. Sie benötigen ein Blue-Green-Bereitstellungsmuster mit schnellem Rollback, falls Smoke-Tests nach dem Release fehlschlagen.'
      },
      question: {
        en: 'Which approach should you use?',
        de: 'Welchen Ansatz sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Deploy to a staging slot and swap with production', de: 'In einen Staging-Slot bereitstellen und mit Produktion austauschen' } },
        { id: 'B', text: { en: 'Replace files directly on the production slot', de: 'Dateien direkt im Produktionsslot ersetzen' } },
        { id: 'C', text: { en: 'Use only manual FTP uploads', de: 'Nur manuelle FTP-Uploads verwenden' } },
        { id: 'D', text: { en: 'Stop the production app during every deployment', de: 'Die Produktions-App bei jeder Bereitstellung stoppen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Deployment slots in App Service are a common blue-green mechanism. You deploy the new build to a non-production slot, validate it, and then swap traffic. If issues appear, you can swap back quickly, which reduces risk and downtime.',
        de: 'Bereitstellungsslots in App Service sind ein gängiger Blue-Green-Mechanismus. Sie stellen den neuen Build in einem Nicht-Produktionsslot bereit, validieren ihn und schalten dann den Traffic um. Treten Probleme auf, können Sie schnell zurücktauschen, was Risiko und Ausfallzeit reduziert.'
      },
      hint: {
        en: 'Look for the App Service feature designed for staged deployment and quick traffic switching.',
        de: 'Suchen Sie nach der App-Service-Funktion, die für gestufte Bereitstellung und schnelles Umschalten des Traffics vorgesehen ist.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots'
    },
    {
      id: 'az400-015',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., multiple engineers run Terraform from a pipeline to provision Azure resources. You need shared state, locking, and reliable collaboration.',
        de: 'Bei Proseware, Inc.: mehrere Ingenieure führen Terraform über eine Pipeline aus, um Azure-Ressourcen bereitzustellen. Sie benötigen gemeinsamen State, Sperrmechanismen und zuverlässige Zusammenarbeit.'
      },
      question: {
        en: 'How should you store the Terraform state?',
        de: 'Wie sollten Sie den Terraform-State speichern?'
      },
      options: [
        { id: 'A', text: { en: 'In an Azure Storage account backend', de: 'In einem Azure-Storage-Account als Backend' } },
        { id: 'B', text: { en: 'In a local file on each build agent', de: 'In einer lokalen Datei auf jedem Build-Agent' } },
        { id: 'C', text: { en: 'Inside pipeline logs', de: 'Innerhalb der Pipeline-Logs' } },
        { id: 'D', text: { en: 'In the application repository README', de: 'In der README des Anwendungsrepositories' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Terraform state should be stored in a shared remote backend for collaboration. Azure Storage is commonly used with Terraform on Azure because it provides centralized state management and supports safer team workflows than per-agent local files.',
        de: 'Terraform-State sollte für Zusammenarbeit in einem gemeinsamen Remote-Backend gespeichert werden. Azure Storage wird mit Terraform in Azure häufig verwendet, weil es zentrale State-Verwaltung bietet und sicherere Team-Workflows unterstützt als lokale Dateien pro Agent.'
      },
      hint: {
        en: 'The state must be remote and shared, not tied to one pipeline agent.',
        de: 'Der State muss remote und gemeinsam nutzbar sein, nicht an einen einzelnen Pipeline-Agent gebunden.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/developer/terraform/get-started/store-state-in-azure-storage'
    },
    {
      id: 'az400-016',
      type: 'multiple',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'You work for Contoso, Ltd. One choice improves template authoring, and the other previews the delta before deployment.',
        de: 'Contoso, Ltd. – Ihr Team möchte ARM-Template-Bereitstellungen modernisieren. Die Lösung muss mit Azure Resource Manager kompatibel bleiben, Templates besser lesbar machen und Infrastrukturänderungen vor der Produktionsbereitstellung vorab anzeigen.'
      },
      question: {
        en: 'Which two actions should you take?',
        de: 'Welche zwei Maßnahmen sollten Sie ergreifen?'
      },
      options: [
        { id: 'A', text: { en: 'Convert the JSON ARM templates to Bicep', de: 'Die JSON-ARM-Templates in Bicep konvertieren' } },
        { id: 'B', text: { en: 'Run a what-if deployment in the pipeline', de: 'Eine What-If-Bereitstellung in der Pipeline ausführen' } },
        { id: 'C', text: { en: 'Use only portal-based deployments', de: 'Ausschließlich portalbasierte Bereitstellungen verwenden' } },
        { id: 'D', text: { en: 'Track desired state in a spreadsheet', de: 'Den Sollzustand in einer Tabellenkalkulation verwalten' } }
      ],
      correct: ['A', 'B'],
      explanation: {
        en: 'Bicep improves readability and authoring experience while still deploying through Azure Resource Manager. Running what-if in the pipeline previews expected infrastructure changes, which helps review and control production deployments before they are applied.',
        de: 'Bicep verbessert Lesbarkeit und Authoring-Erlebnis, während weiterhin über Azure Resource Manager bereitgestellt wird. Wenn in der Pipeline What-If ausgeführt wird, werden erwartete Infrastrukturänderungen vorab angezeigt, was die Überprüfung und Steuerung von Produktionsbereitstellungen vor der Anwendung erleichtert.'
      },
      hint: {
        en: 'One choice improves template authoring, and the other previews the delta before deployment.',
        de: 'Eine Auswahl verbessert die Template-Erstellung, die andere zeigt die Unterschiede vor der Bereitstellung an.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-what-if'
    },
    {
      id: 'az400-017',
      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: 'You package Kubernetes applications as Helm charts and want a managed Azure service to store versioned OCI artifacts close to your container images. Which service should you use?',
        de: 'Sie paketieren Kubernetes-Anwendungen als Helm-Charts und möchten einen verwalteten Azure-Dienst nutzen, um versionierte OCI-Artefakte in der Nähe Ihrer Container-Images zu speichern. Welchen Dienst sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Azure Container Registry', de: 'Azure Container Registry' } },
        { id: 'B', text: { en: 'Azure Boards', de: 'Azure Boards' } },
        { id: 'C', text: { en: 'Azure Bastion', de: 'Azure Bastion' } },
        { id: 'D', text: { en: 'Azure Site Recovery', de: 'Azure Site Recovery' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Azure Container Registry can store OCI artifacts, which includes modern Helm chart packaging scenarios. Keeping charts and container images together in ACR simplifies versioning, access control, and deployment workflows.',
        de: 'Azure Container Registry kann OCI-Artefakte speichern, wozu moderne Szenarien für die Verpackung von Helm-Charts gehören. Wenn Charts und Container-Images gemeinsam in ACR liegen, werden Versionierung, Zugriffskontrolle und Bereitstellungs-Workflows vereinfacht.'
      },
      hint: {
        en: 'Choose the registry service rather than a planning or connectivity service.',
        de: 'Wählen Sie den Registrierungsdienst und keinen Planungs- oder Konnektivitätsdienst.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/container-registry/container-registry-image-formats'
    },
    {
      id: 'az400-018',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Fabrikam, Inc., an application runs on a Virtual Machine Scale Set. The release team wants to update instances in batches so that some instances continue serving traffic during deployment.',
        de: 'Bei Fabrikam, Inc. läuft auf einem Virtual Machine Scale Set. Das Release-Team möchte Instanzen in Chargen aktualisieren, sodass während der Bereitstellung weiterhin einige Instanzen Traffic bedienen.'
      },
      question: {
        en: 'Which deployment strategy fits best?',
        de: 'Welche Bereitstellungsstrategie passt am besten?'
      },
      options: [
        { id: 'A', text: { en: 'Rolling deployment', de: 'Rolling Deployment' } },
        { id: 'B', text: { en: 'Big bang deployment', de: 'Big-Bang-Bereitstellung' } },
        { id: 'C', text: { en: 'Blue-green deployment only', de: 'Ausschließlich Blue-Green-Bereitstellung' } },
        { id: 'D', text: { en: 'Manual copy to every server at once', de: 'Manuelles Kopieren auf alle Server gleichzeitig' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Rolling deployment updates targets in batches instead of switching everything at once. That keeps part of the fleet available, reduces risk, and is a common strategy for VM scale set and server-based rollouts.',
        de: 'Ein Rolling Deployment aktualisiert Ziele in Chargen, anstatt alles auf einmal umzuschalten. Dadurch bleibt ein Teil der Flotte verfügbar, das Risiko sinkt, und es ist eine gängige Strategie für Rollouts auf VM Scale Sets und serverbasierten Umgebungen.'
      },
      hint: {
        en: 'Choose the strategy that progresses through the fleet batch by batch.',
        de: 'Wählen Sie die Strategie, die schrittweise Charge für Charge durch die Flotte läuft.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops'
    },
    {
      id: 'az400-019',
      type: 'multiple',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'medium',
      scenario: {
        en: 'A GitHub repository at Proseware, Inc. contains infrastructure code and application code. You want pull requests to detect leaked credentials and vulnerable open-source dependencies before merge.',
        de: 'Ein GitHub-Repository bei Proseware, Inc. enthält Infrastrukturcode und Anwendungscode. Sie möchten, dass Pull Requests geleakte Zugangsdaten und anfällige Open-Source-Abhängigkeiten vor dem Merge erkennen.'
      },
      question: {
        en: 'Which two capabilities should you enable?',
        de: 'Welche zwei Funktionen sollten Sie aktivieren?'
      },
      options: [
        { id: 'A', text: { en: 'Secret scanning', de: 'Secret Scanning' } },
        { id: 'B', text: { en: 'Dependabot alerts or dependency review', de: 'Dependabot-Warnungen oder Dependency Review' } },
        { id: 'C', text: { en: 'Disable scanning to keep pipelines fast', de: 'Scans deaktivieren, um Pipelines schneller zu machen' } },
        { id: 'D', text: { en: 'Store secrets in plain text repository variables', de: 'Geheimnisse als Klartext in Repository-Variablen speichern' } }
      ],
      correct: ['A', 'B'],
      explanation: {
        en: 'Secret scanning helps detect exposed credentials, while dependency analysis such as Dependabot alerts or dependency review helps identify known vulnerable packages before code is merged. Together they improve supply chain and credential hygiene early in the workflow.',
        de: 'Secret Scanning hilft, offengelegte Zugangsdaten zu erkennen, während Abhängigkeitsanalysen wie Dependabot-Warnungen oder Dependency Review bekannte verwundbare Pakete identifizieren, bevor Code gemergt wird. Zusammen verbessern sie frühzeitig die Lieferkettensicherheit und den Umgang mit Geheimnissen.'
      },
      hint: {
        en: 'One answer focuses on credentials, and the other on vulnerable packages.',
        de: 'Eine Antwort konzentriert sich auf Zugangsdaten, die andere auf verwundbare Pakete.'
      },
      reference: 'https://learn.microsoft.com/en-us/training/modules/introduction-github-advanced-security/'
    },
    {
      id: 'az400-020',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'easy',
      scenario: null,
      question: {
        en: 'You need pipeline secrets such as connection strings to be stored centrally, rotated outside the pipeline, and retrieved at runtime in Azure DevOps. What should you integrate?',
        de: 'Sie müssen Pipeline-Geheimnisse wie Verbindungszeichenfolgen zentral speichern, außerhalb der Pipeline rotieren und zur Laufzeit in Azure DevOps abrufen. Was sollten Sie integrieren?'
      },
      options: [
        { id: 'A', text: { en: 'Azure Key Vault linked to a variable group or pipeline secret retrieval', de: 'Azure Key Vault, verknüpft mit einer Variablengruppe oder direktem Secret-Abruf in der Pipeline' } },
        { id: 'B', text: { en: 'Plain text variables in YAML', de: 'Klartextvariablen in YAML' } },
        { id: 'C', text: { en: 'Secret values in the README file', de: 'Geheimwerte in der README-Datei' } },
        { id: 'D', text: { en: 'Manual environment variables set on one agent', de: 'Manuell gesetzte Umgebungsvariablen auf einem Agent' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Azure Key Vault is designed for centralized secret storage and rotation. Azure DevOps can retrieve Key Vault secrets at runtime, which keeps sensitive values out of source control and out of static pipeline definitions.',
        de: 'Azure Key Vault ist für zentrale Geheimnisspeicherung und Rotation vorgesehen. Azure DevOps kann Key-Vault-Geheimnisse zur Laufzeit abrufen, sodass sensible Werte nicht im Quellcode und nicht in statischen Pipeline-Definitionen gespeichert werden müssen.'
      },
      hint: {
        en: 'Choose the managed secret store that integrates directly with Azure DevOps.',
        de: 'Wählen Sie den verwalteten Geheimnisspeicher, der sich direkt in Azure DevOps integrieren lässt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/release/azure-key-vault?view=azure-devops'
    },
    {
      id: 'az400-021',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'hard',
      scenario: {
        en: 'The security team at Contoso, Ltd. wants every pull request for a public-facing web API to fail when code violates critical OWASP-related rules such as injection or insecure configuration. The organization already uses SonarQube.',
        de: 'Das Sicherheitsteam von Contoso, Ltd. möchte, dass jeder Pull Request für eine öffentlich erreichbare Web-API fehlschlägt, wenn der Code gegen kritische OWASP-bezogene Regeln wie Injection oder unsichere Konfiguration verstößt. Die Organisation verwendet bereits SonarQube.'
      },
      question: {
        en: 'What should you implement?',
        de: 'Was sollten Sie implementieren?'
      },
      options: [
        { id: 'A', text: { en: 'Run SonarQube analysis in CI and enforce a quality gate before merge', de: 'SonarQube-Analyse in CI ausführen und vor dem Merge ein Quality Gate erzwingen' } },
        { id: 'B', text: { en: 'Review code only after production deployment', de: 'Code erst nach der Produktionsbereitstellung prüfen' } },
        { id: 'C', text: { en: 'Disable pull request validation for security files', de: 'Pull-Request-Validierung für Sicherheitsdateien deaktivieren' } },
        { id: 'D', text: { en: 'Run unit tests only', de: 'Nur Unit-Tests ausführen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'SonarQube can analyze code during CI and evaluate the result with a quality gate. When the gate includes critical security rules aligned to OWASP concerns, the pipeline can block unsafe code before it is merged or released.',
        de: 'SonarQube kann Code während CI analysieren und das Ergebnis mit einem Quality Gate bewerten. Wenn das Gate kritische Sicherheitsregeln enthält, die zu OWASP-Anforderungen passen, kann die Pipeline unsicheren Code blockieren, bevor er gemergt oder veröffentlicht wird.'
      },
      hint: {
        en: 'The requirement is shift-left security enforcement in the pull request workflow.',
        de: 'Die Anforderung ist eine nach links verlagerte Sicherheitsdurchsetzung im Pull-Request-Workflow.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/ecosystems/java?view=azure-devops'
    },
    {
      id: 'az400-022',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'easy',
      scenario: null,
      question: {
        en: 'Which Azure service is primarily used to collect application telemetry, distributed traces, exceptions, and dependency calls from an app?',
        de: 'Welcher Azure-Dienst wird primär verwendet, um Anwendungstelemetrie, verteilte Traces, Ausnahmen und Abhängigkeitsaufrufe aus einer App zu sammeln?'
      },
      options: [
        { id: 'A', text: { en: 'Application Insights', de: 'Application Insights' } },
        { id: 'B', text: { en: 'Azure Artifacts', de: 'Azure Artifacts' } },
        { id: 'C', text: { en: 'Azure Repos', de: 'Azure Repos' } },
        { id: 'D', text: { en: 'Azure Front Door', de: 'Azure Front Door' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Application Insights is the Azure service focused on application performance monitoring. It captures requests, dependencies, exceptions, traces, and other telemetry that helps teams understand runtime behavior and user impact.',
        de: 'Application Insights ist der Azure-Dienst für Application Performance Monitoring. Er erfasst Anforderungen, Abhängigkeiten, Ausnahmen, Traces und weitere Telemetrie, die Teams hilft, Laufzeitverhalten und Benutzerwirkungen zu verstehen.'
      },
      hint: {
        en: 'Choose the APM-focused service rather than a package or source control service.',
        de: 'Wählen Sie den auf APM ausgerichteten Dienst und keinen Paket- oder Quellcodedienst.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview'
    },
    {
      id: 'az400-023',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., after each production deployment, the team wants to correlate the new release with error rate and response time changes in the application telemetry.',
        de: 'Bei Contoso, Ltd.: nach jeder Produktionsbereitstellung möchte das Team das neue Release mit Änderungen bei Fehlerrate und Antwortzeit in der Anwendungstelemetrie korrelieren.'
      },
      question: {
        en: 'What should you configure?',
        de: 'Was sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Release annotations with Application Insights or Azure Monitor', de: 'Release-Anmerkungen mit Application Insights oder Azure Monitor' } },
        { id: 'B', text: { en: 'A manual spreadsheet entry after deployment', de: 'Einen manuellen Eintrag in eine Tabellenkalkulation nach der Bereitstellung' } },
        { id: 'C', text: { en: 'A second source control branch', de: 'Einen zweiten Quellcode-Branch' } },
        { id: 'D', text: { en: 'A longer build timeout', de: 'Ein längeres Build-Timeout' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Release annotations mark deployment events on telemetry timelines so the team can quickly compare changes in failures, latency, or other KPIs immediately after a release. That is much more effective than relying on separate manual records.',
        de: 'Release-Anmerkungen markieren Bereitstellungsereignisse auf Telemetrie-Zeitachsen, sodass das Team Änderungen bei Fehlern, Latenz oder anderen KPIs direkt nach einem Release schnell vergleichen kann. Das ist wesentlich wirksamer, als sich auf separate manuelle Aufzeichnungen zu verlassen.'
      },
      hint: {
        en: 'Think about a feature that stamps deployment events directly onto the monitoring timeline.',
        de: 'Denken Sie an eine Funktion, die Bereitstellungsereignisse direkt auf der Monitoring-Zeitachse markiert.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/app/annotations'
    },
    {
      id: 'az400-024',
      type: 'multiple',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'You work for Fabrikam, Inc. One answer controls exposure, and the other measures the outcome.',
        de: 'Sie arbeiten für Fabrikam, Inc. Eine Antwort steuert die Freigabe, die andere misst das Ergebnis.'
      },
      question: {
        en: 'Which two capabilities best support this?',
        de: 'Welche zwei Funktionen unterstützen dies am besten?'
      },
      options: [
        { id: 'A', text: { en: 'Feature flags with targeting filters', de: 'Feature Flags mit Zielgruppenfiltern' } },
        { id: 'B', text: { en: 'Application Insights or Azure Monitor metrics to compare cohorts', de: 'Application-Insights- oder Azure-Monitor-Metriken zum Vergleich von Kohorten' } },
        { id: 'C', text: { en: 'Static configuration baked into the image for all users', de: 'Statische Konfiguration, die für alle Benutzer fest ins Image eingebaut ist' } },
        { id: 'D', text: { en: 'Manual SSH changes on each server', de: 'Manuelle SSH-Änderungen auf jedem Server' } }
      ],
      correct: ['A', 'B'],
      explanation: {
        en: 'Feature flags with targeting filters enable progressive exposure for selected user segments. Telemetry from Application Insights or Azure Monitor then lets the team compare engagement, errors, and performance across groups, which is essential for safe A/B-style rollout decisions.',
        de: 'Feature Flags mit Zielgruppenfiltern ermöglichen eine schrittweise Freigabe für ausgewählte Benutzersegmente. Telemetrie aus Application Insights oder Azure Monitor erlaubt dem Team anschließend, Nutzung, Fehler und Leistung zwischen Gruppen zu vergleichen, was für sichere A/B-artige Rollout-Entscheidungen entscheidend ist.'
      },
      hint: {
        en: 'One answer controls exposure, and the other measures the outcome.',
        de: 'Eine Antwort steuert die Freigabe, die andere misst das Ergebnis.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-app-configuration/manage-feature-flags'
    },
    {
      id: 'az400-025',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'medium',
      scenario: null,
      question: {
        en: 'You need a central place to aggregate platform logs and metrics from Azure resources, run KQL queries, and build alert rules and workbooks. Which Azure Monitor component should you use?',
        de: 'Sie benötigen einen zentralen Ort, um Plattformlogs und Metriken aus Azure-Ressourcen zu sammeln, KQL-Abfragen auszuführen und Warnregeln sowie Workbooks zu erstellen. Welche Azure-Monitor-Komponente sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Log Analytics workspace', de: 'Log-Analytics-Arbeitsbereich' } },
        { 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 Deployment Slots', de: 'Azure Deployment Slots' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A Log Analytics workspace is the data platform behind many Azure Monitor capabilities. It centralizes logs, supports KQL queries, and can feed alerts, dashboards, and workbooks for broad observability across Azure resources.',
        de: 'Ein Log-Analytics-Arbeitsbereich ist die Datenplattform hinter vielen Azure-Monitor-Funktionen. Er zentralisiert Logs, unterstützt KQL-Abfragen und kann Warnungen, Dashboards und Workbooks für umfassende Observability über Azure-Ressourcen hinweg bereitstellen.'
      },
      hint: {
        en: 'Choose the Azure Monitor data store and query workspace, not a project management or deployment feature.',
        de: 'Wählen Sie den Azure-Monitor-Datenspeicher und Abfrage-Arbeitsbereich, nicht eine Projektmanagement- oder Bereitstellungsfunktion.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-workspace-overview'
    },
    {
      id: 'az400-026',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'easy',
      scenario: null,
      question: {
        en: 'A Scrum team wants to prevent too many work items from being active at the same time on its Azure Boards Kanban board. Which board capability should the team configure?',
        de: 'Ein Scrum-Team möchte verhindern, dass auf seinem Azure-Boards-Kanban-Board zu viele Arbeitselemente gleichzeitig aktiv sind. Welche Board-Funktion sollte das Team konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Work in progress limits on columns', de: 'WIP-Grenzen für Spalten' } },
        { id: 'B', text: { en: 'A release pipeline approval', de: 'Eine Release-Pipeline-Genehmigung' } },
        { id: 'C', text: { en: 'A service connection', de: 'Eine Serviceverbindung' } },
        { id: 'D', text: { en: 'A build retention policy', de: 'Eine Build-Aufbewahrungsrichtlinie' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Kanban WIP limits are designed to control flow by limiting how much work can sit in a column at one time. They help teams expose bottlenecks and finish work before starting too much new work.',
        de: 'Kanban-WIP-Grenzen sind dafür gedacht, den Fluss zu steuern, indem sie begrenzen, wie viel Arbeit gleichzeitig in einer Spalte liegen darf. Sie helfen Teams, Engpässe sichtbar zu machen und Arbeit abzuschließen, bevor zu viel Neues begonnen wird.'
      },
      hint: {
        en: 'Think about the Kanban setting that controls flow, not a pipeline or security feature.',
        de: 'Denken Sie an die Kanban-Einstellung, die den Fluss steuert, nicht an eine Pipeline- oder Sicherheitsfunktion.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/boards/boards/kanban-overview?view=azure-devops'
    },
    {
      id: 'az400-027',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., several Azure DevOps projects need a new Customer Impact field on bugs and user stories, and the process owner wants to make the change without editing XML process templates.',
        de: 'Bei Fabrikam, Inc.: mehrere Azure-DevOps-Projekte benötigen ein neues Feld Customer Impact für Bugs und User Stories, und der Prozessverantwortliche möchte die Änderung ohne Bearbeitung von XML-Prozessvorlagen umsetzen.'
      },
      question: {
        en: 'What should the process owner use?',
        de: 'Was sollte der Prozessverantwortliche verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'An inherited process', de: 'Einen geerbten Prozess' } },
        { id: 'B', text: { en: 'A variable group', de: 'Eine Variablengruppe' } },
        { id: 'C', text: { en: 'A deployment group', de: 'Eine Bereitstellungsgruppe' } },
        { id: 'D', text: { en: 'A pipeline cache key', de: 'Einen Pipeline-Cache-Schlüssel' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Inherited processes are the modern way to customize work item types, fields, states, and rules in Azure DevOps Services. They let process owners evolve multiple projects in a controlled and supported way without XML customization.',
        de: 'Geerbte Prozesse sind der moderne Weg, Arbeitselementtypen, Felder, Zustände und Regeln in Azure DevOps Services anzupassen. Sie ermöglichen es Prozessverantwortlichen, mehrere Projekte kontrolliert und unterstützt weiterzuentwickeln, ohne XML-Anpassungen zu verwenden.'
      },
      hint: {
        en: 'Choose the Azure Boards customization model for cloud-hosted process changes.',
        de: 'Wählen Sie das Azure-Boards-Anpassungsmodell für cloudgehostete Prozessänderungen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/customize-process?view=azure-devops'
    },
    {
      id: 'az400-028',
      type: 'multiple',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a program manager wants backlog items grouped by owning business unit and also wants each team to assign work to the correct sprint.',
        de: 'Bei Proseware, Inc.: ein Programmmanager möchte Backlogeinträge nach verantwortlicher Geschäftseinheit gruppieren und außerdem, dass jedes Team Arbeit dem richtigen Sprint zuordnet.'
      },
      question: {
        en: 'Which two Azure Boards classification features should the teams use?',
        de: 'Welche zwei Azure-Boards-Klassifizierungsfunktionen sollten die Teams verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Area paths', de: 'Bereichspfade' } },
        { id: 'B', text: { en: 'Iteration paths', de: 'Iterationspfade' } },
        { id: 'C', text: { en: 'Service hooks', de: 'Service Hooks' } },
        { id: 'D', text: { en: 'Secure files', de: 'Sichere Dateien' } }
      ],
      correct: ['A', 'B'],
      explanation: {
        en: 'Area paths are used to group work by team, product, or business ownership. Iteration paths are used to place work into time boxes such as sprints. Together they provide clear ownership and planning cadence.',
        de: 'Bereichspfade werden verwendet, um Arbeit nach Team, Produkt oder Geschäftsverantwortung zu gruppieren. Iterationspfade werden verwendet, um Arbeit in Zeitboxen wie Sprints einzuordnen. Zusammen liefern sie klare Zuständigkeit und Planungsrhythmus.'
      },
      hint: {
        en: 'One feature maps ownership, and the other maps sprint timing.',
        de: 'Eine Funktion bildet Zuständigkeit ab, die andere den Sprint-Zeitplan.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-area-paths-sprints?view=azure-devops'
    },
    {
      id: 'az400-029',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., the operations team wants architecture notes and runbooks stored as Markdown in the same Git repository as the application so documentation changes follow the same pull request workflow as code.',
        de: 'Bei Contoso, Ltd.: das Betriebsteam möchte Architekturnotizen und Runbooks als Markdown im selben Git-Repository wie die Anwendung speichern, damit Dokumentationsänderungen denselben Pull-Request-Workflow wie Code durchlaufen.'
      },
      question: {
        en: 'Which Azure DevOps documentation option should you choose?',
        de: 'Welche Azure-DevOps-Dokumentationsoption sollten Sie wählen?'
      },
      options: [
        { id: 'A', text: { en: 'Publish the repository as a code wiki', de: 'Das Repository als Code Wiki veröffentlichen' } },
        { id: 'B', text: { en: 'Use only release notes', de: 'Ausschließlich Release Notes verwenden' } },
        { id: 'C', text: { en: 'Store the content in pipeline variables', de: 'Den Inhalt in Pipeline-Variablen speichern' } },
        { id: 'D', text: { en: 'Create a dashboard widget', de: 'Ein Dashboard-Widget erstellen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A code wiki keeps Markdown content in Git so the docs can use branching, pull requests, review history, and versioning just like application code. That is the best fit when documentation must evolve with the repository.',
        de: 'Ein Code Wiki hält Markdown-Inhalte in Git, sodass Dokumentation Branches, Pull Requests, Review-Historie und Versionierung genau wie Anwendungscode nutzen kann. Das passt am besten, wenn sich Dokumentation zusammen mit dem Repository entwickeln soll.'
      },
      hint: {
        en: 'The requirement is documentation that lives in Git and follows the same PR process as code.',
        de: 'Die Anforderung ist Dokumentation, die in Git lebt und denselben PR-Prozess wie Code durchläuft.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/project/wiki/wiki-create-repo?view=azure-devops'
    },
    {
      id: 'az400-030',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Fabrikam, Inc., stakeholders want automatic Microsoft Teams notifications whenever a release is deployed or a work item is updated to a critical state.',
        de: 'Bei Fabrikam, Inc.: stakeholder möchten automatische Microsoft-Teams-Benachrichtigungen erhalten, wenn ein Release bereitgestellt wird oder ein Arbeitselement in einen kritischen Zustand wechselt.'
      },
      question: {
        en: 'Which Azure DevOps integration capability should you configure?',
        de: 'Welche Azure-DevOps-Integrationsfunktion sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Service hooks or a Teams connector', de: 'Service Hooks oder einen Teams-Connector' } },
        { id: 'B', text: { en: 'A Git hook on each workstation', de: 'Einen Git-Hook auf jedem Arbeitsplatz' } },
        { id: 'C', text: { en: 'An artifact feed', de: 'Einen Artefakt-Feed' } },
        { id: 'D', text: { en: 'A release tag in Git', de: 'Ein Release-Tag in Git' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Service hooks are built to publish Azure DevOps events to external systems such as Teams, webhooks, and other collaboration endpoints. They reduce manual status communication and keep stakeholders informed automatically.',
        de: 'Service Hooks sind dafür vorgesehen, Azure-DevOps-Ereignisse an externe Systeme wie Teams, Webhooks und andere Kollaborationsendpunkte zu veröffentlichen. Sie reduzieren manuelle Statuskommunikation und informieren Stakeholder automatisch.'
      },
      hint: {
        en: 'Choose the event integration feature, not a source control or package management feature.',
        de: 'Wählen Sie die Ereignis-Integrationsfunktion und keine Quellcode- oder Paketverwaltungsfunktion.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/service-hooks/overview?view=azure-devops'
    },
    {
      id: 'az400-031',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Proseware, Inc., a GitHub engineering organization wants a dedicated place for long-form design conversations, community questions, and architecture proposals that do not fit the lifecycle of a bug or task.',
        de: 'Bei Proseware, Inc.: eine GitHub-Engineering-Organisation möchte einen dedizierten Ort für längere Designdiskussionen, Community-Fragen und Architekturvorschläge, die nicht in den Lebenszyklus eines Bugs oder einer Aufgabe passen.'
      },
      question: {
        en: 'Which GitHub feature best fits this requirement?',
        de: 'Welche GitHub-Funktion passt am besten zu dieser Anforderung?'
      },
      options: [
        { id: 'A', text: { en: 'GitHub Discussions', de: 'GitHub Discussions' } },
        { id: 'B', text: { en: 'Git tags', de: 'Git-Tags' } },
        { id: 'C', text: { en: 'Git submodules', de: 'Git-Submodule' } },
        { id: 'D', text: { en: 'Git LFS', de: 'Git LFS' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'GitHub Discussions is designed for open-ended, threaded, community-style conversations. It is a better fit than issues when the goal is knowledge sharing, proposals, and questions rather than trackable work items.',
        de: 'GitHub Discussions ist für offene, strukturierte, Community-artige Gespräche ausgelegt. Es ist besser geeignet als Issues, wenn das Ziel Wissensaustausch, Vorschläge und Fragen sind und nicht nachverfolgbare Arbeitselemente.'
      },
      hint: {
        en: 'Think about the GitHub feature for threaded conversations instead of tracked work.',
        de: 'Denken Sie an die GitHub-Funktion für strukturierte Gespräche statt für nachverfolgte Arbeit.'
      },
      reference: 'https://docs.github.com/en/discussions'
    },
    {
      id: 'az400-032',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: {
        en: 'Proseware, Inc. links GitHub repositories to Azure Boards. Product owners want work items updated automatically from developer commits and pull requests.',
        de: 'Proseware, Inc. verknüpft GitHub-Repositories mit Azure Boards. Product Owner möchten, dass Arbeitselemente automatisch durch Entwickler-Commits und Pull Requests aktualisiert werden.'
      },
      question: {
        en: 'What should developers include in commits and pull requests to create the traceability link?',
        de: 'Was sollten Entwickler in Commits und Pull Requests angeben, um die Nachverfolgbarkeitsverknüpfung zu erstellen?'
      },
      options: [
        { id: 'A', text: { en: 'The Azure Boards work item syntax such as AB#123', de: 'Die Azure-Boards-Arbeitselementsyntax wie AB#123' } },
        { id: 'B', text: { en: 'Only the branch name', de: 'Nur den Branchnamen' } },
        { id: 'C', text: { en: 'The agent pool name', de: 'Den Namen des Agent-Pools' } },
        { id: 'D', text: { en: 'The pipeline cache key', de: 'Den Pipeline-Cache-Schlüssel' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'When GitHub is connected to Azure Boards, mentioning work items with the Azure Boards syntax such as AB#123 creates and strengthens traceability between code changes and tracked work. That supports reporting, auditing, and release communication.',
        de: 'Wenn GitHub mit Azure Boards verbunden ist, erzeugt die Nennung von Arbeitselementen mit der Azure-Boards-Syntax wie AB#123 eine Nachverfolgbarkeit zwischen Codeänderungen und erfasster Arbeit. Das unterstützt Berichte, Audits und Release-Kommunikation.'
      },
      hint: {
        en: 'The answer is the work item reference format, not a branch or pipeline setting.',
        de: 'Die Antwort ist das Referenzformat für Arbeitselemente und keine Branch- oder Pipeline-Einstellung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/boards/github/link-to-from-github?view=azure-devops'
    },
    {
      id: 'az400-033',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., an agile coach wants to measure whether teams are getting faster at moving work from start to completion over time without exporting data to another tool.',
        de: 'Bei Contoso, Ltd.: ein Agile Coach möchte messen, ob Teams im Laufe der Zeit schneller werden, Arbeit von Beginn bis Abschluss zu bewegen, ohne Daten in ein anderes Tool zu exportieren.'
      },
      question: {
        en: 'Which Azure Boards capability should the coach use?',
        de: 'Welche Azure-Boards-Funktion sollte der Coach verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Analytics widgets such as lead time and cycle time', de: 'Analytics-Widgets wie Lead Time und Cycle Time' } },
        { id: 'B', text: { en: 'A deployment group', de: 'Eine Bereitstellungsgruppe' } },
        { id: 'C', text: { en: 'A secure file', de: 'Eine sichere Datei' } },
        { id: 'D', text: { en: 'A service connection', de: 'Eine Serviceverbindung' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Azure Boards analytics widgets surface flow metrics such as lead time and cycle time directly in dashboards. They are built for teams that want process insights without moving the data to a separate reporting platform first.',
        de: 'Azure-Boards-Analytics-Widgets stellen Flussmetriken wie Lead Time und Cycle Time direkt in Dashboards dar. Sie sind für Teams gedacht, die Prozesseinblicke gewinnen möchten, ohne die Daten zuvor in eine separate Reporting-Plattform zu verschieben.'
      },
      hint: {
        en: 'Choose the built-in reporting capability for process flow metrics.',
        de: 'Wählen Sie die integrierte Reporting-Funktion für Prozessflussmetriken.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/report/dashboards/overview?view=azure-devops'
    },
    {
      id: 'az400-034',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Fabrikam, Inc., leadership wants one Azure DevOps page that combines build status, release health, backlog charts, and team metrics for a product line.',
        de: 'Bei Fabrikam, Inc.: die Leitung möchte eine Azure-DevOps-Seite, die Build-Status, Release-Gesundheit, Backlog-Diagramme und Teammetriken für eine Produktlinie kombiniert.'
      },
      question: {
        en: 'Which feature should you use?',
        de: 'Welche Funktion sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Dashboards with widgets', de: 'Dashboards mit Widgets' } },
        { id: 'B', text: { en: 'Git reflog', de: 'Git reflog' } },
        { id: 'C', text: { en: 'A package feed', de: 'Einen Paket-Feed' } },
        { id: 'D', text: { en: 'A variable group', de: 'Eine Variablengruppe' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Azure DevOps dashboards are meant to aggregate data from Boards, Pipelines, Test Plans, and other sources into a single customizable view. Widgets make them ideal for executive and operational reporting.',
        de: 'Azure-DevOps-Dashboards sind dafür gedacht, Daten aus Boards, Pipelines, Test Plans und anderen Quellen in einer anpassbaren Ansicht zusammenzuführen. Widgets machen sie ideal für Management- und Betriebsberichte.'
      },
      hint: {
        en: 'Think of the feature that aggregates visual status widgets across services.',
        de: 'Denken Sie an die Funktion, die visuelle Status-Widgets über mehrere Dienste hinweg zusammenführt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/report/dashboards/overview?view=azure-devops'
    },
    {
      id: 'az400-035',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a support organization wants a searchable knowledge base inside Azure DevOps for incident procedures, but the content does not need to stay in the same Git repository as the application.',
        de: 'Bei Proseware, Inc.: eine Support-Organisation möchte eine durchsuchbare Wissensbasis innerhalb von Azure DevOps für Incident-Prozeduren, aber der Inhalt muss nicht im selben Git-Repository wie die Anwendung bleiben.'
      },
      question: {
        en: 'Which wiki option is the best fit?',
        de: 'Welche Wiki-Option passt am besten?'
      },
      options: [
        { id: 'A', text: { en: 'A project wiki', de: 'Ein Projekt-Wiki' } },
        { id: 'B', text: { en: 'A Git tag', de: 'Ein Git-Tag' } },
        { id: 'C', text: { en: 'A deployment job', de: 'Einen Deployment-Job' } },
        { id: 'D', text: { en: 'A NuGet feed', de: 'Einen NuGet-Feed' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A project wiki provides a managed documentation space inside Azure DevOps without requiring the content to live in the same application repository. That makes it a good fit for operational knowledge bases and shared team documentation.',
        de: 'Ein Projekt-Wiki bietet einen verwalteten Dokumentationsbereich innerhalb von Azure DevOps, ohne dass der Inhalt im selben Anwendungsrepository liegen muss. Dadurch eignet es sich gut für operative Wissensdatenbanken und gemeinsame Teamdokumentation.'
      },
      hint: {
        en: 'The content should stay in Azure DevOps, but not necessarily in the app repository.',
        de: 'Der Inhalt soll in Azure DevOps bleiben, aber nicht zwingend im App-Repository.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/project/wiki/wiki-create-project-wiki?view=azure-devops'
    },
    {
      id: 'az400-036',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Contoso, Ltd., a product owner wants an email whenever a work item in the Escalated state is assigned to their team.',
        de: 'Bei Contoso, Ltd.: ein Product Owner möchte eine E-Mail erhalten, wenn ein Arbeitselement im Zustand Escalated seinem Team zugewiesen wird.'
      },
      question: {
        en: 'Which Azure DevOps capability should you configure?',
        de: 'Welche Azure-DevOps-Funktion sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'A notification subscription', de: 'Ein Benachrichtigungsabonnement' } },
        { id: 'B', text: { en: 'A pipeline artifact', de: 'Ein Pipeline-Artefakt' } },
        { id: 'C', text: { en: 'A Git submodule', de: 'Ein Git-Submodul' } },
        { id: 'D', text: { en: 'A container registry webhook', de: 'Einen Container-Registry-Webhook' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Notification subscriptions are used to send email or other alerts when Azure DevOps events match selected filters. They are the simplest way to keep roles informed about work item changes without manual polling.',
        de: 'Benachrichtigungsabonnements werden verwendet, um E-Mails oder andere Hinweise zu senden, wenn Azure-DevOps-Ereignisse ausgewählten Filtern entsprechen. Sie sind der einfachste Weg, Rollen über Arbeitselementänderungen informiert zu halten, ohne manuell nachsehen zu müssen.'
      },
      hint: {
        en: 'This is an event notification requirement, not a source control requirement.',
        de: 'Dies ist eine Anforderung zur Ereignisbenachrichtigung und keine Anforderung an die Quellcodeverwaltung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/notifications/about-notifications?view=azure-devops'
    },
    {
      id: 'az400-037',
      type: 'single',
      domain: { en: 'Configure Processes and Communications', de: 'Prozesse und Kommunikation konfigurieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a release train engineer wants to see where work is piling up across the team workflow and identify bottlenecks over time.',
        de: 'Bei Fabrikam, Inc.: ein Release-Train-Engineer möchte sehen, wo sich Arbeit im Teamworkflow staut, und Engpässe im Zeitverlauf erkennen.'
      },
      question: {
        en: 'Which report best supports this goal?',
        de: 'Welcher Bericht unterstützt dieses Ziel am besten?'
      },
      options: [
        { id: 'A', text: { en: 'Cumulative flow diagram', de: 'Kumulatives Flussdiagramm' } },
        { id: 'B', text: { en: 'Git blame', de: 'Git blame' } },
        { id: 'C', text: { en: 'A release tag list', de: 'Eine Liste von Release-Tags' } },
        { id: 'D', text: { en: 'An agent capability report', de: 'Ein Bericht zu Agent-Fähigkeiten' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A cumulative flow diagram shows how work accumulates in each workflow state over time. It is one of the most useful reports for spotting queue growth, bottlenecks, and unstable flow in agile delivery.',
        de: 'Ein kumulatives Flussdiagramm zeigt, wie sich Arbeit im Zeitverlauf in jedem Workflow-Zustand ansammelt. Es ist einer der nützlichsten Berichte, um Warteschlangenwachstum, Engpässe und instabilen Fluss in der agilen Lieferung zu erkennen.'
      },
      hint: {
        en: 'Choose the report that visualizes work distribution across workflow states over time.',
        de: 'Wählen Sie den Bericht, der die Verteilung von Arbeit über Workflow-Zustände im Zeitverlauf visualisiert.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/report/dashboards/cumulative-flow?view=azure-devops'
    },
    {
      id: 'az400-038',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a SaaS team uses GitHub and deploys many times per day. They want a lightweight model where developers branch from main, open a pull request, merge quickly, and keep the main branch always releasable.',
        de: 'Bei Fabrikam, Inc.: ein SaaS-Team verwendet GitHub und stellt viele Male pro Tag bereit. Es möchte ein schlankes Modell, bei dem Entwickler von main abzweigen, einen Pull Request öffnen, schnell mergen und den main-Branch stets releasefähig halten.'
      },
      question: {
        en: 'Which branching model is the best fit?',
        de: 'Welches Branching-Modell passt am besten?'
      },
      options: [
        { id: 'A', text: { en: 'GitHub Flow', de: 'GitHub Flow' } },
        { id: 'B', text: { en: 'Long-lived GitFlow release branches for every feature', de: 'Langlebige GitFlow-Release-Branches für jedes Feature' } },
        { id: 'C', text: { en: 'One permanent branch per developer', de: 'Ein dauerhafter Branch pro Entwickler' } },
        { id: 'D', text: { en: 'Manual ZIP snapshots only', de: 'Nur manuelle ZIP-Snapshots' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'GitHub Flow is optimized for frequent integration, short-lived branches, pull requests, and a releasable default branch. That matches high-deployment SaaS teams better than heavy release branching models.',
        de: 'GitHub Flow ist für häufige Integration, kurzlebige Branches, Pull Requests und einen releasefähigen Standard-Branch optimiert. Das passt zu SaaS-Teams mit hoher Bereitstellungsfrequenz besser als schwere Release-Branching-Modelle.'
      },
      hint: {
        en: 'Choose the simple PR-based model centered on an always-deployable main branch.',
        de: 'Wählen Sie das einfache PR-basierte Modell mit einem stets bereitstellbaren main-Branch.'
      },
      reference: 'https://docs.github.com/en/get-started/using-github/github-flow'
    },
    {
      id: 'az400-039',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'A GitHub repository at Contoso, Ltd. must block direct pushes to main, require pull requests, and ensure CI checks pass before merge.',
        de: 'Ein GitHub-Repository bei Contoso, Ltd. muss direkte Pushes auf main blockieren, Pull Requests erzwingen und sicherstellen, dass CI-Prüfungen vor dem Merge erfolgreich sind.'
      },
      question: {
        en: 'What should you configure?',
        de: 'Was sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'A branch protection rule for main', de: 'Eine Branch-Protection-Regel für main' } },
        { id: 'B', text: { en: 'A local post-commit hook', de: 'Einen lokalen Post-Commit-Hook' } },
        { id: 'C', text: { en: 'A Git stash policy', de: 'Eine Git-Stash-Richtlinie' } },
        { id: 'D', text: { en: 'A package retention policy', de: 'Eine Paket-Aufbewahrungsrichtlinie' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Branch protection rules in GitHub centrally enforce pull requests, required status checks, and restrictions on direct pushes. That makes them the correct control for protecting the main branch.',
        de: 'Branch-Protection-Regeln in GitHub erzwingen zentral Pull Requests, erforderliche Statusprüfungen und Einschränkungen für direkte Pushes. Damit sind sie die richtige Kontrolle zum Schutz des main-Branches.'
      },
      hint: {
        en: 'The requirement must be enforced on the server side for the protected branch.',
        de: 'Die Anforderung muss serverseitig für den geschützten Branch erzwungen werden.'
      },
      reference: 'https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches'
    },
    {
      id: 'az400-040',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., changes under the /database folder in a GitHub repository must always be reviewed by the database engineering team before merge.',
        de: 'Bei Contoso, Ltd.: änderungen im Ordner /database eines GitHub-Repositories müssen vor dem Merge immer vom Datenbank-Engineering-Team überprüft werden.'
      },
      question: {
        en: 'Which GitHub capability should you use?',
        de: 'Welche GitHub-Funktion sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'CODEOWNERS', de: 'CODEOWNERS' } },
        { id: 'B', text: { en: 'Git LFS', de: 'Git LFS' } },
        { id: 'C', text: { en: 'Git stash', de: 'Git stash' } },
        { id: 'D', text: { en: 'A release tag', de: 'Ein Release-Tag' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A CODEOWNERS file maps paths to owners and can automatically request or require review from the correct team when matching files change. That is the standard way to route file-specific reviews in GitHub.',
        de: 'Eine CODEOWNERS-Datei ordnet Pfade Eigentümern zu und kann automatisch eine Überprüfung durch das richtige Team anfordern oder erzwingen, wenn passende Dateien geändert werden. Das ist der Standardweg, um dateispezifische Reviews in GitHub zu steuern.'
      },
      hint: {
        en: 'Think about path-based reviewer ownership.',
        de: 'Denken Sie an pfadbasierte Reviewer-Zuständigkeit.'
      },
      reference: 'https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners'
    },
    {
      id: 'az400-041',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'A team at Fabrikam, Inc. wants every completed pull request to appear as one clean commit on main so the history stays short and easy to read.',
        de: 'Ein Team bei Fabrikam, Inc. möchte, dass jeder abgeschlossene Pull Request als ein sauberer Commit auf main erscheint, damit die Historie kurz und leicht lesbar bleibt.'
      },
      question: {
        en: 'Which merge option should the team prefer?',
        de: 'Welche Merge-Option sollte das Team bevorzugen?'
      },
      options: [
        { id: 'A', text: { en: 'Squash and merge', de: 'Squash and merge' } },
        { id: 'B', text: { en: 'Rebase without merge', de: 'Rebase ohne Merge' } },
        { id: 'C', text: { en: 'Reset hard', de: 'Reset hard' } },
        { id: 'D', text: { en: 'Git stash pop', de: 'Git stash pop' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Squash merge combines the pull request commits into one commit on the target branch. This keeps history compact and is common when teams want a simple, readable main branch history.',
        de: 'Squash Merge kombiniert die Commits eines Pull Requests zu einem Commit auf dem Ziel-Branch. Dadurch bleibt die Historie kompakt, was häufig gewünscht ist, wenn Teams einen einfachen und lesbaren main-Branch haben möchten.'
      },
      hint: {
        en: 'Choose the merge method that produces a single commit on the target branch.',
        de: 'Wählen Sie die Merge-Methode, die einen einzelnen Commit auf dem Ziel-Branch erzeugt.'
      },
      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-042',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a critical fix was committed on a release branch, and you need to apply only that specific change to main without merging all other release branch commits.',
        de: 'Bei Fabrikam, Inc.: ein kritischer Fix wurde auf einem Release-Branch committet, und Sie müssen nur diese spezifische Änderung auf main anwenden, ohne alle anderen Commits des Release-Branches zu mergen.'
      },
      question: {
        en: 'Which Git command should you use?',
        de: 'Welchen Git-Befehl sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'git cherry-pick', de: 'git cherry-pick' } },
        { id: 'B', text: { en: 'git clean', de: 'git clean' } },
        { id: 'C', text: { en: 'git stash', de: 'git stash' } },
        { id: 'D', text: { en: 'git branch -d', de: 'git branch -d' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'git cherry-pick applies one or more selected commits onto another branch. It is the right tool when you must move a specific fix without bringing over unrelated branch history.',
        de: 'git cherry-pick wendet einen oder mehrere ausgewählte Commits auf einen anderen Branch an. Es ist das richtige Werkzeug, wenn ein bestimmter Fix übertragen werden muss, ohne die übrige Branch-Historie mitzunehmen.'
      },
      hint: {
        en: 'The goal is to move one exact commit, not to merge the full branch.',
        de: 'Das Ziel ist, genau einen Commit zu übertragen und nicht den gesamten Branch zu mergen.'
      },
      reference: 'https://git-scm.com/docs/git-cherry-pick'
    },
    {
      id: 'az400-043',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Proseware, Inc., a repository contains very large binary design files that change occasionally, and cloning the repository has become slow and storage-heavy.',
        de: 'Bei Proseware, Inc.: ein Repository enthält sehr große binäre Designdateien, die sich gelegentlich ändern, und das Klonen des Repositories ist langsam und speicherintensiv geworden.'
      },
      question: {
        en: 'Which Git-related solution is designed for this scenario?',
        de: 'Welche Git-bezogene Lösung ist für dieses Szenario vorgesehen?'
      },
      options: [
        { id: 'A', text: { en: 'Git LFS', de: 'Git LFS' } },
        { id: 'B', text: { en: 'Git rebase', de: 'Git rebase' } },
        { id: 'C', text: { en: 'Git notes', de: 'Git notes' } },
        { id: 'D', text: { en: 'Git bisect', de: 'Git bisect' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Git LFS stores large files outside normal Git object storage while keeping lightweight pointers in the repository. That helps repositories remain manageable when they contain large binaries.',
        de: 'Git LFS speichert große Dateien außerhalb des normalen Git-Objektspeichers, während im Repository nur schlanke Verweise liegen. So bleiben Repositories mit großen Binärdateien besser handhabbar.'
      },
      hint: {
        en: 'Choose the solution built specifically for large binary files.',
        de: 'Wählen Sie die Lösung, die speziell für große Binärdateien entwickelt wurde.'
      },
      reference: 'https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage'
    },
    {
      id: 'az400-044',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'Developers at Proseware, Inc. want a local Git hook that runs formatting and lint checks before a commit is created.',
        de: 'Entwickler bei Proseware, Inc. möchten einen lokalen Git-Hook, der Formatierungs- und Lint-Prüfungen ausführt, bevor ein Commit erstellt wird.'
      },
      question: {
        en: 'Which hook should they use?',
        de: 'Welchen Hook sollten sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'pre-commit', de: 'pre-commit' } },
        { id: 'B', text: { en: 'post-merge', de: 'post-merge' } },
        { id: 'C', text: { en: 'pre-push', de: 'pre-push' } },
        { id: 'D', text: { en: 'post-checkout', de: 'post-checkout' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'The pre-commit hook runs before Git creates the commit object. That makes it the right place for local formatting, linting, and validation that should happen before the commit is recorded.',
        de: 'Der pre-commit-Hook läuft, bevor Git das Commit-Objekt erstellt. Dadurch ist er der richtige Ort für lokale Formatierung, Linting und Validierung, die vor dem Commit stattfinden sollen.'
      },
      hint: {
        en: 'The check must happen before the commit is finalized.',
        de: 'Die Prüfung muss stattfinden, bevor der Commit endgültig erstellt wird.'
      },
      reference: 'https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks'
    },
    {
      id: 'az400-045',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., every commit message must contain a work item identifier that matches the team standard before the commit is accepted on the local machine.',
        de: 'Bei Contoso, Ltd.: jede Commit-Nachricht muss eine Arbeitselement-ID enthalten, die dem Teamstandard entspricht, bevor der Commit lokal akzeptiert wird.'
      },
      question: {
        en: 'Which Git hook is the best place to enforce this?',
        de: 'Welcher Git-Hook ist der beste Ort, um dies zu erzwingen?'
      },
      options: [
        { id: 'A', text: { en: 'commit-msg', de: 'commit-msg' } },
        { id: 'B', text: { en: 'post-commit', de: 'post-commit' } },
        { id: 'C', text: { en: 'post-rewrite', de: 'post-rewrite' } },
        { id: 'D', text: { en: 'post-checkout', de: 'post-checkout' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'The commit-msg hook is specifically intended to inspect and validate the commit message before the commit completes. It is the correct local hook for enforcing message patterns and required identifiers.',
        de: 'Der commit-msg-Hook ist speziell dafür vorgesehen, die Commit-Nachricht zu prüfen und zu validieren, bevor der Commit abgeschlossen wird. Er ist der richtige lokale Hook, um Nachrichtenmuster und erforderliche Kennungen zu erzwingen.'
      },
      hint: {
        en: 'Focus on the hook that validates the commit message text itself.',
        de: 'Konzentrieren Sie sich auf den Hook, der den Text der Commit-Nachricht selbst validiert.'
      },
      reference: 'https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks'
    },
    {
      id: 'az400-046',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a developer has a short-lived feature branch that has not been shared yet. Main has moved forward, and the developer wants to replay the local commits on top of the latest main to reduce merge noise.',
        de: 'Bei Fabrikam, Inc.: ein Entwickler hat einen kurzlebigen Feature-Branch, der noch nicht geteilt wurde. Main hat sich weiterentwickelt, und der Entwickler möchte die lokalen Commits auf den neuesten Stand von main neu aufsetzen, um Merge-Rauschen zu verringern.'
      },
      question: {
        en: 'Which Git technique should the developer use?',
        de: 'Welche Git-Technik sollte der Entwickler verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Rebase the feature branch onto main', de: 'Den Feature-Branch auf main rebasen' } },
        { id: 'B', text: { en: 'Delete the branch and start again', de: 'Den Branch löschen und neu beginnen' } },
        { id: 'C', text: { en: 'Use git clean -fd', de: 'git clean -fd verwenden' } },
        { id: 'D', text: { en: 'Create a tag', de: 'Ein Tag erstellen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Rebasing replays local commits on top of a newer base branch. For an unshared short-lived branch, that can reduce merge commits and keep the eventual pull request history cleaner.',
        de: 'Rebase setzt lokale Commits auf einen neueren Basis-Branch neu auf. Für einen ungeteilten kurzlebigen Branch kann dies Merge-Commits reduzieren und die spätere Pull-Request-Historie sauberer halten.'
      },
      hint: {
        en: 'The branch is still local, so rewriting its history is acceptable.',
        de: 'Der Branch ist noch lokal, daher ist das Umschreiben seiner Historie vertretbar.'
      },
      reference: 'https://git-scm.com/book/en/v2/Git-Branching-Rebasing'
    },
    {
      id: 'az400-047',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Proseware, Inc., a monorepo contains hundreds of services. One developer only needs files for service-a and wants to avoid populating the working directory with the rest of the repository.',
        de: 'Bei Proseware, Inc.: ein Monorepo enthält Hunderte von Diensten. Ein Entwickler benötigt nur die Dateien für service-a und möchte vermeiden, dass das Arbeitsverzeichnis mit dem Rest des Repositories gefüllt wird.'
      },
      question: {
        en: 'Which Git capability should the developer use?',
        de: 'Welche Git-Funktion sollte der Entwickler verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Sparse checkout', de: 'Sparse Checkout' } },
        { id: 'B', text: { en: 'Git blame', de: 'Git blame' } },
        { id: 'C', text: { en: 'Annotated tags', de: 'Annotierte Tags' } },
        { id: 'D', text: { en: 'Cherry-pick', de: 'Cherry-pick' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Sparse checkout lets a developer populate the working tree with only selected paths from a repository. It is valuable in large monorepos where a contributor needs only a subset of files.',
        de: 'Sparse Checkout ermöglicht es einem Entwickler, den Arbeitsbaum nur mit ausgewählten Pfaden eines Repositories zu füllen. Das ist besonders wertvoll in großen Monorepos, wenn nur ein Teil der Dateien benötigt wird.'
      },
      hint: {
        en: 'The goal is to check out only part of the repository working tree.',
        de: 'Das Ziel ist, nur einen Teil des Arbeitsbaums des Repositories auszuchecken.'
      },
      reference: 'https://git-scm.com/docs/git-sparse-checkout'
    },
    {
      id: 'az400-048',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., a compliance policy says every commit merged into main in GitHub must be cryptographically attributable to the author.',
        de: 'Bei Contoso, Ltd.: eine Compliance-Richtlinie verlangt, dass jeder in GitHub nach main gemergte Commit kryptografisch dem Autor zugeordnet werden kann.'
      },
      question: {
        en: 'Which repository protection should you enable?',
        de: 'Welche Repository-Schutzfunktion sollten Sie aktivieren?'
      },
      options: [
        { id: 'A', text: { en: 'Require signed commits', de: 'Signierte Commits verlangen' } },
        { id: 'B', text: { en: 'Enable Git LFS', de: 'Git LFS aktivieren' } },
        { id: 'C', text: { en: 'Use draft pull requests only', de: 'Nur Draft-Pull-Requests verwenden' } },
        { id: 'D', text: { en: 'Disable branch history', de: 'Branch-Historie deaktivieren' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Requiring signed commits helps ensure commits are cryptographically verified and attributable to known identities. This supports stronger provenance and auditability for protected branches.',
        de: 'Das Erzwingen signierter Commits hilft sicherzustellen, dass Commits kryptografisch verifiziert und bekannten Identitäten zugeordnet werden können. Das unterstützt eine stärkere Herkunftsnachweisbarkeit und Auditierbarkeit für geschützte Branches.'
      },
      hint: {
        en: 'The policy is about commit authenticity, not review style.',
        de: 'Die Richtlinie betrifft die Echtheit von Commits und nicht den Review-Stil.'
      },
      reference: 'https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification'
    },
    {
      id: 'az400-049',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a faulty merge commit is already on a shared branch that other developers have pulled. You need to undo its effect without rewriting shared history.',
        de: 'Bei Fabrikam, Inc.: ein fehlerhafter Merge-Commit befindet sich bereits auf einem gemeinsam genutzten Branch, den andere Entwickler bereits gepullt haben. Sie müssen seine Wirkung rückgängig machen, ohne die gemeinsame Historie umzuschreiben.'
      },
      question: {
        en: 'What should you do?',
        de: 'Was sollten Sie tun?'
      },
      options: [
        { id: 'A', text: { en: 'Create a revert commit for the merge', de: 'Einen Revert-Commit für den Merge erstellen' } },
        { id: 'B', text: { en: 'Run git reset --hard on the shared branch and force push', de: 'git reset --hard auf dem gemeinsamen Branch ausführen und force-pushen' } },
        { id: 'C', text: { en: 'Delete the repository', de: 'Das Repository löschen' } },
        { id: 'D', text: { en: 'Use git stash', de: 'git stash verwenden' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Reverting the merge creates a new commit that safely undoes the change while preserving published history. That is much safer than resetting and force-pushing a branch that others already use.',
        de: 'Das Zurücksetzen per Revert erzeugt einen neuen Commit, der die Änderung sicher rückgängig macht, während die veröffentlichte Historie erhalten bleibt. Das ist deutlich sicherer, als einen Branch zurückzusetzen und zu force-pushen, den andere bereits verwenden.'
      },
      hint: {
        en: 'The branch is shared, so avoid rewriting history.',
        de: 'Der Branch wird gemeinsam genutzt, daher sollte die Historie nicht umgeschrieben werden.'
      },
      reference: 'https://git-scm.com/docs/git-revert'
    },
    {
      id: 'az400-050',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Proseware, Inc., an open-source project accepts contributions from external developers but does not want to grant them direct write access to the central repository.',
        de: 'Bei Proseware, Inc.: ein Open-Source-Projekt akzeptiert Beiträge von externen Entwicklern, möchte ihnen aber keinen direkten Schreibzugriff auf das zentrale Repository geben.'
      },
      question: {
        en: 'Which collaboration model should the project use?',
        de: 'Welches Kollaborationsmodell sollte das Projekt verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Fork and pull request workflow', de: 'Fork-und-Pull-Request-Workflow' } },
        { id: 'B', text: { en: 'Direct commits to main', de: 'Direkte Commits auf main' } },
        { id: 'C', text: { en: 'Shared force-push access', de: 'Gemeinsamer Force-Push-Zugriff' } },
        { id: 'D', text: { en: 'Git stash handoff', de: 'Übergabe per Git stash' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'The fork and pull request model lets contributors work in their own repositories and submit changes back for review. That keeps the central repository protected while still enabling collaboration.',
        de: 'Das Fork-und-Pull-Request-Modell erlaubt Mitwirkenden, in ihren eigenen Repositories zu arbeiten und Änderungen zur Überprüfung zurückzusenden. So bleibt das zentrale Repository geschützt und Zusammenarbeit ist dennoch möglich.'
      },
      hint: {
        en: 'External contributors should propose changes without writing directly to the protected repo.',
        de: 'Externe Mitwirkende sollten Änderungen vorschlagen, ohne direkt in das geschützte Repository zu schreiben.'
      },
      reference: 'https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks'
    },
    {
      id: 'az400-051',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., an Azure Repos team wants existing pull request approvals to be cleared whenever the author pushes new commits after review feedback.',
        de: 'Contoso, Ltd. – Ein Azure-Repos-Team möchte, dass bestehende Pull-Request-Genehmigungen zurückgesetzt werden, sobald der Autor nach Review-Feedback neue Commits pusht.'
      },
      question: {
        en: 'Which branch policy setting should the team configure?',
        de: 'Welche Branchrichtlinien-Einstellung sollte das Team konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Reset code reviewer votes when there are new changes', de: 'Reviewer-Stimmen bei neuen Änderungen zurücksetzen' } },
        { id: 'B', text: { en: 'Allow squash merge only', de: 'Nur Squash-Merge zulassen' } },
        { id: 'C', text: { en: 'Disable comment threads', de: 'Kommentar-Threads deaktivieren' } },
        { id: 'D', text: { en: 'Allow force push on main', de: 'Force Push auf main zulassen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Azure Repos branch policies can automatically reset reviewer votes when new changes are pushed. This ensures approvals reflect the current code rather than an earlier version of the pull request.',
        de: 'Azure-Repos-Branchrichtlinien können Reviewer-Stimmen automatisch zurücksetzen, wenn neue Änderungen gepusht werden. Dadurch stellen Sie sicher, dass Genehmigungen den aktuellen Code und nicht eine frühere Version des Pull Requests widerspiegeln.'
      },
      hint: {
        en: 'The control is about keeping approvals valid after source changes.',
        de: 'Die Kontrolle dient dazu, Genehmigungen nach Quellcodeänderungen gültig zu halten.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops'
    },
    {
      id: 'az400-052',
      type: 'single',
      domain: { en: 'Design and Implement Source Control', de: 'Quellcodeverwaltung entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Contoso, Ltd., a release manager wants immutable named markers in Git for versions such as v2.3.0 so builds and deployments can always reference the exact release point.',
        de: 'Bei Contoso, Ltd.: ein Release Manager möchte unveränderliche benannte Markierungen in Git für Versionen wie v2.3.0, damit Builds und Bereitstellungen immer auf den exakten Release-Punkt verweisen können.'
      },
      question: {
        en: 'What should the release manager create?',
        de: 'Was sollte der Release Manager erstellen?'
      },
      options: [
        { id: 'A', text: { en: 'Annotated tags', de: 'Annotierte Tags' } },
        { id: 'B', text: { en: 'Temporary stashes', de: 'Temporäre Stashes' } },
        { id: 'C', text: { en: 'Detached HEAD states', de: 'Detached-HEAD-Zustände' } },
        { id: 'D', text: { en: 'Untracked files', de: 'Nicht verfolgte Dateien' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Annotated tags are a standard Git mechanism for marking important points such as releases. They provide stable version identifiers that pipelines and teams can reference later.',
        de: 'Annotierte Tags sind ein Standardmechanismus in Git, um wichtige Punkte wie Releases zu markieren. Sie liefern stabile Versionskennzeichen, auf die Pipelines und Teams später verweisen können.'
      },
      hint: {
        en: 'Think about the Git feature used to label release versions permanently.',
        de: 'Denken Sie an die Git-Funktion, mit der Release-Versionen dauerhaft gekennzeichnet werden.'
      },
      reference: 'https://git-scm.com/book/en/v2/Git-Basics-Tagging'
    },
    {
      id: 'az400-053',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Fabrikam, Inc., a YAML pipeline needs one logical execution boundary that usually gets its own agent and can contain several sequential tasks such as restore, build, and test.',
        de: 'Bei Fabrikam, Inc.: eine YAML-Pipeline benötigt eine logische Ausführungsgrenze, die in der Regel ihren eigenen Agent erhält und mehrere aufeinanderfolgende Aufgaben wie Restore, Build und Test enthalten kann.'
      },
      question: {
        en: 'Which Azure Pipelines concept is this?',
        de: 'Welches Azure-Pipelines-Konzept ist dies?'
      },
      options: [
        { id: 'A', text: { en: 'Job', de: 'Job' } },
        { id: 'B', text: { en: 'Repository', de: 'Repository' } },
        { id: 'C', text: { en: 'Tag', de: 'Tag' } },
        { id: 'D', text: { en: 'Hook', de: 'Hook' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A job is the unit that runs on an agent or server and contains multiple steps. Stages group jobs, while steps are the individual tasks or scripts inside a job.',
        de: 'Ein Job ist die Einheit, die auf einem Agent oder Server läuft und mehrere Schritte enthält. Stages gruppieren Jobs, während Schritte die einzelnen Tasks oder Skripte innerhalb eines Jobs sind.'
      },
      hint: {
        en: 'Think of the unit between a stage and an individual step.',
        de: 'Denken Sie an die Einheit zwischen einer Stage und einem einzelnen Schritt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/key-pipelines-concepts?view=azure-devops'
    },
    {
      id: 'az400-054',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a deployment pipeline should start automatically only after a separate library pipeline finishes successfully and publishes a validated artifact.',
        de: 'Bei Proseware, Inc.: eine Deployment-Pipeline soll automatisch erst starten, nachdem eine separate Library-Pipeline erfolgreich abgeschlossen wurde und ein validiertes Artefakt veröffentlicht hat.'
      },
      question: {
        en: 'Which YAML feature should you use?',
        de: 'Welche YAML-Funktion sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'A pipeline resource with a completion trigger', de: 'Eine Pipeline-Ressource mit Abschluss-Trigger' } },
        { id: 'B', text: { en: 'A git stash', de: 'Ein Git stash' } },
        { id: 'C', text: { en: 'A secure file', de: 'Eine sichere Datei' } },
        { id: 'D', text: { en: 'A code wiki', de: 'Ein Code Wiki' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Pipeline resources let one pipeline consume artifacts from another and can trigger execution when the upstream pipeline completes. That is the standard pattern for chaining validated build outputs into later delivery flows.',
        de: 'Pipeline-Ressourcen erlauben es einer Pipeline, Artefakte aus einer anderen zu nutzen, und können die Ausführung auslösen, wenn die vorgelagerte Pipeline abgeschlossen ist. Das ist das Standardmuster, um validierte Build-Ergebnisse in nachgelagerte Delivery-Flows zu übernehmen.'
      },
      hint: {
        en: 'The trigger source is another pipeline, not a repository change.',
        de: 'Die Trigger-Quelle ist eine andere Pipeline und keine Repository-Änderung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/resources?view=azure-devops'
    },
    {
      id: 'az400-055',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Contoso, Ltd., a monorepo contains many services, but the pipeline for service-a should run only when files under src/service-a change.',
        de: 'Bei Contoso, Ltd.: ein Monorepo enthält viele Dienste, aber die Pipeline für service-a soll nur laufen, wenn sich Dateien unter src/service-a ändern.'
      },
      question: {
        en: 'Which trigger setting should you configure?',
        de: 'Welche Trigger-Einstellung sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Path filters', de: 'Pfadfilter' } },
        { id: 'B', text: { en: 'ManualValidation', de: 'ManualValidation' } },
        { id: 'C', text: { en: 'Deployment slots', de: 'Bereitstellungsslots' } },
        { id: 'D', text: { en: 'CODEOWNERS', de: 'CODEOWNERS' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Path filters restrict CI triggers to changes in selected folders or files. That reduces unnecessary pipeline runs in monorepos and focuses validation on the impacted service.',
        de: 'Pfadfilter beschränken CI-Trigger auf Änderungen in ausgewählten Ordnern oder Dateien. Das reduziert unnötige Pipeline-Läufe in Monorepos und konzentriert die Validierung auf den betroffenen Dienst.'
      },
      hint: {
        en: 'The requirement is to trigger based on changed paths.',
        de: 'Die Anforderung ist, anhand geänderter Pfade auszulösen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops'
    },
    {
      id: 'az400-056',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a Node.js library must be validated against Node 18, 20, and 22 in the same pipeline definition.',
        de: 'Bei Fabrikam, Inc.: eine Node.js-Bibliothek muss innerhalb derselben Pipelinedefinition gegen Node 18, 20 und 22 validiert werden.'
      },
      question: {
        en: 'Which YAML strategy should you use?',
        de: 'Welche YAML-Strategie sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'A matrix strategy', de: 'Eine Matrix-Strategie' } },
        { id: 'B', text: { en: 'A git subtree', de: 'Einen Git Subtree' } },
        { id: 'C', text: { en: 'A code wiki', de: 'Ein Code Wiki' } },
        { id: 'D', text: { en: 'A deployment group', de: 'Eine Bereitstellungsgruppe' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A matrix strategy runs the same job multiple times with different variable combinations such as runtime versions or operating systems. That is ideal for multi-version test validation.',
        de: 'Eine Matrix-Strategie führt denselben Job mehrfach mit unterschiedlichen Variablenkombinationen wie Laufzeitversionen oder Betriebssystemen aus. Das ist ideal für die Validierung gegen mehrere Versionen.'
      },
      hint: {
        en: 'Choose the feature for one job definition repeated with different inputs.',
        de: 'Wählen Sie die Funktion, mit der eine Jobdefinition mit verschiedenen Eingaben wiederholt wird.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops'
    },
    {
      id: 'az400-057',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., pipeline runs are slow because npm dependencies are downloaded repeatedly even when package-lock.json has not changed.',
        de: 'Bei Proseware, Inc.: pipeline-Läufe sind langsam, weil npm-Abhängigkeiten wiederholt heruntergeladen werden, obwohl sich package-lock.json nicht geändert hat.'
      },
      question: {
        en: 'Which Azure Pipelines feature should you add?',
        de: 'Welche Azure-Pipelines-Funktion sollten Sie hinzufügen?'
      },
      options: [
        { id: 'A', text: { en: 'Pipeline caching keyed by the lock file', de: 'Pipeline-Caching mit Schlüssel auf Basis der Lock-Datei' } },
        { id: 'B', text: { en: 'A manual approval', de: 'Eine manuelle Genehmigung' } },
        { id: 'C', text: { en: 'A service hook', de: 'Einen Service Hook' } },
        { id: 'D', text: { en: 'A wiki page', de: 'Eine Wiki-Seite' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Pipeline caching stores reusable dependency content between runs. When the cache key includes the lock file, dependencies are restored quickly while still changing automatically when the dependency graph changes.',
        de: 'Pipeline-Caching speichert wiederverwendbare Abhängigkeitsinhalte zwischen Läufen. Wenn der Cache-Schlüssel die Lock-Datei enthält, werden Abhängigkeiten schnell wiederhergestellt und ändern sich trotzdem automatisch, wenn sich der Abhängigkeitsgraph ändert.'
      },
      hint: {
        en: 'The goal is to speed up repeated dependency restoration.',
        de: 'Das Ziel ist, wiederholte Abhängigkeitswiederherstellung zu beschleunigen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops'
    },
    {
      id: 'az400-058',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Contoso, Ltd., several pipelines need the same nonsecret configuration values such as region names and resource identifiers managed in one place.',
        de: 'Bei Contoso, Ltd.: mehrere Pipelines benötigen dieselben nicht geheimen Konfigurationswerte wie Regionsnamen und Ressourcenkennungen, die zentral verwaltet werden sollen.'
      },
      question: {
        en: 'Which Azure DevOps feature should you use?',
        de: 'Welche Azure-DevOps-Funktion sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Variable groups', de: 'Variablengruppen' } },
        { id: 'B', text: { en: 'Secure files', de: 'Sichere Dateien' } },
        { id: 'C', text: { en: 'Git submodules', de: 'Git-Submodule' } },
        { id: 'D', text: { en: 'Deployment groups', de: 'Bereitstellungsgruppen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Variable groups centralize shared values that can be referenced by many pipelines. They reduce duplication and make it easier to update common configuration in one place.',
        de: 'Variablengruppen zentralisieren gemeinsam genutzte Werte, auf die viele Pipelines verweisen können. Sie reduzieren Duplikate und erleichtern es, gemeinsame Konfiguration an einer Stelle zu aktualisieren.'
      },
      hint: {
        en: 'Think about shared pipeline configuration, not source control content.',
        de: 'Denken Sie an gemeinsam genutzte Pipeline-Konfiguration und nicht an Quellcodeinhalt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops'
    },
    {
      id: 'az400-059',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Fabrikam, Inc., a build job calculates a Docker image tag dynamically, and a later deployment stage must use exactly that generated value.',
        de: 'Bei Fabrikam, Inc.: ein Build-Job berechnet ein Docker-Image-Tag dynamisch, und eine spätere Deployment-Stage muss genau diesen erzeugten Wert verwenden.'
      },
      question: {
        en: 'How should you pass the value forward?',
        de: 'Wie sollten Sie den Wert weitergeben?'
      },
      options: [
        { id: 'A', text: { en: 'Set an output variable and consume it in the downstream stage', de: 'Eine Output-Variable setzen und in der nachgelagerten Stage verwenden' } },
        { id: 'B', text: { en: 'Write the value into the README', de: 'Den Wert in die README schreiben' } },
        { id: 'C', text: { en: 'Create a git tag during every build', de: 'Bei jedem Build ein Git-Tag erstellen' } },
        { id: 'D', text: { en: 'Use a dashboard widget', de: 'Ein Dashboard-Widget verwenden' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Output variables are the supported way to emit a value from one job or stage and reference it later in the pipeline. They are well suited for dynamically calculated values such as image tags or artifact names.',
        de: 'Output-Variablen sind der unterstützte Weg, einen Wert aus einem Job oder einer Stage auszugeben und später in der Pipeline zu referenzieren. Sie eignen sich gut für dynamisch berechnete Werte wie Image-Tags oder Artefaktnamen.'
      },
      hint: {
        en: 'The value is generated during execution, so it must flow through the pipeline runtime.',
        de: 'Der Wert wird während der Ausführung erzeugt und muss daher zur Laufzeit durch die Pipeline fließen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/set-variables-scripts?view=azure-devops'
    },
    {
      id: 'az400-060',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a mobile pipeline needs to use a signing certificate file that must be stored securely and downloaded only during the build.',
        de: 'Bei Proseware, Inc.: eine Mobile-Pipeline muss eine Signaturzertifikatsdatei verwenden, die sicher gespeichert und nur während des Builds heruntergeladen werden darf.'
      },
      question: {
        en: 'Which Azure DevOps library feature is intended for this?',
        de: 'Welche Azure-DevOps-Library-Funktion ist dafür vorgesehen?'
      },
      options: [
        { id: 'A', text: { en: 'Secure files', de: 'Sichere Dateien' } },
        { id: 'B', text: { en: 'Work item tags', de: 'Arbeitselement-Tags' } },
        { id: 'C', text: { en: 'Git notes', de: 'Git notes' } },
        { id: 'D', text: { en: 'Delivery Plans', de: 'Delivery Plans' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Secure files are designed for protected binary assets such as certificates, provisioning profiles, and SSH keys that pipelines may need temporarily. They are more appropriate than storing files in source control.',
        de: 'Sichere Dateien sind für geschützte Binärartefakte wie Zertifikate, Provisioning-Profile und SSH-Schlüssel gedacht, die Pipelines vorübergehend benötigen können. Sie sind geeigneter, als solche Dateien in der Quellcodeverwaltung zu speichern.'
      },
      hint: {
        en: 'The requirement is a protected file artifact, not a text variable.',
        de: 'Die Anforderung betrifft ein geschütztes Datei-Artefakt und keine Textvariable.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/library/secure-files?view=azure-devops'
    },
    {
      id: 'az400-061',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., a pipeline deploys infrastructure only to one resource group. Security wants the authentication object limited to that scope and nothing broader.',
        de: 'Bei Contoso, Ltd.: eine Pipeline stellt Infrastruktur nur in eine Ressourcengruppe bereit. Das Sicherheitsteam möchte, dass das Authentifizierungsobjekt auf genau diesen Bereich beschränkt ist und nicht breiter wirkt.'
      },
      question: {
        en: 'How should you configure the Azure connection?',
        de: 'Wie sollten Sie die Azure-Verbindung konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Create a service connection scoped to the target resource group', de: 'Eine auf die Ziel-Ressourcengruppe begrenzte Serviceverbindung erstellen' } },
        { id: 'B', text: { en: 'Use the owner role at tenant root', de: 'Die Owner-Rolle auf Mandantenstammebene verwenden' } },
        { id: 'C', text: { en: 'Store an admin password in YAML', de: 'Ein Admin-Kennwort in YAML speichern' } },
        { id: 'D', text: { en: 'Share one global account across all projects', de: 'Ein globales Konto für alle Projekte freigeben' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Service connections should be scoped as narrowly as possible to follow least privilege. If the pipeline deploys only to one resource group, the connection should be limited to that resource group instead of using broader access.',
        de: 'Serviceverbindungen sollten gemäß Least Privilege so eng wie möglich abgegrenzt werden. Wenn die Pipeline nur in eine Ressourcengruppe bereitstellt, sollte die Verbindung auf diese Ressourcengruppe beschränkt sein und keinen breiteren Zugriff verwenden.'
      },
      hint: {
        en: 'The authentication boundary should match the deployment scope.',
        de: 'Die Authentifizierungsgrenze sollte dem Bereitstellungsumfang entsprechen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops'
    },
    {
      id: 'az400-062',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., build jobs must reach private on-premises resources that are not accessible from Microsoft-hosted agents.',
        de: 'Bei Fabrikam, Inc.: build-Jobs müssen private lokale Ressourcen erreichen, die von Microsoft-gehosteten Agenten nicht zugänglich sind.'
      },
      question: {
        en: 'What type of agent should you use?',
        de: 'Welchen Agent-Typ sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'A self-hosted agent', de: 'Einen selbstgehosteten Agent' } },
        { id: 'B', text: { en: 'A service hook', de: 'Einen Service Hook' } },
        { id: 'C', text: { en: 'A project wiki', de: 'Ein Projekt-Wiki' } },
        { id: 'D', text: { en: 'A git submodule', de: 'Ein Git-Submodul' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Self-hosted agents run inside your network and can access private resources such as internal package feeds, firewalled servers, and legacy systems. Microsoft-hosted agents usually cannot reach such endpoints.',
        de: 'Selbstgehostete Agenten laufen in Ihrem Netzwerk und können auf private Ressourcen wie interne Paket-Feeds, durch Firewalls geschützte Server und Legacy-Systeme zugreifen. Microsoft-gehostete Agenten erreichen solche Endpunkte in der Regel nicht.'
      },
      hint: {
        en: 'The key requirement is private network connectivity during pipeline execution.',
        de: 'Die zentrale Anforderung ist private Netzwerkkonnektivität während der Pipeline-Ausführung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops'
    },
    {
      id: 'az400-063',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'A team at Fabrikam, Inc. wants every build to run with the same toolchain versions regardless of the underlying agent image.',
        de: 'Ein Team bei Fabrikam, Inc. möchte, dass jeder Build mit denselben Toolchain-Versionen läuft, unabhängig vom zugrunde liegenden Agent-Image.'
      },
      question: {
        en: 'Which pipeline execution model best supports this?',
        de: 'Welches Pipeline-Ausführungsmodell unterstützt dies am besten?'
      },
      options: [
        { id: 'A', text: { en: 'Container jobs', de: 'Container-Jobs' } },
        { id: 'B', text: { en: 'Project wikis', de: 'Projekt-Wikis' } },
        { id: 'C', text: { en: 'Git notes', de: 'Git notes' } },
        { id: 'D', text: { en: 'Area paths', de: 'Bereichspfade' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Container jobs let you run pipeline steps inside a specified container image, which gives consistent runtime tools and dependencies across agents. This is useful when builds must be reproducible.',
        de: 'Container-Jobs erlauben es, Pipelineschritte innerhalb eines angegebenen Container-Images auszuführen und liefern dadurch konsistente Laufzeitwerkzeuge und Abhängigkeiten über verschiedene Agenten hinweg. Das ist nützlich, wenn Builds reproduzierbar sein müssen.'
      },
      hint: {
        en: 'The goal is a consistent build environment defined as an image.',
        de: 'Das Ziel ist eine konsistente Build-Umgebung, die als Image definiert ist.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=azure-devops'
    },
    {
      id: 'az400-064',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Proseware, Inc., a pipeline should compile the application once and then let later stages download that exact build output for testing and deployment.',
        de: 'Bei Proseware, Inc.: eine Pipeline soll die Anwendung einmal kompilieren und spätere Stages sollen genau dieses Build-Ergebnis für Tests und Bereitstellung herunterladen können.'
      },
      question: {
        en: 'What should the build stage publish?',
        de: 'Was sollte die Build-Stage veröffentlichen?'
      },
      options: [
        { id: 'A', text: { en: 'Pipeline artifacts', de: 'Pipeline-Artefakte' } },
        { id: 'B', text: { en: 'Area paths', de: 'Bereichspfade' } },
        { id: 'C', text: { en: 'Draft pull requests', de: 'Draft-Pull-Requests' } },
        { id: 'D', text: { en: 'Git LFS pointers', de: 'Git-LFS-Zeiger' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Pipeline artifacts are meant to move build outputs between jobs and stages efficiently. Publishing them once and reusing them later supports build-once, deploy-many delivery patterns.',
        de: 'Pipeline-Artefakte sind dafür gedacht, Build-Ergebnisse effizient zwischen Jobs und Stages zu übertragen. Sie einmal zu veröffentlichen und später wiederzuverwenden unterstützt Build-once-deploy-many-Liefermuster.'
      },
      hint: {
        en: 'Choose the built-in mechanism for sharing compiled outputs across stages.',
        de: 'Wählen Sie den integrierten Mechanismus, um kompilierte Ergebnisse zwischen Stages zu teilen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/pipeline-artifacts?view=azure-devops'
    },
    {
      id: 'az400-065',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., the release team wants deployment history, environment approvals, and traceability recorded against dev, test, and prod targets in a YAML pipeline.',
        de: 'Bei Contoso, Ltd.: das Release-Team möchte Bereitstellungsverlauf, Umgebungs-Genehmigungen und Nachverfolgbarkeit gegen dev-, test- und prod-Ziele in einer YAML-Pipeline aufzeichnen.'
      },
      question: {
        en: 'Which Azure Pipelines construct should you use?',
        de: 'Welche Azure-Pipelines-Konstruktion sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Deployment jobs targeting environments', de: 'Deployment-Jobs, die auf Umgebungen abzielen' } },
        { id: 'B', text: { en: 'Git submodules', de: 'Git-Submodule' } },
        { id: 'C', text: { en: 'A CODEOWNERS file', de: 'Eine CODEOWNERS-Datei' } },
        { id: 'D', text: { en: 'A project wiki', de: 'Ein Projekt-Wiki' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Deployment jobs integrate with environments so Azure DevOps can track where deployments happened, who approved them, and what checks were applied. That gives much better release governance than a generic job.',
        de: 'Deployment-Jobs integrieren sich mit Umgebungen, sodass Azure DevOps nachverfolgen kann, wo Bereitstellungen stattgefunden haben, wer sie genehmigt hat und welche Prüfungen angewendet wurden. Das liefert deutlich bessere Release-Governance als ein generischer Job.'
      },
      hint: {
        en: 'The requirement is deployment traceability tied to named environments.',
        de: 'Die Anforderung ist Bereitstellungs-Nachverfolgbarkeit, die an benannte Umgebungen gebunden ist.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops'
    },
    {
      id: 'az400-066',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a production stage must run only when every previous stage succeeded and the source branch is main.',
        de: 'Bei Fabrikam, Inc.: eine Produktions-Stage darf nur laufen, wenn alle vorherigen Stages erfolgreich waren und der Quell-Branch main ist.'
      },
      question: {
        en: 'How should you enforce this in YAML?',
        de: 'Wie sollten Sie dies in YAML erzwingen?'
      },
      options: [
        { id: 'A', text: { en: 'Use a condition such as succeeded() and a branch equality check', de: 'Eine Bedingung wie succeeded() und eine Branch-Gleichheitsprüfung verwenden' } },
        { id: 'B', text: { en: 'Use git stash before the stage', de: 'Vor der Stage git stash verwenden' } },
        { id: 'C', text: { en: 'Increase the timeout', de: 'Das Timeout erhöhen' } },
        { id: 'D', text: { en: 'Disable approvals', de: 'Genehmigungen deaktivieren' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'YAML conditions let you control whether a stage runs based on prior outcome and runtime context such as branch name. This is the standard way to keep production deployment logic explicit and auditable.',
        de: 'YAML-Bedingungen erlauben es, zu steuern, ob eine Stage abhängig vom vorherigen Ergebnis und vom Laufzeitkontext wie dem Branchnamen ausgeführt wird. Das ist der Standardweg, um Produktionsbereitstellungslogik explizit und auditierbar zu halten.'
      },
      hint: {
        en: 'Use an execution condition, not a source control command.',
        de: 'Verwenden Sie eine Ausführungsbedingung und keinen Quellcodeverwaltungsbefehl.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops'
    },
    {
      id: 'az400-067',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'A team at Proseware, Inc. wants a full regression and security scan to run every night even if no new commits were pushed that day.',
        de: 'Ein Team bei Proseware, Inc. möchte, dass jede Nacht ein vollständiger Regressions- und Sicherheitsscan läuft, selbst wenn an diesem Tag keine neuen Commits gepusht wurden.'
      },
      question: {
        en: 'Which trigger type should the team configure?',
        de: 'Welchen Trigger-Typ sollte das Team konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'A scheduled trigger', de: 'Einen geplanten Trigger' } },
        { id: 'B', text: { en: 'A path filter only', de: 'Nur einen Pfadfilter' } },
        { id: 'C', text: { en: 'A pull request draft', de: 'Einen Draft-Pull-Request' } },
        { id: 'D', text: { en: 'A manual variable group', de: 'Eine manuelle Variablengruppe' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Scheduled triggers run pipelines according to a defined cadence such as nightly or weekly. They are appropriate when validation must occur regardless of whether code changed recently.',
        de: 'Geplante Trigger führen Pipelines nach einem definierten Zeitplan wie jede Nacht oder wöchentlich aus. Sie sind geeignet, wenn Validierung unabhängig davon stattfinden muss, ob sich Code kürzlich geändert hat.'
      },
      hint: {
        en: 'This run must be time-based, not change-based.',
        de: 'Dieser Lauf muss zeitbasiert und nicht änderungsbasiert sein.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/scheduled-triggers?view=azure-devops'
    },
    {
      id: 'az400-068',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'The platform team at Contoso, Ltd. stores reusable pipeline templates in a dedicated repository and wants application pipelines to reference those templates centrally instead of copying YAML into every repo.',
        de: 'Das Plattformteam von Contoso, Ltd. speichert wiederverwendbare Pipeline-Templates in einem dedizierten Repository und möchte, dass Anwendungspipelines diese Templates zentral referenzieren, anstatt YAML in jedes Repository zu kopieren.'
      },
      question: {
        en: 'Which YAML mechanism should application teams use?',
        de: 'Welchen YAML-Mechanismus sollten Anwendungsteams verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'A repository resource with template references', de: 'Eine Repository-Ressource mit Template-Referenzen' } },
        { id: 'B', text: { en: 'A git stash workflow', de: 'Einen Git-Stash-Workflow' } },
        { id: 'C', text: { en: 'A dashboard widget', de: 'Ein Dashboard-Widget' } },
        { id: 'D', text: { en: 'A code wiki export', de: 'Einen Code-Wiki-Export' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Repository resources let a pipeline consume templates from another repository. This enables central template governance and avoids YAML duplication across many application repositories.',
        de: 'Repository-Ressourcen erlauben es einer Pipeline, Templates aus einem anderen Repository zu nutzen. Das ermöglicht zentrale Template-Governance und vermeidet YAML-Duplikate über viele Anwendungs-Repositories hinweg.'
      },
      hint: {
        en: 'The templates live in another repository, so the pipeline must reference an external repo resource.',
        de: 'Die Templates liegen in einem anderen Repository, daher muss die Pipeline eine externe Repository-Ressource referenzieren.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops'
    },
    {
      id: 'az400-069',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a pipeline consumer must choose the target cloud region before the run starts, and the selected value should shape template expansion and stage inclusion.',
        de: 'Bei Proseware, Inc.: ein Nutzer der Pipeline muss die Ziel-Cloud-Region vor dem Start auswählen, und der gewählte Wert soll die Template-Erweiterung und Stage-Auswahl beeinflussen.'
      },
      question: {
        en: 'Should you use variables or parameters for this value?',
        de: 'Sollten Sie für diesen Wert Variablen oder Parameter verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Parameters', de: 'Parameter' } },
        { id: 'B', text: { en: 'Classic release notes', de: 'Klassische Release Notes' } },
        { id: 'C', text: { en: 'Git tags', de: 'Git-Tags' } },
        { id: 'D', text: { en: 'Pipeline artifacts', de: 'Pipeline-Artefakte' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Parameters are evaluated earlier and are intended for values that must affect template expansion, stage inclusion, and queue-time choices. Variables are better for values consumed during execution rather than shaping the pipeline structure.',
        de: 'Parameter werden früher ausgewertet und sind für Werte gedacht, die Template-Erweiterung, Stage-Auswahl und Entscheidungen zur Queue-Zeit beeinflussen müssen. Variablen eignen sich besser für Werte, die während der Ausführung genutzt werden, ohne die Struktur der Pipeline zu verändern.'
      },
      hint: {
        en: 'The value must influence pipeline structure before execution begins.',
        de: 'Der Wert muss die Pipeline-Struktur beeinflussen, bevor die Ausführung beginnt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/runtime-parameters?view=azure-devops'
    },
    {
      id: 'az400-070',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Contoso, Ltd., a template author needs to loop over a list of environments and conditionally insert jobs before runtime starts.',
        de: 'Bei Contoso, Ltd.: ein Template-Autor muss über eine Liste von Umgebungen iterieren und Jobs bedingt einfügen, bevor die Laufzeit beginnt.'
      },
      question: {
        en: 'Which Azure Pipelines expression syntax should be used?',
        de: 'Welche Azure-Pipelines-Ausdruckssyntax sollte verwendet werden?'
      },
      options: [
        { id: 'A', text: { en: 'Template expressions with ${{ }}', de: 'Template-Ausdrücke mit ${{ }}' } },
        { id: 'B', text: { en: 'Runtime variables with $( ) only', de: 'Nur Laufzeitvariablen mit $( )' } },
        { id: 'C', text: { en: 'Git hooks', de: 'Git-Hooks' } },
        { id: 'D', text: { en: 'Markdown tables', de: 'Markdown-Tabellen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Template expressions using ${{ }} are evaluated during template expansion before runtime. They are required when you need to generate or omit jobs and stages based on parameters or template logic.',
        de: 'Template-Ausdrücke mit ${{ }} werden während der Template-Erweiterung vor der Laufzeit ausgewertet. Sie sind erforderlich, wenn Jobs und Stages auf Basis von Parametern oder Template-Logik erzeugt oder ausgelassen werden sollen.'
      },
      hint: {
        en: 'The pipeline structure must change before runtime starts.',
        de: 'Die Pipeline-Struktur muss sich ändern, bevor die Laufzeit beginnt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/template-expressions?view=azure-devops'
    },
    {
      id: 'az400-071',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Fabrikam, Inc., a new AKS release should go to a small share of users first, then progressively expand after health checks and telemetry look good.',
        de: 'Bei Fabrikam, Inc.: ein neues AKS-Release soll zunächst an einen kleinen Teil der Benutzer gehen und danach schrittweise ausgeweitet werden, wenn Health Checks und Telemetrie gut aussehen.'
      },
      question: {
        en: 'Which deployment strategy best matches this requirement?',
        de: 'Welche Bereitstellungsstrategie passt am besten zu dieser Anforderung?'
      },
      options: [
        { id: 'A', text: { en: 'Canary deployment', de: 'Canary-Bereitstellung' } },
        { id: 'B', text: { en: 'Big bang deployment', de: 'Big-Bang-Bereitstellung' } },
        { id: 'C', text: { en: 'Manual FTP deployment', de: 'Manuelle FTP-Bereitstellung' } },
        { id: 'D', text: { en: 'Direct replace-all deployment', de: 'Direkte Alles-ersetzen-Bereitstellung' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Canary deployment is built for progressive exposure. It limits blast radius by sending only a fraction of traffic to the new version before expanding rollout after validation.',
        de: 'Die Canary-Bereitstellung ist für progressive Freigabe gedacht. Sie begrenzt den Schaden im Fehlerfall, indem zunächst nur ein Teil des Traffics an die neue Version geleitet wird und die Ausweitung erst nach erfolgreicher Validierung erfolgt.'
      },
      hint: {
        en: 'Choose the strategy that starts with a small audience and grows safely.',
        de: 'Wählen Sie die Strategie, die mit einer kleinen Zielgruppe beginnt und sich sicher ausweitet.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops'
    },
    {
      id: 'az400-072',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., an application uses two equivalent production environments behind traffic management. The team wants to deploy to the idle environment, validate it fully, and then switch all traffic at once.',
        de: 'Bei Fabrikam, Inc. verwendet zwei gleichwertige Produktionsumgebungen hinter Traffic-Management. Das Team möchte in die inaktive Umgebung bereitstellen, diese vollständig validieren und dann den gesamten Traffic auf einmal umschalten.'
      },
      question: {
        en: 'Which deployment strategy is being described?',
        de: 'Welche Bereitstellungsstrategie wird beschrieben?'
      },
      options: [
        { id: 'A', text: { en: 'Blue-green deployment', de: 'Blue-Green-Bereitstellung' } },
        { id: 'B', text: { en: 'Rolling deployment', de: 'Rolling Deployment' } },
        { id: 'C', text: { en: 'Patch Tuesday deployment', de: 'Patch-Tuesday-Bereitstellung' } },
        { id: 'D', text: { en: 'Git flow deployment', de: 'Git-Flow-Bereitstellung' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Blue-green deployment keeps two production-ready environments and switches traffic when the new environment is proven ready. It supports fast rollback because traffic can be switched back if needed.',
        de: 'Blue-Green-Bereitstellung hält zwei produktionsbereite Umgebungen vor und schaltet den Traffic um, wenn die neue Umgebung als bereit validiert wurde. Sie unterstützt schnelles Rollback, da der Traffic bei Bedarf zurückgeschaltet werden kann.'
      },
      hint: {
        en: 'The entire traffic switch happens after validating the alternate environment.',
        de: 'Der gesamte Traffic wird nach Validierung der alternativen Umgebung umgeschaltet.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/architecture/example-scenario/apps/devops-blue-green-deployment'
    },
    {
      id: 'az400-073',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a release must update a fleet of VMs in small batches so most instances stay online during the rollout.',
        de: 'Bei Proseware, Inc.: ein Release muss eine Flotte von VMs in kleinen Chargen aktualisieren, sodass die meisten Instanzen während des Rollouts online bleiben.'
      },
      question: {
        en: 'Which deployment strategy should you use?',
        de: 'Welche Bereitstellungsstrategie sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Rolling deployment', de: 'Rolling Deployment' } },
        { id: 'B', text: { en: 'Blue-green deployment only', de: 'Ausschließlich Blue-Green-Bereitstellung' } },
        { id: 'C', text: { en: 'Big bang deployment', de: 'Big-Bang-Bereitstellung' } },
        { id: 'D', text: { en: 'Manual FTP deployment', de: 'Manuelle FTP-Bereitstellung' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Rolling deployment updates targets in batches so some capacity remains available throughout the rollout. This is a common fit for VM and server fleets where gradual replacement lowers risk.',
        de: 'Ein Rolling Deployment aktualisiert Ziele in Chargen, sodass während des Rollouts weiterhin Kapazität verfügbar bleibt. Das passt häufig zu VM- und Serverflotten, bei denen schrittweiser Austausch das Risiko senkt.'
      },
      hint: {
        en: 'The deployment should proceed batch by batch through the fleet.',
        de: 'Die Bereitstellung soll Charge für Charge durch die Flotte laufen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops'
    },
    {
      id: 'az400-074',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., several GitHub repositories need to call the same centrally managed CI workflow that includes build, test, and package jobs.',
        de: 'Bei Contoso, Ltd.: mehrere GitHub-Repositories müssen denselben zentral verwalteten CI-Workflow aufrufen, der Build-, Test- und Paket-Jobs enthält.'
      },
      question: {
        en: 'Which GitHub Actions feature should you use?',
        de: 'Welche GitHub-Actions-Funktion sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'A reusable workflow triggered with workflow_call', de: 'Einen wiederverwendbaren Workflow mit workflow_call' } },
        { id: 'B', text: { en: 'A git submodule', de: 'Ein Git-Submodul' } },
        { id: 'C', text: { en: 'A release tag', de: 'Ein Release-Tag' } },
        { id: 'D', text: { en: 'A CODEOWNERS file', de: 'Eine CODEOWNERS-Datei' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Reusable workflows encapsulate entire workflows and can be invoked from many repositories with inputs and secrets passed in a controlled way. They are the best fit for standardized CI logic spanning multiple jobs.',
        de: 'Wiederverwendbare Workflows kapseln vollständige Workflows und können aus vielen Repositories mit kontrolliert übergebenen Eingaben und Geheimnissen aufgerufen werden. Sie sind die beste Wahl für standardisierte CI-Logik über mehrere Jobs hinweg.'
      },
      hint: {
        en: 'The reuse unit is an entire workflow, not just a few steps.',
        de: 'Die Wiederverwendungseinheit ist ein vollständiger Workflow und nicht nur einige Schritte.'
      },
      reference: 'https://docs.github.com/en/actions/using-workflows/reusing-workflows'
    },
    {
      id: 'az400-075',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., within one repository, multiple workflows repeat the same small sequence of steps to set up a tool and run a standardized command.',
        de: 'Bei Fabrikam, Inc.: innerhalb eines Repositories wiederholen mehrere Workflows dieselbe kleine Schrittfolge, um ein Werkzeug einzurichten und einen standardisierten Befehl auszuführen.'
      },
      question: {
        en: 'Which GitHub Actions reuse mechanism is the best fit?',
        de: 'Welcher Wiederverwendungsmechanismus in GitHub Actions passt am besten?'
      },
      options: [
        { id: 'A', text: { en: 'A composite action', de: 'Eine Composite Action' } },
        { id: 'B', text: { en: 'A release branch', de: 'Ein Release-Branch' } },
        { id: 'C', text: { en: 'A git stash', de: 'Ein Git stash' } },
        { id: 'D', text: { en: 'A wiki page', de: 'Eine Wiki-Seite' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Composite actions package a reusable sequence of steps. They are ideal when you want to standardize a repeated step block without defining an entire reusable workflow.',
        de: 'Composite Actions kapseln eine wiederverwendbare Schrittfolge. Sie sind ideal, wenn Sie einen wiederholten Schrittblock standardisieren möchten, ohne einen vollständigen wiederverwendbaren Workflow zu definieren.'
      },
      hint: {
        en: 'This is step reuse inside workflows, not reuse of complete workflows.',
        de: 'Hier geht es um die Wiederverwendung von Schritten innerhalb von Workflows, nicht um vollständige Workflows.'
      },
      reference: 'https://docs.github.com/en/actions/creating-actions/creating-a-composite-action'
    },
    {
      id: 'az400-076',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a GitHub Actions workflow deploys to production. The security team requires a manual approval before the production job can access secrets and continue.',
        de: 'Bei Proseware, Inc.: ein GitHub-Actions-Workflow stellt in die Produktion bereit. Das Sicherheitsteam verlangt eine manuelle Genehmigung, bevor der Produktionsjob auf Geheimnisse zugreifen und fortfahren darf.'
      },
      question: {
        en: 'What should you configure?',
        de: 'Was sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'A protected environment with required reviewers', de: 'Eine geschützte Umgebung mit erforderlichen Reviewern' } },
        { id: 'B', text: { en: 'A git tag convention', de: 'Eine Git-Tag-Konvention' } },
        { id: 'C', text: { en: 'A CODEOWNERS file only', de: 'Nur eine CODEOWNERS-Datei' } },
        { id: 'D', text: { en: 'A repository label', de: 'Ein Repository-Label' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'GitHub environments can require reviewers before deployment jobs proceed and before environment secrets become available. This is the correct control for gated production deployments in GitHub Actions.',
        de: 'GitHub-Umgebungen können Reviewer verlangen, bevor Deployment-Jobs fortfahren und bevor Umgebungsgeheimnisse verfügbar werden. Das ist die richtige Kontrolle für gesteuerte Produktionsbereitstellungen in GitHub Actions.'
      },
      hint: {
        en: 'The approval must protect the deployment environment itself.',
        de: 'Die Genehmigung muss die Bereitstellungsumgebung selbst schützen.'
      },
      reference: 'https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment'
    },
    {
      id: 'az400-077',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Contoso, Ltd., a build job in GitHub Actions creates compiled binaries that a later job in the same workflow needs to test and package.',
        de: 'Bei Contoso, Ltd.: ein Build-Job in GitHub Actions erzeugt kompilierte Binärdateien, die ein späterer Job im selben Workflow testen und paketieren muss.'
      },
      question: {
        en: 'Which feature should you use to pass the files between jobs?',
        de: 'Welche Funktion sollten Sie verwenden, um die Dateien zwischen Jobs zu übergeben?'
      },
      options: [
        { id: 'A', text: { en: 'Upload and download workflow artifacts', de: 'Workflow-Artefakte hochladen und herunterladen' } },
        { id: 'B', text: { en: 'Git stash between runners', de: 'Git stash zwischen Runnern' } },
        { id: 'C', text: { en: 'A wiki attachment', de: 'Einen Wiki-Anhang' } },
        { id: 'D', text: { en: 'A branch protection rule', de: 'Eine Branch-Protection-Regel' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Workflow artifacts in GitHub Actions are designed to persist and transfer files between jobs. They are the standard approach for moving compiled outputs through a workflow.',
        de: 'Workflow-Artefakte in GitHub Actions sind dafür gedacht, Dateien zwischen Jobs zu speichern und zu übertragen. Sie sind der Standardansatz, um kompilierte Ergebnisse durch einen Workflow zu bewegen.'
      },
      hint: {
        en: 'The files must cross job boundaries, not repository boundaries.',
        de: 'Die Dateien müssen Job-Grenzen und nicht Repository-Grenzen überqueren.'
      },
      reference: 'https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts'
    },
    {
      id: 'az400-078',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a container platform team wants image builds to run close to Azure Container Registry and automatically rebuild when the base image is updated.',
        de: 'Bei Fabrikam, Inc.: ein Container-Plattformteam möchte, dass Image-Builds in der Nähe von Azure Container Registry laufen und automatisch neu gebaut werden, wenn das Basis-Image aktualisiert wird.'
      },
      question: {
        en: 'Which Azure service feature should the team use?',
        de: 'Welche Azure-Dienstfunktion sollte das Team verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'ACR Tasks', de: 'ACR Tasks' } },
        { id: 'B', text: { en: 'Azure Boards', de: 'Azure Boards' } },
        { id: 'C', text: { en: 'Delivery Plans', de: 'Delivery Plans' } },
        { id: 'D', text: { en: 'Git LFS', de: 'Git LFS' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'ACR Tasks can build container images in the registry context and support triggers such as source updates and base image updates. This offloads work from pipeline agents and fits cloud-native image build scenarios.',
        de: 'ACR Tasks können Container-Images im Kontext der Registry bauen und unterstützen Trigger wie Quellcode-Updates und Aktualisierungen des Basis-Images. Das entlastet Pipeline-Agenten und passt gut zu cloudnativen Image-Build-Szenarien.'
      },
      hint: {
        en: 'Choose the registry-native build capability.',
        de: 'Wählen Sie die registry-native Build-Funktion.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-overview'
    },
    {
      id: 'az400-079',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a Docker image contains both build tooling and the final runtime, making the production image larger and harder to secure.',
        de: 'Bei Proseware, Inc.: ein Docker-Image enthält sowohl Build-Werkzeuge als auch die endgültige Laufzeit, wodurch das Produktions-Image größer und schwerer abzusichern ist.'
      },
      question: {
        en: 'Which Docker technique should you use?',
        de: 'Welche Docker-Technik sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'A multi-stage Docker build', de: 'Einen mehrstufigen Docker-Build' } },
        { id: 'B', text: { en: 'A Git tag', de: 'Ein Git-Tag' } },
        { id: 'C', text: { en: 'A dashboard widget', de: 'Ein Dashboard-Widget' } },
        { id: 'D', text: { en: 'A work item query', de: 'Eine Arbeitselementabfrage' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'A multi-stage Docker build separates build tooling from the final runtime image so only the necessary runtime artifacts are shipped. This reduces image size and usually lowers attack surface.',
        de: 'Ein mehrstufiger Docker-Build trennt Build-Werkzeuge vom endgültigen Laufzeit-Image, sodass nur die notwendigen Laufzeitartefakte ausgeliefert werden. Das reduziert die Image-Größe und verringert meist die Angriffsfläche.'
      },
      hint: {
        en: 'The goal is to keep build dependencies out of the runtime image.',
        de: 'Das Ziel ist, Build-Abhängigkeiten aus dem Laufzeit-Image herauszuhalten.'
      },
      reference: 'https://docs.docker.com/build/building/multi-stage/'
    },
    {
      id: 'az400-080',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'A team at Proseware, Inc. packages AKS deployments and wants versioned release definitions with easy upgrade and rollback commands.',
        de: 'Ein Team bei Proseware, Inc. paketiert AKS-Bereitstellungen und möchte versionierte Releasdefinitionen mit einfachen Upgrade- und Rollback-Befehlen.'
      },
      question: {
        en: 'Which tool should the team standardize on?',
        de: 'Auf welches Werkzeug sollte das Team standardisieren?'
      },
      options: [
        { id: 'A', text: { en: 'Helm charts', de: 'Helm-Charts' } },
        { id: 'B', text: { en: 'Excel spreadsheets', de: 'Excel-Tabellen' } },
        { id: 'C', text: { en: 'FTP scripts', de: 'FTP-Skripte' } },
        { id: 'D', text: { en: 'Wiki attachments', de: 'Wiki-Anhänge' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Helm packages Kubernetes resources into versioned charts and provides standard upgrade, rollback, and value override patterns. That makes it a common choice for AKS application delivery.',
        de: 'Helm verpackt Kubernetes-Ressourcen in versionierte Charts und bietet standardisierte Muster für Upgrade, Rollback und Wertüberschreibungen. Dadurch ist es eine gängige Wahl für die Anwendungsbereitstellung auf AKS.'
      },
      hint: {
        en: 'The requirement is Kubernetes package versioning and managed release operations.',
        de: 'Die Anforderung betrifft Kubernetes-Paketversionierung und verwaltete Release-Vorgänge.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/aks/kubernetes-helm'
    },
    {
      id: 'az400-081',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'Contoso, Ltd. wants reusable infrastructure modules with simpler syntax than JSON ARM templates while still deploying through Azure Resource Manager.',
        de: 'Contoso, Ltd. möchte wiederverwendbare Infrastrukturmodule mit einfacherer Syntax als JSON-ARM-Templates, aber weiterhin mit Bereitstellung über Azure Resource Manager.'
      },
      question: {
        en: 'Which IaC language should you use?',
        de: 'Welche IaC-Sprache sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Bicep', de: 'Bicep' } },
        { id: 'B', text: { en: 'Markdown', de: 'Markdown' } },
        { id: 'C', text: { en: 'YAML comments', de: 'YAML-Kommentare' } },
        { id: 'D', text: { en: 'CSV', de: 'CSV' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Bicep is a domain-specific language for Azure deployments that compiles to ARM templates. It improves readability, reuse, and maintainability while remaining fully compatible with Azure Resource Manager.',
        de: 'Bicep ist eine domänenspezifische Sprache für Azure-Bereitstellungen, die zu ARM-Templates kompiliert. Sie verbessert Lesbarkeit, Wiederverwendung und Wartbarkeit und bleibt dabei vollständig mit Azure Resource Manager kompatibel.'
      },
      hint: {
        en: 'Choose the ARM-compatible language designed to replace most handwritten JSON templates.',
        de: 'Wählen Sie die ARM-kompatible Sprache, die die meisten handgeschriebenen JSON-Templates ersetzen soll.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules'
    },
    {
      id: 'az400-082',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., before approving a production infrastructure deployment, reviewers want to see what resources will be created, changed, or deleted by the Bicep template.',
        de: 'Bei Contoso, Ltd.: bevor eine Produktions-Infrastruktur-Bereitstellung genehmigt wird, möchten Reviewer sehen, welche Ressourcen durch das Bicep-Template erstellt, geändert oder gelöscht werden.'
      },
      question: {
        en: 'Which Azure deployment capability should the pipeline run?',
        de: 'Welche Azure-Bereitstellungsfunktion sollte die Pipeline ausführen?'
      },
      options: [
        { id: 'A', text: { en: 'A what-if deployment', de: 'Eine What-If-Bereitstellung' } },
        { id: 'B', text: { en: 'A git stash', de: 'Ein git stash' } },
        { id: 'C', text: { en: 'A code wiki export', de: 'Einen Code-Wiki-Export' } },
        { id: 'D', text: { en: 'A sprint burndown', de: 'Einen Sprint-Burndown' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'What-if analyzes the ARM or Bicep deployment and previews the resource-level delta before applying it. This helps reviewers understand impact and reduce the chance of surprise infrastructure changes.',
        de: 'What-If analysiert die ARM- oder Bicep-Bereitstellung und zeigt vor der Anwendung den Ressourcenunterschied an. Das hilft Reviewern, die Auswirkungen zu verstehen und überraschende Infrastrukturänderungen zu vermeiden.'
      },
      hint: {
        en: 'The requirement is a preview of infrastructure changes before deployment.',
        de: 'Die Anforderung ist eine Vorschau der Infrastrukturänderungen vor der Bereitstellung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-what-if'
    },
    {
      id: 'az400-083',
      type: 'multiple',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Fabrikam, Inc., a Terraform-based pipeline must let reviewers inspect the exact infrastructure delta in a pull request and must prevent apply from running automatically without explicit approval.',
        de: 'Bei Fabrikam, Inc.: eine Terraform-basierte Pipeline muss es Reviewern ermöglichen, den genauen Infrastrukturunterschied in einem Pull Request zu prüfen, und verhindern, dass apply automatisch ohne ausdrückliche Genehmigung läuft.'
      },
      question: {
        en: 'Which two actions should you implement?',
        de: 'Welche zwei Maßnahmen sollten Sie implementieren?'
      },
      options: [
        { id: 'A', text: { en: 'Run terraform plan during validation and publish the plan output for review', de: 'terraform plan während der Validierung ausführen und die Plan-Ausgabe zur Überprüfung veröffentlichen' } },
        { id: 'B', text: { en: 'Require an approval before the stage that runs terraform apply', de: 'Vor der Stage mit terraform apply eine Genehmigung verlangen' } },
        { id: 'C', text: { en: 'Skip the plan step to save time', de: 'Den Plan-Schritt überspringen, um Zeit zu sparen' } },
        { id: 'D', text: { en: 'Store the state file in the repository root', de: 'Die State-Datei im Repository-Stamm speichern' } }
      ],
      correct: ['A', 'B'],
      explanation: {
        en: 'terraform plan provides a reviewable preview of the intended changes, while an explicit approval gate before terraform apply prevents uncontrolled modification of infrastructure. Together they create a safer and more auditable IaC workflow.',
        de: 'terraform plan liefert eine überprüfbare Vorschau der beabsichtigten Änderungen, während eine explizite Genehmigung vor terraform apply unkontrollierte Änderungen an der Infrastruktur verhindert. Zusammen schaffen sie einen sichereren und besser auditierbaren IaC-Workflow.'
      },
      hint: {
        en: 'One control creates visibility, and the other creates governance before apply.',
        de: 'Eine Kontrolle schafft Transparenz, die andere Governance vor apply.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops'
    },
    {
      id: 'az400-084',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Proseware, Inc., self-hosted Azure DevOps agents run on Azure virtual machines and must access Azure resources and Key Vault without storing client secrets on disk.',
        de: 'Bei Proseware, Inc.: selbstgehostete Azure-DevOps-Agenten laufen auf Azure-VMs und müssen auf Azure-Ressourcen und Key Vault zugreifen, ohne Client-Geheimnisse auf dem Datenträger zu speichern.'
      },
      question: {
        en: 'What is the best authentication design?',
        de: 'Welches Authentifizierungsdesign ist am besten geeignet?'
      },
      options: [
        { id: 'A', text: { en: 'Assign a managed identity to the agent hosts and grant the needed access', de: 'Den Agent-Hosts eine Managed Identity zuweisen und die benötigten Berechtigungen erteilen' } },
        { id: 'B', text: { en: 'Commit a service principal secret to the repository', de: 'Ein Service-Principal-Geheimnis ins Repository einchecken' } },
        { id: 'C', text: { en: 'Share one personal access token for Azure resource access', de: 'Ein gemeinsames Personal Access Token für den Azure-Ressourcenzugriff verwenden' } },
        { id: 'D', text: { en: 'Store a password in a wiki page', de: 'Ein Kennwort in einer Wiki-Seite speichern' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Managed identities let Azure-hosted compute authenticate to Azure services without storing long-lived credentials in files or pipeline definitions. That aligns well with secure self-hosted agent design.',
        de: 'Managed Identities ermöglichen es Azure-gehosteter Compute, sich bei Azure-Diensten zu authentifizieren, ohne langlebige Anmeldeinformationen in Dateien oder Pipelinedefinitionen zu speichern. Das passt gut zu einem sicheren Design selbstgehosteter Agenten.'
      },
      hint: {
        en: 'The goal is secretless authentication from Azure-hosted compute.',
        de: 'Das Ziel ist geheimnislose Authentifizierung von Azure-gehosteter Compute.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview'
    },
    {
      id: 'az400-085',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Contoso, Ltd., production deployments should pause automatically if Azure Monitor indicates active platform or application alerts for the target environment.',
        de: 'Bei Contoso, Ltd.: produktionsbereitstellungen sollen automatisch pausieren, wenn Azure Monitor aktive Plattform- oder Anwendungswarnungen für die Zielumgebung anzeigt.'
      },
      question: {
        en: 'Which Azure DevOps capability best enforces this?',
        de: 'Welche Azure-DevOps-Funktion erzwingt dies am besten?'
      },
      options: [
        { id: 'A', text: { en: 'An environment check that queries Azure Monitor alerts', de: 'Eine Umgebungsprüfung, die Azure-Monitor-Warnungen abfragt' } },
        { id: 'B', text: { en: 'A local git hook', de: 'Einen lokalen Git-Hook' } },
        { id: 'C', text: { en: 'A Kanban WIP limit', de: 'Ein Kanban-WIP-Limit' } },
        { id: 'D', text: { en: 'A CODEOWNERS file', de: 'Eine CODEOWNERS-Datei' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Environment checks can gate deployments based on external health signals such as Azure Monitor alerts. This lets production releases stop automatically when the target environment is already unhealthy.',
        de: 'Umgebungsprüfungen können Bereitstellungen anhand externer Gesundheitssignale wie Azure-Monitor-Warnungen blockieren. So lassen sich Produktions-Releases automatisch stoppen, wenn die Zielumgebung bereits ungesund ist.'
      },
      hint: {
        en: 'Use a deployment gate based on monitoring data.',
        de: 'Verwenden Sie ein Bereitstellungsgate auf Basis von Monitoring-Daten.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops'
    },
    {
      id: 'az400-086',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a deployment job simply needs to execute the deployment one time to an environment with no canary or rolling behavior.',
        de: 'Bei Fabrikam, Inc.: ein Deployment-Job muss eine Bereitstellung einfach einmal in eine Umgebung ausführen, ohne Canary- oder Rolling-Verhalten.'
      },
      question: {
        en: 'Which deployment strategy should you choose?',
        de: 'Welche Bereitstellungsstrategie sollten Sie wählen?'
      },
      options: [
        { id: 'A', text: { en: 'runOnce', de: 'runOnce' } },
        { id: 'B', text: { en: 'rolling', de: 'rolling' } },
        { id: 'C', text: { en: 'canary', de: 'canary' } },
        { id: 'D', text: { en: 'matrix', de: 'matrix' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'runOnce is the simplest deployment job strategy and fits cases where there is no need for progressive rollout. It still provides environment tracking and deployment history.',
        de: 'runOnce ist die einfachste Deployment-Job-Strategie und passt zu Fällen, in denen kein progressiver Rollout erforderlich ist. Sie bietet dennoch Umgebungsnachverfolgung und Bereitstellungsverlauf.'
      },
      hint: {
        en: 'No progressive rollout is needed here.',
        de: 'Hier ist kein progressiver Rollout erforderlich.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops'
    },
    {
      id: 'az400-087',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Proseware, Inc., a pipeline needs a human review step after deployment to staging but before a later job continues to production, and the team wants the pause defined in YAML.',
        de: 'Bei Proseware, Inc.: eine Pipeline benötigt nach der Bereitstellung nach Staging, aber vor einem späteren Job zur Produktion, einen menschlichen Review-Schritt, und das Team möchte die Pause in YAML definieren.'
      },
      question: {
        en: 'Which task is designed for this scenario?',
        de: 'Welche Task ist für dieses Szenario vorgesehen?'
      },
      options: [
        { id: 'A', text: { en: 'ManualValidation', de: 'ManualValidation' } },
        { id: 'B', text: { en: 'Cache', de: 'Cache' } },
        { id: 'C', text: { en: 'DownloadBuildArtifacts', de: 'DownloadBuildArtifacts' } },
        { id: 'D', text: { en: 'Checkout', de: 'Checkout' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'The ManualValidation task pauses a YAML pipeline and waits for human approval or rejection before continuing. It is useful when the pause should be defined inside the pipeline flow itself.',
        de: 'Die ManualValidation-Task pausiert eine YAML-Pipeline und wartet auf menschliche Genehmigung oder Ablehnung, bevor sie fortfährt. Sie ist nützlich, wenn die Pause direkt im Pipeline-Flow definiert werden soll.'
      },
      hint: {
        en: 'The pause must be expressed directly in YAML execution logic.',
        de: 'Die Pause muss direkt in der YAML-Ausführungslogik ausgedrückt werden.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/manual-validation-v0?view=azure-pipelines'
    },
    {
      id: 'az400-088',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., a .NET pipeline restores packages from a private Azure Artifacts feed and must authenticate automatically during the run.',
        de: 'Bei Contoso, Ltd.: eine .NET-Pipeline stellt Pakete aus einem privaten Azure-Artifacts-Feed wieder her und muss sich während des Laufs automatisch authentifizieren.'
      },
      question: {
        en: 'Which task should you add?',
        de: 'Welche Task sollten Sie hinzufügen?'
      },
      options: [
        { id: 'A', text: { en: 'NuGetAuthenticate', de: 'NuGetAuthenticate' } },
        { id: 'B', text: { en: 'ManualValidation', de: 'ManualValidation' } },
        { id: 'C', text: { en: 'PublishTestResults', de: 'PublishTestResults' } },
        { id: 'D', text: { en: 'UseNode', de: 'UseNode' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'NuGetAuthenticate configures the credentials needed for NuGet tools to access Azure Artifacts feeds during the pipeline. It is the standard task for secure feed access in .NET package restore scenarios.',
        de: 'NuGetAuthenticate konfiguriert die Anmeldeinformationen, die NuGet-Werkzeuge benötigen, um während der Pipeline auf Azure-Artifacts-Feeds zuzugreifen. Es ist die Standard-Task für sicheren Feed-Zugriff in .NET-Paket-Restore-Szenarien.'
      },
      hint: {
        en: 'The problem is package feed authentication for NuGet-based tooling.',
        de: 'Das Problem ist die Paket-Feed-Authentifizierung für NuGet-basierte Werkzeuge.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/nuget-authenticate-v1?view=azure-pipelines'
    },
    {
      id: 'az400-089',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., a JavaScript build uses npm packages from a private Azure Artifacts feed and needs the pipeline to configure authentication safely.',
        de: 'Bei Fabrikam, Inc.: ein JavaScript-Build verwendet npm-Pakete aus einem privaten Azure-Artifacts-Feed und muss die Authentifizierung in der Pipeline sicher konfigurieren.'
      },
      question: {
        en: 'Which task should you use?',
        de: 'Welche Task sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'npmAuthenticate', de: 'npmAuthenticate' } },
        { id: 'B', text: { en: 'CopyFiles', de: 'CopyFiles' } },
        { id: 'C', text: { en: 'ManualValidation', de: 'ManualValidation' } },
        { id: 'D', text: { en: 'Checkout', de: 'Checkout' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'npmAuthenticate prepares npm configuration so the pipeline can access private feeds without hardcoding credentials into source-controlled files. That is the preferred approach for Azure Artifacts npm authentication.',
        de: 'npmAuthenticate bereitet die npm-Konfiguration so vor, dass die Pipeline auf private Feeds zugreifen kann, ohne Anmeldedaten in versionskontrollierte Dateien fest einzubauen. Das ist der bevorzugte Ansatz für die npm-Authentifizierung mit Azure Artifacts.'
      },
      hint: {
        en: 'The requirement is secure npm feed authentication inside the pipeline.',
        de: 'Die Anforderung ist sichere npm-Feed-Authentifizierung innerhalb der Pipeline.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/npm-authenticate-v0?view=azure-pipelines'
    },
    {
      id: 'az400-090',
      type: 'multiple',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'A team at Fabrikam, Inc. wants unit test trends and code coverage visible in the Azure DevOps pipeline run summary after every build.',
        de: 'Ein Team bei Fabrikam, Inc. möchte Unit-Test-Trends und Codeabdeckung nach jedem Build in der Azure-DevOps-Pipeline-Zusammenfassung sichtbar haben.'
      },
      question: {
        en: 'Which two publishing actions should the pipeline perform?',
        de: 'Welche zwei Veröffentlichungsaktionen sollte die Pipeline ausführen?'
      },
      options: [
        { id: 'A', text: { en: 'Publish test results', de: 'Testergebnisse veröffentlichen' } },
        { id: 'B', text: { en: 'Publish code coverage results', de: 'Code-Coverage-Ergebnisse veröffentlichen' } },
        { id: 'C', text: { en: 'Create a wiki page', de: 'Eine Wiki-Seite erstellen' } },
        { id: 'D', text: { en: 'Reset the branch policy', de: 'Die Branchrichtlinie zurücksetzen' } }
      ],
      correct: ['A', 'B'],
      explanation: {
        en: 'Publishing test results surfaces pass and fail information directly in the pipeline, and publishing code coverage results makes coverage trends visible to the team. Together they improve feedback and release confidence.',
        de: 'Das Veröffentlichen von Testergebnissen stellt Pass- und Fehlerschläge direkt in der Pipeline dar, und das Veröffentlichen von Code-Coverage-Ergebnissen macht Coverage-Trends für das Team sichtbar. Zusammen verbessern sie Feedback und Release-Vertrauen.'
      },
      hint: {
        en: 'One action reports test outcome, and the other reports coverage.',
        de: 'Eine Aktion berichtet das Testergebnis, die andere die Abdeckung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/test/review-unit-test-results?view=azure-devops'
    },
    {
      id: 'az400-091',
      type: 'single',
      domain: { en: 'Design and Implement Build and Release Pipelines', de: 'Build- und Release-Pipelines entwerfen und implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Proseware, Inc., a release process must ensure that development, test, and production all receive the exact same validated application bits and that no environment rebuild occurs.',
        de: 'Bei Proseware, Inc.: ein Release-Prozess muss sicherstellen, dass Entwicklung, Test und Produktion exakt dieselben validierten Anwendungs-Bits erhalten und dass kein erneuter Build pro Umgebung stattfindet.'
      },
      question: {
        en: 'What delivery pattern should you implement?',
        de: 'Welches Delivery-Muster sollten Sie implementieren?'
      },
      options: [
        { id: 'A', text: { en: 'Build once, publish an immutable artifact, and promote that artifact through environments', de: 'Einmal bauen, ein unveränderliches Artefakt veröffentlichen und dieses Artefakt durch die Umgebungen promoten' } },
        { id: 'B', text: { en: 'Rebuild separately in every environment', de: 'In jeder Umgebung separat neu bauen' } },
        { id: 'C', text: { en: 'Copy files manually from developer laptops', de: 'Dateien manuell von Entwickler-Laptops kopieren' } },
        { id: 'D', text: { en: 'Commit production binaries to Git after each release', de: 'Produktions-Binärdateien nach jedem Release in Git einchecken' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Build-once promote-many ensures the same tested artifact moves across environments, which improves traceability and reduces the risk of environment-specific rebuild differences. It is a core DevOps release design principle.',
        de: 'Build-once-promote-many stellt sicher, dass dasselbe getestete Artefakt durch die Umgebungen bewegt wird, was Nachverfolgbarkeit verbessert und das Risiko umgebungsspezifischer Neubau-Unterschiede reduziert. Es ist ein zentrales DevOps-Release-Prinzip.'
      },
      hint: {
        en: 'The artifact should be immutable and reused, not recreated.',
        de: 'Das Artefakt sollte unveränderlich sein und wiederverwendet werden, nicht neu erstellt.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/pipeline-artifacts?view=azure-devops'
    },
    {
      id: 'az400-092',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'medium',
      scenario: {
        en: 'A GitHub repository at Proseware, Inc. needs automated static analysis that flags insecure coding patterns in pull requests and surfaces security findings directly in the code scanning experience.',
        de: 'Ein GitHub-Repository bei Proseware, Inc. benötigt automatisierte statische Analyse, die unsichere Codierungsmuster in Pull Requests kennzeichnet und Sicherheitsbefunde direkt in der Code-Scanning-Erfahrung anzeigt.'
      },
      question: {
        en: 'Which GitHub Advanced Security capability should you enable?',
        de: 'Welche GitHub-Advanced-Security-Funktion sollten Sie aktivieren?'
      },
      options: [
        { id: 'A', text: { en: 'Code scanning with CodeQL', de: 'Code Scanning mit CodeQL' } },
        { id: 'B', text: { en: 'Git LFS', de: 'Git LFS' } },
        { id: 'C', text: { en: 'GitHub Discussions', de: 'GitHub Discussions' } },
        { id: 'D', text: { en: 'Release tags', de: 'Release-Tags' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Code scanning with CodeQL performs static analysis and presents findings directly in GitHub security views and pull requests. It is a primary shift-left control for identifying risky coding patterns before release.',
        de: 'Code Scanning mit CodeQL führt statische Analyse durch und zeigt Befunde direkt in GitHub-Sicherheitsansichten und Pull Requests an. Es ist eine zentrale Shift-Left-Kontrolle, um riskante Codierungsmuster vor dem Release zu erkennen.'
      },
      hint: {
        en: 'This is the SAST capability in GitHub Advanced Security.',
        de: 'Dies ist die SAST-Funktion in GitHub Advanced Security.'
      },
      reference: 'https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning'
    },
    {
      id: 'az400-093',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., security reviewers want pull requests to show whether new or updated package dependencies introduce known vulnerabilities before the code is merged.',
        de: 'Bei Contoso, Ltd.: sicherheitsreviewer möchten in Pull Requests sehen, ob neue oder aktualisierte Paketabhängigkeiten bekannte Schwachstellen einführen, bevor der Code gemergt wird.'
      },
      question: {
        en: 'Which GitHub capability best fits this requirement?',
        de: 'Welche GitHub-Funktion passt am besten zu dieser Anforderung?'
      },
      options: [
        { id: 'A', text: { en: 'Dependency review', de: 'Dependency Review' } },
        { id: 'B', text: { en: 'Git annotate', de: 'Git annotate' } },
        { id: 'C', text: { en: 'Git stash', de: 'Git stash' } },
        { id: 'D', text: { en: 'Project wiki', de: 'Projekt-Wiki' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Dependency review analyzes dependency changes in pull requests and highlights known vulnerable packages and risk information before merge. This is a strong control for software supply chain hygiene.',
        de: 'Dependency Review analysiert Abhängigkeitsänderungen in Pull Requests und hebt bekannte verwundbare Pakete sowie Risikoinformationen vor dem Merge hervor. Dies ist eine starke Kontrolle für die Hygiene der Software-Lieferkette.'
      },
      hint: {
        en: 'The check is specific to dependency changes in a pull request.',
        de: 'Die Prüfung bezieht sich speziell auf Abhängigkeitsänderungen in einem Pull Request.'
      },
      reference: 'https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review'
    },
    {
      id: 'az400-094',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'hard',
      scenario: {
        en: 'At Contoso, Ltd., an Azure DevOps pipeline deploys to Azure, and the security team wants to remove expiring client secrets from the service connection authentication model.',
        de: 'Contoso, Ltd. – Eine Azure-DevOps-Pipeline stellt nach Azure bereit, und das Sicherheitsteam möchte ablaufende Client-Geheimnisse aus dem Authentifizierungsmodell der Serviceverbindung entfernen.'
      },
      question: {
        en: 'What should you implement?',
        de: 'Was sollten Sie implementieren?'
      },
      options: [
        { id: 'A', text: { en: 'A service connection that uses workload identity federation', de: 'Eine Serviceverbindung, die Workload Identity Federation verwendet' } },
        { id: 'B', text: { en: 'A plain text secret in YAML', de: 'Ein Klartextgeheimnis in YAML' } },
        { id: 'C', text: { en: 'A password in a wiki page', de: 'Ein Kennwort in einer Wiki-Seite' } },
        { id: 'D', text: { en: 'A PAT for Azure Resource Manager', de: 'Ein PAT für Azure Resource Manager' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Workload identity federation lets Azure DevOps authenticate to Azure without storing long-lived client secrets. This improves security and reduces operational overhead from secret expiration and rotation.',
        de: 'Workload Identity Federation ermöglicht Azure DevOps die Authentifizierung bei Azure, ohne langlebige Client-Geheimnisse zu speichern. Das verbessert die Sicherheit und reduziert den Betriebsaufwand durch Ablauf und Rotation von Geheimnissen.'
      },
      hint: {
        en: 'The goal is secretless modern authentication for the service connection.',
        de: 'Das Ziel ist moderne geheimnislose Authentifizierung für die Serviceverbindung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops'
    },
    {
      id: 'az400-095',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'medium',
      scenario: {
        en: 'Developers at Fabrikam, Inc. occasionally paste secrets into commits by accident. The organization wants GitHub to detect and block these exposures as early as possible.',
        de: 'Entwickler bei Fabrikam, Inc. fügen gelegentlich versehentlich Geheimnisse in Commits ein. Die Organisation möchte, dass GitHub diese Offenlegungen so früh wie möglich erkennt und blockiert.'
      },
      question: {
        en: 'Which capability should you enable?',
        de: 'Welche Funktion sollten Sie aktivieren?'
      },
      options: [
        { id: 'A', text: { en: 'Secret scanning with push protection', de: 'Secret Scanning mit Push Protection' } },
        { id: 'B', text: { en: 'Git LFS', de: 'Git LFS' } },
        { id: 'C', text: { en: 'A project wiki', de: 'Ein Projekt-Wiki' } },
        { id: 'D', text: { en: 'A matrix build', de: 'Einen Matrix-Build' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Secret scanning detects exposed credentials, and push protection can stop them before they land in the repository. This is one of the most effective controls for preventing accidental secret leakage in GitHub.',
        de: 'Secret Scanning erkennt offengelegte Zugangsdaten, und Push Protection kann sie stoppen, bevor sie im Repository landen. Das ist eine der wirksamsten Kontrollen, um versehentliche Geheimnislecks in GitHub zu verhindern.'
      },
      hint: {
        en: 'The best control is the one that blocks secret exposure before or at push time.',
        de: 'Die beste Kontrolle ist diejenige, die Geheimnisoffenlegung vor oder spätestens beim Push blockiert.'
      },
      reference: 'https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection'
    },
    {
      id: 'az400-096',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., container images are pushed to Azure Container Registry before deployment to AKS. Security wants vulnerability findings available before the images are promoted to production.',
        de: 'Bei Fabrikam, Inc.: container-Images werden vor der Bereitstellung nach AKS in Azure Container Registry gepusht. Das Sicherheitsteam möchte Schwachstellenbefunde verfügbar haben, bevor die Images in Produktion promoted werden.'
      },
      question: {
        en: 'Which Azure security capability should you use?',
        de: 'Welche Azure-Sicherheitsfunktion sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Microsoft Defender for Cloud image vulnerability scanning', de: 'Microsoft Defender for Cloud für Image-Schwachstellen-Scanning' } },
        { id: 'B', text: { en: 'Azure Boards Delivery Plans', de: 'Azure Boards Delivery Plans' } },
        { id: 'C', text: { en: 'Git sparse checkout', de: 'Git Sparse Checkout' } },
        { id: 'D', text: { en: 'Manual FTP uploads', de: 'Manuelle FTP-Uploads' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Microsoft Defender for Cloud can assess container images and surface vulnerability findings for registries and container workloads. This helps teams gate promotion and reduce the chance of deploying known vulnerable images.',
        de: 'Microsoft Defender for Cloud kann Container-Images bewerten und Schwachstellenbefunde für Registries und Container-Workloads bereitstellen. Das hilft Teams, Promotions zu steuern und die Bereitstellung bekanntermaßen verwundbarer Images zu vermeiden.'
      },
      hint: {
        en: 'The requirement is image vulnerability insight before promotion.',
        de: 'Die Anforderung ist Einblick in Image-Schwachstellen vor der Promotion.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-container-registries-introduction'
    },
    {
      id: 'az400-097',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'hard',
      scenario: {
        en: 'At Proseware, Inc., auditors require every software release to include a machine-readable inventory of the components that went into the build for supply chain review.',
        de: 'Bei Proseware, Inc.: auditoren verlangen, dass jede Softwareauslieferung eine maschinenlesbare Inventarliste der Komponenten enthält, die in den Build eingeflossen sind, um die Lieferkette zu prüfen.'
      },
      question: {
        en: 'What should your pipeline generate and publish?',
        de: 'Was sollte Ihre Pipeline erzeugen und veröffentlichen?'
      },
      options: [
        { id: 'A', text: { en: 'A software bill of materials', de: 'Eine Software Bill of Materials' } },
        { id: 'B', text: { en: 'A Git stash list', de: 'Eine Git-Stash-Liste' } },
        { id: 'C', text: { en: 'A dashboard screenshot', de: 'Einen Dashboard-Screenshot' } },
        { id: 'D', text: { en: 'A manual email summary', de: 'Eine manuelle E-Mail-Zusammenfassung' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'An SBOM documents the components and dependencies that make up a software release. It is increasingly important for compliance, incident response, and software supply chain transparency.',
        de: 'Eine SBOM dokumentiert die Komponenten und Abhängigkeiten, aus denen eine Softwareauslieferung besteht. Sie ist zunehmend wichtig für Compliance, Incident Response und Transparenz in der Software-Lieferkette.'
      },
      hint: {
        en: 'The requirement is a structured component inventory for compliance.',
        de: 'Die Anforderung ist ein strukturierter Komponentenbestand für Compliance-Zwecke.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/security/fundamentals/supply-chain-security'
    },
    {
      id: 'az400-098',
      type: 'single',
      domain: { en: 'Develop a Security and Compliance Plan', de: 'Sicherheits- und Compliance-Plan entwickeln' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., a pipeline only needs to deploy resources within one resource group and must not be able to grant access or manage other scopes.',
        de: 'Bei Contoso, Ltd.: eine Pipeline muss nur Ressourcen innerhalb einer Ressourcengruppe bereitstellen und darf keine Berechtigungen vergeben oder andere Bereiche verwalten.'
      },
      question: {
        en: 'Which Azure RBAC role assignment best follows least privilege?',
        de: 'Welche Azure-RBAC-Rollenzuweisung folgt am besten dem Least-Privilege-Prinzip?'
      },
      options: [
        { id: 'A', text: { en: 'Contributor on the target resource group', de: 'Mitwirkender auf der Ziel-Ressourcengruppe' } },
        { id: 'B', text: { en: 'Owner at the subscription scope', de: 'Besitzer auf Abonnementebene' } },
        { id: 'C', text: { en: 'Global Administrator in Microsoft Entra ID', de: 'Globaler Administrator in Microsoft Entra ID' } },
        { id: 'D', text: { en: 'Reader on the management group', de: 'Leser auf Verwaltungsebene' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Contributor at the resource group scope allows resource deployment and modification within that scope without granting access-management rights such as role assignment. That is a better least-privilege fit than Owner.',
        de: 'Mitwirkender auf Ebene der Ressourcengruppe erlaubt Bereitstellung und Änderung von Ressourcen innerhalb dieses Bereichs, ohne Zugriffsverwaltungsrechte wie Rollenzuweisungen zu vergeben. Das passt besser zum Least-Privilege-Prinzip als Besitzer.'
      },
      hint: {
        en: 'The pipeline needs deployment rights, but not access management rights.',
        de: 'Die Pipeline benötigt Bereitstellungsrechte, aber keine Rechte zur Zugriffsverwaltung.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles'
    },
    {
      id: 'az400-099',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Proseware, Inc., a public web endpoint must be checked regularly from outside the application to confirm that it is reachable and responding correctly.',
        de: 'Proseware, Inc. – Ein öffentlicher Web-Endpunkt muss regelmäßig außerhalb der Anwendung geprüft werden, um zu bestätigen, dass er erreichbar ist und korrekt antwortet.'
      },
      question: {
        en: 'Which Azure Monitor capability should you configure?',
        de: 'Welche Azure-Monitor-Funktion sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'Availability tests', de: 'Verfügbarkeitstests' } },
        { id: 'B', text: { en: 'Git tags', de: 'Git-Tags' } },
        { id: 'C', text: { en: 'Azure Artifacts', de: 'Azure Artifacts' } },
        { id: 'D', text: { en: 'Area paths', de: 'Bereichspfade' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Availability tests simulate requests from outside the application and help teams verify endpoint uptime and responsiveness. They are useful for detecting outages and regressions visible to users.',
        de: 'Verfügbarkeitstests simulieren Anfragen von außerhalb der Anwendung und helfen Teams, Uptime und Reaktionsfähigkeit von Endpunkten zu überprüfen. Sie sind nützlich, um Ausfälle und Regressionen zu erkennen, die für Benutzer sichtbar sind.'
      },
      hint: {
        en: 'The check must come from outside the application itself.',
        de: 'Die Prüfung muss von außerhalb der Anwendung selbst kommen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/app/availability'
    },
    {
      id: 'az400-100',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'easy',
      scenario: {
        en: 'At Fabrikam, Inc., an alert rule must notify email, SMS, and webhook targets whenever a critical production metric threshold is exceeded.',
        de: 'Bei Fabrikam, Inc.: eine Warnregel muss E-Mail-, SMS- und Webhook-Ziele benachrichtigen, sobald ein kritischer Produktionsmetrikschwellenwert überschritten wird.'
      },
      question: {
        en: 'Which Azure Monitor construct handles the notification routing?',
        de: 'Welche Azure-Monitor-Konstruktion übernimmt das Routing der Benachrichtigungen?'
      },
      options: [
        { id: 'A', text: { en: 'An action group', de: 'Eine Aktionsgruppe' } },
        { id: 'B', text: { en: 'A work item query', de: 'Eine Arbeitselementabfrage' } },
        { id: 'C', text: { en: 'A code wiki', de: 'Ein Code Wiki' } },
        { id: 'D', text: { en: 'A Git hook', de: 'Ein Git-Hook' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Action groups define who or what gets notified when an alert fires, including email, SMS, voice, push, and webhook actions. They separate alert conditions from notification destinations.',
        de: 'Aktionsgruppen definieren, wer oder was benachrichtigt wird, wenn ein Alert ausgelöst wird, einschließlich E-Mail, SMS, Sprache, Push und Webhook-Aktionen. Sie trennen Alert-Bedingungen von den Benachrichtigungszielen.'
      },
      hint: {
        en: 'The alert rule defines when, but this object defines who gets notified.',
        de: 'Die Warnregel definiert wann, aber dieses Objekt definiert, wer benachrichtigt wird.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups'
    },
    {
      id: 'az400-101',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Proseware, Inc., a microservices application needs end-to-end distributed traces across services, dependencies, and requests, and the engineering team wants to use an open standard for instrumentation.',
        de: 'Bei Proseware, Inc.: eine Microservices-Anwendung benötigt durchgängige verteilte Traces über Dienste, Abhängigkeiten und Anforderungen hinweg, und das Engineering-Team möchte einen offenen Standard für die Instrumentierung verwenden.'
      },
      question: {
        en: 'Which approach should you choose?',
        de: 'Welchen Ansatz sollten Sie wählen?'
      },
      options: [
        { id: 'A', text: { en: 'Instrument the app with OpenTelemetry and send data to Application Insights', de: 'Die App mit OpenTelemetry instrumentieren und Daten an Application Insights senden' } },
        { id: 'B', text: { en: 'Use only Git tags for tracing', de: 'Nur Git-Tags für Tracing verwenden' } },
        { id: 'C', text: { en: 'Store errors in README files', de: 'Fehler in README-Dateien speichern' } },
        { id: 'D', text: { en: 'Rely only on deployment approvals', de: 'Sich nur auf Deployment-Genehmigungen verlassen' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'OpenTelemetry provides a vendor-neutral instrumentation standard for traces, metrics, and logs. Combined with Application Insights or Azure Monitor, it gives strong distributed observability across microservices.',
        de: 'OpenTelemetry bietet einen herstellerneutralen Instrumentierungsstandard für Traces, Metriken und Logs. In Kombination mit Application Insights oder Azure Monitor erhalten Sie starke verteilte Observability über Microservices hinweg.'
      },
      hint: {
        en: 'The key requirement is open-standard distributed tracing.',
        de: 'Die zentrale Anforderung ist verteiltes Tracing auf Basis eines offenen Standards.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-overview'
    },
    {
      id: 'az400-102',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., a production metric has normal daily and weekly patterns, so a static threshold causes too many false alarms.',
        de: 'Bei Contoso, Ltd.: eine Produktionsmetrik zeigt normale tägliche und wöchentliche Muster, sodass ein statischer Schwellenwert zu viele Fehlalarme verursacht.'
      },
      question: {
        en: 'What type of Azure Monitor alert should you prefer?',
        de: 'Welche Art von Azure-Monitor-Alert sollten Sie bevorzugen?'
      },
      options: [
        { id: 'A', text: { en: 'A dynamic threshold metric alert', de: 'Einen Metrik-Alert mit dynamischem Schwellenwert' } },
        { id: 'B', text: { en: 'A wiki reminder', de: 'Eine Wiki-Erinnerung' } },
        { id: 'C', text: { en: 'A Git hook', de: 'Einen Git-Hook' } },
        { id: 'D', text: { en: 'A package retention rule', de: 'Eine Paket-Aufbewahrungsregel' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Dynamic thresholds learn normal behavior and adjust alerting based on observed patterns, which helps reduce false positives compared with a static fixed threshold for variable workloads.',
        de: 'Dynamische Schwellenwerte lernen normales Verhalten und passen die Alarmierung an beobachtete Muster an, was im Vergleich zu einem festen statischen Schwellenwert bei variablen Lasten Fehlalarme reduziert.'
      },
      hint: {
        en: 'The metric baseline is not fixed, so the alert should adapt.',
        de: 'Die Metrik-Basislinie ist nicht fest, daher sollte sich der Alert anpassen.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-dynamic-thresholds'
    },
    {
      id: 'az400-103',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Fabrikam, Inc., operations wants one interactive view that combines metrics, logs, charts, and text explanations for incident triage and service review meetings.',
        de: 'Bei Fabrikam, Inc.: der Betrieb möchte eine interaktive Ansicht, die Metriken, Logs, Diagramme und Text-Erklärungen für Incident-Triage und Service-Review-Meetings kombiniert.'
      },
      question: {
        en: 'Which Azure Monitor feature is best suited for this?',
        de: 'Welche Azure-Monitor-Funktion ist dafür am besten geeignet?'
      },
      options: [
        { id: 'A', text: { en: 'Workbooks', de: 'Workbooks' } },
        { id: 'B', text: { en: 'Git cherry-pick', de: 'Git cherry-pick' } },
        { id: 'C', text: { en: 'Azure Artifacts feeds', de: 'Azure-Artifacts-Feeds' } },
        { id: 'D', text: { en: 'CODEOWNERS', de: 'CODEOWNERS' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Azure Monitor workbooks combine queries, charts, parameters, metrics, and explanatory text in one interactive document. They are very useful for operational dashboards and troubleshooting guides.',
        de: 'Azure-Monitor-Workbooks kombinieren Abfragen, Diagramme, Parameter, Metriken und erläuternden Text in einem interaktiven Dokument. Sie sind sehr nützlich für operative Dashboards und Troubleshooting-Leitfäden.'
      },
      hint: {
        en: 'The requirement is an interactive observability document, not a static dashboard only.',
        de: 'Die Anforderung ist ein interaktives Observability-Dokument und nicht nur ein statisches Dashboard.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-overview'
    },
    {
      id: 'az400-104',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'medium',
      scenario: {
        en: 'At Contoso, Ltd., an API generates very high telemetry volume, and the team needs to control monitoring cost while still preserving useful trend data.',
        de: 'Bei Contoso, Ltd. erzeugt sehr große Telemetrievolumen, und das Team muss die Monitoring-Kosten kontrollieren, ohne nützliche Trenddaten zu verlieren.'
      },
      question: {
        en: 'Which telemetry technique should you use?',
        de: 'Welche Telemetrie-Technik sollten Sie verwenden?'
      },
      options: [
        { id: 'A', text: { en: 'Sampling', de: 'Sampling' } },
        { id: 'B', text: { en: 'Disable all logging', de: 'Alle Protokolle deaktivieren' } },
        { id: 'C', text: { en: 'Store telemetry in Git', de: 'Telemetrie in Git speichern' } },
        { id: 'D', text: { en: 'Use bigger commit messages', de: 'Größere Commit-Nachrichten verwenden' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Sampling reduces the amount of telemetry sent and stored while preserving statistically useful insights for trends and investigation. It is a standard approach for balancing observability value and cost.',
        de: 'Sampling reduziert die Menge an gesendeter und gespeicherter Telemetrie, während statistisch nützliche Erkenntnisse für Trends und Untersuchungen erhalten bleiben. Es ist ein Standardansatz, um Observability-Nutzen und Kosten auszubalancieren.'
      },
      hint: {
        en: 'You want less volume, not zero visibility.',
        de: 'Sie möchten weniger Volumen und nicht null Sichtbarkeit.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/app/sampling-classic-api'
    },
    {
      id: 'az400-105',
      type: 'single',
      domain: { en: 'Implement an Instrumentation Strategy', de: 'Instrumentierungsstrategie implementieren' },
      difficulty: 'hard',
      scenario: {
        en: 'At Proseware, Inc., after each deployment, site reliability engineers want an alert if failed request count rises sharply in the next 15 minutes based on log data queried with KQL.',
        de: 'Bei Proseware, Inc.: nach jeder Bereitstellung möchten Site-Reliability-Engineers einen Alert, wenn die Anzahl fehlgeschlagener Anforderungen in den nächsten 15 Minuten auf Basis von per KQL abgefragten Logdaten stark ansteigt.'
      },
      question: {
        en: 'Which Azure Monitor alert type should you configure?',
        de: 'Welchen Azure-Monitor-Alert-Typ sollten Sie konfigurieren?'
      },
      options: [
        { id: 'A', text: { en: 'A log search alert rule', de: 'Eine Log-Search-Alert-Regel' } },
        { id: 'B', text: { en: 'A branch protection rule', de: 'Eine Branch-Protection-Regel' } },
        { id: 'C', text: { en: 'A Git tag policy', de: 'Eine Git-Tag-Richtlinie' } },
        { id: 'D', text: { en: 'A Kanban swimlane', de: 'Eine Kanban-Swimlane' } }
      ],
      correct: ['A'],
      explanation: {
        en: 'Log search alerts evaluate KQL queries over log data and can fire when the query result crosses a threshold. They are appropriate when the condition depends on structured log analysis rather than a simple metric.',
        de: 'Log-Search-Alerts werten KQL-Abfragen über Logdaten aus und können auslösen, wenn das Abfrageergebnis einen Schwellenwert überschreitet. Sie sind geeignet, wenn die Bedingung von strukturierter Log-Analyse und nicht von einer einfachen Metrik abhängt.'
      },
      hint: {
        en: 'The condition is expressed in KQL over logs, not as a basic metric threshold.',
        de: 'Die Bedingung wird in KQL über Logs ausgedrückt und nicht als einfacher Metrikschwellenwert.'
      },
      reference: 'https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-log'
    }
  ]
};