Correct: Consumes

In CSDM, an Application Service represents the operational, customer-facing or business-facing service that users consume, whereas a Business Application represents the logical design-time application model.

The appropriate relationship is that the Business Application consumes the Application Service because the service delivers the operational capabilities that the Business Application relies on.

This aligns with CSDM guidance: Business Applications in the Design domain consume Application Services in the Sell/Consume domain, which ensures proper service reporting, ownership clarity, and alignment with ITSM and AIOps use cases.

Incorrect: Uses

Although “Uses” sounds valid in plain language, it is not the recommended CSDM relationship for linking Business Applications to Application Services.

“Uses“ is generally applied between services or technical components, not specifically between Business Applications and their Application Services.

Incorrect: Runs On

“Runs On“ is typically used to express relationships between Application Services or Technical Services and the underlying infrastructure components, such as servers, cloud platforms, or database instances.

It does not apply to the logical-to-operational linkage between a Business Application and its Application Service.

Incorrect: Depends On

“Depends On“ is a generic relationship often used in service-to-service or component-level dependency mapping.

While it may conceptually describe reliance, it does not adhere to the CSDM-preferred semantic mapping for the Business Application to Application Service relationship.

The source explicitly states that ‘it is difficult to define an objective measure… The criteria used… are subjective to the individuals explaining them and then interpretation from an interview‘. Therefore, stating its interpretation is *purely objective* is incorrect.

Items to include in an architecture diagram are ‘ServiceNow Instances‘, ‘Integrations‘, ‘Authentication systems‘, ‘Portals‘, ‘Data lakes‘, and ‘External service providers‘. Items *not* to include are ‘Disparate systems‘ unless integrated , and not all information gathered is for the diagram.

The five foundation data elements are People, Company, Organizational structure, Location, and Groups. Services are explicitly stated as not being part of CSDM‘s foundation domain or considered foundational data.

Guiding principles include: foundation data supporting capability, data influencing value/effort/onboarding time, data sourced externally if timely and governed, and critical ownership by a product owner. Option 1 is incorrect as external systems are valid sources. Option 5 is incorrect as influencing *effort* in managing data is a key consideration.

Service Portfolio Management fits in the ‘sell/consume‘ area of the CSDM.

Customized bulk import methods are explicitly mentioned as valid scenarios where large volumes of data are pushed or retrieved, leveraging import sets and transform maps. Therefore, this statement is INCORRECT.

A Single Sign-On (SSO) solution for user authentication is the most common implementation requirement for ServiceNow customers, typically involving an existing SSO system with an IdP.

Out-of-the-box capabilities for INBOUND transactional integrations include ‘REST APIs‘, ‘SOAP APIs on a table basis‘, ‘Scripted REST or SOAP web services‘, and ‘Email-based operations‘. Flow Designer/IntegrationHub and business rules/script actions triggering web service calls are OUTBOUND integration methods.

Permission groups, also referred to as security groups, manage the allocation of ServiceNow roles to end-users. The leading practice is explicitly ‘Do not assign roles to individuals directly‘.

Key governance considerations for release and instance management include: Operating Model, Platform Scope (products/applications), Instances (number/purpose of environments), and Methodology (Waterfall/Agile/SAFe, release cadence). Option 5 is a general business consideration, but not explicitly listed as a *governance step* consideration here, though it might influence overall decisions.

The 3-stack instance structure is described as having pros such as ‘Standard deployment‘, ‘Separates Test from Dev‘, and ‘Streamlined‘. However, a con is ‘No staging‘. Therefore, offering a dedicated staging environment is NOT a pro.

Defining policies helps in ‘Reducing risk‘, ‘Reducing the mean time to resolve (MTTR) incidents or outages‘, and ‘Preventing incidents and outages‘. Options 4 and 5 are not listed benefits and contradict sound instance management practices.

Application Repositories allow publishing a custom application to the repository so it can be installed on other instances in the organization and restricting access to the same company. Team Development is superseded by Source Control.

Correct: B. Because business applications belong to the Design domain, and ITSM processes require structures from the Manage Technical Services or Sell/Consume domains

