{"id":22891,"date":"2026-09-26T09:26:34","date_gmt":"2026-09-26T09:26:34","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=22891"},"modified":"2026-09-26T09:26:34","modified_gmt":"2026-09-26T09:26:34","slug":"cisco-ccnp-data-center-300-610-practice-test-questions-and-exam-dumps-part7-q121-140","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cisco-ccnp-data-center-300-610-practice-test-questions-and-exam-dumps-part7-q121-140\/","title":{"rendered":"Cisco CCNP Data Center 300-610 Practice Test Questions and Exam Dumps Part7 Q121-140"},"content":{"rendered":"

View Full <\/b>Cisco CCNP Data Center 300-610 Exam Dumps<\/b><\/a> and Practice Test Dumps.<\/b><\/p>\n


\n<\/b>Question 121. What is the default scope of a standard ACI contract<\/b><\/p>\n

    \n
  1. <\/b> Application profile<\/span><\/li>\n
  2. <\/b> VRF<\/span><\/li>\n
  3. <\/b> Tenant<\/span><\/li>\n
  4. <\/b> Global<\/span><\/li>\n<\/ol>\n

    Correct Answer: 2. VRF<\/b><\/p>\n

    Explanation:<\/b><\/p>\n

    The default scope of a standard Cisco ACI contract is the VRF scope. This means endpoint groups associated with the same VRF can use the contract even when those EPGs belong to different application profiles. Contract scope determines how broadly a policy can be applied and is therefore important when designing segmentation and shared connectivity. Other available scopes include application profile, tenant, and global. Designers should avoid selecting a scope that is broader than required because doing so can unintentionally permit communication between endpoint groups that were expected to remain isolated.<\/span><\/p>\n

    Question 122. Which ACI contract scope can apply across different tenants<\/b><\/p>\n

      \n
    1. <\/b> VRF<\/span><\/li>\n
    2. <\/b> Application profile<\/span><\/li>\n
    3. <\/b> Tenant<\/span><\/li>\n
    4. <\/b> Global<\/span><\/li>\n<\/ol>\n

      Correct Answer: 4. Global<\/b><\/p>\n

      Explanation:<\/b><\/p>\n

      Global is the broadest Cisco ACI contract scope. A contract with global scope can apply between endpoint groups across different tenants in the fabric when the contract is visible to the participating tenants. Cisco advises using this scope carefully because an overly broad global contract can create unintended communication between otherwise separated environments. Intertenant contracts are commonly defined in the common tenant or exported through a contract interface so both sides can reference the contract. Global scope should therefore be selected only when cross tenant communication is an intentional design requirement.<\/span><\/p>\n

      Question 123. Which contract scope restricts use to EPGs in one application profile<\/b><\/p>\n

        \n
      1. <\/b> Application profile<\/span><\/li>\n
      2. <\/b> VRF<\/span><\/li>\n
      3. <\/b> Tenant<\/span><\/li>\n
      4. <\/b> Global<\/span><\/li>\n<\/ol>\n

        Correct Answer: 1. Application profile<\/b><\/p>\n

        Explanation:<\/b><\/p>\n

        Application profile scope limits a Cisco ACI contract to endpoint groups defined within the same application profile. Even if another EPG is located in the same VRF, it cannot use that contract when it belongs to a different application profile. This scope is useful when the designer wants contract policy to remain tightly associated with one logical application. Selecting application profile scope provides stronger policy containment than the default VRF scope. Cisco recommends choosing the narrowest scope that satisfies the intended connectivity because broader scopes can allow additional EPG relationships that were not originally required.<\/span><\/p>\n

        Question 124. Which ACI contract scope can support EPGs in different VRFs of the same tenant<\/b><\/p>\n

          \n
        1. <\/b> Application profile<\/span><\/li>\n
        2. <\/b> VRF<\/span><\/li>\n
        3. <\/b> Tenant<\/span><\/li>\n
        4. <\/b> Context only<\/span><\/li>\n<\/ol>\n

          Correct Answer: 3. Tenant<\/b><\/p>\n

          Explanation:<\/b><\/p>\n

          Tenant scope allows a contract to be used by endpoint groups located in different VRFs as long as those EPGs belong to the same tenant. This makes tenant scope useful for inter VRF communication requirements within one administrative domain. Cisco notes that route leaking must also be configured correctly between the consumer and provider VRFs for inter VRF communication to operate. The contract alone does not create routing reachability. Designers therefore need to plan both policy scope and route leaking behavior when connecting application groups that belong to different routing contexts within one tenant.<\/span><\/p>\n

          Question 125. What is the primary purpose of an ACI taboo contract<\/b><\/p>\n

            \n
          1. <\/b> Permit all IP traffic<\/span><\/li>\n
          2. <\/b> Deny selected traffic<\/span><\/li>\n
          3. <\/b> Create a bridge domain<\/span><\/li>\n
          4. <\/b> Configure VXLAN tunnels<\/span><\/li>\n<\/ol>\n

            Correct Answer: 2. Deny selected traffic<\/b><\/p>\n

            Explanation:<\/b><\/p>\n

            A taboo contract is a Cisco ACI policy construct used to deny specific traffic that might otherwise be permitted by a standard contract. A filter defines the traffic that should be blocked as it travels toward the EPG associated with the taboo policy. Cisco also describes taboo contracts as useful for logging denied traffic. This mechanism allows designers to create broad permit contracts while explicitly excluding certain protocols or ports. Because taboo rules have higher priority than ordinary contract permits, they can provide targeted deny behavior without redesigning all existing communication contracts.<\/span><\/p>\n

            Question 126. Which contract takes precedence when a standard contract permits traffic that a taboo contract denies<\/b><\/p>\n

              \n
            1. <\/b> Taboo contract<\/span><\/li>\n
            2. <\/b> Standard contract<\/span><\/li>\n
            3. <\/b> The oldest contract<\/span><\/li>\n
            4. <\/b> The largest filter<\/span><\/li>\n<\/ol>\n

              Correct Answer: 1. Taboo contract<\/b><\/p>\n

              Explanation:<\/b><\/p>\n

              A taboo contract takes precedence when its deny criteria match traffic that a standard ACI contract would otherwise permit. Cisco assigns taboo policies a higher priority so the explicit deny can override the normal permit relationship. For example, a standard contract can permit general IP communication between two endpoint groups while a taboo contract blocks SSH traffic toward one of those EPGs. This allows administrators to create exceptions to broad connectivity policies while maintaining the original permit contract. Taboo contracts are therefore useful for implementing specific restrictions without completely restructuring existing application communication rules.<\/span><\/p>\n

              Question 127. What is a benefit of defining reusable ACI filters in the common tenant<\/b><\/p>\n

                \n
              1. <\/b> They can be shared by other tenants<\/span><\/li>\n
              2. <\/b> They disable VRFs<\/span><\/li>\n
              3. <\/b> They remove contracts<\/span><\/li>\n
              4. <\/b> They create SAN zones<\/span><\/li>\n<\/ol>\n

                Correct Answer: 1. They can be shared by other tenants<\/b><\/p>\n

                Explanation:<\/b><\/p>\n

                The common tenant provides Cisco ACI objects that can be visible and reusable from other tenants. A commonly used filter can therefore be defined once in the common tenant instead of being recreated independently in every user tenant. This can simplify operations and improve configuration consistency. Cisco cautions that contracts defined in the common tenant require careful scope planning because overly broad contract use can accidentally enable communication across tenants. Reusing filters is often simpler and safer because the filter describes traffic matching criteria while each tenant can still define its own appropriate contract relationships and scope.<\/span><\/p>\n

                Question 128. Where can an intertenant ACI contract be defined so all tenants can see it<\/b><\/p>\n

                  \n
                1. <\/b> Management tenant only<\/span><\/li>\n
                2. <\/b> Infrastructure tenant only<\/span><\/li>\n
                3. <\/b> Common tenant<\/span><\/li>\n
                4. <\/b> APIC local user database<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 3. Common tenant<\/b><\/p>\n

                  Explanation:<\/b><\/p>\n

                  An intertenant contract can be defined in the common tenant, making the contract visible to other tenants that need to consume or provide it. Cisco also supports defining a contract in a user tenant and exporting it to another tenant through a contract interface. The common tenant approach is convenient for shared services and reusable policy, but designers must select the correct scope. A global contract used by several tenants can create cross tenant communication if that behavior is not carefully planned. Contract visibility and contract scope therefore need to be considered together in intertenant designs.<\/span><\/p>\n

                  Question 129. What does NDFC bootstrap use for day zero switch provisioning<\/b><\/p>\n

                    \n
                  1. <\/b> POAP<\/span><\/li>\n
                  2. <\/b> HSRP<\/span><\/li>\n
                  3. <\/b> FSPF<\/span><\/li>\n
                  4. <\/b> LACP<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 1. POAP<\/b><\/p>\n

                    Explanation:<\/b><\/p>\n

                    Cisco Nexus Dashboard Fabric Controller bootstrap functionality uses NX OS PowerOn Auto Provisioning to simplify day zero deployment of new switches into an existing fabric. POAP can provide initial management addressing and configuration so a new switch can be brought under fabric management with minimal manual setup. NDFC can use either a local DHCP service or an external DHCP server for automatic address assignment during bootstrap. This automation reduces the repetitive console configuration normally required when installing multiple switches and helps ensure devices enter the fabric with consistent initial settings.<\/span><\/p>\n

                    Question 130. Which address assignment methods can NDFC bootstrap use for POAP<\/b><\/p>\n

                      \n
                    1. <\/b> DNS only<\/span><\/li>\n
                    2. <\/b> Static routing only<\/span><\/li>\n
                    3. <\/b> RADIUS only<\/span><\/li>\n
                    4. <\/b> Local or external DHCP<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 4. Local or external DHCP<\/b><\/p>\n

                      Explanation:<\/b><\/p>\n

                      NDFC bootstrap can use either a local DHCP server function or an external DHCP server to provide automatic management addresses during POAP. When local DHCP is enabled, the administrator defines the appropriate DHCP scope information in Nexus Dashboard. If local DHCP is not selected, the deployment can reference an external DHCP infrastructure. POAP then uses the supplied network information as part of the automated day zero switch bring up process. This flexibility allows designers to integrate bootstrap operations with an existing enterprise DHCP service or use NDFC supplied DHCP functionality when appropriate for the deployment.<\/span><\/p>\n

                      Question 131. What is the main purpose of NDFC Image Management<\/b><\/p>\n

                        \n
                      1. <\/b> Create ACI EPGs<\/span><\/li>\n
                      2. <\/b> Automate switch software lifecycle tasks<\/span><\/li>\n
                      3. <\/b> Configure server BIOS<\/span><\/li>\n
                      4. <\/b> Create Fibre Channel zones only<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 2. Automate switch software lifecycle tasks<\/b><\/p>\n

                        Explanation:<\/b><\/p>\n

                        Nexus Dashboard Fabric Controller Image Management automates software lifecycle operations for supported Cisco Nexus switches. Cisco describes workflows for planning upgrades, scheduling operations, downloading or staging software, validating compatibility, monitoring compliance, and performing supported upgrade procedures. Managing these tasks centrally reduces the time and potential human error associated with manually upgrading switches one at a time. Image policies can specify the expected software version and patch level for groups of switches so administrators can quickly identify devices that do not match the intended software baseline.<\/span><\/p>\n

                        Question 132. What does image staging copy to a Nexus switch<\/b><\/p>\n

                          \n
                        1. <\/b> ACI contracts<\/span><\/li>\n
                        2. <\/b> Service profiles<\/span><\/li>\n
                        3. <\/b> Software image files<\/span><\/li>\n
                        4. <\/b> Fibre Channel zones only<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 3. Software image files<\/b><\/p>\n

                          Explanation:<\/b><\/p>\n

                          Image staging copies the required software image files to the switch bootflash before the actual software upgrade takes place. Cisco allows staging and validation work to be performed before the maintenance window so the disruptive portion of an upgrade can be shorter and more predictable. Validation can confirm that the image is complete and suitable for the target hardware and can help determine whether a supported nondisruptive upgrade is possible. Separating staging from activation also gives administrators time to resolve image transfer or compatibility issues before production maintenance begins.<\/span><\/p>\n

                          Question 133. What does an NDFC image policy compliance check compare<\/b><\/p>\n

                            \n
                          1. <\/b> Actual and expected software versions<\/span><\/li>\n
                          2. <\/b> MAC and IP addresses<\/span><\/li>\n
                          3. <\/b> EPG and bridge domain names<\/span><\/li>\n
                          4. <\/b> GPU and CPU utilization<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 4. Actual and expected software versions<\/b><\/p>\n

                            Explanation:<\/b><\/p>\n

                            NDFC image policy compliance determines whether the software running on a managed switch matches the version and patch level defined by the attached image policy. When a switch is out of compliance, administrators can review the current and expected software versions and plan an upgrade or downgrade as appropriate. This provides a centralized method for maintaining consistent NX OS software baselines across groups of switches. Software consistency can simplify operations, reduce feature mismatches, and help make maintenance planning more predictable in large data center fabrics.<\/span><\/p>\n

                            Question 134. What should be disabled before an NDFC managed Nexus software upgrade<\/b><\/p>\n

                              \n
                            1. <\/b> POAP boot mode<\/span><\/li>\n
                            2. <\/b> BGP<\/span><\/li>\n
                            3. <\/b> vPC<\/span><\/li>\n
                            4. <\/b> All VLANs<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 1. POAP boot mode<\/b><\/p>\n

                              Explanation:<\/b><\/p>\n

                              Cisco Image Management guidance states that POAP boot mode should be disabled on supported Nexus 9000 and Nexus 3000 switches before performing the software upgrade. The setting can be enabled again after the upgrade is complete when POAP functionality is still required. This precaution prevents the switch from unintentionally entering the automated provisioning process during maintenance or reload operations. Administrators should also ensure that the appropriate device credentials are configured in Nexus Dashboard Fabric Controller before attempting workflows such as in service software upgrade operations.<\/span><\/p>\n

                              Question 135. What does an NDFC fabric template generate<\/b><\/p>\n

                                \n
                              1. <\/b> GPU firmware<\/span><\/li>\n
                              2. <\/b> Server operating systems<\/span><\/li>\n
                              3. <\/b> Intended fabric switch configuration<\/span><\/li>\n
                              4. <\/b> SAN disk volumes<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 3. Intended fabric switch configuration<\/b><\/p>\n

                                Explanation:<\/b><\/p>\n

                                An NDFC fabric template contains the logic and rules required to generate intended switch configuration for an entire managed fabric. Cisco fabric templates integrate with elements such as device roles, topology information, resource management, and configuration compliance. NDFC includes predefined templates for common architectures such as Data Center VXLAN EVPN, Enhanced Classic LAN, BGP Fabric, and external connectivity environments. Because fabric templates encode Cisco recommended deployment logic, administrators generally select an appropriate built in template rather than creating a complete fabric template from the beginning.<\/span><\/p>\n

                                Question 136. What does an NDFC profile template primarily provision<\/b><\/p>\n

                                  \n
                                1. <\/b> Physical chassis power<\/span><\/li>\n
                                2. <\/b> Overlay networks and VRFs<\/span><\/li>\n
                                3. <\/b> Server UUID pools<\/span><\/li>\n
                                4. <\/b> Fibre Channel domain IDs only<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 2. Overlay networks and VRFs<\/b><\/p>\n

                                  Explanation:<\/b><\/p>\n

                                  Cisco distinguishes profile templates from broader fabric templates. A profile template is used primarily to provision overlay objects such as networks and VRFs, while a fabric template contains the larger rules and logic needed to create the overall fabric architecture. This separation allows administrators to use one fabric design while repeatedly creating application networks and routing segments according to standardized overlay templates. NDFC therefore combines infrastructure level automation with reusable service level provisioning so the physical and logical elements of a data center fabric can be managed consistently.<\/span><\/p>\n

                                  Question 137. What is the default power redundancy mode for a UCS X9508 chassis<\/b><\/p>\n

                                    \n
                                  1. <\/b> N plus 1<\/span><\/li>\n
                                  2. <\/b> Grid<\/span><\/li>\n
                                  3. <\/b> Not Redundant<\/span><\/li>\n
                                  4. <\/b> N plus 2<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 1. N plus 1<\/b><\/p>\n

                                    Explanation:<\/b><\/p>\n

                                    Cisco specifies N plus 1 as the default power redundancy mode for the UCS X9508 chassis under the documented initial discovery and recommissioning conditions. In N plus 1 mode, Power Manager turns on the minimum number of power supplies required to support the chassis load and keeps one additional PSU available for redundancy. This provides protection against a single power supply failure while avoiding the greater power reserve required by N plus 2 operation. Designers should select the redundancy mode according to power source architecture, availability requirements, and available chassis power capacity.<\/span><\/p>\n

                                    Question 138. What does Grid power redundancy require<\/b><\/p>\n

                                      \n
                                    1. <\/b> One PSU only<\/span><\/li>\n
                                    2. <\/b> No standby capacity<\/span><\/li>\n
                                    3. <\/b> One power source<\/span><\/li>\n
                                    4. <\/b> Two power sources<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 4. Two power sources<\/b><\/p>\n

                                      Explanation:<\/b><\/p>\n

                                      Grid redundancy is designed around two independent power sources. Cisco explains that if one source fails, the power supplies connected to the surviving source must be able to provide sufficient power for the chassis. This design protects against failure of an entire upstream power feed rather than only the loss of one individual PSU. Grid redundancy is therefore appropriate when the data center supplies two independent electrical feeds and the server architecture must continue operating after either feed fails. Power capacity on each side must be designed to support the required chassis load independently.<\/span><\/p>\n

                                      Question 139. What is the default UCS thermal fan control mode described by Cisco<\/b><\/p>\n

                                        \n
                                      1. <\/b> Low Power<\/span><\/li>\n
                                      2. <\/b> Balanced<\/span><\/li>\n
                                      3. <\/b> Maximum Power<\/span><\/li>\n
                                      4. <\/b> Acoustic<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 2. Balanced<\/b><\/p>\n

                                        Explanation:<\/b><\/p>\n

                                        Balanced is the default fan control mode in the documented Cisco thermal policy. In Balanced mode, fan speed increases when additional cooling is required based on server heat output and returns toward the minimum necessary speed when thermal demand falls. This mode seeks a practical balance between cooling effectiveness, power consumption, and acoustics. Cisco notes that particular server configurations, such as systems containing certain PCIe cards, can require different cooling behavior. Thermal policy should therefore reflect the actual server hardware, workload, rack cooling design, and environmental conditions rather than relying automatically on the default for every deployment.<\/span><\/p>\n

                                        Question 140. What does Low Power thermal mode do<\/b><\/p>\n

                                          \n
                                        1. <\/b> Runs fans at maximum speed<\/span><\/li>\n
                                        2. <\/b> Disables all chassis fans<\/span><\/li>\n
                                        3. <\/b> Uses lower minimum fan speeds<\/span><\/li>\n
                                        4. <\/b> Removes power redundancy<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 3. Uses lower minimum fan speeds<\/b><\/p>\n

                                          Explanation:<\/b><\/p>\n

                                          Low Power thermal mode operates fans at slightly lower minimum speeds when the server can safely remain within its thermal limits. The goal is to reduce power consumption when maximum cooling is unnecessary. Cisco contrasts this with High Power and Maximum Power modes, which maintain higher fan speeds and prioritize cooling or performance at the cost of greater power use. Designers should not select Low Power solely to reduce energy consumption without considering installed components and workload characteristics. Insufficient cooling can increase component temperatures and potentially affect performance or hardware reliability.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full Cisco CCNP Data Center 300-610 Exam Dumps and Practice Test Dumps. Question 121. What is the default scope of a standard ACI contract Application profile VRF Tenant Global Correct Answer: 2. VRF Explanation: The default scope of a standard Cisco ACI contract is the VRF scope. This means endpoint groups associated with the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/22891"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=22891"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/22891\/revisions"}],"predecessor-version":[{"id":22892,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/22891\/revisions\/22892"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=22891"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=22891"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=22891"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}