Business Applications in the CSDM reside in the Design domain, where the focus is on modeling what the business uses, not how it is operated.

ITSM processes such as Incident, Change, and Problem are operational by nature and must be tied to CIs that live in the Manage Technical Services or Sell/Consume domains, such as Application Services or Technical Services.

Mapping ITSM processes to Business Applications breaks the intended architecture and disrupts out-of-the-box ITSM reporting, service ownership, and service health monitoring.

CSDM expects operational work to be tied to the service layer structures that support Service Operations, not to Business Application records.

Incorrect: A. Because business applications are solely for financial tracking, not operational processes

Business Applications are not limited to financial tracking.

They serve an architectural purpose in the Design domain and represent capabilities used by the business.

While they are not meant for ITSM ticket assignment, the reason is tied to domain usage, not financial tracking.

Incorrect: C. Because incident and change management should only be assigned to individual Configuration Items (CIs), not higher-level applications

The issue is not about higher-level vs. lower-level CIs.

ITSM processes can be tied to service-level CIs (like Application Services), not just low-level components.

The real concern is aligning to the correct CSDM domain, which makes this statement incomplete and misleading.

Incorrect: D. Because the business application table is only for applications used at a strategic level, not for operational health reporting

Business Applications are not strictly “strategic”—they are part of the Design domain that defines what the business uses.

While they are not tied to operational health reporting, the core reason this practice is incorrect is tied to CSDM domain alignment rather than strategic vs. operational classification.

Leading practices for interviews include keeping them under one hour, having no more than two participants, asking open-ended questions (not yes/no), taking relevant notes, and asking for documents. Suzi advises against focusing too much on IT-related personas, emphasizing engagement with a wide variety including business users.

Correct: Walk, as it emphasizes the management of technology services and meta-data synchronization.

The Walk stage of the CSDM maturity model focuses on establishing and operationalizing Technology Services, Service Offerings, and supporting CI relationships so that ITSM processes can reliably use them.

At this level, organizations begin automated routing of incidents, change automation, and CI-to-support group alignment, which fits the customer’s requirement.

Walk also enables the synchronization of discovered CIs with manual CMDB meta-data (like support or approver groups), allowing Incident and Change workflows to leverage Service Offerings effectively.

Incorrect: Crawl, as it focuses on basic incident and problem tracking.

The Crawl phase is foundational and focuses on core CMDB structure and basic data integrity.

It does not yet support routing based on service offerings or meta-data synchronization for approval groups.

Crawl is about establishing initial CI classes, not enabling automation tied to Service Offerings.

Incorrect: Run, as it enables full impact assessment for technology on the business.

The Run phase represents advanced service modeling and business impact alignment.

While incident routing and approver automation may still occur at this stage, the question scenario aligns more closely with earlier operational adoption, not advanced maturity.

Run is focused on event correlation, SPM, and business impact analysis, which goes beyond the described requirements.

Incorrect: Manage, which indicates formalized data domains with stewardship forums.

Manage is a governance layer, not a functional maturity stage for implementing ITSM use cases.

It involves ongoing data stewardship, ownership, and policy enforcement, but does not specifically deliver automation like incident routing or CI meta-data synchronization.

This phase applies after an organization has already matured its service models.

Correct: Sold Products and Install Base Items

In Customer Service Management (CSM), Sold Products represent what a customer has purchased or is entitled to receive, while Install Base Items represent the specific deployed instances of those products or services at the customer’s environment.

These records allow internal services and CMDB data to be exposed to external B2B customers while maintaining entitlement, visibility, and support alignment.

This linkage enables CMDB-driven services to be consumed through the CSM portal, ensuring that customers only see and interact with the services tied to their contracts or subscriptions.

Incorrect: Business Applications and Business Services

These CMDB record types are service-modeling components used for internal architecture and operational alignment, not for exposing or entitling services to external B2B customers.

They do not handle customer-specific visibility, contracts, or entitlements, which are required in a CSM scenario.

Incorrect: Configuration Items and Technical Service Offerings

While these CMDB records may be referenced by CSM processes, they do not directly manage customer entitlement or exposure of services to external business customers.

Technical Service Offerings support ITSM and service operations, not CSM-facing product entitlement or installed asset tracking.

Incorrect: Product Models and Service Models

Product Models define reusable product templates, and Service Models support internal service mapping, but neither is the primary mechanism for external customer service entitlement and visibility.

They cannot independently ensure that the correct services are displayed only to the correct B2B customers.

Correct: Sell/Consume, leveraging Sold Products and Case Management integration

The Sell/Consume domain is designed for customer-facing consumption of services, making it the correct choice for scenarios where external customers log cases against specific service offerings.

Sold Products and their linkage to Service Offerings provide the entitlement foundation needed for routing, visibility, and case creation in Customer Service Management (CSM).

When an agent converts a case to an incident, the consumed service information flows through automatically, ensuring the incident is routed to the correct assignment or resolver group without duplication of effort or data loss.

This domain is purpose-built for B2B customer-facing use cases, especially those that require entitlement, routing, and cross-process data transfer.

Incorrect: Manage Technical Services, focusing on Incident Management processes

This domain supports internal IT operations and service health but does not address customer entitlement, service consumption, or case-to-incident transfer of sold services.

It is too narrow in scope for the end-to-end B2B customer experience described in the scenario.

Incorrect: Build, focusing on Application Service relationships

The Build domain is about service composition and application architecture, not the exposure or entitlement of services to end customers.

It cannot meet the requirement of customers logging cases against purchased offerings or automatic routing based on Sold Products.

Incorrect: Design, defining Business Service Offerings

While Business Service Offerings are created in the Design domain, that alone does not provide customer-facing visibility, logging, entitlement, or routing.

Design domain structures must be consumed by Sell/Consume processes to fulfill the scenario, so this option is incomplete.

Correct: They enable powerful decision-support by illustrating dependencies and impacts between CIs.

CI relationships in the CMDB are foundational for driving impact analysis, root cause identification, dependency mapping, and automated routing across ITSM and ITOM processes.

These relationships allow the platform to generate service maps, outage impact trees, change risk assessments, and proactive incident resolution, all of which help decision-makers understand how failures or changes in one component affect others.

This capability is central to CMDB’s value: visibility, context, and intelligence for operational decisions.

Incorrect: They simplify the process of defining new CI classes

Defining CI classes is part of data model design, which is unrelated to CI relationships.

Relationships connect instances, not classes, and they do not simplify CI class creation or maintenance.

Incorrect: They ensure that CIs can exist independently without external dependencies

CI relationships do the opposite by highlighting dependencies, rather than promoting independent existence.

The CMDB is intended to show interconnectedness, not independence, especially in modern distributed architectures.

Incorrect: They provide granular details about physical attributes of a computer

Granular physical or hardware attributes are stored on the CI record itself, not in its relationships.

CI relationships describe how CIs relate, not what they physically are.

Correct: To ensure data maps correctly to appropriate CMDB tables for full product benefits.

The primary purpose of adopting the CSDM framework is to ensure that services, applications, and operational data are modeled in the correct CMDB tables with proper relationships.

When CSDM alignment is followed, ServiceNow products such as ITSM, ITOM, ITAM, CSM, and SPM can fully leverage out-of-the-box capabilities, including service mapping, impact analysis, routing, AIOps, and reporting.

Proper alignment ensures data consistency, cross-product interoperability, and long-term platform scalability, resulting in a maintainable and future-proof architecture.

Incorrect: To ensure that all data is automatically populated via Discovery without manual intervention

Discovery helps populate infrastructure and application CIs, but not all CSDM data comes from Discovery.

CSDM also includes business services, application services, service offerings, and service portfolios, many of which are manually curated or integrated, not auto-discovered.

Incorrect: To guarantee that custom applications are built in isolated scopes

Scoped application development is a general ServiceNow design principle, unrelated to CSDM.

CSDM focuses on data modeling for services, not development or scope isolation.

Incorrect: To standardize reporting metrics across all IT operations, regardless of CMDB structure

While CSDM improves reporting accuracy, standardizing reporting is a by-product, not the core purpose.

CSDM’s main intent is proper CMDB structuring and service alignment, not enforcing uniform reporting practices.

Correct:

Designing a plan for implementing ServiceNow governance.

This is the correct responsibility because the design and implementation plan for platform governance sets the strategic direction, defines the organizational changes required, and secures the necessary resources. Executive sponsorship and oversight are explicitly required to authorize this plan, enforce its adoption across the enterprise, and ensure it aligns with overall business strategy.

Incorrect:

Incorrect:

Advising how decision-making groups make informed decisions.

The platform owner primarily sets up the decision-making groups and their charter (which dictates how decisions are made), but the act of advising on specific informed decisions is an ongoing operational or tactical activity, not a key preparatory responsibility that hinges on executive oversight for its setup.

Deciding on the governance framework‘s flexibility.

The platform owner decides the framework‘s flexibility as part of the overall design, but this is a technical or organizational design choice. The executive sponsorship is needed to approve and champion the entire governance framework and its implementation plan (Option B), not just a specific attribute like flexibility.

Conducting a thorough review of product documentation.

This is a foundational, technical task required of the implementation team, solution architects, and the platform owner. While critical, it is an internal due diligence activity and does not require explicit executive sponsorship and oversight to complete, unlike the high-level strategic implementation plan (Option B).

Correct:
• To avoid overlapping responsibilities and involve the right specialists for specific decisions while maintaining synchronization.
? This is the primary reason, as endorsed by the CTA guidance on governance. Effective governance dictates that decisions be made at the most appropriate level.
? The separation ensures that the Executive Steering Board focuses purely on strategy and funding (the Why), the Portfolio Demand Board focuses on prioritization (the What), and the Technical Governance Board focuses on platform standards and architecture (the How). This clear distinction utilizes the expertise of the right stakeholders for each decision type, preventing redundancy and accelerating decision-making while maintaining alignment across the platform strategy.

Incorrect:
• To increase bureaucratic oversight and ensure meticulous documentation.
? While documentation is a necessary output of governance, increasing bureaucratic oversight is antithetical to the goal of efficient platform operation and is not a recommended objective. The goal is to facilitate, not hinder, progress.
• To delegate all technical decisions solely to the Technical Governance Board.
? This is incorrect because not all technical decisions belong to the Technical Governance Board. Key architectural decisions with financial or strategic implications often require approval or review by the other boards (e.g., a major non-standard integration requires Executive approval for budget). The technical board focuses on standards and enforcement, not every technical detail.
• To ensure that budget allocation is strictly separated from strategic vision.
? This is inaccurate. In fact, a key function of the Executive Steering Board is to link the strategic vision to the budget and funding allocation. The governance structure is designed to align these two elements, not strictly separate them.

Correct:
• The Platform Owner, with accountability for safeguarding alignment with enterprise governance.
? According to CTA principles, the Platform Owner is the single, ultimately Accountable senior leader for the entire ServiceNow platform. This accountability extends to the core governance domains, including Data Governance.
? The Platform Owner is responsible for creating and enforcing the strategic vision and governance policies for the platform, ensuring these policies (including those for data ownership, quality, and security) are aligned with the overarching Enterprise Governance framework and business strategy. They preside over the Technical Governance Board, which develops the policies, but the Platform Owner remains the accountable executive.

Incorrect:
• The Enterprise Architect, for creating a single language across IT functions.
? The Enterprise Architect (EA) is a crucial Consulted or Responsible role. The EA designs and enforces architectural standards (including data architecture) and ensures a “single language“ (or consistent data model like CSDM). However, the EA is typically Responsible for the design, not the final Accountable party for the creation and alignment of the policy itself. That accountability rests higher with the Platform Owner.
• The Platform Administrator, for routine instance hygiene activities.
? The Platform Administrator is a Responsible role focused on operational and technical tasks (implementing changes, maintaining health, applying hygiene). They are responsible for enforcing the policies through configurations (e.g., ACLs, data certification), but they do not have the strategic accountability for creating and aligning the governance policy.
• The Security Administrator, for protecting data according to organizational security policies.
? The Security Administrator is Responsible for the implementation and monitoring of security controls (ACLs, encryption) to protect data based on policy. While they contribute heavily to the data governance policy, their role is not to be the single accountable party for the creation and enterprise alignment of the entire data ownership and usage policy.

Correct:
• Regression testing, as ATF reduces time and cost for repeated execution of previously run tests.
? The core requirement is to ensure new functionality does not introduce unwanted regressions to existing features after upgrades or new releases. Regression testing is the process of retesting previously developed and tested parts of the application to ensure that a change (like an upgrade or a new feature implementation) has not negatively impacted existing, working functionality. The Automated Testing Framework (ATF) is ServiceNow‘s native tool, explicitly designed to automate these repetitive, crucial regression test suites, significantly reducing the manual effort, time, and cost associated with validating a highly customized instance after an upgrade. This is a foundational best practice advocated in the CTA domain for maintaining platform integrity.

Incorrect:
• Usability testing, due to its focus on end-user experience.
? Usability testing focuses on how easy the application is for an end-user to use, learn, and operate, often involving real users and subjective feedback. While important, the primary concern in the question is regression (preventing existing features from breaking after a change), which is a functional and technical requirement, not a user experience one. ATF can execute some UI actions, but its core value is in functional validation, not subjective usability assessment.
• Ad hoc testing, which relies on the tester‘s insight without a plan.
? Ad hoc testing is unstructured and performed without a formal test plan or documentation. This approach is unsuitable for the core problem of ensuring an upgrade does not break a highly customized platform. A highly customized environment requires documented, repeatable, and comprehensive testing to ensure all custom logic remains intact, which is the exact opposite of the ad hoc approach.
• Exploratory testing, which requires human intuition due to limited documentation.
? Exploratory testing is the simultaneous learning, test design, and test execution by a human tester, often used when documentation is limited or for uncovering unexpected bugs. While valuable, this is a manual process. The benefit of ATF is automation for repeated validation of existing, critical features during upgrades. Exploratory testing relies on human intuition and cannot provide the consistent, repeatable, and scalable validation needed to secure a customized instance against regression across multiple upgrades.

Correct:

C. To obtain customer/business validation that the platform is set up correctly and meets business outcomes.

This is the core purpose of UAT. It focuses on the customer (the business/end-user) perspective to confirm that the deployed solution on the ServiceNow platform not only functions technically but also directly supports and achieves the business outcomes and processes for which it was implemented. It‘s the final sign-off that the system is “acceptable“ for real-world business use.

Incorrect:

A. To verify that individual code units work as required in isolation.

This describes Unit Testing, which is performed much earlier in the development lifecycle, typically by developers. UAT is an end-to-end, business-process-focused test, not a component-level technical test.

B. To assess the system holistically for overall specification compliance and integration.

This describes System Testing or System Integration Testing (SIT). While UAT is holistic, its primary objective is the business/user acceptance of the solution, whereas System Testing/SIT focuses on whether the system‘s technical components and integrations work together according to the technical specifications and design. UAT follows SIT.

D. To identify potential security vulnerabilities through simulated attacks.

This describes Penetration Testing (Pen Test) or specific Security Testing activities. While security is critical, it‘s a separate, specialized testing phase (or a component of other phases like System Testing) and is not the primary outcome or objective of UAT, which centers on business workflow validation by end-users.

Correct:

The customer must upgrade their instances to the latest release and patch version and implement ServiceNow‘s hardening guide.

ServiceNow‘s policy for allowing a customer-driven penetration test on their instance requires the instance to be in a secure and supportable state. This means the instance must be running a currently supported release family and be on the latest patched version of that family.

Furthermore, the customer must have implemented the ServiceNow hardening guide (or security best practices) to ensure the baseline security posture of the non-production instance (where the testing is typically performed) is robust and correctly configured. The intent is to test the customer‘s configurations and customisations, not known platform vulnerabilities that have already been patched or incorrect default settings covered in the hardening guides.

Incorrect:

The customer must provide a comprehensive list of all custom applications.

While providing the scope for the test, which includes custom applications, is part of the overall engagement, the list of applications itself is a detail of the scope, not the fundamental prerequisite for the test to be allowed to proceed. The core prerequisite is the platform‘s security and patch level.

The customer must sign a waiver releasing ServiceNow from all liability for data breaches during testing.

ServiceNow‘s policy is based on ensuring the instance is patched and hardened, and the test is scheduled and conducted according to their guidelines (typically on a non-production instance). While contractual agreements cover liability, an absolute, blanket waiver releasing all liability is not the specific, mandatory technical prerequisite mentioned in their penetration testing policy for CTA-level knowledge. ServiceNow maintains security and operational controls even during testing.

The customer must perform the test only during peak business hours.

This is incorrect. Penetration tests, especially those that could be resource-intensive or disruptive, are typically required or at least recommended to be performed during off-peak hours or in a controlled non-production environment to minimize impact on critical business operations. Performing it only during peak hours would violate best practices and is not a ServiceNow requirement.

Correct:

Performance testing

Performance testing is a key discipline within non-functional testing that is directly relevant to the ServiceNow Certified Technical Architect (CTA) role, particularly within the “Testing Leading Practices“ and “Platform Data and Integrations“ domains.

It is specifically designed to evaluate how a system operates under a specific workload, focusing on attributes like speed (response time, latency), stability (reliability over time), and scalability (handling increased user load or data volume).

For a CTA, ensuring the solution architecture is scalable and performs under expected loads is critical. This testing provides the data necessary to identify and resolve bottlenecks, ensuring the application is ready for production launch.

Incorrect:

Usability testing

Usability testing is a type of non-functional testing but focuses on the user experience—specifically, how easy and intuitive an application is to use. It evaluates factors like user-friendliness, efficiency, and satisfaction.

It does not primarily provide information about the application‘s technical attributes like speed, stability, or scalability under load, which is the focus of the question.

Documentation testing

Documentation testing, also a form of non-functional testing, evaluates the accuracy, completeness, and clarity of the supporting materials (user guides, administration manuals, online help).

While important for a successful product launch, it does not assess the application‘s operational performance characteristics (speed, stability, scalability).

Localization testing

Localization testing is a type of non-functional testing that verifies the application‘s features for a specific regional or cultural environment. This includes checking language translations, date/currency formats, and legal compliance for a target market.

It does not provide data on the system‘s technical speed, stability, or ability to scale, which are the characteristics requested in the question.

Correct:

It allows validation of developed applications against requirements and ensures new functionality doesn‘t introduce regressions.

The “early and often“ approach, a core principle in modern delivery models like DevOps and crucial for the ServiceNow Certified Technical Architect (CTA), directly addresses two primary concerns:

Validation against Requirements: Testing concurrently with development (or immediately following a change/upgrade) verifies that the new or customized functionality meets the intended business requirements and specifications.

Regression Prevention: The most critical benefit of frequent testing on a platform like ServiceNow is regression testing. Changes, whether from platform upgrades, new releases, or custom development, can inadvertently break existing, previously working functionality. Continuous testing (especially automated testing via the Automated Test Framework/ATF) ensures that the new changes don‘t introduce these “regressions,“ thereby maintaining platform stability and integrity—a key responsibility for a CTA.

Incorrect:

It solely focuses on identifying programming errors in isolated units of code.

This describes Unit Testing, which is a component of the overall testing strategy. The benefit of testing “early and often“ for platform changes is much broader, encompassing system testing, integration testing, and regression testing across the entire application and critical business processes, not just isolated code units.

It primarily reduces the need for manual test case execution.

While frequent testing heavily relies on and drives the automation of test cases (e.g., using ATF), the reduction of manual effort is a means to an end, not the core benefit described in the question. The key benefit is the quality outcome—the validation and regression checking—that the efficiency of automation enables.

It guarantees a completely error-free deployment without any potential issues.

No testing process can offer a guarantee of completely error-free deployment. This is an unrealistic expectation. The benefit of “early and often“ testing is to find issues earlier, reduce the number of critical defects, and lower the cost of fixing them, thereby increasing confidence and quality, not achieving an absolute guarantee.

Correct:

Mobile and Virtual Agent interfaces

For the ServiceNow Certified Technical Architect (CTA), understanding testing boundaries is essential for solution design. The Automated Test Framework (ATF) is explicitly designed for the web UI of the core platform, including Agent Workspace, standard forms, and the Service Portal.

ATF does not support the native testing of ServiceNow Mobile applications (Now Mobile, Agent App, etc.) and, traditionally, it did not support testing the user experience and interface of the Virtual Agent chat client in a UI-based manner. While there are specific features for testing the logic of Virtual Agent topics in the Virtual Agent Designer, a UI-level test of the chat interface itself, similar to how it tests a standard form, is generally not supported.

Incorrect:

Configurable Workspaces (as of Utah, limited support)

While earlier versions had limited support, the CTA must be aware that ServiceNow has continually invested in expanding ATF support for Configurable Workspaces. As of recent releases (e.g., Utah and later), the platform has introduced native ATF support for Configurable Workspaces, allowing architects to automate tests for basic navigation, standard UI actions, and lists within the modern workspace experience. Therefore, this is not explicitly unsupported.

Service Portal components

The Service Portal is generally well-supported by ATF. The framework includes specific test steps like “Open Service Portal Page“ and “Click Service Portal Widget Button“ to interact with the portal‘s UI, including custom widgets using the “Custom UI“ steps. While complex, highly customized portal components might require advanced scripting, the component is fundamentally supported.

Standard record forms and lists

Testing of Standard record forms and lists in the classic UI and Next Experience UI is the primary use case and strength of ATF. ATF provides a rich set of pre-built test steps such as “Set Field Values,“ “Click UI Action,“ and “Open an Existing Record“ specifically to automate tests against these foundational elements of the platform.

Leading practices include managing change from the start, establishing a good OCM team, ensuring communications happen throughout pre go-live, go-live, and post go-live, delivering inspiring messages from leadership, and conducting surveys for feedback. Option 3 is incorrect as communication should happen ‘throughout pre go-live, go-live, and post go-live‘.

At the ‘crawl‘ maturity level, CMDB modeling allows ITSM to start tracking incidents, problems, and change requests against application services.

The ‘Walk‘ level focuses on management of technology services and synchronization of discovered CIs with metadata via technical service offerings. The introduction of business service offerings for different stratifications (like geographies and companies) is a characteristic of progressing to the ‘Run‘ maturity level.

Suzi plans to use ‘Account‘, ‘Sold product‘, and ‘Install base item‘ concepts. Additionally, to link service offerings to sold products, a ‘service model‘ is necessary if services are sold to customers. Business Service is part of the core CSDM model, not specifically a CSM record type introduced for B2B linking.

Governance is defined as a decision-making framework that defines ‘What decisions need to be made and when‘, ‘Who is involved in decision-making‘, and ‘How decisions are made‘. Option 1 describes an operating model, not governance itself, though governance is part of it. Option 5 is an outcome, not a definition of what governance *defines* as a framework.

The Platform owner‘s responsibilities include defining scope, planning, and identifying stakeholders. However, ‘deciding on the governance framework to flex to meet the changing needs of the organization‘ is a broader responsibility that requires executive sponsorship and oversight, as the platform owner alone cannot accomplish this.

The ‘lagging indicator‘ of successful governance is success against top-level, program KPIs, such as whether an implementation delivered on expectations. The other options are ‘leading indicator‘ metrics.

Suzi explicitly suggests ‘Do not try to test everything or the out of the box configuration that ServiceNow has already tested‘.

The ServiceNow Automated Testing Framework (ATF) application is used to create and run automated tests on your ServiceNow instance, for both implementations and release upgrades. Test Management 2.0 is for manual testing.

ATF has limited support for Configurable Workspaces (as of Utah, planned for future releases), does not support Mobile and Virtual Agent, and cannot test the UI of other systems, even if it can test integrations. Standard Service Portals are generally supported.

Regression testing involves re-running tests that have been run before, using a standardized, repeatable process, and automated testing reduces testing time and cost for this.

Non-functional testing is defined as testing the *way* a system operates, in contrast to functional testing, which tests against *functional requirements* describing the *functions* of a system. Therefore, functional testing is not a non-functional test type.

ServiceNow‘s load testing aims to simulate the expected load on a customer‘s instance with automated testing tools replicating the impact of multiple users performing a set of predefined activities. It is explicitly stated that load testing is *not* a stress testing service.

Prerequisites for customer-initiated security testing include upgrading to the latest release/patch, implementing the hardening guide, sharing testing scenarios/findings, and potentially meeting a minimum HealthScan score. Option 3 is not explicitly mentioned as a prerequisite.

The Now Create methodology has five project phases, with go-live being in the ‘Deliver‘ phase. Specifically, ‘Go-Live Transition Planning‘ is listed under the ‘Deliver‘ phase.

The relationship between a business application (credit check) and an application service (credit check prod) is ‘Consumes‘.

The goals of hypercare support include managing incidents/requests in a dashboard, managing handover documents, and continuous service improvement. It is a period of *elevated* support, implying a gradual transition rather than immediate handover. Therefore, immediately transitioning all support responsibilities is incorrect for hypercare.

The ‘Shared Security Model‘ table explicitly lists ‘Data encryption at rest‘ as a Customer responsibility. While Edge Encryption is customer-managed, Platform Encryption and Database Encryption are ServiceNow responsibilities for data at rest. Nevertheless the CTA training materials state in the “Security Architecture“ module that the Customer is the primary responsible for “Data encryption at rest“.

The network layer security section explicitly mentions ‘IP address access control‘ and ‘Edge Encryption‘ as additional network mitigation options. CLE, MFA, and PE are application layer or database layer security features, not network layer mitigations.

Edge Encryption should NOT be used ‘When the customer cannot manage the additional infrastructure, key management, and overall complexity of the solution‘. The other options are reasons *to use* Edge Encryption.

The application layer components include pre-logon, authentication, authorization, and instance settings (hardening, PE, Vault). The database layer is explicitly described as a discrete, non-internet routable network segment where requests from end users or integrations cannot be made directly.

The four considerations for application layer security architecture are: ‘What happens before you get access to the instance?‘, ‘What happens when you log on?‘, ‘What happens while you are on the instance?‘, and ‘What is the behavior of the instance itself?‘. Physical security is part of the overall physical architecture, not the application layer.

ServiceNow Vault is described as a paid plugin that incorporates data security tools including secrets management, code signing, data privacy, and data discovery.

Full Disk Encryption protects only against physical loss or theft of storage devices and provides ‘no additional protection when encrypted disk servers are powered on and providing data‘. Therefore, this statement is INCORRECT.

The three core principles for data import are: ‘Only import data that is needed to support the processes or applications running on ServiceNow‘, ‘Import data from authoritative systems of record for each data element‘, and ‘Choose automated mechanisms over manual and align import schedules with the latency expectations of dependent processes and expected rate of change in the data‘. Options 1 and 2 contradict these principles.

Data Management is the component that practices ‘continuous improvement of data quality, including its accuracy, integrity, relevance, and usefulness‘.

The IRE API processes three types of inbound quality checks: ‘Identification rules‘, ‘Reconciliation rules‘, and ‘Relationship rules‘. Robust Transform Engine (RTE) processes data *before* IRE. Duplicate remediator is a workflow for identified duplicates, not an IRE inbound quality check.

The ‘Managed‘ level signifies ‘Formalized and disciplined data domains with stewardship forums deployed‘. Quantitative measurements and RCA are characteristic of the ‘Quantitatively managed‘ level, which comes after ‘Managed‘.

Data Certification is used to ‘validate CMDB data‘ and ‘Support regular verification of data by owners to ensure accurate data‘, and is leveraged with the compliance function as part of CMDB Health.

The main objective of identifying the current architecture is ‘to support the identification of what? The current mode of operation‘ and ‘identify where issues and gaps are within the business requirements‘.